How A DOS Format Blunder Revealed Some Priceless Source Code

As those of us who worked in the consumer software world back when physical media was king can attest, when a master disc has been sent for duplication and distribution there is no turning back from whatever code is in the hands of thousands of users. Usually such worries were confined to bugs or inadvertently sending out pre-release software versions, but [Lance Ewing] is here with the story of how Sierra On-Line once inadvertently released most of the source code for their game engine.

If you have some 720k floppy disk versions of the 1988 game Space Quest II, the first disk in the set appears to have nothing out of the ordinary, but a closer look reveals that the free space on the disk reported by DOS is greater than its used space. Diving in to the disk block contents with a hex editor reveals that many of the unused blocks in fact contain C code, and some further detective work allows the recovery of a not-quite complete set of source files for the company’s AGI, or adventure game interpreter. They had been left behind when the original master disk had been emptied by deleting them, rather than by formatting it afresh.

In commercial terms this would in 1988 have been something of a disaster for Sierra had it been discovered at the time, because it was the cornerstone of their success. As it was we’re told the code sat peacefully undetected until 2016, since when it has proved invaluable to those interested in computer game archaeology. Or did it? We’ll never know if a sharp-eyed competitor snagged it, and kept quiet.

Of course, these days, there are game engines that are open source. Some of them are very modern. Others… not so much.

14 thoughts on “How A DOS Format Blunder Revealed Some Priceless Source Code

  1. We used to buy boxes of “blank” 3.5″ floppies from a company called Chicken Shit Software, they were dirt cheap because they were overstock from a duplication house and Chicken Shit’s labels were stuck ove the originals.

    We got some real nice software off those disks because they’d been quick formatted and hadn’t been bulk erased.

    1. This was a pretty common practice, there were a number of disk copy programs built to explicitly handle some of the tricks that the manufacturers were using.
      Some of the earliest copy protection routines would just fill all of RAM up so you couldn’t add a copy program

  2. At least Sierra Online left behind a game engine. When at was at Xerox, many years ago, our engineers were building a new multi-function device. Microsoft talked them into using a new version of Windows they had written for such devices named “Microsoft At Work” (renamed later to Windows CE). All the diskettes we received, directly from them, came virus infected. I don’t remember which virus but I do remember having to disinfect the files on our Novell servers and the desktop guys running around with antivirus boot disks to clean nearly every one of the 200+ Windows machines in that work group.

      1. By 1988, AGI engine was being very aged, anyway.

        Games like Space Quest III were using SCI0 already, which was much better. The Roland MT-32 support, notably.

        By 1990, Sierra had re-released maby titles as “VGA” titles, even though that was a bit of a misnomer.
        VGA is mode 12h, 640×480 16c.
        What these games really had used was “PS/2 Graphics” aka MCGA, mode 13h, 256c.

        Anyway, SCI engine was already on the horizon in the late 80s.
        Leisure Suit Larry and Kings Quest III were pretty late AGI titles, I think.

        AGI was a very compact engine that ran on C64 era hardware. Weak 8gbit machines with low-fi graphics.
        That’s why AGI games are so low-res. The viewport is 160×120 pixels, that’s a Gameboy’s resolution.

        So the AGI resolution did CGA w/ NTSC artifacts colors justice, at best.
        It massively underutilized the graphics abilities of a Tandy 1000 or EGA machine.

        To see what can be done with EGA let’s have a look at Lucas Arts’ The Secret of Monkey Island 2.

        It uses EGA’s 640×200 16c mode to do dithering.
        The visual result is close to running same game in MCGA in 320×200 256c.

        That’s were Sierra should have been in 1987/88, already, in terms of quality.

        If that was too much of work, Sierra could have had at least make use of normal EGA in 640×350 16c.

        Business users who probably played Larry a lot had used normal EGA monitors, anyway, because productivity software usually had required it.

        So yeah, AGI was very limited, graphically. Not state-of-the-art. But in 1984 it was okay.
        That’s when people had used machines such as an Apple II, ZX Spectrum or an Matell Aquarius.
        Or an IBM PC with CGA and a composite monitor.

  3. Interesting article. Though back then, so called “disk editors” were more popular than hex editors.
    Because, floppies were the main medium, anyway..

    One of the books by Peter Norton in ~1986 had shipped with one, for example, I vaguely remember.

    Using either is same base principle, really, but disk editors are being disk-oriented rather than file-oriented.

    Using a raw floppy image on a hex editor is about same experience.

    Of course, there might be fancy disk editors out there, with graphical representation of floppy content etc.

  4. “In commercial terms this would in 1988 have been something of a disaster for Sierra had it been discovered at the time, because it was the cornerstone of their success.” – not really. Reverse engineering was a thing back then as well, and the source code of games was tiny, back in the days, compared to now.

  5. Ah yes, I recall finding the code for the “key generator” for a BBC micro game (called XOR I think) at the end of the disk.
    I reported it to the company thinking they’d find it amusing and send me some swag or something but no dice.

  6. Oh! I didnt realise that it was the actual source code I was looking at! Wow!

    Back in 1993 I got the SQ2 disks and hex’d away for *days* trying to bypass the CRC copy protection in (This was 12 months before I had access to the net which a quick BBS search would find the necessary nop’s to wipe out two or three conditional JMP’s). I can recall seeing heaps of code in the unused sectors but had no idea what I was looking at.

    …so, discovered in 1993. But not knowing what it was.

    1. …racing through looking at the source code now. Wow oh wow. Bringing back memories of trying to find those conditional jumps and stepping line by line through using DEBUG.
      Can’t believe that the source could have been put out there for the world 30 years ago if only I had of even had an inckling of what I was looking at. (C source code. This is going to read weird, but, I didn’t even know what C source looked like at the time. I was lapping up intel assembly as far as I could)

  7. I remember playing the SoL ‘quest’ series games at my first job.
    Then getting stuck and digging in to scanning through the files with hex editor/viewer for clues.
    Spotting an ‘almost’ but not quite repeating pattern and smelling XOR ‘encryption’
    A bit of trial and error later and some XOR’ing in quickbasic.
    Before you could say ‘AvisDurgan’ you had the previously encrypted text content.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.