3 ms·

I don't know about the others but NetBSD has had an even stronger focus on compatability, with some people still running an old binary from NetBSD 0.9 (released

I don't know about the others but NetBSD has had an even stronger focus on compatability, with some people still running an old binary from NetBSD 0.9 (released in 1993). The one major exception was that the first threading implementation was based on scheduler activations and was completely removed. Any system that supports static binaries needs a stable system call interface if it wants binary compatibility. IIUC, Windows never supported static binaries.

mehrdadn 7y ago
> Any system that supports static binaries needs a stable system call interface if it wants binary compatibility. IIUC, Windows never supported static binaries. I feel like you're just playing semantics here. Windows refers to syscalls by name rather than number (which IMO is better), so the numbers aren't the static entities; the static entities are the names. That's static to me. I don't see a single thing that referencing by numbers vs. names would gain you.
- joveian 7y ago
  https://en.wikipedia.org/wiki/Dynamic-link_library https://en.wikipedia.org/wiki/Dynamic-link_library https://en.wikipedia.org/wiki/Static_library https://en.wikipedia.org/wiki/Static_library I'm not saying Windows is wrong (other systems later changed to dynmaic linking but some still have support for static linking) it just means that you can't replace only the kernel with a new major version and expect it to work (another issue there is kmem grovelers which I think Linux is entirely rid of but NetBSD isn't quite). IIUC, most of the major issues with Windows compatability are due to developers not following the documented system interface and directly calling the explicitly unstable and undocumented system calls directly. Stuff that uses the documented interface continues to work indefinitely. The origin of the stable syscall tradition in unixy systems is not fixing the same issues that Windows has but is due to the historic use of static binaries.

mehrdadn 7y ago

> Any system that supports static binaries needs a stable system call interface if it wants binary compatibility. IIUC, Windows never supported static binaries. I feel like you're just playing semantics here. Windows refers to syscalls by name rather than number (which IMO is better), so the numbers aren't the static entities; the static entities are the names. That's static to me. I don't see a single thing that referencing by numbers vs. names would gain you.

joveian 7y ago
https://en.wikipedia.org/wiki/Dynamic-link_library https://en.wikipedia.org/wiki/Dynamic-link_library https://en.wikipedia.org/wiki/Static_library https://en.wikipedia.org/wiki/Static_library I'm not saying Windows is wrong (other systems later changed to dynmaic linking but some still have support for static linking) it just means that you can't replace only the kernel with a new major version and expect it to work (another issue there is kmem grovelers which I think Linux is entirely rid of but NetBSD isn't quite). IIUC, most of the major issues with Windows compatability are due to developers not following the documented system interface and directly calling the explicitly unstable and undocumented system calls directly. Stuff that uses the documented interface continues to work indefinitely. The origin of the stable syscall tradition in unixy systems is not fixing the same issues that Windows has but is due to the historic use of static binaries.