3 ms·

The 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 Microso

The 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 ago
The 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 ago
  The 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 ago
    MSVCRT works perfectly fine for something with this feature set.
    - TonyTrapp 1y ago
      I 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 ago
  Regarding 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.
  - throwanem 1y ago
    Ugh, thanks. That clears it up. Say what you like about the modern JS ecosystem, the practical requirement of a single exhaustive declaration of all external dependencies and their sources is not to be sneered at.
    - tacker2000 1y ago
      i get you, but this also introduces a whole other set of issues, like "dependency hell", where if you update one package you need to re-jig everything else. Things were just moving much slower back "in the days"
      - throwanem 1y ago
        Dep version clashes were a problem until iirc some time about mid-late last decade, say ~2017. These days it's perfectly solved at some cost in storage and memory, which in entire fairness are lately about as cheap as any other resource. There is also lately a movement in the space significantly away from "taking dependencies," a phrase I quote to highlight its pejorative connotation: presumptively undesirable, however necessary. If a large language model is satisfactorily efficient for 2025, then to scruple over the disk space and RAM used in the current model of exhaustive dependency resolution employed by modern JS/TS package managers, seems impossible to regard as other than ideologically motivated. In any case, I took some care earlier to avoid talking beyond the package.json dependency declaration model, in hopes of forestalling precisely this bikeshed. If you want to talk further about things that don't interest me in this context, please find someone else with whom to do so. (I don't wish to seem rude in this. Only that I have had that discussion too many more times than I can count, and I have long since stopped expecting it to vary noticeably in a given iteration.)
jug 1y ago
Why would you not link against the UCRT if you’re intentionally designing for Win32 though? It’s a decade old library by now. Time flies…
- TonyTrapp 1y ago
  Some people value being able to support older OSes without shipping the entire UCRT as an optional component. Granted, this will become less and less relevant in the future...
  - int_19h 1y ago
    At this point, the only Windows version which doesn't ship uCRT that's not out of support is Windows Server 2012 R2 VL, and even that is only supported through the paid Extended Security Updates program which ends next year.

throwanem 1y ago

The 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 ago
The 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 ago
  MSVCRT works perfectly fine for something with this feature set.
  - TonyTrapp 1y ago
    I 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 ago
Regarding 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.
- throwanem 1y ago
  Ugh, thanks. That clears it up. Say what you like about the modern JS ecosystem, the practical requirement of a single exhaustive declaration of all external dependencies and their sources is not to be sneered at.
  - tacker2000 1y ago
    i get you, but this also introduces a whole other set of issues, like "dependency hell", where if you update one package you need to re-jig everything else. Things were just moving much slower back "in the days"
    - throwanem 1y ago
      Dep version clashes were a problem until iirc some time about mid-late last decade, say ~2017. These days it's perfectly solved at some cost in storage and memory, which in entire fairness are lately about as cheap as any other resource. There is also lately a movement in the space significantly away from "taking dependencies," a phrase I quote to highlight its pejorative connotation: presumptively undesirable, however necessary. If a large language model is satisfactorily efficient for 2025, then to scruple over the disk space and RAM used in the current model of exhaustive dependency resolution employed by modern JS/TS package managers, seems impossible to regard as other than ideologically motivated. In any case, I took some care earlier to avoid talking beyond the package.json dependency declaration model, in hopes of forestalling precisely this bikeshed. If you want to talk further about things that don't interest me in this context, please find someone else with whom to do so. (I don't wish to seem rude in this. Only that I have had that discussion too many more times than I can count, and I have long since stopped expecting it to vary noticeably in a given iteration.)

jug 1y ago

Why would you not link against the UCRT if you’re intentionally designing for Win32 though? It’s a decade old library by now. Time flies…

TonyTrapp 1y ago
Some people value being able to support older OSes without shipping the entire UCRT as an optional component. Granted, this will become less and less relevant in the future...
- int_19h 1y ago
  At this point, the only Windows version which doesn't ship uCRT that's not out of support is Windows Server 2012 R2 VL, and even that is only supported through the paid Extended Security Updates program which ends next year.