3 ms·

> 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, Win

> 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
    - dwattttt 2mo ago
      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=112152/ https://devblogs.microsoft.com/oldnewthing/20260319-00/?p=11... arm64: https://devblogs.microsoft.com/oldnewthing/20260320-00/?p=112154/ https://devblogs.microsoft.com/oldnewthing/20260320-00/?p=11...
pjmlp 2mo ago
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.
- delta_p_delta_x 2mo ago
  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.
matheusmoreira 2mo ago
> 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".
- delta_p_delta_x 2mo ago
  > 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.
  - matheusmoreira 2mo ago
    > 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 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-echo.ln 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 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 https://www.matheusmoreira.com/articles/linux-system-calls
stevefan1999 2mo ago
> There's the old and new C runtimes in MSVCRT.DLL Some advertisement for VC-LTL: https://github.com/Chuyu-Team/VC-LTL5 https://github.com/Chuyu-Team/VC-LTL5 and https://github.com/Chuyu-Team/YY-Thunks 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.

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
  - dwattttt 2mo ago
    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=112152/ https://devblogs.microsoft.com/oldnewthing/20260319-00/?p=11... arm64: https://devblogs.microsoft.com/oldnewthing/20260320-00/?p=112154/ https://devblogs.microsoft.com/oldnewthing/20260320-00/?p=11...

pjmlp 2mo ago

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.

delta_p_delta_x 2mo ago
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.

matheusmoreira 2mo ago

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

delta_p_delta_x 2mo ago
> 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.
- matheusmoreira 2mo ago
  > 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 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-echo.ln 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 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 https://www.matheusmoreira.com/articles/linux-system-calls

stevefan1999 2mo ago

> There's the old and new C runtimes in MSVCRT.DLL Some advertisement for VC-LTL: https://github.com/Chuyu-Team/VC-LTL5 https://github.com/Chuyu-Team/VC-LTL5 and https://github.com/Chuyu-Team/YY-Thunks 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.