29 ms·

The Space Quest II Master Disk Blunder

644 points by smcameron 2y ago

JohnFen 2y ago
Still not as bad as when a company I worked for managed to press and ship a ton of CDs that included a virus.
- ljf 2y ago
  Ouch - no where near that bad but once I was working on a children's online game. The game was large (500MB or more), and this was still pretty early on in ADSL roll out - lot's of kids still had dial up. So we offered a CD with the game on for free. After 800 of them arrived for me to start mailing out, they found a small issue with the game, which they patched - "don't worry the kids will just have to run the patch the first time they play" - I tested it, the patch was 800MB... I didn't send any of the CDs out.
  - zoky 2y ago
    How the heck could a 500MB game have an 800MB patch? Sounds like someone had no idea what they were doing…
    - ljf 2y ago
      I just managed the website - I wasn't involved in the game, but it didn't seem to be that well managed from my outside perspective. I think part of the issue was there was not system to 'patch' - so the far larger download in theory allowed them to add smaller patches to the game in the future, but that didn't happen as far as I remember. I don't think we even ended up opening all the levels of the game as the uptake wasn't that great.
  - mypalmike 2y ago
    I worked at a game company in the 90s that shipped a strategy game with a bug where the AI would literally never attack the player. I think the cause was some last minute copy/paste while rushing to deliver the game to the publisher. It was discovered before the game hit the shelves, but the decision was made to ship it anyhow and release a patch, which had just become a somewhat reasonable practice with all those 33.6k modems out there.
- MenhirMike 2y ago
  Still could be worse. For example, the King's Quest 8 Master CD-ROM contained a copy of King's Quest 8.
  - gwbas1c 2y ago
    ??? Did you mean to type something different? Obviously the King's Quest 8 master will contain King's Quest 8.
    - henrikschroder 2y ago
      [dead]
    - Sniffnoy 2y ago
      That's the joke. It's a joke about the quality of King's Quest 8.
      - hi-v-rocknroll 2y ago
        KQV was the best one. The later ones jumped the shark.
    - Dwedit 2y ago
      King's Quest 8 (Mask of Eternity) is a terrible game. King's Quest is an adventure game series. It is known for hand-drawn 2D character sprites moving over hand-drawn 2D backgrounds, collecting items and solving inventory puzzles. This entry in the series tried to "modernize" it by adding in 3D graphics and RPG-like combat elements, which completely went against everything the series stood for. The 3D graphics were around N64 quality and aged very poorly. It's considered to be a game that killed off the whole Adventure game genre.
      - bzzzt 2y ago
        That was Gabriel Knight 3 with the infamous 'cat hair moustache' puzzle right? ;)
- joezydeco 2y ago
  There was a game startup a long time ago that shipped the heavily instrumented debug build of an Xbox game instead of the certified gold master.
- protocolture 2y ago
  Worked on a small game development project in university. It was meant to teach us project managment and coding skills. It took one whole trimester, 3 months or so, and we had a working game. The only deliverable we had not met was handing the mastered game over to the tutors. The Project manager reserved this responsibility for himself. He put the disc in a PC. Messed around with it. Handed it in. Got on his motorcycle and left the state. Turns out he handed over a blank disc. We almost all failed, lots of students suddenly low on HD space had started purging their laptops of the files. The coders had to come in on semester break to put something together to hand in. There was one guy who backed up everything, out of a team of 30 or so people.
khedoros1 2y ago
There were a couple posts on this yesterday too (although no discussion there either). https://news.ycombinator.com/item?id=40438604 https://news.ycombinator.com/item?id=40438604 https://news.ycombinator.com/item?id=40437834 https://news.ycombinator.com/item?id=40437834 It's weird how stories sometimes take a few tries to catch on.
- indigoabstract 2y ago
  It looks like third time's a charm. I for one think it's a feature to have stories competing for the reader's attention and just take their time to bubble up to the front page. And this is quite an interesting story. Since the Sierra games' source code was never publicly released, it makes me think how radical id were to open source their games at the time, in the 90's.
- Suppafly 2y ago
  Might depend on what time of day they are posted?
- lance_ewing 2y ago
  I was wondering the same thing. I was the first post, then saw the second one. I was quite surprised to see this third one really take off like this. Yeah, perhaps it does depend on the time of day? - A big thank you to smcameron for reposting.
mmastrac 2y ago
Ah yes, the two modes of disk erase failure: 1) the "quick format" that just re-wrote the FAT and root directory, leaving data, and 2) the immediately recognizable 0xE5 (σ in the 437 codepage). I used to use the Norton disk editor tool (IIRC, part of Disk Doctor) to explore my drive from time-to-time and it was somewhat fun to try and piece back together deleted files. In some cases, it was actually because I had accidentally deleted something important and UNDELETE wasn't good enough to get it back. In one hare-brained moment, I decided to see what would happen if I turned off the DIR attribute bits on all of the directory entries in the root of my drive to see what would happen in DOS. The stress of trying to find a boot disk to edit those attributes back left a few decades of PTSD, though I'm sure that taught me some valuable, subconscious lessons. Eventually I did recover from that mistake!
- sumtechguy 2y ago
  I blew away a boot sector once playing that game....
- anyfoo 2y ago
  When I was young, I discovered the joy of writing TSR programs in assembly. TSR stands for "terminate and stay resident", basically background programs in DOS. It's somewhat similar to what you would call a "daemon" in Unix, though much more "free form" and low level. One such early TSR of mine hooked the disk services interrupt (INT 13h I believe), which got invoked whenever you want to access the disk through the BIOS (so, almost always), and my program then output a little "click" over the speaker. The result was as if you took the already very audible seeking of spinning hard disks and made it really, really loud. It wasn't even my idea, just a fun premise to fiddle with hooking interrupt handlers. I compiled/assembled the TSR, ran it, and typed "DIR". The expected clicking came out of the speaker with every disk access, which indeed sounded funny and great, but at the end of the directory listing, an error appeared. I typed "DIR" again, and now listing the directory failed entirely. In a bout of incredible stupidity, I typed "CD \" to change to the root directory, and "DIR" again. Now I couldn't list my root directory. I reset my computer and... DOS did not boot anymore. It suddenly became immediately clear what I had done. My interrupt handler, after outputting the click over the speaker, obviously had to call back into the old handler, to actually service the requested disk access. When saving and restoring the registers that instruct the original handler what disk access to perform, I must have messed up in a way that it, at least sufficiently often, converted a read access into a write access. I don't remember the details, probably just flipping a single bit would do that. But effectively I've overwritten every sector of my root directory (and the original working one) with junk. So I had destroyed at least my root directory, and hence lost access to all my data. With lots of work I probably could have pieced my root directory back together. Nowadays, I'd probably have taken it as an exciting challenge to write a program that heuristically does just that by itself. Back then, I'm pretty sure I just abandoned the file system and started over.
MenhirMike 2y ago
It did apparently happen with quite a few games, where the Master Disk wasn't a brand new disk but some random disk that someone formatted and sent over to duplication. There are other games where cut content or early source code was recovered that way because the duplication house didn't work on a file system level but duplicated the entire disk as-is.
coldcode 2y ago
Between 1987 and 1993, I prepared around nine master disks for two Mac apps. I always used a fresh floppy and had a long list of checks to ensure the disk was correct. Thankfully, all came out right, especially when some were used to make 100k disks. It's a good thing no one has to do this anymore!
- shagie 2y ago
  They do, though its called "docker layers" I have seen layers that were: base add tools add source code compile delete source code delete extra tools (ship - why is the docker image so large? Oh well, storage is cheap...) And there are easy ways to resolve this such as multi stage builds ( https://docs.docker.com/build/building/multi-stage/ https://docs.docker.com/build/building/multi-stage/ ) - but mistakes still happen from time to time when people aren't aware that the current view of the docker image contains all of the previous layers too.
  - coldcode 2y ago
    At least you can replace it quickly if you find it broken. Back then, we could only afford to make an update once. When you mailed out the update disk, you had to charge for it ($10 or so, disk, mailing container, printed instructions, postage, and label); if you sent out 100k bad disks, you had to eat $1M. If it was version 1.0, it went into a box and was shipped to distributors, retailers, and mail-order, and you might never even know who the end user was.
mmahemoff 2y ago
My favourite part is no-one apparently discovered the source code sitting on the disk for an entire generation. “Surprisingly, no one appeared to have noticed that this happened, not Sierra, not their competitors or their customers, and it was only discovered decades later, the first known discovery of it by online user NewRisingSun in October 2016.” Reminds me of the recent breakthroughs in Tetris and Super Mario Bros. When I played these games as a kid, I would have thought they’d be forgotten relics decades later, impossible for anyone but the most dedicated hobbyist to stand up and run, let alone keep learning new things about them. The internet and emulators breathed new life into those earlier games and computing.
- LaundroMat 2y ago
  I guess your last sentence answers your question. I'm sure some people had found the deleted files, but because that would before the internet was ubiquitous, it was not generally known or recorded.
  - lance_ewing 2y ago
    Yeah, this could well be true. I was using a Hex Editor a lot back in the late 80s and early 90s, and that involved many of the Sierra games. Most of the time I was looking at the files installed on a hard disk though, as I generally installed the game from the floppy to the hard disk first and assumed I had everything. I think it would have been rare for me to be viewing the whole floppy disk of a Sierra game sector by sector in a Hex Viewer, although I did do that a lot for some disks. I'm surprised I didn't spot this back in those days. I bought this version of Space Quest II back in 1989.
    - caf 2y ago
      My memory of those times was that floppy disks were fragile enough, and software expensive enough, that you would take the original disks out only to install the game (or cough make a backup copy for a friend) and then carefully put them back in the box. So it's not too surprising to me that people weren't studying them closely enough to spot this.
TillE 2y ago
I don't think there's any particular secret sauce in the AGI engine, such that competitors would benefit from a leak. There are probably other examples I can't think of, but Hugo's House of Horrors was basically an AGI-style game made by one guy just a few years later. Beyond the initial novelty of a graphical adventure, Sierra games worked because they put a ton of effort into creating those graphics and actually writing the game. The tech isn't nothing, but it's a small fraction of the end product.
- pavlov 2y ago
  Information and useful example code were much harder to acquire in those days. Learning to build working software was immensely harder than today because there was nothing to build on. There was almost no meaningful open source on MS-DOS, and certainly no open source game engines. In that environment a widespread leak of the AGI source might have been significant, at least as an inspiration that would have provided a blueprint of exactly how these most popular PC games of the era were made.
- GuB-42 2y ago
  I sometimes wonder if leaked source code has any value, especially code like that that doesn't contain secrets that could be taken advantage of by hackers (ex: keys, backdoors, ...). The leak obviously doesn't come with any license, so you can't reuse that code for your own products, at least not if you don't want to get sued. So it means that in order to take advantage of the code for your own work, you need to read it, understand the techniques, and apply them to your own work in a way that doesn't smell like copyright infringement. More often than not, it is harder to do than going from scratch, and in cases it is advantageous, how often will you get a real competitive advantage? Developers often write code from scratch even when they could use open source code that is well documented and with a permissive license. Reading code is often harder than writing it. Even just rebuilding it may be challenging. It may facilitate piracy, but barely, games often got cracked and distributed within days, and the copy protection may not even be part of the source code.
  - Gormo 2y ago
    If I'm not mistaken, Microsoft now owns all of the old Sierra IP (if I'm not mistaken, the chain of custody was: Sierra -> CUC -> Cendant -> Havas -> Vivendi Universal -> Activision Blizzard -> Microsoft) and I wouldn't expect Microsoft to sue over old source code to a 40-year old game engine with a graphics resolution of 160x200. In fact, given that they've been gradually opening source code for DOS from the same era, they might even be convinced to make an official release of it.
rietta 2y ago
Fascinating! What a fortuitous mistake for historical preservation purposes. Also a good lesson in why media overwrites are important.
elvis70 2y ago
Double Dragon II: The Revenge for DOS from 1989 was distributed on two floppy disks, one of which contained the entire source code in a deleted archive file, invisible from the DIR command but easily recoverable: https://tcrf.net/Double_Dragon_II:_The_Revenge_(DOS) https://tcrf.net/Double_Dragon_II:_The_Revenge_(DOS)
- jpsouth 2y ago
  This might be a silly question, but how does this even happen? I would have thought they’d finalise the game, get a ‘master’ of sorts and then send it to a mass production facility - how would the deleted archive end up on the master? Did they accidentally copy it over, then remove it before shipping? Edit: definitely should have read the comments here before adding my own!
  - MenhirMike 2y ago
    Yeah, Duplication Houses usually duplicate the disk sector-by-sector, instead of on a file system level. (This makes a lot of sense, because it allowed the disk to contain any file system). But that also means that data that was still on the physical sectors of the disk got copied as well, regardless of whether the file system on the disk was still referencing that data.
    - Rinzler89 2y ago
      >Yeah, Duplication Houses usually duplicate the disk sector-by-sector I think they went even deeper. From the vintage computing nerds I saw on YouTuber, I think the duplication houses were replicating the raw magnetic flux off the disks as-is, since game studios were implementing some crafty low level anti-piracy measures on the golden disks to ensure that if you did sector level copies at home you wouldn't be able to run the game.
      - MenhirMike 2y ago
        That makes sense, I do remember some Commodore 64 games that even a Nibbler couldn't properly duplicate, and how some people modified their 1541 drives to have a different timing to work with some of that stuff.
greenthrow 2y ago
This article has a bunch of stuff asserted as facts that just aren't. As mentioned in another comment, there was nothing technically advanced about AGI itself. If other studios wanted to get into adventure games they didn't need to steal AGI to do it. And no one with a functioning brain would have used a stolen game engine for a commercial game. Companies don't want to give away their code but in the case of adventure games it's not because they are worried about their competitors. The other assertion that's off-base is that this would have been a sackable offense. No. Sierra still had legal protection against competitors using their game engine. This goof, while a little embarassing, had no real financial or security or any other damaging implications for the company. I doubt anyone would have gotten any more than a talking to about how to avoid it happening again.
- lance_ewing 2y ago
  Yeah, that is a fair point. I was a little too eager and dramatic with my wording. I have now removed the bit about it potentially being a sackable offence, as I feel you are probably right regarding that. Someone else in the comments made a similar point. Your point about the legal protection against competitors is a good one too. I've tried to reword the bit that suggested it might be drastic. Let me know if you think it reads better now. Thanks.
  - greenthrow 2y ago
    Yep, I think it's better, FWIW.
me_again 2y ago
I sometimes wonder about the commercial impact of source code leaks. In this case, nobody noticed until the product was commercially irrelevant, but what might have happened if some competitor had noticed? My guess is probably nothing. Having the interpreter source code is a liability for other companies in case of an infringement lawsuit. Are there good examples where a source code leak actually led to significant consequences for a company?
- ryandrake 2y ago
  My hunch is that companies tend to be paranoid and vastly overestimate the commercial importance of their source code. Are there really that many realistic opportunities to copy secrets from one mature source tree to another and commercially benefit from it? These code bases are likely totally different, use different design patterns, different internal APIs, data models are different, maybe even different languages. Anyone who has done integration work between two totally foreign-to-each-other code bases knows that the integration effort is often greater than just writing the code from scratch. The biggest risk is probably someone getting their hands on the entire project, including code, art assets, build infrastructure, and just compiling an identical program to release under their own name. But that would be obvious and probably easy to prove/litigate.
  - cesarb 2y ago
    > Are there really that many realistic opportunities to copy secrets from one mature source tree to another and commercially benefit from it? These code bases are likely totally different, use different design patterns, different internal APIs, data models are different, maybe even different languages. When you're stuck failing to make something work, it can be a large benefit to be able to look at how somebody else managed to make it work. Sometimes it's a bit you forgot to set on a register somewhere, sometimes it's a sequence of operations that tickles a hardware bug which can be avoided by doing things in a different order. On a higher level, sometimes the issue is that the A API is implemented as "return <error>" and only the corresponding W API is actually implemented. Or the trick to make the API work is to cast one of the many objects you already got into a non-intuitive poorly-documented interface, allowing you to call a method which returns yet another object which allows you to do what you actually want. And so on.
jandrese 2y ago
I wonder if this is the only copy of that source code that survives? It's extremely common for source code from that era to be lost to time, especially from defunct companies. From a historical and preservation viewpoint this "blunder" may be a miracle.
- lance_ewing 2y ago
  It happened twice at Sierra, around the same time in fact. I have found part of the AGI interpreter source code on a King's Quest III disk (version 2.14, 720KB version, disk 1). There is nowhere near as much, but lucky for us, it happens to include a few complete files that were not on the SQ2 disk. So that increases the total amount of source a bit. I have checked other Sierra disks, and so far the SQ2 and KQ3 occurrences are the only ones I know of.
EvanAnderson 2y ago
Always do sector-level imaging of old disks, at minimum, for archiving. ("Flux"-level images taken with something like Greaseweazel are even better.)
- hi-v-rocknroll 2y ago
  Greaseweazle. Back in the day, there was Central Point's Copy II PC Deluxe Option Board, or the rarer Central Point's Copy II PC Enhanced Option Board able to copy physically-damaged-for-copy-protection media. For copy protection, NevrLock and CrackAid. I still encounter DOS malware and a lack of proper cracking in some poor quality releases on the interwebs. For archival purposes, it's generally better to buy several physical copies of a game and Greaseweazle it and end up with at least 1 complete and unspoiled version.
- snvzz 2y ago
  Precedence like: "analog" (multi-bit samples) flux > digital (1bit samples) flux > track > sector > block > files.
Exuma 2y ago
This game was such an insane strong part of my childhood that when I think about the present day many years later it feels like a dream. I try to imagine in my current life having the same sort of "connection" to a game and it just feels impossible. Everything around me feels like "just" a game, show, material object, whatever... but space quest 2,3,4 all feel like they are fundamentally part of my DNA, intertwined with it.
- thyrox 2y ago
  I feel that for music. During my teenage years I used to listen to the same songs over and over on my walkman. I still remember 99% lyrics to the whole albums. The music used to have such a strong connection. Nowadays there are 1000+ songs in my playlist I can't even recollect 20% lyrics nor there is a chance in hell that I would listen to every single song on the entire album let alone every single song by tthe same artist. It's like if I don't like the first 10 seconds, it's hide song and Spotify makes sure I never have to listen to that again. Even though some of my all time favorites are songs I hated at first but then there was no hide song button. Sorry I digress but yeah the connections you make in childhood are really something. I just hope it's my age and not the technology responsible for this and the youth of today feel the same connection too.
  - caf 2y ago
    I still try to find time to sit down and listen to an album from start to finish - it's kind of like the musical equivalent of spending an hour in a gallery exhibition of a single artist's work.
- the_af 2y ago
  Same feelings but specifically about Space Quest II. I played SQ I way later in life, and SQ III didn't resonate as strongly with me. The rest were no longer EGA "text input" games either. SQ II brings back memories. I learned some of my English with it, too. I remember the feeling of satisfaction when I discovered I could "rub berries" on Roger Wilco ;)
  - 2y ago
mrguyorama 2y ago
This exact situation actually happened all the time. The cutting room floor lists about 500, in various states between just a little accidental included code to most of it: https://tcrf.net/Category:Games_with_uncompiled_source_code https://tcrf.net/Category:Games_with_uncompiled_source_code
- lance_ewing 2y ago
  Thanks for the link. I hadn't previously visited that site. Very interesting. From a quick check, I can't see this particular Space Quest II disk's AGI interpreter uncompiled code mentioned in there yet. Do you agree? I have noticed that the same thing happened with a King's Quest III disk, in fact it looks like it may have happened around the same time as the Space Quest II occurrence.
  - mrguyorama 2y ago
    https://tcrf.net/Space_Quest_II:_Vohaul%27s_Revenge https://tcrf.net/Space_Quest_II:_Vohaul%27s_Revenge This AGI code is mentioned at the bottom of the Space Quest II page. It's not technically "source code for the game" so it doesn't fit in the category I linked above.
Joel_Mckay 2y ago
This still happens at some firms every so often with source code and private signing key sets. The issue is usually management making an arbitrary call on who is part of the development pipeline. Thus, for a time some contractors and partners may get a backup of the build tree or temporary repository access (if you catch the "new" users.) It is harder than one would think to keep things confidential... Cleaning up after one of these leaks is another set of problems, but usually at that point it is better to jump ship. Best of luck, =)
Dwedit 2y ago
The Famicom version of Air Fortress has a ridiculously large amount of stuff unintentionally making it into the ROM. There is some uncompiled ASM code in there, some MS-DOS directory listings, some text strings from one of the EXEs used to build the game, and even more. The Japanese cartridge was 128+128KB large. Then they built the US NES version. Most of the 128K of graphics data was duplicate graphics, or unused. There was about 36KB of actual unique graphics. They shrunk the graphics down to 32KB by removing an image of a planet from one of the endings, and shipped it on a 128+32KB cartridge instead of a 128+128KB cartridge. Source: https://tcrf.net/Air_Fortress https://tcrf.net/Air_Fortress
boricj 2y ago
Back when release artifacts were hand crafted, these often contained leftovers that weren't meant to be shipped, like cut content [1] or debugging symbols [2]. When I stumbled upon debugging symbols hidden inside the data archive of the demo version of the video game I'm reverse-engineering, it was an unexpected but very helpful surprise. Nowadays with CICD, automated builds and other modern development practices it probably happens less often. [1] https://tcrf.net https://tcrf.net [2] https://www.retroreversing.com/games/symbols https://www.retroreversing.com/games/symbols
- playingalong 2y ago
  CICD pipelines can also work the opposite direction. No one looks into several thousands of console output unless there is some error. Also the tests are likely to pass even with excessive content in the final release package. So my intuition is rather opposite. It may happen more often. Or at least CICD makes it more likely to happen than manual building. There might be other factors too.
  - boricj 2y ago
    I'd say manual building has a chance of a slip-up every time it is done, whereas automated building has a chance that it will slip-up every time it is executed.
- protocolture 2y ago
  I have a suspicion that good practices like CI/CD are not as common a feature of games development as one might suspect.
ajxs 2y ago
I've been doing a lot of reverse-engineering of synthesiser ROMs lately. The Yamaha DX9 ROM has some fragments of the firmware's symbol table embedded in the empty space left in the binary[0], along with a big block of 6303 code that was probably from whatever development system they used. It's a really amazing feeling when you stumble upon things like this! I'm such a nerd about these things that I feel like some kind of software-archaeologist, getting a small glimpse into the past. Finding this sent me down a really deep rabbit hole trying to find out more information about what development tools Yamaha might have used. I never discovered anything definitive, but reading the documentation on contemporary devtools gave me a real appreciation for modern workflows! 0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_a_DX7.html#leftover_data https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...
- aa-jv 2y ago
  I too like to reverse engineer synthesizer things, and I did it for the Yamaha A-samplers back in the day, producing a management tool that sped up the basic operations for Yamaha A-sampler disk users .. I used a BeBox to do a lot of raw i/o and analysis of raw disk sectors, as BeOS had some nice tools for filesystem hacking, and through this I managed to build a filesystem driver (for Windows) which worked well enough to get Yamaha's backing. If you ever get the motivation to reverse engineer the Yamaha ROM's for the A-samplers, lets get in touch. I have a lot of interest in this realm .. (EDIT: great work on the DX9/DX7 thing .. as an original user of both synths when they were released, this is really amusing ..)
  - easyThrowaway 2y ago
    Oh god the repressed memories. I believe there was a SCSI thingy to do some basic sysex (or whatever format they were using) and presets save/load from 68K macintoshes?
    - aa-jv 2y ago
      For the A-samplers? There are a number of tools out there for manipulating the A-sampler data with a PC - I wrote one of them (DiskY) which makes filesystem management over SCSI with a Windows PC a lot smoother/faster than using the onboard OS, and there is also b.Zone, which is an editor that uses MIDI CC and Sysex to do editing. Together, they make the A-sampler .. almost .. usable. ;) I would love to dig further into the A-sampler ROM and figure out a few more of its secrets. I'd especially like to know the exact reason why the A-samplers SCSI subsystem is .. so .. darn .. slow .. so maybe there's a chance to dig into this at some point.
olliej 2y ago
Not sure this would have counted as “losing it to the public domain” - accidentally leaking the sources doesn’t negate copyright (presumably just trade secrets stuff by Iqbal)
- lance_ewing 2y ago
  Yeah, sorry, that was a poor choice of words on my part. I have reworded the sentence slightly to hopefully avoid the legal implication.
  - olliej 2y ago
    ah yeah that's fair :D
johnyzee 2y ago
I love the change history comments. They show a high level of attention to detail and craftsmanship, at a time long before source control tools made this kind of thing obvious (and honestly, even after CVS/SVN/Git it still wasn't obvious to a lot of people). This post also makes me think of the famous 'No Silver Bullet' essay[1], which in 1986 predicted that software would more or less continue to be written they way it was then, by programmers, painstakingly, one instruction after the other. The similarity of the game engine code (along with the comments) in the OP, to something I might have written today, bears this out, I think, almost 40 years (!) later. [1] https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet
- progbits 2y ago
  To this day I see too many git commits like "fix" and "stuff".
  - brokenmachine 2y ago
    No need for personal attacks.
    - cmplxconjugate 2y ago
      When I became a lead dev, one of the first issues I had was a 55 y/o dev who begrudgingly adopted git but consistently included commits like: “Monday morning commit”, “changed some things”, “commit”. He also refused to delete issue template examples and included it all with his own additions. In the entire time we worked together over a few years, he refused to adapt to the rest of the team.
      - sumtechguy 2y ago
        I have younger devs who do the same thing. Some people just do not want a process at all and do not play well with others.
        2y ago
pcwalton 2y ago
Looking through the repo, some of the assembler [1] looks odd: getShdwOfst: xor bh,bh mov bl,al mov di,bx shl di,1 shl di,1 shl d1,1 ... Why shift one bit at a time, like you would on a CPU like the 6502 with no multi-bit shift instructions? Was this hand-ported from some system without those? [1]: https://github.com/lanceewing/agi/blob/main/src/CMGRAPHX.ASM#L579 https://github.com/lanceewing/agi/blob/main/src/CMGRAPHX.ASM...
- grumpyprole 2y ago
  8088 did not have a barrel shifter, so multi-bit shifts would have been expensive and non-interruptible over multiple clocks. Perhaps game devs just avoided them out of habit.
- ksherlock 2y ago
  It was hand-written for a system without multi-bit shift instructions. 8086 shifts were 1 bit at a time (2 cycles for a register shift.) or using cl for the count (8 cycles + 4 cycles/bit for a register shift). constant multi-bit shifts were added in the 80186.
jesprenj 2y ago
> FormMaster duplication machine Anyone got any links with more info about this device?
- lance_ewing 2y ago
  I found it very difficult to find references to it online. There is a reference in the "Hackers" book by Steven Levy to Sierra On-Line having one (he uses the name "Form Master"), and former Sierra employees have mentioned it as well but with the two words run together as FormMaster. As I couldn't find much more, I'm not sure which form of spelling is correct. https://www.google.co.uk/books/edition/Hackers/JwKHDwAAQBAJ?hl=en&gbpv=1&dq=%22Form+Master%22++steven+levy&pg=PA405&printsec=frontcover https://www.google.co.uk/books/edition/Hackers/JwKHDwAAQBAJ?... There is a photograph in a September 1983 issue of a Japanese magazine called "LOGiN" of one of Sierra On-Line's disk copying machines but the article doesn't mention it by name. I wonder if it is the FormMaster/Form Master machine. https://archive.org/details/login-september-1983/LOGiN%20-%20September%201983/page/138/mode/2up https://archive.org/details/login-september-1983/LOGiN%20-%2... As an aside, that September 1983 magazine is the earliest clear reference to the development of King's Quest that I could find. It isn't mentioned by name but it is obvious that it is King's Quest that is being referred to.
  - jesprenj 2y ago
    Thank you for the links! I kind of expected a machine with 10+ floppy slots (: I think I just wasn't really aware of the year this machine was produced.
    - lance_ewing 2y ago
      This video that Ken Williams put on Youtube a year or so back has got a short bit showing someone using the machine in the Sierra On-Line office: https://www.youtube.com/watch?v=oY_JbTYXVjg https://www.youtube.com/watch?v=oY_JbTYXVjg It is at about 1:47 into the video. It is the same machine shown in that LOGiN magazine article. This one appears to only support the 5 1/4 inch floppies, since I think the 3 1/2 inch disks weren't around at the time, so they must have got a newer machine later on. Ken's title for the video claims it was from 1983, but from my research, I think that a September 1982 date is more likely. The whole thing is an amazing video actually. Well worth watching. Incredible that it actually survived and is now preserved on Youtube.
accrual 2y ago
Kind of a tangent but I wonder how the serial numbers on the floppy disks were generated. They're clearly not sequential and the length differs between version 2.0D and 2.0F. SER# 312929011101963 (15 digits) SER# 3129289101202698 (16 digits) I wonder if they kept track of these in a CSV or something. Was the idea a customer could call in with their serial number and report a problem, which could be traced to a batch number or something? Anyway, just a curiosity I noticed.
- lance_ewing 2y ago
  I was also wondering about these numbers when putting the article together. The photo of the 2.0D disk is of my own personal copy of the game. I assume the number is unique to that disk, but I haven't spent any time at all researching that. I wonder if someone has.
  - anyfoo 2y ago
    They might have intentionally obfuscated it, maybe to conceal how many disks they produced (https://en.wikipedia.org/wiki/German_tank_problem https://en.wikipedia.org/wiki/German_tank_problem ). Just XOR'ing the real serial number with a secret key that has exactly as many bits as the (padded) serial number is entirely sufficient, though my experience tells me that at that time, folks tended to do more complicated (and ironically, much less secure, not that it matters much here) things. Basic cryptography literacy wasn't as common then, as unencrypted and unauthenticated communication was the norm, even on most networks.
    - sumtechguy 2y ago
      > as unencrypted and unauthenticated communication was the norm, even on most networks That it worked at all was pretty amazing :)
- EnigmaFlare 2y ago
  I think you just nerdsniped me: 312929011101963 2.0D TFA 312929011100925 2.0D [1] 312928072902102 2.0D [2] 312928091704272 2.0D 5.25" [3] 3129289101202698 2.0F TFA 312922022211663 2.0F [4] 752923060122148 2.0F [5] 272929011600468 2.0F [6] 272929052600081 2.0F [7] The 16 digits seems like a freak. [1] https://archive.org/details/space-quest-ii-ms-dos-disk-1-of-2 https://archive.org/details/space-quest-ii-ms-dos-disk-1-of-... [2] https://www.mocagh.org/loadpage.php?getgame=sierra3pack-alt https://www.mocagh.org/loadpage.php?getgame=sierra3pack-alt [3] https://www.sierrachest.com/gfx/games/SQ2/box/03_m1.jpg https://www.sierrachest.com/gfx/games/SQ2/box/03_m1.jpg [4] https://www.mobygames.com/game/128/space-quest-ii-chapter-ii-vohauls-revenge/cover/group-6990/cover-14829/ https://www.mobygames.com/game/128/space-quest-ii-chapter-ii... [5] https://ia802300.us.archive.org/12/items/spacequest_ii_kfx/space_quest_ii_disk1.jpg https://ia802300.us.archive.org/12/items/spacequest_ii_kfx/s... [6] https://www.worthpoint.com/worthopedia/space-quest-ii-seirra-games-amiga-1777540316 https://www.worthpoint.com/worthopedia/space-quest-ii-seirra... [7] https://www.tradera.com/item/340851/630607300/space-quest-ii-chapter-2-vohaul-s-revenge-sierra-amiga https://www.tradera.com/item/340851/630607300/space-quest-ii...
lance_ewing 2y ago
> MWC was a C compiler from the Mark Williams company that was very popular in those days. Since publishing the article, I discovered some fragments of not yet linked compiled AGI interpreter obj files from the slack space on a KQ3 disk that mentions the MWC version number used, which was MWC86 V2.3.8. I also discovered a directory entry in the slack space of another sector on the same disk that has the name of the executable, MWC.EXE, the size and the timestamp: MWC.EXE 18420 23-Oct-1985 15:17:32
- ngneer 2y ago
  Great article. Great nostalgia. I wonder, do you still enjoy playing the games, now that you have thoroughly reverse engineered them? Also, what other insights have you gleaned? Also, have you read Not All Fairy Tales Have Happy Endings, by Ken Williams? https://kensbook.com/ https://kensbook.com/
  - lance_ewing 2y ago
    Yeah, I do still enjoy them. I have been having to play through a few of them again recently in order to test my own AGI interpreter (https://agi.sierra.games https://agi.sierra.games). For example, I've recently been playing King's Quest IV on my phone using AGILE. I bought Ken's book a while back. As Ken has mentioned in reference to that book, his memories of things aren't as clear as they used to be. It's a long time ago. Still a great read though. I enjoyed it. I have also read "The Sierra Adventure" by Shawn Mills. That's another great book, in fact it has some quotes from various people that I hadn't seen anywhere else. I loved some of the inside story from Doug MacNeill in regards to the original King's Quest project. I've actually been working on my own book in relation to Sierra, AGI, the AGI games, the tools, the fan-made games... all things AGI I guess. Its probably still a few years away from release though. I keep getting distracted by things like writing the web based AGI interpreter.
anyfoo 2y ago
> These days a great modern equivalent is the excellent HxD Hex Editor written by Maël Hörz. If you are on macOS, check out Hex Fiend: https://hexfiend.com https://hexfiend.com I'd pay for it if it wasn't free (and BSD licensed, to boot) anyway.
snvzz 2y ago
With memory map, partial source code and reverse engineering tools, it should be possible to recreate the whole thing.
- lance_ewing 2y ago
  Yes, certainly, and any gaps could be filled in with what the NAGI project provides: https://github.com/sonneveld/nagi https://github.com/sonneveld/nagi. NAGI is a fan-made AGI interpreter created by Nick Sonneveld. He disassembled the Sierra's original AGI interpreter and then used that to create equivalent C source code. It is interesting to compare what he came up with to the actual original AGI interpreter source code from the SQ2 disk. Nick had to make up appropriate names for things, as he obviously didn't have the memory map, but it is easy to see the equivalent functions etc when you compare equivalent modules.
aa-jv 2y ago
Back in the 80's I worked on a "multimedia engine" very similar to AGI, which had the requirement of not using MS-DOS - the customers who would use this engine for their titles, simply didn't want to pay an MS-DOS license. The engine thus used BIOS calls, and I implemented enough basic disk i/o functionality that we could boot from the floppy, load the engine, and stream the bytecode straight from raw floppy sectors into the engine, which would then display vector graphics on either CGA or EGA monitors (the multi- in multimedia). This worked well enough for two titles to be released to a few tens of thousands of customers, who enjoyed them well enough. A days before the clients started shipping the titles they'd built with my engine, I went back to look at the floppy disks for the "master engine" series, which would be the last update to the engine itself, just to be sure - and by then I needed a raw disk copying routine for another project, so I took a close look at the prior results to see if there were any major issues. Sure enough, in the 'empty' sectors of the engine disks I'd produced, I'd managed to include things that looked suspiciously like a DOS FAT-based filesystem. This was because I'd simply reused the same floppy to produce beta versions of the engine disks, and someone had taken one of my old master beta disks and used it 'temporarily', to copy some files for themselves, on MS-DOS machines. Lucky I caught it - we really didn't need to include a resignation letter in the empty spaces of the multimedia titles. Anyway, this story brought back fond memories of making a multimedia engine that didn't use MS-DOS .. and also, 40 years later, reminded me to always check the edge cases before you ship a master/gold release to customers who will ship it to tens of thousands of people .. I suppose the modern equivalent is to clean up the git repo before shipping, or have a procedure for vetting commits, lol. Okay, I gotta do that on some of my juniors' projects, brb ..
bluehex 2y ago
Once an Android app for the startup I was working on had a suspiciously large apk size. One of our engineers dug in and realized that our packaging script copied the .git directory in with the static files. All it took to see the source was to cd into the unzipped apk directory and do a "git reset --hard ."
bobmcnamara 2y ago
Medtronic did this on one of their heart monitor base stations.

644 points by smcameron 2y ago

JohnFen 2y ago

Still not as bad as when a company I worked for managed to press and ship a ton of CDs that included a virus.

ljf 2y ago
Ouch - no where near that bad but once I was working on a children's online game. The game was large (500MB or more), and this was still pretty early on in ADSL roll out - lot's of kids still had dial up. So we offered a CD with the game on for free. After 800 of them arrived for me to start mailing out, they found a small issue with the game, which they patched - "don't worry the kids will just have to run the patch the first time they play" - I tested it, the patch was 800MB... I didn't send any of the CDs out.
- zoky 2y ago
  How the heck could a 500MB game have an 800MB patch? Sounds like someone had no idea what they were doing…
  - ljf 2y ago
    I just managed the website - I wasn't involved in the game, but it didn't seem to be that well managed from my outside perspective. I think part of the issue was there was not system to 'patch' - so the far larger download in theory allowed them to add smaller patches to the game in the future, but that didn't happen as far as I remember. I don't think we even ended up opening all the levels of the game as the uptake wasn't that great.
- mypalmike 2y ago
  I worked at a game company in the 90s that shipped a strategy game with a bug where the AI would literally never attack the player. I think the cause was some last minute copy/paste while rushing to deliver the game to the publisher. It was discovered before the game hit the shelves, but the decision was made to ship it anyhow and release a patch, which had just become a somewhat reasonable practice with all those 33.6k modems out there.
MenhirMike 2y ago
Still could be worse. For example, the King's Quest 8 Master CD-ROM contained a copy of King's Quest 8.
- gwbas1c 2y ago
  ??? Did you mean to type something different? Obviously the King's Quest 8 master will contain King's Quest 8.
  - henrikschroder 2y ago
    [dead]
  - Sniffnoy 2y ago
    That's the joke. It's a joke about the quality of King's Quest 8.
    - hi-v-rocknroll 2y ago
      KQV was the best one. The later ones jumped the shark.
  - Dwedit 2y ago
    King's Quest 8 (Mask of Eternity) is a terrible game. King's Quest is an adventure game series. It is known for hand-drawn 2D character sprites moving over hand-drawn 2D backgrounds, collecting items and solving inventory puzzles. This entry in the series tried to "modernize" it by adding in 3D graphics and RPG-like combat elements, which completely went against everything the series stood for. The 3D graphics were around N64 quality and aged very poorly. It's considered to be a game that killed off the whole Adventure game genre.
    - bzzzt 2y ago
      That was Gabriel Knight 3 with the infamous 'cat hair moustache' puzzle right? ;)
joezydeco 2y ago
There was a game startup a long time ago that shipped the heavily instrumented debug build of an Xbox game instead of the certified gold master.
protocolture 2y ago
Worked on a small game development project in university. It was meant to teach us project managment and coding skills. It took one whole trimester, 3 months or so, and we had a working game. The only deliverable we had not met was handing the mastered game over to the tutors. The Project manager reserved this responsibility for himself. He put the disc in a PC. Messed around with it. Handed it in. Got on his motorcycle and left the state. Turns out he handed over a blank disc. We almost all failed, lots of students suddenly low on HD space had started purging their laptops of the files. The coders had to come in on semester break to put something together to hand in. There was one guy who backed up everything, out of a team of 30 or so people.

khedoros1 2y ago

There were a couple posts on this yesterday too (although no discussion there either). https://news.ycombinator.com/item?id=40438604 https://news.ycombinator.com/item?id=40438604 https://news.ycombinator.com/item?id=40437834 https://news.ycombinator.com/item?id=40437834 It's weird how stories sometimes take a few tries to catch on.

indigoabstract 2y ago
It looks like third time's a charm. I for one think it's a feature to have stories competing for the reader's attention and just take their time to bubble up to the front page. And this is quite an interesting story. Since the Sierra games' source code was never publicly released, it makes me think how radical id were to open source their games at the time, in the 90's.
Suppafly 2y ago
Might depend on what time of day they are posted?
lance_ewing 2y ago
I was wondering the same thing. I was the first post, then saw the second one. I was quite surprised to see this third one really take off like this. Yeah, perhaps it does depend on the time of day? - A big thank you to smcameron for reposting.

mmastrac 2y ago

Ah yes, the two modes of disk erase failure: 1) the "quick format" that just re-wrote the FAT and root directory, leaving data, and 2) the immediately recognizable 0xE5 (σ in the 437 codepage). I used to use the Norton disk editor tool (IIRC, part of Disk Doctor) to explore my drive from time-to-time and it was somewhat fun to try and piece back together deleted files. In some cases, it was actually because I had accidentally deleted something important and UNDELETE wasn't good enough to get it back. In one hare-brained moment, I decided to see what would happen if I turned off the DIR attribute bits on all of the directory entries in the root of my drive to see what would happen in DOS. The stress of trying to find a boot disk to edit those attributes back left a few decades of PTSD, though I'm sure that taught me some valuable, subconscious lessons. Eventually I did recover from that mistake!

sumtechguy 2y ago
I blew away a boot sector once playing that game....
anyfoo 2y ago
When I was young, I discovered the joy of writing TSR programs in assembly. TSR stands for "terminate and stay resident", basically background programs in DOS. It's somewhat similar to what you would call a "daemon" in Unix, though much more "free form" and low level. One such early TSR of mine hooked the disk services interrupt (INT 13h I believe), which got invoked whenever you want to access the disk through the BIOS (so, almost always), and my program then output a little "click" over the speaker. The result was as if you took the already very audible seeking of spinning hard disks and made it really, really loud. It wasn't even my idea, just a fun premise to fiddle with hooking interrupt handlers. I compiled/assembled the TSR, ran it, and typed "DIR". The expected clicking came out of the speaker with every disk access, which indeed sounded funny and great, but at the end of the directory listing, an error appeared. I typed "DIR" again, and now listing the directory failed entirely. In a bout of incredible stupidity, I typed "CD \" to change to the root directory, and "DIR" again. Now I couldn't list my root directory. I reset my computer and... DOS did not boot anymore. It suddenly became immediately clear what I had done. My interrupt handler, after outputting the click over the speaker, obviously had to call back into the old handler, to actually service the requested disk access. When saving and restoring the registers that instruct the original handler what disk access to perform, I must have messed up in a way that it, at least sufficiently often, converted a read access into a write access. I don't remember the details, probably just flipping a single bit would do that. But effectively I've overwritten every sector of my root directory (and the original working one) with junk. So I had destroyed at least my root directory, and hence lost access to all my data. With lots of work I probably could have pieced my root directory back together. Nowadays, I'd probably have taken it as an exciting challenge to write a program that heuristically does just that by itself. Back then, I'm pretty sure I just abandoned the file system and started over.

MenhirMike 2y ago

It did apparently happen with quite a few games, where the Master Disk wasn't a brand new disk but some random disk that someone formatted and sent over to duplication. There are other games where cut content or early source code was recovered that way because the duplication house didn't work on a file system level but duplicated the entire disk as-is.

coldcode 2y ago

Between 1987 and 1993, I prepared around nine master disks for two Mac apps. I always used a fresh floppy and had a long list of checks to ensure the disk was correct. Thankfully, all came out right, especially when some were used to make 100k disks. It's a good thing no one has to do this anymore!

shagie 2y ago
They do, though its called "docker layers" I have seen layers that were: base add tools add source code compile delete source code delete extra tools (ship - why is the docker image so large? Oh well, storage is cheap...) And there are easy ways to resolve this such as multi stage builds ( https://docs.docker.com/build/building/multi-stage/ https://docs.docker.com/build/building/multi-stage/ ) - but mistakes still happen from time to time when people aren't aware that the current view of the docker image contains all of the previous layers too.
- coldcode 2y ago
  At least you can replace it quickly if you find it broken. Back then, we could only afford to make an update once. When you mailed out the update disk, you had to charge for it ($10 or so, disk, mailing container, printed instructions, postage, and label); if you sent out 100k bad disks, you had to eat $1M. If it was version 1.0, it went into a box and was shipped to distributors, retailers, and mail-order, and you might never even know who the end user was.

mmahemoff 2y ago

My favourite part is no-one apparently discovered the source code sitting on the disk for an entire generation. “Surprisingly, no one appeared to have noticed that this happened, not Sierra, not their competitors or their customers, and it was only discovered decades later, the first known discovery of it by online user NewRisingSun in October 2016.” Reminds me of the recent breakthroughs in Tetris and Super Mario Bros. When I played these games as a kid, I would have thought they’d be forgotten relics decades later, impossible for anyone but the most dedicated hobbyist to stand up and run, let alone keep learning new things about them. The internet and emulators breathed new life into those earlier games and computing.

LaundroMat 2y ago
I guess your last sentence answers your question. I'm sure some people had found the deleted files, but because that would before the internet was ubiquitous, it was not generally known or recorded.
- lance_ewing 2y ago
  Yeah, this could well be true. I was using a Hex Editor a lot back in the late 80s and early 90s, and that involved many of the Sierra games. Most of the time I was looking at the files installed on a hard disk though, as I generally installed the game from the floppy to the hard disk first and assumed I had everything. I think it would have been rare for me to be viewing the whole floppy disk of a Sierra game sector by sector in a Hex Viewer, although I did do that a lot for some disks. I'm surprised I didn't spot this back in those days. I bought this version of Space Quest II back in 1989.
  - caf 2y ago
    My memory of those times was that floppy disks were fragile enough, and software expensive enough, that you would take the original disks out only to install the game (or cough make a backup copy for a friend) and then carefully put them back in the box. So it's not too surprising to me that people weren't studying them closely enough to spot this.

TillE 2y ago

I don't think there's any particular secret sauce in the AGI engine, such that competitors would benefit from a leak. There are probably other examples I can't think of, but Hugo's House of Horrors was basically an AGI-style game made by one guy just a few years later. Beyond the initial novelty of a graphical adventure, Sierra games worked because they put a ton of effort into creating those graphics and actually writing the game. The tech isn't nothing, but it's a small fraction of the end product.

pavlov 2y ago
Information and useful example code were much harder to acquire in those days. Learning to build working software was immensely harder than today because there was nothing to build on. There was almost no meaningful open source on MS-DOS, and certainly no open source game engines. In that environment a widespread leak of the AGI source might have been significant, at least as an inspiration that would have provided a blueprint of exactly how these most popular PC games of the era were made.
GuB-42 2y ago
I sometimes wonder if leaked source code has any value, especially code like that that doesn't contain secrets that could be taken advantage of by hackers (ex: keys, backdoors, ...). The leak obviously doesn't come with any license, so you can't reuse that code for your own products, at least not if you don't want to get sued. So it means that in order to take advantage of the code for your own work, you need to read it, understand the techniques, and apply them to your own work in a way that doesn't smell like copyright infringement. More often than not, it is harder to do than going from scratch, and in cases it is advantageous, how often will you get a real competitive advantage? Developers often write code from scratch even when they could use open source code that is well documented and with a permissive license. Reading code is often harder than writing it. Even just rebuilding it may be challenging. It may facilitate piracy, but barely, games often got cracked and distributed within days, and the copy protection may not even be part of the source code.
- Gormo 2y ago
  If I'm not mistaken, Microsoft now owns all of the old Sierra IP (if I'm not mistaken, the chain of custody was: Sierra -> CUC -> Cendant -> Havas -> Vivendi Universal -> Activision Blizzard -> Microsoft) and I wouldn't expect Microsoft to sue over old source code to a 40-year old game engine with a graphics resolution of 160x200. In fact, given that they've been gradually opening source code for DOS from the same era, they might even be convinced to make an official release of it.

rietta 2y ago

Fascinating! What a fortuitous mistake for historical preservation purposes. Also a good lesson in why media overwrites are important.

elvis70 2y ago

Double Dragon II: The Revenge for DOS from 1989 was distributed on two floppy disks, one of which contained the entire source code in a deleted archive file, invisible from the DIR command but easily recoverable: https://tcrf.net/Double_Dragon_II:_The_Revenge_(DOS) https://tcrf.net/Double_Dragon_II:_The_Revenge_(DOS)

jpsouth 2y ago
This might be a silly question, but how does this even happen? I would have thought they’d finalise the game, get a ‘master’ of sorts and then send it to a mass production facility - how would the deleted archive end up on the master? Did they accidentally copy it over, then remove it before shipping? Edit: definitely should have read the comments here before adding my own!
- MenhirMike 2y ago
  Yeah, Duplication Houses usually duplicate the disk sector-by-sector, instead of on a file system level. (This makes a lot of sense, because it allowed the disk to contain any file system). But that also means that data that was still on the physical sectors of the disk got copied as well, regardless of whether the file system on the disk was still referencing that data.
  - Rinzler89 2y ago
    >Yeah, Duplication Houses usually duplicate the disk sector-by-sector I think they went even deeper. From the vintage computing nerds I saw on YouTuber, I think the duplication houses were replicating the raw magnetic flux off the disks as-is, since game studios were implementing some crafty low level anti-piracy measures on the golden disks to ensure that if you did sector level copies at home you wouldn't be able to run the game.
    - MenhirMike 2y ago
      That makes sense, I do remember some Commodore 64 games that even a Nibbler couldn't properly duplicate, and how some people modified their 1541 drives to have a different timing to work with some of that stuff.

greenthrow 2y ago

This article has a bunch of stuff asserted as facts that just aren't. As mentioned in another comment, there was nothing technically advanced about AGI itself. If other studios wanted to get into adventure games they didn't need to steal AGI to do it. And no one with a functioning brain would have used a stolen game engine for a commercial game. Companies don't want to give away their code but in the case of adventure games it's not because they are worried about their competitors. The other assertion that's off-base is that this would have been a sackable offense. No. Sierra still had legal protection against competitors using their game engine. This goof, while a little embarassing, had no real financial or security or any other damaging implications for the company. I doubt anyone would have gotten any more than a talking to about how to avoid it happening again.

lance_ewing 2y ago
Yeah, that is a fair point. I was a little too eager and dramatic with my wording. I have now removed the bit about it potentially being a sackable offence, as I feel you are probably right regarding that. Someone else in the comments made a similar point. Your point about the legal protection against competitors is a good one too. I've tried to reword the bit that suggested it might be drastic. Let me know if you think it reads better now. Thanks.
- greenthrow 2y ago
  Yep, I think it's better, FWIW.

me_again 2y ago

I sometimes wonder about the commercial impact of source code leaks. In this case, nobody noticed until the product was commercially irrelevant, but what might have happened if some competitor had noticed? My guess is probably nothing. Having the interpreter source code is a liability for other companies in case of an infringement lawsuit. Are there good examples where a source code leak actually led to significant consequences for a company?

ryandrake 2y ago
My hunch is that companies tend to be paranoid and vastly overestimate the commercial importance of their source code. Are there really that many realistic opportunities to copy secrets from one mature source tree to another and commercially benefit from it? These code bases are likely totally different, use different design patterns, different internal APIs, data models are different, maybe even different languages. Anyone who has done integration work between two totally foreign-to-each-other code bases knows that the integration effort is often greater than just writing the code from scratch. The biggest risk is probably someone getting their hands on the entire project, including code, art assets, build infrastructure, and just compiling an identical program to release under their own name. But that would be obvious and probably easy to prove/litigate.
- cesarb 2y ago
  > Are there really that many realistic opportunities to copy secrets from one mature source tree to another and commercially benefit from it? These code bases are likely totally different, use different design patterns, different internal APIs, data models are different, maybe even different languages. When you're stuck failing to make something work, it can be a large benefit to be able to look at how somebody else managed to make it work. Sometimes it's a bit you forgot to set on a register somewhere, sometimes it's a sequence of operations that tickles a hardware bug which can be avoided by doing things in a different order. On a higher level, sometimes the issue is that the A API is implemented as "return <error>" and only the corresponding W API is actually implemented. Or the trick to make the API work is to cast one of the many objects you already got into a non-intuitive poorly-documented interface, allowing you to call a method which returns yet another object which allows you to do what you actually want. And so on.

jandrese 2y ago

I wonder if this is the only copy of that source code that survives? It's extremely common for source code from that era to be lost to time, especially from defunct companies. From a historical and preservation viewpoint this "blunder" may be a miracle.

lance_ewing 2y ago
It happened twice at Sierra, around the same time in fact. I have found part of the AGI interpreter source code on a King's Quest III disk (version 2.14, 720KB version, disk 1). There is nowhere near as much, but lucky for us, it happens to include a few complete files that were not on the SQ2 disk. So that increases the total amount of source a bit. I have checked other Sierra disks, and so far the SQ2 and KQ3 occurrences are the only ones I know of.

EvanAnderson 2y ago

Always do sector-level imaging of old disks, at minimum, for archiving. ("Flux"-level images taken with something like Greaseweazel are even better.)

hi-v-rocknroll 2y ago
Greaseweazle. Back in the day, there was Central Point's Copy II PC Deluxe Option Board, or the rarer Central Point's Copy II PC Enhanced Option Board able to copy physically-damaged-for-copy-protection media. For copy protection, NevrLock and CrackAid. I still encounter DOS malware and a lack of proper cracking in some poor quality releases on the interwebs. For archival purposes, it's generally better to buy several physical copies of a game and Greaseweazle it and end up with at least 1 complete and unspoiled version.
snvzz 2y ago
Precedence like: "analog" (multi-bit samples) flux > digital (1bit samples) flux > track > sector > block > files.

Exuma 2y ago

This game was such an insane strong part of my childhood that when I think about the present day many years later it feels like a dream. I try to imagine in my current life having the same sort of "connection" to a game and it just feels impossible. Everything around me feels like "just" a game, show, material object, whatever... but space quest 2,3,4 all feel like they are fundamentally part of my DNA, intertwined with it.

thyrox 2y ago
I feel that for music. During my teenage years I used to listen to the same songs over and over on my walkman. I still remember 99% lyrics to the whole albums. The music used to have such a strong connection. Nowadays there are 1000+ songs in my playlist I can't even recollect 20% lyrics nor there is a chance in hell that I would listen to every single song on the entire album let alone every single song by tthe same artist. It's like if I don't like the first 10 seconds, it's hide song and Spotify makes sure I never have to listen to that again. Even though some of my all time favorites are songs I hated at first but then there was no hide song button. Sorry I digress but yeah the connections you make in childhood are really something. I just hope it's my age and not the technology responsible for this and the youth of today feel the same connection too.
- caf 2y ago
  I still try to find time to sit down and listen to an album from start to finish - it's kind of like the musical equivalent of spending an hour in a gallery exhibition of a single artist's work.
the_af 2y ago
Same feelings but specifically about Space Quest II. I played SQ I way later in life, and SQ III didn't resonate as strongly with me. The rest were no longer EGA "text input" games either. SQ II brings back memories. I learned some of my English with it, too. I remember the feeling of satisfaction when I discovered I could "rub berries" on Roger Wilco ;)
- 2y ago

mrguyorama 2y ago

This exact situation actually happened all the time. The cutting room floor lists about 500, in various states between just a little accidental included code to most of it: https://tcrf.net/Category:Games_with_uncompiled_source_code https://tcrf.net/Category:Games_with_uncompiled_source_code

lance_ewing 2y ago
Thanks for the link. I hadn't previously visited that site. Very interesting. From a quick check, I can't see this particular Space Quest II disk's AGI interpreter uncompiled code mentioned in there yet. Do you agree? I have noticed that the same thing happened with a King's Quest III disk, in fact it looks like it may have happened around the same time as the Space Quest II occurrence.
- mrguyorama 2y ago
  https://tcrf.net/Space_Quest_II:_Vohaul%27s_Revenge https://tcrf.net/Space_Quest_II:_Vohaul%27s_Revenge This AGI code is mentioned at the bottom of the Space Quest II page. It's not technically "source code for the game" so it doesn't fit in the category I linked above.

Joel_Mckay 2y ago

This still happens at some firms every so often with source code and private signing key sets. The issue is usually management making an arbitrary call on who is part of the development pipeline. Thus, for a time some contractors and partners may get a backup of the build tree or temporary repository access (if you catch the "new" users.) It is harder than one would think to keep things confidential... Cleaning up after one of these leaks is another set of problems, but usually at that point it is better to jump ship. Best of luck, =)

Dwedit 2y ago

The Famicom version of Air Fortress has a ridiculously large amount of stuff unintentionally making it into the ROM. There is some uncompiled ASM code in there, some MS-DOS directory listings, some text strings from one of the EXEs used to build the game, and even more. The Japanese cartridge was 128+128KB large. Then they built the US NES version. Most of the 128K of graphics data was duplicate graphics, or unused. There was about 36KB of actual unique graphics. They shrunk the graphics down to 32KB by removing an image of a planet from one of the endings, and shipped it on a 128+32KB cartridge instead of a 128+128KB cartridge. Source: https://tcrf.net/Air_Fortress https://tcrf.net/Air_Fortress

boricj 2y ago

Back when release artifacts were hand crafted, these often contained leftovers that weren't meant to be shipped, like cut content [1] or debugging symbols [2]. When I stumbled upon debugging symbols hidden inside the data archive of the demo version of the video game I'm reverse-engineering, it was an unexpected but very helpful surprise. Nowadays with CICD, automated builds and other modern development practices it probably happens less often. [1] https://tcrf.net https://tcrf.net [2] https://www.retroreversing.com/games/symbols https://www.retroreversing.com/games/symbols

playingalong 2y ago
CICD pipelines can also work the opposite direction. No one looks into several thousands of console output unless there is some error. Also the tests are likely to pass even with excessive content in the final release package. So my intuition is rather opposite. It may happen more often. Or at least CICD makes it more likely to happen than manual building. There might be other factors too.
- boricj 2y ago
  I'd say manual building has a chance of a slip-up every time it is done, whereas automated building has a chance that it will slip-up every time it is executed.
protocolture 2y ago
I have a suspicion that good practices like CI/CD are not as common a feature of games development as one might suspect.

ajxs 2y ago

I've been doing a lot of reverse-engineering of synthesiser ROMs lately. The Yamaha DX9 ROM has some fragments of the firmware's symbol table embedded in the empty space left in the binary[0], along with a big block of 6303 code that was probably from whatever development system they used. It's a really amazing feeling when you stumble upon things like this! I'm such a nerd about these things that I feel like some kind of software-archaeologist, getting a small glimpse into the past. Finding this sent me down a really deep rabbit hole trying to find out more information about what development tools Yamaha might have used. I never discovered anything definitive, but reading the documentation on contemporary devtools gave me a real appreciation for modern workflows! 0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_a_DX7.html#leftover_data https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...

aa-jv 2y ago
I too like to reverse engineer synthesizer things, and I did it for the Yamaha A-samplers back in the day, producing a management tool that sped up the basic operations for Yamaha A-sampler disk users .. I used a BeBox to do a lot of raw i/o and analysis of raw disk sectors, as BeOS had some nice tools for filesystem hacking, and through this I managed to build a filesystem driver (for Windows) which worked well enough to get Yamaha's backing. If you ever get the motivation to reverse engineer the Yamaha ROM's for the A-samplers, lets get in touch. I have a lot of interest in this realm .. (EDIT: great work on the DX9/DX7 thing .. as an original user of both synths when they were released, this is really amusing ..)
- easyThrowaway 2y ago
  Oh god the repressed memories. I believe there was a SCSI thingy to do some basic sysex (or whatever format they were using) and presets save/load from 68K macintoshes?
  - aa-jv 2y ago
    For the A-samplers? There are a number of tools out there for manipulating the A-sampler data with a PC - I wrote one of them (DiskY) which makes filesystem management over SCSI with a Windows PC a lot smoother/faster than using the onboard OS, and there is also b.Zone, which is an editor that uses MIDI CC and Sysex to do editing. Together, they make the A-sampler .. almost .. usable. ;) I would love to dig further into the A-sampler ROM and figure out a few more of its secrets. I'd especially like to know the exact reason why the A-samplers SCSI subsystem is .. so .. darn .. slow .. so maybe there's a chance to dig into this at some point.

olliej 2y ago

Not sure this would have counted as “losing it to the public domain” - accidentally leaking the sources doesn’t negate copyright (presumably just trade secrets stuff by Iqbal)

lance_ewing 2y ago
Yeah, sorry, that was a poor choice of words on my part. I have reworded the sentence slightly to hopefully avoid the legal implication.
- olliej 2y ago
  ah yeah that's fair :D

johnyzee 2y ago

I love the change history comments. They show a high level of attention to detail and craftsmanship, at a time long before source control tools made this kind of thing obvious (and honestly, even after CVS/SVN/Git it still wasn't obvious to a lot of people). This post also makes me think of the famous 'No Silver Bullet' essay[1], which in 1986 predicted that software would more or less continue to be written they way it was then, by programmers, painstakingly, one instruction after the other. The similarity of the game engine code (along with the comments) in the OP, to something I might have written today, bears this out, I think, almost 40 years (!) later. [1] https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet

progbits 2y ago
To this day I see too many git commits like "fix" and "stuff".
- brokenmachine 2y ago
  No need for personal attacks.
  - cmplxconjugate 2y ago
    When I became a lead dev, one of the first issues I had was a 55 y/o dev who begrudgingly adopted git but consistently included commits like: “Monday morning commit”, “changed some things”, “commit”. He also refused to delete issue template examples and included it all with his own additions. In the entire time we worked together over a few years, he refused to adapt to the rest of the team.
    - sumtechguy 2y ago
      I have younger devs who do the same thing. Some people just do not want a process at all and do not play well with others.
      - 2y ago

pcwalton 2y ago

Looking through the repo, some of the assembler [1] looks odd: getShdwOfst: xor bh,bh mov bl,al mov di,bx shl di,1 shl di,1 shl d1,1 ... Why shift one bit at a time, like you would on a CPU like the 6502 with no multi-bit shift instructions? Was this hand-ported from some system without those? [1]: https://github.com/lanceewing/agi/blob/main/src/CMGRAPHX.ASM#L579 https://github.com/lanceewing/agi/blob/main/src/CMGRAPHX.ASM...

grumpyprole 2y ago
8088 did not have a barrel shifter, so multi-bit shifts would have been expensive and non-interruptible over multiple clocks. Perhaps game devs just avoided them out of habit.
ksherlock 2y ago
It was hand-written for a system without multi-bit shift instructions. 8086 shifts were 1 bit at a time (2 cycles for a register shift.) or using cl for the count (8 cycles + 4 cycles/bit for a register shift). constant multi-bit shifts were added in the 80186.

jesprenj 2y ago

> FormMaster duplication machine Anyone got any links with more info about this device?

lance_ewing 2y ago
I found it very difficult to find references to it online. There is a reference in the "Hackers" book by Steven Levy to Sierra On-Line having one (he uses the name "Form Master"), and former Sierra employees have mentioned it as well but with the two words run together as FormMaster. As I couldn't find much more, I'm not sure which form of spelling is correct. https://www.google.co.uk/books/edition/Hackers/JwKHDwAAQBAJ?hl=en&gbpv=1&dq=%22Form+Master%22++steven+levy&pg=PA405&printsec=frontcover https://www.google.co.uk/books/edition/Hackers/JwKHDwAAQBAJ?... There is a photograph in a September 1983 issue of a Japanese magazine called "LOGiN" of one of Sierra On-Line's disk copying machines but the article doesn't mention it by name. I wonder if it is the FormMaster/Form Master machine. https://archive.org/details/login-september-1983/LOGiN%20-%20September%201983/page/138/mode/2up https://archive.org/details/login-september-1983/LOGiN%20-%2... As an aside, that September 1983 magazine is the earliest clear reference to the development of King's Quest that I could find. It isn't mentioned by name but it is obvious that it is King's Quest that is being referred to.
- jesprenj 2y ago
  Thank you for the links! I kind of expected a machine with 10+ floppy slots (: I think I just wasn't really aware of the year this machine was produced.
  - lance_ewing 2y ago
    This video that Ken Williams put on Youtube a year or so back has got a short bit showing someone using the machine in the Sierra On-Line office: https://www.youtube.com/watch?v=oY_JbTYXVjg https://www.youtube.com/watch?v=oY_JbTYXVjg It is at about 1:47 into the video. It is the same machine shown in that LOGiN magazine article. This one appears to only support the 5 1/4 inch floppies, since I think the 3 1/2 inch disks weren't around at the time, so they must have got a newer machine later on. Ken's title for the video claims it was from 1983, but from my research, I think that a September 1982 date is more likely. The whole thing is an amazing video actually. Well worth watching. Incredible that it actually survived and is now preserved on Youtube.

accrual 2y ago

Kind of a tangent but I wonder how the serial numbers on the floppy disks were generated. They're clearly not sequential and the length differs between version 2.0D and 2.0F. SER# 312929011101963 (15 digits) SER# 3129289101202698 (16 digits) I wonder if they kept track of these in a CSV or something. Was the idea a customer could call in with their serial number and report a problem, which could be traced to a batch number or something? Anyway, just a curiosity I noticed.

lance_ewing 2y ago
I was also wondering about these numbers when putting the article together. The photo of the 2.0D disk is of my own personal copy of the game. I assume the number is unique to that disk, but I haven't spent any time at all researching that. I wonder if someone has.
- anyfoo 2y ago
  They might have intentionally obfuscated it, maybe to conceal how many disks they produced (https://en.wikipedia.org/wiki/German_tank_problem https://en.wikipedia.org/wiki/German_tank_problem ). Just XOR'ing the real serial number with a secret key that has exactly as many bits as the (padded) serial number is entirely sufficient, though my experience tells me that at that time, folks tended to do more complicated (and ironically, much less secure, not that it matters much here) things. Basic cryptography literacy wasn't as common then, as unencrypted and unauthenticated communication was the norm, even on most networks.
  - sumtechguy 2y ago
    > as unencrypted and unauthenticated communication was the norm, even on most networks That it worked at all was pretty amazing :)
EnigmaFlare 2y ago
I think you just nerdsniped me: 312929011101963 2.0D TFA 312929011100925 2.0D [1] 312928072902102 2.0D [2] 312928091704272 2.0D 5.25" [3] 3129289101202698 2.0F TFA 312922022211663 2.0F [4] 752923060122148 2.0F [5] 272929011600468 2.0F [6] 272929052600081 2.0F [7] The 16 digits seems like a freak. [1] https://archive.org/details/space-quest-ii-ms-dos-disk-1-of-2 https://archive.org/details/space-quest-ii-ms-dos-disk-1-of-... [2] https://www.mocagh.org/loadpage.php?getgame=sierra3pack-alt https://www.mocagh.org/loadpage.php?getgame=sierra3pack-alt [3] https://www.sierrachest.com/gfx/games/SQ2/box/03_m1.jpg https://www.sierrachest.com/gfx/games/SQ2/box/03_m1.jpg [4] https://www.mobygames.com/game/128/space-quest-ii-chapter-ii-vohauls-revenge/cover/group-6990/cover-14829/ https://www.mobygames.com/game/128/space-quest-ii-chapter-ii... [5] https://ia802300.us.archive.org/12/items/spacequest_ii_kfx/space_quest_ii_disk1.jpg https://ia802300.us.archive.org/12/items/spacequest_ii_kfx/s... [6] https://www.worthpoint.com/worthopedia/space-quest-ii-seirra-games-amiga-1777540316 https://www.worthpoint.com/worthopedia/space-quest-ii-seirra... [7] https://www.tradera.com/item/340851/630607300/space-quest-ii-chapter-2-vohaul-s-revenge-sierra-amiga https://www.tradera.com/item/340851/630607300/space-quest-ii...

lance_ewing 2y ago

> MWC was a C compiler from the Mark Williams company that was very popular in those days. Since publishing the article, I discovered some fragments of not yet linked compiled AGI interpreter obj files from the slack space on a KQ3 disk that mentions the MWC version number used, which was MWC86 V2.3.8. I also discovered a directory entry in the slack space of another sector on the same disk that has the name of the executable, MWC.EXE, the size and the timestamp: MWC.EXE 18420 23-Oct-1985 15:17:32

ngneer 2y ago
Great article. Great nostalgia. I wonder, do you still enjoy playing the games, now that you have thoroughly reverse engineered them? Also, what other insights have you gleaned? Also, have you read Not All Fairy Tales Have Happy Endings, by Ken Williams? https://kensbook.com/ https://kensbook.com/
- lance_ewing 2y ago
  Yeah, I do still enjoy them. I have been having to play through a few of them again recently in order to test my own AGI interpreter (https://agi.sierra.games https://agi.sierra.games). For example, I've recently been playing King's Quest IV on my phone using AGILE. I bought Ken's book a while back. As Ken has mentioned in reference to that book, his memories of things aren't as clear as they used to be. It's a long time ago. Still a great read though. I enjoyed it. I have also read "The Sierra Adventure" by Shawn Mills. That's another great book, in fact it has some quotes from various people that I hadn't seen anywhere else. I loved some of the inside story from Doug MacNeill in regards to the original King's Quest project. I've actually been working on my own book in relation to Sierra, AGI, the AGI games, the tools, the fan-made games... all things AGI I guess. Its probably still a few years away from release though. I keep getting distracted by things like writing the web based AGI interpreter.

anyfoo 2y ago

> These days a great modern equivalent is the excellent HxD Hex Editor written by Maël Hörz. If you are on macOS, check out Hex Fiend: https://hexfiend.com https://hexfiend.com I'd pay for it if it wasn't free (and BSD licensed, to boot) anyway.

snvzz 2y ago

With memory map, partial source code and reverse engineering tools, it should be possible to recreate the whole thing.

lance_ewing 2y ago
Yes, certainly, and any gaps could be filled in with what the NAGI project provides: https://github.com/sonneveld/nagi https://github.com/sonneveld/nagi. NAGI is a fan-made AGI interpreter created by Nick Sonneveld. He disassembled the Sierra's original AGI interpreter and then used that to create equivalent C source code. It is interesting to compare what he came up with to the actual original AGI interpreter source code from the SQ2 disk. Nick had to make up appropriate names for things, as he obviously didn't have the memory map, but it is easy to see the equivalent functions etc when you compare equivalent modules.

aa-jv 2y ago

Back in the 80's I worked on a "multimedia engine" very similar to AGI, which had the requirement of not using MS-DOS - the customers who would use this engine for their titles, simply didn't want to pay an MS-DOS license. The engine thus used BIOS calls, and I implemented enough basic disk i/o functionality that we could boot from the floppy, load the engine, and stream the bytecode straight from raw floppy sectors into the engine, which would then display vector graphics on either CGA or EGA monitors (the multi- in multimedia). This worked well enough for two titles to be released to a few tens of thousands of customers, who enjoyed them well enough. A days before the clients started shipping the titles they'd built with my engine, I went back to look at the floppy disks for the "master engine" series, which would be the last update to the engine itself, just to be sure - and by then I needed a raw disk copying routine for another project, so I took a close look at the prior results to see if there were any major issues. Sure enough, in the 'empty' sectors of the engine disks I'd produced, I'd managed to include things that looked suspiciously like a DOS FAT-based filesystem. This was because I'd simply reused the same floppy to produce beta versions of the engine disks, and someone had taken one of my old master beta disks and used it 'temporarily', to copy some files for themselves, on MS-DOS machines. Lucky I caught it - we really didn't need to include a resignation letter in the empty spaces of the multimedia titles. Anyway, this story brought back fond memories of making a multimedia engine that didn't use MS-DOS .. and also, 40 years later, reminded me to always check the edge cases before you ship a master/gold release to customers who will ship it to tens of thousands of people .. I suppose the modern equivalent is to clean up the git repo before shipping, or have a procedure for vetting commits, lol. Okay, I gotta do that on some of my juniors' projects, brb ..

bluehex 2y ago

Once an Android app for the startup I was working on had a suspiciously large apk size. One of our engineers dug in and realized that our packaging script copied the .git directory in with the static files. All it took to see the source was to cd into the unzipped apk directory and do a "git reset --hard ."

bobmcnamara 2y ago

Medtronic did this on one of their heart monitor base stations.