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

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.

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

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.

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/

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

That's a pretty great article. Re. the stack probes, it's not hard to supply your own; Raymond Chen recently did a blog series on stack probes, the entries for amd64 and arm64 are here:

amd64: https://devblogs.microsoft.com/oldnewthing/20260319-00/?p=11...

arm64: https://devblogs.microsoft.com/oldnewthing/20260320-00/?p=11...

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

> Linux has a stable system call ABI

This is a noble but practically worthless ideal. Hardly anything is written against the kernel ABI except glibc itself. End-user application developers don't write against the kernel interface. Platform library and application developers like KDE and GNOME don't really write against the kernel interface either. Nowadays even driver developers don't entirely write against the kernel interface, instead also linking in glibc and lib{std}c++ for things like shader compilers (which is nowadays usually just a fork of Clang). Like it or not, glibc is the singular entry point for desktop Linux, which is the point of essentially every comment under this post.

That 'desktop Linux ≡ glibc' is something that I daresay the kernel developers also have to take responsibility for, rather than shrugging their shoulders and pawning it off to GNU. Linux's unstable user-mode is the entire reason for Docker's existence. It is bodge upon bodge and has led to much gnashing of teeth. The GNU/Linux community (I don't care for Stallman's meme rant here) have to grow a backbone and understand that an OS is much more than just a kernel, it is a platform, and currently the Linux platform is a disparate set of communities with highly divergent goals.

That's why I've always said the best Linux is Android, because Android is a platform.

> Hardly anything is written against the kernel ABI except glibc itself.

I'm working hard to change that.

Here's an entire lisp interpreter written in freestanding C using nothing but Linux system calls:

https://github.com/lone-lang/lone

It has a system-call primitive too, which means it can do anything.

Here's a TCP echo server written in lone lisp:

https://github.com/lone-lang/lone/blob/master/examples/tcp-e...

It works, and you don't need libc.

> Like it or not, glibc is the singular entry point for desktop Linux

Well I don't like it, and I've made it my mission to fix it.

Maybe lisp isn't the answer, Rust is. I've revived my liblinux crate too.

https://github.com/matheusmoreira/liblinux

I'm going to add system calls to this thing every day until I have every single one. Then I'll use them to make all of my applications.

Already have my first project planned: a custom Rust network stack for my QEMU virtual machines so I can firewall them off in userspace without root access.

> the Linux platform

The linux platform is these system calls. Everything else is userspace. This is exactly what makes it special.

https://www.matheusmoreira.com/articles/linux-system-calls

> The linux platform is these system calls. Everything else is userspace. This is exactly what makes it special.

This is exactly the attitude I meant by 'the kernel developers also have to take responsibility for, rather than shrugging their shoulders and pawning it off to GNU' and 'an OS is much more than just a kernel, it is a platform'.

By 'platform', I mean windowing toolkits, such as Wayland. Audio libraries like ALSA and PipeWire. Desktop idioms and libraries like DBus, and the entire freedesktop.org effort including Mesa and more. Init systems like systemd. Bootloaders like GRUB/systemd-boot. Networking, including systemd-networkd, iwd, and NetworkManager. Power and device management including PowerDevil, Bluez.

If all of this is considered 'user space' then my point is strongly vindicated. On most competitor OSs these comprise the 'platform'. You won't ever encounter a Windows or OS X developer arguing that USER32.DLL or Foundation is 'userspace' even if it is technically true and code from those libraries may only ever run in ring 3. From the average user's point of view, the only 'userspace' are end-user applications that they have installed, like Chrome, video games, etc. From that perspective, even purely user-mode applications that ship with the distro ought to considered 'platform'. This includes such trivia like calculator and camera applications.

We need to talk about the practical realities of a platform, not a theoretical, unattainable, and as I mentioned, useless ideal. These practical realities mean shipping a unified set of useful 'batteries included' user-mode libraries and applications. If one wants to develop the platform itself, then sure, the kernel has a nice stable interface, but on most Linux distributions the kernel is built from source anyway, so even that nicety is moot.

> By 'platform', I mean

You mean Linux distributions.

> From that perspective, even purely user-mode applications that ship with the distro ought to considered 'platform'.

Every Linux distribution is its own platform.

You decried Stallman's meme rant yet you just rewrote the entire rant in your own terms. Linux is the kernel, GNU's just the stuff on top. You can get rid of it if you want and make your own. Android did exactly that.

It's more than a little funny that you disparage syscalls being Linux's stable interface, and then immediately praise Android, which only works because glibc isn't uniquely privileged the way you seem to want.

Also, I daily drive Alpine Linux (using musl) and I'm quite happy to assure you that glibc really is only one option, not at all mandatory for desktop Linux.

> It's more than a little funny that you disparage syscalls being Linux's stable interface, and then immediately praise Android, which only works because glibc isn't uniquely privileged the way you seem to want.

I never disparaged it; I said having it doesn't make it any more useful that OSs that don't, because the practical reality is that the kernel interface is narrow and highly technical, and a stable kernel binary interface has little to do with a user's day-to-day experience with an OS.

I daresay Android would still work pretty well even sans the kernel ABI stability, because the kernel is usually built from source, and if it isn't, then every Android source tree has kernel prebuilts for the kernel version shipping. I also never said nor implied glibc should be uniquely privileged; I think you have misrepresented my comment.

> There's the old and new C runtimes in MSVCRT.DLL

Some advertisement for VC-LTL: https://github.com/Chuyu-Team/VC-LTL5 and https://github.com/Chuyu-Team/YY-Thunks

VC-LTL Implements a good subset of modern CRT functions using the msvcrt.dll, which makes modern MSVC compiler to emit binaries that theoretically can run in Windows NT 4.1 or Windows 98 (until CFG broke them, but you can turn it off). Still can teach an old dog new tricks.

YY-Thunk is a little more funky, it tries to implement new Win32 userspace API for old system by emulating the behavior and expected values using userspace API in the old apartment, so you can try to implement a function in Windows 10 with functions in Windows Vista, and hopefully it will work out.

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

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

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?

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.