As I understand emulators (in a simple way), they do translate or substitute the function calls of a program using functions of system X into functions used by system Y in which the program is being run onto. Wine project claims that Wine Is Not an Emulator, because:

Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.

Well, how emulators and virtual machines simulate internal Windows logic on host non-Windows systems? Isn't that by translating Windows system calls into the host's own respective calls? Is the difference between emulators and non-emulators (like Wine) is that emulators emulate a whole operating system then the application uses that system APIs without knowing that it is talking to an emulator, while non-emulators directly translates application's calls into the host's (and the application also may not know it)? Is the extra level of indirection is the only different between emulators and Wine?

  • 9
    Normally when computer minded people use the word "emulator", they mean a hardware emulator, software that emulates hardware. In that sense Wine is not an emulator. However in the dictionary sense of the word, Wine does emulate Windows, and in that sense you could call Wine a Windows emulator. Commented Nov 11, 2013 at 16:56
  • 1
    WINE is also a slightly stretched backronym, a kind of humor that appeals to the personality required to create WINE in the first place.
    – RBerteig
    Commented Nov 11, 2013 at 19:46

6 Answers 6


Well, how emulators and virtual machines simulate internal Windows logic on host non-Windows systems? Isn't that by translating Windows system calls into the host's own respective calls?

No, or at least not in the sense that WINE does -- by literally translating system calls one to one in user space. An emulator does this abstractly via a more circuitous route; it does not translate system calls directly.

A true emulator creates a virtual machine (e.g. x86-64), not a virtual operating system. You can then in theory run any operating system targeting that style of machine. Commonly an "emulator" includes the operating system, but that's not really what it is emulating; the OS it includes is the same as one that would run on a real machine.

Emulators are sometimes used to simulate hardware different from the host machine, but also hardware that is exactly the same for the purpose of running one OS inside another.

WINE is different from this in that it is not actually windows. You could run an x86-64 emulator with a real copy of windows inside it, but that is not what WINE is. Their claim that it is actually more efficient than an emulator makes sense -- the overhead for just translating system calls is probably lower than that of running a VM. The disadvantage is that WINE can only be windows; you cannot use it with some other OS as you could a normal VM.


Consider Java Virtual Machines. No JVM emulates any other, they're all implementations of a specification. Wine isn't emulating the win32 api, it's an implementation of it. Specs and reality not necessarily matching, both Microsoft's implementation and Wine's implementation have workarounds to make buggy code work, and it's not necessarily obvious which implementation is a better target for any given project.


Wine is a shim which intercepts windows API calls and converts them in the fly to the corresponding Linux API call(s). A emulator or virtual machine instead emulates a physical machine. Obviously a shim is more efficient, but may not be completely capable of mimicking the desired functionality.


Emulators virtualize the processor and/or OS which normally runs a Windows application by creating the logic and behavior of the OS/processor platform in the emulator application which itself runs on top of another OS/processor platform. Wine does not virtualize the Windows OS/processor behavior but rather runs the Windows application at the same level of abstraction as the Windows OS. It does this by re-implementing the Windows API to run directly on the Unix-based OS/processor platform. That is, Wine is a re-implementation of the core elements of the Windows OS, a set of compiled DLLs which directly translate Windows API call requests into equivalent Unix-based code that communicates directly with the physical processor.

This means that sometimes there are run-time contexts which will allow Wine + Linux to run a Windows application faster than Windows itself! An Emulator could never have that possibility because its code would be busy simulating the CPU/WinOS platform on top of the Unix-based platform at a higher level of abstraction. In this case, more translations and interfaces are necessary to run a Windows application. (See diagram below)

In short, Wine is a re-implementation of Windows, not an emulation of Windows.

enter image description here


Wine is like Python, Java or other runtimes. Wine is runtimable for Windows executable and libraries running on Linux/Unix like Darling ( macOs applications and dynamic libraries run on Linux ) Also it is not emulator just runtime.


WINE is an emulator. The way an emulator does what it does is utterly irrelevant to the fact that it is, by definition, a mechanism for running the software of one OS in another. At what layer of that BIOS to app route it happens is immaterial. What is germane is that the OS that is being emulated is not being run, which is the case with WINE. WINW would have been a more precise acronym, as in WINE is not Windows.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .