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; §5.8), 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?

2 Answers 2


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 two bytes at offset 0x0DA. If they are zeroes, IOS checks the following four bytes: if they are also zeroes (like in the standard MBR code written by Microsoft’s FDISK), IOS overwrites them with an identification signature1, again using interrupt 0x13 services. Otherwise the existing contents are assumed to be a signature that is remembered for later. If any of the above fails, then as a fallback a sum-of-doublewords checksum of the boot sector is computed and remembered instead.

This mechanism is alluded to in the I/O Supervisor Guide for Windows 9x/Me Operating Systems, a document provided by Microsoft to device driver writers (it used to be available from Microsoft; original download preserved by Internet Archive). On page 38, it mentions 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. If you extract IOS.VXD from within VMM32.VXD and disassemble it, you will find code that performs the very process described above, and stores the result in a data structure matching the description in the I/O Supervisor Guide.

After the above probing process is done, 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 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.)

1 The signature, also referred to as ‘the mystery bytes’, 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.

  • Turns out disassembly was not necessary. <web.archive.org/web/20040117095839id_/http://…> describes this process and more. It claims the probing of fixed sector numbers did continue well into the Windows 95 days. I may incorporate this into this answer at some point. Jan 11, 2022 at 22:05
  • Warning: above link is to an EXE file containing a DOC file. It's a ZIP SFX so it might open with a normal ZIP archive program.
    – Joshua
    Jan 16, 2023 at 17:19

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

  • 1
    There’s also a detailed explanation of some of wdctrl’s behaviour in Geoff Chappell’s DOS Internals. Apr 7, 2020 at 15:57
  • 1
    Are you sure Windows 95 still uses wdctrl? From what I can see, it doesn’t... Apr 7, 2020 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. Apr 7, 2020 at 19:32
  • 2
    While I have the greatest respect for Schulman's work, I'm not convinced trusting a book published in 1994 to be an authoratitive guide to the behaviour of Windows 95 is a great idea. It must have been based on beta/preview releases and details may have changed between writing and the actual RTM version of the OS. OTOH, the vogons.org thread is interesting, and the results posted there do tend to confirm this theory. And yet the behaviour of Win95 regarding duplicated MBRs is also wellmdocumented. It seems more research is required here...
    – occipita
    Aug 13, 2020 at 5:47
  • 1
    I think Schulman’s description of the architecture in Windows 95 is fine; it’s not like Microsoft could afford to significantly change it at the last minute. Thing is, nowhere does he claim that wdctrl (or a driver that uses an identical detection mechanism) is used in Windows 95. This claim is also contradicted by the linked Vogons thread. This answer is indeed wrong; what it actually applies to is Windows 3.1. Aug 14, 2020 at 11:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .