Can you confirm that there is a "UEFI" PnP HWID?

Quoted from Ray Hinchliffe's SIF (System Information Viewer) included file pnpdevs.txt:

they all had purple colour, and needed a driver post install (hence, no boot HDD ever worked from esata in XP)

I think we tried that in our search for sillicon hyll gigabyte sil 3132, and I blew a mobo by attempting a "suggested fix" that I did while the BIOS prevention (a dual bios..) said I shouldnt.
GB replaced it at no cost (I gave Wim Leers back the money some of the donators forked out for that episode)

the third party port was never meant to boot from, but it was esata (a boon to me, for data rescue work)
Today, it's another ball game.

The capability has to be SET.
What if you did not, and you try it? Any known law cases yet?

I dont think I have this wrong, Sir.
Man, I read what you did for us here at DriverPacks.. I am gonna take lessons from you real soon, god willing.

hot swap can be a setting in UEFI BIOS.
iow, in legacy mode the on mobo port ain't even selectable as hot swap, and in UEFI mode it has that capability.

way back, I had to make damn sure the purple ports were connected to a true hot swap bay, now it's a new ball game.

TIP for people building your own.
internal sata to external wit Esata capabilities, make use of unique color cables, because you will much sooner than you think make an error in that spaghetti.
(many of my test mobos had more than 4 HDD ports. The craziest I went was 10HDD and two DVD.)

This does not mean I never put together a machine with just one HDD, but I Always wanted ports to spare.

Hot swap is a setting in either the firmware or in the software. and should present itself regardless of the physical cable.

(hang a drive on a regular cable direct to the MB, unplug as needed .

Therefore; PCIide is installed,
which apparently from what i've read thusfar, will not support Hot-Swap!

Unfortunately, i have no eSATA cable for testing.
A regular SATA cable will not fit.

I do reason that a modified .Inf would rectify this situation, if true.

However; i will not make the change and simply document this theory here.  Done.

Can anyone enlighten me further?

I will venture to do some testing with only the in-box native driver during Setup, then compare benchmarks & hot-swap ability with either the Intel-supplied intelide or pciide based drivers.

I have read that in at least NT6 that TRIM is supported by both drivers.

Primarily, i would like confirmation on how this should work on NT5, with an eye towards NT6.x.  This discussion doesn't yet take AHCI (msahci.inf) into consideration.

I see that intelide, a native driver, is used for Intel controllers ICH0 through ICH5 (w2k) & ICH6 (xp,2k3) by NT5.  All other "unknown" pci controllers tend to use pciide, another native driver.  This is accomplished via the driver mshdc.inf.  Note that any Intel PCI IDE controller newer than ICH6 should natively install the pciide driver.

Add Intel's Chipset package into the mix with it's own drivers.  Now we have a choice between intelide and pciide.  There are drivers named ibexide.inf for instance, which generally support pciide (mask of ????ide.inf).  There is also drivers named ibexid2.inf for instance, which generally support intelide (mask of ????id2.inf).

Both types of driver have been included in DriverPacks, since at least 2007.  This has not been without issue.

I do recall that the intelide driver did cause issue for some with ICH7 controllers (changed in MS v11.07).    see:  http://forum.driverpacks.net/viewtopic. … 885#p37885
There have also been issues with Sysprep, and some Dell GX600 series systems, if i have read those topics correctly.

Conclusion:  For NT5, i tend to think that these drivers should be archived as "intelide" and "pciide".  It should be up to the individual whether or not they are installed.  This would avoid any possible pitfall of their usage.  It also offers an obvious bugfix should native drivers fail.

What are your thoughts?