Wine vs. an emulator: what's the difference?
By Andrew Nakas · Published June 9, 2026 · Updated July 1, 2026 · ~9 minute read
If you've looked into running Windows software on a Mac, Linux, or in a browser, you've run into Wine — and the cheeky claim that "Wine Is Not an Emulator." It's a real distinction, not just a joke, and understanding it explains a lot about what works and what doesn't. Here's the plain-language version.
What an emulator actually does
An emulator pretends to be hardware. A CPU emulator reads the machine instructions of one processor (say x86) and simulates, step by step, what a real chip would do — updating fake registers, fake memory, fake flags. The program being emulated has no idea it isn't running on real silicon. This is powerful and universal: you can emulate an x86 PC on an ARM phone, a game console on a laptop, anything on anything. The price is speed. Simulating each instruction in software is many times slower than letting real hardware run it directly.
You've almost certainly used one. DOSBox — the program behind nearly every classic DOS game sold or re-released today — is a genuine emulator: it simulates an entire early-90s PC, including the CPU, the VGA graphics card, and a Sound Blaster, with a DOS-like environment layered on top. Console emulators do the same for a SNES or a PlayStation. Projects like v86 push it further, emulating enough of a complete PC inside a browser tab to boot whole operating systems — Windows 95, FreeDOS, small Linux distributions. The common thread: the emulator recreates the machine, and whatever ran on the original machine runs on the recreation. Slowly, but faithfully.
What Wine does instead
Wine takes a completely different approach. A Windows program is two things: (1) a stream of CPU instructions, and (2) a constant series of calls into Windows system libraries — kernel32.dll, user32.dll, gdi32.dll, and hundreds more. Wine doesn't touch the CPU part at all. On an actual x86 Mac or Linux box, the processor is already x86, so those instructions run natively at full speed. What Wine does is intercept the second part: when the program calls a Windows function, Wine answers with its own from-scratch implementation built on Linux/macOS system calls. It's a translation layer for the Windows API, not a hardware simulator. That's why it's "not an emulator" — and why, on matching hardware, Wine is fast.
| Emulator | Simulates the CPU/hardware. Universal, but slow. Example: emulating x86 on ARM. |
|---|---|
| Wine | Re-implements the Windows API on top of POSIX. Fast on matching hardware, but not 100% complete. |
Thirty years of Wine, briefly
Wine is old enough that the joke in its name has outlived several versions of Windows. The project started in 1993, when Windows 3.1 was the target, as an attempt to run Windows programs on Linux without Windows. The name is a recursive acronym — "Wine Is Not an Emulator" — chosen precisely to head off the confusion this article is about. Progress was famously slow, because the goal kept moving: reimplementing the Windows API means chasing every function Microsoft adds, and it took the project about fifteen years to declare a 1.0 release in 2008. Today it's maintained under the WineHQ banner, with much of the heavy lifting funded by CodeWeavers, the company that employs many core Wine developers and sells CrossOver, a polished, supported version of Wine for macOS, Linux, and ChromeOS.
The approach got its mainstream moment in 2018, when Valve shipped Proton — a Wine-based compatibility layer built into Steam, paired with translation for modern graphics APIs. Proton is the reason the Steam Deck, a Linux machine, plays thousands of Windows games out of the box. None of those games were recompiled or ported; their Windows calls are simply translated as they run. If you've heard someone say the Steam Deck "just runs Windows games," Wine's translation trick is the technology doing it.
Why the same trick works for one app and fails for another
API translation has a very different failure profile from emulation, and it explains Wine's famously app-by-app compatibility. A Windows program only ever uses a slice of the API. If everything it calls sits in the well-worn core — windows, menus, buttons, file access, 2D drawing — Wine's implementations are decades-mature and the app can run indistinguishably from Windows. That's why so many 90s and 2000s utilities and games work perfectly on the first try.
But translation is all-or-nothing in a way hardware emulation isn't. If an app imports a DLL Wine doesn't provide, or calls one function Wine has only stubbed out, it can fail instantly — the classic err:module:import_dll Library X.dll not found in the log. It doesn't matter that the other 99% of the app would have worked. The usual failure clusters are predictable: apps that need modern .NET runtimes, installers that lean on MSI custom actions, and copy protection or anti-cheat that deliberately probes deep Windows internals Wine doesn't reproduce. This is also why WineHQ maintains a per-application compatibility database rather than a simple version list — an app's fate depends on which calls it happens to make, not on its age or size. A full-machine emulator running real Windows sidesteps all of this, at the cost of needing an actual Windows install and being slower still.
So why does ExeBrowser use both?
Here's the twist. A browser doesn't run x86 — it runs WebAssembly. So Wine alone isn't enough: there's no x86 processor underneath for those instructions to run on. That's where the emulator comes back in. Boxedwine pairs Wine with a software x86 CPU emulator, and compiles the whole bundle to WebAssembly. The emulator handles the CPU instructions (the slow part); Wine handles the Windows API calls (the translation part). Stacked together, they let a Windows EXE run in a tab — which is exactly what ExeBrowser does.
This stacking is also why browser-based Wine is slower than Wine on a real Linux PC: on Linux, the x86 layer is free because the hardware is x86. In a browser, that layer has to be emulated, so you pay for it. The result is roughly 10–40% of native speed — invisible for a text editor, very noticeable for a 3D game.
One practical footnote: the Wine build ExeBrowser ships is 32-bit (Wine 1.7.55), so 64-bit-only EXEs won't load on the default engine. There's an experimental 64-bit runtime, but if the software you want ever shipped a 32-bit build, that build is the safe bet.
Where the other browser approaches fit
Boxedwine's CPU-plus-Wine stack isn't the only way to run old software in a tab, and it isn't always the right one. It sits between two neighbors:
- Full-machine emulation (v86). Emulate an entire PC — CPU, disk, graphics, everything — and boot a real operating system in the tab. Fidelity is total, because it is genuine Windows 95 or DOS running in there. The cost: you need an actual OS image (and the license that goes with it), you sit through a real boot, and everything runs at emulated speed. It's the right tool when an app depends on quirks of the real OS that Wine doesn't reproduce.
- DOS emulation (DOSBox / js-dos). For software older than Windows 95, the answer isn't Wine at all. A DOS-era program never calls the Windows API — Wine has nothing to translate — so handing a DOS EXE to Wine typically just fails. DOSBox, a true emulator of an early-90s PC, is the standard answer, and js-dos brings it to the browser via WebAssembly. This is exactly why ExeBrowser itself runs DOS games on DOSBox rather than forcing them through Wine: right era, right tool.
- Boxedwine (what ExeBrowser uses for Windows apps). The middle path: emulate only the CPU, let Wine stand in for the OS. No Windows license, no OS boot, seconds to start, and unmodified Win32 EXEs run directly — but you inherit Wine's incomplete corners along with its speed advantage.
Which one do you actually need?
A quick decision guide. If the program is from the DOS era — pre-1995, the kind you launched from a C:\> prompt — use DOSBox, on the desktop or in a browser. If it's a classic 32-bit Windows app and you're on a Linux or Intel Mac machine, plain Wine (or CrossOver, if you want paid support) is the fastest option because there's no CPU layer to pay for. If it's a modern Windows game and you're on Linux or a Steam Deck, Proton handles it through Steam. If you need a genuine, complete old operating system — quirks, boot screen, and all — that's v86-style full-machine emulation, license and patience included. And if you just want to run a 32-bit Windows EXE in a tab with nothing installed, that's the Wine-plus-emulator stack this site is built on.
The takeaway
"Emulator" and "Wine" solve different halves of the same problem. An emulator gives you the CPU you don't have; Wine gives you the operating system you don't have. Run a Windows app on an x86 Linux box and you only need Wine. Run it in a browser and you need both — which is the whole trick behind running a .exe in a tab.