Hacker News
points by lolpanda 3 days ago | 0 comments
In 2026 does it still make sense to build new Windows app using Win32 API? I was building a simple image viewer similar to QuickLook on Mac using Win32. I found it's very responsive. The code is less readable compared to React. For me Win32 is a good option if the UI state machine is simple enough.
[–] okanat 3 days ago
I think the sweet spot is WPF or actaully its FOSS version: AvaloniaUI. It is high level enough to be cross-platform and not stupidly verbose, however it is rather light pn resources. However, Win32 still wins in absolute minimalism.
[–] Scharkenberg 3 days ago
While Win32 tends to deliver the most resource-efficient and responsive apps if the complexity is not high, I have settled on the latest .NET + C# + Windows App SDK / WinUI 3. Making an app look good and fit into the modern Windows look is extremely hard with Win32 C/C++ and writing and maintaining it requires energy that I'd rather spend elsewhere. Besides, modern frameworks are making great strides in speed, efficiency and QoL features. .NET 11 is full of optimizations, for example.
[–] lloydatkinson 3 days ago
I've tried this and found the WinUI deployment model frustrating and user hostile. There are like 5 open issues on GitHub where people seem deeply confused (I'm one of them) as to if it's possible to build a plain .NET .exe. Some people have tried it and it "works", others try it and get obscure errors, it's a real mess.
[–] WorldMaker 2 days ago
It's definitely possible to build a self-contained EXE. It's not easy or the default for a number of reasons, including the fact that going back even to DOS the PC application deployment model for applications is folders full of shared library DLLs and a smaller EXE that makes use of them. (The Win32 page model was built on it.) Modern .NET excels in that, including in the classic DOS installer model of "just copy the files, no installer required (but you'll probably build one anyway for extra branding opportunities and a few bonuses)".

Some .NET versions <= 4 installed a lot of their DLLs globally in Windows and if you were exact version tolerant enough (and GAC binding magic lucky enough) you could distribute a single EXE without an installer and expect some number of Windows users it would "just work" with only the EXE (and other users you would get complex dances of Windows Updates and .NET Installers to debug). Modern .NET decided on the classic DOS style "folder of DLLs" model over "global DLL cache and DLL Hell". You can no longer assume that the output EXE can "just work" on some supported Windows machines, but can better assume that the output folder of DLLs and EXE will work as intended generally on every supported Windows machine.

[–] Scharkenberg 2 days ago
Not everything is flowers and sunshine (got a couple of open issues myself... in .NET MAUI too), but whether one can build a single, compact, self-contained exe does not define the hostility of a framework or platform, IMO. .NET was conceived as an enterprise-friendly development framework and that's where it shines the most. Quick-and-dirty/mean-and-lean/distribute-and-forget development was never its forte. I would appreciate that feature too, but it's largely a non-issue.
[–] lloydatkinson 1 day ago
Both replies totally misunderstand my comment.
[–] 72deluxe 2 days ago
Why not use something like wxWidgets?
[–] Scharkenberg 1 day ago
Apart from deeper technical issues: I don't like how wxWidgets look and that touch is seemingly not considered a first-class citizen like mouse+keyboard (yet).
[–] 72deluxe 23 hours ago
But wxwidgets is just the actual native user interface?
[–] 72deluxe 20 hours ago
Replying to myself as I cannot edit now: and therefore since wxWidgets is the native user interface, it has no "look"
[–] chuckadams 3 days ago
Unless your name is Raymond Chen, you probably want to at least use ATL/MFC, which are frozen but still supported. Me, I'd take Qt any day, or wxWidgets if I wanted to go minimal.
[–] keithnz 3 days ago
yeah, it's still pretty good for a lot of things. I've found with AI it's now super easy to do native win32 apps really easily. It used to be doing all the plumbing was a PITA. There were wrappers to make it easier, but now you can do it directly. It means you get super performant, tiny binaries, that start instantly. Like windows should be. However, at home I've moved to linux a while back so way less useful to me now, though works fine with WINE. I still use it to make little utilities for work though.
[–] WorldMaker 2 days ago
In 2026 with WINE, Win32 is a surprisingly handy cross-platform GUI toolkit with surprisingly relaxed licensing restrictions. WINE even helps maintain the cross-platform support for modern .NET's (.NET 6+) System.Windows.Forms which allows you to write Win32 in a modern language stack with relatively modern conveniences.
[–] adzm 3 days ago
Win32 API is great and responsive; ATL/WTL (and MFC) are still very useful abstractions with little cost. The biggest pain point is having to handle a lot of things manually, like DPI awareness (and themed controls). Even things like Emoji and other modern text features are not available through GDI and require DirectWrite iirc. Still, I'm surprised how useful it manages to be regardless how old it is.
[–] queenkjuul 3 days ago
When you say responsive, you mean like it reacts quickly, or it responds to screen size?

In web we refer to the latter but i feel you mean the former.

I built a toy project in .NET 2005[0] with WinForms and the experience was actually excellent, binding data to controls was dead simple, it felt surprisingly modern. But i can't imagine how I'd make the UI resizable lol

[0]https://github.com/queenkjuul/spotify97

[–] WorldMaker 2 days ago
WinForms provided some responsive control patterns like "anchors" and "dock" properties [0] and other sorts of relative positioning. Some third party component libraries included even more advanced layout controls. A lot of applications would add in imperative code to make up for more complex scenarios that anchors/dock didn't handle well enough. WinForms was still built on the back of pixel-perfect positioning assumptions, so there was always people doing it manually with handwritten/hand-tuned math.

It is something I appreciate about WPF and other successors is that responsive layouts became the default and low level building blocks with "pixel perfect" harder to do and less of an "after thought" on top of pixel perfect WYSIWYG that's easy to get responsive wrong, but even with WinForms people were building responsive apps back in the day.

[0] https://learn.microsoft.com/en-us/dotnet/desktop/winforms/co...

[–] canucker2016 3 days ago
Probably more responsive.

Windows apps always had to be able to respond to dynamically changing screen dimensions since the user could change from one screen resolution to another while an app was still running. Apps would get a WM_DISPLAYCHANGE message in their top-level windows message processing loop. Docs say WM_DISPLAYCHANGE was introduced in Win95.

[–] NetMageSCW 3 days ago
I would say WinForms in C# is still the best today.
[–] jim180 3 days ago
I am having a blast with AI + C + WinAPI. The responsiveness of WinAPI is awesome
[–] toast0 3 days ago
I mean, if I was building a windows app, I would. Microsoft always tries to convince people to stop using it, but Win32 keeps working.

If Microsoft ever makes something that actually meets all the needs that Win32 addresses, they'll probably build a compat layer and a) your win32 code will still work in compat mode, b) that new thing may be worth targeting.

[–] ack_complete 3 days ago
As someone who does raw Win32 API based UI... no. The Win32 UI system has been neglected for many years and is missing very basic functionality by modern standards, including dark mode support, antialiased rendering, hardware accelerated image stretching, and wide color gamut / HDR support. You're going to be working around a lot of ancient restrictions compared to a more modern UI and rendering layers on top of it.
[–] the__alchemist 3 days ago
I wouldn't, because I do not think we should put up barriers in our application between OSs (Nor have to maintain separate UI code bases for each OS you think might use it). So I use cross-platform kits. There are compromises, but I don't care about the looks native qualification compared to works anywhere. Yes, the software looks like an EGUI app (etc. Substitute Qt), instead of Looks native, but I appreciate how I'm not setting up barriers between OSs or making extra work.
[–] jen20 3 days ago
I also don't care how if things _look_ native, I care if the work like a native app. For example, on the rare occasions I touch Windows, I expect standard keyboard shortcuts to work. On macOS, I expect full integration with the accessibility frameworks and OS affordances like services.

A lowest common denominator idea of "everywhere" is just not that useful.

[–] the__alchemist 3 days ago
How do you handle this for your own software? Could you please link me to one of your project's websites and install instructions? What specifically do you find that one OS has that's mandatory for a good/native UIs that others don't?

I hear you on the native UI is better all things considered. I'm trying to figure out how that works in practice. I.e., to accompany a "cross-platform UIs are inferior to native ones", you would be effective to also include the workflows you use. In a realm where you choose options, eliminating one should come with illuminating another, as one must choose a path, and others could be eliminated for their drawbacks as well, leaving none available. What is your path here?

[–] jen20 3 days ago
No - almost all of the software I work on is at least one of:

- proprietary,

- command line tooling,

- single-platform.

A good example of what I consider to be a great approach (not mine) is Ghostty, which has fully native UI per platform and a shared core between platforms. JetBrains tools also go out of their way to integrate with platform conventions everywhere.

An example that cross-platform toolkits usually get wrong: cursor navigation in text fields. Home and End do different things on different platforms, and on macOS, basic emacs/readline bindings are supposed to work in all text entry fields.

It’s worth noting that this extends beyond GUIs - command line tools written in Go tend to use “package flag” which is native nowhere. The standards between Windows (which has two, in cmd and powershell), GNU-style and “legacy” Unix style are just not reconcilable without implementing platform-specific behaviour.

[–] NetMageSCW 3 days ago
So instead you are creating a bad UI for all of your users. That’s very Java application (or perhaps Electron these days) of you, but seems like a poor trade-off to me.
[–] the__alchemist 3 days ago
Could you please clarify why you think cross-platform means bad UI?
[–] Doohickey-d 3 days ago
These days, with LLM assisted development, with relatively simple GUIs, I would go towards platform native GUIs per platform. And then all the shared business logic goes in a shared "core", with the GUIs only serving as "dumb" inputs and outputs, with all business logic shared between them.

LLMs are quite good at tedious tasks such as keeping multiple GUIs in different languages in sync with each other.

[–] Rohansi 3 days ago
You still need to test all of those separate GUIs though so it's still costing more.

You also generally don't want them to actually be in sync because there are actual UX differences between platforms that you need to align with to really be native. If you don't follow that then what's the point?

[–] floydnoel 3 days ago
I couldn’t disagree more, when it comes to UIs. They should match the platform they are being used on. Cross-platform always produces a very sub-par experience. But us developers tend to care primarily about what makes development easiest for us.
[–] the__alchemist 3 days ago
What does this mean in practice for software you write? What OSes to you build it for, and what OS or GUI-specific conventions to you follow which don't apply to others?

edit: Link software you wrote's installation instructions.

[–] floydnoel 3 days ago
You can just look at my profile and see some of it, or check out my website. I’ll have a new app to show soon, so stay tuned!
[–] the__alchemist 2 days ago
Those are web and mobile apps... Not PC software.
[–] floydnoel 2 days ago
web and mobile are both platforms with their own special quirks, APIs, and behaviors. however, you missed that Logbook Ed also runs on macOS.
[–] the__alchemist 2 days ago
I will just throw this out there:

- You have made the choice to make software only run on MacOS, excluding the (majority) of users who are not using that. This is balanced against the upside of native look and feel.

- I agree that web and mobile have many differences when comparing them to each other, or to PC software. The differences and conventions which relate to application development between Windows, MacOs, and Linux are much smaller than those. (The only concrete example mentioned in this broader discussion was Home and End keys can have different behavior). I see this as a matter of degree, not kind.

I keep coming back to "So, we are deliberately limiting our software to a single OS because... (Vaguely articulated reasons about native look and feel? About cross-platform applications having "bad UIs" and "subpar results"? I can't do anything with that because it's too vague, and doesn't match my experience. Home and End keys or other keyboard shortcuts which are easy to feature-gate if the GUI kit doesn't handle it which it probably does?) When weighing pros and cons, I need to see the cons.

[–] Rohansi 3 days ago
Not everyone has the resources to build five or six different UIs.
[–] floydnoel 3 days ago
I think it’s better to do a good job once rather than five or six bad jobs, but we all have different priorities.
[–] the__alchemist 2 days ago
What specifically to you about cross-platform UI means bad job? I.e. what functionality does Windows specifically support that must work when running the application on Windows that Gnome, for example doesn't? (Or any other GUI/OS comparison)
[–] Rohansi 2 days ago
A lot of it boils down to native widget look and feel. It's pretty silly in reality because there are multiple possible options for what is native on Windows (Win32/WinForms, WPF, UWP, WinUI, ...) and Linux (Qt, GTK, ...), so native apps will still be inconsistent. It's probably just an Apple thing really, because every other platform is already a big mix of different UI styles.
[–] Rohansi 3 days ago
The way you worded this message could mean either a) people should focus on a single platform using native frameworks, or b) people should use a cross-platform framework instead of spreading themselves too thin. Maybe even both?
[–] floydnoel 2 days ago
I suppose it’s hard to follow a thread across multiple comments, but like I said, cross platform UI toolkits give sub-par results.