undefined

points

[-]

> 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-c...

by matheusmoreira17 minutes ago|

parent|

[-]

> Unlike Linux, Windows allows developers to choose their ABI boundary

Linux has a stable system call ABI. I can trash the entire user space and boot Linux with init=/my/program if I want.

It's not that Linux doesn't allow developers to choose, it's that Linux doesn't actually control the userspace ABIs. Userspace is whatever we want it to be, and people settled on "GNU/Linux".

by pjmlp39 minutes ago|

parent|

prev|

[-]

That was introduced in Windows 10, Windows history is a long one.

Usually Windows developers will use Win32 directly, ZeroMemory() instead of memset(), and so on.

by delta_p_delta_x36 minutes ago|

parent|

[-]

Indeed. I was just about to point out the fact that the CRT only provides the C standard library; Windows applications can run perfectly fine without one by linking only to the Windows API DLLs.

by dwattttt1 hours ago|

parent|

prev|

[-]

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=12...

by delta_p_delta_x41 minutes ago|

parent|

[-]

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.

by matheusmoreira2 hours ago|

prev|

[-]

> 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.

by dwattttt2 hours ago|

parent|

[-]

> 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.

by matheusmoreira2 hours ago|

parent|

[-]

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?

by dwattttt1 hours ago|

parent|

[-]

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.