From source code to virtual machine code

At the core of every computer is the central processing unit, or CPU. The CPU's job is to execute instructions given to it in machine code, which is just a string of binary digits: "1101011010010001" (footnote) might mean "go to the 106th location in this computer's memory and add 1 to whatever number you find there." How does the CPU know that that's what this string of digits means? Because the silicon chips are built in just such a way that sending a series of electrical impulses representing that number through the chip has the intended effect. How do you, the programmer, know that that's what this string of digits means? Unless you're working with a very low-level language, you don't have to. That's what a compiler is for.

A compiler is a program which takes source code from a high-level, fairly readable language (like Inform) and converts it into machine code. However, here a problem arises. Every type of machine is different. A string of binary digits that means "add these two numbers together" to the CPU of a Intel machine might mean something different -- or might mean nothing at all -- to an Apple machine. One solution to this problem would be to take your source code, find a machine running Windows, and compile an executable file -- that is, a program that can be run all by itself, like any other program you might use -- for Windows. Then track down a Mac and compile an executable for the Mac. Then get hold of a Palm Pilot and compile a version for that. And then one for the Acorn, and one for the Amiga, and then a new one every time a new kind of machine comes out... it's easy to see why this is not really the best solution if you want people with different sorts of machines to be able to play your game.

Instead, the solution used by the IF community is to compile their programs for virtual machines. Instead of compiling for the Mac or for DOS, TADS users compile files for "the TADS VM", Hugo users compile for "the Hugo VM", and Inform users compile for "the Z-machine". The specification documents for the Z-machine are just like the specification documents for any other machine: they tell compiler-writers what machine code understandable to the Z-machine looks like. The only difference is that no Z-machines are actually built: no factory connects Z-silicon-chips to a Z-circuit-board, and you won't see Z-laptops for sale at CompUSA. But you can still compile programs for them.

So you've come up with an idea for a game, you've learned Inform, you've written your source code, and you've compiled it. What you now have is a game file designed to be run on a machine that doesn't exist. What good does that do? Read on.