13 ms·
Looks like you are linking to static libraries. You should link to DLL not to static libraries - this is will cut down on the application size dramatically.
by vparikh 1y ago
Looks like you are linking to static libraries. You should link to DLL not to static libraries - this is will cut down on the application size dramatically.
- TonyTrapp 1y agoThat seems backwards. If you need to ship the DLLs with the program anyway (they are not part of the operating system, after all), they will contain their full functionality, each one potentially with its own C runtime, etc. If you statically compile everything into a single EXE, there will be only a single C runtime, all unused functions can be trivially removed, etc. DLLs only reduce size if their code is meant to be shared between different programs.
- throwanem 1y ago> they are not part of the operating system Yes they are. Exercising the native Windows API is the entire point of this project, and the only artifact it builds is an executable. edit: See the thread; I had the wrong end here. I haven't worked with Win32 or C in so long I'd forgotten what balls of fishhooks and hair they both tend to be.
- deleted 1y ago[deleted]
- TonyTrapp 1y agoThe CRT is not part of the operating system, unless you count the UCRT on Windows 10 onwards (yes there is also a MSVCRT copy in the Windows folder that Microsoft strongly discourages you from using, so let's ignore that for now). So unless you link against the system-provided UCRT, you will have to either ship a dynamic or a static copy of the C runtime, and linking it statically will be smaller because that will only contain the few string and time functions used by the program, instead of the whole CRT.
- throwanem 1y agoThe idea that something which ships with the OS, as a compatibility shim for legacy but still intentionally supported applications, can be called "not part of the OS," is religious. Strongly discouraged or otherwise, I believe it to be in use here. Not sure. I haven't really done anything serious with MinGW, or Cygwin or even Windows really, in at least a decade now. But there's not really a lot going on in the build here, so I would imagine with your much more recent experience you'd be better able to interpret what's there. edit: Wait, are you even discussing the old (okay, ancient) Win32 API? I'm confused, but as I said, it's been a very long time since I attended the space.
- TonyTrapp 1y agoThe important thing in the context of the original question is that mingw uses its own C runtime (MSVCRT is old and incomplete - you would not be able to use it as a drop-in replacement for a modern CRT). You can link the mingw CRT statically or dynamically, and OP suggested that linking it dynamically would reduce the size. But that is only true for the main executable. You would still have to ship the mingw CRT alongside, which in return would increase the distribution size of the program again. I hope that clears my point up.
- userbinator 1y agoMSVCRT works perfectly fine for something with this feature set.
- TonyTrapp 1y agoI really didn't want to get into the specifics, because the situation is already complex enough without MSVCRT, but: Yes, it is. If you wanted to do a size-optimzied version of this particular program, it would be a good enough choice.
- TonyTrapp 1y agoRegarding your edit: the CRT is responsible for headers such as time.h and string.h, which you can find being used in todo.h. Their implementations are not provided by the operating system but by the C runtime typically supplied by the compiler (mingw in this particular case). Other headers such as windows.h belong to the WinAPI, and result in functions being imported from OS libraries such as user32.dll. They are obviously not linked statically into the program.
- 90s_dev 1y agoYou must not have worked with Win32 or C recently, they both tend to be giant balls of fishhooks and hair. edit: Saw that you just now edited your comment, glad we're on the same page now.
- throwanem 1y agoQuite literally, it would seem! What an entirely remarkable coincidence.
- pjmlp 1y agoNot really, because this is Windows we are talking about. A traditonal Windows application would be using the Windows APIs, and not the C standard library, e.g. FillMemory() instead of memset(), thus there is no DLLs to ship with the application. As can be seen on Petzold books examples.
- Dwedit 1y agoNo, 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.