What ? You just write your OS layer for each platform and it's portable.

True. The OS layer you write (and port to other OSes) is called "the standard library". :-)

But at least now you know what's in there, what's going on behind the scenes. And on top of that, it's filled with all sorts of brand new bugs and vulnerabilities! ;-)

A .h file with different syscalls IDs and perhaps a few inline functions is hardly a standard library though

Not exactly syscall ids: I built network services (telnet daemon, snmp client and server, DNS) that compiled without change for win32 (both on Windows and some embedded win32 compatible abomination) and Linux with just a handful of defines and function wrappers as part of a contract once. A lot of apps can get away with very narrow interfaces to the OS.

> A .h file with different syscalls IDs

That's not portable even across versions of the same OS, many OS don't support raw syscalls and don't make any guarantees about them. That's why you can't statically link libc on OSX for instance, libSystem is literally the system's interface and necessarily dynamically linked.

That would be the few inline functions so to abstract a bit the syscalls.

It doesn't abstract anything, if the syscall changes your "abstract a bit" will be broken all the same. On many if not most OS the machine code side of the syscalls can change with no notice, Windows has changed syscalls in minor revisions, Go broke several times during the Sierra beta due to syscall changes (because it handrolls gettimeofday(2) whose assembly calling convention changed).

The proper abstract interface on non-linux systems is the standard library.