Messy Mastering

Large companies like IBM, Microsoft, or Novell typically had a well defined process for releasing software on floppies. More often than not, files were not directly copied onto a physical floppy; instead, a tool was used to create an image of a floppy disk from distribution files, and the image was then sent off for mass duplication.

Quite often, timestamps of files were set to a predefined value when creating the image. That practice is probably as old as timestamps in the FAT file system. PC DOS 1.0 kept track of the date when a file was modified, but not the time of day. PC DOS 1.0 has all non-system files set to a 08/04/1981 date, although it is theoretically possible that this was a result of normal file manipulation.

With PC DOS 1.1, there is no ambiguity. The timestamps of all files are set to 12:00:00 on 05/07/1982. Floppy disks are not nearly fast enough to write all those files within two seconds (the FAT timestamp resolution), even in the extremely unlikely case that someone sat there waiting until exactly noon to start the operation. It is a given that IBM artificially set the timestamps of all files to match, and that was before the PC was even a year old.

It is notable that Novell followed a different strategy and strictly kept the original timestamps of shipping files. It was common that different releases had some files with matching timestamps and some files different. One could be reasonably confident that two files with the same name and timestamp were in fact identical. That was not always the case with IBM or Microsoft, where two files with different timestamps were often identical. And in rare cases, two different versions of a file were distributed with the same timestamp, arguably completely defeating the purpose of timestamps.

Especially when software was released with artificially created timestamps, this helps identify modifications to the release disks. If one has, say, an IBM DOS 4.0 install disk where files are dated 06/17/1988, but the timestamp of AUTOEXEC.BAT or CONFIG.SYS is different, it’s more or less certain that someone modified those files. Such modifications may otherwise be impossible to clearly identify if one only has a floppy image to work with, because editing an existing text file may not result in any changes to the FAT and a disk sector will simply be rewritten in place.

IBM TCP/IP 2.0 for OS/2

The other day I was looking at a disk set (that is, a set of floppy images) of IBM TCP/IP 2.0 for OS/2 Base Kit. I was almost sure that I had imaged original disks about twenty years ago, but there were several red flags that usually signal non-original disks.

Here’s a listing of the B1 floppy (the installation disk):

Directory'\*':
   731921 ---a 01/06/1994 10:17:12 BASE1.ZIP
        0  DIR 01/06/1994 15:23:22 LANLK
    43151 ---a 01/03/1994 15:45:22 BASECSD.DOC
    56528 ---a 12/07/1993 13:20:12 BASEXT.EXE
     1999 ---a 01/06/1994 11:27:06 DEFAULT.RSP
      422 ---a 03/19/1993 16:49:00 LAPSRSP.RSP
     5436 ---a 08/12/1993 20:29:14 README
   111242 ---a 12/04/1993 11:29:08 TCPINST.EXE
    12663 ---a 06/17/1993 18:44:32 TCPINST.HLP
   114303 ---a 01/05/1994 08:42:56 TCPINST2.EXE
    92080 ---a 11/03/1993 09:08:46 UNZIP.DLL
        0  DIR 10/28/1993 14:10:24 TK
        0  DIR 10/28/1993 14:10:28 HDCONTL
Directory '\LANLK\*':
    15580 ---a 07/26/1993 16:18:46 IBMLANLK.EXE
     4420 ---a 07/26/1993 16:18:46 IBMLANLK.SYS
     4548 ---a 07/26/1993 16:18:50 LSI.MSG
     5579 ---a 07/26/1993 16:18:50 LSIH.MSG
Directory '\TK\*':
        0  DIR 10/28/1993 14:10:24 SAMPLES
     2847 ---a 07/21/1993 12:11:38 CONTROL.SCR
Directory '\TK\SAMPLES\*':
        0  DIR 10/28/1993 14:10:24 VIDINST
        0  DIR 10/28/1993 14:10:24 CODEC
        0  DIR 10/28/1993 14:10:26 VCADDT
Directory '\TK\SAMPLES\VIDINST\*':
     3017 ---a 08/03/1993 10:05:26 MAKEFILE
     2202 ---a 07/21/1993 12:11:36 README
Directory '\TK\SAMPLES\CODEC\*':
     2743 ---a 09/22/1993 09:54:20 README
     2691 ---a 08/03/1993 10:05:22 MAKEFILE
      553 ---a 09/22/1993 09:54:20 CONTROL.SCR
Directory '\TK\SAMPLES\VCADDT\*':
     2310 ---a 08/10/1993 10:17:56 README
Directory '\HDCONTL\*':
    10456 ---a 10/28/1993 13:06:58 MASTERH3.RTP
     4634 ---a 10/28/1993 13:06:56 CONTROLH.SCR

While the LANLK directory is presumably part of the installer, the TK and HDCONTL directories are definitely not. They are in fact fragments of the OS/2 2.1 Multimedia Toolkit. Completely unrelated to TCP/IP. So… that’s suspicious.

The README file is several months older than the rest, which is unusual; usually the README includes late-breaking information and ends up being one of the most recent files on an installation disk.

And there’s more. The OEM identifier in the boot sector of disk B1 from the kit is “IBM 20.0”, which is normal for OS/2 2.x disks. The OEM identifier on disk B2 is “DOS4.0” which is much less common for OS/2 software. Disk B3 has OEM identifier “IBM 3.3”. Disks B4 and B5 have “IBM 20.0” and disk B6 has “IBM 3.3” again. To top it off, the OEM identifier on the IBM Library Reader disk (also part of the Base Kit) is “IBM 10.2”, indicating OS/2 1.2.

In other words, the disks are a complete mess. They were clearly not created through any kind of a controlled process. It looks like someone just took whatever random disks they had lying around, deleted the existing files, and copied over the new ones.

That is also clearly visible in the root directories of the disks, which contain some (or many) deleted files.

There’s also the small matter that IBM released TCP/IP 2.0 for OS/2 in mid-1993, and these disks clearly contain updated files from early 1994, even though the packaging does not indicate an updated version.

All this made me quite unsure that I was looking at images of original disks. So I had to find the old box of floppies and then ran them through my Kryoflux. Lo and behold… the images were really made from true blue IBM disks. The Kryoflux tools can identify rewritten disk sectors but no, the disks were all clean mass-duplicated specimens.

Whoever mastered these disks was either in a real hurry or didn’t have the right tools, and really just took a box of random floppies, deleted existing files, and copied the (updated) TCP/IP 2.0 Base Kit files onto the disks. And so we ended up with distribution disks that look really fishy, but are in fact completely intact originals.

Thanks to the Kryoflux, I can also exclude the possibility that someone modified the original disks after the fact—which was always unlikely, but not completely impossible. No, there was no modification, the disk images really reflect exactly how IBM shipped the disks from the factory… primed to confuse digital archivists decades later.