Learn Something Old Every Day, Part XVI: DOS 4.0 SELECT Is Too Clever

A while ago I discovered an antique pirated copy of IBM DOS 4.00 on 5.25″ media, which was something that was missing in my archive. And by antique I mean from August 1988, when DOS 4.0 was practically brand new.

There were SNATCH-IT disk images in files DOS400-1.ARC to DOS400-5.ARC (DOS400-6.ARC includes the disk from the IBM DOS 4.0 Technical Reference, not part of the OS per se). There were two problems. At first, I didn’t know what to do with SNATCH-IT images at all, and also the image of the install disk (DS40INST.CP2) was corrupted, with ARC reporting a CRC error.

Once I sorted out SNATCH-IT image decoding, I was left with the corrupted disk. The corrupted image was 60 bytes longer than it should have been, but it was actually mostly OK. A “feature” of old compressors like ARC is that they work with blocks of several kilobytes in size, and if one is lucky, one block will be corrupted but the rest won’t.

I set out to determine where exactly the SNATCH-IT image was corrupted. Armed with the knowledge of the format, I found the corruption was in one of the data blocks (large chunks, a few dozen kilobytes in size, that hold bare sector data) and not in any of the control structures. So far so good; since I have images of 720K disks of IBM DOS 4.00, I would likely have good files to recover from the damage.

Then I tried to cut out the extra 60 bytes while causing minimal damage. That was tricky because the sector data was stored interleaved in the SNATCH-IT image. In the end I localized the damage and created a semi-fixed DS40INST.CP2 which I could convert to a raw image.

In the converted image, there were two corrupted files, DISKCOPY.COM and DISPLAY.SYS. Interestingly thanks to interleaving, the last cluster/sector of DISKCOPY.COM was intact. I replaced the files in the image with copies from the 3.5″ variant of IBM DOS 4.00, but as it happens these two files were identical even in IBM DOS 4.01 anyway.

Now I had what should be a good set of disk images, with some questions as to its provenance. The images were clearly made from IBM DOS 4.00 disks (otherwise why bother with SNATCH-IT), but were those disks unmodified originals? There were no obvious signs of tampering and all timestamps were what they should have been.

Yet there were at least two oddities. The OPERATING 1 disk did not contain a hidden zero-length file called DOS01I.400, and there were no hidden zero-length files such as VENDOR-#.TO1 that are present on 5.25″ disk images of IBM DOS 4.01.

I never quite figured out the story with the VENDOR-#.xxx files and they are clearly not required. The DOS01I.400 file is clearly not required either, as it later turned out, and it may be a genuine omission. All images have “IBM 4.0” OEM string in the boot sector, which suggests they are genuine, as such disks were anything but common in August 1988.

Back to that slack space at the end of DISKCOPY.COM. It contains a curious fragment of text:

     0AB1008 \\SPIDERMAN\DRIVEA (A)
000030AB1008 \\SPIDERMAN\DRIVEA (A)
06/14/1988 08:10:43.30 RAMBO  000030AB1008 \\SPIDERMAN\720KB (720)
06/14/1988 08:11:30.54 RAMBO  000030AB1008 \\SPIDERMAN\DRIVEA (A)
06/14/1988 09:32:38.97 RAMBO  000030AB1008 \\SPIDERMAN\720KB (720)
06/14/1988 09: 

The \\SPIDERMAN\DRIVEA string looks like the name of a network share. What’s more, the timestamps (June 14th, 1988) happen to be the same as the timestamps on the actual disk, which is something that might very conceivably happen if the IBM DOS 4.00 disks were in fact mastered on June 14th, 1988. The thought that someone planted this fragment in a disk image of commodity software nearly 40 years ago seems not just extremely improbable, but outright lunatic.

Installing

Okay, so let’s install the thing. Starting the installer in a VM was no problem, but after rebooting and continuing after FDISK, the installer would just lock up every single time.

Maybe I restored the installation disk incorrectly? Maybe it was more damaged than I had thought? Well… I tried the 5.25″ install disks of IBM DOS 4.01 and they had the exact same problem!

I tried various things, re-running parts of the installer manually… and eventually a light bulb went off. The installer was asking me for the OPERATING floppy, not OPERATING 1. The 5.25″ 360K disk set has three OPERATING 1/2/3 disks, whereas the 3.5″ 720K disk set only has one OPERATING floppy. Does the installer think I’m using the 3.5″ disk set?

Thanks to Microsoft we have the source code for SELECT, the DOS 4.0 installer… and sure enough, it determines the installation media type from the drive type!

In other words, the SELECT installation files are essentially identical between the 5.25″ and 3.5″ disk sets. SELECT determines the kind of disk set it’s working with based on the drive type. The installation disks were double density only, so there was no worry about DD versus HD floppies. That logic is not crazy, because physical 5.25″ disks cannot possibly be used in a 3.5″ drive and vice versa… but virtual disks can.

Using 360K disk images in a virtual 1.44M 3.5″ drive works just fine most of the time. But clearly SELECT is one of the exceptions. Again, it is hard to call this a bug in SELECT, because users would have had to work extra hard to reproduce the same scenario on physical hardware.

Once I adjusted the VM to use a 5.25″ 1.2M drive, sure enough, the installation worked fine, and I ended up booting into the DOS Shell:

Then I realized there’s yet another non-obvious thing that SELECT does. I thought the installer would ask me to insert a blank disk to create a writable “SELECT COPY” disk which is a modified copy of the installation disk. But it never did, and just modified the installation disk.

This was what I expected to see, but never did:

Then I realized that SELECT is kind of clever. It tries updating the installation disk (it needs to modify AUTOEXEC.BAT and write a few temporary files) and if that works, it just does that. Only if it finds that the installation disk is write protected, it asks the user for another disk to write to.

I can imagine that this would have made testing the DOS 4.0 installation less of a hassle, because skipping the SELECT COPY disk creation avoids a bunch of disk swaps. But it is an unexpected (if logical) difference in behavior depending on whether the installation disk is writable or not. As they say, learn something new old every day…