VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

How Emulation Works for Digital Preservation | How Old Software Keeps Running After Its Original Machine Is Gone

Sometimes the safest way to preserve a digital object is not to change the object. It is to rebuild the vanished world around it.

A game may depend on an obsolete console. A digital artwork may require an old operating system and graphics stack. A scientific program may rely on a proprietary runtime. A spreadsheet may contain macros whose behaviour disappears when the file is converted.

Emulation is a preservation strategy in which a current system recreates enough of an older hardware or software environment that original digital objects can continue to run.

This article sits beneath How Library Preservation Works, How Significant Properties Work in Digital Preservation and the previous How File Format Migration Works. Migration changes the representation. Emulation changes the environment.


1. Emulation Preserves Behaviour by Recreating Dependencies

A digital object can depend on layers: hardware architecture, operating system, drivers, libraries, application software, fonts, codecs, input devices and display behaviour.

An emulator recreates enough of those dependencies that the original software behaves as expected on modern hardware.

2. The Object May Stay Original While the Environment Is Synthetic

This is the key contrast with migration.

Instead of converting a file into a new format, the archive can keep the original file and present it to a recreated environment that still understands it.

The Digital Preservation Coalition describes emulation as an alternative to migration that can preserve original behaviour and look-and-feel, especially for complex interactive objects. See DPC Digital Preservation Handbook — Preservation Action.

3. Hardware Emulation and Software Emulation Are Different Layers

Some emulators recreate a processor, memory map, graphics hardware or entire console. Others recreate an operating system or application environment.

The preservation team needs to know which layer the object actually depends on. Emulating too little can fail. Emulating far more than necessary can make the stack difficult to maintain.

4. Environment Capture Is Preservation Metadata

An emulator is not enough if nobody knows which operating system image, application version, fonts, plug-ins, drivers or configuration files the object requires.

The environment itself needs documentation, identifiers, provenance and version control.

This connects to How Preservation Metadata Works.

5. Emulation Is Especially Valuable for Behavioural Objects

A static image can often be migrated while preserving its important properties. A game, simulation or interactive artwork is different.

The object’s meaning may depend on timing, user input, state change, sound, animation, software logic and even bugs. Flattening it into screenshots or video can preserve evidence of appearance while destroying the behaviour that made the object itself.

6. Authentic Experience and Authentic Record Are Not the Same Claim

An emulated game may feel close to the original and still differ in latency, colour, sound or input timing.

The archive should therefore avoid vague claims that the experience is “identical.” It should document what environment was emulated, what hardware differences remain, what significant properties were tested and where the reconstruction departs from the historic setup.

7. Emulators Themselves Become Preservation Dependencies

An emulator written today may become obsolete tomorrow.

Preservation does not eliminate dependencies; it can move them upward. The archive may later need to migrate or recompile the emulator while keeping the emulated environment stable.

This creates a layered preservation strategy: original object → preserved environment → emulator → current host system.

8. Rights Can Be Harder Than Technology

Operating-system images, commercial applications, firmware, game ROMs and fonts can be protected by copyright, licences or technical restrictions.

A repository can have the technical capability to emulate and still lack the legal permission to distribute or even retain particular software components in the intended way.

Rights review belongs inside the preservation plan rather than after the environment has been assembled.

9. Security Boundaries Matter

Old software can contain known vulnerabilities. Networking an emulated legacy system directly to modern infrastructure can create risk.

Archives may need sandboxing, network isolation, controlled file transfer and disposable runtime sessions.

Preserving historic behaviour does not mean preserving unsafe deployment conditions.

10. Input Devices Can Be Significant

A game designed for a joystick does not necessarily feel the same when mapped to a touchscreen. A digital artwork may expect a mouse, MIDI device or physical controller.

If interaction is significant, the preservation system needs to document and sometimes recreate the input relationship, not only the executable environment.

11. Display and Timing Can Matter

Old CRT displays, fixed resolutions, refresh rates and aspect ratios can affect appearance. Processor speed can affect software that tied animation or game logic to hardware timing.

Emulation quality therefore has to be evaluated against significant properties rather than “it launched successfully.”

12. Emulation Can Be Centralised

One configured legacy environment can serve many preserved objects that depend on the same stack.

That makes emulation attractive for collections with repeated dependencies: thousands of documents created in one application, or many games from one platform.

13. Worked Example: Interactive CD-ROM

A 1990s educational CD-ROM contains animation, narration, hyperlinks and quizzes tied to a legacy multimedia runtime.

A screen recording preserves one walkthrough. Emulation preserves the branching choices, interface timing and learner interaction. The archive can keep the disc image, required software stack and configured emulator as linked preservation objects.

14. Worked Example: Spreadsheet With Macros

A financial model contains macros and external calculations.

A PDF preserves visible reports. An emulated original application can preserve the computational behaviour. Depending on the preservation purpose, the repository may keep both: a stable access rendition and an emulated functional representation.

15. Worked Example: Digital Art

An artwork responds to mouse movement and changes over time according to code.

A video captures one performance of the work. Emulation can preserve the rule system that generates many possible performances. Documentation records expected behaviour and tolerated differences.

16. Worked Example: Scientific Software

A historical simulation requires an old compiler and numerical library.

Emulation can provide access to the original computational environment for reproducibility research. The archive should also preserve source code, documentation, input data and known output checks where available.

17. Migration and Emulation Can Coexist

Preservation strategies are not mutually exclusive.

An archive might migrate descriptive documents into stable formats, preserve original executables, emulate the old runtime and create video documentation for easy public access.

The strategy can be layered because different representations serve different future jobs.

18. An Emulation Checklist

  1. Identify behaviour or properties migration cannot preserve adequately.
  2. Map hardware, operating system, application, library, font and device dependencies.
  3. Preserve original object and environment components where lawful.
  4. Record configuration and version state.
  5. Choose and preserve an emulator appropriate to the environment.
  6. Test display, timing, input and output against significant properties.
  7. Isolate security risks from obsolete software.
  8. Resolve software and firmware rights.
  9. Document known differences from historic hardware.
  10. Plan for future maintenance or replacement of the emulator itself.

19. Read the Mechanism Forward, Backward and Sideways

Forward: preserved object → dependency map → environment capture → emulator → reconstructed behaviour → user access. Backward: start from a behavioural mismatch and locate whether the object, software stack, emulator, input mapping or host timing caused it. Sideways: compare creator, archivist, software engineer, rights owner and future user. Each defines “the same experience” differently.

20. The Civilisation Lesson

Some digital objects are inseparable from the machines that once interpreted them. When the machine disappears, preservation may have to preserve the relationship between object and machine rather than the object alone.

Emulation preserves by rebuilding context: instead of teaching the old object a new language, it teaches the new machine how to speak the old one.

Continue through How File Format Migration Works, How Significant Properties Work in Digital Preservation and the How X Works hub. Next: digital record authenticity — why an unchanged or successfully emulated file still needs evidence that it is the record it claims to be.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading