There is something I like about win32 gui programming. It's a little idiosyncratic, but if you read Raymond Chen's blog you'll see why.
The win32 API has its origins on the 8088 processor and doing things a certain way results in saving 40 bytes of code or uses one less register or something.
I wrote a lot of toy gui apps using mingw and Petzold's book back in the day. Writing custom controls, drawing graphics and text, handling scrolling, hit testing etc was all a lot of fun.
I see in your app you're using strcpy, sprintf. Any kind of serious programming you should be using the length-checked variants. I'm surprised the compiler didn't spew.
You'll also find that the Win32 API has a lot of replacements for what's in the C standard library. If you really want to try and get the executable size down, see if you can write your app using only <Windows.h> and no cstdlib. Instead of memset() you've got ZeroMemory(), instead of memcpy() you've got CopyMemory().
At some point writing raw C code becomes painful. Still, I think doing your first few attempts in raw C is the best way to learn. Managing all the minutiae gives you a great sense of what's going on while you're learning.
If you want to play more with win32 gui programming, I'd have a look at the WTL (Windows Template Library). It's a C++ wrapper around the win32 API and makes it much easier to reason about what's going on.
> There is something I like about win32 gui programming
Totally agree with you. I use an excellent PC app called AlomWare Toolbox, and it's the epitome of Win32 design (https://www.alomware.com/images/tab-automation.png), and despite it doing so much it's only about 3 MB in size because of it. No frameworks with it either, just a single executable file. I wish all software were still like this.
At minimum, these days, if you dont use strncpy instead of strcpy, you’ll have to suffer through every man and his dog (or AI tool) forever telling you to do otherwise. (For me this is one of the main arguments of using zig, a lot of these common pitfalls are minimized by using zig, but c is fine as well)
It's not really suitable for general purpose programming like the OP is doing. It won't null terminate the string if the buffer is filled, which will cause you all sorts of problems. If the buffer is not filled, it will write extra null bytes to fill the buffer (not a problem, but unnecessary).
On freebsd you have strlcpy(), Windows has strcpy_s() which will do what the OP needs. I remember someone trying to import strlcpy() into Linux, but Ulrich Drepper had a fit and said no.
You just never assume a string is null terminated when reading, using strnlen or strncpy when reading as well.
Not really possible when dealing with operating system level APIs that expect and require null-terminated strings. It's safer and less error-prone to keep everything null terminated at all times.
Or just write in C++ and use std::string, or literally any other language. C is terrible when it comes to text strings.
I am not writing in C, but always wondered, why pascal-like strings wrappers are not popular, i. e. when you have first 2 bytes represent the length of the string following by \0 terminated string for compatibility.
2 bytes is not enough, usually you'll see whole "size_t" worth of bytes for the length.
But you could do something utf-8 inspired I suppose where some bit pattern in the first byte of the length tells you how many bytes are actually used for the length.
>It won't null terminate the string if the buffer is filled, which will cause you all sorts of problems.
if you don't know how to solve/avoid a problem like that, you will have all sorts of other problems
pound-define strncopy to a compile fail, write the function you want instead, correct all the compile errors, and then, not only move on with your life, never speak of it again, for that is the waste of time. C++ std:string is trash, java strings are trash, duplicate what you want from those in your C string library and sail ahead. no language has better defined behaviors than C, that's why so many other languages, interpreters, etc. have been implemented in C.
> Everything in C is just array of bytes, some would argue uint32_t is just array of 4 bytes
That isn't how the C language is defined. The alignment rules may differ between those two types. Consider also the need for the union trick to portably implement type-punning in C. Also, the C standard permits for CHAR_BIT to equal 32, so in C's understanding of a 'byte', the uint32_t type might in principle correspond to just a single byte, in some exotic (but C compliant) platform.
Instead of memset() you've got ZeroMemory(), instead of memcpy() you've got CopyMemory().
I believe MSVC intrinsics will use the rep stos/movs instructions, which are even smaller than calling functions (which includes the size of their import table entries too.)
> You'll also find that the Win32 API has a lot of replacements for what's in the C standard library. If you really want to try and get the executable size down, see if you can write your app using only <Windows.h> and no cstdlib. Instead of memset() you've got ZeroMemory(), instead of memcpy() you've got CopyMemory().
I see he's also using fopen/fread/fclose rather than CreateFile/ReadFile/WriteFile/etc.
> I see he's also using fopen/fread/fclose rather than CreateFile/ReadFile/WriteFile/etc.
It's a todo list, not a network service. So what if it's using unbounded strcpy's all over the place? It has basically no attack surface. He wrote it for himself, not for criticism from the HN hoi polloi.
For once maybe take someone's work at face value instead of critiquing every mundane detail in order to feel like the smartest person in the room.
Computers are tools to get stuff done. Sometimes those tools are not pretty.
I place much of the criticism being levied here in the same category as the "we must rewrite 'ls' in Rust for security" nonsense that is regularly praised here.
So what if it's using unbounded strcpy's all over the place? It has basically no attack surface. He wrote it for himself, not for criticism from the HN hoi polloi
I didn't point that out so I could be the smartest person in the room and I certainly don't subscribe to the whole rewrite-the-world in rust.
The sheer amount of time I spent debugging problems caused by buffer overruns and other daft problems is immense. It's literal days of my life that could have been saved had safer APIs been created in the first place.
It's a cool toy program and I encourage the learning but maybe let's try and avoid unnecessary problems.
Oh yes, all those parameters are absolutely a pain to work with. But it can still be good to have an understanding of what options are abstracted away by fopen etc. Trying to write an app only using <Windows.h> can be a good learning exercise if you want to understand the fundamentals of the OS.
> It's amazing how much better Borland built their "Delphi like" C++ library.
As I recall, it wasn't "Delphi like", but rather literally the same VCL that Delphi used. That's why C++Builder had all those language extensions - they mapped 1:1 to the corresponding Delphi language features so that you could take any random Delphi unit (like VCL) and just use it from C++. In fact, C++Builder could even compile Delphi source code.
Yes, and it grew out of Object Windows Library, which also add extensions, and was definitly much more pleasant to use than MFC has ever managed to.
No need for the past tense, both products are still on the market with frequent releases and developer conferences, even if no longer at the same adoption level.
I remember OWL being somewhat weird in that it rendered quite a few stock controls itself, in ways that made OWL apps really stick out on Win 3.11.
MFC gets a lot of flak, but I think that a large chunk of it is undeserved because it's a fundamentally different kind of framework - a wrapper that tries to streamline the use of underlying APIs without concealing their fundamental nature, whereas OWL and VCL (and VB6, and WinForms) are higher-level wrappers that do quite a lot for you even when they use native widgets under the hood. From that perspective, if anything, the more appropriate criticism of MFC is that it tries to do too much - e.g. that whole document/view thing is clearly a high-level abstraction that always felt out of place to me given the overall design of the framework. WTL is basically what MFC tried to be but failed.
That was optional, it just turned out too many people liked to enable custom rendering.
That is exactly the reason why many of us dislike MFC, its low level wrapping of Windows APIs.
With OWL you could already have a kind of C# like experience, but in Windows 3.x, that is how far ahead the experience was versus MFC.
This is the tragedy of C++ frameworks, the tooling could be as good as VB, Delphi, Java, .NET, but then we have a big chunk of developers that insist in pushing for low level Cisms instead.
Honestly I never see much uptake on WTL, especially because dealing with ATL was already bad enough.
From the outside it feels like the chain of command at Microsoft has some big issue with producing great GUI development experiences for C++ developers.
When they finally nailed it, having a C++ Builder like experience, it was killed in the name of extensions by a rebel group, that nowadays is having fun writing Rust bindings for Windows APIs.
It's worth remembering that Windows 1.x and 2.x predates the C89 standard. This also explains why WINAPI calling convention was inherited from Pascal instead of C. The C standard library was "just another competitor" at the time.
The WINAPI calling convention is a cross between C and Pascal - C-style order of arguments on the stack, but Pascal-style callee cleaning the stack before return.
The reason for its use in Windows is that it makes generated code slightly smaller and more efficient, at the cost of not supporting varags easily (which you don't need for most functions anyway). Back when you had 640 Kb of RAM, saving a few bytes here and there adds up quickly.
Windows didn't standardize on C. It was mostly assembly and some Pascal in the beginning with C and C++ later.
Microsoft have always viewed C as just another language, it's not privileged in the way UNIX privileges C. By implication, the C standard library was provided by your compiler and shipped with your app as a dependency on Windows, it wasn't provided by the operating system.
These days that's been changing, partly because lots of installers dumped the MSVC runtime into c:\windows\system and so whether it was a part of the OS or not became blurred and partly because Microsoft got more willing to privilege languages at the OS level. Even so, the Windows group retains a commitment to language independence that other operating systems just don't have. WinRT comes with lots of metadata for binding it into other languages, for example.
> Windows didn't standardize on C. It was mostly assembly and some Pascal in the beginning with C and C++ later.
No, it was never Pascal. It was always C from the beginning. You may have been confused by them using the Pascal calling convention because it was generally faster on the 16-bit CPUs of the time.
Apple was the one going with Pascal for the OS, originally the Object Pascal linage was started at Apple, in collaboration with Niklaus Wirth that gave feedback on the design.
Unlike Unix, Windows historically didn't have a standard C runtime at all. Stuff like MSVCRT.DLL etc came later (and are themselves implemented on top of Win32 API, not directly on top of syscalls as is typical in Unix land).
Instead of laboriously calling CreateWindow() for every control, traditionally we would lay out a dialog resource in a .rc file (Visual Studio still has the dialog editor to do it visually) and then use CreateDialog() instead of CreateWindow(). This will create all the controls for you. Add an application manifest and you can get modern UI styling and high-DPI support.
You also get automatic tabbing between controls, and a few other keyboard shortcuts this way. Note that resizing them still needs to be done manually if you want that, but that's usually easy and not more than a few hundred bytes of code.
However, this approach is easily translatable to a language that has decent FFI, and requires nothing else: no resource compiler and linker to make a resource DLL.
Resource files and their binary format are not a good API.
If you have those CreateWindow calls in a decently high level language, you can probably meta-program some resource-like DSL that fits right in the language.
You don't need a "resource DLL"; the compiled .rc file gets linked directly into the binary, and any Win32 C toolchain is capable of doing that, including MinGW.
As API goes, I don't see what's wrong with it (anymore so than Win32 in general). And you do get quite a lot for free, as GP mentioned. Hi-DPI, for example - .rc files use "dialog units" to measure all widgets, which, unlike raw pixel values you pass to CreateWindow, are DPI-independent.
I don't understand this scenario. If you're writing an .rc file, then by definition you are building your own app (or library, although having one that displays dialogs is rather unusual).
Are you talking about localizable text, by chance?
What if the app isn't in a language that links to an .exe, where we can include the .res file compiled from .rc?
The language may have an .exe run-time, but we don't get to link that.
In that case if we want to use a .rc file anyway, it seems we would want to create a resource DLL out of it and dynamically load it.
(I'm aware that one reason for resource DLL's is for localizable strings. That use makes sense even of programs which can statically link the GUI layout resources.)
Ah, I see what you mean now. But the context is a Win32 app that is very deliberately written in C, so my take was from that perspective - i.e. there's no good reason to avoid .rc files and instead handwrite CreateWindow, handle DPI etc in this case.
However, even in the case that you describe, you don't actually have to use a resource DLL. CreateDialogIndirect can be used to create a dialog from an array of DLGITEMTEMPLATE structs, each describing a single control. I'm not entirely sure, but I suspect that compiled dialogs are basically just a dump of that array (but if not you could always just create it manually).
That doesn't matter; you can still use Visual Studio to create the .rc file. This technique still works great for MinGW-based projects. The important thing is that Visual Studio has a .rc dialog editor.
There are several .rc editors for Windows outside of VS that incorporate visual dialog editing. Pelles C would be one example that still gets regular updates.
Thanks for the tip about Pelles C. I just fired it up and it's a little clunky (so is Visual Studio) but I was able to load and edit a .rc dialog resource. Visual Studio's old dialog editor is pretty crashy these days so it's great to have an alternative.
As others have said, doing so in pure C and linking dynamically, you can easily remain under 20 KiB, at least on Linux, but Windows should be even simpler since it ships with much more out of the box as part of the OS.
In any event, I salute the effort! You can try the linking options I mentioned at the end of my article, it should help getting the size down.
Well, my somewhat extended TUI (ncurses) TODO program is 15K. Linux. Not statically linked though. I did not get around to build ncurses yet with musl.
Checks out: blurry fonts in scaled dpi, no Tab support, can't Ctrl-A select text in text fields and do all the other stuff that pre-modern frameworks offered you, errors on adding a row, ...
This code dynamically checks for and calls one of the following: user32:SetProcessDpiAwarenessContext, shcore:SetProcessDpiAwareness, then user32:SetProcessDPIAware. If the Windows version is extremely old and doesn't implement any of those (Windows XP or earlier), it won't call anything.
It's a little more complicated if you are to be using themes, GDI and common controls.
Some time ago I put together this example: https://github.com/tringi/win32-dpi
The high DPI support in Windows went through quite an evolution since XP, but mostly to fix what app programmers messed up. You can have nice and crisp XP at 250% dpi if you do things right, e.g.: https://x.com/TheBobPony/status/1733196004881482191/photo/1
The colons there don't represent C++. That's just a way of referring to a windows API function that exists in a specific DLL (in this case "user32"). Because the functions used here do not exist in older versions of Windows, the linked code dynamically loads user32.dll and tries to get the address of those functions so they can be called. That's why you need to know which Windows DLL they exist in.
Was going to point out would have to be an embedded program that can be booted into without need of an OS; but then program would still rely on various external api/abi interfaces aka bios, drivers & protocols (usb, scsi, pci, ansi, etc). Given today's hardware, think there's not really a realizstic thing as a realistic reall world 'pure C' program -- way to much knowledge / effort even if exclude NDA's. VM environment for 'hardware' as software still has abi interface, so not 'pure' C at source code level.
I tried to reproduce this binary to see what the 278 KB was being taken up by. The first obstacle that I ran into was that the build.bat file doesn't work if you have git configured to use core.autocrlf=false. Changing that to core.autocrlf=true and recloning was sufficient to get me building.
I'm using x86_64-15.1.0-release-win32-seh-msvcrt-rt_v12-rev0.7z from https://github.com/niXman/mingw-builds-binaries/releases/tag... as the toolchain. This produces a 102 KB .exe file. Right off the bat we are doing much better than the claimed 278 KB. Maybe the author is using a different toolchain or different settings? Exact steps to reproduce would be welcome.
We can improve this by passing some switches to GCC.
The v0.1 release from yesterday, at the time of posting, was 278 KB. The latest release, v0.3 from 9 hours ago, adds -Os -s and UPX to compress down to 27 KB.
I also used mingw and yet I arrived at different results. Maybe it was a different version, or a different distro of MinGW, or a 32-bit vs. 64-bit issue, or I'm linking against a different CRT. Without details from OP, we can't really tell.
A lot of it is due to the platform and executable format. Things can be much more lightweight when there's no information for stack traces, no dynamic linking infrastructure, no exception handling tables (necessary even in C in case exceptions traverse a c function,) etc.
I’m surprised it’s that big to be honest. I was expecting it to be smaller or half the size to be taken by some app icon. I remember writing this kind of stuff back in the days and it was smaller.
This reminds me of the days when all of a sudden win32 programming in assembly became hip enough, probably as a response to the increasing size of shareware downloads ('twas the dark time of MFC).
Combined with early Palm Pilot 68k programming, those were the last hurrahs of non-retrocomputing asm I can remember.
A processor? Luuuxury! In my time we worked twenty-six hours a day, did all the calculations with pen and paper and would be thrilled to use an abacus!
Ah, back in my early existence, we didn't have time and all these superficial dimensions. Ontological creation out of nothing was all one needed, but it looks like it's all lost art now.
I'm spending some time this evening debugging a failure I have with an emulator I've written - it emulates a system running a Z80 processor with 64k of RAM.
Sometimes I too take a step back and look at the way things have changed. But then again we've made a lot of progress for the size-changes I guess.
Hello friends, I made this app just to try it out and have some fun, haha, but the comments are right, something like this could have been done more sensibly with C++ or other languages, ahaha.
This is exactly how I've learned to create my first Windows programs about 30 years ago, except that I'd use a C++ compiler.
I am not sure why but I believe writing C style code with a C++ compiler was how the windows API was documented to be used. I think Microsoft just went with the idea that C++ was an improved superset of C so should be used even for C-style code.
> I think Microsoft just went with the idea that C++ was an improved superset of C so should be used even for C-style code.
And as a consequence, for a long time their official C compiler was stuck on C89, while other platforms already had full C99 support and beyond. I believe their support for newer C standards has gotten better since then, but AFAIK they still don't have full C99 support.
C++ actually makes a lot of sense specifically for Win32 API because RAII takes care of releasing all the numerous handles at the right time in the right manner. Also, things like string operations are a pain in pure C (indeed, this app uses stuff like strcpy which is a recipe for buffer overruns etc).
Seeing a lot of chirps in here from people who work on software or websites that load megabytes of JS or C# or in order to send 278kb of telemetry every time the user moves their mouse.
A 10 Kb .exe shouldn't be surprising given that it's fairly high-level (Java-like) bytecode rather than native code, and that WinForms incorporates a lot of the scaffolding that you have to handwrite for a Win32 app, like message dispatch.
The fact that you can do everything in C when developing a Windows app always makes me feel all warm and fuzzy. Building up from the lowest-level primitives just makes sense.
Meanwhile, on MacOS, everything is an ObjectiveC Object, so if you want to write an app in pure C you can but it's about 1000x more verbose because you've gone an abstraction level deeper than Apple intended, and you essentially have to puppeteer the Objective C class hierarchy to make anything happen. It's incredibly icky.
I don't know why they can't rebase the ObjectiveC class-based API onto a basic win32-style procedural API (technically win32 is also "class-based" but it's minimal). It's part of why I don't see myself porting any of my C code to MacOS any time soon.
Interestingly, Windows has its own object-oriented API/ABI with COM (and later WinRT, which builds on COM). However, the MIDL compiler for COM interfaces produces headers that are consumable from C, both to use interfaces and to implement them: https://www.codeproject.com/KB/com/com_in_c1.aspx
As far as I know, this still works today even for WinRT, although the generated C struct and function names get very ugly because they have to include the entire namespace: https://stackoverflow.com/a/7437006/111335
They did have a procedural API, it was called Carbon; which was a nearly drop-in replacement for the Macintosh Toolbox API that user32.dll blatantly copied.
The thing is, outside of programmer fuzzies, UIs really, really want to be object-oriented. A tree of unrelated objects sharing some common behaviors describes basically 99% of all UI code. And Toolbox / Carbon really strained for lack of having one. That's actually the one original thought Windows added - window classes.
Personally, the weirdness you feel manipulating Obj-C classes directly from C is how I feel any time I have to define a window class or procedure in user32.dll code[0]. OOP wants dedicated language features, just like how UI wants OOP. You can make do without but it's 2000x less ergonomic.
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.
You can do it without a manifest too, it involves calling "CreateActCtxA" and "ActivateActCtx" with the appropriate Activation Context object. Manifest file is much easier.
As well as information about side by side assemblies (ie: library versions), a Windows manifest file has various settings and a declaration of compatible versions of Windows that affect Windows' handling of the app, such as whether it can handle paths over MAX_PATH, if it is hi-dpi aware, or if it knows about themed controls.
If an EXE doesn't have a manifest file, Windows assumes that it's ancient, so it falls back to conservative defaults like ye olde USER controls to try and avoid breaking it.
While MSDN is a bit impractical to browse (there's simply so much stuff in there) it's usually the best place to go to for documentation when doing Windows dev.
The magic numbers (hashes and UUIDs) sort of make sense because there's a slightly adversarial interaction between developers and Microsoft. If you just had a compatibleWindowsMin and compatibleWindowsMax field with version numbers, people would just go ahead and put "9999" in the max field, and then OS upgrades break applications again. By using UUIDs instead, an application developer can't intentionally or unintentionally declare compatibility with unreleased Windows versions.
I'd suggest `-Oz` instead, as it optimises for size above all else at the cost of performance, unlike `-Os` which is less aggressive (but likely produces similar code anyway). `-Oz` is somewhat new if I remember correctly, so it depends on the GCC version.
That's more than 10x bigger than I expected, given that all it seems to do is manipulate a list view. Something like this should be doable in under 10KB.
Nostalgia: My first job in 1997 was a windows apps in C++, it was weather software used on ships and oil rigs, we used to ship updates on floppy disk via helicopter.
Great respect! I've tried many times, without final result. I'll try to use this for learning purposes!
Btw. I like how Inno Setup used some very old Delphi 2 compiler to create exe so small it would fit without breaking the zip compliancy. I read it somewhere 10+ years ago, so not sure if this is still the case, but still. And the initial dialog was done in pure winapi.h (of course it was winapi.pas which made everything more difficult for me to learn from)
Every time I see something in C for Windows I see people using MinGW, gcc and friends just like they would do in a Unix-like system. But I wouldn't expect that they are tools that Microsoft recommends for developing on Windows.
So, a honest question from a Linux/Mac guy: what is the Windows-y way to do that?
A cursory browse says there's no Linux-isms in the code base, so the Windows-y way to build that (without going into licensing) would be to use the Visual Studio Build Tools. They're the CLI toolchain you get for Visual Studio, but free when compiling open source projects (as of recently: https://devblogs.microsoft.com/cppblog/updates-to-visual-stu...)
They still notionally need to run on a Windows machine, although I recall people have managed to run them under wine before.
EDIT: It took me a few reads to parse what the link is saying, so: using the toolchain to compile open source dependencies is fine, even if your codebase is closed source, so long as the closed source part isn't being built with the Build Tools.
The most Windows-y way to do that is to get Visual Studio (Community Edition is free for non-commercial use). It still has project templates for pure Win32 apps even, although they are C++ rather than C.
I remember Pelles C being the first full C11 implementation, which I felt was impressive for such an unpopular toolchain.
I guess they can't switch to a FOSS licence because of the licence of LCC? How much of the original code even remains after more than 20 years and several C standards later?
I find frequently the smaller and simpler the subject, the more people can easily confidently grasp it and generate quick to share opinions.
Noticed this with Code Reviews. To a point, the smaller the code change, the more comments and input. Beyond a certain size, comments and reviews (without nagging or external incentives) trends towards zero.
Iirc mingw links its libc statically, that's probably why. Fwiw I still remember that an empty VB6 project with one form compiles to 20kb (16 if you select "optimize for size"). It still needs its VM, which is a dll that was considerably larger. I think about 1mb, but it's been a while.
We shipped our VB6 software on a 1.44 MB floppy disk. Actually, we had to add some random stuff to the installer to make our software fit on two floppies instead of one, so that customers would think our application was more complex. Our CEO wanted to make sure that the end user had to eject disk 1 and insert disk 2 during the installation. Sometimes you want to go big. So size matters.
That's amazing! It reminds me of when a client once asked to make the red more red. I asked him to look at it again the next day and he said it was much better. I didn't have to do anything.
So, this uses the DLL version of the Microsoft CRT. Don’t know if that counts as cheating :) Why is a CRT needed here anyway, beyond very basic stuff like startup code and memcpy?.. Is MiniCRT[1] an option?
It possibly isn't, and you can typically do without by telling VC++ to build without linking to it - though the compiler has a bad habit of generating calls to memcpy, so you may have to provide your own implementation of that (and hope the compiler doesn't spot what you're doing and helpfully replace it with a call to memcpy). But aside from that, it's easy enough. You don't need the CRT startup code; you can use WriteConsole to print to stdout/stderr; you can use LocalAlloc/LocalFree to allocate memory; there's a few string routines in the Win32 DLLs that are a bit like the C equivalents, if nothing in the ordinary Win32 API does what you want.
I used to be into this stuff and created a number of useful <10 KB EXEs this way. I'm not sure it's really worth it though! I started out writing code for computers where you'd have like 16 KB free RAM, and this wasn't much, but for most purposes you didn't actually have to sweat every single last byte. So on the same basis, now that even my laptop (which is over 10 years old) has 16 GB RAM, I am not massively inclined to worry about anything less than 1 MB.
The downside to me knowing how small programs can be if I don't link the CRT is that I can't help but feel like what I've written is terribly bloated if I don't make an effort to avoid the CRT.
I blame people who constantly comment about how bloated software is now for making overly conscious of program size even when its down at a point where it doesn't matter :')
The allure of the perfect notes and todo app. Having gone through phases of various modern todo and note apps over the years, I’ve finally let it go and decided to embrace just using text files. (Neovim for me, not that it matters which text editor one uses)
It’s not that there aren’t cool apps for this stuff, it’s more that I have a trail of data across various todo and notes apps from years of different tools.
One solution to the problem of making things “feel native” is to go all in on letting go of native. Target a different style, be it minimalism, Commodore 64, pixel art, etc… it can be fun that way, especially if it’s mostly just a tool for you.
It's probably too late, but this qualifies for "Show HN" if you update the title to have the prefix "Show HN: ".[0]
I think the size of the source is actually more impressive than the size of the binary. I'm impressed that you can implement the whole thing in what looks like about 1 KLOC in just four .c files.
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow);
If you know, you know.
I'm to understand that entire divisions of Microsoft itself no longer know how to code anywhere near this level, which is why many of their flagship applications (looking at you, Microsoft Teams (work or school)) are Electron monstrosities you can watch draw themselves like Windows 1.0 apps -- on modern multicore hardware.
I'm apparently so ancient I am just looking at that line of code thinking "isn't that the standard entrypoint for a Windows app?", lol; is there something else to know? ;P Oh! I guess, staring at it, isn't that wrong?... if you use LPCTSTR, one would expect that you are trying to be agnostic to UNICODE, but then you also have to use _tWinMain, no? (And, after considering that, I went and double-checked, and the C is also incorrect in this context.)
Funnily enough, the "ANSI" versions of Win32 functions are no longer considered a legacy thing, now that the OS offers UTF-8 as the supported encoding, and apps can explicitly request it (regardless of non-Unicode codepage setting) via manifest:
Here is one of few Windows apps that I have written, albeit in C#. compinfo is a single, 431 KB windows executable.
It displays basic computer info including user name, computer name, OS, model, serial number (service tag), CPU model, memory, IPv4 address and uptime.
What's modern about it? Also you could have used C++ instead to remove some potential issues, and those global variables...
Use std::string and std::array or std::list, some anonymous namespaces, remove all the malloc, etc. Your code would be half the size and still compile to the same assembly language without the bugs.
To note that even the latest editions of the famous Petzold book, before the C# edition, switched to using the common C subset from C++ and compiling with Visual C++ in C++ mode, instead of plain old C.
Already by Windows 95 timeframe, only C diehards would be writing Windows applications still in C instead of VB, Delphi and C++, as the more mainstream languages, there were obviously other ones to chose from as well.
> Use std::string and std::array or std::list /.../
While nothing is modern about this approach, if we're going the WINAPI route, there's very little to be gained by using std::string instead of the LPWSTR that WINAPI offers (and plays nicely with). I would definitely avoid plain C strings (char[]) but rather use the wide version (which is what LPWSTR is under the hood). But for std::array or std::list, I don't see how the codebase would vastly benefit from them.
It’s not modern but there’s some value to programming close to the metal so you understand what’s really going on. The problem domain is simple and easy to keep in your head. Good learning exercise. I wonder if there’s an assembly language version of something like this.
I remember doing that for some custom installer I wrote. It felt like a good idea for 5mins until it got flagged by a bunch of anti virus software… had to sign the installer in the end and spent a lot of time reporting false positives.
Fun project! I think the smallest I ever shrunk a win32 application was on the order of 2-4kb by writing in ASM. It was a great illustration of why 10x binary size is actually a great trade-off in terms of productivity.
I’m pretty sure an app as mediocre as this would take up less code in React, or even plain JavaScript. The UI is a single table and a few inputs and buttons, and its main way of communicating with the outside world is message boxes - trivial to do in a web browser.
By "actual code" I meant the assembly that the application logic compiles down to, not the entire executable. But as far as the entire package goes, compiling it using clang with some flags I can get down to 19.5k without any effort. If I wanted to waste time on this, ripping out the CRT entirely and getting it to 16k would probably take less than an hour.
Interesting! I was just looking at raylib for this kind of thing: super light weight, cross platform, reliable, ideally C-based method to get GUI.
Raylib and raygui is truly incredible from my point of view. I succeeded in getting the macOS and Windows builds going on a bunch of cute little novel (not stock standard in the repo) examples in a matter of hours with AI help. I'm inspired by all I can do with this.
For ages I felt "cut off" from the world of Desktop GUI because it was so verbose, and had high friction - need a bunch of tooling, set up, and so on. And then everything was fragile. I like to work quickly, with feedback, and PoCs and results. I think in raylib I have found a method that really achieves this. For instance, check out this tiny little "text_input.c"
#define RAYGUI_IMPLEMENTATION
#include <raylib.h>
#include "deps/raygui.h"
#define WINDOW_WIDTH 800
#define WINDOW_HEIGHT 600
#define MAX_INPUT_CHARS 32
int main(void) {
InitWindow(WINDOW_WIDTH, WINDOW_HEIGHT, "Text Input Demo");
SetTargetFPS(60);
// Load a larger font for better text appearance
Font font = LoadFontEx("resources/fonts/arial.ttf", 32, 0, 0);
if (font.texture.id == 0) {
font = GetFontDefault(); // Fallback to default font if loading fails
}
// Set the font for raygui controls
GuiSetFont(font);
// Customize raygui styles (using BGR order for hex values)
GuiSetStyle(BUTTON, TEXT_ALIGNMENT, TEXT_ALIGN_CENTER);
GuiSetStyle(BUTTON, BASE_COLOR_NORMAL, 0x50AF4CFF); // Green (B=80, G=175, R=76, A=255) ‚Üí R=76, G=175, B=80
GuiSetStyle(BUTTON, TEXT_COLOR_NORMAL, 0xFFFFFFFF); // White text
GuiSetStyle(BUTTON, BASE_COLOR_PRESSED, 0x6ABB66FF); // Lighter green
GuiSetStyle(BUTTON, TEXT_COLOR_PRESSED, 0xFFFFFFFF);
GuiSetStyle(BUTTON, BASE_COLOR_FOCUSED, 0x84C781FF); // Hover color
GuiSetStyle(BUTTON, TEXT_COLOR_FOCUSED, 0xFFFFFFFF);
GuiSetStyle(BUTTON, BORDER_WIDTH, 2);
GuiSetStyle(BUTTON, BORDER_COLOR_NORMAL, 0x327D2EFF); // Dark green border
// Adjust font size for raygui controls (optional, since font is already 32pt)
GuiSetStyle(DEFAULT, TEXT_SIZE, 20); // Slightly smaller for button and text box to fit better
GuiSetStyle(DEFAULT, TEXT_SPACING, 1);
char inputText[MAX_INPUT_CHARS + 1] = "\0"; // Buffer for text input
bool textBoxEditMode = false; // Tracks if the text box is being edited
bool messageSubmitted = false; // Tracks if a message has been submitted
float effectTimer = 0.0f; // Timer for the flash effect
const float effectDuration = 0.5f; // Flash duration in seconds
while (!WindowShouldClose()) {
// Update effect timer
if (effectTimer > 0) {
effectTimer -= GetFrameTime();
}
BeginDrawing();
// Set background color based on effect
if (effectTimer > 0) {
ClearBackground((Color){ 255, 255, 150, 255 }); // Yellow flash (RGB order)
} else {
ClearBackground(RAYWHITE);
}
// Center the text box and button
int textBoxWidth = 200;
int textBoxHeight = 40;
int buttonWidth = 120;
int buttonHeight = 40;
int textBoxX = (WINDOW_WIDTH - textBoxWidth) / 2;
int textBoxY = (WINDOW_HEIGHT - textBoxHeight) / 2 - 40;
int buttonX = (WINDOW_WIDTH - buttonWidth) / 2;
int buttonY = textBoxY + textBoxHeight + 10;
// Draw the text box
if (GuiTextBox((Rectangle){ (float)textBoxX, (float)textBoxY, textBoxWidth, textBoxHeight }, inputText, MAX_INPUT_CHARS, textBoxEditMode)) {
textBoxEditMode = !textBoxEditMode; // Toggle edit mode on click
}
// Draw the button
if (GuiButton((Rectangle){ (float)buttonX, (float)buttonY, buttonWidth, buttonHeight }, "Submit")) {
messageSubmitted = true;
effectTimer = effectDuration; // Start the flash effect
TraceLog(LOG_INFO, "Message submitted: %s", inputText);
}
// Display the submitted message
if (messageSubmitted && inputText[0] != '\0') {
const char *label = "Message: ";
char displayText[256];
snprintf(displayText, sizeof(displayText), "%s%s", label, inputText);
int textWidth = MeasureTextEx(font, displayText, 32, 1).x;
int textX = (WINDOW_WIDTH - textWidth) / 2;
int textY = buttonY + buttonHeight + 20;
DrawTextEx(font, displayText, (Vector2){ (float)textX, (float)textY }, 32, 1, (Color){ 33, 150, 243, 255 }); // Bright blue (RGB order)
}
EndDrawing();
}
UnloadFont(font);
CloseWindow();
return 0;
}
I love it! I feel unleashed again to program in graphics and games and real GUI! The first real paid programming job I had was using a lot of ps5 in Java and JavaScript (Open Processing) and I dug it! :)
And the file sizes are sweet (to me):
- macOS: text_input - 123736
- Windows: text_input.exe - 538909
Two dependencies to distribute with on Windows: glfw3.dll and libraylib.dll (322K and 2.1MB respectively)
Raylib was built to make game programming fun. And maybe I will use it for that! :) But right now I want to use it for GUI. The issue with Qt and others, is while I like the idea of standard-Andy controls, I don't want to pay a commercial license - when I figure "it can't be that hard to get what I want" - as I plan to use this stuff for commercial/proprietary control-panes and layers on my existing products: BrowserBox, DiskerNet, and more.
At the same time I really respect what Qt have done growing their business and might be inspired or even emulate some of their model myself in my business.
There is something I like about win32 gui programming. It's a little idiosyncratic, but if you read Raymond Chen's blog you'll see why.
The win32 API has its origins on the 8088 processor and doing things a certain way results in saving 40 bytes of code or uses one less register or something.
I wrote a lot of toy gui apps using mingw and Petzold's book back in the day. Writing custom controls, drawing graphics and text, handling scrolling, hit testing etc was all a lot of fun.
I see in your app you're using strcpy, sprintf. Any kind of serious programming you should be using the length-checked variants. I'm surprised the compiler didn't spew.
You'll also find that the Win32 API has a lot of replacements for what's in the C standard library. If you really want to try and get the executable size down, see if you can write your app using only <Windows.h> and no cstdlib. Instead of memset() you've got ZeroMemory(), instead of memcpy() you've got CopyMemory().
At some point writing raw C code becomes painful. Still, I think doing your first few attempts in raw C is the best way to learn. Managing all the minutiae gives you a great sense of what's going on while you're learning.
If you want to play more with win32 gui programming, I'd have a look at the WTL (Windows Template Library). It's a C++ wrapper around the win32 API and makes it much easier to reason about what's going on.
> There is something I like about win32 gui programming
Totally agree with you. I use an excellent PC app called AlomWare Toolbox, and it's the epitome of Win32 design (https://www.alomware.com/images/tab-automation.png), and despite it doing so much it's only about 3 MB in size because of it. No frameworks with it either, just a single executable file. I wish all software were still like this.
Is the font-size adjustable? It's too small on my screen
At minimum, these days, if you dont use strncpy instead of strcpy, you’ll have to suffer through every man and his dog (or AI tool) forever telling you to do otherwise. (For me this is one of the main arguments of using zig, a lot of these common pitfalls are minimized by using zig, but c is fine as well)
Heh, and if you use strncpy() you'll have to suffer through me lecturing you on why strncpy() is the wrong function to use as well.
strncpy is more or less perfect in my line of work where a lot of binary protocols have fixed size string fields (char x[32]) etc.
The padding is needed to make packets hashable and not leak uninitialized bytes.
You just never assume a string is null terminated when reading, using strnlen or strncpy when reading as well.
Yep, that's intended use case for strncpy().
It's not really suitable for general purpose programming like the OP is doing. It won't null terminate the string if the buffer is filled, which will cause you all sorts of problems. If the buffer is not filled, it will write extra null bytes to fill the buffer (not a problem, but unnecessary).
On freebsd you have strlcpy(), Windows has strcpy_s() which will do what the OP needs. I remember someone trying to import strlcpy() into Linux, but Ulrich Drepper had a fit and said no.
You just never assume a string is null terminated when reading, using strnlen or strncpy when reading as well.
Not really possible when dealing with operating system level APIs that expect and require null-terminated strings. It's safer and less error-prone to keep everything null terminated at all times.
Or just write in C++ and use std::string, or literally any other language. C is terrible when it comes to text strings.
> On freebsd you have strlcpy()
strlcpy() came from OpenBSD and was later ported to FreeBSD, Solaris, etc.
Yup.
Lots of good security & safety innovations came from OpenBSD.
You shouldn't use any of those garbage functions. Just ignore \0 entirely, manage your lengths, and use memcpy.
I am not writing in C, but always wondered, why pascal-like strings wrappers are not popular, i. e. when you have first 2 bytes represent the length of the string following by \0 terminated string for compatibility.
2 bytes is not enough, usually you'll see whole "size_t" worth of bytes for the length.
But you could do something utf-8 inspired I suppose where some bit pattern in the first byte of the length tells you how many bytes are actually used for the length.
Pascal originally required you to specify the length of the string before you did anything with it.
This is a totally good idea, but was considered to be too much of a pain to use at the time.
You still need a 0-terminated string to pass to API of most libraries (including ones included with the OS - in this case, Win32).
Yeah, Drepper said the same thing.
>It won't null terminate the string if the buffer is filled, which will cause you all sorts of problems.
if you don't know how to solve/avoid a problem like that, you will have all sorts of other problems
pound-define strncopy to a compile fail, write the function you want instead, correct all the compile errors, and then, not only move on with your life, never speak of it again, for that is the waste of time. C++ std:string is trash, java strings are trash, duplicate what you want from those in your C string library and sail ahead. no language has better defined behaviors than C, that's why so many other languages, interpreters, etc. have been implemented in C.
I thought string is just byte array that has Null as last element?
How can a string not Null-terminated ?
Whether the string ends in NULL or not is up to you as a programmer. It's only an array of bytes, even though the convention is to NULL-terminate it.
Well maybe more than just a convention, but there is nothing preventing you from setting the last byte to whatever you want.
Everything in C is just array of bytes, some would argue uint32_t is just array of 4 bytes. That's why we need convention.
A string is defined as byte array with Null at last. Remove the Null and it's not a string anymore.
> Everything in C is just array of bytes, some would argue uint32_t is just array of 4 bytes
That isn't how the C language is defined. The alignment rules may differ between those two types. Consider also the need for the union trick to portably implement type-punning in C. Also, the C standard permits for CHAR_BIT to equal 32, so in C's understanding of a 'byte', the uint32_t type might in principle correspond to just a single byte, in some exotic (but C compliant) platform.
No doubt there are other subtleties besides.
That's only one possible convention, and it's not a particularly good one at that.
Instead of memset() you've got ZeroMemory(), instead of memcpy() you've got CopyMemory().
I believe MSVC intrinsics will use the rep stos/movs instructions, which are even smaller than calling functions (which includes the size of their import table entries too.)
The standard allows memset/memcpy to be replaced by inline code. There is no need to use non-standard extensions to get a performance boost.
That's how the MSVC intrinsics work. Turn on the option and memset/memcpy, among others, gets replaced automatically:
https://learn.microsoft.com/en-us/cpp/preprocessor/intrinsic...
I spent a lot of time doing that and to be honest, I miss the ability to develop for native UIs with native code.
> You'll also find that the Win32 API has a lot of replacements for what's in the C standard library. If you really want to try and get the executable size down, see if you can write your app using only <Windows.h> and no cstdlib. Instead of memset() you've got ZeroMemory(), instead of memcpy() you've got CopyMemory().
I see he's also using fopen/fread/fclose rather than CreateFile/ReadFile/WriteFile/etc.
> I see he's also using fopen/fread/fclose rather than CreateFile/ReadFile/WriteFile/etc.
It's a todo list, not a network service. So what if it's using unbounded strcpy's all over the place? It has basically no attack surface. He wrote it for himself, not for criticism from the HN hoi polloi.
For once maybe take someone's work at face value instead of critiquing every mundane detail in order to feel like the smartest person in the room.
Computers are tools to get stuff done. Sometimes those tools are not pretty.
I place much of the criticism being levied here in the same category as the "we must rewrite 'ls' in Rust for security" nonsense that is regularly praised here.
So what if it's using unbounded strcpy's all over the place? It has basically no attack surface. He wrote it for himself, not for criticism from the HN hoi polloi
I didn't point that out so I could be the smartest person in the room and I certainly don't subscribe to the whole rewrite-the-world in rust.
The sheer amount of time I spent debugging problems caused by buffer overruns and other daft problems is immense. It's literal days of my life that could have been saved had safer APIs been created in the first place.
It's a cool toy program and I encourage the learning but maybe let's try and avoid unnecessary problems.
>I certainly don't subscribe to the whole rewrite-the-world in rust.
Good because those Rust people get really upset when you point out that Rust mostly seems to exist for people to "Rewrite X in Rust".
To be fair, CreateFile etc are a lot more verbose than fopen.
Oh yes, all those parameters are absolutely a pain to work with. But it can still be good to have an understanding of what options are abstracted away by fopen etc. Trying to write an app only using <Windows.h> can be a good learning exercise if you want to understand the fundamentals of the OS.
I agree with most of this, but let's be honest, win32 gui programming (like this) is/was a pain
Even MFC barely took the edge out. It's amazing how much better Borland built their "Delphi like" C++ library.
> Instead of memset() you've got ZeroMemory(), instead of memcpy() you've got CopyMemory().
Yes. And your best API for opening (anything but files but maybe files as well) is... CreateFile
Aah the memories :)
> It's amazing how much better Borland built their "Delphi like" C++ library.
As I recall, it wasn't "Delphi like", but rather literally the same VCL that Delphi used. That's why C++Builder had all those language extensions - they mapped 1:1 to the corresponding Delphi language features so that you could take any random Delphi unit (like VCL) and just use it from C++. In fact, C++Builder could even compile Delphi source code.
Yes, and it grew out of Object Windows Library, which also add extensions, and was definitly much more pleasant to use than MFC has ever managed to.
No need for the past tense, both products are still on the market with frequent releases and developer conferences, even if no longer at the same adoption level.
I remember OWL being somewhat weird in that it rendered quite a few stock controls itself, in ways that made OWL apps really stick out on Win 3.11.
MFC gets a lot of flak, but I think that a large chunk of it is undeserved because it's a fundamentally different kind of framework - a wrapper that tries to streamline the use of underlying APIs without concealing their fundamental nature, whereas OWL and VCL (and VB6, and WinForms) are higher-level wrappers that do quite a lot for you even when they use native widgets under the hood. From that perspective, if anything, the more appropriate criticism of MFC is that it tries to do too much - e.g. that whole document/view thing is clearly a high-level abstraction that always felt out of place to me given the overall design of the framework. WTL is basically what MFC tried to be but failed.
That was optional, it just turned out too many people liked to enable custom rendering.
That is exactly the reason why many of us dislike MFC, its low level wrapping of Windows APIs.
With OWL you could already have a kind of C# like experience, but in Windows 3.x, that is how far ahead the experience was versus MFC.
This is the tragedy of C++ frameworks, the tooling could be as good as VB, Delphi, Java, .NET, but then we have a big chunk of developers that insist in pushing for low level Cisms instead.
Honestly I never see much uptake on WTL, especially because dealing with ATL was already bad enough.
From the outside it feels like the chain of command at Microsoft has some big issue with producing great GUI development experiences for C++ developers.
When they finally nailed it, having a C++ Builder like experience, it was killed in the name of extensions by a rebel group, that nowadays is having fun writing Rust bindings for Windows APIs.
> Instead of memset() you've got ZeroMemory(), instead of memcpy() you've got CopyMemory().
What is or was the purpose of providing these instead of the existing Windows C std?
It's worth remembering that Windows 1.x and 2.x predates the C89 standard. This also explains why WINAPI calling convention was inherited from Pascal instead of C. The C standard library was "just another competitor" at the time.
The WINAPI calling convention is a cross between C and Pascal - C-style order of arguments on the stack, but Pascal-style callee cleaning the stack before return.
The reason for its use in Windows is that it makes generated code slightly smaller and more efficient, at the cost of not supporting varags easily (which you don't need for most functions anyway). Back when you had 640 Kb of RAM, saving a few bytes here and there adds up quickly.
Those functions explicitly? I can't find any definitive explanation on why they exist.
It looks like nowdays ZeroMemory() and RtlZeroMemory() are just macros for memset().
Here's an article on some of the RECT helper functions. Relevant for the 8088 CPU but probably not so much today: https://devblogs.microsoft.com/oldnewthing/20200224-00/?p=10...
Windows didn't standardize on C. It was mostly assembly and some Pascal in the beginning with C and C++ later.
Microsoft have always viewed C as just another language, it's not privileged in the way UNIX privileges C. By implication, the C standard library was provided by your compiler and shipped with your app as a dependency on Windows, it wasn't provided by the operating system.
These days that's been changing, partly because lots of installers dumped the MSVC runtime into c:\windows\system and so whether it was a part of the OS or not became blurred and partly because Microsoft got more willing to privilege languages at the OS level. Even so, the Windows group retains a commitment to language independence that other operating systems just don't have. WinRT comes with lots of metadata for binding it into other languages, for example.
> Windows didn't standardize on C. It was mostly assembly and some Pascal in the beginning with C and C++ later.
No, it was never Pascal. It was always C from the beginning. You may have been confused by them using the Pascal calling convention because it was generally faster on the 16-bit CPUs of the time.
Apple was the one going with Pascal for the OS, originally the Object Pascal linage was started at Apple, in collaboration with Niklaus Wirth that gave feedback on the design.
You could write code without using libc / the C runtime. You still can.
Unlike Unix, Windows historically didn't have a standard C runtime at all. Stuff like MSVCRT.DLL etc came later (and are themselves implemented on top of Win32 API, not directly on top of syscalls as is typical in Unix land).
I second this, and just want to add that strsafe.h contains replacements for the runtime string routines.
Instead of laboriously calling CreateWindow() for every control, traditionally we would lay out a dialog resource in a .rc file (Visual Studio still has the dialog editor to do it visually) and then use CreateDialog() instead of CreateWindow(). This will create all the controls for you. Add an application manifest and you can get modern UI styling and high-DPI support.
You also get automatic tabbing between controls, and a few other keyboard shortcuts this way. Note that resizing them still needs to be done manually if you want that, but that's usually easy and not more than a few hundred bytes of code.
Only UNIX overlaps C standard library with OS library, and back in 1985 (Windows 1.0 release), there was still no standard to speak of.
Sure there was K&R C, which each OS outside UNIX cherry picked what would be available.
Additionally outside UNIX clones, the tradition among vendors has been that the C compiler is responsible for the standard library, not the platform.
Thus the C library was provided by Borland, Watcom, Symantec, Microsoft, Green Hills, Zortech,....
Note it was the same on Mac OS, until MPW came to be.
As it was in IBM and Unisys, micros and mainframes.
VMS before OpenVMS.
And so on.
Since Windows 10, you have the Universal C Runtime as well.
I think you replied to the wrong comment.
Great answer, helpful and not judgemental.
Look it up in Petzold they used to say...
However, this approach is easily translatable to a language that has decent FFI, and requires nothing else: no resource compiler and linker to make a resource DLL.
Resource files and their binary format are not a good API.
If you have those CreateWindow calls in a decently high level language, you can probably meta-program some resource-like DSL that fits right in the language.
You don't need a "resource DLL"; the compiled .rc file gets linked directly into the binary, and any Win32 C toolchain is capable of doing that, including MinGW.
As API goes, I don't see what's wrong with it (anymore so than Win32 in general). And you do get quite a lot for free, as GP mentioned. Hi-DPI, for example - .rc files use "dialog units" to measure all widgets, which, unlike raw pixel values you pass to CreateWindow, are DPI-independent.
What if "the binary" is stock (not built or relinked by you) installation of a language run-time? That's more like the case I'm thinking of.
A program like this nicely translates to that situation.
I don't understand this scenario. If you're writing an .rc file, then by definition you are building your own app (or library, although having one that displays dialogs is rather unusual).
Are you talking about localizable text, by chance?
What if the app isn't in a language that links to an .exe, where we can include the .res file compiled from .rc?
The language may have an .exe run-time, but we don't get to link that.
In that case if we want to use a .rc file anyway, it seems we would want to create a resource DLL out of it and dynamically load it.
(I'm aware that one reason for resource DLL's is for localizable strings. That use makes sense even of programs which can statically link the GUI layout resources.)
Ah, I see what you mean now. But the context is a Win32 app that is very deliberately written in C, so my take was from that perspective - i.e. there's no good reason to avoid .rc files and instead handwrite CreateWindow, handle DPI etc in this case.
However, even in the case that you describe, you don't actually have to use a resource DLL. CreateDialogIndirect can be used to create a dialog from an array of DLGITEMTEMPLATE structs, each describing a single control. I'm not entirely sure, but I suspect that compiled dialogs are basically just a dump of that array (but if not you could always just create it manually).
>Visual Studio still has the dialog editor to do it visually
They are using gcc.
That doesn't matter; you can still use Visual Studio to create the .rc file. This technique still works great for MinGW-based projects. The important thing is that Visual Studio has a .rc dialog editor.
There are several .rc editors for Windows outside of VS that incorporate visual dialog editing. Pelles C would be one example that still gets regular updates.
Thanks for the tip about Pelles C. I just fired it up and it's a little clunky (so is Visual Studio) but I was able to load and edit a .rc dialog resource. Visual Studio's old dialog editor is pretty crashy these days so it's great to have an alternative.
I have done something similar for Linux under 2 KiB in assembly some time ago: https://gaultier.github.io/blog/x11_x64.html
As others have said, doing so in pure C and linking dynamically, you can easily remain under 20 KiB, at least on Linux, but Windows should be even simpler since it ships with much more out of the box as part of the OS.
In any event, I salute the effort! You can try the linking options I mentioned at the end of my article, it should help getting the size down.
Well, my somewhat extended TUI (ncurses) TODO program is 15K. Linux. Not statically linked though. I did not get around to build ncurses yet with musl.
> no frameworks
Checks out: blurry fonts in scaled dpi, no Tab support, can't Ctrl-A select text in text fields and do all the other stuff that pre-modern frameworks offered you, errors on adding a row, ...
> modern
In what way?
Example of setting DPI awareness: https://github.com/Dwedit/GameStretcher/blob/master/Stretche...
This code dynamically checks for and calls one of the following: user32:SetProcessDpiAwarenessContext, shcore:SetProcessDpiAwareness, then user32:SetProcessDPIAware. If the Windows version is extremely old and doesn't implement any of those (Windows XP or earlier), it won't call anything.
You can also set it in the application manifest, which is recommended over setting it programmatically: https://learn.microsoft.com/en-us/windows/win32/hidpi/settin...
It's a little more complicated if you are to be using themes, GDI and common controls. Some time ago I put together this example: https://github.com/tringi/win32-dpi
The high DPI support in Windows went through quite an evolution since XP, but mostly to fix what app programmers messed up. You can have nice and crisp XP at 250% dpi if you do things right, e.g.: https://x.com/TheBobPony/status/1733196004881482191/photo/1
Ah isn't the user32:<windows api functions> a framework not related to 'pure' C?
The colons there don't represent C++. That's just a way of referring to a windows API function that exists in a specific DLL (in this case "user32"). Because the functions used here do not exist in older versions of Windows, the linked code dynamically loads user32.dll and tries to get the address of those functions so they can be called. That's why you need to know which Windows DLL they exist in.
Arguably, Windows itself is an object oriented UI framework.
Was going to point out would have to be an embedded program that can be booted into without need of an OS; but then program would still rely on various external api/abi interfaces aka bios, drivers & protocols (usb, scsi, pci, ansi, etc). Given today's hardware, think there's not really a realizstic thing as a realistic reall world 'pure C' program -- way to much knowledge / effort even if exclude NDA's. VM environment for 'hardware' as software still has abi interface, so not 'pure' C at source code level.
It's "modern" in that it's much bigger than necessary, while missing a lot of functionality.
(A lot of what you mention is missing is trivial to add, especially tabbing between controls.)
I think font scaling is fixed (i.e. turned on) with SetThreadDpiAwarenessContext(-4). Or whatever the constant that equates to -4 is called.
It's modern in that he just released it.
The 6502 programmer in me is dying inside that 278kb now passes as lightweight.
I tried to reproduce this binary to see what the 278 KB was being taken up by. The first obstacle that I ran into was that the build.bat file doesn't work if you have git configured to use core.autocrlf=false. Changing that to core.autocrlf=true and recloning was sufficient to get me building.
I'm using x86_64-15.1.0-release-win32-seh-msvcrt-rt_v12-rev0.7z from https://github.com/niXman/mingw-builds-binaries/releases/tag... as the toolchain. This produces a 102 KB .exe file. Right off the bat we are doing much better than the claimed 278 KB. Maybe the author is using a different toolchain or different settings? Exact steps to reproduce would be welcome.
We can improve this by passing some switches to GCC.
If all you are interested in is a small .exe size, there is plenty of room for improvement here.If you had a blog or YouTube channel where you just went around to open source projects optimizing them down, I’d be very interested.
> Maybe the author is using a different toolchain or different settings?
I wonder if they are compiling with debugging symbols? I don't know how much this would change things in vanilla C but that would be my first guess
I think there's a typo somewhere. The repo and the release says 27KB (not 278).
The v0.1 release from yesterday, at the time of posting, was 278 KB. The latest release, v0.3 from 9 hours ago, adds -Os -s and UPX to compress down to 27 KB.
Oh! I arrived late...
They used mingw, read TFA
I also used mingw and yet I arrived at different results. Maybe it was a different version, or a different distro of MinGW, or a 32-bit vs. 64-bit issue, or I'm linking against a different CRT. Without details from OP, we can't really tell.
A lot of it is due to the platform and executable format. Things can be much more lightweight when there's no information for stack traces, no dynamic linking infrastructure, no exception handling tables (necessary even in C in case exceptions traverse a c function,) etc.
no dynamic linking infrastructure
You get that for free on Windows.
no exception handling tables (necessary even in C in case exceptions traverse a c function,
Not necessary if you're using pure C. SEH is rarely necessary either.
Maybe we could petition the demo scene competitions to have a '64kb TODO app' category.
I’m surprised it’s that big to be honest. I was expecting it to be smaller or half the size to be taken by some app icon. I remember writing this kind of stuff back in the days and it was smaller.
Is it due to MinGw maybe?
This reminds me of the days when all of a sudden win32 programming in assembly became hip enough, probably as a response to the increasing size of shareware downloads ('twas the dark time of MFC).
Combined with early Palm Pilot 68k programming, those were the last hurrahs of non-retrocomputing asm I can remember.
6502? Luxury! In my times you were lucky to have a processor.
A processor? Luuuxury! In my time we worked twenty-six hours a day, did all the calculations with pen and paper and would be thrilled to use an abacus!
Ah, back in my early existence, we didn't have time and all these superficial dimensions. Ontological creation out of nothing was all one needed, but it looks like it's all lost art now.
Atrus? is that you?
you had paper? We had to use sand and sticks!
Btw. I love how you people refer to this sketch so seamlessly!
Hehe :) Okey.. I have sth easier to write.. but smaller:
15kB quickrun.exe :) C, pure Win32 API.. No hacks to shrink binary, Mingw32 compiler.
Its GUI app to quickly launch any application via alias.
I'm spending some time this evening debugging a failure I have with an emulator I've written - it emulates a system running a Z80 processor with 64k of RAM.
Sometimes I too take a step back and look at the way things have changed. But then again we've made a lot of progress for the size-changes I guess.
I remember being thunderstruck in early 1990-something upon seeing that Nethack compiled to a 900kb+ executable.
For some reason it's built with GCC instead of using MSVC, and there are no optimizations enabled (for speed or size).
it's about ABI, also 8bit << ... << 64bit architecture. Every pointer is 8 times longer. Don't complain, just admire. It's an art.
That barely fits on a 5 1/4” floppy!
try to open "new" calculator on win10/win11. It's like loading another operating system... useless.
Probably JIT-ing? Compiled against native should make startup instant. No idea how they compile these.
Hello friends, I made this app just to try it out and have some fun, haha, but the comments are right, something like this could have been done more sensibly with C++ or other languages, ahaha.
This is exactly how I've learned to create my first Windows programs about 30 years ago, except that I'd use a C++ compiler.
I am not sure why but I believe writing C style code with a C++ compiler was how the windows API was documented to be used. I think Microsoft just went with the idea that C++ was an improved superset of C so should be used even for C-style code.
> I think Microsoft just went with the idea that C++ was an improved superset of C so should be used even for C-style code.
And as a consequence, for a long time their official C compiler was stuck on C89, while other platforms already had full C99 support and beyond. I believe their support for newer C standards has gotten better since then, but AFAIK they still don't have full C99 support.
Unironically, I would rather use your to-do app over the default Windows 11 one.
AHhhahah thanks
It's just the way it should be.
Other language doesn't fundamentally change anything if you want to use win32 API, if anything it would make things more confusing.
People often fall prey to C++isms, and they would have made the whole thing an even more confusing mess (to people not familiar with win32 API).
This is a very cute thing to do and some familiarity with win32 APIs is a nice basic competency thing, regardless of what other people think.
C++ actually makes a lot of sense specifically for Win32 API because RAII takes care of releasing all the numerous handles at the right time in the right manner. Also, things like string operations are a pain in pure C (indeed, this app uses stuff like strcpy which is a recipe for buffer overruns etc).
WTL (https://en.wikipedia.org/wiki/Windows_Template_Library) is the oldschool way to do low-level Win32 coding in C++.
https://github.com/Efeckc17/YoutubeGO By the way, you can also review or examine this application, I would be very happy :D
This is exactly the sort of project (clean, native UI) that motivated me to learn programming, kudos!
Seeing a lot of chirps in here from people who work on software or websites that load megabytes of JS or C# or in order to send 278kb of telemetry every time the user moves their mouse.
A similar app in C# + WinForms is under 10KB on disk and 6MB RAM. This app takes 1.5MB RAM. Both start instantly.
Impressive. Can you share a link to the source code?
A 10 Kb .exe shouldn't be surprising given that it's fairly high-level (Java-like) bytecode rather than native code, and that WinForms incorporates a lot of the scaffolding that you have to handwrite for a Win32 app, like message dispatch.
The fact that you can do everything in C when developing a Windows app always makes me feel all warm and fuzzy. Building up from the lowest-level primitives just makes sense.
Meanwhile, on MacOS, everything is an ObjectiveC Object, so if you want to write an app in pure C you can but it's about 1000x more verbose because you've gone an abstraction level deeper than Apple intended, and you essentially have to puppeteer the Objective C class hierarchy to make anything happen. It's incredibly icky.
I don't know why they can't rebase the ObjectiveC class-based API onto a basic win32-style procedural API (technically win32 is also "class-based" but it's minimal). It's part of why I don't see myself porting any of my C code to MacOS any time soon.
Interestingly, Windows has its own object-oriented API/ABI with COM (and later WinRT, which builds on COM). However, the MIDL compiler for COM interfaces produces headers that are consumable from C, both to use interfaces and to implement them: https://www.codeproject.com/KB/com/com_in_c1.aspx
As far as I know, this still works today even for WinRT, although the generated C struct and function names get very ugly because they have to include the entire namespace: https://stackoverflow.com/a/7437006/111335
They did have a procedural API, it was called Carbon; which was a nearly drop-in replacement for the Macintosh Toolbox API that user32.dll blatantly copied.
The thing is, outside of programmer fuzzies, UIs really, really want to be object-oriented. A tree of unrelated objects sharing some common behaviors describes basically 99% of all UI code. And Toolbox / Carbon really strained for lack of having one. That's actually the one original thought Windows added - window classes.
Personally, the weirdness you feel manipulating Obj-C classes directly from C is how I feel any time I have to define a window class or procedure in user32.dll code[0]. OOP wants dedicated language features, just like how UI wants OOP. You can make do without but it's 2000x less ergonomic.
[0] Or anything to do with GTK/GObject.
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.
> 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.
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.
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…
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 hope that clears my point up.
MSVCRT works perfectly fine for something with this feature set.
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.
> 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.
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...
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.
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.)
> 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.
You 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.
Quite literally, it would seem! What an entirely remarkable coincidence.
Call it a coincidence all you want, we both know you just copy/pasted my comment into your own edit.
Bold, I'll give you that. Did we both get that from the UNIX-HATERS Handbook? I believe it originally described Perl, and not at all unjustly.
Don't even have to go that far, it's word for word in Perl's own documentation. They've become self aware at some point it seems.
And who could say it had been too long coming?
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.
As can be seen on Petzold books examples.
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.
Exactly why there is still enough room to be a smaller executable.
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.
Note that the project is using mingw, so it's not using any Microsoft DLLs for the CRT anyway. mingw brings its own CRT along.
I thought Mingw defaulted to MSVCRT.DLL as the CRT?
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.
It's really hard these days to get Mingw to use msvcrt. It's not supported.
If you add a manifest you’ll get post-Windows-2000 GUI styling.
You can do it without a manifest too, it involves calling "CreateActCtxA" and "ActivateActCtx" with the appropriate Activation Context object. Manifest file is much easier.
But why would you possibly want that? ;)
I’d be interested in seeing a PR for that. I’ve always found the manifests a bit confusing.
can you elaborate?
As well as information about side by side assemblies (ie: library versions), a Windows manifest file has various settings and a declaration of compatible versions of Windows that affect Windows' handling of the app, such as whether it can handle paths over MAX_PATH, if it is hi-dpi aware, or if it knows about themed controls.
https://learn.microsoft.com/en-us/windows/win32/sbscs/applic...
If an EXE doesn't have a manifest file, Windows assumes that it's ancient, so it falls back to conservative defaults like ye olde USER controls to try and avoid breaking it.
In my experience, the wxWidgets documentation and forums are pretty good resources for Windows manifest files. YMMV.
An example from one of my projects: https://pastebin.com/Jvjn5C6S
You need to reference it from your resource source like so: https://pastebin.com/8FUi4tMz
And then compile that into an object file with windres: x86_64-w64-mingw32-windres rsrc/metadata/windows.rc -o winbuild/windowsrc.o
And link it with your project like you would any other object file.
The entire structure is also documented on MSDN with all possible values - https://learn.microsoft.com/en-us/windows/win32/sbscs/applic....
While MSDN is a bit impractical to browse (there's simply so much stuff in there) it's usually the best place to go to for documentation when doing Windows dev.
Strongly disagree. There's way too much mystery and magic number usage in the official documentation.
The magic numbers (hashes and UUIDs) sort of make sense because there's a slightly adversarial interaction between developers and Microsoft. If you just had a compatibleWindowsMin and compatibleWindowsMax field with version numbers, people would just go ahead and put "9999" in the max field, and then OS upgrades break applications again. By using UUIDs instead, an application developer can't intentionally or unintentionally declare compatibility with unreleased Windows versions.
Can you recommend any good alternatives for someone looking to learn programming using windows APIs?
If you're going for a small EXE, I'd recommend telling GCC to optimise for size with "-Os".
Link-Time Optimisation with "-flto" might also help, depending on how the libraries were built.
I'd suggest `-Oz` instead, as it optimises for size above all else at the cost of performance, unlike `-Os` which is less aggressive (but likely produces similar code anyway). `-Oz` is somewhat new if I remember correctly, so it depends on the GCC version.
-Oz and -Os are basically identical with GCC in my experience. LLVM -Os is much less aggressive.
Random example: https://news.ycombinator.com/item?id=39547329
That's more than 10x bigger than I expected, given that all it seems to do is manipulate a list view. Something like this should be doable in under 10KB.
The title reminds of recently released really fast file explorer called File Pilot. Made in C and weighs 1.8MB only https://filepilot.tech/
Nostalgia: My first job in 1997 was a windows apps in C++, it was weather software used on ships and oil rigs, we used to ship updates on floppy disk via helicopter.
Great respect! I've tried many times, without final result. I'll try to use this for learning purposes!
Btw. I like how Inno Setup used some very old Delphi 2 compiler to create exe so small it would fit without breaking the zip compliancy. I read it somewhere 10+ years ago, so not sure if this is still the case, but still. And the initial dialog was done in pure winapi.h (of course it was winapi.pas which made everything more difficult for me to learn from)
There's no application manifest for the common controls so it will look outdated
Contains numerous memory leaks, doesn't permit arbitrarily long lists, and saves and restores uninitialized data. Really sloppy.
Every time I see something in C for Windows I see people using MinGW, gcc and friends just like they would do in a Unix-like system. But I wouldn't expect that they are tools that Microsoft recommends for developing on Windows.
So, a honest question from a Linux/Mac guy: what is the Windows-y way to do that?
A cursory browse says there's no Linux-isms in the code base, so the Windows-y way to build that (without going into licensing) would be to use the Visual Studio Build Tools. They're the CLI toolchain you get for Visual Studio, but free when compiling open source projects (as of recently: https://devblogs.microsoft.com/cppblog/updates-to-visual-stu...)
They still notionally need to run on a Windows machine, although I recall people have managed to run them under wine before.
EDIT: It took me a few reads to parse what the link is saying, so: using the toolchain to compile open source dependencies is fine, even if your codebase is closed source, so long as the closed source part isn't being built with the Build Tools.
Thanks!
I wrote a guide [1] that collects this information in one place.
[1] https://akr.am/blog/posts/a-guide-to-compiling-programs-on-w...
The most Windows-y way to do that is to get Visual Studio (Community Edition is free for non-commercial use). It still has project templates for pure Win32 apps even, although they are C++ rather than C.
I use Pelle's C. Never seen it mentioned here. Based (a long time ago) on LCC. I think it's sweet.
I remember Pelles C being the first full C11 implementation, which I felt was impressive for such an unpopular toolchain.
I guess they can't switch to a FOSS licence because of the licence of LCC? How much of the original code even remains after more than 20 years and several C standards later?
Odd that there’s so much conversation about this. Why is that? Genuine question.
I find frequently the smaller and simpler the subject, the more people can easily confidently grasp it and generate quick to share opinions.
Noticed this with Code Reviews. To a point, the smaller the code change, the more comments and input. Beyond a certain size, comments and reviews (without nagging or external incentives) trends towards zero.
I think this Win32 app could be done in C under 20 kB.
Iirc mingw links its libc statically, that's probably why. Fwiw I still remember that an empty VB6 project with one form compiles to 20kb (16 if you select "optimize for size"). It still needs its VM, which is a dll that was considerably larger. I think about 1mb, but it's been a while.
We shipped our VB6 software on a 1.44 MB floppy disk. Actually, we had to add some random stuff to the installer to make our software fit on two floppies instead of one, so that customers would think our application was more complex. Our CEO wanted to make sure that the end user had to eject disk 1 and insert disk 2 during the installation. Sometimes you want to go big. So size matters.
That's amazing! It reminds me of when a client once asked to make the red more red. I asked him to look at it again the next day and he said it was much better. I didn't have to do anything.
Similar to programs like TurboTax that add delays and “working” animations to make the user think something really complicated is being achieved.
I built it with VC++ and it's 23,552 bytes. Close enough. Command line:
So, this uses the DLL version of the Microsoft CRT. Don’t know if that counts as cheating :) Why is a CRT needed here anyway, beyond very basic stuff like startup code and memcpy?.. Is MiniCRT[1] an option?
[1] http://www.malsmith.net/minicrt/
It possibly isn't, and you can typically do without by telling VC++ to build without linking to it - though the compiler has a bad habit of generating calls to memcpy, so you may have to provide your own implementation of that (and hope the compiler doesn't spot what you're doing and helpfully replace it with a call to memcpy). But aside from that, it's easy enough. You don't need the CRT startup code; you can use WriteConsole to print to stdout/stderr; you can use LocalAlloc/LocalFree to allocate memory; there's a few string routines in the Win32 DLLs that are a bit like the C equivalents, if nothing in the ordinary Win32 API does what you want.
I used to be into this stuff and created a number of useful <10 KB EXEs this way. I'm not sure it's really worth it though! I started out writing code for computers where you'd have like 16 KB free RAM, and this wasn't much, but for most purposes you didn't actually have to sweat every single last byte. So on the same basis, now that even my laptop (which is over 10 years old) has 16 GB RAM, I am not massively inclined to worry about anything less than 1 MB.
The downside to me knowing how small programs can be if I don't link the CRT is that I can't help but feel like what I've written is terribly bloated if I don't make an effort to avoid the CRT.
I blame people who constantly comment about how bloated software is now for making overly conscious of program size even when its down at a point where it doesn't matter :')
I remember TheGun, a Win32 notepad app in 6K, written in MASM. Anyone know where to find it?
https://web.archive.org/web/20051230021217/http://www.movsd....
hutch was a legend. RIP.
https://forum.exetools.com/showthread.php?p=127834
The allure of the perfect notes and todo app. Having gone through phases of various modern todo and note apps over the years, I’ve finally let it go and decided to embrace just using text files. (Neovim for me, not that it matters which text editor one uses)
It’s not that there aren’t cool apps for this stuff, it’s more that I have a trail of data across various todo and notes apps from years of different tools.
One solution to the problem of making things “feel native” is to go all in on letting go of native. Target a different style, be it minimalism, Commodore 64, pixel art, etc… it can be fun that way, especially if it’s mostly just a tool for you.
If text files are your world, then http://todotxt.org/ might be for you. I'm currently using "pter".
Thanks for sharing, OP!
It's probably too late, but this qualifies for "Show HN" if you update the title to have the prefix "Show HN: ".[0]
I think the size of the source is actually more impressive than the size of the binary. I'm impressed that you can implement the whole thing in what looks like about 1 KLOC in just four .c files.
[0] https://news.ycombinator.com/showhn.html
This is a blast from the past and it is neat to see some bare bones coding projects, but as others have said this is hardly "modern".
Hell to the yes!
If you know, you know.I'm to understand that entire divisions of Microsoft itself no longer know how to code anywhere near this level, which is why many of their flagship applications (looking at you, Microsoft Teams (work or school)) are Electron monstrosities you can watch draw themselves like Windows 1.0 apps -- on modern multicore hardware.
EDIT: more correct function sig
I'm apparently so ancient I am just looking at that line of code thinking "isn't that the standard entrypoint for a Windows app?", lol; is there something else to know? ;P Oh! I guess, staring at it, isn't that wrong?... if you use LPCTSTR, one would expect that you are trying to be agnostic to UNICODE, but then you also have to use _tWinMain, no? (And, after considering that, I went and double-checked, and the C is also incorrect in this context.)
Funnily enough, the "ANSI" versions of Win32 functions are no longer considered a legacy thing, now that the OS offers UTF-8 as the supported encoding, and apps can explicitly request it (regardless of non-Unicode codepage setting) via manifest:
https://learn.microsoft.com/en-us/windows/apps/design/global...
Here is one of few Windows apps that I have written, albeit in C#. compinfo is a single, 431 KB windows executable.
It displays basic computer info including user name, computer name, OS, model, serial number (service tag), CPU model, memory, IPv4 address and uptime.
https://github.com/jftuga/compinfo
> A modern, native Windows Todo application
What's modern about it? Also you could have used C++ instead to remove some potential issues, and those global variables...
Use std::string and std::array or std::list, some anonymous namespaces, remove all the malloc, etc. Your code would be half the size and still compile to the same assembly language without the bugs.
> those global variables...
What about them? In a 500 loc app there is no practical difference and there's only ~20 of them with clear purpose.
> Use std::string <...> or std::list <...> remove all the malloc, etc
> still compile to the same assembly language without the bugs.
I see you have no clue what those things actually compile down to.
To note that even the latest editions of the famous Petzold book, before the C# edition, switched to using the common C subset from C++ and compiling with Visual C++ in C++ mode, instead of plain old C.
Already by Windows 95 timeframe, only C diehards would be writing Windows applications still in C instead of VB, Delphi and C++, as the more mainstream languages, there were obviously other ones to chose from as well.
> Use std::string and std::array or std::list /.../
While nothing is modern about this approach, if we're going the WINAPI route, there's very little to be gained by using std::string instead of the LPWSTR that WINAPI offers (and plays nicely with). I would definitely avoid plain C strings (char[]) but rather use the wide version (which is what LPWSTR is under the hood). But for std::array or std::list, I don't see how the codebase would vastly benefit from them.
In that case, make yourself a favour and use WIL, aka Windows Implementation Library.
https://github.com/microsoft/wil
It’s not modern but there’s some value to programming close to the metal so you understand what’s really going on. The problem domain is simple and easy to keep in your head. Good learning exercise. I wonder if there’s an assembly language version of something like this.
Back in the day I used to use UPX to compress my executables to achieve impressively small sizes.
I remember doing that for some custom installer I wrote. It felt like a good idea for 5mins until it got flagged by a bunch of anti virus software… had to sign the installer in the end and spent a lot of time reporting false positives.
Still common today when dealing with Go executables.
Curious what this would look like written in Rust, using the windows-rs bindings.
You'll definitely want to allow theming on your controls, if for no other reason than to let them feel native like the rest of the OS.
I'd also suggest at ATL, to make your life a bit easier without making it much heavier.
Fun project! I think the smallest I ever shrunk a win32 application was on the order of 2-4kb by writing in ASM. It was a great illustration of why 10x binary size is actually a great trade-off in terms of productivity.
Title says 278 KB, github says 27 KB.
I assume this is a typo in the title, OP if you ask dang nicely I’m sure he would be willing to remove the typo.
Never easy to pull these off, so congrats! App might be modern in the sense that you coded it in 2025, but looks straight out of Windows 98
The Readme emojis tell me this was vibe coded.
Incidentally, NASM makes Win32 programming in assembler a breeze.
I think the hard limit of 100 todos is the best feature of this. Why don't other todo apps have this feature?
I think 127 would make more sense.
Some of us have a lot to do!
If only I can do the same across 3 desktop and two phone platforms...
It should be written UPPER CASE, in Pascal, maybe...
Simple and elegant!
Less LOC than React/Redux app... Makes you think, what were we doing last 30 years :/
I’m pretty sure an app as mediocre as this would take up less code in React, or even plain JavaScript. The UI is a single table and a few inputs and buttons, and its main way of communicating with the outside world is message boxes - trivial to do in a web browser.
278kb? you are doing something very wrong, this should be possible in 10kb!
The actual code in the repo definitely compiles to less than 10k. The rest is bloat from linking CRT statically.
Above, someone shared this tip to compile down to 23,552 bytes. Ref: https://news.ycombinator.com/item?id=43957984
Can you share how you can compile to only 10kb?
By "actual code" I meant the assembly that the application logic compiles down to, not the entire executable. But as far as the entire package goes, compiling it using clang with some flags I can get down to 19.5k without any effort. If I wanted to waste time on this, ripping out the CRT entirely and getting it to 16k would probably take less than an hour.
The pedantry in the comments of a todo app is exquisite. HN never disappoints.
Very nostalgic OP, warms my heart 10/10
Right now it's only 27 kb and I've added the manifest file :)
ready for enterprise todo
Interesting! I was just looking at raylib for this kind of thing: super light weight, cross platform, reliable, ideally C-based method to get GUI.
Raylib and raygui is truly incredible from my point of view. I succeeded in getting the macOS and Windows builds going on a bunch of cute little novel (not stock standard in the repo) examples in a matter of hours with AI help. I'm inspired by all I can do with this.
For ages I felt "cut off" from the world of Desktop GUI because it was so verbose, and had high friction - need a bunch of tooling, set up, and so on. And then everything was fragile. I like to work quickly, with feedback, and PoCs and results. I think in raylib I have found a method that really achieves this. For instance, check out this tiny little "text_input.c"
I love it! I feel unleashed again to program in graphics and games and real GUI! The first real paid programming job I had was using a lot of ps5 in Java and JavaScript (Open Processing) and I dug it! :)And the file sizes are sweet (to me):
- macOS: text_input - 123736
- Windows: text_input.exe - 538909
Two dependencies to distribute with on Windows: glfw3.dll and libraylib.dll (322K and 2.1MB respectively)
Raylib was built to make game programming fun. And maybe I will use it for that! :) But right now I want to use it for GUI. The issue with Qt and others, is while I like the idea of standard-Andy controls, I don't want to pay a commercial license - when I figure "it can't be that hard to get what I want" - as I plan to use this stuff for commercial/proprietary control-panes and layers on my existing products: BrowserBox, DiskerNet, and more.
At the same time I really respect what Qt have done growing their business and might be inspired or even emulate some of their model myself in my business.
Me no like inconsistent use of spaces.
What no clang-format or equiv in 1990?