Well... Who told you to link to MSVCRT (the one in System32)? Not Microsoft that...

sterlind · on July 2, 2022

there's a weird licensing thing for the VC runtime where you can't redistribute the dll alongside your code unless you have a special license. instead, you have to install it as an MSI. I have no idea why they created that restriction. I even work for MS and it baffles me.

londons_explore · on July 2, 2022

At one point MS was very keen for people to use MSI's rather than building custom installers that jam things into system32. Perhaps that was why.

saagarjha · on July 3, 2022

I don’t usually bug people about this but you mean “MSIs”, not “MSI’s”. They mean different things in this context.

Dylan16807 · on July 2, 2022

But if you're using it for yourself you wouldn't want to put it in system32.

chunkyks · on July 3, 2022

There was a looong period of time where a lot of developers felt entirely free to drop whatever they wanted into c:\Windows, System, System32, whatever. It's a big part of what led to windows getting a reputation for being poorly behaved/crashy/slow over time [leading to a lot of "have you tried reinstalling windows?" recommendations]

Dylan16807 · on July 3, 2022

Yes but I think that's separate from a newer installer using one of these newer runtimes.

legalcorrection · on July 3, 2022

It’s so the system can update the runtime when security vulnerabilities and such are discovered.

naikrovek · on July 2, 2022

probably so it gets a consistent installation location that is protected by the operating system. read the Raymond Chen blog post linked here a few times to see why not doing this has bitten Microsoft in the past.

userbinator · on July 3, 2022

Even if you don't compile with VS you can distribute the runtime library

...which is about two orders of magnitude bigger than the applications I write, so that's already a huge DO NOT WANT. Don't even get me started on the retarded UCRT mess that newer VS seems to force you to use...

mananaysiempre · on July 2, 2022

Isn’t every (release-mode) Microsoft CRT malloc a thin wrapper around KERNEL32!HeapAlloc (thus eventually NTDLL!RtlAllocateHeap)? CRTDLL did it, MSVCRT did it, UCRTBASE still seems to be doing it.

Tringi · on July 3, 2022

Yes, it is.

spatulon · on July 2, 2022

I suspect they are actually talking about the modern/redistributable C/C++ runtime, not the old msvcrt.dll.

Microsoft refer to the modern libraries as the "Microsoft C and C++ (MSVC) runtime libraries", so shortening that to MSVCRT doesn't seem unreasonable.

nice_byte · on July 3, 2022

i'm not sure which part of the post gave you the impression that it's linking against the one in system32. the author even says:

> it's statically linking with the CRT shipped with Visual Studio

that is, unless you know for a fact that they're wrong and clang uses the msvcrt from system32. in which case this seems like clang's fault?

bjourne · on July 3, 2022

He updated the text after the article hit HN: https://web.archive.org/web/20220702095817/https://erikmcclu...

The C runtime shipped in Windows is called MSVCRT.DLL and the ones shipped in Visual Studio are called MSVCRxxx.DLL, where xxx is Visual Studio's version number. If he statically linked to MSVCRxxx.DLL (MSVCRxxx.LIB actually) then what version did he link to? The performance of malloc() differs between versions.

Clang doesn't ship its own C/C++ runtime and certainly can link to MSVCRT.DLL. That is how legacy applications are built.