Windows 9x can employ two kinds of disk drivers: native protected-mode drivers and compatibility-mode DOS drivers, and the former are used in preference to the latter whenever possible. When Windows is started and native disk drivers are loaded, existing DOS drivers for each drive letter are disabled and the protected-mode drivers take over. If there are any drives left that Windows doesn’t have native drivers for, Windows falls back to using DOS drivers for those, resulting in a Control Panel message: "Drive X is using MS-DOS compatibility mode file system".

DOS disk drivers usually delegate hard disk accesses to interrupt 0x13 services, which identify each available disk by an 8-bit number. Protected-mode drivers, on the other hand, access the disk by directly communicating with the disk controller, which does not use BIOS disk numbers. In order to identify which protected-mode drivers correspond to which drive letters, some kind of mapping between DOS/BIOS disk numbers and the bus positions where the disks are attached has to be established.

The EDD 3.0 specification defines a structure through which a BIOS may communicate this mapping to the operating system (AH=0x48), but that probably wasn’t universally available back when Windows 95 was developed.

How then does Windows 9x identify which letter corresponds to which disk?


By their contents.

When Windows boots, the I/O Supervisor VxD (IOS) uses BIOS interrupt 0x13 services to read sector 0 (the Master Boot Record) of each drive. It then looks at six bytes at offset 0x0DA; if they are all zeroes (like in standard MBR code written by Microsoft’s FDISK), IOS writes an identification signature¹ at offset 0x0DC, again using interrupt 0x13. A checksum of the boot sector is computed and remembered, along with the four signature bytes at offset 0x0DC.

Then, sector 0 of each drive is read again, this time using native disk drivers, and compared² against data remembered in the previous step. If the checksum and/or signature bytes match, IOS assumes the disk to be the same. The partitions themselves are then matched to DOS drive letters by their partition offsets, and the drive letters are handed over to the protected-mode driver. Partitions that have not been assigned drive letters by DOS are assigned new ones.

This mechanism is the reason why Windows 9x may be confused by disk cloning software: if at boot time IOS sees two disks with identical MBRs with the signature field filled, it will not write a new signature (because it cannot assume the field is free to use) and will later confuse the two disks for each other. The solution is to rewrite the MBR for either drive so that the signature bytes differ; ideally, they should be cleared back to zero, so that IOS may fill them again.

(The above only applies to hard disks; this method obviously cannot work with floppy and CD-ROM drives, even though Windows native drivers manage to take over from DOS drivers for those as well.)

Later edit: A document called the I/O Supervisor Guide for Windows 9x/Me Operating Systems, apparently official (it used to be available from Microsoft), mentions on page 38 a list of data structures ‘used to audit and reconcile boot record vs. drive letter when assigning drive letters during IOS conversion from real mode to protected mode drivers’, each containing the BIOS disk number, some checksum and some disk signature. This seems to confirm the above research.

¹ The signature is of the form nn ss mm hh (where nn is the BIOS disk number and ss mm hh is the current time as a binary-coded decimal). The actual contents don’t matter too much, though; the goal is simply to have some identifying value that is hopefully unique among all disks attached to the system.

² Presumably the signature bytes are used in preference to the checksum, but I have not investigated which is used in what circumstances. I have not researched the checksum algorithm either.

| improve this answer | |

It wasn't anything to do with drive letters, or the Windows NT disc signature in the MBR.

DOS-Windows 9x, in particular the infamous wdctrl virtual device driver (often known colloquially and misleadingly as "32-bit disk access"), after determining that it was reasonable for it to supplant the real-mode firmware in the first place, issued three INT 13h calls to the firmware, and watched to see which ATA I/O ports were accessed and what the controller register contents specifying the command and C/H/S address were.

This can be seen from the old Microsoft KnowledgeBase article Q119674 which describes the three rounds of I/O requests and their negative test results, and the source code of DOSBox-x (and above) which has to fake the behaviour of actual hardware.

From this wdctrl knew a mapping from the 00,01, … 80, 81, … disc numbers used at the firmware level to the actual ATA I/O registers. This is effectively the same information as returned (for a root-bus ATA bus) in the device and interface paths from the EDD API call.

Schulman notes the INT 2Fh broadcasts for letting firmware extensions and replacements know that device detection is in progress, giving slightly more detail than Brown.

Further reading

| improve this answer | |
  • 1
    There’s also a detailed explanation of some of wdctrl’s behaviour in Geoff Chappell’s DOS Internals. – Stephen Kitt Apr 7 at 15:57
  • 1
    Are you sure Windows 95 still uses wdctrl? From what I can see, it doesn’t... – Stephen Kitt Apr 7 at 17:06
  • 4
    I didn’t mention Windows NT disk signatures anywhere in my answer. I mentioned a disk signature, but it isn’t the Windows NT disk signature. And yes, I actually checked this is how it works. – user3840170 Apr 7 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.