Ah, this discussion make me misty-eyed for the Be API, with such gems as:

is_computer_on() and is_computer_on_fire()

SirNickity wrote:

Emulating the hardware is much lower level. You're taking code at the CPU op-code level and making decisions about whether the […]
Show full quote

Emulating the hardware is much lower level. You're taking code at the CPU op-code level and making decisions about whether the host CPU can process that instruction directly (there's no harm in letting the host CPU add two numbers together), or if that instruction needs to be redirected to a proxy routine -- which would be the case if the emulated code is trying to... say... write to an I/O port for a piece of hardware that may not exist at all and so has to be emulated, or would interfere with the state of the hardware being used by the host OS.

Emulating an API is higher level. As a basic example, let's say the virtualized application is trying to call an API routine named "GetWindowsVersion". Well, for one, that API call might not exist anymore -- having been named to "GetWindowsNTVersion" for example. (Please bear in mind these are made up names, BTW, just for illustrative purposes.) So, the API compatibility layer will map those original calls to either internal routines (returning "Windows 95 build xxxx.xxx" for example), or map them to modern API calls with perhaps a little fudging of the parameters along the way.

API emulation essentially lets you run non-native applications directly on the native OS, by "pulling a fast one" during certain function calls that wouldn't ordinarily work if the app tried to run locally without any help. It can get as extreme as in the case of WINE, where you're providing an entire Windows API on a non-Windows OS. This usually requires that the instructions themselves are directly executable on the underlying hardware -- there's no x86-to-ARM translation or anything like that. It's just a switcheroo of API functions to alternative ones, which in the end all boil down to patching the location of calls to the correct (emulated API) code segments in memory so the desired outcome is reached.

Hardware emulation can allow any code to run on any platform. Run code designed for a Pentium MMX on a Raspberry Pi, or less drastically, allow a generic x86-32 CPU to execute x86-32 code, but non-exclusively -- i.e., let two or more OSes run on the same hardware at the same time by emulating the "bare metal" that all but one of those OSes sees.

Fantastic explanation. Thank you!