DOS boot hang update

Additional information came to light regarding the hangs with DOS 2.x/3.x when booting from a disk with large number of sectors per track.

The problem appears to have been noticed sometime in 1987—perhaps. The MS-DOS OEM Adaptation Kit (OAK) for MS-DOS 3.21 from May 1987 includes the buggy boot sector prone to hangs. However, the OAK for MS-DOS 3.30 from July 1987 contains a fix for the problem. That might suggest the problem was fixed around June 1987, but there’s more to the story. First a long digression…

The source code for SYS.COM in the MS-DOS 3.30 OAK shows that in June 1986(!), IBM made a change to only require the first 2,048 bytes (or four 512-byte sectors) of IBMBIO.COM to be contiguous. There’s interesting logic in the code which assumes (not unreasonably) that if IBMBIO.COM exists on the target disk, it is in the correct place and even if it’s the PC DOS 1.x version, covers enough contiguous space.

The MS-DOS 3.30 OAK Adaptation Guide is almost identical to the 3.21 version. One of the few differences is that the 3.30 version explicitly mentions that only IO.SYS needs to be contiguous and MSDOS.SYS does not.

Interestingly, the 3.30 Adaptation Guide is at odds with KB 66530 which claims that in fact only the first three sectors of IO.SYS need to be contiguous (and at the very beginning of the disk’s data area). The Adaptation Guide in both cases (3.21 and 3.30) says that the boot sector may load both IO.SYS and MSDOS.SYS, or only IO.SYS which will then load MSDOS.SYS on its own.

To add to the fun, the MS-DOS 3.30 packaged product (with file dates from February 1988) shipped on disks with DOS 3.2 boot sectors, but its FORMAT.COM and SYS.COM wrote out the updated DOS 3.3 boot sector which is safe for modern disks. Since the boot floppies shipped by Microsoft only had 9 sectors per track (typically 360K, perhaps 720K media), there was no problem.

Looking at the source code for SYS.COM in the MS-DOS 3.30 OAK, it is apparent that the Adaptation Guide is wrong and KB 66530 is right. DOS had been extended (by IBM) to not require IO.SYS and MSDOS.SYS to be contiguous. As mentioned above, only the first few sectors of IO.SYS need to be contiguous. The change made it much easier to upgrade existing boot disks created by older DOS versions. Since DOS versions prior to 3.3 required IO.SYS/IBMBIO.COM to be contiguous, there was always enough room on the disk for the contiguous part of the DOS BIOS component. However, if the 3.3 version was larger, that did not matter and the file could be fragmented.

Interestingly, although IO.SYS could be fragmented by SYS.COM, the MS-DOS 3.30 boot sector always tried to load the entire file as though it had been contiguous. The difference from MS-DOS 3.21 was only that the boot sector no longer tried to read more sectors than necessary to load IO.SYS.

Boot changes between DOS 3.21 and 3.30

Examining the two OAKs, it is obvious that the 3.30 Adaptation Guide wasn’t properly updated and did not reflect the true state of affairs. But since the OAK delivered the full source code for IO.SYS as well as for the boot sector, it’s easy to analyze the boot code in detail.

In DOS 3.2 (and earlier versions), IO.SYS had to be strictly contiguous and was fully loaded by the boot sector. Life was simple, just prone to hangs if a disk with many sectors per track entered the picture, against all odds.

In DOS 3.3, a new stage was inserted into the boot process as part of IO.SYS. It was called “Non-Contiguous BIOS Loader” or MSLOAD. It was stored at the beginning of IO.SYS, but was not truly part of it.

When MSLOAD was executed (getting control directly from the boot sector), it loaded the disk’s FAT and determined how many clusters in IO.SYS were contiguous. If all of IO.SYS was contiguous, MSLOAD only needed to relocate the already loaded IO.SYS; that is, move the “old” IO.SYS down to where MSLOAD had been loaded by the boot sector.

If IO.SYS wasn’t contiguous, MSLOAD could safely assume that the boot sector had already loaded the entire first contiguous chunk of the file. MSLOAD then had to traverse the FAT and load the remaining clusters.

The downside of MSLOAD was that in the best case, the FAT had to be loaded (and then discarded) only to find out that IO.SYS is contiguous and there’s nothing to do. In the worst case, IO.SYS was fragmented and the boot sector had ended up loading perhaps up to about 20KB of useless data. MSLOAD then had to read the remainder of IO.SYS cluster by cluster.

The upside of MSLOAD was that SYS.COM could upgrade almost any existing boot disk to DOS 3.3, even if the original IO.SYS was much smaller than the DOS 3.3 version.

Back to the original problem…

It should be apparent that the addition of MSLOAD did not directly impact the problem with the boot sector hangs. The issue with many sectors per track was isolated to the boot sector.

For one reason or another, the boot sector in PC DOS 3.30 released in April 1987 was fixed. The boot sector in the MS-DOS 3.21 OAK from May 1987 was not. The boot sector in the MS-DOS 3.30 OAK from July 1987 was fixed.

The only clue to the problem is a comment in MSBOOT.ASM in the 3.30 OAK: “The COUNT value has a bogus check to determine if we’ve loaded in all the sectors of IO.SYS. This will cause too big of a load if the sectors per track is high enough, causing either a stack overflow or the boot code to be overwritten.”

The comment indicates that it applies to revision 3.31 and its author was MarkT; it’s unclear who that was. It’s also unclear why there was revision 3.31 in a DOS 3.30 OAK, but the revisions in source files did not always match the DOS version. And it’s unclear whether the boot sector change was related to the MSLOAD addition or not.

However, it is clear that sometime in early 1987 or more likely in 1986, someone did notice the problem with disks with lots of sectors per track and it was fixed for DOS 3.3. It’s unfortunate (sloppy?) that the fix was not included in the MS-DOS 3.21 OAK, even though the OAK was released at least a month later than PC DOS 3.30.