Good grief, and here I was thinking Microsoft _finally_ got around to
fixing that. (I mean, cripes... at least look at a flaming CD
fellas?!)
That can create problems in the truly general case. Think about
it: you are loading drivers for an HBA and want to get them from
a CD-ROM, potentially attached to that very same HBA...
I think USB could be difficult due to the fact that the initial loader
(in the case of Windows XP and earlier) started in DOS, loaded the
drivers into RAM then kickstarted the NT kernel from there, but one
would have thought that on modern systems, the BIOS should still at
least allow some access to USB drives. And clearly CD-ROMs are
accessible as it loads the rest of the drivers that way.
That would seem the most natural PC way of doing things. I'm not
really familiar with the Windows boot process anymore but there
has to be _some_ point early on where the BIOS is still readily
accessible and kernel modules can easily be loaded.
Of course the most elegant way would be to place basic get-you-home
drivers on the device itself. Sun managed this twenty years ago
with their OpenPROM system, and that didn't even depend on the CPU
since they were written in architecture-independent Forth. However
that probably requires the kind of centralised planning and
authoritative "this is the way it is going to be done" assertion
that is difficult to enforce for commodity x86 hardware. The only
time I can see you doing it is with a new bus standard: if e.g.
PCIe had demanded it manufacturers would have little wriggle room.
