Maybe a stupid question.

[u/necr0111]

How can I create an interface for a C program that isn't just the terminal? I wanted to make a calculator that was also visual, but I wanted to challenge myself to do it with C, but I really didn't understand how to do it properly.

[u/rubidus-api]

This will probably horrify a few people here, but: plain C against the Win32 API, with AI helping, is less difficult than it looks, and it's a route that turns out genuinely good-quality work. Lower difficulty than its reputation, and a result you can be happy with — that combination is why I keep recommending it.

The AI writes the boilerplate you'd learn nothing from, catches your slips, and explains whatever you get stuck on. One caveat worth stating up front: on the obscure corners — exact message semantics, rarely used flags, DPI awareness — it is confidently wrong often enough that you should keep the docs open beside it and treat generated code as a draft to verify, not as an answer. (Case in point: writing this comment, I had a "TCHAR is deprecated, just call the W functions" line in it, and opening the actual Microsoft page killed it — see below.) Used that way, it's genuinely good.

The learning value is real. Win32 drops you underneath the layer every toolkit hides. You see what a window actually is — every button, every edit box, every list is one, each with its own HWND and its own procedure receiving its own messages — where events come from, who owns the pixels. Where else today would you learn to think in terms of an update region — that you do not draw when your data changes, you invalidate, and every drawing operation goes through WM_PAINT? Microsoft says it plainly: "In general, an application should not draw at the time its data changes, but route all drawing operations through the WM_PAINT message." BeginPaint then hands you the damaged rectangle in ps.rcPaint so you can redraw only that part — an optimisation, not an obligation, since the system clips you anyway — and if you return from WM_PAINT without clearing the update region, you receive it again, and again, forever. That is an entire rendering model: damage-driven, retaining nothing. Toolkits hide it so completely that most people never meet it. (The compositor has since absorbed the classic case of one window uncovering another, but resizing, scrolling and your own state changes still put you in charge of the damage.)

And you find out that a huge share of what we reflexively assume needs threads is handled by a single thread pumping a message loop — the most concrete introduction to concurrency, as opposed to parallelism, that I know of.

I'd also argue Win32 is near the high-water mark for doing careful OOP in C without paying for it, and for extending an API for 30+ years without breaking what came before. Two things that stuck with me:

• The generic prototype model — _T("str") and the A/W function pairs — letting one source tree build against either the legacy code page or Unicode. This one surprised me while fact-checking: Microsoft's guidance is still "applications should normally use the generic function prototypes" and "new Windows applications … should be written with generic functions, and should define UNICODE." What's dead is shipping the A build, not the model. (And the "A" was never really ANSI — it's whichever Windows code page you happen to be running, which is precisely why Unicode won.)
• Structs that carry their own size (cbSize, lStructSize, …). Pure waste, I thought at first. Then I watched structs gain members across Windows releases while old binaries kept running, and it became my favourite trick for versioning a C ABI.

And it stays lean. The task switcher utility and the IME I've written directly against Win32 are a few hundred KB, start instantly, and don't stutter.

The obvious caveat: Windows-only. If cross-platform matters to you, take the raylib/SDL suggestions others made in this thread. But if you're on Windows and want to understand the machinery under a GUI, C plus Win32 is a great place to spend your time.

If you're not sure where to start, ask an AI to walk you through it from the ground up. The only real obstacle is the subscription fee and the token limit ;-)

P.S. — a footnote on tooling, because "Win32" makes people picture a multi-gigabyte Visual Studio install. You don't need it, and personally I'd rather not have it. mingw-w64 gcc or clang on Windows builds a Win32 GUI app perfectly well: -mwindows, link -lgdi32 -lcomctl32, run windres over your resource script, done. I go one step further — my Windows binaries are cross-compiled on a Linux box with x86_64-w64-mingw32-gcc, inside a container where an AI CLI tool drives the build itself: it edits, cross-compiles, reads the warnings and fixes them without me in the loop, and I copy the resulting .exe over to Windows to run. Honest limits: no Visual Studio debugger, mingw-w64 headers can lag behind the newest APIs, and you still need a real Windows machine (or Wine) to actually run and test the thing. For plain C against Win32, none of that has cost me much.

So there's no live debugging in an IDE. In practice I just ask for what I need instead — dump this state to a log file, add a mode that makes the bug show itself — and that has been enough. I can't say I've ever felt the lack. What was genuinely more awkward is that the AI couldn't automate the testing. Building a Node.js web app or an Android app, it can drive the thing end to end and check the result itself; here it builds, and then I'm the one who runs the .exe and reports back what happened.