I would argue that we have that today in the form of the Apple MacMini (https://www.apple.com/shop/buy-mac/mac-mini) -- the Commodore 64 was priced at around $300 in 1984 or $950 in 2025 money. The basic model MacMini comes in at $600 today. For that you get a fully Unix system with a full development suite to build desktop/mobile/Unix apps out of the box. Every development platform is available (C/C++, Python, Swift, JavaScript, Java, Rust, etc.) on it. The expansion system is extremely simple also (USB C/Thunderbolt). Not to mention it is much smaller than a Commodore 64 and arguably more user friendly.
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.
That 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.
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.
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.
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...
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.
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.
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 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.
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.
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.
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:
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.
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"
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.)
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.
Not 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.
This code is not from the Petzold books. It literally includes and uses string.h, stdlib.h and time.h. It is not using WinAPI equivalents of C functions.
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?
Windows 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.
It 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.
My uncle bought a TI-99/4A when Texas Instruments were blowing them out for $49 around the summer of 1987 or so. Played Parsec with the voice module and that was it - I was hooked. I needed to figure out how it did this. Started with the BASIC programming books that came with the machine.
Begged my parents until they bought me a Commodore 64 with a 1541 drive. I go a subscription to Compute's Gazette and typed in programs and figured out how they worked. Graduated to Richard Mansfield's Machine Learning for Beginners (https://archive.org/details/Compute_s_Machine_Language_for_B...) and I was on my way. And poured over the 'Antatomy of the Commodore 64' which had a dump of the annotated ROM firmware and poured over it to learn the machine inside and out (https://archive.org/details/The_Anatomy_of_the_Commodore_64/...)
And finally - dove into 'The Kracker Jax Revealed Books 1, 2, 3' (https://www.lyonlabs.org/commodore/onrequest/the_kracker_jax...) to learn all the protection schemes and how they were implemented to work around them. This taught me all of the tricks of disk access/memory compression, encryption and obfuscation. This really showed me a lot of how low level coding to control micro controllers/memory access/hardware level coding etc.
I had about four friends in school from 4th grade to high school graduation that had 64s and we would spend lunch and recess discussing what we learned/hacked/discovered the night before. Sure we were outcasts - but then we were so obsessed within our little world we could care less about the petty teenage drama around us.
Good times. I miss those days. I look at kids today and feel kind of sad that they lack the opportunity and/or the patience to do anything like that.
TI's price war with Commodore went into high gear in 1983, and TI pulled out of the market in '84. So your early experiences with the TI-99/4A were probably a bit earlier than you remember.
I had a similar story -- my grandfather grabbed one for $50 at, IIRC, JC Penney and gave it to me for my 4th birthday in 1983. Got my start with TI-BASIC as a young kid, then GW-BASIC on an XT clone a few years later. Then came Scheme, Pascal, C, C++, Java, Python, PHP, JavaScript...
Yes - you are completely right. I just looked up my receipt for my C64 and it was Dec. of 1984. Still have it all! So long ago, yet seems like yesterday :)
Experienced generalist software engineer, tech lead with 27+ years of software experience. Reliable-software enthusiast. Interested in everything. Idea generator. Start-up to large corporate experience, Ex-McKinsey
Experienced generalist software engineer, tech lead with 27+ years of software experience. Reliable-software enthusiast. Interested in everything. Idea generator. Start-up to large corporate experience, Ex-McKinsey
So many memories. This game was a masterpiece. I spent three weeks missing class (nearly failing my compiler construction class) and broke up with a girlfriend playing this game. Glad they don't make games like this anymore.
This is not going to change anything - Apple makes $109,229 per second(https://tipalti.com/profit-per-second/) - this so called penalty is 3.8 hours of Apple's profit. This is equivalent to a parking ticket for Apple.
Not that it changes much beyond the US GDP but you labeled the per minute figure per second.
Impact aside, which is should absolutely impact more, I'm almost doubtful the practice is even a net loss for them. ${years} of the hiring practice for an unknown number of individuals may have even been worth more than the fine.
Some other comments note it may have other impacts though, so maybe that's the real influence.
Apple didn't bring programming to the masses - for the following reason:
- Just to expensive. The Apple Macintosh in January 1984 cost $2500 - thats $7000 dollars in todays money!
- Too complex to get started. The amount of knowledge to successfully write anything really useful in 1984 on that make was a huge barrier to entry - you had to learn ObjectPascal, the then new GUI concepts, somehow get your hands on CodeWarrior (another expensive software package) and learn the UI of CodeWarrior.
- Documentation was poor. The system shipped with nothing mentioning any of this or the hardware underpinnings.
The Mac was designed as an end user 'consumption' machine, not a development machine. Nothing wrong with that - as the market had shown it was highly proficient and successful in its intended role.
The company (in the US at least) that brought programming to the masses was Commodore.
- IT WAS CHEAP! With the release of the Commodore 64 it brought the a super sophisticated system at bargain basement prices. By early 1985 the C64's price was $149 (https://en.wikipedia.org/wiki/Commodore_64) - thats $420 in todays money. A complete system with a 1541 disk drive & monitor cost a total $549 (https://www.mclib.info/Research/Local-History-Genealogy/Hist...) or $1,547 in todays money. A computer with 64K, 16 color graphics, a revolutionary 3 voice synthesizer capable of speech, and a massive software library and peripherals.
- It came with everything you need to to write code. The system booted into a BASIC interpreter REPL which served as its command line also. No additional software needed.
- The info that it shipped with was phenomenal. The manual shipped with the computer actually give you a nice tutorial on the basics of writing code, with examples of color graphics, sound generation, sprites and accessing peripherals (https://www.commodore.ca/manuals/c64_users_guide/c64-users_g...) You could write to Commodore and they would actually send you a schematic of the main board and expansion ports as well as a dump of the ROM so you could look at the actual code that the system used to do what it did.
It was an amazing time to be a young Commodore 64 programmer back then. Heck even the company's slogan was "Computing for the masses, not the classes". And with the Commodore 64 they lived that slogan.
The interesting thing is that todays Apple is even more friendly than Commodore was to the budding developer - with the MacMini line and the Unix underpinnings of the MacOS X, there isn't a better beginner developer system than Apple today.
Apple in many ways, learned its lessons and adapted. Commodore unfortunately - so Apple Mac of today is bringing programming to the masses.
All of my nieces and nephews - I bought them an iMac mini for last Christmas and showed them how to use the terminal and python - and they are on their way.
They were terrified of Java and the JVM that went along with it, as it would make their cash cow - Windows possibly redundant. They basically switched everything to .Net and the CLR.
Also, you are looking at VB through rose tinted glasses. VB was a terrible system to build products on:
- Poor language. BASIC is not, as implemented by VB, a production level language. I am sure folks will argue that point, but I will stand by it.
- The component model was terrible - you had to drop in to C and use OLE/DCOM to create components for it. A VB dev couldn't create components directly in VB.
- DLL HELL. Shipping VB code was a nightmare.
Delphi was an answer to all of this - but Microsoft killed that too by stealing Anders Hejlsberg, whow went on to create the .Net frameworks, implementing many of the Delphi innovations in a Microsoft ecosystem.
My simple rules about money and investing for the future:
- Max out 401K and place it in S&P 500 mutual fund
- Take an additional 15% and but into an S&P 500 mutual fund
- Don't look at it, just keep buying at regular intervals until you decide to retire.
The rest of your money - do what you wish (within reason) and stay out of debt.
