The Emularity

A layer between the catalogue and the machine

When the Internet Archive began accumulating software for its collections, the obvious problem was not storage but playback. A disc image sitting in a server rack in San Francisco is only as useful as the means to run it — and for decades, running it meant downloading an emulator, configuring it correctly, and pointing it at the file yourself. The Emularity collapsed that chain to a single click.

The framework, developed inside the Archive and first deployed in earnest around 2014, sits between a collection item and a browser-based emulator. It reads the item's metadata, selects the appropriate emulator for the machine or runtime that item requires, loads that emulator as a WebAssembly or JavaScript module, fetches the disk or ROM image, and starts the whole thing inside the page — automatically, without the visitor doing any of it. From the outside it looks like pressing play. From the inside it is a small operating system for emulators.

The key design decision was not to emulate specific games but to emulate the runtime rather than the game: bring up a working virtual Apple II, a working DOS environment, a working Flash player, and every piece of software written for that environment becomes playable at once. The Emularity is the glue that performs this trick at catalogue scale, where a single collection might contain tens of thousands of items.

Several emulators plug into the framework. MAME, the long-running multi-arcade machine emulator maintained by a volunteer community, handles a wide range of hardware targets. DOSBox-X covers the DOS era. For Flash specifically, the Archive integrated Ruffle, the open-source reimplementation of the Flash runtime written in Rust and compiled to WebAssembly, which can run inside a modern browser without any plugin at all. Each emulator is treated as a module; the Emularity is the loader that knows which one to call.

What the framework actually solves

Before a system like this existed, browser-based emulation required the visitor to understand what they were looking at. That is a reasonable expectation for an enthusiast, and an unreasonable one for a researcher consulting a software archive the way they might consult a newspaper archive. The Emularity's contribution is to make the expertise implicit in the metadata rather than required of the person in the chair.

It also solves a provenance problem that matters to institutions. When an emulator runs locally on a visitor's machine, the archive has no reliable way to know whether the software executed correctly, or at all. When the emulator runs inside the page, mediated by the archive's own framework, the interaction is accountable — the collection item is served, and the emulator runs a version the archive has tested against that item. For a library treating software as a primary source the way the Internet Archive does, that auditability is not incidental.

The framework does not solve every problem. Software that made network calls to servers that no longer exist, checked online licence servers, or loaded assets from external URLs still fails — the emulated machine is alive but the world it expects to connect to is gone. Those failures are documented in the Archive's own collection notes on affected items, and they are a category of loss the Emularity cannot address because no emulator can reconstitute a server that has been switched off.

What it can address — and has, at a scale no previous preservation infrastructure attempted — is the simple fact that bit rot is not only a storage problem. Software rots in two ways: the physical medium degrades, and the environment it ran in disappears. Archivists solved the first problem with digital imaging; the Emularity is part of the answer to the second. It keeps a working environment available at the moment of access, assembled on demand from tested components, for a collection that spans home computers, arcade hardware, early web runtimes, and interactive fiction going back to the era of MUD1 at Essex and before.

When the Internet Archive began accumulating software for its collections, the obvious problem was not storage but playback.

The framework is open source, which means other institutions can adopt it. The Internet Archive's own Software Library, Console Living Room collection, and Historical Software Collection all run through it, serving items to browsers without asking anything of the person on the other side of the screen except curiosity.