Ah, no, not talking about VMs; talking about running the app directly on your own platform *without any copyrightable content from the other platform* anywhere involved
We had that with Posix for a very long time and it never really took off. In absolute terms that's because its a terrible implementation on any platform, but it proved a useful point that this is a hard demarcation to solve. At a minimum it needs ABI, but then Java et al show API is critical too.
Yeah you definitely need both, and Windows in particular has a few tens of thousands of APIs you'd need to implement. It's a very non-trivial technical challenge (tho also, it *is* a tractable one)
Oh yeah, in theory it's completely defined too. You implement the functions defined in the SDK and you cover, in theory, everything arbitrary apps need. At that point you're effectively writing Windows from scratch, or a close facsimile. Heck, we did that ourselves for SQL Server on Linux.
If the spec says a certain behavior is "undefined" that only means the actual behavior is a guessing game where the penalty for being wrong is applications will break in seemingly random and impossible to debug ways
I've heard very interesting arguments that applications should sharply punish undefined behavior by outputting a *random* response if an error is not an option for some reason, so as to prevent such unintended dependencies.
Something being undefined in the spec means the spec was written after the software was written and the devs don't want anyone to take a dependency on the current behavior. Seriously.
Often genuinely a bug that just has non-crashing effects on this version (i.e. the app calls the API, the API silently fails, and the app continues) that creates a PITA headache for future platform devs who now need to not change that API in ways that cause the broken behavior to fault
OK why not, simple dumb example for you, settle down for story time, this is the story of undefined behavior that's in the Intel Graphics usermode driver DLL that's been running on a few billion machines for several years
In Windows, graphics drivers sometime shove DLLs into random processes to allow them to translate graphics calls into a format that better suits their kernel mode driver. It's ugly but it works. Intel has a few of these. NVidia too. But this story is about the Intel one.
In the intel one, the DLL wants to talk to the kernel mode driver. Normally apps talk to the kernel over the syscall interface, but drivers can't add syscalls directly. To talk to a driver, you need to ask Windows for a handle to the driver, and then you can "talk" to it using that handle
The mechanism here isn't all that important. What matters is you get a HANDLE, which is typedef'd to void*, which is the C/C++ way of saying "it's an address that points to anything", and when you're done with the handle, you call CloseHandle, which takes a single HANDLE parameter.
HANDLEs in Windows are (not quite, but mostly) sequential indexes into a handle table in the kernel, that it can use to translate your HANDLE into the corresponding kernel object to service the request. Importantly: this means although a HANDLE is typedef'd to void*, it's usually just a small int
Anyway, long story short, to access the kernel driver, it correctly opens a handle to the driver, does some stuff with it, and then tries to close the handle. And the code for that looks a bit like
HANDLE hDriver = CreateFile(...)
dothings(hDriver)
CloseHandle(&hDriver)
Yeah I was more so calling out certain asinine language compiler specs. I think our official stance when we doc things is that they're "reserved" functionality? I can't remember.
