5 ms·

Well... Who told you to link to MSVCRT (the one in System32)? Not Microsoft that's for sure. New software is supposed to link to the Visual Studio C runtime it

Well... Who told you to link to MSVCRT (the one in System32)? Not Microsoft that's for sure. New software is supposed to link to the Visual Studio C runtime it was compiled with and then ship that library alongside the application itself. Even if you don't compile with VS you can distribute the runtime library (freely downloadable from some page on microsoft.com). Ostensibly, that library contains an efficient malloc. If you willingly link to the MSVCRT Microsoft for over a decade has stated is deprecated and should be avoided you are shooting yourself in the foot. "Windows is not a Microsoft Visual C/C++ Run-Time delivery channel" https://devblogs.microsoft.com/oldnewthing/20140411-00/ https://devblogs.microsoft.com/oldnewthing/20140411-00/

spatulon 4y ago
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.
sterlind 4y ago
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 4y ago
  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.
  - Dylan16807 4y ago
    But if you're using it for yourself you wouldn't want to put it in system32.
    - chunkyks 4y ago
      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 4y ago
        Yes but I think that's separate from a newer installer using one of these newer runtimes.
  - saagarjha 4y ago
    I don’t usually bug people about this but you mean “MSIs”, not “MSI’s”. They mean different things in this context.
- naikrovek 4y ago
  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.
- legalcorrection 4y ago
  It’s so the system can update the runtime when security vulnerabilities and such are discovered.
mananaysiempre 4y ago
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 4y ago
  Yes, it is.
userbinator 4y ago
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...
nice_byte 4y ago
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 4y ago
  He updated the text after the article hit HN: https://web.archive.org/web/20220702095817/https://erikmcclure.com/blog/windows-malloc-implementation-is-a-trash-fire/ 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.

spatulon 4y ago

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.

sterlind 4y ago

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 4y ago
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.
- Dylan16807 4y ago
  But if you're using it for yourself you wouldn't want to put it in system32.
  - chunkyks 4y ago
    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 4y ago
      Yes but I think that's separate from a newer installer using one of these newer runtimes.
- saagarjha 4y ago
  I don’t usually bug people about this but you mean “MSIs”, not “MSI’s”. They mean different things in this context.
naikrovek 4y ago
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.
legalcorrection 4y ago
It’s so the system can update the runtime when security vulnerabilities and such are discovered.

mananaysiempre 4y ago

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 4y ago
Yes, it is.

userbinator 4y ago

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

nice_byte 4y ago

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 4y ago
He updated the text after the article hit HN: https://web.archive.org/web/20220702095817/https://erikmcclure.com/blog/windows-malloc-implementation-is-a-trash-fire/ 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.