'Round these parts, we write about old Sierra games and their rich inner lives. As I'm often at pains to point out, this is thanks to the brilliant script decompiler written by Phil Fortier for SCI Companion. Released in 2015, it was the first and only decompiler for SCI games — at least as far as the world is concerned. And now lo, for there is another.

Last year, I had a vision and began writing my own decompiler — a mass decompiler — with the goal of wiring it up to my script tools for annotations. Annotations are comments and symbols that transform decompiled code from something you can read into something you want to. That's how I learned the scripts in the first place: by writing automatic annotators and reading the results. I wanted to share this with the community* but the particulars of SCI Companion made it a thorny problem. The decompiler I envisioned could unlock the solution, but I didn't know how to write it. I wasn't sure I ever would. The only certainty was that win or lose, it would take a while.

In the meantime, I slowly obtained as many games and variants as I could. What's a mass decompiler without the masses? There are only about sixty games, but they were heavily revised, ported, and translated. Software scavenger hunts are fun and this one as been successful. I've now amassed over three hundred versions of SCI games from 1988 through 1996. While that's not every single one, you have my permission to say it is.

Today, with one command and a couple of cores, I've decompiled and annotated every Sierra SCI game, and practically every version, and dumped the results on github for everyone to enjoy. Gentlemen... BEHOLD!

https://github.com/sluicebox/sci-scripts

You're still here?? Look, you're welcome to stay, but I just linked to half a gig of way more interesting text. I even got out the big font! (When do we ever get out the big font?) In fact, I'm counting on the crowd thinning out so I can indulge in some inside baseball.

I just want to kick back and tell the story of how this came to be. We'll see where Sierra's script language came from, what reverse engineers have done with it, and why I'm cheerfully undermining the blog with today's release. I've got a lot of meta-rules to break. You go outside and play with your scripts!

When I talk about Sierra code, I break it into three categories:

• Game Scripts: This is the unique code that defines a game. Every room in every game gets its own script. You care about this if you want to solve murder mysteries or find easter eggs. This is probably the only code you care about.

• System Scripts: These are the supporting scripts that appear in every game. They form a common runtime library that the games are built on. You'll find generic classes for rooms and actors and icon bars, and utility functions for things like message boxes and math. Even the game loop lives here. As you get deeper into SCI mechanics, you care more about these scripts, although perhaps reluctantly.

• The Interpreter: This is the program that runs the show; you know it as SIERRA.EXE or SCIV.EXE. The interpreter was written in C and a lot of assembly, and then rewritten in C++ and slightly less assembly. It loads drivers, decodes resources, and runs the first game script in a virtual machine. It's the "VM" in ScummVM. From there, it just follows orders until a script sets the quit flag or it famously crashes. It also contains over a hundred kernel functions that scripts call to do work. You care about the interpreter if you want to solve bonus mysteries or find timebombs. Or if you're crazy enough to replace the whole thing.

Today is all about the scripts. Let's see what one looks like! Remember that Sierra programmers wrote these in their proprietary language (also called Script) and compiled them with their in-house compiler to SCI bytecode. Those are the bytes that shipped with the games. Decompiling can never recover the original text. Symbols are lost. Control flow is ambiguous. Compilers have bugs. Optimizations ruin everything.

But God is alive, and Magic is afoot.

(instance mints of View
	(method (doVerb param1)
		(switch param1
			(5
				(if (< global153 3)
					(if (not (global0 has: 23))
						(global2 setScript: takeMintScr)
					else
						(global91 say: noun param1 35)
					)
				else
					(global91 say: 7 5 32)
				)
			)
			(1
				(if (< global153 3)
					(global91 say: noun param1 33)
				else
					(global91 say: noun param1 32)
				)
			)
			(else
				(super doVerb: param1 &rest)
			)
		)
	)
)

Thanks, decompiler! Now let's see it with annotations.

(instance mints of View
	(method (doVerb theVerb)
		(switch theVerb
			(5 ; Do
				(if (< gAct 3)
					(if (not (gEgo has: 23)) ; mint
						(gCurRoom setScript: takeMintScr)
					else
						(gMessager say: noun theVerb 35) ; "Alexander already has a mint. He'd prefer to leave some for the other customers."
					)
				else
					(gMessager say: 7 5 32) ; "The mint dish is empty."
				)
			)
			(1 ; Look
				(if (< gAct 3)
					(gMessager say: noun theVerb 33) ; "An elegant little glass dish decorates the counter top."
				else
					(gMessager say: noun theVerb 32) ; "The candy dish is empty."
				)
			)
			(else
				(super doVerb: theVerb &rest)
			)
		)
	)
)

This is the code that runs when you click the mint dish in King's Quest VI. And thanks to the annotations, you know what it does. Each comment was generated by an annotator. The message annotator is usually the most helpful. Without the comments, you're just staring at numbers. The global variables were renamed by two annotators: one that handles system globals and another that knows KQ6 details. As you can see in the first version, some symbols come straight from the game. Sierra generously included them for debugging. Combine those names with annotations and you get highly readable code.

Annotations aside, scope out that language. SCI Script is often described as LISP-like, but that's just a curvy stereotype. It looks like LISP because of parenthesis and prefix notation, but if that's all it takes... well please tell that to a LISP programmer. They deserve it. This language doesn't even have LISts! The syntax does make it easy to parse, but I haven't seen anyone take advantage of that; except compiler authors and me. So join the rest of the world and forget about LISP. The real inspiration for SCI Script is Smalltalk.

BYTE Magazine, August 1981

Jeff Stephenson is the father of SCI — he wrote the language, the compiler, and the bytecode interpreter. Two years ago, the Video Game Newsroom Time Machine scored a two hour interview about his life and career, and he recounted his influences:

Somewhere in there, BYTE Magazine came out with their Smalltalk issue and I discovered object oriented programming, and you know, I read that issue cover to cover I think, and sometimes multiple times maybe. [...]

In any case I started learning about object oriented programming and it just really resonated with me. And then suddenly we were able to start displaying more than 16 colors on monitors, and Ken wanted of course to take advantage of that, but AGI was written in such a way that it was going to take a major rework of the entire game engine and language and everything in order to support 256 colors. And so that's when I pitched Ken on SCI and basically saying okay let's go with a whole new language, we're going to have to rewrite this thing anyway, let's make things better. And he was pretty dubious, but I guess he figured since we were having to rewrite everything anyway, he might as well let me do it.

BYTE Magazine dedicated one issue to a language each year. In August 1981, that was Smalltalk. Reading through, I was first struck by the magazine cover. Oh... it has a back story. It's a charming retort to the Pascal cover from 1978 that painted Smalltalk as aloof and inaccessible. I love it; did that allegorical slight really fester at Xerox PARC for three years? Of course it did! They're nerds! And their response? A textbook clapback from the Yacht Rock era.

Reading further, I was surprised by how much terminology made its way into SCI: selectors, method dictionaries, temporary variables, receivers — they're all in those pages. Even SCI's ubiquitous doit method is a Smalltalk convention. The influence is clear.

Jeff also mentioned Objective C, and I'm sure that contributed too, but I refused to research it. Sorry, it's a personal prejudice. That language is just so damned ugly that, like a filthy freakin' opossum, it triggers my fight-or-flight. And I'm done breaking laptops! So we're sticking with the Smalltalk narrative. And breaking meta-rules instead.

My one exposure to Smalltalk was in school. The assignment was to implement the Enigma cipher in a language you didn't know. For extra credit, you could write a program to crack it. Excuse me? Breaking Nazi encryption is optional?? Not in my family! We really need Grandpa Benshoof to survive D-Day! Smalltalk did the trick and I remember it fondly. My fascist decoder worked, but as the messages got longer it got slower. Really slow. Even on the expensive machines. Oh well, I wasn't getting graded on speed. Later, the department chair left a handwritten note about my impressive use of CPU cycles. The polite implication was that I would have lost us the war for want of a hash table.

Speaking of impressions! I'm impressed with the shelf life on that Smalltalk issue. SCI was developed in 1988 and yet these technical articles from 1981 were still relevant. In a way, they're timeless. Just not timely.

When Can I Buy It?

There are currently no personal computer implementations for the Smalltalk-80 language. Because of this, I'm sure we'll be criticized by some for introducing the language too early and frustrating our readers. Nevertheless, I feel that the time to begin exposing people to object-oriented language is now. Only by challenging and enticing the personal computer community can we stimulate the industry to create the machines we all dream of.

Smalltalk fans had the programming language, but not the software. SCI fans had the opposite problem. They had years of games, and years to reverse engineer them, but the source language was a secret. How do you decompile that? What syntax do you use? If SCI Script was internal to Sierra, and the games only contain bytecode, then how do we know what the language looks like at all?

We didn't! Not exactly. And not for a long time. But all that's over. Now we know everything.

To see how far we've come, take a look at this snapshot of Lance Ewing's SCI Syntax page from 2011. Lance thoroughly documented the publicly available clues to establish what was known and could be inferred about the language. Here In The Future, we have things a bit easier. Here's the original language spec by Jeff Stephenson himself. This document is a monument to getting things right the first time. Throughout SCI's successful nine year run, the language never changed. The details that drifted are unspeakably dull. The games from 1988 are radically different than 1996, but underneath it's all the same bytecode from the same language. This was a design goal from the start.

The whole goal was flexibility in programming, and trying to push as much of the programming capabilities up to the game developer level rather than having them have to go into the engine as we could, and decoupling graphics and so forth to the point where you could keep extending the graphical capabilities. Because at that point it was pretty clear we're going to be getting more and more changes in hardware and everything.

To a reverse engineer, this sounds like great news. It sounds like if you want to work with SCI scripts, you can do so universally. And that's true! Kinda? But also not really, because even though the bytecode is consistent, everything else is all over the map.

When I joined the ScummVM team, Martin Kiewitz told me that the hardest part of SCI was all the versions. Now that ScummVM runs even more of them, I joke that the entire codebase is version checks. The SciVersion code is a window into the madness:

/**
 * SCI versions
 * For more information, check here:
 * https://wiki.scummvm.org/index.php/Sierra_Game_Versions#SCI_Games
 */
enum SciVersion {
	SCI_VERSION_NONE,
	SCI_VERSION_0_EARLY, // KQ4 early, LSL2 early, XMAS card 1988
	SCI_VERSION_0_LATE, // KQ4, LSL2, LSL3, SQ3 etc
	SCI_VERSION_01, // KQ1 and multilingual games (S.old.*)
	SCI_VERSION_1_EGA_ONLY, // SCI 1 EGA with parser (i.e. QFG2 only)
	SCI_VERSION_1_EARLY, // KQ5 floppy, SQ4 floppy, XMAS card 1990, Fairy tales, Jones floppy
	SCI_VERSION_1_MIDDLE, // LSL1, Jones CD, LSL3 & SQ3 multilingual Amiga
	SCI_VERSION_1_LATE, // Dr. Brain 1, EcoQuest 1, Longbow, PQ3, SQ1, LSL5, KQ5 CD
	SCI_VERSION_1_1, // Dr. Brain 2, EcoQuest 1 CD, EcoQuest 2, KQ6, QFG3, SQ4CD, XMAS 1992 and many more
	SCI_VERSION_2, // GK1, PQ4 floppy, QFG4 floppy
	SCI_VERSION_2_1_EARLY, // GK2 demo, KQ7 1.4/1.51, LSL6 hires, PQ4CD, QFG4CD
	SCI_VERSION_2_1_MIDDLE, // GK2, Hoyle 5, KQ7 2.00b, MUMG Deluxe, Phantasmagoria 1, PQ:SWAT, Shivers 1, SQ6, Torin
	SCI_VERSION_2_1_LATE, // Demos and Mac versions of LSL7, Lighthouse, RAMA
	SCI_VERSION_3 // LSL7, Lighthouse, RAMA, Phantasmagoria 2, interactive Lighthouse demos
};

Depending on your perspective, thirteen versions could be a little, could be a lot. But these aren't real versions; they're high level buckets invented by reverse engineers. Games don't cleanly fall into them. Sierra typically had three or four games in various stages of development. Meanwhile, the interpreter evolved at its own pace. Think of each release as a fork with who knows what fixes and features backported in or taken out or tweaked. Resource formats, container formats, and compression formats each change over time. So apply those fuzzy versions to every layer. And then multiply the combinations across all the patches and ports.

If you want to write SCI software that works with more than a handful of games then these are your problems to deal with.

One of these is a typo that's also a real version

God help you if you turn to SCI's version numbers. Assuming Sierra didn't typo the floppy labels, or leave the placeholder x.yy.zzz, or release a non-release version, or get the odometer stuck on 2.100.002, then they're best treated as based on a true story. Versions that start with "L.rry" aren't Leisure Suit Larry games; they're whatever Larry Scott compiled that day. Consider that ScummVM is the most comprehensive SCI software and it doesn't even attempt to look at these version numbers.

Instead, each piece is felt out at runtime with careful heuristics, deductive inference, and deep vats of hard-coded exceptions. And then someone finds a German Amiga version full of anachronisms and blows it all up.

Believe it or not, I'm not complaining! If these things were easy then there wouldn't be any left for me.

But I do want to convince you that Universal SCI is hard and the versions are a heavy tax. We're going to talk about the reverse engineers who took on the scripts, and I want you to know what they were getting into, and appreciate how far they got.

Brian Provinciano is an SCI pioneer. In 1999 he wrote SCI Graphics Studio and set a dangerous precedent with a resource editor for Windows. This grew into SCI Studio, the first program that allowed fans to create their own EGA games. By 2002 it was out of beta and included a script editor, script compiler, and a full template game. SCI Studio was a legitimate Integrated Development Environment — the era of fan games had begun.

What an exciting time that must have been. And so much work! Sierra's Script was still a secret, so to write a compiler you first had to reinvent the language. At least there were clues to what it should look like. And the bytecode wasn't a total mystery; the names of opcodes and kernel functions were included with games for debugging. Still — sounds hard! Brian took all this and developed his own script syntax with the necessary features that captured the spirit of the original, and then wrote a compiler for it. Sierra's 1980s executables happily ran the results. Nowadays we call this SCI Studio Syntax, but at the time it was the only game in town.

Okay so you have the world's first third party SCI compiler. Now what? Well, Sierra's game programmers didn't start from scratch, they had all those system scripts we discussed earlier. So I guess you need those scripts! But if all you have is bytecode...

I am now working on decompiling Leisure Suit Larry 2 to create the template game. It is TONS of work because my program can only disassemble, not decompile. I am having to do it all by hand. In order to write a decompiler, I would basically have to mimic the interpreter. It would be a lot of work, more work than it's worth.

Brian later said that he spent weeks on this "long and grueling task" and manually decompiled 50-60 scripts and over 130 classes from several games. If you've never decompiled assembly code by hand then it's hard to explain this sacrifice. And I won't try, because you shouldn't be punished for good life choices. But I will say that once it's done it's done, and is less work than writing a decompiler.

Brian Provinciano with SCI Studio 3 on TechTV, March 7 2003

March 2003 was a big month. Brian released SCI Studio 3 and flew from Canada to San Francisco to appear on the TechTV show Call For Help to present it with Sierra fan Aaron Wester. Afterwards, he... sorry can we back up for a sec?

Let me get this straight... you're saying that in 2003... a real television studio recorded a real show about SCI fan software? And this was broadcast across real satellites to real hotel rooms all over the world? And you want me to believe that U.S. Customs believed all this?? No. Absolutely not! As an SCI nerd in 2023, I can't accept any of this. Nope nope nope. The Wayback Machine must have crawled an alternate timeline*.

That same month, Brian announced he was working on supporting VGA games, and had even begun writing a script decompiler. Over the next two years he posted status updates. He even posted entire scripts he'd decompiled from a variety of games.

And then a hellbeast ate him.

In 2006 Brian retired from SCI and posted his remaining code, but without mentioning the decompiler. He worked on SCI Studio for many years, some while in school, and set the bar for all future tools. His goal was for people to make games and they did and they were weird and that is good. ScummVM happily supports fan games so you can still run them today, and probably forever.

As you can imagine, this left some people disappointed. Not me though. I just found out! Oh man... so here I am, thinking I'm ushering in the second decompiling, finish the dang thing, do the research for the announcement, and only then find out I've been bumped down to third.

I'm thrilled that the SCI decompiler story is a trilogy with a lost first volume. Brian's samples and posts are now highly relevant to my interests, so I read them all. Here's the executive summary:

Brian's decompiler was a standalone program that targeted the full range of SCI versions. The hardest part of decompiling is analyzing control flow, and when the decompiler couldn't figure that out, it generated code with goto statements. That's also what professional programs like IDA Pro and Ghidra do. Goto code isn't very readable, but the alternative is all or nothing. An impressive amount of the samples he posted were right. At one point he said that he was 90% done, but I said the same thing — right before the other 90%. Brian's decompiler was the real deal and on track to do everything.

Phil Fortier is our SCI savior. In 2007 he released SCI Companion 2 to replace SCI Studio. Phil is an independent game developer and one of his motivations was to make his own game. SCI Companion supported Brian's script syntax and the existing fan games. Like SCI Studio, it was limited to EGA games. After a few updates, things quieted down, and then got real quiet.

Eight years later Phil returned with SCI Companion 3. And it had everything! There was support for VGA games, a sound editor, and... AND... an end to the twelve year thirst: the world finally had a script decompiler.

When I describe SCI reverse engineering, I stress that not only have we been graced with a latter-day decompiler — against all odds — but an excellent one. It works so well that there's little to talk about except its limitations.

The decompiler isn't perfect, but typically it can decompile about 95 to 99 percent of a game into source code. Success is typically on a function-by-function basis. Luckily, if an error or unexpected condition occurs anywhere during the decompilation of a function, we can have the entire function fallback to assembly. This at least retains the ability to recompile code correctly, and also retains some symbol information.

Compare this approach to Brian's goto statements. If just one thing goes wrong then SCI Companion fails a function and produces no code. The larger the function, the more likely it fails. But gotos aren't an option anymore, and for a good reason.

Phil created a new script syntax based on the original and named it Sierra Script. It's so close to Sierra's that I can't remember the differences. I think Phil's is stricter but my parsers can't tell the difference so neither can I. Decompiled scripts look like the real thing, and that's great, and that means no gotos — also great.

That leaves the bugs where the decompiler silently produces incorrect code. I'm familiar with these because my decompiler stumbled on the same scripts, just louder. Causes include: unexpected optimizations, nonsensical source scripts, and impossible instructions due to compiler bugs. But these instances are so rare that you can pretend they don't exist. So sure, trust but verify, but in practice don't worry about it.

The decompiler's biggest limitations aren't in its algorithms, but its ergonomics. It's a complex component in a huge Windows GUI whose primary purpose is to let fans make games. In order to even find the bytecode it has to survive the SCI version nightmare. Phil borrowed the version logic from ScummVM, so it supports most, but he understandably skipped some of the more annoying bits. Some versions fall between these cracks. And the SCI3 script format from the last four games is unsupported. And there's no concept of multiple CDs or Macintosh. If it's outside the mainstream then it's unavailable to the decompiler.

These are all reasonable priorities for a program that makes fan games. No fan was going to make a seven disc Fantasmagoria. If you want to add support for these extras, you'll have to touch a lot of unfun C++ before you even get to the decompiler. It's been open source for many years so nothing has stopped you, but that brings us to the real limitation...

SCI Companion is a Microsoft Foundation Classes Win32 C++ codebase that no one wants to work on*. Oh, I get it! Long ago I wrote some of my favorite programs in that stuff, and I still love running them today, but I can't bring myself to look at the code again.

There are signs of life. The Cat has a fork with some fixes, and Laurence Myers recently added automatic builds. That's exciting, but let's not quibble over commits: Phil finished a long time ago and no one else has touched the decompiler. Including me! As you'll see, I don't even know how it works. Maybe today's release will spark some interest. For now, the decompiler is done, and that's okay.

With a bunch more work, it should be possible to have the decompiler 100% effective (except for corrupted scripts, of course) — but I decided that the effort vs reward wasn't worth it beyond this point, especially given the fallback to assembly.

Phil split SCI reverse engineering into two eras: Before Companion and After Decompiler. Reverse engineering generates countless unknowns that are too impractical to investigate. There's a threshold there, and it's determined by the tools. SCI Companion's decompiler sent that threshold plummeting. I'm hoping that today's release finishes the job.

Think of all the SCI details that were too difficult to figure out before 2015. Turn all the bytecode into high quality text, and people like us can knock them out with one grep. It's fun! It has to be — it's cheating!

But you can have too much fun, so you have to be careful. Or else you could end up with a hobby.

Here's where I enter the story:

It's important to have goals, or so I'm told by several reputable hashtags. In the 90s mine were to solve The Colonel's Bequest, and more importantly, The Dagger of Amon Ra. It was clear that merely playing them wasn't going to cut it. As time passed I would occasionally check in on the Sierra scene and when SCI Viewer dropped so did my hopes.

SCI Viewer revealed that there was indeed a lot more to these cases but that the answers were all in the scripts. At the time, this meant reams of intolerably low level disassembly text. This wouldn't do for the high level answers I sought. "I'll come back later." In 2015 it was later, and lo, for Phil Fortier released from the heavens SCI Companion 3.0 with an honest to goodness script decompiler. It had been twenty years but not only could my investigation now proceed, it had to.

I don't know exactly when I discovered SCI Companion 3, but I remember feeling lucky. It must have been pretty new, because it crashed so much that I couldn't use it. Before giving up, I tried compiling the latest code — the last refuge of a scoundrel. It wouldn't build, some MFC or SDK thing, the usual strife. "Just when I think I'm out." After some begrudging hacks, it built. SCI Companion was stable as a table and I've built from source ever since. More luck! The miracle I'd been waiting for hinged on latent knowledge of the Windows API. I bore witness and became a decompiler disciple.

I quickly hit my limits with the scripts. Remember that first example? It's great by decompiler standards, but it's still not good enough for solving complex things like a Sleuth-O-Meter. It was taking too long to get my bearings in the game code and I didn't even know the language. I didn't know anything! But I did know the messages that appear in the games.

SCI Viewer had command line tools that could dump resources and export game messages as XML. Script those up, write some regular expressions to parse out message tuples, and baby you got a stew going: one ham-fisted message annotator. No knowledge of SCI internals required. I had my foothold! Now I could get around in these message-heavy games and build from there.

As my tools grew they set off a cycle. A typical pattern: first my parser trips on something, then I investigate and crash ScummVM, then I investigate with ScummVM's debugger and crash that, and finally it turns out that none of this ever worked and the game has been crashing since 1990. By the time it was over I'd have fixed my bug, the ScummVM bug, the debugger, and written a script patch in bytecode to fix the game. Bonus points if there was a ten year old ticket in the bug tracker. Then my parsers would scan for similar anomalies across other games and it would start all over.

I didn't mean to build a bug hunting machine, I just wrote some parsers that weren't very bright, and things got out of hand.

As I learned more, I wrote proper parsers, and the annotators flourished. I was closing a lot of ScummVM tickets thanks to my decompiled scripts. But as you'll recall, SCI Companion doesn't support everything. If I couldn't decompile, then I couldn't do much. The open tickets were starting to hint at which games and versions were outside of SCI Companion's purview. So I wrote some programs to bring them into the fold. The first one converted Macintosh scripts to DOS with a bunch of byte-swapping. The second program downgraded SCI3 scripts to SCI2, which is so insane that I named it Conversion Therapy. Now I could decompile and annotate everything, and without touching SCI Companion's code. The tickets continued to close and the writing queue grew.

Eventually I had a big problem: the annotated scripts had gotten too good to keep to myself. But they weren't good enough to release. Even if they were, they weren't the products of a program, but a process. Then I realized just how many imperfections I was working around, reverting, or tolerating. Hell's horses! I'd outgrown the SCI Companion decompiler.

Obviously the problem with this pipeline is that it runs through an unmaintained Windows GUI. Obviously the solution is to replace it. Obviously there are problems with that solution:

1. It rather involves writing a decompiler
2. Phil's is a tough act to follow!

There was hope. Phil left a map: a four part blog series on decompiling SCI — a masterclass in accessible technical writing. By now I've read a lot of decompiler literature and Phil's articles are still the best. If you want to decompile any kind of bytecode, start there.

And so last year I used Phil's guide and started writing a decompiler, failed, tried again this year, and succeeded. I later learned that Phil also shelved his first attempt. I'd love to talk about how mine works, but we'll save that for another day. I owe us a full write-up about what it takes to get to one hundred percent.

Yes, that's right: One Hundred Percent. Brian's decompiler produced goto statements. Phil's fell back to assembly. I didn't want to do either, so mine fully decompiles every function in every Sierra script. No need to write fallback code if you never fail!

	Total	Solved
Games	323	323	100%
Scripts	66,256	66,256	100%
Functions	831,176	831,176	100%
Loop Functions	47,546	47,546	100%
Loops	68,311	68,311	100%

You crave caveats. Well, there could be silent failures I don't know about. It seems like there must be some in all that text. Find 'em and I'll fix 'em. But the last bug affected only one function, and it was from a bug in Sierra's compiler, and that was a while ago. So I don't know what to think. As I mentioned, there are also a few versions I don't have. Maybe you do? It's mostly a handful of localized games. I don't expect any exciting scripts, but who knows? Help me find out!

SCI Companion will always be the best way to view scripts, so I've packaged mine to be compatible; you just need the game. You can try compiling the scripts, but you're on your own there. It might work! Just remember that the version detection in SCI Companion is incomplete, so it can misinterpret accurate symbols like kernel functions. Maybe you'll fix it?

I wish my work produced fixes for SCI Companion, but the projects didn't overlap. For one thing, I didn't use C++, because #selfcare. Bigger obstacle: I don't really know how the other decompiler works. Phil's articles are so good that I didn't need the code to design my own. The two decompilers must be pretty different though, because I came up with my algorithms by staring at a mess of graphs until blacking out. (Dramatization! ...I Think!)

Speaking of drama! ...There's one more thing.

Original Sierra source code. That subject has been off limits, but thanks to recent events I can relax that rule. If there's anything good about performance art, it's the unexpected. I consider this performance art, and I didn't expect to be presented with a Sierra cache on deep background. There's a good story there, but it's not mine to tell. The important thing, I told myself, is that it's found its way into enough hands that it won't get lost — and won't stay underground forever.

On Christmas Day, Jason Scott discreetly posted the original scripts for nine Sierra games to the Internet Archive. They're also on github. I'm happy (and relieved) that we can discuss these publicly, but I have to tell you... as exciting as real source code is, annotated decompiled scripts are so much more useful. But you're hard to convince. So I wrote one more annotator...

My decompiled scripts include Sierra's symbols — even ones not publicly available! The annotator extracts the names of functions and variables from my cache of original scripts and matches them to decompiled scripts. Every game benefits because I also have original system scripts. Of course, if one or two games whose scripts haven't been posted were to have all of their symbols, that could raise some questions. Not to worry! This blog doesn't have comments.

Speaking of comments! Let's end with one of Jeff's, the gentleman who got us into this mess. I think it will resonate with every ScummVM developer, and anyone else who plays computer games as an adult by making graphs full of assembly.

While I did play some of the games just to see how they worked, and actually I probably played Space Quest more just because it was such a gas, but I was pretty unaware of the actual game involved. So my involvement was really at doing the tools that allowed the games to be built, and I encountered the games sort of off and on, but eh they're all just the animated things that are stories, they're not the fun part.

Deoptimized basic blocks in a control flow graph

**JOB DONE** — SCI is decompiled, I hope you have fun. Because I broke a lot of rules today. And I wrote a decompiler!

And I gave away the farm!

See, I've still got this writing queue of Sierra discoveries here, and while nothing has ever stopped you from finding them yourself... it just got a heck of a lot easier! So go ahead and scoop me. You can even do your own write-ups! In fact, I'd love to read them. All I ask is that you do a good job and don't skimp on the NewsRadio references. We'll call it outsourcing and they'll call me genius.

Otherwise I'll keep getting to them in my own sweet time. Or faster! — if you can just get me back on the dole...