windows-syscalls

>you must go through a system provided shared library rather than make syscalls directly Just to add to this, on Windows for example you're really only supposed to invoke syscalls via ntdll as the syscall table is not stable so their numbering changes over time. You cannot guarantee forward or backward compat if you do not use the library. If you look at some of the syscalls in https://github.com/j00ru/windows-syscalls, you can see they clearly do change over time too.

Indeed. Anything documented has a function wrapper. `NtCreateFile` is a function wrapper for the syscall number, so any user-mode code that has `NtCreateFile` instead of directly loading the syscall number 0x55 will be stable. The latter might not. In fact, it is not; the number has increased by 3 since Windows XP[1]. One could probably produce some sort of function pointer loader library with these tables, but at that point... Why not just use the documented APIs? [1]: https://github.com/j00ru/windows-syscalls/blob/8a6806ac91486...

I'm pretty sure Windows just automatically generates syscall numbers in their build process. Since the kernel and the dynamic libraries that are the only blessed way to interact with the kernel are shipped together, that's not a problem from Microsoft's point of view. For example, look at [1] and search for e.g. 0x01aa, to see how the meaning of that syscall number changes in a pretty systematic way over releases. 1: https://github.com/j00ru/windows-syscalls/blob/master/x86/cs...