8 Jun
2022
8 Jun
'22
1:41 a.m.
On Jun 7, 2022, at 10:00 AM, Paul Winalski <paul.winalski(a)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