[TonyTrapp]

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.

[Const-me]

> such as time.h and string.h

In Windows, the APIs provided by the OS are IMO better than these C standard headers.

WinAPI date/time is more precise, the kernel keeps int64 number of 100 nanosecond ticks. WinAPI supports arbitrary timezones, has functions to convert between timezones, has functions to deal with daylight saving.

About strings, WinAPI can convert strings between encodings, case-insensitive comparisons (including a version to use arbitrary locale), Unicode normalization, etc.

[int_19h]

The CRT has been an OS component on Windows for a decade now:

https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-c...

MinGW does not provide its own CRT. Historically, it used msvcrt.dll, which is the old and outdated CRT for VC++ 6.0 that was included in Windows a long time ago. These days it can also use uCRT, and that is indeed the new default:

https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64...

[throwanem]

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]

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]

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

[int_19h]

> These days it's perfectly solved

If you mean maintaining separate versions of the same dependency, that doesn't "perfectly solve" the problem because you still can't take an object returned from one library (or something that depends on it and exposes that dependency) and pass it to another library without breakage, which can often be silent and subtle.