3 ms·
No, linking to a static version of the CRT is a good thing, it cuts out the unused code. If you dynamic link to MSVCRxx/VCRUNTIME, you force the user to downlo
by Dwedit 1y ago
No, linking to a static version of the CRT is a good thing, it cuts out the unused code. If you dynamic link to MSVCRxx/VCRUNTIME, you force the user to download that exact DLL from Microsoft. Dynamic linking to MSVCRT doesn't have that problem, but it's very hard to do in Visual Studio.
The only time you really can't static link to the CRT is LGPL compliance?
- TonyTrapp 1y agoNote that the project is using mingw, so it's not using any Microsoft DLLs for the CRT anyway. mingw brings its own CRT along.
- Dwedit 1y agoI thought Mingw defaulted to MSVCRT.DLL as the CRT?
- TonyTrapp 1y agoIt looks looks mingw actually has several options to base its own CRT on (including MSVCRT, UCRT and various VS runtimes). Still, in the context of OP's original post, we are talking about the mingw DLLs that may or may not redirect most of their duties to Microsoft DLLs, depending on how mingw is configured.
- actionfromafar 1y agoIt's really hard these days to get Mingw to use msvcrt. It's not supported.
- int_19h 1y agoWindows has been shipping an up-to-date, modern CRT in the box for a decade now (Win10+), and MinGW will even dynamically link to it by default. Even on out-of-support OSes like Vista and Win7, users who have all the security updates installed will have it. So you have to unwind all the way back to WinXP for a version of Windows that doesn't have uCRT out of the box. There's absolutely no reason to statically link CRT in a Win32 app today. Especially not if your goal is to minimize .exe size.