16

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?

Improve this question
25

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 signature¹, 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.

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 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 corroborate the above research.

¹ 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.

Improve this answer
9

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 '20 at 15:57
  • 1
    Are you sure Windows 95 still uses wdctrl? From what I can see, it doesn’t... – Stephen Kitt Apr 7 '20 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 '20 at 19:32
  • 1
    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 '20 at 5:47
  • I also note that this approach would fail on systems that supported non-IDE drives in BIOS, even if an appropriate 32-bit driver were loaded. – occipita Aug 13 '20 at 5:47

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.