3 ms·

Because you asked: https://developer.apple.com/library/archive/qa/qa1118/_index.html https://developer.apple.com/library/archive/qa/qa1118/_index... "Apple doe

by lgg 4y ago

Because you asked: https://developer.apple.com/library/archive/qa/qa1118/_index.html https://developer.apple.com/library/archive/qa/qa1118/_index... "Apple does not support statically linked binaries on Mac OS X. A statically linked binary assumes binary compatibility at the kernel system call interface, and we do not make any guarantees on that front. Rather, we strive to ensure binary compatibility in each dynamically linked system library and framework." More to the point, platform vendors decide what their ABI boundaries are. Historically Unix vendors (back in the late 80s and early 90s) had no ABI boundaries... the expectation was every new OS release would require a recompile of all software. Obviously Linus has very different ideas about stability than the other Unix like systems of the time (which was a good thing), and focused on syscall stability. That made a lot of sense since he only wanted to maintain a kernel, not a full OS distribution. When modern macOS and Windows developed their ABIs they both were relatively mature OS distributions including a dynamic linker and default runtime libraries, and the ABI boundary chosen was well above the kernel as that is an easier place to define and maintain it.

loup-vaillant 4y ago
> the ABI boundary chosen was well above the kernel as that is an easier place to define and maintain it. How do we actually know that placing the boundary above the kernel makes it easier to define and maintain?
- dataflow 4y ago
  One reason (may not be their main one) could be that system calls have more overhead than function calls, and some things (like futexes) make more sense to implement on the userspace side. As another example, imagine a function for measuring time. You don't want that to be a system call if it's meant to be efficient, and when a better mechanism comes along, changing the implementation on the user space side is a lot easier and potentially more efficient if the kernel interface can be changed without breaking compatibility.
- bell-cot 4y ago
  Quip: The higher up the rug, the more crap that there's room to sweep under it. Or: Life can be easier for the kernel team if they're allowed to make breaking changes. Then task the lib team with writing shims / wrappers / etc. to fix all the problems which that causes. Then the manager of the lib team may have a perfect reason to boost his headcount. Then...
- Someone 4y ago
  It makes it possible to change the API of system calls or completely remove them if better ideas come along for implementing their functionality. Without it, you end up maintaining system calls that nobody should use. Now, you could argue that moves the mess to the c library, which would still have deprecated functions that used to call old system calls, but now are built on top of better ones, but there’s more flexibility there. Application programmers can, one by one, move to newer c libraries that remove that cruft.
silon42 4y ago
The issues are not the same.. Having a stable syscall interface is one thing... not supporting static linking is another... Even on linux, statically linking libc, GTK, ... is not a great idea.
dekhn 4y ago
In the 80s and 90s, you could often use your old compiled binaries for decades. No recompile after an OS release. For example, I had binaries compiled in the mid-80s on a DEC running Digital UNIX that worked through all the upgrades to the systems to bring them to Tru64/TruCluster. That was a big part of the value of the system. I also had a Mathematica binary (statically compiled except for libc) that ran on Linux from 1998 to 2010, including X windows (at some point, somebody moved the X files to a different location, so I had to set an env var).
- classichasclass 4y ago
  I still have AIX 3 binaries from the early-mid 1990s running on AIX 6 and 7.

by lgg 4y ago

loup-vaillant 4y ago

> the ABI boundary chosen was well above the kernel as that is an easier place to define and maintain it. How do we actually know that placing the boundary above the kernel makes it easier to define and maintain?

dataflow 4y ago
One reason (may not be their main one) could be that system calls have more overhead than function calls, and some things (like futexes) make more sense to implement on the userspace side. As another example, imagine a function for measuring time. You don't want that to be a system call if it's meant to be efficient, and when a better mechanism comes along, changing the implementation on the user space side is a lot easier and potentially more efficient if the kernel interface can be changed without breaking compatibility.
bell-cot 4y ago
Quip: The higher up the rug, the more crap that there's room to sweep under it. Or: Life can be easier for the kernel team if they're allowed to make breaking changes. Then task the lib team with writing shims / wrappers / etc. to fix all the problems which that causes. Then the manager of the lib team may have a perfect reason to boost his headcount. Then...
Someone 4y ago
It makes it possible to change the API of system calls or completely remove them if better ideas come along for implementing their functionality. Without it, you end up maintaining system calls that nobody should use. Now, you could argue that moves the mess to the c library, which would still have deprecated functions that used to call old system calls, but now are built on top of better ones, but there’s more flexibility there. Application programmers can, one by one, move to newer c libraries that remove that cruft.

silon42 4y ago

The issues are not the same.. Having a stable syscall interface is one thing... not supporting static linking is another... Even on linux, statically linking libc, GTK, ... is not a great idea.

dekhn 4y ago

In the 80s and 90s, you could often use your old compiled binaries for decades. No recompile after an OS release. For example, I had binaries compiled in the mid-80s on a DEC running Digital UNIX that worked through all the upgrades to the systems to bring them to Tru64/TruCluster. That was a big part of the value of the system. I also had a Mathematica binary (statically compiled except for libc) that ran on Linux from 1998 to 2010, including X windows (at some point, somebody moved the X files to a different location, so I had to set an env var).

classichasclass 4y ago
I still have AIX 3 binaries from the early-mid 1990s running on AIX 6 and 7.