Wine is basicly just a set of libraries and tools that let the programs run within a unix-like system.
Or as the Wine-FAQ says,
Wine's "emulator" is really just a binary loader that allows Windows applications to interface with the Wine API replacement.
So I like the term "compatibility layer" much more here.
As an aside, a few months ago I was trying to find texts describing how WINE works, without much success (I believe I lack both patience and skill -- which are related -- for web search); I was thinking of the technical details of creating an Android compatibility layer and whether syscall translation (using ptrace, probably) would be necessary for seemingly Android-only kernel components like Binder/OpenBinder, and so wondered how WINE does syscall translation. It does not help that I am knowledgeable only, really, about GNU/Linux and know little to nothing about Windows (internals) or Android (anything/everything), having avoided both, nearly completely, for at least five years.
What I have concluded, cautiously, is that WINE does indeed use ptrace, probably for syscall translation, but that this is a marginal use. Instead, it mainly implements two layers of interfaces (the Windows API, which well behaved applications are supposed to use and which has a very high degree of backwards compatibility, and the Native API, which applications should leave alone and which is not officially documented and is unstable within and between Windows releases). Apparently, the Windows kernel interface to userspace, unlike the Linux kernel, has no guarantee nor even suggestion of stability, with all syscalls coming from DLLs provided as part of the OS (which I found intriguing*), with none from well-behaved applications.
This suggests that any well-behaved application run via WINE that either uses OpenGL rather than Direct3D, or which does not use a hardware graphics API, should experience
no overhead whatsoever, in theory, compared with the same application running on Microsoft Windows. This is likely the origin of claims that certain applications (presumably those not using Direct3D, and therefore without overhead from translation to OpenGL) run
faster on GNU/Linux via WINE than on Windows, as the Linux kernel is often said to be more efficient (though I have never sought out benchmark tests). If, in normal operation, WINE has no overhead, and does not actually translate anything (Direct3D aside), being simply a reimplementation of the APIs/libraries (with a foreign-to-Linux calling convention and executable format) that come with the base Windows system, then
it is in no way an emulator in a conventional sense.
Of course, it is quite possible that I have misunderstood something fundamental: as I said, I did not have much joy when trying to find out the details of all this.
*Linus Torvalds has spoken at length about his efforts to keep compatibility for syscalls, while saying that basic system libraries like GLIBC have been cavalier with compatibility. Microsoft Windows seems to have the opposite phenomenon: the kernel breaks compatibility all the time, but is always provided along with DLLs, that should never be bypassed, that fix compatibility. I am not sure which arrangement is better, but would it suggest that Microsoft have an easier time, theoretically, when cleaning up cruft in their kernel?
)
