People up-voting this only to read later and find out what Proton is. I thought WINE was the Windows Emulation Layer on Linux. Although, of course, Wine Is Not an Emulator.
I'm a big fan of Porting Kit, a Mac app that has a library of pre-configured Wine wrappers for windows games, the installers for which are usually obtained from GOG or Steam. It worked really well. Currently enjoying Far Cry 2 on my iMac.
WINE abstracts away the operating system kernel so it is essentially a process or application VM, which is an emulator. Don't wanna argue semantics but I never understood the recursive acronym. WINE _is_ an emulator.
It is a bit more than a library because it has a significant Runtime component, but a bit less than a full blown VM.
You could also call a drop in libc replacement that not only implements the standard but also the quirks and extensions of a specific implementation, an emulator.
I am thinking at it from this point of view, say you create a library named libmath and you put a function in it named add.
Then someone makes an app that uses your libmath named MathApp.
If I reimplemnt libmath myself, then do some trickery to make MathApp use my version did I emulate your library or reimplement it? IMO I reimplemented it and it is very possible that my implementation could be less buggy and faster in some cases.
It is an emulator, because it mimics the behaviour of the native Windows APIs. It's an abstraction layer on top of Linux syscalls, as much as libc is such an abstraction. However it's not a process virtual machine, that's provided by the kernel, and doesn't differ from what ordinary Linux processes get.
Thanks for clarifying. What is a typical example of a process virtual machine then? I'd always thought that applications that abstract away the kernel for the purposes of running software from a different OS were classic process VMs.
It's because when most people hear "emulator" they think of hardware emulators, which have a huge performance penalty. WINE is just translating x86 code to x86 code with minimal to no performance loss, so they want to distance themselves from the emulator label.
My understanding is that it doesn't do any of this. Windows programs generally don't make direct syscalls, they're undocumented and only used by Microsoft-written DLLs. Wine provides a re-implementation of these DLLs suitable for Unix-like systems. The code of the program itself is untranslated and runs as-is with no performance loss.
