3 ms·

In pretty much every OS of the unix tradition. libc is the API, with a stable ABI. Although Windows has a something pretty much identical in — I believe — ntdll

In pretty much every OS of the unix tradition. libc is the API, with a stable ABI. Although Windows has a something pretty much identical in — I believe — ntdll. The name and API differ, but the intent is the same.

vlovich123 3y ago
Except notably Linux where the kernel ABI is the thing that’s stable.
- mikepavone 3y ago
  glibc actually goes through quite a bit of effort to remain backwards compatible. There have been times when mistakes were made here, but the extent to which glibc does not have a stable ABI is overstated. The only annoying thing about glibc and ABI stability is that the way it achieves that is via symbol versioning which makes it annoying to target an old glibc on a system with a new er glibc.
  - vlovich123 3y ago
    I didn’t mean to imply that glibc’s API isn’t stable. Just that the stable API boundary for the kernel on Linux is the syscall ABI, not libc.
    - mikepavone 3y ago
      Ah sorry, I misunderstood
      - vlovich123 3y ago
        No worries. My wording was muddled.
    - dfox 3y ago
      Another stable ABI boundary is anything produced by glibc that can be conceivably placed into memory shared by different unrelated processes (ie. Posix IPC primitives). The requirement for backwards compatibility and architecture variant compatibility (32b/64b…) is the largest reason why things like pthread_mutex have somewhat large overhead and why it is worthwhile to invent various iterations of “futex in userspace”.
MarekKnapek 3y ago
No, Windows has stable API and ABI named Win32 API. This comes from times of 16bit Windows and works also in x64 / ARM / ARM64, previously it worked in Alpha / MIPS / IA64. This API is implemented in kernel.dll user.dll gdi.dll advapi.dll and similar, it does some stuff, but mostly forwards to the NT API. Beware, kernel.dll is user space component despite its name (historical reasons). NT API is undocumented and not meant to be used by user programs, it is not stable, it lives in ntdll.dll, it does syscalls to the kernel: ntoskrnl.exe. Windows doesn't have a libc (for user programs, it has private one for its own programs), Visual Studio has a libc. Each version of Visual Studio (roughly) has its own libc named msvcrt.dll msvrt100.dll msvcrt140.dll and similar, it hosts the C and C++ libc, it could be linked statically for various benefits and drawbacks.
- aseipp 3y ago
  Windows does actually have a universal C runtime library now, but it's pretty recent; only Windows 10+ https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-c... A big motivation for it was security posture; it means that Microsoft can now ship security updates to UCRT that everyone can rely on rather than a ton of extra surface area through various multiple versions of runtime libraries.
  - actionfromafar 3y ago
    It had (has) an unsupported, crippled, unversioned msvcrt.dll which if you used it very carefully with a subset of functions, you could write programs which worked fine on Windows NT and up.
- monocasa 3y ago
  FWIW, large swaths of ntdll are documented and supported these days, for performing work that can't be expressed via the win32 API like raw disk manipulation.
deleted 3y ago
[deleted]

vlovich123 3y ago

Except notably Linux where the kernel ABI is the thing that’s stable.

mikepavone 3y ago
glibc actually goes through quite a bit of effort to remain backwards compatible. There have been times when mistakes were made here, but the extent to which glibc does not have a stable ABI is overstated. The only annoying thing about glibc and ABI stability is that the way it achieves that is via symbol versioning which makes it annoying to target an old glibc on a system with a new er glibc.
- vlovich123 3y ago
  I didn’t mean to imply that glibc’s API isn’t stable. Just that the stable API boundary for the kernel on Linux is the syscall ABI, not libc.
  - mikepavone 3y ago
    Ah sorry, I misunderstood
    - vlovich123 3y ago
      No worries. My wording was muddled.
  - dfox 3y ago
    Another stable ABI boundary is anything produced by glibc that can be conceivably placed into memory shared by different unrelated processes (ie. Posix IPC primitives). The requirement for backwards compatibility and architecture variant compatibility (32b/64b…) is the largest reason why things like pthread_mutex have somewhat large overhead and why it is worthwhile to invent various iterations of “futex in userspace”.

MarekKnapek 3y ago

No, Windows has stable API and ABI named Win32 API. This comes from times of 16bit Windows and works also in x64 / ARM / ARM64, previously it worked in Alpha / MIPS / IA64. This API is implemented in kernel.dll user.dll gdi.dll advapi.dll and similar, it does some stuff, but mostly forwards to the NT API. Beware, kernel.dll is user space component despite its name (historical reasons). NT API is undocumented and not meant to be used by user programs, it is not stable, it lives in ntdll.dll, it does syscalls to the kernel: ntoskrnl.exe. Windows doesn't have a libc (for user programs, it has private one for its own programs), Visual Studio has a libc. Each version of Visual Studio (roughly) has its own libc named msvcrt.dll msvrt100.dll msvcrt140.dll and similar, it hosts the C and C++ libc, it could be linked statically for various benefits and drawbacks.

aseipp 3y ago
Windows does actually have a universal C runtime library now, but it's pretty recent; only Windows 10+ https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-c... A big motivation for it was security posture; it means that Microsoft can now ship security updates to UCRT that everyone can rely on rather than a ton of extra surface area through various multiple versions of runtime libraries.
- actionfromafar 3y ago
  It had (has) an unsupported, crippled, unversioned msvcrt.dll which if you used it very carefully with a subset of functions, you could write programs which worked fine on Windows NT and up.
monocasa 3y ago
FWIW, large swaths of ntdll are documented and supported these days, for performing work that can't be expressed via the win32 API like raw disk manipulation.

deleted 3y ago

[deleted]