[TUHS] Re: [simh] Announcing the Open SIMH project

[Chris Hanson <cmhanson@eschatologist.net>]

On Jun 7, 2022, at 10:00 AM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> Windows and OS X rarely had problems with upward compatibility (newer
> versions able to run executables built for older versions), but Linux
> was living hell. Shared library compatibility was the biggest
> problem. Not only were shared libraries often incompatible between
> different Linux distributions, they were sometimes incompatible even
> between different versions of the same distribution.

That's because, at least when it comes to macOS (nee OS X, nee Mac OS X, nee OPENSTEP/Mach, nee NEXTSTEP in various capitalizations) we treat treat binary compatibility as something for the operating system as a whole to maintain, not just the kernel or the kernel userspace.

Linux's ABI compatibility is itself kind of bare-bones; it achieves userspace compatibility by having a fixed set of system call numbers with well-specified calling sequences that get compiled into every binary for a particular architecture, and it doesn't even attempt to provide the kernel ABI compatibility needed by commercial driver vendors.

We handle userspace ABI compatibility in macOS by actually putting the syscalls on the other side of a shared library (libSystem.dylib) so the calling sequences and syscall numbers are entirely hidden from userspace. We've historically taken a different approach to kernel ABI compatibility but have provided it too, though not to the same extent as userspace.

As an example of where this helps, things like Linux-derived containers would be much faster on non-Linux platforms if the container system could swap in its own "libsyscall.so" instead of having to run atop a VM of some sort to handle the Linux syscall traps.

  -- Chris