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.
Another variation of that is smuggling the version number inside the timestamp, like Windows 3.1 files being dated 03-10-1992 or the time on MS-DOS 6.22 files being 06:22.
This also reminds me of your prior post on junk data in files: https://www.os2museum.com/wp/unidentified-pc-dos-1-1-boot-sector-junk-identified/
Yes, I think setting the timestamp to indicate a version number was an old tactic. I don’t know who started it but Quarterdeck’s QEMM used it at least since 1988 (QEMM 4.10).
You can recreate floppy disks from the images on the CD. This would completely rewrite all sectors.
I think my first CDs with OS/2 were 2.1. I was part of the OS/2 2.0 beta program and a longtime member of DevCon. We received approx. 100 floppy disks for each beta release, but no CDs (with LAN, C Compiler, printer and video drivers and whatnot).
Yes… mostly. In this case, I don’t think I have matching images on CD-ROM. That is, some Developer Connection releases did come with TCP/IP 2.0, but it was in the form of ZIP files installable directly from the CD-ROM, not floppy images.
In general, floppy images may not contain all sectors/tracks. It was a common optimization that diskette imaging programs used primarily with FAT-based disks analyzed the FAT and didn’t even bother reading unused cylinders at the end of the disk. When such an image is used, the contents of the not-imaged tracks is truly indeterminate–the original may have been filled with zeros, with the F6h pattern, or with literally anything else. Imaging utilities often did not write the unused tracks when restoring, either.
I have seen the old IBM beta drops and yes, in the 2.0 days it was a LOT. The base OS, compiler, Toolkit, LAN Server, Extended Services, it was dozens of disks. Plus reams of printed documentation. Or one neat little CD-ROM.
“It was a common optimization that diskette imaging programs … didn’t even bother reading unused cylinders at the end of the disk. … the contents of the not-imaged tracks is truly indeterminate–the original may have been filled with zeros, with the F6h pattern, or with literally anything else.
When opening *.DSK images under Win7, you can get failures by WinImage and probably 7zip as well. The *.DSK must use /D /A switches, if so, any *.DSK will happily open. Was a cause of much annoyance until we read the readme files…
LOADDSKF and SAVEDSKF utilities
Note: For later Windows systems to be able to consistently access the *.DSK, you MUST use the /D /A switches. /D omits the 1 sector leader and inhibits data compression. /A saves all sectors of the disk. Example:
SAVEDSKF a: C:temprefdisk.dsk /D /A
“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)”
What’s your point here? We are talking about file MODIFIED timestamp. That timestamp doesn’t change when you copy files to floppy. So no need to write all the files in two second. You can freely copy files all day long if you like and you still have all the same timestamps. Your argument is not correct.
For IBM employees, the betas tended to be disk images grabbed from the PCTOOLS minidisk or whatever and then written to whatever diskettes you could find with LOADDSKF. It would be a lot of diskettes, and you’d tend to reuse them over and over. I suspect some of the disk images we have now originally came from a pile of reused diskettes on somebody’s desk.
But what do you initially write the files to, on a machine that has no hard disk?
@fraft: The point is, let’s say that you are preparing the release of this version of DOS, you assemble/compile all your programs and copy your already edited README, etc. All this files will have different times, then let’s say that you use a program to copy all this files to a floppy that writes the modification date when the file is copied. With a floppy drive of this era, of this computer, it’s impossible to write all the files within 2 seconds, so you will have files with some amount of difference in the modification time. If all the files have the same modification time it is because the modification date was manually altered. If you know UNIX/Linux like using the “touch” command.
I think fraft’s point was that on DOS, the COPY command keeps the timestamp (unlike on *nix). Which is true, but as you point out, that doesn’t change the fact that getting the files to have the same timestamps could not naturally happen.
It’s actually quite likely that the files were not built on DOS but rather on some minicomputer and perhaps transferred to DOS using a serial link. In which case… same problem.
We all agree that the timestamps were artificially modified after the fact and do not reflect the true creation or modification times.
The timestamps could be correct. High speed CPU bit banging requires turning off interrupts. Turning off interrupts prevents the clock from advancing. The entire transfer may happen with the same time being recorded.
No hard disk? In the really old days, IBM employees had a utility that would directly write to a diskette from a 3270 link using some kind of protocol to download files. But I think that was short lived – people tended to get PC/XTs (1982) or the PC 3270 (1983) and it just made more sense to download the files to the fixed disk first and then write them to a diskette.
A good question is when people started using LOADDSKF. As I recall, these were on the PCTOOLS minidisk, but sadly I can confirm that that ceased to exist a while ago. It’s really too bad businesses like IBM don’t archive things like that (I will give Microsoft credit for going to some effort to archive things like early MS-DOS.)
The LOADDSKF copyright message says 1989-1993 (in the version I happen to have on hand) so probably around ’89. I don’t think floppy images were common before 1990, although the concept did exist at least since 1986 or so.
Also Microsoft does deserve credit for opening up old source code, but not so much for archiving. As far as I know, all the released DOS source code came from outside of Microsoft, and they “only” gave a permission to release it.
In the WinWorldPC collection files of Turbo Pascal 3.01A (there are few different images) from 1985 all have random creation time and date, while Turbo Pascal 3.02 from 1986 uses 1986-09-17 03:02:00 for all files. Just a data point.
Re disk images: I would think that what made the concept more relevant would be improved modem speeds. I.E. whenever it started to be reasonable to transfer a disk image using a modem it would “open up a market” for disk images.
Also back in the days hard disks were so expensive and tape backup devices so rare that few if any would say for example archive floppy images on tape as a savings measure. The cheapest way to store a floppy image would likely had been to just write it to a floppy. Sure, a compressed image could be written as a file to a floppy and you’d have space for something else too, but still.
To be slightly pedantic, the earliest floppy disk imaging software I can think of was Diskotape by Dann McCreary for the Apple II. That shows with a date of 1980. As the name implies, the disk image was stored on a cassette.
Disk images didn’t make all that much sense until the specialized boot disks were needed by frequently updated OS betas.
That’s interesting. It’s clear that on early PCs, disk images made very little sense because there was nowhere to store them. Hard disks changed that.
SNATCH-IT is one of the earliest PC floppy imaging programs I know of, circa 1985.
By the time harddisks were common equipment so were high density floppies. Disk images still did make sense for most folks because how many were you going to keep around? Chewing up 1.2MB of your 20MB or even 40MB harddisk did not make a lot of sense. Outside of a few special cases like software development shots, not many good arguments for archiving cheap removable storage on expensive online storage.