Spinning Burr, on 22 February 2013 - 10:43 AM, said:
So sayeth the great and all-knowing Wiki:
- "The phrase "Wine Is Not an Emulator" is a reference to the fact that no processor code execution emulation occurs when running a Windows app under Wine. "Emulation" usually refers to the execution of compiled code intended for one processor (say, x86) by interpreting/recompiling software running on a different processor (say, PowerPC). Such emulation is almost always much slower than execution of the same code by the processor for which the code was compiled. In Wine, the Windows app's compiled x86 code runs at full native speed on the computer's x86 processor, just as it does when running under Windows. And Windows API calls and services also are not emulated, but rather substituted with Linux equivalents that are compiled for x86 and run at full, native speed."
- "Typically, an emulator is divided into modules that correspond roughly to the emulated computer's subsystems. Most often, an emulator will be composed of the following modules: a CPU emulator or CPU simulator (the two terms are mostly interchangeable in this case), a memory subsystem module, and various I/O devices emulators."
- "In software engineering, a compatibility layer is an interface that allows binaries for a legacy or foreign system to run on a host system. This translates system calls for the foreign system into native system calls for the host system. With some libraries for the foreign system, this will often be sufficient to run foreign binaries on the host system."
- "A compatibility layer requires the host system's CPU to be (upwardly) compatible to that of the foreign system. Thus, for example, an MS Windows compatibility layer is not possible on PowerPC hardware, since MS Windows requires an x86 CPU; in that case, full emulation is needed."
Basically, WINE and other "compatibility layers" go about a similar task in a different manner than "true" emulators, as well as sacrifice a number of the characteristics of "true" emulators in order to alleviate or mitigate certain of the "true" emulators' weak points (namely, performance speed; "if the emulator does not perform as quickly as the original hardware, the emulated software may run much more slowly than it would have on the original hardware, possibly triggering time interrupts that alter performance").
(Perhaps someone more well-versed in CompSci might chime in...?
