5 ms·

> Can't be done. The libc is legacy, it can't be changed without breaking everything. It's also mandatory on every operating system other than Linux. Windows e

> Can't be done. The libc is legacy, it can't be changed without breaking everything. It's also mandatory on every operating system other than Linux. Windows explicitly does not want you to link the system libc. You are expected to bring your own, and doing so means your process has multiple libc's loaded into its address space. And if you choose to build a binary that doesn't need a libc, you won't be bringing one.

matheusmoreira 2mo ago
> You are expected to bring your own, and doing so means your process has multiple libc's loaded into its address space. That only massively compounds the problem. > And if you choose to build a binary that doesn't need a libc, you won't be bringing one. NT system calls are not stable. You still need to link against ntdll.dll at the very least, like a forced Linux vDSO.
- dwattttt 2mo ago
  > That only massively compounds the problem. The Windows ecosystem, that manages to deliver built binaries easily & widely, regardless of whether the author has a 1 year old OS or a 15 year old OS, suggests that it's not as big a problem as you believe.
  - matheusmoreira 2mo ago
    It's not a problem in the same way that things like snap or flatpak aren't problems. It works but it bloats things up considerably and makes you wonder where it all went so wrong. I mean, dozens of slightly incompatible runtimes inside a single process?
    - dwattttt 2mo ago
      Those incompatible runtimes are separated by a linker that doesn't resolve all symbols globally, but rather scoped to the shared object they're expected from. They all coexist happily, and if you're so inclined you could resolve the same symbol from each, if you had reason to do so.
delta_p_delta_x 2mo ago
> Windows explicitly does not want you to link the system libc This is categorically false; UCRT[1] is a thing. The 'U' stands for universal. Unlike Linux, Windows allows developers to choose their ABI boundary and also ship that boundary if they desire, or use the 'system' one and ask older platforms to install redistributables or Windows update packages. There's the old and new C runtimes in MSVCRT.DLL and UCRTBASE.DLL, the C++ runtime in VCRUNTIME140.DLL, Win32 in KERNEL32.DLL, USER32.DLL and more, and then the stable-ish kernel interfaces in NTDLL.DLL, in order of 'closeness to the kernel'. And also, 'libc' is a UNIXism; on Windows the term is CRT, for 'C runtime'. [1]: https://learn.microsoft.com/en-gb/cpp/porting/upgrade-your-code-to-the-universal-crt?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/porting/upgrade-your-c...
- dwattttt 2mo ago
  By "system libc" I'm only referring to msvcrt.dll, found in the Windows directory. Quoting Raymond Chen: > At some point, the decision was made to just give up and declare it an operating system DLL, to be used only by operating system components. https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=1273 https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12...
  - delta_p_delta_x 2mo ago
    I think the grander point is that there is no real 'system CRT' on Windows; as I mentioned, there are multiple entry points each at an appropriate level of abstraction available to both platform and application developers (not that there is a real difference between the two, since platform developers may also write applications like Office). Many Windows platform libraries (WIL, for instance) themselves use UCRT instead of MSVCRT now. The latter exists, but it is by no means and has not ever been by any means the single entry point to the Windows platform, unlike glibc on most desktop Linux distributions.
    - okanat 2mo ago
      You can completely skip all CRTs on Windows and still have a program that can call dynamic loader and other Win32 APIs. Here is a tutorial: https://nullprogram.com/blog/2023/02/15/ https://nullprogram.com/blog/2023/02/15/ When you link with UCRT your specific program just gets a "view" of standard C functions. You can load DLLs that were linked with MSVCRT from a UCRT program. It just works

matheusmoreira 2mo ago

> You are expected to bring your own, and doing so means your process has multiple libc's loaded into its address space. That only massively compounds the problem. > And if you choose to build a binary that doesn't need a libc, you won't be bringing one. NT system calls are not stable. You still need to link against ntdll.dll at the very least, like a forced Linux vDSO.

dwattttt 2mo ago
> That only massively compounds the problem. The Windows ecosystem, that manages to deliver built binaries easily & widely, regardless of whether the author has a 1 year old OS or a 15 year old OS, suggests that it's not as big a problem as you believe.
- matheusmoreira 2mo ago
  It's not a problem in the same way that things like snap or flatpak aren't problems. It works but it bloats things up considerably and makes you wonder where it all went so wrong. I mean, dozens of slightly incompatible runtimes inside a single process?
  - dwattttt 2mo ago
    Those incompatible runtimes are separated by a linker that doesn't resolve all symbols globally, but rather scoped to the shared object they're expected from. They all coexist happily, and if you're so inclined you could resolve the same symbol from each, if you had reason to do so.

delta_p_delta_x 2mo ago

> Windows explicitly does not want you to link the system libc This is categorically false; UCRT[1] is a thing. The 'U' stands for universal. Unlike Linux, Windows allows developers to choose their ABI boundary and also ship that boundary if they desire, or use the 'system' one and ask older platforms to install redistributables or Windows update packages. There's the old and new C runtimes in MSVCRT.DLL and UCRTBASE.DLL, the C++ runtime in VCRUNTIME140.DLL, Win32 in KERNEL32.DLL, USER32.DLL and more, and then the stable-ish kernel interfaces in NTDLL.DLL, in order of 'closeness to the kernel'. And also, 'libc' is a UNIXism; on Windows the term is CRT, for 'C runtime'. [1]: https://learn.microsoft.com/en-gb/cpp/porting/upgrade-your-code-to-the-universal-crt?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/porting/upgrade-your-c...

dwattttt 2mo ago
By "system libc" I'm only referring to msvcrt.dll, found in the Windows directory. Quoting Raymond Chen: > At some point, the decision was made to just give up and declare it an operating system DLL, to be used only by operating system components. https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=1273 https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12...
- delta_p_delta_x 2mo ago
  I think the grander point is that there is no real 'system CRT' on Windows; as I mentioned, there are multiple entry points each at an appropriate level of abstraction available to both platform and application developers (not that there is a real difference between the two, since platform developers may also write applications like Office). Many Windows platform libraries (WIL, for instance) themselves use UCRT instead of MSVCRT now. The latter exists, but it is by no means and has not ever been by any means the single entry point to the Windows platform, unlike glibc on most desktop Linux distributions.
  - okanat 2mo ago
    You can completely skip all CRTs on Windows and still have a program that can call dynamic loader and other Win32 APIs. Here is a tutorial: https://nullprogram.com/blog/2023/02/15/ https://nullprogram.com/blog/2023/02/15/ When you link with UCRT your specific program just gets a "view" of standard C functions. You can load DLLs that were linked with MSVCRT from a UCRT program. It just works