LAN Manager 2.1/2.2 Registration

Posted on December 1, 2021 by Michal Necasek

Anyone who spent a bit of time archiving software distributed on floppies probably knows this situation: There’s only one disk set of a given software release known to exist, and it’s not clean. That is, it’s been previously used to install the software and the installer scribbled something on the floppies, like the user’s name or a serial number.

Installing a clean copy of LAN Manager 2.2

Restoring the disks to a virgin state is desirable, but that’s easier said than done. There are easy cases like the OS/2 installation boot floppy: The installer creates a file named INSTALL.LOG and writes a couple of things to it, but does not modify any existing files. Such behavior is relatively harmless because the additional file can be simply ignored, or all traces of it can be thoroughly erased.

LAN Manager 2.1 and 2.2 is in a different category. The setup program “burns in” the user name, modifying a file on one of the installation disks. That is far more difficult to undo because an existing file’s timestamp is changed and the contents modified. Restoring original content is rather difficult because it’s not at all obvious what it had originally been. Although having just one “clean” set of LAN Manager disks helps.

Continue reading →
Posted in Archiving, Debugging, Microsoft, Software Hacks | 18 Comments

The Secret History of ATAPI

Posted on November 24, 2021 by Michal Necasek

The other day I asked myself a seemingly trivial question: What was the first ATAPI CD-ROM drive and when was it available? Given that ATAPI was a major technology which instantly obsoleted all proprietary CD-ROM interfaces and made SCSI much less desirable, one might expect that there would have been some press releases touting the advantages of the new technology, articles describing the whys and wherefores, but… nope. There is nothing.

A rather old IDE CD-ROM drive with curious jumper settings

In 1993, CD-ROM drives used either SCSI or one of several proprietary interfaces, the major amongst those being Matsushita/Panasonic, Mitsumi, Philips, and Sony. In 1995, the proprietary interfaces were effectively gone and most new CD-ROM drives used the ATAPI interface. Something clearly happened in 1994, but exactly what, when, and how—that’s something of a mystery.

Continue reading →
Posted in CD-ROM, PC history, Standards, Undocumented | 60 Comments

Looking for High Sierra

Posted on October 29, 2021 by Michal Necasek

Some time ago, I thought it would be useful to understand exactly what is the difference between CD-ROMs recorded in the old High Sierra format versus the ISO 9660 standard. This was in part spurred by the fact that I have a number of CD-ROMs/images that use the High Sierra format (Microsoft Programmer’s Library, some IBM Developer Connection issues, OS/2 Warp 4, and more) that both macOS and Windows 10 refuse to mount. The other part of my motivation was the usual insatiable curiosity.

Finding the actual text of the High Sierra Working Paper (also High Sierra Proposal, i.e. proposed standard) turned out to be rather unexpectedly difficult. I found a number of articles talking about the High Sierra Proposal (HSP) but not the actual HSP text.

The closest thing I could find was an article in the excellent PC Tech Journal in the July 1987 issue (Patterning CD-ROM by Peter Jansson, page 163). Said article recaps the HSP in very good detail but it’s not the actual text. But even that was enough to show that although the structure defined in the High Sierra format is not far from the ISO 9660 standard, the two data structures are just different enough to be mutually incompatible.

Continue reading →
Posted in CD-ROM, Documentation, PC history | 23 Comments

Deeper Into ATA History

Posted on October 14, 2021 by Michal Necasek

While looking for something completely unrelated (namely the Rock Ridge extensions to ISO 9660), I came across a cache of old X3T9 committee documents from 1990. In retrospect I’m a little surprised that I hadn’t found these earlier, since the archive appears to have been published on one of Walnut Creek CD-ROMs circa 1994, but I’m not sure how long it’s been online.

What’s interesting is that the Walnut Creek archive appears to overlap with the X3T9.2 archive that has available for a long time, but contains numerous documents that the X3T9.2 archive does not. Notably there’s a directory with CAM Committee documents. While the CAM Committee’s primary objective was to define a Common Access Method (CAM) for software accessing SCSI devices, an effort that ultimately went nowhere, the CAM Committee also started a rather more successful side project, the AT Attachment (ATA) standard.

The archive is far from complete, but it does include one complete ATA draft, revision 2.1 from June 11, 1990. That’s one revision older than the oldest ATA draft I was aware of until now, which is revision 2.2 from August 1990. The rev 2.1 draft is provided as a ZIP archive containing WordStar files, which is excellent for seeing exactly how the draft was edited (and the WordStar files include a couple of editorial comments that do not show up in the printed version), but the downside is that getting from WordStar to PDF was not entirely trivial. In the end I was able to produce a PDF of ATA Rev 2.1 in 2-up format that’s quite similar to the scanned documents in the X3T9.2 archive.

Even better, the Walnut Creek archive includes what appears to be the very first and quite incomplete ATA standard draft from March 30, 1989. Said draft also provides a hint why a SCSI oriented committee started ATA in the first place: The early ATA drafts also included a specification of EATA (Extended AT Attachment), a SCSI pass through mode of ATA devices (completely separate from and much older than ATAPI).

Sadly the initial draft—which is so old that it’s called DAD, for Disk ATBus Definition, rather than ATA—does not include the EATA sections. In the next oldest currently available draft (revision 2.1), EATA had been already removed again. ATA revisions 1.x appear to have included the SCSI pass through functionality defined by EATA.

EATA was the brainchild of DPT (Distributed Processing Technology), one of the larger SCSI HBA vendors. An overview of EATA can be found here. I don’t believe anyone besides DPT implemented EATA, but the idea behind it was quite interesting.

CHM’s oral history of Dal Allan describes how EATA was created by DPT and desired by Quantum, but WD successfully fought to remove it from the standard for cost reasons, only to implement the same idea (SCSI pass through over ATA) as ATAPI a couple of years later.

The first ATA draft from March 1989 notably already defines the IDENTIFY DRIVE command as well as READ/WRITE MULTIPLE, but there is no sign of DMA support yet. The DASP signal for letting drive 0 detect drive 1 was also already defined, although the details were refined many times since then.

Finding the very first ATA draft is something I doubted would ever happen. Now I wonder if the revision 1.x ATA drafts might eventually turn up, too.

The list of early ATA drafts on this site has now been appropriately updated.

Posted in IDE, PC history, Standards | 17 Comments

Weird Tales

Posted on October 1, 2021 by Michal Necasek

While researching various aspects of the history of computing, sometimes I come across what can best be described as “weird tales” — unsourced claims that sound interesting but are either provably wrong or there’s no evidence to support them. In the 1980s and 1990s, Bill Gates was a frequent purveyor of such weird tales, often designed to burnish the image of Microsoft.

Listening to Bill Gates, one might for example get the impression that he personally designed the IBM PC, even though Microsoft’s involvement with the actual hardware design was at best peripheral. At the same time, there’s often enough some kernel of truth in the implausible stories.

Some time ago, one of such weird tales caught my attention, the story of Microsoft putting the Wang word processing character set into the IBM PC. Here’s one version of the story:

They told us for this keyboard, they said Lexington had to use a certain layout. We wanted these function keys to be up here, that the Lexington layout forced them to be over here. We ended up with this funny big key over here because of Lexington. But here we’d put in our favorite fully-extended character set. Came up with some new ideas there. Put some special things in here that we thought we’d be able to use. In fact, we put in the Wang word processing character set because we weren’t sure whether to do a Wang-clone word processor, or start with our own approach at that time.

Bill Gates, Smithsonian Video History Interview

There is another variant of the story, similar but not the same:

Yeah, we were also fascinated by dedicated word processors from Wang, because we believed that general-purpose machines could do that just as well. That’s why, when it came time to design the keyboard for the IBM PC, we put the funny Wang character set into the machine–you know, smiley faces and boxes and triangles and stuff. We were thinking we’d like to do a clone of Wang word-processing software someday. Most personal computers back then didn’t even have upper- and lower-case characters.

Bill Gates, Fortune Magazine interview, October 2, 1995

First a side note about “Lexington”. No one appears to know of an IBM keyboard codenamed “Lexington”. On the other hand, it is well known that the original IBM PC keyboard layout came straight from System/23 Datamaster. It is also well known that IBM’s keyboards were manufactured in Lexington, Kentucky at the time (later Lexmark). Bill Gates most likely mixed things up, perhaps due to incomplete information he had.

Continue reading →
Posted in IBM, Microsoft, PC history, PC press | 22 Comments

DOS 2.11 From Scratch

Posted on September 21, 2021 by Michal Necasek

Warning: Long post!

After having good luck with rebuilding core PC DOS 1.1 from source code, I thought I’d do the same with the DOS 2.11 source code released by the CHM. What follows is largely a collection of notes that I wrote down while banging the released source code into shape. That turned out to be a lot harder than building DOS 1.1 for two reasons.

One is that the released DOS 2.11 source code is a lot more extensive and includes source code for numerous utilities (CHKDSK, DEBUG, EDLIN, SYS, etc.). The other, bigger reason is that the CHM unfortunately created a bit of a mess when releasing the code and sorting out the pieces was not trivial.

Microsoft style DOS 2.11 boot

The CHM placed all DOS 2.x related files in just two directories, ‘v20object’ and ‘v20source’. It is now clear that the files came from at least three distinct sources:

  • MS-DOS 2.00 OEM distribution disks
  • MS-DOS 2.11 source code of unknown provenance
  • Miscellaneous debris such as WordStar 3.20 overlay files

Fortunately for me, Jeff Parsons has done a lot of legwork reconstructing the DOS 2.0 OEM distribution disks. These disks were clearly an early version of what Microsoft later called OAK (OEM Adaptation Kit). The disks contain generic DOS 2.0 binaries, with the notable exception of IO.SYS which had to be supplied by the OEM. There is example “skeletal” IO.SYS source, together with source for PRINT.COM that OEMs might modify, and example OEM source module for FORMAT.COM which OEMs had to write.

Continue reading →
Posted in Development, DOS, Microsoft, PC history | 42 Comments

PC DOS 1.1 From Scratch

Posted on September 10, 2021 by Michal Necasek

A number of years ago, the Computer History Museum together with Microsoft released the source code for MS-DOS 1.25 (very close to PC DOS 1.1) and MS-DOS 2.11. I never did anything with it beyond glancing at the code, in no small part because the release was rather poorly organized.

PC DOS 1.1 rebuilding itself

Now I finally decided to look at the code for DOS 1.1 and see how far I could get with it. For both DOS 1.1 and 2.0, there are ‘object’ and ‘source’ directories. The ‘object’ directory for DOS 1.1 simply contains a copy of PC DOS 1.1, which is not particularly revealing or useful on its own (and strictly speaking I’m not even sure why the CHM thought it could publish those files).

The ‘source’ directory is much more interesting and contains the following files:

05/09/1983 09:59 AM   63,781 ASM.ASM
05/17/1983 06:19 PM   67,064 COMMAND.ASM
07/02/1982 11:33 AM    3,625 HEX2BIN.ASM
08/03/1982 12:29 AM   36,882 IO.ASM
05/17/1983 06:15 PM  114,253 MSDOS.ASM
05/17/1983 06:20 PM      649 STDDOS.ASM
07/01/1982 11:54 PM   16,223 TRANS.ASM

This turns out to be an interesting mix, and an included 2013 e-mail from Tim Paterson explains its origin: Those files are the source code for what SCP (Seattle Computer Products) shipped to its customers. ASM, HEX2BIN, and TRANS were SCP’s development tools used for initial DOS development. MSDOS.ASM and COMMAND.ASM are source code for core DOS components. IO.ASM is source code for SCP’s IO.SYS (i.e. IBMBIO.COM equivalent).

Continue reading →
Posted in Development, DOS, Microsoft, PC history | 24 Comments

Learn Something Old Every Day, Part III

Posted on September 8, 2021 by Michal Necasek

As part of a hobby project, I set out to reconstruct assembly source code that should be built with an old version of MASM and exactly match an existing old binary. In the process I learned how old MASM versions worked, and why programmers hated MASM. Note that “old versions” in this context means MASM 5.x and older, i.e. older than MASM 6.0.

The way old MASM works is relatively straightforward but its documentation often explains it very poorly or not at all. MASM is a two-pass assembler, and that indirectly explains almost everything about its quirks. This is different from more modern N-pass assemblers which automatically run multiple passes to resolve ambiguities.

The core of the problem is that MASM tries to be clever, but it’s not nearly clever enough. It is very questionable whether MASM’s cleverness is a solution or a problem; other assemblers are stricter, relying on programmers to resolve ambiguities. This perhaps puts slightly more of a burden on the programmer but results in more readable, consistent source code.

Most ambiguities result from the fact that like most assemblers, MASM does not require symbols to be declared before they’re referenced. In the first pass, MASM generates “provisional” code, making guesses about what unknown symbols are. At the end of the first pass, all symbols are known (if they’re not, the assembly will fail).

In the second pass, MASM applies what it learned in the first pass and generates the final object code. If the guesses made in the first pass turn out to be incompatible with the second pass, MASM will report the dreaded “phase error”. More about that later.

Continue reading →
Posted in Assembler, Development, Microsoft, PC history | 11 Comments

PC-86-DOS

Posted on September 3, 2021 by Michal Necasek

A number of years ago, an 8″ disk containing Seattle Computer Products (SCP) 86-DOS 1.0 was successfully imaged. The newest files on the disk are dated April 30, 1981, making the disk the oldest complete release of what was soon to be known as PC DOS and MS-DOS, about a month older than a pre-release of PC DOS from early June 1981.

While it is possible to run the 8″ disk image with 86-DOS version 1.00 under an emulator, it of course doesn’t run on a PC or any PC emulator/virtualizer. That’s a shame because most of the utilities included with SCP’s 86-DOS run under DOS just fine. In theory, it should be possible to provide a PC compatible “BIOS” component (IBMBIO.COM or IO.SYS equivalent) and run the rest of the system more or less unmodified on a PC.

In practice, it can in fact be done. Behold PC-86-DOS 1.00, running from this disk image:

SCP’s 86-DOS 1.00 on a PC

Actually achieving this wasn’t complicated but there was one non-trivial snag.

Continue reading →
Posted in Development, DOS, IBM, PC history | 18 Comments

The Dual-Drive IDE Hell

Posted on August 25, 2021 by Michal Necasek

I have perhaps inaccurate but very strong memories from my PC-building days (in the early to mid-1990s) that one of the most failure-prone and frustrating endeavors was trying to get two IDE drives working together on a single cable as a master/slave pair, or as Device 0/1 in the language of the ATA Standard.

It’s not that it was fundamentally impossible… but it was insanely random and unpredictable. No one could tell in advance whether any given pair of IDE drives would work. Mixing drive vendors seemed to increase the likelihood of failure, but using two drives from the same vendor was by no means a guarantee of success.

Various jumpers used for configuring IDE hard disks

There were two major reasons for why this was the case:

  • The whole thing started out as a giant hack, pretending that two separate IDE drives are really two drives attached to a single AT style controller.
  • The vast majority of IDE users only ever had one drive, thus not putting enough pressure on IDE vendors to get their act together.

Eventually, by the late 1990s, things did work reasonably well. The key ingredient was cable select and (barely) special cables which allowed all drives to be configured identically and work as either master or slave depending on their cable position. This was not exactly a revolutionary concept; PC floppy drives and ST506 interface hard disks used the same idea, using a twist in the cable, since the early 1980s.

Continue reading →
Posted in IDE, PC hardware, PC history | 20 Comments