Standalone executables

“Can’t I export my game as a plain old executable, and not bother with an interpreter?”

I’ve been looking all over for information related to this question—specifically as it applies to Inform games, because a solution for Inform games would be a solution for my situation.

Mostly I’ve found people saying “No, this actually is not a good idea,” which, I mean, okay. Let’s pretend it is, though.

I’ve also found people saying “Instead, you should write a script that launches the interpreter and then loads the game,” which I agree is pretty elegant and perhaps more desirable in some situations, but of course it is not the exact thing I am looking for.

In some places I have heard murmurs that sticking game and interpreter together in this way might violate a license, or a copyright, but I have not been able to confirm this.

And once in a while I’ve found someone saying “Sure, yeah, here’s a tool that will make your file into an executable, no problem”—but then it turns out that the link is dead, and all I’m left with are my dashed hopes.

Most of what I’ve found in my research is from like five years ago, though. Have any new facts emerged since then?

AFAIK, if you put Frotz or Glulx/Git in the same folder as the game file and rename it so that you have, say, MyGame.blorb and MyGame.exe (.exe being the interpreter), opening the interpreter will automatically load the game file. I doubt this would violate anything.

Not quite what you want, but off the top of my head…

In the in-development installers for Kerkerkruip we take the launcher script approach. I can’t really see any downsides to it, except I guess that it isn’t portable. If you specifically want a single portable .exe it probably is possible. I’d look for a generic bundling method. One I’ve seen (but haven’t used) is this:

There’s L. Ross Raszewski’s BundleMonkey (I have no personal experience using it, though).

Just for fun, I tried out the Nullsoft Scriptable Install System which he recommends, and I was able to cobble something together (for Windows) in a short amount of time:

  1. Download and install NSIS from (I went with the current version 3.0a1)
  2. Download and unzip the interpreter you want to distribute (e.g., Windows Frotz, .zip version).
  3. Put the unzipped interpreter, your game file and (optionally) an icon in a directory.
  4. Put the installer script (see code below or just take the attached .txt file and rename it to .nsi) into that directory, too.
  5. Of course, modify the script to substitute the right filenames for your project.
  6. Compile the installer script with the NSIS compiler (right-click the .nsi file in Windows Explorer and choose “Compile NSIS Script” from the context menu).

That’s it. The compiler should have produced a single .exe file, which, when the end-user executes it, will silently unpack its contents into the user’s temp directory and start the interpreter with the game file already loaded up. (edited post to add: Despite the name, the “install system” will not actually install anything on the user’s computer in this case. After the user quits the interpreter, the unpacked files will automatically be cleared from the temp directory.)

I made a “Curses.exe” as an example, using Graham Nelson’s classic Curses, Windows Frotz and the favicon from this very forum. Cf. the attached file - unfortunately the forum doesn’t allow attachments with an .exe extension, so I zipped it. The forum also doesn’t like the .nsi extension of the attached script, so I changed that to .txt before uploading.

Here’s the script which I adapted from one I found on the NSIS wiki:

[code]; NULLsoft Scriptable Install System
; use this to bundle an interpreter and an IF game
; based on:
; “make a REBOL Script executable”
; provided by
; downloaded from
; crudely adapted for IF purposes by StJohnLimbo

; Name of the installer (don’t really care here because of silent below)
Name “Curses”

; Don’t want a window, just unpack files and execute
SilentInstall silent

; Set a name for the resulting executable
OutFile “Curses.exe”

; Set an icon (optional)
Icon “IF.ico”

; The stuff to install
Section “”
; Set output path to a temporary directory.

; put the required files here
File /r WindowsFrotz ; add the interpreter directory and its contents recursively
File “curses.z5” ; IF game file

; Execute and wait for the session to end
ExecWait ‘"$PLUGINSDIR\WindowsFrotz\Frotz.exe" “$PLUGINSDIR\curses.z5”’

; Set working directory to something else
; If it’s not set, $PLUGINSDIR will not be deleted
SetOutPath $TEMP
SectionEnd[/code] (948 KB)
curses-test.txt (1.11 KB)

Holy cow, that is slick! Thanks very much.

This is a really neat trick too.

Thanks you guys!

Is a game bundled like this going to work on a Mac? I’m guessing not. Not that I have a problem with that, but might that be the reason people try to shun away from a single executable?

This is essentially what people do when they release a version of their game specifically for iOS.

It’s a perfectly good idea. I just never remember the answer because people usually talk about producing a Windows stand-alone interpreter.

(Or, yes, an iOS one. I know about that.)

It’s not a bad idea by itself but at some point people grew frustrated because when someone did this they usually released the Windows exe but not the plain story file. They had the best of intentions, wanting to make it easier to play their game without needing to install a separate interpreter, but they forgot that not everyone were using Windows.

Yes, some TADS games are trapped in their DOS-only wrapping now. A shame.

I’m not aware of any, at least not in the Archive. It’s pretty easy to get the TADS game back out in the DOS case, as the game data is simply appended to the executable. With a hex editor you can strip off the DOS executable to leave behind just the game file.

I know nothing about HEX editors. :frowning:

I was sure I’d seen TADS games trapped in their dos-only form, but I can’t find them right now. I may have been mistaken, or I may have already found their TADS counterpart. Apologies.

EDIT - This one’s MAC only. Might have been what I was thinking about.

EDIT 2 - Here’s a DOS-only one.

EDIT 3 - Mac/DOS…

And I think these might be it.

Mind you, I know it’s not much and these are hardly stellar games. Still.

EDIT 4 - There was an Andy Phillips game (Enemies, maybe?) where the latest version was available only on DOS form, and the version for ZMachine was earlier. But that one was simple enough to extract, there are tools that even a layman like me could use and it was simple enough to then upload the extracted file to the archive and link to it on IFDB.

I’ll see if the TADS game can be extracted from these.

For a MacOS 6/7 interpreter binary, the game data is almost certainly either stored as the application’s data fork (Infocom’s Mac interpreter did this), or stored as one of the application’s resources (my MaxZip/MaxTADS did this).

In the latter case, use ResEdit or DeRez to extract the file. In the former case, use cat.

When I put together MaxZip/MaxTADS, I made sure that the bundled game application had a menu item “Export raw game file”. Not sure anybody ever used it, but it’s the polite thing to do, for exactly this reason.

I have a suggestion. Why don’t we simply declare Windows against the law? It is a malware, after all.

We used to call that “trolling”, in simpler times.

Both of these appear to be compiled with TADS 1.2. While it’s possible to extract the game data, there’s no point - there’s no TADS interpreter that can handle the format, as TADS 1 was pretty rapidly superseded by TADS 2.

This is some sort of old Mac self-extracting archive - I haven’t found any way to unpack it on Windows. Zarf, could you at least unpack the contents and upload it to the Archive? Then we can see what game data is in there.

“Release along with an interpreter.” is the solution for Inform7: almost everybody would be able to read your game.html file with their browser.

An .exe can hardly be called “standalone” because you need microsoft windows to read it.

“Standalone” doesn’t mean universal, though.

Not easily. It was a self-extracting executable in 1992, but that means it’s a 68000-architecture binary for System 7. Macs haven’t supported either for a long time.

I see that there’s still a StuffIt commercial tool (, but honestly I don’t trust it – a proprietary compression tool in the Internet age is more likely to have adware as a business model than anything else.

Best bet is to run the thing in a Mac emulator.