Isn't Windows also known for being committed to both API and ABI stability?

Yes, but the stable interface is functions exported from kernel32, ntdll, etc. Syscall numbers can and do change freely between builds.

Indeed. The Win32 API (and UWP et al) is the only one that's officially stable.

Kernel syscalls themselves are entirely unstable. Not even just the numbers but the calling convention and everything else. Microsoft reserves the right to add, remove or modify anything in or exposed by the NT kernel. Of course they won't do so frivolously but syscall numbers are especially prone to change with a new build of the kernel.

So as with MacOS, BSD, etc the stable interface is provided by userspace libraries.

Go tried to break the rules and call macOS syscalls directly (like they do on Linux, because Go is a massively NIH language so they don't use libc where they can get away with it) and it bit them hard when an OS update broke all Go apps.

If Apple broke every Go program, then that's on Apple. Why are people blaming the victim? Go didn't do anything wrong.

Apple came back in the late nineties, in part, because they copied and pasted the magic numbers from the Bell System Five codebase, e.g. 1 for exit(), etc. Capitalizing on UNIX popularity helped Apple succeed. So they shouldn't treat Bell Labs technologies like it's their own implementation detail.

For example, Microsoft has the right to break NTDLL because they invented it, and never intended for it to be used directly by app developers. Windows was designed from its beginning to have dynamic system interfaces too. In the UNIX community, DSOs have always been extremely controversial, since they raise legal questions compared to SYSCALL and INT trapping, and they violate the ability of a program to assume complete control of the full virtual address space.

If Apple devs are reading, then please, we love your products, but we don't love DSOs. Please grant us the freedom to choose. Please keep SYSCALL stable. It'd also be great if you didn't add special-cased code to XNU that blocks open source Actually Portable Executables, like you did with UPX. Email me (the author) your feedback instead. I'll do anything to help, short of adopting a second WIN32 linkage model.

Are you familiar with Apple's concept of "private API"? Apple considers the list of exported symbols from a dynamic library to not be a boundary (in fact, they have a linker that ignores that and links against a predefined list of symbols regardless of what a binary exports), much less the kernel syscall interface. In fact, Apple silicon requires that your program is loaded by dyld as far as I can tell.

While I wan't around in the nineties, I'm curious how syscall numbering helped Apple's success. I'm sure System-V ABI when they switched to 64-bit Intel was probably a nice bonus, but system call numbers?

Live at head goes both ways it seems

I might not be following here. Windows kernel functions are those in ntdll.dll. They've been stable for a very long time as far as I am aware. Well, the 30% of them that are documented at least. It's used by drivers, antivirus and rootkits.

C headers with the prototypes are available from the Windows Driver Development Kit. It's not something you want to use though, the average kernel function takes 10 arguments to support both sync and async IO.

https://docs.microsoft.com/en-us/windows/win32/api/winternl/...

Symbol names and function prototypes in ntdll.dll are stable (albeit not officially stable), but system call numbers change frequently: https://j00ru.vexillium.org/syscalls/nt/64/

NTDLL is only stable if Microsoft likes what you're doing. For example, Microsoft culture is super biased against fork() or any creative use of virtual memory. There was, for decades, a sort of a hush hush fork() workaround in NTDLL that people thought was stable. Then some Sunnyvale startup called Crossmeta built a product to capitalize on it, Microsoft rolled out a security update, and poof it's gone. They ignored all the documented warnings saying "if you use NTDLL be sure to have fallback!" So think twice before messing with Redmond.

ntdll is a userspace library, not a part of the kernel. So when you call ntdll functions you aren't calling into the kernel (although most ntdll functions will do so on your behalf).

And ntdll itself is technically unstable[0], though I'll grant you that there are many functions that are unlikely to break. There's no guarantee though.

[0]: https://docs.microsoft.com/en-us/windows/win32/devnotes/call...

There are different rules for drivers. Which is also why it's common and normal for a driver written for an older version of Windows to not work on a new version, but it's rare (and considered a bug) for userspace software.

> and UWP et al

That remains to be seen in ~10 years at least :-P

Might this change now that things like game copy protections are implementing syscalls manually?

Doubtful. There have long been software that abuses syscalls and other kernel level features to implement Sony rootkits and other DRM. Ironically those that implement game copy protection would be annoyed if syscalls were stabilized because the whole reason they use unstable syscalls is to obfuscate what they're doing and make the program extremely sensitive to tampering.

FreeBSD guarantees syscall ABI stability too.

Do you have a source for that? The closest I could find suggests otherwise, but admittedly I haven't yet found a more relevant document on policy:

> No compatibility for API and ABI is guaranteed from one to the next major release, though an effort is made to make the upgrade process and source code changes as untroubled as possible.

https://wiki.freebsd.org/VendorInformation

It’s pretty obvious from the fact that people are routinely running jails with old userspace (eg 11.0) under newer kernels (eg 13.0). It doesn’t always work for management interfaces (so eg an old route(8) binary might be broken), but is guaranteed to work for normal user programs.