DOS boot sector, BPB, and the media descriptor byte

All DOS programmers know that DOS storage media (floppies, fixed disks, even RAM drives) have a BPB (BIOS Parameter Block) which describes the basic layout of the storage medium. All DOS programmers also know that every DOS disk contains a boot sector with a 0x55, 0xAA signature in the last two bytes and the BPB stored at offset 3 and starting with an 8-byte OEM identifier. Sadly, it’s not true. There are DOS disks with no signature in the boot sector and no BPB stored in the boot sector. Even when there is a BPB, it’s not necessarily correct.

The basic problem with BPBs is that they were only introduced in DOS 2.0; previous versions of DOS did not use the concept at all. It’s easy to see why: DOS 1.0 only supported a single storage medium format (a single-sided 5¼” floppy with 40 tracks and 8 sector per track, 160KB total capacity). There was no real need to distinguish between various formats, although there was a way to do so through the media descriptor byte in the FAT.

DOS 1.1 was shipped with updated PCs that had double-sided floppy drives. An additional format utilizing both sides was supported, with 320KB total capacity. The media descriptor byte was used to distinguish between the single-sided and double-sided formats.

When DOS 2.0 was shipped with the PC/XT, additional floppy formats with 9 sectors per track (180KB and 360KB) were introduced. The media descriptor byte could still be used to distinguish between 1/2 sides and 8/9 sectors per track. But the XT also supported fixed disks, and the media descriptor byte was woefully inadequate for describing fixed disk formats.

DOS 2.0 therefore created the concept of a BIOS Parameter Block—or BPB—which contained basic disk geometry information. It was stored in the disk’s boot sector. There was just one problem—none of the existing DOS 1.x disks contained any BPB.

Microsoft’s solution was to build the BPB on the fly. For fixed disks there was no problem; DOS 1.x could not work with them, hence there was no backwards compatibility to worry about. For floppies, only two BPB-less formats existed and were easy to distinguish from each other by the media descriptor byte. The upshot was that for fixed disks, the BPB had to be always correct, but for floppies, it was not always used.

When formatting disks, DOS 2.x and later always wrote the BPB, but the BPB was not always used when accessing floppies. This inconsistency led to an embarrassing bug: DOS versions starting with 2.0 and ending with 3.1 wrote incorrect BPBs in certain cases. I was recently bitten by this bug when working with a single-sided floppy formatted by DOS 2.0 (in a virtual machine, of course). The BPB claimed the disk used two sectors per cluster, but in reality it was just one. Any software which trusts the BPB is not going to work.

When adding 3½” floppy support, Microsoft tried to use the BPBs whenever available (instead of the media descriptor byte which was no longer adequate even for floppies), the bug became obvious. Microsoft’s solution was a classic hack: use the OEM ID signature (which in theory was purely informational and might contain any data) and check for DOS versions older than 3.2. For old versions, fix up the BPB with presumably correct data. For newer versions, use the BPB as it exists on the disk. The solution worked since the PC-DOS and MS-DOS wrote OEM ID signatures containing the DOS version. Disks formatted by third party software hopefully had correct BPBs.

Years later, Microsoft forgot about how all that stuff had worked. Windows 9x reused the OEM ID signature as a hash and destroyed the original OEM identifier.  In theory, a user might have a disk with an unusual format but a valid BPB, recognized as such by Windows. Then Windows would destroy the OEM ID and would no longer be able to access the data on the disk. Very clever!

To my knowledge, the relationship between the media descriptor bytes and BPBs was never documented by Microsoft, and the exact algorithms for building BPBs were not documented either. That led to third party software often getting things subtly wrong. Eventually Microsoft became the victim of its own design blunders, as if attempting to prove that quick hacks can in the long run cause more problems than they solve.