OSDev.org

That is an urban legend.

Some people probably observed that even recent MS boot loaders don't use the BIOS returned DL but rather rely on the BPB Drive ID.
They probably inferred from this that the BIOS Drive ID could not be relied upon. (This, in itself led to a lot of USB booting difficulties
for a lot of people and also contributed to the USB MBR booting urban legend).

The fact is that early MS-DOS ran on computers (before and during the early IBM PC era) that had no BIOS. CP/M, 86DOS and early
MS-DOS came with OEM supplied BIOS on disk. The machine itself only had minimal firmware code to load one specific sector to a
specific address and jump to it. That "boot sector" then loaded some or all of the "BIOS" file. Even with the latest version (Win98) io.sys,
only four sectors were loaded. io.sys then loaded the rest itself.

So, at that time, there was no Drive ID and of course only one floppy drive attached to the computer - so not much need to identify it.
Backwards compatibility being the hallmark of MS.

So, at that time, there was no Drive ID and of course only one floppy drive attached to the computer - so not much need to identify it.

Not true. The disk controller boards from Seattle Computers - for which the precursor of MS-DOS was developed - supported up to 8 disk drives; four 8" ones and four 5 1/4" ones. Although if we are talking about a product marketed as MS-DOS, that was for the IBM PC not earlier computers.

Even if there was more than one floppy drive (or hard drive) attached to the computer, there was no need to identify it: only the first drive could be used to boot the machine. It was also unnecessary to differentiate between floppy and hard drive: you would write different data to the BPB based on the type of disk.

Of course, if you did need to differentiate between the two, at least on the XT 286, DL would contain the expected value. Unfortunately, there's no indication that it's intentional. The source code has no comments to that effect, and there's no source code available for any of the hard disk adapter ROMs for other IBM PC models.

The Plug and Play BIOS Specification states that DL will contain a valid drive number as long as the BIOS reports itself as Plug and Play compatible, but says nothing about what happens otherwise. The BIOS Boot Specification suggests always using DL, which implies that there weren't many incompatible BIOSes (or at least they were all obsolete by 1996).

I wonder if there are any pre-1996 references to the BIOS passing the drive number in DL...

Hi,

mikegonta wrote:That is an urban legend.

I've been doing OS development (and helping beginners, etc) for about 15 years now, and I have never heard of this supposed "urban legend". Nor have I ever seen a computer that doesn't pass the BIOS drive number in DL correctly; and have never heard of anyone having problems because the BIOS drive number wasn't passed in DL correctly.

I think you made this up yourself, and are trying to pretend it's an "urban legend" in an attempt to legitimise some unknown (and likely foolish) plan you've concocted.

mikegonta wrote:Some people probably observed that even recent MS boot loaders don't use the BIOS returned DL but rather rely on the BPB Drive ID.

I doubt it. For example, Microsoft's MBRs do rely on DL.

However; as far as I know (I haven't studied it properly or anything) Microsoft do an incredibly stupid thing - they have a "boot manager" built into the start of the boot code which is controlled by a configuration file ("boot.ini")' and the boot sectors for other OSs are expected to be stored as files in the same file system, and it doesn't chain load boot sectors in a sane/acceptable way. Their boot manager probably uses the device path (from the config file) to determine what value it should pass to the copy of the boot sector. The fact that Microsoft's boot manager is able to boot something completely different (e.g. a Linux boot sector) that does not have a BPB at all indicates that they are not using the values from the BPB.

Also note that whenever the user copies file systems around or adds/removes disk drives to their system the "drive ID" in the BPB becomes wrong. For this reason you'd have to be extremely incompetent to rely on it.


Cheers,

Brendan

en.wikipedia.org wrote:DL is supported by IBM BIOSes as well as most other BIOSes. The Toshiba T1000 BIOS is known to not support this properly, and some old Wyse 286 BIOSes use DL values greater or equal to 2 for fixed disks (thereby reflecting the logical drive numbers under DOS rather than the physical drive numbers of the BIOS).

I think those old BIOSes are irrelevant nowadays. There are much more advantages of using the DL value passed by whathever runs before your boot sector (e.g. chain-loading scenarios). Although I took this problem into account in my boot sector so that changing a single byte will make it use the hard coded BPB value if I wanted to try it on some very rare hardware. The default behaviour is of course to use the passed DL value.

mikegonta wrote:The fact is that early MS-DOS ran on computers (before and during the early IBM PC era) that had no BIOS. CP/M, 86DOS and early
MS-DOS came with OEM supplied BIOS on disk. The machine itself only had minimal firmware code to load one specific sector to a
specific address and jump to it. That "boot sector" then loaded some or all of the "BIOS" file. Even with the latest version (Win98) io.sys,
only four sectors were loaded. io.sys then loaded the rest itself.

Nope, MS-DOS proper only ever ran on machines with the BIOS in ROM. There is some potential for confusion in the fact that IO.SYS was the DOS equivalent to a disk-loaded component that had been called the BIOS on on CP/M systems, and the word "BIOS" was sometimes used to refer to IO.SYS, but under DOS and all later PC operating systems, the word "BIOS" with no other qualifications or clarifications refers to the system firmware, not to IO.SYS.

I have this strange sense of déjà vu.

mikegonta wrote:The machine itself only had minimal firmware code to load one specific sector to a specific address and jump to it. That "boot sector" then loaded some or all of the "BIOS" file.

This sounds exactly how boot sectors have worked all the time. I would assume that the "boot sector" is using the firmware routines for loading more sectors. Even if that firmware had not contained all the services that moderd BIOS implementations have, meaning that the "BIOS file" contained some code that supplemented missing functionality, the "firmware something" would still be a kind of BIOS.