[throwaway7356]

> all system calls had to go through libc (or perhaps a big ntdll.dll-like

Which makes containers crap on Windows and *BSD as they have to run the currect libc or equivalent. Thus you need to build a different container per OS version which sucks compared to Linux.

[Joker_vD]

Windows doesn't even have its own libc.

[orangesilk]

Windows does have three libc, likely as a compability layer. their names are:

  * <forgotten something Windows 3.1>
  * msvcrt.dll, 2014
  * ucrt.dll (universal c runtime, since Windows 10)

[Joker_vD]

Those are not a compatibility layer with the OS. Heck, the all barely even provide proper access to the file system, ffs! The "msvcrt.dll" in the System32 folder is an ancient leftover from Microsoft-internal version of MSVC 6.0 or so, not intended for 3rd-party consumption.

At some point Microsoft got tired of maintaining binary-incompatible versions of its C runtime for different Visual Studios, so they started shipping UCRT with Windows itself... but you still don't need to touch that garbage for anything whatsoever.

[quotemstr]

In Window,s the last-userspace-before-kernel-mode layer is called ntdll.dll. Unlike msvcrt or any other libc, ntdll is universal and loaded into every process.

[yjftsjthsd-h]

They said "or equivalent", so ntdll

[quotemstr]

You understand that your container is using the VDSO today, right? A UAPI requirement to issue system calls through it wouldn't hurt your deployment story at all.

But sure, keep using SYSCALL, THE DEPENDENCY MUTILATOR. It's got what containers crave!