Emulation is the technique of imitating one computer system in software on another, so that programs written for the original hardware or operating system run unchanged. In OS compatibility, it is the most thorough way of running software made for other systems or versions, because the emulator reproduces the processor, memory and devices the program expects.
The price of this completeness is performance overhead. An emulator must translate or interpret every instruction of a foreign processor, which is why modern operating systems combine emulation with faster methods such as binary translation, virtualization and compatibility layers.
How emulation reproduces a foreign machine
An emulator models the guest system, meaning the machine the software was written for, on top of the host system that actually runs it. It keeps the guest’s registers, memory map and device state in host memory and updates them exactly as the original hardware would.
Three execution methods exist, and real emulators often mix them. The table compares their speed and accuracy.
| Method | How it works | Speed | Accuracy |
|---|---|---|---|
| Interpretation | Decodes and executes each guest instruction one by one | Slowest, often 10-100 times slower | Very high |
| Dynamic binary translation | Translates blocks of guest code into host code at run time and caches them | Fast, often a fraction slower than native | High |
| Static binary translation | Translates a whole program before it runs | Close to native | Limited by self-modifying code |
Besides the processor, a full-system emulator must reproduce graphics chips, timers, storage controllers and firmware. Cycle-accurate emulation, which matches the timing of every clock cycle, is the most demanding and is mainly used to preserve old consoles and verify hardware designs.
Types of emulation on desktop systems
Desktop emulation falls into three practical categories, distinguished by how much of the original environment is imitated.
| Type | What is emulated | Typical example |
|---|---|---|
| Full-system emulation | Processor, devices and firmware | QEMU running an ARM operating system on x86 |
| User-mode emulation | Processor only, system calls passed to the host | Rosetta 2 running x86 Mac apps on Apple silicon |
| Architecture emulation in Windows | x86 and x64 code on ARM processors | Windows on ARM running classic desktop apps |
| Console and legacy emulation | Complete historical machines | Emulators for retro consoles and home computers |
User-mode emulation is the common case on modern desktops. Only the application’s instructions are translated, while file access, windows and networking go directly to the host operating system, which keeps overhead low and integration seamless.
Emulation compared with related compatibility methods
Emulation is often confused with virtualization and compatibility layers, but the decisive difference is the processor architecture. Emulation can bridge different instruction sets, while virtualization runs guest code directly on the same kind of processor.
| Approach | Translates instructions | Needs foreign OS | Typical overhead |
|---|---|---|---|
| Emulation | Yes | Sometimes | Moderate to high |
| Virtualization | No, same architecture | Yes, full guest OS | Low |
| Compatibility layer such as Wine | No | No, translates API calls | Low |
| Compatibility mode | No | No, adjusts OS behavior | Negligible |
| Dual boot or Boot Camp | No | Yes, runs natively | None, but requires a restart |
Wine is a useful contrast: its name stands for “Wine Is Not an Emulator”, because it translates Windows API calls into Linux or macOS calls while the x86 code runs natively. Compatibility mode in Windows goes even lighter and only changes reported versions and behaviors for older programs.
Performance and practical choices
Emulation speed depends mainly on how different the two architectures are and on how much of the system must be imitated. Translating between modern 64-bit processors with similar memory models is far cheaper than reproducing an exotic chip with unusual timing.
Translators also need hardware help for memory ordering. x86 processors guarantee a stricter order of memory operations than ARM, so a faithful translation either inserts costly barriers or relies on processor support for x86-style memory ordering, as Apple silicon provides.
| Situation | Recommended method | Reason |
|---|---|---|
| Old x86 app on an ARM laptop | Built-in user-mode emulation | Transparent and usually fast enough |
| Software for a different OS on the same CPU | Virtual machine or Wine | No instruction translation needed |
| Testing firmware for another processor | Full-system emulation | Reproduces devices and boot process |
| Demanding game with anti-cheat | Native version or dual boot | Emulation and layers are often blocked |
| Preserving a historical machine | Cycle-accurate emulator | Matches original timing behavior |
Limitations and common pitfalls
Emulation solves application compatibility, but it cannot emulate what the host lacks. Several limits recur in practice.
- Kernel-mode drivers generally cannot be emulated by user-mode translators, so hardware utilities and some antivirus tools fail.
- Specialized instruction sets such as certain vector extensions may be missing or translated slowly, which hurts audio and video software.
- Anti-cheat and copy protection often detect emulation and refuse to start.
- Just-in-time compilers inside the guest, such as browser engines, force repeated translation and reduce performance.
- Licensing of firmware or operating system images is a separate legal question from the emulator itself.
A frequent misconception is that emulation is always slow. Modern translators with caching and ahead-of-time translation run many everyday applications at speeds users do not notice, while the gap remains large for compute-heavy workloads.
The idea in brief
Every processor speaks its own language of instructions. A program written for one processor cannot be understood by another, just as a book in Japanese cannot be read by someone who only knows English.
An emulator is a live interpreter. It reads the foreign instructions and turns them into ones the computer understands, while pretending to be the original machine so that the program never notices the difference. The program runs, but translation costs some speed, which is why emulators work hard to remember translations they have already made.
A practical scenario
An engineering firm moves its staff to ARM-based laptops for longer battery life. One essential tool, a ten-year-old calculation program, exists only as a 32-bit x86 Windows application, and the vendor no longer updates it.
On the new laptops, Windows runs the program through its built-in x86 emulation. The first launch takes a few seconds longer while code is translated and cached; afterwards the program starts quickly and its calculations finish in roughly the same time users were used to.
A USB license dongle for a different program, however, needs a kernel-mode driver that cannot be emulated. The IT team keeps two older x86 desktops for that program, a typical outcome in which emulation covers most software but not drivers.