5 ms·
> 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
by throwaway7356 3mo ago
> 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 3mo agoWindows doesn't even have its own libc.
- yjftsjthsd-h 3mo agoThey said "or equivalent", so ntdll
- orangesilk 3mo agoWindows 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 3mo agoThose 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 3mo agoIn 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.
- quotemstr 3mo agoYou 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!