I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid.
Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that:
Enumerating the machine’s displays and their bounds
A few API calls. Probably a few hundred bytes.
Placing borderless, titlebar-less, non-activating black windows
Creating non-functional windows is trivial. Another few hundred bytes at most.
Intercepting a global keyboard shortcut
A few dozen bytes to call SetWindowsHookEx.
Optionally running at startup
Write to the appropriate registry key. A few hundred bytes.
Storing some persistent settings
Ditto. Another few hundred bytes. You can use a .ini file too, for around the same size.
Displaying a tray icon with a few menu items
Most of this size of this will be the icon itself - a few kilobytes; the next biggest contributor will be text strings; and the rest is accomplished with a few hundred bytes of API calls.
Add another few hundred bytes of (not much) logic, round up to a kilobyte and add maybe another for general overhead.
But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Using Win32 to write a UI in Windows is like pulling teeth. There are bindings for Rust but even still it's a nightmare.
MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell.
I think it's fair to say that the entire story for native app development is a mess - which is most likely why Electron became so popular. There just isn't a practical sane alternative.
The sane alternative is macOS because there is one thing that Windows lacks; a community. Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.
When I look at the apps on Windows, all I see are abandoned projects and MVPs with a borderline malware financial structure.
> Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.
Microsoft has had even more people working on Windows software..
"Developers, Developers, Developers!" - Steve Balmer
Microsoft has always had vastly more developers and development of software for Windows.
Apple still after all these years has a tiny market share of overall platforms, software, all of it really.
Not sure how you can suggest Apple is somehow the bastion of software development. If you write mac software, you'll be targeting a platform with 15-20% market share at best.
Isn't software development about making money? On phones, if you want to make money you have to target iOS, since this is where you have the people with money to spend on software. Do you believe that the vastly larger installed base of Windows guarantees more money for everyone?
At a previous workplace, we released certain software targeted at media/videography professionals for macOS first. The immediate response at conferences was, 'do you have a Windows version? We all use Windows.' Once we ported our software to Windows, the uptake was easily 1.5 orders of magnitude greater than for macOS.
The era of 'macOS is a better media computer' is long gone.
>On phones, if you want to make money you have to target iOS
It's funny that you think Android users are broke-ass nobodies. That's some reality-distortion-field fanboi nonsense. And it's also hilarious that you think phone apps are useful software that costs lots of money.
Most people in tech with high-paying jobs that I know are using Android, because it's actually pretty awesome compared to the locked-down walled-garden that is Apple. More than half my friends use Android or Windows. They use Android because it isn't as locked-down as iPhone. They use Windows because it runs all the software they want it to run. We also really don't care about Apple's blue bubbles.
No, Apple users are not the only ones with jobs. Plenty of Android users have plenty of disposable income. It's a ridiculous argument to make that Apple users have more money to spend.
>Do you believe that the vastly larger installed base of Windows guarantees more money for everyone?
I don't have to believe it, the market believes it. People vote with their dollars, and they aren't voting for Apple all that often worldwide. Plenty of wealthy people use Android and Windows. I'd wager that most big companies are still run on Windows - and I know this experientially, from back in the day setting up computers for major corps, it was 85% Windows, 15% Apple. Always was, always will be.
Way to go with anecdata to try and disentangle your feelings from reality. Come back when you have cold hard facts. With 27% of the market, they make twice as much money on their app store.
Making money does not equate to popularity. It only means their users are suckers for overpaying. $1000 for a monitor stand? $700 for 4 tiny wheels? Yet people pay these absurd prices for their niche over-hyped and over-priced hardware. "A fool and their money are soon parted."
Then how do you square that Apple has a billion worldwide users? They're all fools? Everybody who bought an iPhone is an idiot? There's no way an 900$ iPhone is a good purchase when the equivalent device that Samsung advertises as a competitor is over a thousand bucks?
You lost my interest when you suggested that iPhone was the platform to target because those users have all the money to spend. This pointless internet interaction is over.
I've been a fulltime Linux user for years but there are tons of excellent Windows-only apps.
Here are some that I miss: Directory Opus, ShareX, Wiztree, Everything, AltDrag, AutoHotkey, Paint.NET, irfanview, SumatraPDF. I'd add Keepass2 as well but fortunately KeepassXC is a thing.
Those are all feature-filled (in the bloat-free good way) and they've all been around for over a decade (from memory). Most are free and open source to boot.
MyLifeOrganized was the biggest thing I gave up when I switched to Mac in 2013. Still miss it -- nothing else (Omnifocus, Things, outliners, etc) has been as effective as a system for me. They've been talking about a potential Mac app for year, I'm on the waiting list, but I've given up hope that it'll ever come. Even if it does, I doubt it'll be as good as it is on Windows.
Comparing oranges to apples.
Win32/Win API is (one of) the native API to do Windows programming.
Pure C is not the native way to do application programming on macOS. As I mentioned elsewhere, you can bring up a window with a button with no code on macOS. You can make that button show a string on a label with a handful lines of code.
Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it is to be considered in certain situations.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are still some reasons to do so, of course, but Win32 isn't one of them -- one can use it from a memory safe language just fine, e.g. https://github.com/microsoft/windows-rs
A good rule of thumb for programming languages is to check what the general recommendation is on HN and do the opposite.
Using win32 from Rust is nonsensical. This is the kind of use-one-tool-for-any-job Visual Basic 6 programmers used to have, except VB6 would have actually been much better than Rust at Windows programming.
Unsafe blocks are common when interfacing with C or C++ code.
The first thing you want to ensure is that you avoid unsafe in YOUR code. That is, after all, where you are going to create your bugs.
Ideally, there is no unsafe code in the crates you use. If there is, at least there are more eyes on that code to catch problems. You can inspect and debug that code, and others can do it for you. Others may battle test it and stress it far more than you will.
And at least the unsafe code is isolated to a few areas in the supporting libraries. Less to inspect. Less to debug. Fewer places to introduce memory related regressions.
It does not at all follow that, given an unsafe block, we may just have well used C++.
It's straightforward to contain the unsafe usage and potentially write safe wrappers and structures around it. Memory bugs mostly stem from the larger application in conjunction with the API anyway, rarely only the API layer.
IDK man, I wonder how TF did the creators of Winamp do it? Were they so much smarter than the programers of today? And Winamp 2.95 still works on WIndows 11 today.
IIRC Borland Delphi was the most popular tool back then for making Win32 apps since it was so easy to use.
> Were they so much smarter than the programers of today?
Unironically the answer is yes. I've been watching this for at least 15 years.
I think one inflection point is when everybody who was coming up became accustomed to GC languages. Within a decade of that trend starting, nobody could reason about memory anymore.
With the AI boom we're going through another inflection point. When coding is synonymous with using an LLM, nobody will be aware of how anything works (or doesn't)
Also a lot of people got into the industry because they saw the salaries of programmers, but have no real passion for computers or software. They did the studying enough to pass the tests and write an algorithm to pass the interview and land a job. But they don't have the drive to make things better, think outside the box, or write something they can be proud of.
AI has accelerated this because it's becoming harder to detect the frauds.
There is a certain amount of truth to that I think
I do not think anybody was “smarter”. There were smart and less smart people then and now.
But the “typical” practice changes. And that changes what you get. I think your “typical” programmer is more productive today in terms of what they can accomplish. But that work is going to be built at a higher level of abstraction and likely a lower level of run-time efficiency. As a percentage, fewer people understand or take into account the lower level details.
It is not just about new tech. After all, I can write all my code in RISC-V assembler. And I can manually allocate memory and manipulate pointers in C#. It is just not what people normally do these days.
The web and web apps as pushed by Google and others was another nail in the coffin of efficient software.
From Android to whatever web framework they’re peddling as development solutions, these are not designed for efficiency, but for time-to-market and consumption by front-end developers.
I worked on Windows programs similar to WinAmp, which had custom drawing, skins with custom shapes, etc. Usually written directly in WinAPI, VCL (C++ Builder, not Delphi) or a combination.
It was a matter of having access to the right (although limited) resources such as Petzold’s book, Codeproject and experimentation. There was no big rush, no start-up hustler mentality and most importantly hardware resources mattered a lot and it was a point of pride to create efficient software.
The development culture of present time is the opposite of that: developers are drowning in documentation, the default solution is technically inferior and the hustler mentality’s dominating.
https://github.com/alexfreud/winamp : does indeed look like classic Win32 in the files I randomly tried, although there's also a QT DLL and a whole load of other stuff on there.
If you don't want to spend quite so much time byte shaving, and you don't want to deal with memory safety or _UNICODE, you can do it in .Net Framework in half the time.
The main function of the app being discussed here is to draw solid black rectangles on the screen.
Don't forget the "average person", I'm assuming someone relying on software as a tool, doesn't care about the stuff "designers" seem to obsess over, and will actively hate if you break their workflow by doing things like adding useless padding that makes them scroll more or shows less information in the name of "modernity". There's a lot of specialized niche software for various industries, often very expensive too, which looks like it came out in the early 90s. As long as it works well, users won't complain.
Oh, how I hate when vendors bring "modern web" aesthetics to desktop utility programs. For example, Docker Desktop could go a long way in terms of usability if it just sticked to Win32 common controls - the kind of buttons, labels and list views that have been around since Windows 95. Maybe I wouldn't even have to wait 10 seconds for the main window to show up every time.
You mean conceptually or to match it? Native components are pretty much impossible to match without actually using the native framework which provides them, so you need WinUI/WPF.
Win32 provides its own components which are basically Win95 style apps, and you can draw the components using some graphics APIs by yourself.
The whole native development area is a mess exactly because making your own (decent) renderer is a huge undertaking.
Agreed. The Qt framework, which is a cross-platform UI framework, does a decent job mimicking the native Win32 looks. Inside, the code is a giant mess. But on the outside, the API is very well thought out and easy to use.
But you are making false equivalence, the Win32 GUI API is decades out of date from modern UIs. I can use flutter and make a pixel perfect equivalent of the above UI in an hour, with the exact same responsiveness behavior on both windows tablets and desktop, and scales perfectly in high DPI displays. 3 hours if you want the toggle animation timing to be exactly the same.
I came from the WinForms world so don't pretend I don't understand Win32 programming. The fault lies with Microsoft for not investing in it more.
You talk like that is a bad thing. Win32 UI works, is fast, works everywhere even on ancient 640x480 server screens, safe mode and vnc in 16 colors without opengl, directx, Angle or vulkan.
Flutter is nicer to scale and maybe design but it is a massive overhead. Skia still has trouble with some drivers and causes lag or falls back to software rasterization. Hot replacement while coding is pretty neat though. It runs much better on mobile devices imho.
It works, and fast, but it is not portable. I would argue something like Qt is much more viable in $current_year for cross-platform development. Or if you're really dead-set on actual native components, then I guess wxWidgets works too.
The functionality of that is not hard at all. A few checkboxes, a trackbar, and a hotkey control (there is actually a standard Win32 control for this: https://learn.microsoft.com/en-us/windows/win32/controls/hot... ), with "pushlike" checkboxes at the top to be drawn replicating the monitor layout.
But that "modern" style is... disgusting and repulsive. That whole dialog is bigger than one of my monitors due to how much wasted space it has.
My favourite example of "Modern" style is the toggle switch, shown even in that image. I laugh a lot of the times I see one, it's the 'replacement' for the checkbox, but it's so awful at actually telegraphing it's current state in a consistent way- (the entire purpose of the control!) that it has to have a label indicating whether it's on or off. I find it so absurd that people genuinely put this stuff into their programs and have no problem with it, because apparently we are just supposed to accept this type of poorly designed component because it's more "Modern".
If your application saves me time (is intuitive) or enables me to do tasks that I couldn't do before (is powerful) then I don't care one whit what it looks like. As long as it doesn't actively hurt my eyes to stare at you can do whatever you want.
Sure, if I'm building something for myself or fellow hobbyists this approach works (though in that case I'd prefer a good TUI/CLI). But if you're building an app for the average person, how it looks has a big effect on whether they choose it over an alternative.
It's funny, the "modern" look has become a countersignal for me. If the app looks like a webpage, I instinctively don't want it. Not because of aesthetics, but simply because I've come to associate that style of appearance with a lack of (or awkward) keyboard shortcuts, featuresets dumbed down to a level appropriate for chimps, various nags injecting friction against getting work done (ads, feature tours, logins, update reminders, etc) and laggy, resource-squandering performance thanks to some kind of bloated rendering framework like Electron with multiple V8 hosting processes sprawled across chrome.exe instances or whatever.
Case in point, the Dropbox Simplified Desktop App was a huge improvement for me. It nails just about everything I ever needed their app to do, and removes all the user-hostile fluff I never asked for. Similarly, I found Windows 11 Enterprise IoT LTSC to offer an improved desktop experience compared to traditional Windows, thanks to its exclusion of a lot of the cruft Microsoft otherwise shoves down the throats of users who, as far as I can tell from frank discussions with many of them, likewise actively don't want.
I'm not saying your desire to make your app look polished means it's crap, but beauty is in the eye of the beholder. Just like fashion, I wouldn't be surprised if we see a shift in the aesthetics trend as more people discover a retro feel sometimes signals a better user experience.
They really don't. Though if Microsoft wanted to, they could solve that too. For example, the OS control panel used to be extendable. Technically still is, just not the new one (and of course both remain). Then you could have this UI or something very similar to it right in there.
Several integration points like this have been removed, supposedly because third party software was just too bad in how they used them, causing issues. Or at least so goes Microsoft's perspective. Personally, I find that very believable! If by integration points the only thing one can imagine is calling into random third party code on the regular that the user has installed, bang spank in the middle of critical user flows, on the same thread and in the same process as itself, that's exactly the kind of grief I'd expect to occur...
If only there was a way to provide a way to craft e.g. custom flyout menus for the taskbar or custom pages in the Settings app, without invoking arbitrary third party code and possibly causing crashes and hangs in system apps and menus... or just not letting crashes and hangs affect the application (e.g. Windows Explorer) calling them in the first place.
That sounds like a great way to make a mess. Look at Microsoft's own apps shunning proper File dialogs and instead presenting a giant, bizarre pane of mostly text and a few crudely-drawn boxes in order to save a file. You have no idea what you're looking at or where you are in the file system.
Then there's the removal of title bars from Windows. You often have no idea what app you're looking at. Pull up a PDF in Acrobat and also in Edge. Now, at a glance, which is which?
A couple of weeks ago, I decided to write a GUI utility to propagate my new PuTTY default settings to existing sessions. I took the Go Walk package, which is Win32, and was done in several hours, most of those spent hunting down an obscure layout bug. So long with memory-unsafe languages.
I made an app using Win32 in Golang. It controls my monitors' brightness and "true-tones" them to match the sun cycle via DDC/CI. It has autostart, global hotkeys, persistent settings, sits in the tray, silent auto updates etc.
The hard parts were seeded by Claude Code. Happily maintaining and modifying it for close to 3 months now. Just a data point, especially about not needing C++.
There were decent and reasonably thin layers over that to solve the immediate practical issues (e.g. Delphi, MFC), but they're no longer fashionable and nothing seems to have replaced them in the same space. Maybe we need a "NoFramework" phase to get back to RAD again?
>> But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.*
Eh. I spent many years writing cloud/backend software on the JVM, in between stints writing desktop software. When I was first writing desktop software, it was all in C and C++, and I got used to it, but it wasn't pleasant.
When I came back to writing desktop software in C again (just a few years ago), after writing in memory-safe languages for so long (Java, Scala, Rust, Go), I found going back to C to be just so tedious and annoying. It's just incredibly unpleasant to be chasing down segfaults and data races and crap.
So I think saying it's a "crime" is hyperbole, but even for apps that don't have untrusted input, it's still much more pleasant writing in a language that doesn't let you write memory safety bugs.
(Absolutely agree with you on how it's possible to make nice, small, non-trivial Win32 apps, though I haven't done Windows app development in a couple decades. But I think a lot of people would save themselves a lot of time and headaches if they reached for .NET or something higher level.)
This is the way. Everything is fine if you are a responsible dev that writes secure code. You can very clearly see the pattern of shitty framework after shitty framework coming and going. Why bother when the C++ code will outlive whatever shitty framework is coming next?
I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I find it a breeze to write native gui programs in pure win32 and c++.
Recently had to add a new feature to and old program that was last updated in the XP era and two things to note:
1. The program did not need to be updated to run on Vista, 7, 10 and 11, shit just kept working throughout the years.
2. I loaded the project into Visual Studio 2022, it converted from VC6 and compiled without problems, added the feature, shipped a new .exe to the customer, and it just worked.
What other platform has that backwards and forwards compatibility success story?
I feel like I'm the only person in the world who would rather write ugly win32 jank for the rest of my days than ever having to touch an "elegant" or "well structured" Cocoa codebase. In win32 if you want a button you call a function and pass a hande, in the Apple world you first subclass 7 interfaces in some unreadable Smalltalk-wannabe syntax and pray you don't need to access the documentation. And of course they constantly change things because breaking backwards compatibility is Apple's kink.
After bouncing around GUI toolkits (from win32 to SwiftUI) and web for 30 years I have simply run out of fucks. They all suck. Each in their own unique way. Apple aren't worth singling out - they are just their own special isolated variant of it.
Tcl/Tk is pretty good in terms of rapid development. Unfortunately it has stagnated quite a lot over the years.
Gtk on the other hand is absolutely terrible and its developers don't help by completely rewriting things every few years and breaking all existing code in the process.
Have you tried WinForms? It isn’t the latest hotness so Microsoft has to be dragged kicking and screaming to support it in current VS, but they were forced to do so because corporate developers still have some clout.
I still think that WPF was the peak desktop UI framework. Extremely powerful with lots of small composable primitives, can easily do declarative but drop into more traditional event-driven imperative style where it makes sense.
I live in a bizarro universe where I started my career working on an expansive WPF desktop app on .NET Framework 4.0, and am still working on it now on .NET 10. From my perspective it's been WPF the entire time, and it's been pretty okay.
Similarly, I've been doing It development for pretty much the entirety of my career. When I see the struggles to make remotely useable apps in other frameworks I'm very happy I chose this path
This is patently false. To add a button to your UI, you open your window’s nib file Xcode/Interface Builder, click the plus button on the toolbar, and add a button. Then you control-drag from the button to File’s Owner and choose the method that you want to invoke when the button is clicked. Done.
Yes, generations of Mac and Windows programmers have used GUIs to create their GUIs. Visual Basic, MFC + App Studio, .NET + WinForms, Interface Builder…
Why wouldn't you program a GUI with a GUI if one is available? Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.
> Why wouldn't you program a GUI with a GUI if one is available? Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.
I've been a developer for a long time; I've built pretty large applications in all sorts of technologies and I now just prefer defining GUIs using text. Having a live GUI preview is great but actually dragging and dropping stuff is not more efficient to me.
To fit your analogy, using source code is like writing a song using musical notation. I'll write the song, then play it, and then go back to notation to fix it or expand on it.
In my experience drag-and-drop GUI editors work great until you add the constraint that the window has to be resizeable. Then it becomes a mess of clicking through dialogs for every UI element to make sure the anchoring and display flow is set up correctly, and you often have to go back and redo this whenever you add a new element or change the layout of the form. I think the best GUI programming experience I've ever had is on Palm OS simply because it had the constraint that every program always displayed in fullscreen at 160x160 (pixel-doubled to 320x320 on later devices) so you never had to deal with resizeable windows.
I'm not saying you should never program with a GUI, but it comes at a cost of being able to read the code and tell what the result of the code will be, and all the associated benefits of version control and code reviews that you lose.
And as a side-effect of that, merge conflicts become murder when your "Fix right-hand margins" commit with a 20 line readable +/- diff instead becomes a 1000 line +/- diff.
The one time I built an iOS app using the xCode IB so that I could get up to speed more quickly, I really came to regret it several years into the project.
If this is a real issue, it seems to be an issue with the way a particular toolkit handles visual WYSIWYG editors. Lazarus serializes the object properties into a simple and readable text format that follows the class declarations themselves and you can easily diff them. E.g. here is the diff of a minor change i did (added a new button in a panel with an event handler and modified a property in an existing button):
I swear I meant to write an "often" in my previous post. But yeah, that was largely directed at the interface builder in xCode, for iOS - it gives you storyboard/xib files that are effectively-not-human-editable (and entirely non-mergeable) xml.
That feels like quite the exaggeration. If all you want is a button, all you need to do is initialize an NSButton and then tweak a few properties to customize it as desired.
If you want something more custom, subclass NSControl and you’re off to the races.
And if Obj-C isn’t your cup of tea, one can use Swift instead, even in a codebase that had been only Obj-C prior.
You can now use SwiftUI, which is, as of the latest version, quite stable. They used to change things a lot between releases a few years ago, but nowadays you don't need to refactor your code every year. Only issue with it is that it's iOS first, so you may need to fallback to AppKit (Cocoa) to implement more complex elements.
If you were doing "classic" Cocoa in the way it was intended, you wouldn't need to subclass anything for a simple button.
You wouldn't even need to write a single line of code, you'd just instantiate said button in Interface Builder, hook it up to a delegate (e.g. a window controller) and off you go. You can create a hello world example with a handful lines of code.
And even if you'd rather create the button programmatically, it's not much more involved.
Sure, if you're coming from Win32 and expect to program Cocoa without learning Cocoa, you're out of luck. But I guess that applies to all frameworks.
I'm probably another, but I have never done any professional Win32 work. You know, those kind of jobs are rare now and I doubt they want anyone without experience.
What are you talking about? In Cocoa if you want a button you drag one in via Interface Builder. You don't even need to write any code. If you want it to do something, you type the name of the function it should call.
To me this kind of "no need to change anything" implies stability but there's a younger cohort of developers who are used to everything changing every week and who think that something that is older than week is "unmaintained" and thus buggy and broken.
One of the earliest security issues that I remember hitting Windows was that if you had a server running IIS, anyone could easily put a properly encoded string in the browser and run any command by causing IIS to shell out to cmd.
I mentioned in another reply the 12 different ways that you had to define a string depending on which API you had to call.
Can you imagine all of the vulnerabilities in Windows caused by the layers and layers of sediment built up over 30 years?
It would be as if the modern ARM Macs had emulators for 68K, PPC, 32-bit x86 apps and 64K x86 apps (which they do) and had 64 bit Carbon libraries (just to keep Adobe happy)
I think its at least as much of a working environment preference.
Once I became experienced enough to have opinions about things like my editor and terminal emulator... suddenly the Visual Studio environment wasn't nearly as appealing. The Unix philosophy of things being just text than you can just edit in the editor you're already using made much more sense to me than digging through nested submenus to change configuration.
I certainly respect the unmatched Win32 backwards/forwards compatibility story. But as a developer in my younger years, particularly pre-WSL, I could get more modern tools that were less coupled to my OS or language choice, more money, and company culture that was more relevant to my in my 20s jumping into Ruby/Rails development than the Windows development ecosystem despite the things it does really well.
Or to say differently: it wasn't the stability of the API that made Windows development seem boring. It was the kind of companies that did it, the rest of the surrounding ecosystem of tools they did it with, and the way they paid for doing it. (But even when I was actually writing code full time some corners of the JS ecosystem seemed to lean too hard into the wild west mentality. Still do, I suspect, just now its Typescript in support of AI).
The one big challenge I've had with big legacy Win32/C++ codebases is migrating it fully from 32bit to 64bit. Loads of know-how and docs for complex GUI controls and structs are lost to time, or really fragmented. Other than that, yeah it really does all just work once you're past that.
Well it's still a 32 bit program so I guess that helps.
Would probably require some porting to make it 64 bit native, but as long as you use the WPARAM, INT_PTR typed and what not correctly it 'should just work'.
Yeah that's the bulk of the work for migrating small Win32 apps. Things escalate when someone has built their own dynamic GUI framework over Win32, used a range of GUI controls, and then built event-driven apps on top of that, it's a lot lol
I went through that a few years ago and it actually went pretty smoothly. There were a few UINT_PTR or DWORD_PTR changes I had to get used to and a couple of string glitches (we mostly used the _T() macro for strings and already used the _t variants of string functions in the original code, so that helped).
The biggest problems were DAO (database) and a few COM controls that were not available in x64.
How do Linux and Java do it, when you want to compile your program in both 16-bit char and 8-bit char mode? Oh that's right, you don't.
You can pick one or the otherfor Windows too, so don't ask me why it's done that way. It was originally so you could compile for both the new hotness Unicode, and the old compatible ASCII.
Partly because Microsoft resisted UTF-8 forever, and so using the ANSI/multibyte strings didn't therefore give you modern functionality. Why they didn't implement Unicode for Win95, I'm just not sure. If they had, the only reason to compile an ANSI version would have been to target Win32S (Windows 3.11).
Or, they could have implemented a UTF-8 code page for Win32 as soon as it was available and then most software could just use byte strings.
In 32-bit windows, you used to be able to see if a pointer was valid or not by seeing if it pointed to the last 2GB of address space. If it did, it was pointing to Kernel memory that was not valid for user mode code.
But then Large Address Aware (4GB limit) changes everything, and you can't do that anymore. In order for a program to be Large Address Aware, you need to not try to do things like check high bits of pointers, then every single library and DLL you use also needs to do the same.
Win32 programming has been reduced to a small niche now. Even 20+ year old Win32 books don't cover things in-depth (or practical use cases) let alone the 32bit->64bit migration
Yeah that doesn't always work that well. Think you were lucky.
Add high DPI to the mix and things get rough very quickly. Also the common control have weird input issues (try ctrl+backspace in an Edit control). All those little things need to be fixed carefully for something to be ok in 2026.
Winforms is great until you try to make windows dynamically sized, or deal with DPI nicely. In every other regard it's still fine, and for accessibility actually _better_ than many subsequent frameworks. And produces nice small fast executables.
I assume that if Microsoft hadn't abandoned WinForms for the next thing, it would support dynamic sizing and DPI properly. It's mindboggling how much time and effort they've wasted coming up with new GUI frameworks instead of just improving on what they have.
It does, but many still think it is like using VB 6 and don't learn the additional APIs that provide that support, e.g. FlowLayoutPanel and TableLayoutPanel.
Or, unless they've changed it, hardware accelerated rendering. Winforms was based on System.Drawing, which used GDI+, which was largely software rendering. This was confusing because GDI+ was not really related to GDI, which had and still does retain some hardware acceleration support. Even basic color fills start becoming an issue with a big window/monitor.
Winforms is also .NET based, so it's inaccessible if you don't want to write your UI in and take a dependency on .NET.
transparency as well. WinForm really struggles with the idea of stacking elements on top of one another where there is an arbitrary amount of transparency or tricky shapes. Its just not worth the hassle compared to WPF.
I've not done MFC Win32 programming since 1999 but if I recall those programs don't execute the main() function. They instantiate the Win32 class for your app or something like that. I can't remember any details anymore.
You still have a main function in Win32, it's just called WinMain and has a slightly different signature.
MFC has CWinApp, which you'd normally subclass, and a stock WinMain implementation that instantiates that, but it's not strictly necessary to subclass it, just convenient.
They don't use main because they use WinMain, which is the entry point for Windows apps that don't run in a console window.
WinMain should create an instance of the app class and call Run.
"You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 which feels pretty unfair
> "You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 which feels pretty unfair
I get that if I post more than six replies in an hour.
But that’s the point the article’s making. At the C level you’ve got a fully functional system. Above that level (even at the C++ level), feature support is a mess.
Honestly, your GUIs are too simple to be part of this conversation. Try writing something like Spotify in WinAPI and that's not even a complicated GUI either.
Actually it doesn't. Win32 skinning is either making a control completely from scratch or hacking into undocumented aspects of the native controls - i.e. what WindowBlinds does. AFAIK modern Delphi has some component that basically follows the WindowBlinds approach.
> Win32 skinning is either making a control completely from scratch
In almost all cases you just need to handle the drawing yourself, and you get fairly broad access through the API to do so through the various non-client and client window messages.
Now, Windows has gained some newfangled components over the years with more or less integration, I'm thinking basic Win32 controls.
What all cases? Windows (basic Win32 at that) provides a lot of controls like buttons, checkboxes, inputboxes, scrollbars, radiobuttons, comboboxes, listboxes, etc which do all their drawing themselves and you do not have any way to fully skin them (without hooking into undocumented stuff). Some controls allow for custom drawn elements but pretty much always that is just for the elements themselves, not the entire control.
Again, unless you have existing Windows 8/10 applications that were written against WinRT, UAP or UWP[0], that make use of WinUI 2.0, forget about touching anything related to WinUI 3.0 or WinAppSDK, stay away from the marketing.
Exception being the few APIs that have been introduced in Win32 that instead of COM, actually depend on WinRT like the new MIDI 2.0 or Windows ML.
Keep using Win32, MFC (yes it is in a better state than WinUI 3.0 with C++), WinForms, WPF, if using Microsoft only tooling.
They were even forced to revamp WPF status at BUILD 2024, given how bad WinUI 3.0 was back then, and it isn't if it got any better, apparently it is in the process of being open sourced, to see if the community can take over the mess a $4 trillion valued company cannot fix.
Really, stay away from WinUI, unless you're a Microsoft employee on the Windows team without any other option.
[0] - Can explain by the nth time the differences, if one feels like it.
Just wanted to add a shoutout to WinJS for posterity, with which I built a Windows 8 app that I had published to the Windows Store for a brief period of time. Then they open-sourced the UI part of WinJS and decided it was just a web framework instead of an officially supported method for building Windows apps iirc, which was the end of my foray into the Windows store.
I was actually part of a team at Barnes & Noble.com which tried to use WinJS for a serious application. (We were previously using Chromium Embedded Framework, or our own hand-rolled WebKit integration, for the desktop e-reader.)
I have a WinJS book somewhere, from Microsoft Press.
When it was announced at PDC, they only talked about WinJS and nothing else, the folks of .NET Rocks have a few shows where they mention they thought .NET was done, and they needed to refocus into something else.
The show where they interview Miguel de Icaza they go into this.
I have the book (and CD) on my shelf above my machines in my home office. I vaguely recall buying this at Costco, around the same time I bought the 4 volume Microsoft Press C++ series (for dirt cheap, at the time) from Costco.
MS Press used to publish some amazing references. I have a LOT of 'em.
It probably is now, but I don't think it was at the time. This was back in the early Windows 8 era, when apps were called "Metro" – 2012 to 2015 I think? I'm primarily a .NET dev by trade, but I wanted to try something different with WinJS so invested time in learning that.
WinJS was a bit different, where your app was genuinely just a bundle of JavaScript and a UWP host process dealt with the rendering. (No Electron-esque to deliver with your app) Made for some tiny, succinct apps.
In that light, it is troubling that Friday’s blog post [0] announced
“moving core Windows experiences to the WinUI3 framework” as a measure to improve the quality of said experiences.
As long as it only applies to Microsoft employees, maybe the pain using C++/WinRT will finally improve the Visual Studio tooling for the rest of us, but I doubt it.
These steps are necessary stepping stones in getting the thing good, the question is, given Microsoft's tendency to abandon UI frameworks halfway, apart from the classical ones listed above, is if they will keep it focused until its gets as mature as those.
The only good thing to say about that is it removes the stupidity of using Electron (or the Microsoft Edge equivalent) for built-in Windows apps and the Start Menu. SMH.
Heh, nodejs uses V8 which shares legacy with WebKit's JavaScript core, itself being forked from KDE's KJS. Fun to think that eventually, some KDE code spiritually made its way to the windows start menu
1. Do not relay LLM output. If someone wanted, they would use it, ChatGPT is free. Post your own, human, meaty thoughts.
2. The blog post explains all these technologies, one just need to read it further than the title. It might be a big ask here on HN, I know, but still.
The lessons I've learnt building and shipping a few a Windows apps at scale are basically:
(1) Learn Win32 and use those ancient APIs if possible, they're extraordinarily stable and you'll probably need to reach for them anyway. They're not that scary.
(2) Don't use any Microsoft-owned UI toolkit, you'll get burnt. Literally anything is better. Ideally choose a toolkit that doesn't prevent layering in Win32 tweaks on top, otherwise you'll end up hitting cases the toolkit developers didn't think of and you can't fix. You're going to need a custom WindowProc eventually. You need to have access to the underlying Win32 window lifecycle and handles.
> "(2) Don't use any Microsoft-owned UI toolkit, you'll get burnt"
This is 100% true for all of their techs produced within the past ~20 years, but WPF and Winforms are extremely stable with no real issues.
It's so weird too because most of everything they've done in the past 20 years has basically just been incomplete remixes of WPF. If they just stuck with WPF and extended it onward, something like a UI toolkit equivalent of C#, it would 100% be the gold standard for Windows development today, and perhaps even UI development in general if they open source/standarded it.
When they announced UWP I was just starting a new side project and I thought, let's check it out. I was hoping it would basically bring WPF into first class citizen territory. Instead, they made them needlessly incompatible. Like writing for both NeXT and MacOS, but on the same platform. I got discouraged right away and have really never done any significant Windows work since, which turned out to be a great move for my sanity.
Ahhm. At previous $DAYJOB, I inherited a WPF app written in 2012; I stumbled upon several WONTFIX bugs through the years - mostly having to do with shared memory bitmaps, having to manually call GC at times, and a host of other things.
Stable, but many issues. Stay away if you value your sanity and do anything nontrivial.
WPF and Winforms may be stable, but they're not going to work well on a modern machine with a HiDpi monitor. Same with Win32 controls.
My take: Use Win32 for opening windows and interfacing with the OS. Use a different toolkit for actually drawing inside the windows.
Ideally a toolkit that can paint in sync with window open and resize, otherwise you'll get Electron-style window flickering. And something that supports multiple windows in a lightweight way, since you're going to want popups, menus etc. to extend outside parent window bounds
the should just have updated wpf with their newer widgets and just continue to improve it and even make it cross platform. (basically what avalonia is doing)
Hypothesis: This could be due to the toolkit's handling of color profiles. You see this a lot in macOS land with images that use a Display P3 colour profile, e.g. screenshots from a Mac or iPhone.
Native toolkits are usually more advanced and tend to properly support the colour profiles and allow for wider gamut output. Whereas historically the web had poor handling and would assume sRGB, causing more "washed out" output.
Let me chime in and say that plain Win32 API is a perfectly viable option if you are using C++ (or another "OO" language) and if you are willing to sink a couple of weeks into writing your own MFC-like wrapper.
Clearly this is not an option for those who are just starting up with Windows GUI work, but with little experience it is really a matter of 2-3 weeks of ground work and then you have full control over all nuances of the UI, yours to extend and mend as you wish.
If there's one thing that Microsoft is really good at, it's ensuring deep backward compatibility. So anything that's based on Win32 API is going to be stable. If it works now, it will work later.
I have some examples from 10+ years of development updates accumulated here - https://bvckup2.com/wip
The main thing that's hard going down this route is dark mode support. The Win32 USER and common controls just don't not support dark mode, but are actively hostile to it due to the amount of hardcoded light colors and backgrounds in the system. All of the system colors are light regardless of the dark/light system setting, highlights are hardcoded to light blue, disabled controls use a hardcoded color, half of the window messages for changing control colors are silently ignored with theming is enabled. Menus are among the more difficult to deal with as they require extensive owner draw.
On top of this, there are a small handful of system UIs that do support dark mode and make your program look inconsistent with dark mode regardless. Message boxes will switch to dark mode, and so will file dialogs -- which is a problem if you've used the Vista-style customization, as any syslinks will appear in a color of blue that's hard to read against the dark mode background.
First, dark mode is for people who set their screen brightness too high.
Second, win32 is designed with the ability to change all the default colors and you used to be able to do this by right clicking the desktop and selecting "properties". If dark mode doesn't follow this - just another symptom of Microsoft's siloing incompetence. The team that wrote dark mode may not have been aware that this feature existed because parts of the platform are so disconnected from other parts.
Dark mode for apps is a setting in the OS and a general expectation now, it's suboptimal to ship a new UI that doesn't support it. And, again, Win32 message boxes in your program will switch to dark mode whether you want them to or not.
Win32 controls ignoring system colors goes much farther back than dark mode being introduced in Windows 10. The theming engine that broke a lot of that functionality was introduced in Windows XP. Beyond that, there were always a few hardcoded colors like disabled gray text going back to Windows 95.
Dark mode ignoring Win32 system colors is not incompetence. It was _intentional_. Dark mode was introduced by the UWP side, which intentionally did not extend it to Win32. To this day, there is not even a Win32 API for desktop apps to query whether dark mode is even enabled. The official recommendation is to compute the luminance of the UWP foreground color setting:
But they had dark themes for the XP theming engine, e.g. the Zune theme, didn't they? They could make the dark mode switch to a dark theme for XP-style themed controls and configure dark colors for the Win32 system colors.
Yes, and this is also how Windows 10/11 explorer turns some parts of its UI dark like scrollbars. But notably, Microsoft refuses to officially support Explorer's dark control themes or ship a complete dark theme, and because the theming engine only loads themes signed by Microsoft, no one else can ship one either without patching the OS.
Only a very small minority of users actually care about dark mode. It is not a general expectation for software, as loud as those users may be on forums like this one.
Mobile is different from desktop. Dark mode became popular with OLED panels because on those it saves battery, and blacks actually look nice, compared to the average LCD. I use dark mode on mobile but light mode on desktop.
I'm not sure how much Android use generalizes - I prefer light mode, but I'll use dark mode for the battery savings on portable devices with OLED screens.
> First, dark mode is for people who set their screen brightness too high.
Not at all. It became popular mainly because as part of the spread of the flat UI epidemic, the previously non-optional “light mode” OS UI themes all shifted away from midtone colors to blinding stark whites. This meant that monitor brightness settings that had previously been comfortable suddenly weren’t.
On top of this, modern flat UI light mode themes consistently have poorer contrast and delineation than their dark mode counterparts, because higher contrast with darker grays makes flat white UI themes appear “dirty”. So even if the brightness isn’t an issue, your eyes have fewer visual cues to guide them.
Aside from that, on IPS panel monitors lowering brightness past a certain point also greatly lowers color vividness which looks bad, which is why some of us like to keep it maybe not maxed but a bit higher than is comfortable with light mode.
It is not. I have some issues with my eyesight and dark mode makes it easier to use a computer in some lighting conditions. So for me dark mode is an accessibility feature. And yes you could use the ugly recolor feature windows has but dark mode does the same thing and looks better most of the time cause a UI designer actually looked at it.
> dark mode is for people who set their screen brightness too high
There can be other valid perspectives than your own.
I don't think your brightness sentiment is universally shared by most people, hence the downvotes. I think this comes from one particular study that people just end up parroting, possibly via third-hand gossip.
While a sufficiently low-brightness screen might have some specific advantages to dark mode, I think the issue is more nuanced than that.
First, not everyone can set their brightness to an appropriate level.
If the user is prone to migraines or light sensitivity, light mode even at a low setting could trigger headaches.
Light mode also produces significantly more blue light, which can have health side-effects as well.
If you keep a white screen on at appropriately low brightness in a dark room, the relative difference between the screen and the surroundings is still massive. This creates pupil strain as the eye constantly adjusts. Dark mode aligns the screen's luminance closer to the room's, reducing this strain.
Dark backgrounds make colors pop more vibrantly and prevent the "washed-out" look that can happen when bright images sit on a white background. It can also reduce halos visible around bright objects in photography apps and make the UI less distracting.
For battery-powered/mobile devices, dark mode uses much less battery power on OLED screens.
Maybe I grew up with Windows so the older uis don’t phase me, but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland. The average Windows user might stumble on an aero dialog, which is arguably less jarring in win11 than og metro.
> but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland
I've been around long enough to remember MS and their fans banging on about how bad other OSs were for their inconsistent interfaces, so I feel justified in getting a little riled at the hypocrisy of how much of a mess UIs are in Windows these days.
And I don't see it getting any better - they'd rather spend the time finding new places to slip in adverts. And this is far from the fault of app developers, while they often do have something to answer for wrt consistency, because the worst culprit is MS themselves both in their apps and the OS.
I shouldn't have to click to make sure the right thing has focus for instance, particularly after switching from another virtual desktop, I should be able to see this information easily but there is no consistency in titlebars and other window chrome any more.
Screenshots are made on Windows 8.1 box, the windows chrome comes from there.
Plus the whole thing is meant to work on ancient Windows versions (like, Vista and WS2008 ancient), so that ultimately defines the minimal common UI denominator.
The last time I built a native Windows app years ago, I used WTL 3.0. It’s a light weight wrapper on the native Win32 API, lighter than MFC. It took out the unpleasantness of working directly on Win32 API and wrapped it in a simple OO framework. It had access to all features of Win32. It could produce runtime binary in dozens of K, instead of MB or GB.
Microsoft released it open source later on. Looking at the repository, looks like it has been kept up and maintained, up to version 10 now.
WTL delivers very small and efficient code, very close in size and speed to SDK programs, while presenting a more logical, object oriented model to a programmer.
I don’t want to be that person, but if you can think of a decent API for your MFC-style wrapper, an AI should be able to write a decent implementation for you.
Agreed. In fact this supports the GPs point about using the rawest form of GUI manipulation.
For years we loaded up libraries and abstractions to minimize boilerplate. These hid the actual underlying mechanisms and often made specific customisations harder to do since you were taken away from the raw functionality.
These days AI is extremely good at writing boilerplate and in my opinion explicitly typed out boilerplate code is much easier to reason about than a library that abstracts things away to a one line annotation or similar.
A good example is that i've recently been leaning back to the raw Android apis for things like recyclerviews etc. It used to be 10+ files to changed to create an efficient scrolling view on Android with various resources and adapters required. So a whole bunch of libraries came out to try to abstract the complexity away. You know what though? I don't care about that anymore. I'm going back to the raw GUI APIs where possible because it's so explicit and clear even if it's 10x more code.
> And from what I can tell, neither are most developers. The Hacker News commentariat loves to bemoan the death of native apps. But given what a mess the Windows app platform is, I’ll pick the web stack any day, with Electron or Tauri to bridge down to the relevant Win32 APIs for OS integration.
Well yes as a user I prefer native apps for their performance. It's clearly a mess to develop native apps as the article shows. But as a user I don't see that problem. I do see ever worsening apps though. Like the total mess that is new outlook and teams.
That’s ironic given that the new Outlook and Teams are a mess because they are web apps instead of native apps.
Web apps cause have lots of trouble emulating proper native look and feel and often have wierd issues with things like consistent focus and keystroke navigation. They have all the dumb issues of Java apps with no improvements beyond not being Java and are slower and more memory heavy to boot!
Microsoft has always stood for mediocre quality software so that's no surprise.
Also, they stopped caring about Windows because they want recurring service revenue. Making Windows a subscription service for consumers would outrage the users (even though they kinda already do this for business with Microsoft 365). So the consumer market is just viewed as a billboard for M365 and Copilot. So everything you see there is just lowball effort, even worse than their normal quality.
It's demonstrably possible. And further, why does what some portion of Microsoft, a huge, multi-headed beast, does qualify as the bar for what is reasonable for users to expect?
This, and add to that the fact that web apps make it trivial for the dev to just randomly change the GUI out from under me without my consent or ability to prevent it, and, well, wonder why I and so many others dislike them? I want to be able to refuse app updates, thank you very much.
A question - Which portion of Microsoft, the multi-headed beast develops pure-native apps now ? Even the Windows 11 Settings app is Javascript.
The multi-headed beast has been assimilated by web-tech. They can't code GUI C++ no more - except their compiler/graphics team. And even the latter are dying.
Id be interested in a source for both this and the parent's comment. How do we know which settings pages use which tech? Have people been decompiling them?
Yeah exactly, on Linux I mostly use Qt apps and they're great. Even Telegram is native. The only one that I use that isn't is Obsidian. But all these notetaking apps are electron (and markdown) somehow.
Considering people are leaving Windows in part because Microsoft is shoving web slop into it, perhaps other devs should learn the lesson that it's not acceptable to use web frameworks on the desktop.
> But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
I disagree, the GUI layer is far from behind a safety critical component, and C++ is a battle-tested choice for everything from GUI, videos games, to industrial applications. If C++ is safe enough to control airplanes and nuclear reactors when used well, it is certainly safe enough for something as trivial a GUI.
The article also fails to mention frameworks like Qt, arguably the best way to write GUI apps in 2026. Qt is native (C++), has built-in memory safety features (but no GC), and is cross-platform.
Every non-trivial application will eventually use third-party non-system libraries.
I think "Native app development" has at least two meanings:
1. narrow meaning: the program uses a native UI toolkit (Win32, Cocoa)
2. broad meaning: the program targets one or more specific platforms and the UI is not not just a webview
Even with the narrow meaning, WxWidgets would qualify as "native development" (because it uses native UI toolkits under the hood), yet it is still a third-party library.
For me, native means "I can integrate a platform widget in the middle of it". For instance, with Qt, GTK or wxwidgets it's entirely possible to integrate a Win32 / Cocoa / X11 component right in the middle of your app (and it's super important for instance for things such as integrating audio plugins, where the plugin only gives you a HWND or NSView and you have to draw your application Chrome around it, have it follow resizes, etc.)
It's pretty much impossible to embed properly without edge cases in GPU-based renderers as far as I know, if you want layering of widgets (for instance a platform widget in-between two flutter widgets in z-order)
Most toolkits, including WebUI 3.0, render widgets on their own, so you can't distinguish just on that. I'd say anything written in an interpreted language is not native, and Javascript falls into that category. Dart at least is possible to compile ahead of time, and so is C#.
WebViews aren't written or rendered with interpreted languages either. It is also usually not Javascript that makes browser based apps so heavy. It is almost always the whole browser stack that is making them large and memory hungry, which is mostly written in C++.
You can also hook a WebView up directly to a low-level language and skip Javascript entirely, so does that mean Rust + WebView = Native?
I'd consider them "naturalized"; close enough to native that you wouldn't notice any big differences, but there are still minor ones if you know what to look for.
Author raises several good points. Why isn't the latest .NET runtime pulled down into Windows 11 devices via Windows Update? Why isn't there a better path forward for deployment?
It's another example of how they have completely abandoned any attempt at providing a good user experience across their products
I'm assuming but the versions are not fully backwards compatible so you can't just ship the latest version, they would need to ship all. There almost ten .NET versions released after the one which ships in Windows. And a new version is released every year.
The author does mention that .NET does have distribution options which don't require the user to install the runtime. You can have it package the full runtime with your build, either as a bunch of files, a self-extracting executable, or a standalone AOT-compiled native executable.
The author mentioned that the AOT-compiled executable is 9 MiB which is unacceptable to them. The other options will need even larger. Personally I don't see 9 MiB as a big deal especially when the author would rather go with Electron which is larger at worst (bundled Chromium) and only inefficient at best (system WebView).
Windows update is how it used to work and it's terrible. An update breaks old apps, or downloads a every single version (not feasible). Who would want to run windows update to install a new app?
It's just a bad idea. Today we just pack in the DLLs and it just works.
No one suggesting using Windows Update to install new apps, they are suggesting the current .Net framework should be elevated to a first class Windows citizen and included with Windows installs and updated with Windows Update, and that seems like and obvious idea that should have been implemented when .Net Core became .Net.
We would like it to be good. Whichever way to achieve goodness - either be backwards compat, or ship all the stable versions, I don't care but the current situation is silly. Apple gets flack for this and that, but their UI toolkit situation is lightyears ahead; you just pick the OS version you want to target in your app build settings and it will work that way for everyone.
100 MB per runtime, for everyone, and the majority of them are out of support. Is that really the good option? Why not the option the author dismissed: a 9 MB AOT-compiled executable which doesn't need a separate runtime?
That's what .NET Framework (the one that ships with Windows) tried to do. It usually worked out but you'll still run into compatibility issues sometimes after bug fixes, behavioral changes, etc. because people accidentally build software which depends on quirks.
That's something which is MS' problem; they're supposed to be the company who is best at backwards compatibility, but clearly have strayed from that path.
There are a few reasons that I can see why they don't integrate the latest .net.
First is that the security model changed with .net 5. Next is that they subsume Mono/.net core into the foundation of the language and this cost them them the ability to support Windows native development, specifically anything to do with Win32 API.
If you look at .net 10 and compare that to .net 5 you can see that they are trying to reintegrate the Win32 API but now it is in the all new Microsoft namespace.
The amount of change is too significant to act as a drop in replacement for the original .net framework. Maybe they could have gone a side-by-side installation, but the rapid development of The NET Framework I think made it too hard to tie to an operating system update. They wanted to free it from that update cycle of once a year or every two years and allow the development to progress rapidly at the cost of having to download it and install it each time.
There’s two versions of .NET. One is “legacy”, which is stable as anything and bundled with the OS. The other is “Core”, that only has support for three years and isn’t 100% compatible. The reason the latest .NET runtime isn’t bundled is the above: the stable version is bundled.
Really nice article, thanks - yes I found the same myself recently when trying to write a trivial (I thought) Windows app.
I first investigated the Windows native options and was pretty bamboozled; I wanted to use the "mainstream" "up to date" option (presumably c# and some framework) but as TFA describes, it wasn't at all clear which that was.
I ended up doing it in python with pyqt then finding out a clean deployment was a pain, so revisited the .Net options and remembered why I'd discarded them in the first place...
It is indeed a complete mess (at least coming in anew) and a very strange situation for the world's main desktop environment to be in.
It had been many years since I last developed a desktop app. A couple of weeks ago I used Tauri to create a simple app for Windows and Mac. Developing the app was easy with Claude. Building the app for different platforms and architectures was easy with GitHub Actions.
But after I had the msi and dmg files, my non-techy colleagues couldn't install the apps because they weren't signed. The workaround for Mac was fine (remove the quarantine attribute on the installer) but for Windows my colleague had to disable Smart App Control (SAC), which cannot be re-enabled without re-installing Windows.
I get the point of these protections, but the difficulty of getting past them surprised me. I thought that on Mac you should just go to settings -> security and click 'Allow Anyway'. And that on Windows you'd get a GUI warning that would need admin privileges to get past. But MacOS needed a terminal command, and Windows needed a control panel setting change.
I'm glad people still care about stuff like this. It drives me insane that the simplest form-based software that I build and compile ends up being 50-100 MiB; several times video games from the 80s that I grew up with that did much more complex work, graphically and computationally, on a tenth of the space.
The answer to your question of "why not Electron" at the end is: because then your app will suck. You've laid out the reasons why native apps are harder to make, but the reality is that Electron trades your ease of development for the user having a crappy experience. If you care about producing a good product, then you have to suck it up and make the native app even if it is harder.
Also, I think C# is miles better than TypeScript, but that's just my preference.
> However, for no reason I can understand, Microsoft has decided that even the latest versions of Windows 11 only get .NET 4.8.1 preinstalled.
.NET has new releases every year, supported for 2 or 3 years. That’s not really compatible with Windows release cycles. Also, if Windows 11 25H2 shipped .NET 8, and now Windows 11 26H2 would ship .NET 10, apps which depend on version 8 might break. Easier to just think of .NET as a runtime like Java or Python.
---
Regarding tray icons, 1Password, Signal, and Discord are all Electron apps, so they are using Chrome’s UI toolkit, and its menu component.
Myself, I’m happy with WPF. Starting with .NET 9, it comes with a really good WinUI-style theme.
.Net has always been hugely backwards compatible and breaking e.g. .Net 8 apps which will run out of support in November 2026. How is constantly needing to update .Net any different from constantly needing to update any other part of Windows?
Ideally they would just install newer .Net releases side by side and uninstall .Net releases as they drop out of support.
Microsoft promises things included with Windows will be supported ~forever. Adding modern .NET into the mix would break this promise and add more churn.
Automatically uninstalling .NET runtimes would break apps, and Microsoft will be to blame, not app vendors who failed to upgrade to the latest .NET. An app built for .NET 8 can run on .NET 10, assuming no backwards-incompatible changes in the runtime and system libraries, but this behavior is opt-in.
.Net releases are installed side-by-side. I agree with the Author that a more recent minimum install of the framework would make sense, especially with the existence of LTS releases of .net [1], seems to be every 2nd major version. I don't agree with the argument that Windows would have to guarantee a particular version is installed. If an app requires .net 8 and .net 10 is installed, the app can install .net 8 next to version 10. It would however require different silos within Microsoft to communicate and plan together.
.Net 4.81 is the last one before .Net Framework was unified with .Net Core. It's very legacy by now, but there would be many enterprise/business apps that still require it.
It has been a mess for 15 years and Microsoft keeps making it worse by adding new frameworks without retiring the old ones. Win32, WPF, WinUI, MAUI. Nobody knows which one to pick.
Yes, and the hubris sting-of-death was UWP.
They tried to make Windows into a mobile OS,
severely restricting the alowed actions of programs,
including strict certification to be able to run them (elsewhere).
Of course nobody went for this and UWP died a quiet death.
Recently there are signs that MS is trying to go back
to making products that users actualle want (Win11 reverts).
We'll see...
It's hard to describe how uselessly restrictive the UWP model was when they originally introduced it as "Metro-style apps" in Windows 8. Among the things it officially did not support included:
- Multiple monitors
- Non-full screen views
- Sideloading outside of the Store
- Offline installation
- Explicit threads - thread pool only
- Aligned memory allocation - malloc only
- Any C++ compiler other than MSVC
- Support for any version of Windows other than Windows 8
- Running apps as administrator
- Running more than one instance of an app at a time
- Runtime shader compilation
If any ONE of these things was a blocker, you could not write a Metro style app. And yet Microsoft pushed this extremely hard -- including almost completely ending any maintenance of Win32 APIs. And despite the many relaxations and extensions, UWP is still largely useless today, and now even itself seems to be going into maintenance mode. All of which has done a lot of damage to the state of Windows desktop platform development.
As an example of how bizarre UWP is, for some reason every time they published a list of new APIs added to it, they converted the list of API identifiers to lowercase in the documentation:
> They tried to make Windows into a mobile OS, severely restricting the alowed actions of program
They already had Silverlight! For Windows Phone 7. Then they killed that off too and expected the "plethora" of WP7 apps to be rebuilt for WP8 (requiring the beloved Windows 8 desktop OS for this task). Then they again expected developers to throw that away in favor of UWP for Windows 10, which unified the desktop and phone OSes. By then it was too late.
Old apps still ran on the newer OSes but the SDKs became dead-ends.
They'd lose too much enterprise software that's not being maintained any longer but still is business critical.
You can still run most programs from the Windows 95 era unmodified on a modern Windows 11 machine and a lot of things is relying on that under the hood.
Picking a stack for native Windows UI is like rolling dice, except sometimes you get bitten by COM for fun. If you care at all about backwards compatibility or deploying outside the MS Store you basically end up circling back to Win32 APIs much as the frameworks would love for you to pretend otherwise. Ironically, the 'official' docs now reads like a half-hearted apology for the last decade of churn.
This is quite timely as we need to write a simple UI for Windows (a few buttons, status, maybe a file menu). The main constraint is it must compile to a single binary (.exe) with no dependencies such as runtimes, DLLs, languages etc. It also needs to run on some older unsupported Windows systems, probably Windows >= 7, 32 bit.
My first thought was MFC. Basic, fast, well understood.
But then maybe WxWindows so we can cross-compile it (from Linux) and use the same UI on other platforms? It could probably be compiled statically although I've not tested it.
Or Mono, but that needs a runtime?
Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically?
Qt is compiled to a native .exe. It doesn't have a runtime. To give you a rough idea of size, I have 3 GUI application written using Qt/C++. The installers are 72 MB, 69 MB and 32 MB. The first 2 include a significant amount of documentation. I could probably get them a bit smaller if I really needed to.
For what you describe, .NET + WinForms or WPF will work just fine. These days it can built self-contained executables, although they won't be small (but then again, when many websites have multiple megabytes of JS...). Or you can target .NET 4.8 - for something this simple I doubt there'd be much difference but then you can ship an .exe that measures in kilobytes, and the runtime is included with every version of Windows going back 10 years.
You can build single-file executables for .NET 4, and I do, but there's no static linking, so you need to restrict yourself to assemblies that ship with the framework and whatever other prerequisites you're willing to install or assume will be installed.
Two notable caveats:
1. Certain newer C# language features require runtime support that doesn't ship with older versions of .NET, which can include quite a few DLLs.
2. In-process COM components can only be instantiated in .NET runtimes runtimes with the same processor architecture, even if the .NET program itself is processor-independent (which by default will use the runtime matching the native architecture), so you may need to ship multiple executables to match multiple COM dependency versions even if your program is otherwise processor-independent or you only intend to ship it for a single processor architecture.
For example, if you build a processor-independent program that relies on the Microsoft Access DAO library, it will by default work correctly on 32-bit Windows if 32-bit Access is installed, and on 64-bit Windows if 64-bit Access is installed, but there's no way to get it to work on 64-bit Windows with 32-bit Access without shipping a second executable (that can be identical with the exception of the 32BITREQUIRED flag in the CLR header[1] that can be set as part of the build process or with the .NET SDK corflags utility).
Rather than ship separate "32-bit (or 64-bit with 32-bit <bar>" and "64-bit" versions of a program <foo> that interops with some in-proc COM component <bar>, I prefer to build a single executable <foo>.exe, then create a copy <foo>32.exe with the flag set as part of the build process, and ship both to be installed side-by-side.
Then, since the native COM DLL isn't loaded until you actually create an interop object referencing it, you can just try to create an Interop.<Bar>.<something> object at program start, catch ComException with HResult == REGDB_E_CLASSNOTREG, then in the exception handler, run <foo>32.exe as a subprocess with identical command-line arguments and exit with <foo>32's exit code, unless you're already running in a 32-bit CLR, in which case you just fail normally.
> Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically?
You need a commercial license for that, but yes you could. But since applications are typically distributed with install bundles that put into application-local program files directories, it's not super-important as long as you only cherry-pick the Qt libraries you need.
This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.
I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.
Yes, that is true, but in practice nobody has ever done that. And the material complexity of offering that mode is higher than just dynamically linking the library.
Also, modern compilers make this method much harder to use. It is much harder to stably relink object files like that than to just use the normal dynamic link method.
It’s been a long time since I had to touch Windows development. If I had to do it over again, I would use React Native for Windows UI where possible and low-level Win32-React Native module bridges for user space code.
The last time I had to do Windows development was about 15 years ago. I used a library called WTL (I think a couple comments here mention it). I couldn’t use any of the newer stuff that Windows 8-10 were pushing because it needed backward compatibility. It seemed way less bloated than MFC, but not as annoying to use as ATL or rawdogging Win32 APIs.
Ironically, I was developing a Win32 app to build a cloud bridge to a Rails app (talking to Quickbooks COM API which was hell on Earth, with XML and XML definitions) on Mac, using VMware on Mac to talk to Quickbooks Windows. I was so annoyed with Win32 development I used the Chrome Embedded Framework library to build the UI for the Win32 app so I wouldn’t have to wrestle WTL for UI and just have browser-based views to drive UI.
I think it was very tempting to drop C/C++ development for .NET code, but I didn’t want to drop off user adoption by requesting users to download a huge .NET runtime if their computer didn’t already have it.
This was when I was building Levion, a Quickbooks Windows to Cloud Rails app…
You should run away from React Native Desktop screaming. It's built on top of WinUI 3, and inherits all it's problems, while also being dramatically slower. Almost all functionality requires writing C++ code, and communicating between C++ and JS is a huge pain in the ass. Use QT instead.
And if you think using it will let you port your app to other platforms, think again. There's no drop-in compatible equivalent of RNW for Linux, and the version for Mac is even worse than the Windows version.
t. works on a huge app written with React Native Desktop
The Windows code signing experience has prevented me from shipping apps that otherwise run perfectly fine on the platform. It is a nightmare and I cannot believe it wasn't called out in the "We want to fix Windows" blog post.
Just do exactly what Apple does. Charge me $100 directly from you and let me build an .exe that I can distribute on my website.
Most of the desktop applications I have wrote over the years have been in other languages like Java and Go as I have wanted them to mostly be cross platform. In these cases I have always used the Software UI, which in Java is Swing and in Go is Fyne. These are usually reasonably fast, don't necessarily look native depending on how its themed but ultimately fit the language better than trying to bridge to Win32 or GTK/QT.
I write .NET Framework 4.8 apps. And I will until .NET has an actual support lifetime. 4.8 will still be supported and receiving security updates in ten years, .NET 10 will be gone in 2.
Hobby projects should not be built on a platform that is constantly changing underneath.
My company is moving our main LOB app to .NET 10 in the near future. It's taken a while but has gotten to the point where .NET 10 has pretty much caught up to .NET Framework for feature support, and our take is that the cross-platform support, performance gains and newer C# versions are worth more than the stability of .NET Framework.
And the gap's going to keep growing - doing the upgrade now means future upgrades can be more frequent and incremental, rather than trying to move 4.8 to .NET 20 in a decade.
Unfortunely I have reduced my use of .NET, because some of the partner products that we use, or customers that were into .NET, took the opportunity for going into another technology stack.
Basically the kind of customers that were affected by the breaking changes, between Framework and Core, decided to keep the old stuff running in Framework, and consider other alternatives going forward.
Not sure how much these kind of customers matter to the .NET team's upper management in customer acquisition, but they surely lost a few along the way.
And now there is even CoPilot based migration tooling on VS 2026, because most likely there aren't that few that are still chugging along with Framework.
Yeah we don't have any plans on moving our WPF app to Linux, but the rest of our stack (job scheduler, ASP.NET service, web APIs, etc.) all has real potential to get off of Windows.
It doesn't really matter anymore. When .NET 10 is done, there will be .NET 12 and all your apps will run just fine on it.
.NET framework used to get new versions as well; it's just that it's not anymore. After moving on to newer versions, .NET framework feels clunky now. Also you end up missing out on a decade of new libraries.
Then why are they separate versions? I've got like five modernish .NET runtimes installed on my machine, half are unsupported, and there's no way to identify which ones are still needed.
Meanwhile 4.8.1 is built int Windows and supports apps written over like the past fifteen years. Why wouldn't anyone just use that?
I'm sure modern .NET has some nice things but the release model is not one of them.
Compared to Framework 4.8, modern .NET has a LOT more stuff in it, every year it gets more stuff and its essentially on version 9 now (they skipped .NET 4).
I stick to the LTS versions which are the even numbers and they are supported for 3 years each. after 2 years in, the next LTS is out and all I typically have to do is bump up .NET target number in the project and I haven't really had a problem. There were more changes back in the .NET Core 3 and .NET5/6 days, but that was like 5+ years ago now.
Also, you can build your apps with the framework included in a single executable even, and so anyone can use your app without having the framework installed at all if you are worried about whether the framework version is installed on their system or not.
Also if you wait the 3 years to upgrade the .NET version, then I doubt you would ever have a problem where the target system didn't already have the new LTS version after it will have been out for a year at that point.
If you really don't care at all about cross platform support which .NET offers really well now, then you could keep using Framework 4.8, but after nearly 10 versions of .NET the improvements to the C# language and runtime and everything are hard to ignore. Though I think there is some way with some package you can use the new C# language features with Framework 4.8.
I mean, if Microsoft cared about cross-platform support, I would too. But they don't have an officially supported GUI framework for Linux. I understand there are new things in the new .NET, but the story for upgrading to it and supporting it still isn't worth it.
When Windows builds in a modern .NET, I will use it! Bear in mind all of this above churn, while they claim is the new way things work, is inherently temporary: The reason .NET 4.8 is so well supported is Windows is built on it. So if Microsoft ever wants to use those newer things in Windows... Windows will have to build-in modern .NET features someday.
Microsoft approach is similar to the C++ approach where new way or feature won’t cut the older feature/way of doing things. I’ve heard Bjarne Stroustrup once in a lecture explaining the value of this approach as the language is used in so many fields and that it’s important for all code to compile allowing gradual migration.
In some ways, Microsoft is similar to that.
Apple on the other hand is fast paced so API can suddenly be deprecated and slashed and with Swift they’ve also made a language that is being changed from time to time in a breaking way.
While Microsoft’s approach similar to C++ it is a private company with no committee. This allows fast pace for ideas needed by a company in a competitive market. But, with ensuring backward compatibility, it makes each not throughly thought design -stick.
I guess Win32 is an exception since the first GUI concepts, our desktop designs hasn't changed that much. Window, Menu, Toolbar.
Back then,
The competition and pace was less intense allowing more time to think.
There were other constraints of course being applied by the hardware and stack available back then requiring more abstract designs.
In that sense, it’s quite interesting to see Win32 is kept while Apple’s switch to NS/OSX made everyone eventually transition into Cocoa.
"So when I went to work on my app, I was astonished to find that twenty years after the release of WPF, the boilerplate had barely changed."
Such is the benefit and the curse, I guess, of having the Windows API being locked in the distant past for backwards compatibility.
I've always been surprised that Microsoft didn't do a full operating system refactor and provide a compatibility layer for running old binaries. Perhaps they figure it would be better to just transition everything to software as a service using web tech? But I just don't see how that strategy is gonna work long-term.
They DID such a refactor for Win NT under David Cutler. Even in that comparatively simpler time it was a huge undertaking, and required all-hands-on-deck management that doesn't exist anywhere in tech anymore, let alone at today's Microsoft.
I mean technically they did with Windows on NT and again with Windows on Windows 64. Vista was also a huge redesign from the 1990s NT to a lot of the new technologies they'd made in Longhorn.
I don't know, I think it's pretty embarrassing that Teams is an electron (or whatever) app. The plot on native has been lost so badly that even the fucking company that makes the OS doesn't want to deal with it.
Electron is the worst thing that happened to quality software. I spoke to two HR guys last year at the company I'm working at and they told me they ditch every single resume mentioning "web technologies" in them. Funny part is when they also told me these "bad" resumes are for the vast majority H1B wannabees.
Second. I wouldn't say we ditch resumes on that basis, but ultimately, we're a native outfit only. You can be the best damn app developer on Earth but if all you've ever used is Electron, well, I can't use you.
NPM it's the bigger turd happened ever, slow and bloated. And JS today amounts the biggest enforced propietary loading method of existence in almost every web page.
Say what you will about Apple, they at least still think it’s important to support and do native development, especially for their OS. Microsoft might as well have bought webOS as their new Windows replacement and admitted they’ve given up on native apps.
Do original Macintosh binaries still run on the latest macOS? I haven't looked much at the situation on that side but I believe Apple has no equivalent to the Win32 API.
Clown shit. “We’re made our own OS a nightmare to build on so we’re gonna use JavaScript powered pseudo-VMs and make everything take 2 gigs of ram minimum”
I just use JUCE. It solves all the problems I need solved on Windows and doesn’t lock me into anything. More and more, if its not cross platform C++, it just doesn’t make any sense to invest in it. This is getting more relevant as the years go by, alas.
.. except for where it does make sense, for example, you have applications that you want to deliver to MacOS, Linux and Windows users. Windows is less and less relevant these days - especially when one takes the bull by the horns and deliver cross-platform apps on purpose.
Excellent summary of the stupid state of Windows native GUI app development after the complete lack of direction or coherence Microsoft has shown. Not to mention the irony of Visual Studio not having a GUI designer for anything except Windows Forms.
A lot of people complain about this, but there seemed to be a reasonable XAML designer when I was making my WinUI 3 app. I didn't really use it (my app was simple enough that hand-crafting the XAML felt worthwhile to ensure everything was nicely aligned and not full of any unnecessary designer gunk). So I suspect it does suck, since otherwise people would not complain as much. But one does exist.
Yes, as is the VCL that Delphi ships, along with the Lazarus component library which bases on Qt or GTK on Linux, and Win32 on Windows. It's the same sort of layer.
I’m still confused which frameworks are tied to which “visuals”. Ignoring the web-frameworks, do Win32 apps inherently look like Windows XP buttons or can they look more modern?
It might be nice if the article could add screenshots, a few of the Wikipedia links have a screenshot, but again I’m not sure if you’re limited to that UI or not.
I also like the carousel in the article showing the tray menus, but again not sure what they are each “built-with”.
From what I understand, Win32/MFC/WinForms inherently are stuck around Vista visuals, with no dark mode support. Win32/MFC also have no high-DPI support, so you get gross upscaling. (WinForms supposedly has some support for high DPI, but with many open issues. [1])
Now, I'm not 100% sure, since there are so many commenters in this thread saying "just use Win32/MFC like a real man". (Most of them ignoring the memory safety angle.) I might do a follow-up asking Claude to reproduce my UI in the various frameworks to test. But my strong guess is that we just have a bunch of HackerNews curmudgeons who are happy to foist pixelated Vista-era light-mode-only UIs on their users.
"Dark mode
Windows Forms has fully integrated dark mode support.
Windows Forms for .NET 9 introduced preliminary dark mode visual styling, but in an opt-in preview mode where you had to suppress Compiler Error WFO5001 to use the feature. This feature is no longer guarded behind this compiler error starting with .NET 10.
The Application.SetColorMode(SystemColorMode) API is no longer considered experimental."
I think that would be a great article! For your specific app, I can see how the "super modern" sparse UI fits nicely, since the controls are nice and simple. However, for a more involved app knowing what possibilities there are to get the Windows 10 look would be nice.
I wrote a Win32 app 20 year ago, but the limits to how it handles memory made things confusing when you loaded large amounts of data into the GUI.
I would say Java Swing is still the peak of GUI development. Works flawlessly at close to native speeds (GPU acceleration and all) on all platforms including Risc-V that did not exist when it was developed!
Because I didnt see it already mentioned. Avalonia[1] and Uno[2] for C# are also really great if you want to write windows apps. I wrote some in Avalonia that worked incredible nice on Linux and Windows.
You dont have to use MVVM or AXML for example Uno allows for C# Markup[3] to be used instead or MVUX instead of MVVM.
I personally hate MVVM and AXML but you are not forced to use them.
For Avalonia I dabbled in creating my own replacement[4] for MVVM and AXML using Flecs.Net.
In Avalonia I created a tray icon for the trash bin. So I can see how big it is and clear/open it with a small menu[5].
Both Avalonia and Uno should at least be looked at when judging which framework to use. They are both quite mature and have many great controls and features built in.
I built multiple Avalonia apps with zero previous experience
- Windows 11 Hardening utility - made it because all existing ones are not updated to handle all the new AI telemetry + new updates + I made it differently and more powerful than anything that exists currently
- Windows Admin/ Security / Networking Utility built for my needs
- Windows 11 Anti Virus Nuker - Completely shuts off windows defender without disrupting system performance or zombie files
They are both mentioned in the article. But I appreciate the extra experience and details, beyond what I got from browsing their landing pages and GitHub repos.
> One might think that an advantage of controlling C# would be that Microsoft has carefully shaped and coevolved it to be the perfect programming language for Windows APIs. This does not appear to be the case.
I think they spent all their mana for that on pre-.NET Visual Basic and then had nothing left.
When I tried to release a flutter app via exe installer, google drive said it was a virus but it otherwise installed just fine in windows 10/11. I'm doing the same thing for msix for now. But when I searched for certificates I could only find closer to $200/yr and you need to load it in the latest $100 yubikey due to the fips requirement. I didn't realize that CAs dont let you just get the private/public key files any more. Only distribution method is hardware based fips key. I've given up entirely on code signing since I only made a single open source project for amateur radio.
> knew I wanted to use the latest and greatest first-party foundation. That meant writing a WinUI 3 app, using the Windows App SDK
No it doesn't? That's "the latest", but not "the greatest", and as "a Windows guy" you should know both the meme "wait until sp1" and the principle behind that about the inverse relationship between the two factors in that phrase
> what is the point of using Microsoft’s latest and greatest, if half your code is just interop goop to get at the old APIs?
Good point! Don't, wait until they realize their newest toy isn't popular enough, throw it away and create a new one - use that instead!
> One might think that an advantage of controlling C# would be that Microsoft has carefully shaped and coevolved it to be the perfect programming language for Windows APIs
No one using anything of theirs would ever think that!
One of the challenges with the older methodologies was getting the damned things to look good. I distinctly remember with WinForms having to use DevExpress to get the theming to look moderately modern.
Bit I still never bothered with the later approaches because it looked like I was going to lose out on speed and ease of development. WinForms may have looked ugly but you could bang things together pretty quickly.
IMO WinForms didn't manage to reach even Delphi 2's state, so i'd say it is far from peak considering the improvements later Delphis (and now Lazarus) added. It was abandoned too soon.
The only modern and battle-tested UI framework on Windows is WPF. Going for .NET Fremework 4.8 in the back is smoothest to avoid users needing to install runtime (comes with Windows), but if Microsoft ever decides to include one of LTS versions (NET8 or NET10) this recommendation would change.
Nobody likes web technologies for desktop except lazy developers who know only that and try to make everything fit their world.
WinUI3 is so buggy that not even their UI controls samples app can run for more than 5 minutes without crashing.
Pinvoke is reality on Windows and it is fine. COM is garbage but that's what we've got to maintain compatibility across 30 years. Windows is held by duct-tape and chewing gum and that is just reality
Given the size of some Electron software, bundling TCL/Tk with IronTCL and TCLLib+TKLib weights 58MB and you can develop your own software with it, and that with the source of everything included.
And if you set a native theme for TTK in your code (literal two lines), your software will stop looking Motif-Industrial, the widgets will have the classic Win32 themes. It will look native from XP and up.
Looks like Tcl is still being developed, with 64 bit version released in 2024 [1]. How big is your software, is it mainly C code wrapped in Tcl for the GUI?
What kind of experience you have is about what kinda of developer you are. If you're the kinda programmer who wants to use all the newest versions of stuff because you think it'll be better, then you'll be in an endless quagmire of hitting limitations.
Most web programmers fall into that bucket for example. If you're the type to recoil at XMLHttpRequest, reaching to fetch or other even newer stuff. Then you'll balk at Win32 and be in a never ending pit of new Windows technology. I'd argue this is true of basically all new software. It's worth starting with whatever the oldest most compatible version of your target and ignoring the advertising and hype.
I use WTL with modern C++ (smart pointers, Microsoft WIL for scoped handles is a good point) for suitable Windows native apps. Yes, this seems to be old but it’s the only thing that fits my mental model as a 30 year old Windows programmer as you.
FLTK is great at being fast and light, that’s about it. It’s kind of cumbersome to use but honestly does what it says on the tin. Highly recommend for smaller use cases but can’t imagine using on a large project. I used the rust bindings which are well maintained.
Yeah for my work, legacy Win32/WinForms/WPF codebases tools are kept maintained as-is, but new tools are usually written in PySide6 (QtWidgets or QtQuick) and it's worked out really well (other than bundling/distribution being tricky for big apps)
You will need it, because since Windows Vista, most new APIs are COM based, as they redid Longhorn ideas in C++ instead of .NET, and WinRT also builds upon it.
Classical Win32 C API surface, with some exceptions, is mostly stuck in Windows XP view of the world.
Microsoft has been butchering software development for decades and maintaining dominance through pure business, legal and government connections. It's become like Oracle.
Developers being forced to use horrible Microsoft products is the logical consequence of that.
As a software engineer, most of my job exists to give credibility to the narrative that Microsoft is useful... And I don't even work for Microsoft. It's clear that there are deals behind the scenes which force many large companies into Microsoft contracts. The engineers have to work with what they get and pretend the tech is OK but behind the facade, it's clear from the jokes on the Microsoft Teams chats that they think differently!
Why do people conflate "writing GUI apps" with "native app development" and "low level access"?
If you need low level access to the operating system and the hardware, you need Win32, so you need C/C++. And there's no way around it.
Expecting .NET apis to give you low level access in Windows is akin to expecting Go apis to give you low level access in macOS or using Haskell to interact with hardware on Linux.
I’m was thinking about building native windows UI, wrapping around cross platform library written in swift. I did not know it was that messy and complicated.
Small nitpick. 4.8.1 was .NET Framework, which is a totally different beast that .NET (1 through 10). .NET Framework was heavily dependent on Windows, while .NET (1 through 10) are the newer OS independent system. It's not that they've forgotten to update the system .NET, its that that product is in long term maintenance only mode and modern .NET is a totally different software.
For anybody interested in the use-case underlying this article, mainly disabling peripheral displays in a multi-monitor setup, this is already built into Windows via the Win+P hotkey. It's also possible to turn off all displays by reassigning the functions of the computer's physical power/sleep buttons in Control Panel -> Power Options.
The more I learn about all the frameworks for Windows, the more I believe they should have just switched to web development. Make it native to the platform, fork Electron to enable Edge runtme with some shared resources, and then they'd have a more thriving app ecosystem at least.
I used to code Win32 around the Win 95/98/2000 era (my first VC++ was 1.0 for 16bit) but switched to BSD and Linux around 2000 and haven't looked back. I avoid Windows as much as possible and did learn about .NET and how slow it was but I'm a bit shocked that Win32 is still a thing and still being recommended. Sort of makes me happy and sad at the same time...
It seems that peak native Windows dev tools were Delphi 7 and VB6. It's a tragedy that something at least as good as VB6 is not still developed and supported by Microsoft.
There's nothing as good as VB6 that's developed and supported by *anyone*. It's not a Microsoft only phenomena.
I think programmers started wanting "real" languages (notice the quotes), and henceforth got more complexity and things take longer, although with GenAI, we may be back to the "draw as screen and do this" that we were with VB6. Just now the source generated should be considered the object code, and the prompt is the new source (at least for those types of apps)
I'm not sure how you define "native" here. If you mean native widgets then WinForms does what you want, is still fully supported, works on modern .NET versions, and Visual Studio still has all the GUI designers etc. WinForms is very obviously a calque of VCL, as well, so it can do everything Delphi did, but better.
If you mean native code then VB6 doesn't belong in this category (even if you compiled it to a standalone .exe it was still effectively bytecode).
>Displaying a tray icon with a few menu items: not available. Not only does the tray icon itself need P/Invoke, the concept of menus for tray icons is not standardized
Having never written Windows apps, I am surprised to learn how disorganized and chaotic this all is.
I got burned out of windows development. I was building a desktop app and switched from WPF to UWP because I wanted the new fluent design widgets, but then Microsoft deprecated it towards WINDOWS UI but it didn't have the same features than wpf.
It's always about the abstractions which try to cover the underlying mechanisms but not always can do it. The same with any programming, like named pipes for example. However I need to tell you that
1. Wow you have great knowledge of windows. Congratulations
Seems to me that really the simplest solution to authors problem is to write C++ safely. I mean...this is a trivial utility app. If you can't get that right in modern C++ you should probably just not even pretend to be a C++ programmer.
C++ is hard to get safe in complex systems with hard performance requirements.
If the system is simple and you don't give a shit about performance, it's very very easy to make C++ safe. Just use shared_ptr everywhere. Or, throw everything in a vector and don't destroy it until the end of the program. Whatever, who cares.
Meanwhile editions of Gnome come with Gnome Builder and Flatpak has solved the distribution problem. Things are so much better today on Linux than most people who have used Windows will even remember.
I wonder if Unity (the game engine) actually has a sneaky potential here. It’s cross platform, fast, and maybe just maybe less bloated than carrying around an entire browser like Electron?
Unity's 2D UI stuff is very poorly designed, with lots of edge cases where auto-calculated fields can hit a divide-by-zero issue and then become unrecoverable because the value is now NaN which can't be auto-calculated back to a number.
Not sure about Unity, bot Godot is already used to build tools, like Pixelorama (pixel art graphics editor, a bit akin to Asesprite), RPG In A Box (game engine targeted for RPG games), Bitmapflow (tool to generate in-between animation frames), and probably more I don't know about.
Well, if I remember correctly, the Godot editor is written in Godot.
Speaking from personal experience, Godot has the sneakiest potential. It has all the UI components and flexible layout containers you could ask for, a signaling system that lets you put the methods from less relevant components in the scripts for more relevant ones (making for a more compact project), and you can also manually compile slim template builds for cleaner distribution. There's a future there.
If Unity were to ship platform native replacement for WPF equivalent (hell or even winforms) it would become a really enticing app development platform.
Aren't these pretty much the most trivial UI apps possible? E.g. compared to other native apps like Photoshop, Blender, Visual Studio or Office, CRUD is mostly just about banging together custom UI frontend for a database.
Unity's editor is implemented in its own (old) UI system, same with Godot, so in both engines it's possible to create 'traditional' non-game UI applications.
Thanfully, you don't need to write p/invoke stuff yourself anymore. https://github.com/microsoft/cswin32 creates methods and all related structs for you. It's also AOT compatible (if you specify it). It works for calling C and COM functions.
I mean, not like this brings Windows development anywhere close to "modern", if anything, it feels like you're moving into the opposite direction, but at least this solves the "The modern APIs don't provide the specific functionality I need" problem that plagues all of Microsoft's "nice", "modern" abstractions…
Honestly, if app complexity and size justifies few more MBs of bloat, Python + Pyside is the best option to make UIs, be it Win-only or cross-platform. You get the power of Qt with stuff like hardware-accelerated QGraphicScene exposed via nice, concise, high-level language that also gives you access to some best-in-class libraries. Performance hit is negligible if you know what you are doing (what may not be the case in 2026 and age of vibe-coding).
Unless, of course, you tend to whine about "complex licensing", i.e. people wanting to make money as you do.
Unpopular opinion: FreePascal is perfectly capable of all that and produces tiny native executables. Their clone of Delphi's Visual Component Library - Free Component Library - is rich in features and don't change every year like those Microsoft toolkits.
I needed recently to make an exe that would work on anything from 32-bit Windows 95 up to and including Windows 11 (to accommodate some old machines on production lines), and the only language that made that easily achievable was FreePascal. I think it can also handle the older Windows NT if that is a requirement. There are lots of architectures supported with a single code base.
But for many the Pascal language is just to be laughed upon. Well, I make fast money using it and laugh from JavaScript.
Just scroll down the page and look at the size of the completely self-contained executable programs. THIS is what Win32 is capable of. Something we always had with Win32 that was thrown away with .Net and C#.
And _please_ just spare me your opinions of how Steve Gibson "doesn't know anything about security". That's not what's important here. What's important is how freakin' small his full-on GUI stand-alone executables are.
EDIT: Just noticed this on his page.
Total Historical Count of files downloaded from this page: 52,292,601
With Delphi creating of Native Windows Desktop Applications is a piece of cake (also does MacOS, iOS, Android and partially Linux). Yes it is by now obscure and expensive tool but I still use it to maintain my existing native GUI desktop applications. It is incredibly easy to use / develop with and single exe no dependencies deployment mode is superior. Compatibility
between Windows versions is stellar as well.
There is also an opensource version of Delphi called Lazarus which is way less polished.
I originally had ATL in there, but my proofreading squad (Claude and ChatGPT) told me that ATL was a more niche thing for COM, and looking at the Wikipedia article I was convinced they were right.
But WTL was what I was thinking of---the step between the MFC and .NET that I forgot.
WTL was never a "step between the MFC and .NET" in any meaningful sense. It was more like a very lightweight subset of MFC+ATL, never officially supported or recommended, just something that Microsoft used internally that it decided to publish and then community picked up.
I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid.
Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that:
Enumerating the machine’s displays and their bounds
A few API calls. Probably a few hundred bytes.
Placing borderless, titlebar-less, non-activating black windows
Creating non-functional windows is trivial. Another few hundred bytes at most.
Intercepting a global keyboard shortcut
A few dozen bytes to call SetWindowsHookEx.
Optionally running at startup
Write to the appropriate registry key. A few hundred bytes.
Storing some persistent settings
Ditto. Another few hundred bytes. You can use a .ini file too, for around the same size.
Displaying a tray icon with a few menu items
Most of this size of this will be the icon itself - a few kilobytes; the next biggest contributor will be text strings; and the rest is accomplished with a few hundred bytes of API calls.
Add another few hundred bytes of (not much) logic, round up to a kilobyte and add maybe another for general overhead.
But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Using Win32 to write a UI in Windows is like pulling teeth. There are bindings for Rust but even still it's a nightmare.
MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell.
I think it's fair to say that the entire story for native app development is a mess - which is most likely why Electron became so popular. There just isn't a practical sane alternative.
The sane alternative is macOS because there is one thing that Windows lacks; a community. Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.
When I look at the apps on Windows, all I see are abandoned projects and MVPs with a borderline malware financial structure.
> Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.
Microsoft has had even more people working on Windows software..
"Developers, Developers, Developers!" - Steve Balmer
Microsoft has always had vastly more developers and development of software for Windows.
Apple still after all these years has a tiny market share of overall platforms, software, all of it really.
Not sure how you can suggest Apple is somehow the bastion of software development. If you write mac software, you'll be targeting a platform with 15-20% market share at best.
Isn't software development about making money? On phones, if you want to make money you have to target iOS, since this is where you have the people with money to spend on software. Do you believe that the vastly larger installed base of Windows guarantees more money for everyone?
At a previous workplace, we released certain software targeted at media/videography professionals for macOS first. The immediate response at conferences was, 'do you have a Windows version? We all use Windows.' Once we ported our software to Windows, the uptake was easily 1.5 orders of magnitude greater than for macOS.
The era of 'macOS is a better media computer' is long gone.
>On phones, if you want to make money you have to target iOS
It's funny that you think Android users are broke-ass nobodies. That's some reality-distortion-field fanboi nonsense. And it's also hilarious that you think phone apps are useful software that costs lots of money.
Most people in tech with high-paying jobs that I know are using Android, because it's actually pretty awesome compared to the locked-down walled-garden that is Apple. More than half my friends use Android or Windows. They use Android because it isn't as locked-down as iPhone. They use Windows because it runs all the software they want it to run. We also really don't care about Apple's blue bubbles.
No, Apple users are not the only ones with jobs. Plenty of Android users have plenty of disposable income. It's a ridiculous argument to make that Apple users have more money to spend.
>Do you believe that the vastly larger installed base of Windows guarantees more money for everyone?
I don't have to believe it, the market believes it. People vote with their dollars, and they aren't voting for Apple all that often worldwide. Plenty of wealthy people use Android and Windows. I'd wager that most big companies are still run on Windows - and I know this experientially, from back in the day setting up computers for major corps, it was 85% Windows, 15% Apple. Always was, always will be.
Way to go with anecdata to try and disentangle your feelings from reality. Come back when you have cold hard facts. With 27% of the market, they make twice as much money on their app store.
https://appleinsider.com/articles/24/06/05/app-store-just-ha...
Making money does not equate to popularity. It only means their users are suckers for overpaying. $1000 for a monitor stand? $700 for 4 tiny wheels? Yet people pay these absurd prices for their niche over-hyped and over-priced hardware. "A fool and their money are soon parted."
Then how do you square that Apple has a billion worldwide users? They're all fools? Everybody who bought an iPhone is an idiot? There's no way an 900$ iPhone is a good purchase when the equivalent device that Samsung advertises as a competitor is over a thousand bucks?
You lost my interest when you suggested that iPhone was the platform to target because those users have all the money to spend. This pointless internet interaction is over.
Really?
I've been a fulltime Linux user for years but there are tons of excellent Windows-only apps.
Here are some that I miss: Directory Opus, ShareX, Wiztree, Everything, AltDrag, AutoHotkey, Paint.NET, irfanview, SumatraPDF. I'd add Keepass2 as well but fortunately KeepassXC is a thing.
Those are all feature-filled (in the bloat-free good way) and they've all been around for over a decade (from memory). Most are free and open source to boot.
If you like Paint.NET, you may like Pinta on Linux.
Also, I am pretty sure that SumatraPDF is available for Linux as well. I am not at a computer but I think it is in the AUR.
To be fair, these exist on Windows as well. There's some cool stuff, MyLifeOrganized for example I would consider to be on par with OmniFocus.
But I agree that most of the boutique stuff on Windows gets drowned in all the enterprise software a bit.
MyLifeOrganized was the biggest thing I gave up when I switched to Mac in 2013. Still miss it -- nothing else (Omnifocus, Things, outliners, etc) has been as effective as a system for me. They've been talking about a potential Mac app for year, I'm on the waiting list, but I've given up hope that it'll ever come. Even if it does, I doubt it'll be as good as it is on Windows.
Linux as such has no UI - which framework specifically were you thinking of?
Qt or GTK
It’s certainly doable, but not as nice and easy as Delphi or Qt, which are WYSIWYG.
Of course, if one is a web developer, even attempting such a feat this could result in a brain-melting experience.
What about Qt? I am asking - I really don't know.
Win32 is easy: https://news.ycombinator.com/item?id=21459616
MacOS is not quite so simple: https://news.ycombinator.com/item?id=40085237
Comparing oranges to apples. Win32/Win API is (one of) the native API to do Windows programming.
Pure C is not the native way to do application programming on macOS. As I mentioned elsewhere, you can bring up a window with a button with no code on macOS. You can make that button show a string on a label with a handful lines of code.
Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it is to be considered in certain situations.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are still some reasons to do so, of course, but Win32 isn't one of them -- one can use it from a memory safe language just fine, e.g. https://github.com/microsoft/windows-rs
A good rule of thumb for programming languages is to check what the general recommendation is on HN and do the opposite.
Using win32 from Rust is nonsensical. This is the kind of use-one-tool-for-any-job Visual Basic 6 programmers used to have, except VB6 would have actually been much better than Rust at Windows programming.
I just had a look at two examples from that windows-rs repo.
https://crates.io/crates/windows-sys
https://crates.io/crates/windows
Both seem to do the actual work in unsafe blocks, so I guess you could as well use C++, no? (only have limited Rust knowledge)
Unsafe blocks are common when interfacing with C or C++ code.
The first thing you want to ensure is that you avoid unsafe in YOUR code. That is, after all, where you are going to create your bugs.
Ideally, there is no unsafe code in the crates you use. If there is, at least there are more eyes on that code to catch problems. You can inspect and debug that code, and others can do it for you. Others may battle test it and stress it far more than you will.
And at least the unsafe code is isolated to a few areas in the supporting libraries. Less to inspect. Less to debug. Fewer places to introduce memory related regressions.
It does not at all follow that, given an unsafe block, we may just have well used C++.
> so I guess you could as well use C++
The unsafe code is written inside the library, which the user can contain in a safe API. With C++, the entire codebase is unsafe.
It's straightforward to contain the unsafe usage and potentially write safe wrappers and structures around it. Memory bugs mostly stem from the larger application in conjunction with the API anyway, rarely only the API layer.
> Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project.
Yes, you may be harmed by proper IDE and debugging experience via Visual Studio.
I was gonna say he addressed Microsoft's rust library, but apparently that was something different?
https://github.com/microsoft/windows-app-rs#this-repository-...
I'd say it's confusing but I wouldn't expect any different from Microsoft.
IDK man, I wonder how TF did the creators of Winamp do it? Were they so much smarter than the programers of today? And Winamp 2.95 still works on WIndows 11 today.
IIRC Borland Delphi was the most popular tool back then for making Win32 apps since it was so easy to use.
> Were they so much smarter than the programers of today?
Unironically the answer is yes. I've been watching this for at least 15 years.
I think one inflection point is when everybody who was coming up became accustomed to GC languages. Within a decade of that trend starting, nobody could reason about memory anymore.
With the AI boom we're going through another inflection point. When coding is synonymous with using an LLM, nobody will be aware of how anything works (or doesn't)
Also a lot of people got into the industry because they saw the salaries of programmers, but have no real passion for computers or software. They did the studying enough to pass the tests and write an algorithm to pass the interview and land a job. But they don't have the drive to make things better, think outside the box, or write something they can be proud of.
AI has accelerated this because it's becoming harder to detect the frauds.
> became accustomed to GC languages
There is a certain amount of truth to that I think
I do not think anybody was “smarter”. There were smart and less smart people then and now.
But the “typical” practice changes. And that changes what you get. I think your “typical” programmer is more productive today in terms of what they can accomplish. But that work is going to be built at a higher level of abstraction and likely a lower level of run-time efficiency. As a percentage, fewer people understand or take into account the lower level details.
It is not just about new tech. After all, I can write all my code in RISC-V assembler. And I can manually allocate memory and manipulate pointers in C#. It is just not what people normally do these days.
The web and web apps as pushed by Google and others was another nail in the coffin of efficient software.
From Android to whatever web framework they’re peddling as development solutions, these are not designed for efficiency, but for time-to-market and consumption by front-end developers.
Were they so much smarter than the programers of today?
The average programmer back then was probably far more knowledgeable of the low-level details.
I worked on Windows programs similar to WinAmp, which had custom drawing, skins with custom shapes, etc. Usually written directly in WinAPI, VCL (C++ Builder, not Delphi) or a combination.
It was a matter of having access to the right (although limited) resources such as Petzold’s book, Codeproject and experimentation. There was no big rush, no start-up hustler mentality and most importantly hardware resources mattered a lot and it was a point of pride to create efficient software.
The development culture of present time is the opposite of that: developers are drowning in documentation, the default solution is technically inferior and the hustler mentality’s dominating.
https://github.com/alexfreud/winamp : does indeed look like classic Win32 in the files I randomly tried, although there's also a QT DLL and a whole load of other stuff on there.
Software seems to have quality and capability as diametrically opposed attributes.
Yes, of course they were smarter.
If you don't want to spend quite so much time byte shaving, and you don't want to deal with memory safety or _UNICODE, you can do it in .Net Framework in half the time.
How do you make your win32 app look good to the average person?
Depends what you mean by "look good".
The main function of the app being discussed here is to draw solid black rectangles on the screen.
Don't forget the "average person", I'm assuming someone relying on software as a tool, doesn't care about the stuff "designers" seem to obsess over, and will actively hate if you break their workflow by doing things like adding useless padding that makes them scroll more or shows less information in the name of "modernity". There's a lot of specialized niche software for various industries, often very expensive too, which looks like it came out in the early 90s. As long as it works well, users won't complain.
Oh, how I hate when vendors bring "modern web" aesthetics to desktop utility programs. For example, Docker Desktop could go a long way in terms of usability if it just sticked to Win32 common controls - the kind of buttons, labels and list views that have been around since Windows 95. Maybe I wouldn't even have to wait 10 seconds for the main window to show up every time.
I used to work in finance. Screens very densely packed with text is the preferred user interface.
We did a UI refresh at one point. It looked much nicer. People hated it. We had to hastily redesign it again and it looked far more like the original.
There's a pretty simple settings window: https://github.com/domenic/display-blackout?tab=readme-ov-fi...
Would that UI be hard to accomplish?
You mean conceptually or to match it? Native components are pretty much impossible to match without actually using the native framework which provides them, so you need WinUI/WPF.
Win32 provides its own components which are basically Win95 style apps, and you can draw the components using some graphics APIs by yourself.
The whole native development area is a mess exactly because making your own (decent) renderer is a huge undertaking.
Agreed. The Qt framework, which is a cross-platform UI framework, does a decent job mimicking the native Win32 looks. Inside, the code is a giant mess. But on the outside, the API is very well thought out and easy to use.
But you are making false equivalence, the Win32 GUI API is decades out of date from modern UIs. I can use flutter and make a pixel perfect equivalent of the above UI in an hour, with the exact same responsiveness behavior on both windows tablets and desktop, and scales perfectly in high DPI displays. 3 hours if you want the toggle animation timing to be exactly the same.
I came from the WinForms world so don't pretend I don't understand Win32 programming. The fault lies with Microsoft for not investing in it more.
You talk like that is a bad thing. Win32 UI works, is fast, works everywhere even on ancient 640x480 server screens, safe mode and vnc in 16 colors without opengl, directx, Angle or vulkan.
Flutter is nicer to scale and maybe design but it is a massive overhead. Skia still has trouble with some drivers and causes lag or falls back to software rasterization. Hot replacement while coding is pretty neat though. It runs much better on mobile devices imho.
It works, and fast, but it is not portable. I would argue something like Qt is much more viable in $current_year for cross-platform development. Or if you're really dead-set on actual native components, then I guess wxWidgets works too.
I'd rather tell Linux and Mac users to use WINE.
WinForms is Win32. There is just a managed API wrapper around it.
The functionality of that is not hard at all. A few checkboxes, a trackbar, and a hotkey control (there is actually a standard Win32 control for this: https://learn.microsoft.com/en-us/windows/win32/controls/hot... ), with "pushlike" checkboxes at the top to be drawn replicating the monitor layout.
But that "modern" style is... disgusting and repulsive. That whole dialog is bigger than one of my monitors due to how much wasted space it has.
My favourite example of "Modern" style is the toggle switch, shown even in that image. I laugh a lot of the times I see one, it's the 'replacement' for the checkbox, but it's so awful at actually telegraphing it's current state in a consistent way- (the entire purpose of the control!) that it has to have a label indicating whether it's on or off. I find it so absurd that people genuinely put this stuff into their programs and have no problem with it, because apparently we are just supposed to accept this type of poorly designed component because it's more "Modern".
But think of the poor users expecting consistency with their phones where confusion is expected!
If your application saves me time (is intuitive) or enables me to do tasks that I couldn't do before (is powerful) then I don't care one whit what it looks like. As long as it doesn't actively hurt my eyes to stare at you can do whatever you want.
Sure, if I'm building something for myself or fellow hobbyists this approach works (though in that case I'd prefer a good TUI/CLI). But if you're building an app for the average person, how it looks has a big effect on whether they choose it over an alternative.
It's funny, the "modern" look has become a countersignal for me. If the app looks like a webpage, I instinctively don't want it. Not because of aesthetics, but simply because I've come to associate that style of appearance with a lack of (or awkward) keyboard shortcuts, featuresets dumbed down to a level appropriate for chimps, various nags injecting friction against getting work done (ads, feature tours, logins, update reminders, etc) and laggy, resource-squandering performance thanks to some kind of bloated rendering framework like Electron with multiple V8 hosting processes sprawled across chrome.exe instances or whatever.
Case in point, the Dropbox Simplified Desktop App was a huge improvement for me. It nails just about everything I ever needed their app to do, and removes all the user-hostile fluff I never asked for. Similarly, I found Windows 11 Enterprise IoT LTSC to offer an improved desktop experience compared to traditional Windows, thanks to its exclusion of a lot of the cruft Microsoft otherwise shoves down the throats of users who, as far as I can tell from frank discussions with many of them, likewise actively don't want.
I'm not saying your desire to make your app look polished means it's crap, but beauty is in the eye of the beholder. Just like fashion, I wouldn't be surprised if we see a shift in the aesthetics trend as more people discover a retro feel sometimes signals a better user experience.
Programmers and designers thinking the average person is a moron is one of the two reasons almost no good software is writren today.
What's the other reason?
That most programmers are not that great at programming, and wouldn't be able to produce high quality software even if that was their stated goal.
They really don't. Though if Microsoft wanted to, they could solve that too. For example, the OS control panel used to be extendable. Technically still is, just not the new one (and of course both remain). Then you could have this UI or something very similar to it right in there.
Several integration points like this have been removed, supposedly because third party software was just too bad in how they used them, causing issues. Or at least so goes Microsoft's perspective. Personally, I find that very believable! If by integration points the only thing one can imagine is calling into random third party code on the regular that the user has installed, bang spank in the middle of critical user flows, on the same thread and in the same process as itself, that's exactly the kind of grief I'd expect to occur...
If only there was a way to provide a way to craft e.g. custom flyout menus for the taskbar or custom pages in the Settings app, without invoking arbitrary third party code and possibly causing crashes and hangs in system apps and menus... or just not letting crashes and hangs affect the application (e.g. Windows Explorer) calling them in the first place.
Disable borders and design your app nicely with images to replace standard user input elements.
That sounds like a great way to make a mess. Look at Microsoft's own apps shunning proper File dialogs and instead presenting a giant, bizarre pane of mostly text and a few crudely-drawn boxes in order to save a file. You have no idea what you're looking at or where you are in the file system.
Then there's the removal of title bars from Windows. You often have no idea what app you're looking at. Pull up a PDF in Acrobat and also in Edge. Now, at a glance, which is which?
Regressive garbage.
A couple of weeks ago, I decided to write a GUI utility to propagate my new PuTTY default settings to existing sessions. I took the Go Walk package, which is Win32, and was done in several hours, most of those spent hunting down an obscure layout bug. So long with memory-unsafe languages.
Here's the source code for those who are interested: https://github.com/sergeax/stamputty
I made an app using Win32 in Golang. It controls my monitors' brightness and "true-tones" them to match the sun cycle via DDC/CI. It has autostart, global hotkeys, persistent settings, sits in the tray, silent auto updates etc.
The hard parts were seeded by Claude Code. Happily maintaining and modifying it for close to 3 months now. Just a data point, especially about not needing C++.
There were decent and reasonably thin layers over that to solve the immediate practical issues (e.g. Delphi, MFC), but they're no longer fashionable and nothing seems to have replaced them in the same space. Maybe we need a "NoFramework" phase to get back to RAD again?
>> But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.*
Eh. I spent many years writing cloud/backend software on the JVM, in between stints writing desktop software. When I was first writing desktop software, it was all in C and C++, and I got used to it, but it wasn't pleasant.
When I came back to writing desktop software in C again (just a few years ago), after writing in memory-safe languages for so long (Java, Scala, Rust, Go), I found going back to C to be just so tedious and annoying. It's just incredibly unpleasant to be chasing down segfaults and data races and crap.
So I think saying it's a "crime" is hyperbole, but even for apps that don't have untrusted input, it's still much more pleasant writing in a language that doesn't let you write memory safety bugs.
(Absolutely agree with you on how it's possible to make nice, small, non-trivial Win32 apps, though I haven't done Windows app development in a couple decades. But I think a lot of people would save themselves a lot of time and headaches if they reached for .NET or something higher level.)
This is the way. Everything is fine if you are a responsible dev that writes secure code. You can very clearly see the pattern of shitty framework after shitty framework coming and going. Why bother when the C++ code will outlive whatever shitty framework is coming next?
I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I find it a breeze to write native gui programs in pure win32 and c++.
Recently had to add a new feature to and old program that was last updated in the XP era and two things to note:
1. The program did not need to be updated to run on Vista, 7, 10 and 11, shit just kept working throughout the years.
2. I loaded the project into Visual Studio 2022, it converted from VC6 and compiled without problems, added the feature, shipped a new .exe to the customer, and it just worked.
What other platform has that backwards and forwards compatibility success story?
I feel like I'm the only person in the world who would rather write ugly win32 jank for the rest of my days than ever having to touch an "elegant" or "well structured" Cocoa codebase. In win32 if you want a button you call a function and pass a hande, in the Apple world you first subclass 7 interfaces in some unreadable Smalltalk-wannabe syntax and pray you don't need to access the documentation. And of course they constantly change things because breaking backwards compatibility is Apple's kink.
After bouncing around GUI toolkits (from win32 to SwiftUI) and web for 30 years I have simply run out of fucks. They all suck. Each in their own unique way. Apple aren't worth singling out - they are just their own special isolated variant of it.
Tcl/Tk is pretty good in terms of rapid development. Unfortunately it has stagnated quite a lot over the years.
Gtk on the other hand is absolutely terrible and its developers don't help by completely rewriting things every few years and breaking all existing code in the process.
Tcl/Tk was also popular in certain niche products, like in RF test equipment.
It's still quite big in EDA (electronic design software).
But, why? It's been 30 years. You'd think somebody would have figured out how to make a decent GUI toolkit or framework.
Have you tried WinForms? It isn’t the latest hotness so Microsoft has to be dragged kicking and screaming to support it in current VS, but they were forced to do so because corporate developers still have some clout.
I recall there used to be a problem if you edited a (win)form in Visual Studio on a computer that didn't have the DPI set to 100% - did they fix that?
The work around was 'simply' to switch to 100% DPI scaling before opening Visual Studio. On my macBook Pro built-in monitor, this was not cool.
I still think that WPF was the peak desktop UI framework. Extremely powerful with lots of small composable primitives, can easily do declarative but drop into more traditional event-driven imperative style where it makes sense.
I live in a bizarro universe where I started my career working on an expansive WPF desktop app on .NET Framework 4.0, and am still working on it now on .NET 10. From my perspective it's been WPF the entire time, and it's been pretty okay.
Similarly, I've been doing It development for pretty much the entirety of my career. When I see the struggles to make remotely useable apps in other frameworks I'm very happy I chose this path
That's actually pretty close to my own career as well.
They generally get the design right after some mistakes and are stabilizing it, when the new UI designers take over and want to re-do it from scratch.
I have no complaints using Qt for cross-platform development, it has been paying my bills for the last 15+ years.
AvaloniaUI + MVVM toolkit.
We just built layers of shit over the ones we have.
This is patently false. To add a button to your UI, you open your window’s nib file Xcode/Interface Builder, click the plus button on the toolbar, and add a button. Then you control-drag from the button to File’s Owner and choose the method that you want to invoke when the button is clicked. Done.
And this already worked in OPENSTEP, like 30 years ago.
Programming with GUIs?
Yes, generations of Mac and Windows programmers have used GUIs to create their GUIs. Visual Basic, MFC + App Studio, .NET + WinForms, Interface Builder…
Given that the initial comment was complaining about a status quo, citing a status quo is an odd defense.
Why wouldn't you program a GUI with a GUI if one is available? Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.
> Why wouldn't you program a GUI with a GUI if one is available? Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.
I've been a developer for a long time; I've built pretty large applications in all sorts of technologies and I now just prefer defining GUIs using text. Having a live GUI preview is great but actually dragging and dropping stuff is not more efficient to me.
To fit your analogy, using source code is like writing a song using musical notation. I'll write the song, then play it, and then go back to notation to fix it or expand on it.
In my experience drag-and-drop GUI editors work great until you add the constraint that the window has to be resizeable. Then it becomes a mess of clicking through dialogs for every UI element to make sure the anchoring and display flow is set up correctly, and you often have to go back and redo this whenever you add a new element or change the layout of the form. I think the best GUI programming experience I've ever had is on Palm OS simply because it had the constraint that every program always displayed in fullscreen at 160x160 (pixel-doubled to 320x320 on later devices) so you never had to deal with resizeable windows.
I'm not saying you should never program with a GUI, but it comes at a cost of being able to read the code and tell what the result of the code will be, and all the associated benefits of version control and code reviews that you lose.
And as a side-effect of that, merge conflicts become murder when your "Fix right-hand margins" commit with a 20 line readable +/- diff instead becomes a 1000 line +/- diff.
The one time I built an iOS app using the xCode IB so that I could get up to speed more quickly, I really came to regret it several years into the project.
If this is a real issue, it seems to be an issue with the way a particular toolkit handles visual WYSIWYG editors. Lazarus serializes the object properties into a simple and readable text format that follows the class declarations themselves and you can easily diff them. E.g. here is the diff of a minor change i did (added a new button in a panel with an event handler and modified a property in an existing button):
https://i.imgur.com/aHMHqSc.png
Handling merges (and other VCS functions) is also simple since you can edit the file manually if needed.
I swear I meant to write an "often" in my previous post. But yeah, that was largely directed at the interface builder in xCode, for iOS - it gives you storyboard/xib files that are effectively-not-human-editable (and entirely non-mergeable) xml.
Visual Studio and XCode are way, way overkill for most software and eventually constraining for bigger projects too.
I would say having a good hot reload system gives you the benefit of wysiwyg with more readable code
> Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.
And yet, most songwriters write the song, they don't record themselves playing notes.
I encourage you to listen to the Song Exploder podcast to learn about how songwriters write songs.
That feels like quite the exaggeration. If all you want is a button, all you need to do is initialize an NSButton and then tweak a few properties to customize it as desired.
If you want something more custom, subclass NSControl and you’re off to the races.
And if Obj-C isn’t your cup of tea, one can use Swift instead, even in a codebase that had been only Obj-C prior.
You can now use SwiftUI, which is, as of the latest version, quite stable. They used to change things a lot between releases a few years ago, but nowadays you don't need to refactor your code every year. Only issue with it is that it's iOS first, so you may need to fallback to AppKit (Cocoa) to implement more complex elements.
> as of the latest version, quite stable
Until the next latest version?
Sorry, but this is simply just misinformation.
If you were doing "classic" Cocoa in the way it was intended, you wouldn't need to subclass anything for a simple button.
You wouldn't even need to write a single line of code, you'd just instantiate said button in Interface Builder, hook it up to a delegate (e.g. a window controller) and off you go. You can create a hello world example with a handful lines of code.
And even if you'd rather create the button programmatically, it's not much more involved.
Sure, if you're coming from Win32 and expect to program Cocoa without learning Cocoa, you're out of luck. But I guess that applies to all frameworks.
How to add a button in SwiftUI:
I'm probably another, but I have never done any professional Win32 work. You know, those kind of jobs are rare now and I doubt they want anyone without experience.
What are you talking about? In Cocoa if you want a button you drag one in via Interface Builder. You don't even need to write any code. If you want it to do something, you type the name of the function it should call.
This is total misinformation.
This is such a wonderfully beneficial comment to the HN community. It should get an award.
To me this kind of "no need to change anything" implies stability but there's a younger cohort of developers who are used to everything changing every week and who think that something that is older than week is "unmaintained" and thus buggy and broken.
One of the earliest security issues that I remember hitting Windows was that if you had a server running IIS, anyone could easily put a properly encoded string in the browser and run any command by causing IIS to shell out to cmd.
https://learn.microsoft.com/en-us/security-updates/securityb...
I mentioned in another reply the 12 different ways that you had to define a string depending on which API you had to call.
Can you imagine all of the vulnerabilities in Windows caused by the layers and layers of sediment built up over 30 years?
It would be as if the modern ARM Macs had emulators for 68K, PPC, 32-bit x86 apps and 64K x86 apps (which they do) and had 64 bit Carbon libraries (just to keep Adobe happy)
Better to have known unknowns, than unknown unknowns.
Except the former doesn't eliminate the latter
I think its at least as much of a working environment preference.
Once I became experienced enough to have opinions about things like my editor and terminal emulator... suddenly the Visual Studio environment wasn't nearly as appealing. The Unix philosophy of things being just text than you can just edit in the editor you're already using made much more sense to me than digging through nested submenus to change configuration.
I certainly respect the unmatched Win32 backwards/forwards compatibility story. But as a developer in my younger years, particularly pre-WSL, I could get more modern tools that were less coupled to my OS or language choice, more money, and company culture that was more relevant to my in my 20s jumping into Ruby/Rails development than the Windows development ecosystem despite the things it does really well.
Or to say differently: it wasn't the stability of the API that made Windows development seem boring. It was the kind of companies that did it, the rest of the surrounding ecosystem of tools they did it with, and the way they paid for doing it. (But even when I was actually writing code full time some corners of the JS ecosystem seemed to lean too hard into the wild west mentality. Still do, I suspect, just now its Typescript in support of AI).
Repeat after me: New! Fresh! Clean!
The one big challenge I've had with big legacy Win32/C++ codebases is migrating it fully from 32bit to 64bit. Loads of know-how and docs for complex GUI controls and structs are lost to time, or really fragmented. Other than that, yeah it really does all just work once you're past that.
Well it's still a 32 bit program so I guess that helps. Would probably require some porting to make it 64 bit native, but as long as you use the WPARAM, INT_PTR typed and what not correctly it 'should just work'.
Yeah that's the bulk of the work for migrating small Win32 apps. Things escalate when someone has built their own dynamic GUI framework over Win32, used a range of GUI controls, and then built event-driven apps on top of that, it's a lot lol
I went through that a few years ago and it actually went pretty smoothly. There were a few UINT_PTR or DWORD_PTR changes I had to get used to and a couple of string glitches (we mostly used the _T() macro for strings and already used the _t variants of string functions in the original code, so that helped).
The biggest problems were DAO (database) and a few COM controls that were not available in x64.
Having to use macros for literal strings in your code is just incredibly stupid of Microsoft and/or C++.
How do Linux and Java do it, when you want to compile your program in both 16-bit char and 8-bit char mode? Oh that's right, you don't.
You can pick one or the otherfor Windows too, so don't ask me why it's done that way. It was originally so you could compile for both the new hotness Unicode, and the old compatible ASCII.
Partly because Microsoft resisted UTF-8 forever, and so using the ANSI/multibyte strings didn't therefore give you modern functionality. Why they didn't implement Unicode for Win95, I'm just not sure. If they had, the only reason to compile an ANSI version would have been to target Win32S (Windows 3.11).
Or, they could have implemented a UTF-8 code page for Win32 as soon as it was available and then most software could just use byte strings.
In 32-bit windows, you used to be able to see if a pointer was valid or not by seeing if it pointed to the last 2GB of address space. If it did, it was pointing to Kernel memory that was not valid for user mode code.
But then Large Address Aware (4GB limit) changes everything, and you can't do that anymore. In order for a program to be Large Address Aware, you need to not try to do things like check high bits of pointers, then every single library and DLL you use also needs to do the same.
That sounds like the same ugly hack that caused programs not to be “32 bit clean” back in the day for Macs
One difference is that the Mac OS itself was not initially 32-bit clean, with the top byte being used by the Memory Manager.
Ah yes, these 68000 pointers have a spare 8 bits for me to use! Because nothing will ever need more than 16 MB of memory. Sigh.
It's all good if you have 128kb ram but they should have had a plan to escape it from day one.
This is how pointer authentication codes work on Arm64.
Doesn't WINE have pretty decent documentation by now from all the reverse engineering?
Wine cannot even install office 2014. It's not really as food as some claim sadly.
Lutris can up to 2016.
Win32 programming has been reduced to a small niche now. Even 20+ year old Win32 books don't cover things in-depth (or practical use cases) let alone the 32bit->64bit migration
Yeah that doesn't always work that well. Think you were lucky.
Add high DPI to the mix and things get rough very quickly. Also the common control have weird input issues (try ctrl+backspace in an Edit control). All those little things need to be fixed carefully for something to be ok in 2026.
Winforms?
lol at them still bekng the best option. so much wasted effort trying to replace them
Winforms is great until you try to make windows dynamically sized, or deal with DPI nicely. In every other regard it's still fine, and for accessibility actually _better_ than many subsequent frameworks. And produces nice small fast executables.
I assume that if Microsoft hadn't abandoned WinForms for the next thing, it would support dynamic sizing and DPI properly. It's mindboggling how much time and effort they've wasted coming up with new GUI frameworks instead of just improving on what they have.
It does, but many still think it is like using VB 6 and don't learn the additional APIs that provide that support, e.g. FlowLayoutPanel and TableLayoutPanel.
And for HiDPI, https://learn.microsoft.com/en-us/dotnet/desktop/winforms/hi...
I remember a marvelous quote from a guy that was at some MS conference and got handed a leaflet that said:
> WinForm or WPF, how to choose
and they were like: "the question I have isn't how to choose, but _why_ I have to choose".
I don't think it's abandoned and it looks like there is a lot of activity around the high DPI concern.
https://github.com/dotnet/winforms/issues?q=is%3Aissue%20sta...
Or, unless they've changed it, hardware accelerated rendering. Winforms was based on System.Drawing, which used GDI+, which was largely software rendering. This was confusing because GDI+ was not really related to GDI, which had and still does retain some hardware acceleration support. Even basic color fills start becoming an issue with a big window/monitor.
Winforms is also .NET based, so it's inaccessible if you don't want to write your UI in and take a dependency on .NET.
DevExpress has many advanced Winforms controls that are all GPU accelerated and super fast. So Winforms can certainly do GPU acceleration.
Windows dynamically sized is quite easy, people have had enough time to learn how to use layout managers in Windows Forms.
Naturally it is a bit more than just drag and drop controls from the toolbox.
HiDPI is supported in modern .NET, with additionally APIs, that aren't enabled by default only due to backwards compatibility.
transparency as well. WinForm really struggles with the idea of stacking elements on top of one another where there is an arbitrary amount of transparency or tricky shapes. Its just not worth the hassle compared to WPF.
It's been a while since I've touched it, but IIRC they made WinForms play with Hi-DPI nicely.
And the 12 different ways to define a string depending on which API you call
‘Madness is something rare in individuals — but in groups, parties, peoples, and ages, it is the rule’ —F. Nietzsche
(tongue in cheek)
I've not done MFC Win32 programming since 1999 but if I recall those programs don't execute the main() function. They instantiate the Win32 class for your app or something like that. I can't remember any details anymore.
You still have a main function in Win32, it's just called WinMain and has a slightly different signature.
MFC has CWinApp, which you'd normally subclass, and a stock WinMain implementation that instantiates that, but it's not strictly necessary to subclass it, just convenient.
They don't use main because they use WinMain, which is the entry point for Windows apps that don't run in a console window.
WinMain should create an instance of the app class and call Run.
"You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 which feels pretty unfair
> "You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 which feels pretty unfair
I get that if I post more than six replies in an hour.
I've always been able to post several replies in an hour before.
But that’s the point the article’s making. At the C level you’ve got a fully functional system. Above that level (even at the C++ level), feature support is a mess.
Same here - our IOT device is a i5 running Windows IOT. Recently I switched from C++/Win32 to Golang and walk.
How does it look? I mean, what do the widgets look like?
This was an MFC project, so your old standard win32 common controls that looks the same since 98 or so.
and it would work on linux with wine lol.
Honestly, your GUIs are too simple to be part of this conversation. Try writing something like Spotify in WinAPI and that's not even a complicated GUI either.
Spotify would be remarkably improved if it became a simple enough gui to be excluded from this conversation.
Most apps at the time managed that quite successfully. IIRC Adobe Photoshop was an MFC app. There was no other API but Win32 API.
> Try writing something like Spotify in WinAPI and that's not even a complicated GUI either.
Fruityloops, now FL Studio, was written in Delphi and to my knowledge still is[1]. When ot launched there were no options but Win32 for Delphi.
That's just one example. Win32 makes it reasonably easy to skin things, and back in the 2000s a lit of programs did.
[1]: https://blogs.embarcadero.com/fl-studio-is-a-massively-popul...
> Win32 makes it reasonably easy to skin things
Actually it doesn't. Win32 skinning is either making a control completely from scratch or hacking into undocumented aspects of the native controls - i.e. what WindowBlinds does. AFAIK modern Delphi has some component that basically follows the WindowBlinds approach.
> Win32 skinning is either making a control completely from scratch
In almost all cases you just need to handle the drawing yourself, and you get fairly broad access through the API to do so through the various non-client and client window messages.
Now, Windows has gained some newfangled components over the years with more or less integration, I'm thinking basic Win32 controls.
What all cases? Windows (basic Win32 at that) provides a lot of controls like buttons, checkboxes, inputboxes, scrollbars, radiobuttons, comboboxes, listboxes, etc which do all their drawing themselves and you do not have any way to fully skin them (without hooking into undocumented stuff). Some controls allow for custom drawn elements but pretty much always that is just for the elements themselves, not the entire control.
WinAmp was the win32 music player of choice, once upon a time.
Once upon a time? I still use WinAmp every single day. It works great, does what I need, and I've never had a problem with it.
But isn't that illegal now? You have to write everything in rust according to their cto.
Again, unless you have existing Windows 8/10 applications that were written against WinRT, UAP or UWP[0], that make use of WinUI 2.0, forget about touching anything related to WinUI 3.0 or WinAppSDK, stay away from the marketing.
Exception being the few APIs that have been introduced in Win32 that instead of COM, actually depend on WinRT like the new MIDI 2.0 or Windows ML.
Keep using Win32, MFC (yes it is in a better state than WinUI 3.0 with C++), WinForms, WPF, if using Microsoft only tooling.
Otherwise, Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI,....
They were even forced to revamp WPF status at BUILD 2024, given how bad WinUI 3.0 was back then, and it isn't if it got any better, apparently it is in the process of being open sourced, to see if the community can take over the mess a $4 trillion valued company cannot fix.
Really, stay away from WinUI, unless you're a Microsoft employee on the Windows team without any other option.
[0] - Can explain by the nth time the differences, if one feels like it.
Just wanted to add a shoutout to WinJS for posterity, with which I built a Windows 8 app that I had published to the Windows Store for a brief period of time. Then they open-sourced the UI part of WinJS and decided it was just a web framework instead of an officially supported method for building Windows apps iirc, which was the end of my foray into the Windows store.
https://github.com/winjs/winjs
I was actually part of a team at Barnes & Noble.com which tried to use WinJS for a serious application. (We were previously using Chromium Embedded Framework, or our own hand-rolled WebKit integration, for the desktop e-reader.)
It didn't go great. I gave a talk about it. https://youtu.be/HySQR0t_7CI?si=5sfKbb-7u-qqD65R . (Be gentle to my 2012 self's speaking skills.)
I have a WinJS book somewhere, from Microsoft Press.
When it was announced at PDC, they only talked about WinJS and nothing else, the folks of .NET Rocks have a few shows where they mention they thought .NET was done, and they needed to refocus into something else.
The show where they interview Miguel de Icaza they go into this.
> for posterity
Anyone remember this one?
Microsoft Press: Learn Java Now (complete with J++ installation CD). https://www.amazon.com/dp/1572314281
Of course, the reason for the lawsuit, and redoing Ext-VOS ideas with Cool instead of J++, later renamed to C#.
Ironically, Microsoft nowadays not only has their OpenJDK based distro, they even host Java conferences.
The CD is available on Archive.org
I have the book (and CD) on my shelf above my machines in my home office. I vaguely recall buying this at Costco, around the same time I bought the 4 volume Microsoft Press C++ series (for dirt cheap, at the time) from Costco.
MS Press used to publish some amazing references. I have a LOT of 'em.
If you want JS, isn’t react-native-windows an option?
It probably is now, but I don't think it was at the time. This was back in the early Windows 8 era, when apps were called "Metro" – 2012 to 2015 I think? I'm primarily a .NET dev by trade, but I wanted to try something different with WinJS so invested time in learning that.
WinJS was a bit different, where your app was genuinely just a bundle of JavaScript and a UWP host process dealt with the rendering. (No Electron-esque to deliver with your app) Made for some tiny, succinct apps.
I am once again stating react-native-windows, the key part being native. It doesn't have anything to do with Electron.
In that light, it is troubling that Friday’s blog post [0] announced “moving core Windows experiences to the WinUI3 framework” as a measure to improve the quality of said experiences.
[0] https://blogs.windows.com/windows-insider/2026/03/20/our-com...
As long as it only applies to Microsoft employees, maybe the pain using C++/WinRT will finally improve the Visual Studio tooling for the rest of us, but I doubt it.
Thus better leave WinUI to the Windows team.
These steps are necessary stepping stones in getting the thing good, the question is, given Microsoft's tendency to abandon UI frameworks halfway, apart from the classical ones listed above, is if they will keep it focused until its gets as mature as those.
The only good thing to say about that is it removes the stupidity of using Electron (or the Microsoft Edge equivalent) for built-in Windows apps and the Start Menu. SMH.
The start menu never was electron. It's react native desktop. So, nodejs creating and updating native (well, winui 3) controls.
Heh, nodejs uses V8 which shares legacy with WebKit's JavaScript core, itself being forked from KDE's KJS. Fun to think that eventually, some KDE code spiritually made its way to the windows start menu
Whoever was responsible for that should be fired.
For non-Windows devs (from ChatGPT):
- Win32: The original Windows API (since the 90s). Still widely used.
- MFC: Old C++ wrapper around Win32. Ancient, but still maintained.
- WPF: .NET desktop UI framework (XAML-based). Still very relevant.
- WinForms: Simpler .NET UI toolkit. Old but stable.
- WinRT: A newer API layer meant to replace parts of Win32.
- UWP: Microsoft’s attempt at unified apps (desktop + tablet + phone).
- UAP: Basically early branding/terminology around UWP (rarely used now).
- WinUI 2: UI layer for UWP apps.
- WinUI 3: Meant to bring that UI system to desktop apps outside UWP.
- Windows App SDK: The “new unified” toolkit tying modern Windows APIs together.
Huh? Downvotes for providing explanations of the acronyms/tech...?
I didn't vote but I'll bite the bullet.
1. Do not relay LLM output. If someone wanted, they would use it, ChatGPT is free. Post your own, human, meaty thoughts.
2. The blog post explains all these technologies, one just need to read it further than the title. It might be a big ask here on HN, I know, but still.
The author is right, it's really such a mess.
The lessons I've learnt building and shipping a few a Windows apps at scale are basically:
(1) Learn Win32 and use those ancient APIs if possible, they're extraordinarily stable and you'll probably need to reach for them anyway. They're not that scary.
(2) Don't use any Microsoft-owned UI toolkit, you'll get burnt. Literally anything is better. Ideally choose a toolkit that doesn't prevent layering in Win32 tweaks on top, otherwise you'll end up hitting cases the toolkit developers didn't think of and you can't fix. You're going to need a custom WindowProc eventually. You need to have access to the underlying Win32 window lifecycle and handles.
> "(2) Don't use any Microsoft-owned UI toolkit, you'll get burnt"
This is 100% true for all of their techs produced within the past ~20 years, but WPF and Winforms are extremely stable with no real issues.
It's so weird too because most of everything they've done in the past 20 years has basically just been incomplete remixes of WPF. If they just stuck with WPF and extended it onward, something like a UI toolkit equivalent of C#, it would 100% be the gold standard for Windows development today, and perhaps even UI development in general if they open source/standarded it.
When they announced UWP I was just starting a new side project and I thought, let's check it out. I was hoping it would basically bring WPF into first class citizen territory. Instead, they made them needlessly incompatible. Like writing for both NeXT and MacOS, but on the same platform. I got discouraged right away and have really never done any significant Windows work since, which turned out to be a great move for my sanity.
Ahhm. At previous $DAYJOB, I inherited a WPF app written in 2012; I stumbled upon several WONTFIX bugs through the years - mostly having to do with shared memory bitmaps, having to manually call GC at times, and a host of other things.
Stable, but many issues. Stay away if you value your sanity and do anything nontrivial.
WPF and Winforms may be stable, but they're not going to work well on a modern machine with a HiDpi monitor. Same with Win32 controls.
My take: Use Win32 for opening windows and interfacing with the OS. Use a different toolkit for actually drawing inside the windows.
Ideally a toolkit that can paint in sync with window open and resize, otherwise you'll get Electron-style window flickering. And something that supports multiple windows in a lightweight way, since you're going to want popups, menus etc. to extend outside parent window bounds
WPF scales and works perfectly with HiDPI displays, and (from what I've read) WinForms support for HiDPI has improved in recent years.
Glad to hear things are improving here. Still, the UI doesn't look very nice though ;)
the should just have updated wpf with their newer widgets and just continue to improve it and even make it cross platform. (basically what avalonia is doing)
With WinUI 3 I did not even manage to render PNGs correctly.
The colors were always slightly off and oversaturated, no matter what setting I used.
I migrated the app to Tauri and the PNGs of course rendered perfectly. The implementation was much easier overall.
Hypothesis: This could be due to the toolkit's handling of color profiles. You see this a lot in macOS land with images that use a Display P3 colour profile, e.g. screenshots from a Mac or iPhone.
Native toolkits are usually more advanced and tend to properly support the colour profiles and allow for wider gamut output. Whereas historically the web had poor handling and would assume sRGB, causing more "washed out" output.
I believe that the opposite was the case: WinUI does not handle color profiles correctly.
In the browser or the Windows Photos app they were looking correct, while WinUI was incorrectly oversaturated.
Let me chime in and say that plain Win32 API is a perfectly viable option if you are using C++ (or another "OO" language) and if you are willing to sink a couple of weeks into writing your own MFC-like wrapper.
Clearly this is not an option for those who are just starting up with Windows GUI work, but with little experience it is really a matter of 2-3 weeks of ground work and then you have full control over all nuances of the UI, yours to extend and mend as you wish.
If there's one thing that Microsoft is really good at, it's ensuring deep backward compatibility. So anything that's based on Win32 API is going to be stable. If it works now, it will work later.
I have some examples from 10+ years of development updates accumulated here - https://bvckup2.com/wip
The main thing that's hard going down this route is dark mode support. The Win32 USER and common controls just don't not support dark mode, but are actively hostile to it due to the amount of hardcoded light colors and backgrounds in the system. All of the system colors are light regardless of the dark/light system setting, highlights are hardcoded to light blue, disabled controls use a hardcoded color, half of the window messages for changing control colors are silently ignored with theming is enabled. Menus are among the more difficult to deal with as they require extensive owner draw.
On top of this, there are a small handful of system UIs that do support dark mode and make your program look inconsistent with dark mode regardless. Message boxes will switch to dark mode, and so will file dialogs -- which is a problem if you've used the Vista-style customization, as any syslinks will appear in a color of blue that's hard to read against the dark mode background.
First, dark mode is for people who set their screen brightness too high.
Second, win32 is designed with the ability to change all the default colors and you used to be able to do this by right clicking the desktop and selecting "properties". If dark mode doesn't follow this - just another symptom of Microsoft's siloing incompetence. The team that wrote dark mode may not have been aware that this feature existed because parts of the platform are so disconnected from other parts.
Dark mode for apps is a setting in the OS and a general expectation now, it's suboptimal to ship a new UI that doesn't support it. And, again, Win32 message boxes in your program will switch to dark mode whether you want them to or not.
Win32 controls ignoring system colors goes much farther back than dark mode being introduced in Windows 10. The theming engine that broke a lot of that functionality was introduced in Windows XP. Beyond that, there were always a few hardcoded colors like disabled gray text going back to Windows 95.
Dark mode ignoring Win32 system colors is not incompetence. It was _intentional_. Dark mode was introduced by the UWP side, which intentionally did not extend it to Win32. To this day, there is not even a Win32 API for desktop apps to query whether dark mode is even enabled. The official recommendation is to compute the luminance of the UWP foreground color setting:
https://learn.microsoft.com/en-us/windows/apps/desktop/moder...
But they had dark themes for the XP theming engine, e.g. the Zune theme, didn't they? They could make the dark mode switch to a dark theme for XP-style themed controls and configure dark colors for the Win32 system colors.
Yes, and this is also how Windows 10/11 explorer turns some parts of its UI dark like scrollbars. But notably, Microsoft refuses to officially support Explorer's dark control themes or ship a complete dark theme, and because the theming engine only loads themes signed by Microsoft, no one else can ship one either without patching the OS.
Only a very small minority of users actually care about dark mode. It is not a general expectation for software, as loud as those users may be on forums like this one.
And how do you know this? I decided to check myself, looked for dark mode statistics on android, and:
>Dark mode is used by 81.9% of 2,500 Android users on their phones, in apps, and in other situations. 9.9% alternate between the light and dark
So it's the other way around. Only a very small minority of users actually care about light mode.
Mobile is different from desktop. Dark mode became popular with OLED panels because on those it saves battery, and blacks actually look nice, compared to the average LCD. I use dark mode on mobile but light mode on desktop.
That survey was power users only: https://www.androidauthority.com/dark-mode-poll-results-1090...
I would be astounded if a majority of general Android users used dark mode, as light mode is the default on most phones (all, IME).
Mine switches between light and dark depending on the time of day. It was the default behavior.
I think android is a big difference here. What about excel or Google sheets? Word?
If you're building win32 you're not targeting android.
I'm not sure how much Android use generalizes - I prefer light mode, but I'll use dark mode for the battery savings on portable devices with OLED screens.
On Apple platforms is very uncommon to find apps that only support light mode. The only one on my phone is the app for my old Chinese robot vacuum.
Dark mode ignoring Win32 system colors is not incompetence. It was _intentional_.
Intentional malice, in other words. A stupid attempt at pushing UWP.
> First, dark mode is for people who set their screen brightness too high.
Not at all. It became popular mainly because as part of the spread of the flat UI epidemic, the previously non-optional “light mode” OS UI themes all shifted away from midtone colors to blinding stark whites. This meant that monitor brightness settings that had previously been comfortable suddenly weren’t.
On top of this, modern flat UI light mode themes consistently have poorer contrast and delineation than their dark mode counterparts, because higher contrast with darker grays makes flat white UI themes appear “dirty”. So even if the brightness isn’t an issue, your eyes have fewer visual cues to guide them.
Aside from that, on IPS panel monitors lowering brightness past a certain point also greatly lowers color vividness which looks bad, which is why some of us like to keep it maybe not maxed but a bit higher than is comfortable with light mode.
It is not. I have some issues with my eyesight and dark mode makes it easier to use a computer in some lighting conditions. So for me dark mode is an accessibility feature. And yes you could use the ugly recolor feature windows has but dark mode does the same thing and looks better most of the time cause a UI designer actually looked at it.
> dark mode is for people who set their screen brightness too high
There can be other valid perspectives than your own.
I don't think your brightness sentiment is universally shared by most people, hence the downvotes. I think this comes from one particular study that people just end up parroting, possibly via third-hand gossip.
While a sufficiently low-brightness screen might have some specific advantages to dark mode, I think the issue is more nuanced than that.
First, not everyone can set their brightness to an appropriate level.
If the user is prone to migraines or light sensitivity, light mode even at a low setting could trigger headaches.
Light mode also produces significantly more blue light, which can have health side-effects as well.
If you keep a white screen on at appropriately low brightness in a dark room, the relative difference between the screen and the surroundings is still massive. This creates pupil strain as the eye constantly adjusts. Dark mode aligns the screen's luminance closer to the room's, reducing this strain.
Dark backgrounds make colors pop more vibrantly and prevent the "washed-out" look that can happen when bright images sit on a white background. It can also reduce halos visible around bright objects in photography apps and make the UI less distracting.
For battery-powered/mobile devices, dark mode uses much less battery power on OLED screens.
Judging from the screenshots, that doesn't produce Windows 11 style UIs, right? I.e. it contributes to the problem exploree at https://ntdotdev.wordpress.com/2023/01/01/state-of-the-windo...
Maybe I grew up with Windows so the older uis don’t phase me, but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland. The average Windows user might stumble on an aero dialog, which is arguably less jarring in win11 than og metro.
> but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland
I've been around long enough to remember MS and their fans banging on about how bad other OSs were for their inconsistent interfaces, so I feel justified in getting a little riled at the hypocrisy of how much of a mess UIs are in Windows these days.
And I don't see it getting any better - they'd rather spend the time finding new places to slip in adverts. And this is far from the fault of app developers, while they often do have something to answer for wrt consistency, because the worst culprit is MS themselves both in their apps and the OS.
I shouldn't have to click to make sure the right thing has focus for instance, particularly after switching from another virtual desktop, I should be able to see this information easily but there is no consistency in titlebars and other window chrome any more.
Screenshots are made on Windows 8.1 box, the windows chrome comes from there.
Plus the whole thing is meant to work on ancient Windows versions (like, Vista and WS2008 ancient), so that ultimately defines the minimal common UI denominator.
Many would consider that a positive.
Jesus, that's way worse than I expected before clicking
The last time I built a native Windows app years ago, I used WTL 3.0. It’s a light weight wrapper on the native Win32 API, lighter than MFC. It took out the unpleasantness of working directly on Win32 API and wrapped it in a simple OO framework. It had access to all features of Win32. It could produce runtime binary in dozens of K, instead of MB or GB.
Microsoft released it open source later on. Looking at the repository, looks like it has been kept up and maintained, up to version 10 now.
GitHub mirror of the sourceforge repo: https://github.com/Win32-WTL/WTL
WTL delivers very small and efficient code, very close in size and speed to SDK programs, while presenting a more logical, object oriented model to a programmer.
Why not just use C++ Builder or Delphi?
Presumably because they don't support C++23
I don’t want to be that person, but if you can think of a decent API for your MFC-style wrapper, an AI should be able to write a decent implementation for you.
Agreed. In fact this supports the GPs point about using the rawest form of GUI manipulation.
For years we loaded up libraries and abstractions to minimize boilerplate. These hid the actual underlying mechanisms and often made specific customisations harder to do since you were taken away from the raw functionality.
These days AI is extremely good at writing boilerplate and in my opinion explicitly typed out boilerplate code is much easier to reason about than a library that abstracts things away to a one line annotation or similar.
A good example is that i've recently been leaning back to the raw Android apis for things like recyclerviews etc. It used to be 10+ files to changed to create an efficient scrolling view on Android with various resources and adapters required. So a whole bunch of libraries came out to try to abstract the complexity away. You know what though? I don't care about that anymore. I'm going back to the raw GUI APIs where possible because it's so explicit and clear even if it's 10x more code.
> If it works now, it will work later.
Wine is better at it than Windows itself. Especially for really old programs.
> And from what I can tell, neither are most developers. The Hacker News commentariat loves to bemoan the death of native apps. But given what a mess the Windows app platform is, I’ll pick the web stack any day, with Electron or Tauri to bridge down to the relevant Win32 APIs for OS integration.
Well yes as a user I prefer native apps for their performance. It's clearly a mess to develop native apps as the article shows. But as a user I don't see that problem. I do see ever worsening apps though. Like the total mess that is new outlook and teams.
That’s ironic given that the new Outlook and Teams are a mess because they are web apps instead of native apps.
Web apps cause have lots of trouble emulating proper native look and feel and often have wierd issues with things like consistent focus and keystroke navigation. They have all the dumb issues of Java apps with no improvements beyond not being Java and are slower and more memory heavy to boot!
When Microsoft themselves use electron to develop apps what expectations can we have on other devs?
Microsoft has always stood for mediocre quality software so that's no surprise.
Also, they stopped caring about Windows because they want recurring service revenue. Making Windows a subscription service for consumers would outrage the users (even though they kinda already do this for business with Microsoft 365). So the consumer market is just viewed as a billboard for M365 and Copilot. So everything you see there is just lowball effort, even worse than their normal quality.
To do better?
It's demonstrably possible. And further, why does what some portion of Microsoft, a huge, multi-headed beast, does qualify as the bar for what is reasonable for users to expect?
This, and add to that the fact that web apps make it trivial for the dev to just randomly change the GUI out from under me without my consent or ability to prevent it, and, well, wonder why I and so many others dislike them? I want to be able to refuse app updates, thank you very much.
A question - Which portion of Microsoft, the multi-headed beast develops pure-native apps now ? Even the Windows 11 Settings app is Javascript.
The multi-headed beast has been assimilated by web-tech. They can't code GUI C++ no more - except their compiler/graphics team. And even the latter are dying.
There are like three settings pages that use JavaScript and React Native, the vast majority of Settings is C++ and XAML/WinUI2
but that was already developed, all new development it's going with web based at microsoft
Id be interested in a source for both this and the parent's comment. How do we know which settings pages use which tech? Have people been decompiling them?
Pretty easy to know by just looking at app install folder, or, with Visual Studio, without any need to do any decompiling.
In practice, I guess most people realize because web tech just behaves different than native.
As a user Microsoft is windows and windows is Microsoft.
If doing native apps was realistic then I’d expect windows, Microsoft, etc to also do them.
To decide what tools are the right job for each project,
same expectation as always.
So many “let’s race-to-the-bottom along with the authority” comments on HN lately.
Dude: no! =]
I think more so I’m saying that the platform (metaphorical ship) is sinking.
Majority of applications on Linux are native applications. Maybe the problem is the platform?
Yeah exactly, on Linux I mostly use Qt apps and they're great. Even Telegram is native. The only one that I use that isn't is Obsidian. But all these notetaking apps are electron (and markdown) somehow.
Considering people are leaving Windows in part because Microsoft is shoving web slop into it, perhaps other devs should learn the lesson that it's not acceptable to use web frameworks on the desktop.
Speaking about Electron, for my own little tools I have been using TypeScript+Bun with Electrobun.
https://github.com/blackboardsh/electrobun
This is neat! I clicked through about 10 app examples on that page and none of them had a screenshot of the app!
It's a grave sin to have an app repo without a screenshot in the main README.md.
Note: Yes, I know that electrobun itself has videos on the README.md
[dead]
> But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
I disagree, the GUI layer is far from behind a safety critical component, and C++ is a battle-tested choice for everything from GUI, videos games, to industrial applications. If C++ is safe enough to control airplanes and nuclear reactors when used well, it is certainly safe enough for something as trivial a GUI.
The article also fails to mention frameworks like Qt, arguably the best way to write GUI apps in 2026. Qt is native (C++), has built-in memory safety features (but no GC), and is cross-platform.
Why would the article mention Qt? Qt is native for a subset of Linux distributions, not Windows.
Qt is arguably the best cross platform toolkit to target when writing big/complex apps
Qt for Windows compiles to a win32 or win64 .exe. That is native in my book.
Even Microsoft shipped Qt apps as part of Windows though, for instance onedrive
...but it is comfortable and actually a PITA compared to any managed execution environment :-)
Sure, embedded systems are a different anmial...
Yet we cannot consider Qt to be native app development since every app requires the Qt runtime. Native means system libraries only.
There is no Qt "runtime". Qt is just a library.
> Native means system libraries only.
Every non-trivial application will eventually use third-party non-system libraries.
I think "Native app development" has at least two meanings:
1. narrow meaning: the program uses a native UI toolkit (Win32, Cocoa)
2. broad meaning: the program targets one or more specific platforms and the UI is not not just a webview
Even with the narrow meaning, WxWidgets would qualify as "native development" (because it uses native UI toolkits under the hood), yet it is still a third-party library.
>Native means system libraries only.
Since when? To me, anything not webview-based is native, though you have varying degrees of integration into the platform.
Why single out WebViews? Would you consider Flutter native? It renders widgets on its own just like a WebView does.
For me, native means "I can integrate a platform widget in the middle of it". For instance, with Qt, GTK or wxwidgets it's entirely possible to integrate a Win32 / Cocoa / X11 component right in the middle of your app (and it's super important for instance for things such as integrating audio plugins, where the plugin only gives you a HWND or NSView and you have to draw your application Chrome around it, have it follow resizes, etc.)
So then flutter will let you do that, with a little elbow grease.
doesn't seem like it can though? https://github.com/flutter/flutter/issues/31713
It's pretty much impossible to embed properly without edge cases in GPU-based renderers as far as I know, if you want layering of widgets (for instance a platform widget in-between two flutter widgets in z-order)
Most toolkits, including WebUI 3.0, render widgets on their own, so you can't distinguish just on that. I'd say anything written in an interpreted language is not native, and Javascript falls into that category. Dart at least is possible to compile ahead of time, and so is C#.
WebViews aren't written or rendered with interpreted languages either. It is also usually not Javascript that makes browser based apps so heavy. It is almost always the whole browser stack that is making them large and memory hungry, which is mostly written in C++.
You can also hook a WebView up directly to a low-level language and skip Javascript entirely, so does that mean Rust + WebView = Native?
I have always considered Qt apps (even for Windows) to be native. Think of VLC, VirtualBox, etc.
I'd consider them "naturalized"; close enough to native that you wouldn't notice any big differences, but there are still minor ones if you know what to look for.
Author raises several good points. Why isn't the latest .NET runtime pulled down into Windows 11 devices via Windows Update? Why isn't there a better path forward for deployment?
It's another example of how they have completely abandoned any attempt at providing a good user experience across their products
I'm assuming but the versions are not fully backwards compatible so you can't just ship the latest version, they would need to ship all. There almost ten .NET versions released after the one which ships in Windows. And a new version is released every year.
The author does mention that .NET does have distribution options which don't require the user to install the runtime. You can have it package the full runtime with your build, either as a bunch of files, a self-extracting executable, or a standalone AOT-compiled native executable.
The author mentioned that the AOT-compiled executable is 9 MiB which is unacceptable to them. The other options will need even larger. Personally I don't see 9 MiB as a big deal especially when the author would rather go with Electron which is larger at worst (bundled Chromium) and only inefficient at best (system WebView).
Windows update is how it used to work and it's terrible. An update breaks old apps, or downloads a every single version (not feasible). Who would want to run windows update to install a new app?
It's just a bad idea. Today we just pack in the DLLs and it just works.
No one suggesting using Windows Update to install new apps, they are suggesting the current .Net framework should be elevated to a first class Windows citizen and included with Windows installs and updated with Windows Update, and that seems like and obvious idea that should have been implemented when .Net Core became .Net.
.NET versions are not fully backwards compatible. Would you like every Windows install to ship with over ten versions of the .NET runtime?
We would like it to be good. Whichever way to achieve goodness - either be backwards compat, or ship all the stable versions, I don't care but the current situation is silly. Apple gets flack for this and that, but their UI toolkit situation is lightyears ahead; you just pick the OS version you want to target in your app build settings and it will work that way for everyone.
100 MB per runtime, for everyone, and the majority of them are out of support. Is that really the good option? Why not the option the author dismissed: a 9 MB AOT-compiled executable which doesn't need a separate runtime?
> Would you like every Windows install to ship with over ten versions of the .NET runtime?
A better approach would be to not break backwards compatibility in the first place.
That's what .NET Framework (the one that ships with Windows) tried to do. It usually worked out but you'll still run into compatibility issues sometimes after bug fixes, behavioral changes, etc. because people accidentally build software which depends on quirks.
Yes?
An update breaks old apps
That's something which is MS' problem; they're supposed to be the company who is best at backwards compatibility, but clearly have strayed from that path.
There are a few reasons that I can see why they don't integrate the latest .net.
First is that the security model changed with .net 5. Next is that they subsume Mono/.net core into the foundation of the language and this cost them them the ability to support Windows native development, specifically anything to do with Win32 API.
If you look at .net 10 and compare that to .net 5 you can see that they are trying to reintegrate the Win32 API but now it is in the all new Microsoft namespace.
The amount of change is too significant to act as a drop in replacement for the original .net framework. Maybe they could have gone a side-by-side installation, but the rapid development of The NET Framework I think made it too hard to tie to an operating system update. They wanted to free it from that update cycle of once a year or every two years and allow the development to progress rapidly at the cost of having to download it and install it each time.
Side by side is what I'm asking for. Just like there's WebView (IE-based) and WebView2 (Chromium-based, evergreen, updated every 4 weeks).
I don't think the rapid development cycle argument holds water, when they're shipping a new WebView2 every month.
There’s two versions of .NET. One is “legacy”, which is stable as anything and bundled with the OS. The other is “Core”, that only has support for three years and isn’t 100% compatible. The reason the latest .NET runtime isn’t bundled is the above: the stable version is bundled.
Core is compatible with non deprecated apis.
That’s why they had .NET 5im stead of .net core 5
Really nice article, thanks - yes I found the same myself recently when trying to write a trivial (I thought) Windows app.
I first investigated the Windows native options and was pretty bamboozled; I wanted to use the "mainstream" "up to date" option (presumably c# and some framework) but as TFA describes, it wasn't at all clear which that was.
I ended up doing it in python with pyqt then finding out a clean deployment was a pain, so revisited the .Net options and remembered why I'd discarded them in the first place...
It is indeed a complete mess (at least coming in anew) and a very strange situation for the world's main desktop environment to be in.
It had been many years since I last developed a desktop app. A couple of weeks ago I used Tauri to create a simple app for Windows and Mac. Developing the app was easy with Claude. Building the app for different platforms and architectures was easy with GitHub Actions.
But after I had the msi and dmg files, my non-techy colleagues couldn't install the apps because they weren't signed. The workaround for Mac was fine (remove the quarantine attribute on the installer) but for Windows my colleague had to disable Smart App Control (SAC), which cannot be re-enabled without re-installing Windows.
I get the point of these protections, but the difficulty of getting past them surprised me. I thought that on Mac you should just go to settings -> security and click 'Allow Anyway'. And that on Windows you'd get a GUI warning that would need admin privileges to get past. But MacOS needed a terminal command, and Windows needed a control panel setting change.
> 9 MiB
I'm glad people still care about stuff like this. It drives me insane that the simplest form-based software that I build and compile ends up being 50-100 MiB; several times video games from the 80s that I grew up with that did much more complex work, graphically and computationally, on a tenth of the space.
The answer to your question of "why not Electron" at the end is: because then your app will suck. You've laid out the reasons why native apps are harder to make, but the reality is that Electron trades your ease of development for the user having a crappy experience. If you care about producing a good product, then you have to suck it up and make the native app even if it is harder.
Also, I think C# is miles better than TypeScript, but that's just my preference.
> However, for no reason I can understand, Microsoft has decided that even the latest versions of Windows 11 only get .NET 4.8.1 preinstalled.
.NET has new releases every year, supported for 2 or 3 years. That’s not really compatible with Windows release cycles. Also, if Windows 11 25H2 shipped .NET 8, and now Windows 11 26H2 would ship .NET 10, apps which depend on version 8 might break. Easier to just think of .NET as a runtime like Java or Python.
---
Regarding tray icons, 1Password, Signal, and Discord are all Electron apps, so they are using Chrome’s UI toolkit, and its menu component.
Myself, I’m happy with WPF. Starting with .NET 9, it comes with a really good WinUI-style theme.
.Net has always been hugely backwards compatible and breaking e.g. .Net 8 apps which will run out of support in November 2026. How is constantly needing to update .Net any different from constantly needing to update any other part of Windows?
Ideally they would just install newer .Net releases side by side and uninstall .Net releases as they drop out of support.
Microsoft promises things included with Windows will be supported ~forever. Adding modern .NET into the mix would break this promise and add more churn.
Automatically uninstalling .NET runtimes would break apps, and Microsoft will be to blame, not app vendors who failed to upgrade to the latest .NET. An app built for .NET 8 can run on .NET 10, assuming no backwards-incompatible changes in the runtime and system libraries, but this behavior is opt-in.
.Net releases are installed side-by-side. I agree with the Author that a more recent minimum install of the framework would make sense, especially with the existence of LTS releases of .net [1], seems to be every 2nd major version. I don't agree with the argument that Windows would have to guarantee a particular version is installed. If an app requires .net 8 and .net 10 is installed, the app can install .net 8 next to version 10. It would however require different silos within Microsoft to communicate and plan together.
.Net 4.81 is the last one before .Net Framework was unified with .Net Core. It's very legacy by now, but there would be many enterprise/business apps that still require it.
[1] https://dotnet.microsoft.com/en-us/platform/support/policy/d...
Last time I heard WPF was basically abandoned (open-sourced) and handed over to die to some Indian folks.
Something akin to WCF
At least WPF is seeing some development, and it is officially and fully supported in the modern .NET. WCF is a wasteland.
It has been a mess for 15 years and Microsoft keeps making it worse by adding new frameworks without retiring the old ones. Win32, WPF, WinUI, MAUI. Nobody knows which one to pick.
Yes, and the hubris sting-of-death was UWP. They tried to make Windows into a mobile OS, severely restricting the alowed actions of programs, including strict certification to be able to run them (elsewhere). Of course nobody went for this and UWP died a quiet death. Recently there are signs that MS is trying to go back to making products that users actualle want (Win11 reverts). We'll see...
It's hard to describe how uselessly restrictive the UWP model was when they originally introduced it as "Metro-style apps" in Windows 8. Among the things it officially did not support included:
- Multiple monitors - Non-full screen views - Sideloading outside of the Store - Offline installation - Explicit threads - thread pool only - Aligned memory allocation - malloc only - Any C++ compiler other than MSVC - Support for any version of Windows other than Windows 8 - Running apps as administrator - Running more than one instance of an app at a time - Runtime shader compilation
If any ONE of these things was a blocker, you could not write a Metro style app. And yet Microsoft pushed this extremely hard -- including almost completely ending any maintenance of Win32 APIs. And despite the many relaxations and extensions, UWP is still largely useless today, and now even itself seems to be going into maintenance mode. All of which has done a lot of damage to the state of Windows desktop platform development.
As an example of how bizarre UWP is, for some reason every time they published a list of new APIs added to it, they converted the list of API identifiers to lowercase in the documentation:
https://learn.microsoft.com/en-us/windows/uwp/whats-new/wind...
It's relatively insignificant, but... why? Just one of many things that showed how immature UWP was.
> They tried to make Windows into a mobile OS, severely restricting the alowed actions of program
They already had Silverlight! For Windows Phone 7. Then they killed that off too and expected the "plethora" of WP7 apps to be rebuilt for WP8 (requiring the beloved Windows 8 desktop OS for this task). Then they again expected developers to throw that away in favor of UWP for Windows 10, which unified the desktop and phone OSes. By then it was too late.
Old apps still ran on the newer OSes but the SDKs became dead-ends.
> (Win11 reverts).
I must've missed that one. What did they revert?
It doesn't matter - what Microslop says and what they do are traditionally very distinct things.
But in case you want to read yourself: https://blogs.windows.com/windows-insider/2026/03/20/our-com...
"File explorer launch experience" -hard to tell if this is satire…
I did mean these, very recent promises (vaporware at this moment), without satire. https://blogs.windows.com/windows-insider/2026/03/20/our-com...
> without retiring the old ones
They'd lose too much enterprise software that's not being maintained any longer but still is business critical.
You can still run most programs from the Windows 95 era unmodified on a modern Windows 11 machine and a lot of things is relying on that under the hood.
Picking a stack for native Windows UI is like rolling dice, except sometimes you get bitten by COM for fun. If you care at all about backwards compatibility or deploying outside the MS Store you basically end up circling back to Win32 APIs much as the frameworks would love for you to pretend otherwise. Ironically, the 'official' docs now reads like a half-hearted apology for the last decade of churn.
You don't have to go all the way back to Win32; anything from the pre-WinRT era is fine. MFC, WinForms, WPF are all still supported and updated.
This is quite timely as we need to write a simple UI for Windows (a few buttons, status, maybe a file menu). The main constraint is it must compile to a single binary (.exe) with no dependencies such as runtimes, DLLs, languages etc. It also needs to run on some older unsupported Windows systems, probably Windows >= 7, 32 bit.
My first thought was MFC. Basic, fast, well understood.
But then maybe WxWindows so we can cross-compile it (from Linux) and use the same UI on other platforms? It could probably be compiled statically although I've not tested it.
Or Mono, but that needs a runtime?
Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically?
Pure Win32 will do exactly what you want. Single tiny .exe that works from Win95 to 11. Even Linux with WINE.
Get started learning here: https://news.ycombinator.com/item?id=21459616
Qt is compiled to a native .exe. It doesn't have a runtime. To give you a rough idea of size, I have 3 GUI application written using Qt/C++. The installers are 72 MB, 69 MB and 32 MB. The first 2 include a significant amount of documentation. I could probably get them a bit smaller if I really needed to.
Delphi or Lazarus (https://www.lazarus-ide.org) should solve it.
Nice, I didn't know there was a free software version of Delphi nowadays.
If you mean Delphi Community, it has some restrictions, but probably 99% works?
If you mean Lazarus, it is fully open source. No restrictions but the ones of the software itself.
With restrictions of course.
For what you describe, .NET + WinForms or WPF will work just fine. These days it can built self-contained executables, although they won't be small (but then again, when many websites have multiple megabytes of JS...). Or you can target .NET 4.8 - for something this simple I doubt there'd be much difference but then you can ship an .exe that measures in kilobytes, and the runtime is included with every version of Windows going back 10 years.
You can build single-file executables for .NET 4, and I do, but there's no static linking, so you need to restrict yourself to assemblies that ship with the framework and whatever other prerequisites you're willing to install or assume will be installed.
Two notable caveats:
1. Certain newer C# language features require runtime support that doesn't ship with older versions of .NET, which can include quite a few DLLs.
2. In-process COM components can only be instantiated in .NET runtimes runtimes with the same processor architecture, even if the .NET program itself is processor-independent (which by default will use the runtime matching the native architecture), so you may need to ship multiple executables to match multiple COM dependency versions even if your program is otherwise processor-independent or you only intend to ship it for a single processor architecture.
For example, if you build a processor-independent program that relies on the Microsoft Access DAO library, it will by default work correctly on 32-bit Windows if 32-bit Access is installed, and on 64-bit Windows if 64-bit Access is installed, but there's no way to get it to work on 64-bit Windows with 32-bit Access without shipping a second executable (that can be identical with the exception of the 32BITREQUIRED flag in the CLR header[1] that can be set as part of the build process or with the .NET SDK corflags utility).
Rather than ship separate "32-bit (or 64-bit with 32-bit <bar>" and "64-bit" versions of a program <foo> that interops with some in-proc COM component <bar>, I prefer to build a single executable <foo>.exe, then create a copy <foo>32.exe with the flag set as part of the build process, and ship both to be installed side-by-side.
Then, since the native COM DLL isn't loaded until you actually create an interop object referencing it, you can just try to create an Interop.<Bar>.<something> object at program start, catch ComException with HResult == REGDB_E_CLASSNOTREG, then in the exception handler, run <foo>32.exe as a subprocess with identical command-line arguments and exit with <foo>32's exit code, unless you're already running in a 32-bit CLR, in which case you just fail normally.
[1] https://ecma-international.org/wp-content/uploads/ECMA-335_5...
> but there's no static linking
Not out of the box, but there are ways to do it, e.g. ILMerge.
> so you may need to ship multiple executables
OP's baseline is native code tho, so they are already planning to do that.
> Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically?
You need a commercial license for that, but yes you could. But since applications are typically distributed with install bundles that put into application-local program files directories, it's not super-important as long as you only cherry-pick the Qt libraries you need.
This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.
I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.
[1] https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
Yes, that is true, but in practice nobody has ever done that. And the material complexity of offering that mode is higher than just dynamically linking the library.
Also, modern compilers make this method much harder to use. It is much harder to stably relink object files like that than to just use the normal dynamic link method.
.net will work. Use a weaver (fody) or the modern features to roll everything into 1 .exe.
Use self-contained to have everything together.
https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
For such a trivial thing I'd just take imgui.
MFC, wx, Qt .. it's all overcomplex pointless bloat for this task imo.
It’s been a long time since I had to touch Windows development. If I had to do it over again, I would use React Native for Windows UI where possible and low-level Win32-React Native module bridges for user space code.
The last time I had to do Windows development was about 15 years ago. I used a library called WTL (I think a couple comments here mention it). I couldn’t use any of the newer stuff that Windows 8-10 were pushing because it needed backward compatibility. It seemed way less bloated than MFC, but not as annoying to use as ATL or rawdogging Win32 APIs.
Ironically, I was developing a Win32 app to build a cloud bridge to a Rails app (talking to Quickbooks COM API which was hell on Earth, with XML and XML definitions) on Mac, using VMware on Mac to talk to Quickbooks Windows. I was so annoyed with Win32 development I used the Chrome Embedded Framework library to build the UI for the Win32 app so I wouldn’t have to wrestle WTL for UI and just have browser-based views to drive UI.
I think it was very tempting to drop C/C++ development for .NET code, but I didn’t want to drop off user adoption by requesting users to download a huge .NET runtime if their computer didn’t already have it.
This was when I was building Levion, a Quickbooks Windows to Cloud Rails app…
You should run away from React Native Desktop screaming. It's built on top of WinUI 3, and inherits all it's problems, while also being dramatically slower. Almost all functionality requires writing C++ code, and communicating between C++ and JS is a huge pain in the ass. Use QT instead.
And if you think using it will let you port your app to other platforms, think again. There's no drop-in compatible equivalent of RNW for Linux, and the version for Mac is even worse than the Windows version.
t. works on a huge app written with React Native Desktop
Thanks for the heads up! In all fairness, I'd probably run away from writing any more desktop apps!
The Windows code signing experience has prevented me from shipping apps that otherwise run perfectly fine on the platform. It is a nightmare and I cannot believe it wasn't called out in the "We want to fix Windows" blog post.
Just do exactly what Apple does. Charge me $100 directly from you and let me build an .exe that I can distribute on my website.
This isn't well-known, so I figured I'd mention it.
Microsoft offers a service called Azure Artifact Signing (used to be called Trusted Signing) that manages code signing for you:
https://azure.microsoft.com/en-us/pricing/details/artifact-s...
It's $9.99/mo, and you don't need to worry about procuring or renewing code signing certs.
US and Canada residents only, sadly.
See my sibling reply[1].
[1]: https://news.ycombinator.com/item?id=47507201
Nice. I hope it eventually hits Japan.
Except this requires you to own a business for 3+ years, which makes it a non-starter for indie apps.
Not anymore: Artifact Signing is now generally available (GA), to anyone with an Azure account in the US, Europe, or the UK[1].
[1]: https://techcommunity.microsoft.com/blog/microsoft-security-...
Most of the desktop applications I have wrote over the years have been in other languages like Java and Go as I have wanted them to mostly be cross platform. In these cases I have always used the Software UI, which in Java is Swing and in Go is Fyne. These are usually reasonably fast, don't necessarily look native depending on how its themed but ultimately fit the language better than trying to bridge to Win32 or GTK/QT.
But punish the user so you can develop cheaply and lazily? I’m not sure that’s a model I would want to follow.
I write .NET Framework 4.8 apps. And I will until .NET has an actual support lifetime. 4.8 will still be supported and receiving security updates in ten years, .NET 10 will be gone in 2.
Hobby projects should not be built on a platform that is constantly changing underneath.
My company is moving our main LOB app to .NET 10 in the near future. It's taken a while but has gotten to the point where .NET 10 has pretty much caught up to .NET Framework for feature support, and our take is that the cross-platform support, performance gains and newer C# versions are worth more than the stability of .NET Framework.
And the gap's going to keep growing - doing the upgrade now means future upgrades can be more frequent and incremental, rather than trying to move 4.8 to .NET 20 in a decade.
Unfortunely I have reduced my use of .NET, because some of the partner products that we use, or customers that were into .NET, took the opportunity for going into another technology stack.
Basically the kind of customers that were affected by the breaking changes, between Framework and Core, decided to keep the old stuff running in Framework, and consider other alternatives going forward.
Not sure how much these kind of customers matter to the .NET team's upper management in customer acquisition, but they surely lost a few along the way.
And now there is even CoPilot based migration tooling on VS 2026, because most likely there aren't that few that are still chugging along with Framework.
If .NET had a desktop UI for Linux it might be worth it for me, but we haven't gotten there yet somehow.
Yeah we don't have any plans on moving our WPF app to Linux, but the rest of our stack (job scheduler, ASP.NET service, web APIs, etc.) all has real potential to get off of Windows.
But there are libraries that do that, e.g. https://avaloniaui.net
It doesn't really matter anymore. When .NET 10 is done, there will be .NET 12 and all your apps will run just fine on it.
.NET framework used to get new versions as well; it's just that it's not anymore. After moving on to newer versions, .NET framework feels clunky now. Also you end up missing out on a decade of new libraries.
>.NET 10 will be gone in 2.
To be fair it's been super simple to upgrade .NET versions the last few versions especially.
Then why are they separate versions? I've got like five modernish .NET runtimes installed on my machine, half are unsupported, and there's no way to identify which ones are still needed.
Meanwhile 4.8.1 is built int Windows and supports apps written over like the past fifteen years. Why wouldn't anyone just use that?
I'm sure modern .NET has some nice things but the release model is not one of them.
Compared to Framework 4.8, modern .NET has a LOT more stuff in it, every year it gets more stuff and its essentially on version 9 now (they skipped .NET 4).
I stick to the LTS versions which are the even numbers and they are supported for 3 years each. after 2 years in, the next LTS is out and all I typically have to do is bump up .NET target number in the project and I haven't really had a problem. There were more changes back in the .NET Core 3 and .NET5/6 days, but that was like 5+ years ago now.
Also, you can build your apps with the framework included in a single executable even, and so anyone can use your app without having the framework installed at all if you are worried about whether the framework version is installed on their system or not.
Also if you wait the 3 years to upgrade the .NET version, then I doubt you would ever have a problem where the target system didn't already have the new LTS version after it will have been out for a year at that point.
If you really don't care at all about cross platform support which .NET offers really well now, then you could keep using Framework 4.8, but after nearly 10 versions of .NET the improvements to the C# language and runtime and everything are hard to ignore. Though I think there is some way with some package you can use the new C# language features with Framework 4.8.
I mean, if Microsoft cared about cross-platform support, I would too. But they don't have an officially supported GUI framework for Linux. I understand there are new things in the new .NET, but the story for upgrading to it and supporting it still isn't worth it.
When Windows builds in a modern .NET, I will use it! Bear in mind all of this above churn, while they claim is the new way things work, is inherently temporary: The reason .NET 4.8 is so well supported is Windows is built on it. So if Microsoft ever wants to use those newer things in Windows... Windows will have to build-in modern .NET features someday.
Microsoft approach is similar to the C++ approach where new way or feature won’t cut the older feature/way of doing things. I’ve heard Bjarne Stroustrup once in a lecture explaining the value of this approach as the language is used in so many fields and that it’s important for all code to compile allowing gradual migration.
In some ways, Microsoft is similar to that.
Apple on the other hand is fast paced so API can suddenly be deprecated and slashed and with Swift they’ve also made a language that is being changed from time to time in a breaking way.
While Microsoft’s approach similar to C++ it is a private company with no committee. This allows fast pace for ideas needed by a company in a competitive market. But, with ensuring backward compatibility, it makes each not throughly thought design -stick.
I guess Win32 is an exception since the first GUI concepts, our desktop designs hasn't changed that much. Window, Menu, Toolbar. Back then, The competition and pace was less intense allowing more time to think. There were other constraints of course being applied by the hardware and stack available back then requiring more abstract designs.
In that sense, it’s quite interesting to see Win32 is kept while Apple’s switch to NS/OSX made everyone eventually transition into Cocoa.
"So when I went to work on my app, I was astonished to find that twenty years after the release of WPF, the boilerplate had barely changed."
Such is the benefit and the curse, I guess, of having the Windows API being locked in the distant past for backwards compatibility.
I've always been surprised that Microsoft didn't do a full operating system refactor and provide a compatibility layer for running old binaries. Perhaps they figure it would be better to just transition everything to software as a service using web tech? But I just don't see how that strategy is gonna work long-term.
They DID such a refactor for Win NT under David Cutler. Even in that comparatively simpler time it was a huge undertaking, and required all-hands-on-deck management that doesn't exist anywhere in tech anymore, let alone at today's Microsoft.
"I've always been surprised that Microsoft didn't do a full operating system refactor and provide a compatibility layer for running old binaries"
Just keeping a legacy system in working order is different skillset than writing a new system from scratch.
So you need a new team. Nothing from Windows maintenance transfers.
Maybe would require hiring someone who knows how to design an OS.
It would be a major undertaking, needing protection by CEO (and if it would not succeed CEO would loose a lot of prestige).
I'm not saying MS does not have the existing talent base. I don't _know_.
But I've been inside a house maintaining a monstrous legacy codebase.
I can tell you - it requires surprisingly little deep understanding just to keep an existing system going.
I mean technically they did with Windows on NT and again with Windows on Windows 64. Vista was also a huge redesign from the 1990s NT to a lot of the new technologies they'd made in Longhorn.
That is why everyone even Microsoft themselves does Electron.
Running with html/css/js has benefits it really is open and free development based on international standards and not locked into any single big tech.
I don't know, I think it's pretty embarrassing that Teams is an electron (or whatever) app. The plot on native has been lost so badly that even the fucking company that makes the OS doesn't want to deal with it.
Electron is the worst thing that happened to quality software. I spoke to two HR guys last year at the company I'm working at and they told me they ditch every single resume mentioning "web technologies" in them. Funny part is when they also told me these "bad" resumes are for the vast majority H1B wannabees.
Second. I wouldn't say we ditch resumes on that basis, but ultimately, we're a native outfit only. You can be the best damn app developer on Earth but if all you've ever used is Electron, well, I can't use you.
What's so funny about that? Most electron turds I deal with are American in the first place, they must be trying to appeal to you.
NPM it's the bigger turd happened ever, slow and bloated. And JS today amounts the biggest enforced propietary loading method of existence in almost every web page.
Open? You wish.
>and not locked into any single big tech.
DRM and propietary cody tells me otherwise.
Say what you will about Apple, they at least still think it’s important to support and do native development, especially for their OS. Microsoft might as well have bought webOS as their new Windows replacement and admitted they’ve given up on native apps.
Do original Macintosh binaries still run on the latest macOS? I haven't looked much at the situation on that side but I believe Apple has no equivalent to the Win32 API.
Clown shit. “We’re made our own OS a nightmare to build on so we’re gonna use JavaScript powered pseudo-VMs and make everything take 2 gigs of ram minimum”
Isn’t Microsoft also using React native for desktop stuff?
I just use JUCE. It solves all the problems I need solved on Windows and doesn’t lock me into anything. More and more, if its not cross platform C++, it just doesn’t make any sense to invest in it. This is getting more relevant as the years go by, alas.
Given OS windows shares, if you are writing desktop, cross platform makes no sense for most apps.
.. except for where it does make sense, for example, you have applications that you want to deliver to MacOS, Linux and Windows users. Windows is less and less relevant these days - especially when one takes the bull by the horns and deliver cross-platform apps on purpose.
Excellent summary of the stupid state of Windows native GUI app development after the complete lack of direction or coherence Microsoft has shown. Not to mention the irony of Visual Studio not having a GUI designer for anything except Windows Forms.
A lot of people complain about this, but there seemed to be a reasonable XAML designer when I was making my WinUI 3 app. I didn't really use it (my app was simple enough that hand-crafting the XAML felt worthwhile to ensure everything was nicely aligned and not full of any unnecessary designer gunk). So I suspect it does suck, since otherwise people would not complain as much. But one does exist.
Lazarus is crazy good, as is Delphi, if you can afford it. wxWidgets is also nice, without the licensing weirdness that is Qt.
Lazarus is probably the easiest way to make a lean and fast native Windows app without paying for tooling.
wxWidgets is just a wrapper around existing UI libraries; win32 on Windows, and Gtk/Qt on *nix.
Yes, as is the VCL that Delphi ships, along with the Lazarus component library which bases on Qt or GTK on Linux, and Win32 on Windows. It's the same sort of layer.
I’m still confused which frameworks are tied to which “visuals”. Ignoring the web-frameworks, do Win32 apps inherently look like Windows XP buttons or can they look more modern?
It might be nice if the article could add screenshots, a few of the Wikipedia links have a screenshot, but again I’m not sure if you’re limited to that UI or not.
I also like the carousel in the article showing the tray menus, but again not sure what they are each “built-with”.
From what I understand, Win32/MFC/WinForms inherently are stuck around Vista visuals, with no dark mode support. Win32/MFC also have no high-DPI support, so you get gross upscaling. (WinForms supposedly has some support for high DPI, but with many open issues. [1])
Now, I'm not 100% sure, since there are so many commenters in this thread saying "just use Win32/MFC like a real man". (Most of them ignoring the memory safety angle.) I might do a follow-up asking Claude to reproduce my UI in the various frameworks to test. But my strong guess is that we just have a bunch of HackerNews curmudgeons who are happy to foist pixelated Vista-era light-mode-only UIs on their users.
[1]: https://github.com/dotnet/winforms/issues?q=is%3Aissue%20sta...
>with no dark mode support.
https://learn.microsoft.com/en-us/dotnet/desktop/winforms/wh...
"Dark mode Windows Forms has fully integrated dark mode support.
Windows Forms for .NET 9 introduced preliminary dark mode visual styling, but in an opt-in preview mode where you had to suppress Compiler Error WFO5001 to use the feature. This feature is no longer guarded behind this compiler error starting with .NET 10.
The Application.SetColorMode(SystemColorMode) API is no longer considered experimental."
I think that would be a great article! For your specific app, I can see how the "super modern" sparse UI fits nicely, since the controls are nice and simple. However, for a more involved app knowing what possibilities there are to get the Windows 10 look would be nice.
I have 15 year old binaries made with WinForms that look just fine on Windows 10, and use native Windows 10-styled controls.
I wrote a Win32 app 20 year ago, but the limits to how it handles memory made things confusing when you loaded large amounts of data into the GUI.
I would say Java Swing is still the peak of GUI development. Works flawlessly at close to native speeds (GPU acceleration and all) on all platforms including Risc-V that did not exist when it was developed!
The JVM is the emulator!
Because I didnt see it already mentioned. Avalonia[1] and Uno[2] for C# are also really great if you want to write windows apps. I wrote some in Avalonia that worked incredible nice on Linux and Windows.
You dont have to use MVVM or AXML for example Uno allows for C# Markup[3] to be used instead or MVUX instead of MVVM.
I personally hate MVVM and AXML but you are not forced to use them.
For Avalonia I dabbled in creating my own replacement[4] for MVVM and AXML using Flecs.Net.
In Avalonia I created a tray icon for the trash bin. So I can see how big it is and clear/open it with a small menu[5].
Both Avalonia and Uno should at least be looked at when judging which framework to use. They are both quite mature and have many great controls and features built in.
[1] https://avaloniaui.net/ [2] https://platform.uno/ [3] https://platform.uno/docs/articles/external/uno.extensions/d... [4] https://github.com/AyanamiKaine/Ayanami-sTower/blob/main/Ava... [5] https://github.com/AyanamiKaine/Ayanami-sTower/blob/main/App...
I built multiple Avalonia apps with zero previous experience
- Windows 11 Hardening utility - made it because all existing ones are not updated to handle all the new AI telemetry + new updates + I made it differently and more powerful than anything that exists currently
- Windows Admin/ Security / Networking Utility built for my needs
- Windows 11 Anti Virus Nuker - Completely shuts off windows defender without disrupting system performance or zombie files
- and more
They are both mentioned in the article. But I appreciate the extra experience and details, beyond what I got from browsing their landing pages and GitHub repos.
> One might think that an advantage of controlling C# would be that Microsoft has carefully shaped and coevolved it to be the perfect programming language for Windows APIs. This does not appear to be the case.
I think they spent all their mana for that on pre-.NET Visual Basic and then had nothing left.
When I tried to release a flutter app via exe installer, google drive said it was a virus but it otherwise installed just fine in windows 10/11. I'm doing the same thing for msix for now. But when I searched for certificates I could only find closer to $200/yr and you need to load it in the latest $100 yubikey due to the fips requirement. I didn't realize that CAs dont let you just get the private/public key files any more. Only distribution method is hardware based fips key. I've given up entirely on code signing since I only made a single open source project for amateur radio.
> knew I wanted to use the latest and greatest first-party foundation. That meant writing a WinUI 3 app, using the Windows App SDK
No it doesn't? That's "the latest", but not "the greatest", and as "a Windows guy" you should know both the meme "wait until sp1" and the principle behind that about the inverse relationship between the two factors in that phrase
> what is the point of using Microsoft’s latest and greatest, if half your code is just interop goop to get at the old APIs?
Good point! Don't, wait until they realize their newest toy isn't popular enough, throw it away and create a new one - use that instead!
> One might think that an advantage of controlling C# would be that Microsoft has carefully shaped and coevolved it to be the perfect programming language for Windows APIs
No one using anything of theirs would ever think that!
All my work experience with guis was mfc. And all modernizations were web based. The in betweens are usually not considered worthwhile.
But imgui is a breeze of fresh air for internal stuff
One of the challenges with the older methodologies was getting the damned things to look good. I distinctly remember with WinForms having to use DevExpress to get the theming to look moderately modern.
Bit I still never bothered with the later approaches because it looked like I was going to lose out on speed and ease of development. WinForms may have looked ugly but you could bang things together pretty quickly.
I feel like WinForms was peak (because it was close to Delphi) and it went downhill from there.
IMO WinForms didn't manage to reach even Delphi 2's state, so i'd say it is far from peak considering the improvements later Delphis (and now Lazarus) added. It was abandoned too soon.
I meant peak for MS.
> It was abandoned too soon.
This is probably a recurring theme for MS UI frameworks.
It is not. Not to that extent at least.
I am developing Sciter[1] engine that works on all desktops: Windows, MacOS, Linux (3 distinct backends: pure X11, pure Wayland and GTK4).
Among all those, Windows API is still the most consistent and stable.
Whole of Windows functionality can still be accessed by plain C. For some things (COM) is better to use C++ but C works too.
Just in case: I am in this business for 20+ years.
[1] sciter.com
The only modern and battle-tested UI framework on Windows is WPF. Going for .NET Fremework 4.8 in the back is smoothest to avoid users needing to install runtime (comes with Windows), but if Microsoft ever decides to include one of LTS versions (NET8 or NET10) this recommendation would change.
Nobody likes web technologies for desktop except lazy developers who know only that and try to make everything fit their world. WinUI3 is so buggy that not even their UI controls samples app can run for more than 5 minutes without crashing.
Pinvoke is reality on Windows and it is fine. COM is garbage but that's what we've got to maintain compatibility across 30 years. Windows is held by duct-tape and chewing gum and that is just reality
Given the size of some Electron software, bundling TCL/Tk with IronTCL and TCLLib+TKLib weights 58MB and you can develop your own software with it, and that with the source of everything included.
And if you set a native theme for TTK in your code (literal two lines), your software will stop looking Motif-Industrial, the widgets will have the classic Win32 themes. It will look native from XP and up.
Looks like Tcl is still being developed, with 64 bit version released in 2024 [1]. How big is your software, is it mainly C code wrapped in Tcl for the GUI?
[1] https://en.wikipedia.org/wiki/Tcl_(programming_language)
What kind of experience you have is about what kinda of developer you are. If you're the kinda programmer who wants to use all the newest versions of stuff because you think it'll be better, then you'll be in an endless quagmire of hitting limitations.
Most web programmers fall into that bucket for example. If you're the type to recoil at XMLHttpRequest, reaching to fetch or other even newer stuff. Then you'll balk at Win32 and be in a never ending pit of new Windows technology. I'd argue this is true of basically all new software. It's worth starting with whatever the oldest most compatible version of your target and ignoring the advertising and hype.
I use WTL with modern C++ (smart pointers, Microsoft WIL for scoped handles is a good point) for suitable Windows native apps. Yes, this seems to be old but it’s the only thing that fits my mental model as a 30 year old Windows programmer as you.
Best framework for this is Qt.
I've recently discovered FLTK: https://www.fltk.org/doc-1.4/intro.html
Haven't used Qt in a while, but at first glance, seems simpler: https://github.com/fltk/fltk/blob/master/examples/menubar-ad...
FLTK is great at being fast and light, that’s about it. It’s kind of cumbersome to use but honestly does what it says on the tin. Highly recommend for smaller use cases but can’t imagine using on a large project. I used the rust bindings which are well maintained.
Yeah for my work, legacy Win32/WinForms/WPF codebases tools are kept maintained as-is, but new tools are usually written in PySide6 (QtWidgets or QtQuick) and it's worked out really well (other than bundling/distribution being tricky for big apps)
And Lazarus/FPC.
MFC is rock solid too
WTL and ATL also, especially if you need to do com stuff
You will need it, because since Windows Vista, most new APIs are COM based, as they redid Longhorn ideas in C++ instead of .NET, and WinRT also builds upon it.
Classical Win32 C API surface, with some exceptions, is mostly stuck in Windows XP view of the world.
Microsoft has been butchering software development for decades and maintaining dominance through pure business, legal and government connections. It's become like Oracle.
Developers being forced to use horrible Microsoft products is the logical consequence of that.
As a software engineer, most of my job exists to give credibility to the narrative that Microsoft is useful... And I don't even work for Microsoft. It's clear that there are deals behind the scenes which force many large companies into Microsoft contracts. The engineers have to work with what they get and pretend the tech is OK but behind the facade, it's clear from the jokes on the Microsoft Teams chats that they think differently!
Why do people conflate "writing GUI apps" with "native app development" and "low level access"?
If you need low level access to the operating system and the hardware, you need Win32, so you need C/C++. And there's no way around it.
Expecting .NET apis to give you low level access in Windows is akin to expecting Go apis to give you low level access in macOS or using Haskell to interact with hardware on Linux.
Thank you for the detailed write up.
I’m was thinking about building native windows UI, wrapping around cross platform library written in swift. I did not know it was that messy and complicated.
Small nitpick. 4.8.1 was .NET Framework, which is a totally different beast that .NET (1 through 10). .NET Framework was heavily dependent on Windows, while .NET (1 through 10) are the newer OS independent system. It's not that they've forgotten to update the system .NET, its that that product is in long term maintenance only mode and modern .NET is a totally different software.
For anybody interested in the use-case underlying this article, mainly disabling peripheral displays in a multi-monitor setup, this is already built into Windows via the Win+P hotkey. It's also possible to turn off all displays by reassigning the functions of the computer's physical power/sleep buttons in Control Panel -> Power Options.
This is not the same at all, you are pretty much turning the screen off with that
Isn't that the point? What's the benefit of blacking-out a display instead of putting it in no-signal standby?
This is covered in the article:
> Turning them off will cause Windows to spasm for several seconds and throw all your current window positioning out of whack.
The more I learn about all the frameworks for Windows, the more I believe they should have just switched to web development. Make it native to the platform, fork Electron to enable Edge runtme with some shared resources, and then they'd have a more thriving app ecosystem at least.
I used to code Win32 around the Win 95/98/2000 era (my first VC++ was 1.0 for 16bit) but switched to BSD and Linux around 2000 and haven't looked back. I avoid Windows as much as possible and did learn about .NET and how slow it was but I'm a bit shocked that Win32 is still a thing and still being recommended. Sort of makes me happy and sad at the same time...
.NET is blazing fast by modern standards (given that the typical app experience these days is Electron, meaning Node.js).
"Left behind", the most common phrase used when describing Windows Native programming...at least anecdotally.
Still remember the days of writing apps for windows phone using c# and XAML. Good old times but no definitely don’t wanna go back.
TCC supports win32 and is less than a meg download and as an added bonus supports linux very well thanks to wine.
The problem is not new: https://devblogs.microsoft.com/cppblog/mfc-update-powered-by...
WinForms forever :evil:
come back home Delphi 7, all is forgiven
It seems that peak native Windows dev tools were Delphi 7 and VB6. It's a tragedy that something at least as good as VB6 is not still developed and supported by Microsoft.
There's nothing as good as VB6 that's developed and supported by *anyone*. It's not a Microsoft only phenomena.
I think programmers started wanting "real" languages (notice the quotes), and henceforth got more complexity and things take longer, although with GenAI, we may be back to the "draw as screen and do this" that we were with VB6. Just now the source generated should be considered the object code, and the prompt is the new source (at least for those types of apps)
I'm not sure how you define "native" here. If you mean native widgets then WinForms does what you want, is still fully supported, works on modern .NET versions, and Visual Studio still has all the GUI designers etc. WinForms is very obviously a calque of VCL, as well, so it can do everything Delphi did, but better.
If you mean native code then VB6 doesn't belong in this category (even if you compiled it to a standalone .exe it was still effectively bytecode).
I think WinForms with C# or VB is as good, if perhaps not as fun or approachable.
>Displaying a tray icon with a few menu items: not available. Not only does the tray icon itself need P/Invoke, the concept of menus for tray icons is not standardized
Having never written Windows apps, I am surprised to learn how disorganized and chaotic this all is.
I got burned out of windows development. I was building a desktop app and switched from WPF to UWP because I wanted the new fluent design widgets, but then Microsoft deprecated it towards WINDOWS UI but it didn't have the same features than wpf.
It's always about the abstractions which try to cover the underlying mechanisms but not always can do it. The same with any programming, like named pipes for example. However I need to tell you that
1. Wow you have great knowledge of windows. Congratulations
2. Boy windows API is a mess.
Seems to me that really the simplest solution to authors problem is to write C++ safely. I mean...this is a trivial utility app. If you can't get that right in modern C++ you should probably just not even pretend to be a C++ programmer.
Just write C++ safely! Why didn't we think of that?
C++ is hard to get safe in complex systems with hard performance requirements.
If the system is simple and you don't give a shit about performance, it's very very easy to make C++ safe. Just use shared_ptr everywhere. Or, throw everything in a vector and don't destroy it until the end of the program. Whatever, who cares.
Yeah he literally answered his own question and then used a random excuse for not going with the option.
*has been for 20+ years
Meanwhile editions of Gnome come with Gnome Builder and Flatpak has solved the distribution problem. Things are so much better today on Linux than most people who have used Windows will even remember.
I wonder if Unity (the game engine) actually has a sneaky potential here. It’s cross platform, fast, and maybe just maybe less bloated than carrying around an entire browser like Electron?
Unity's 2D UI stuff is very poorly designed, with lots of edge cases where auto-calculated fields can hit a divide-by-zero issue and then become unrecoverable because the value is now NaN which can't be auto-calculated back to a number.
I think Godot is a possible contender as well. There are a few non-game applications made with it, and they've recently added a docs page tailored to non-game application development: https://docs.godotengine.org/en/stable/tutorials/ui/creating...
Not sure about Unity, bot Godot is already used to build tools, like Pixelorama (pixel art graphics editor, a bit akin to Asesprite), RPG In A Box (game engine targeted for RPG games), Bitmapflow (tool to generate in-between animation frames), and probably more I don't know about.
Well, if I remember correctly, the Godot editor is written in Godot.
Godot is written in C++ It may have some GDScript in there, but I don't think so. The sourcecode is available: https://github.com/godotengine/godot
The C++ code there (at least in the editor directory) initializes and configures godot ui components that the editor is made of
Just use Qt. Native, cross-platform, works like a champ.
Cross-platform and native never works well.
Qt works very well because it's well thought out software. There's a lot of really shit solutions out there, but basically nothing touches Qt.
Nothing is perfect, but it works well in my experience.
You’ve never used Qt
Speaking from personal experience, Godot has the sneakiest potential. It has all the UI components and flexible layout containers you could ask for, a signaling system that lets you put the methods from less relevant components in the scripts for more relevant ones (making for a more compact project), and you can also manually compile slim template builds for cleaner distribution. There's a future there.
There are already tools made in Godot, including the godot editor itself. This page has some of them: https://gamefromscratch.com/godot-developed-non-game-applica...
What’s the story for accessibility and non-LTR text boxes?
Flutter is probably better suited for apps
Recently started making a Flutter app and it is fantastic to use, cross platform to everywhere, dart is a very nice language to.
What's the accessibility story like? Do Unity applications work well with screen readers?
Sure but different target market.
CRUD apps are non-trivial.
If Unity were to ship platform native replacement for WPF equivalent (hell or even winforms) it would become a really enticing app development platform.
> CRUD apps are non-trivial.
Aren't these pretty much the most trivial UI apps possible? E.g. compared to other native apps like Photoshop, Blender, Visual Studio or Office, CRUD is mostly just about banging together custom UI frontend for a database.
Unity's editor is implemented in its own (old) UI system, same with Godot, so in both engines it's possible to create 'traditional' non-game UI applications.
Unity has a big runtime that needs to be bundled with it to run
Thanfully, you don't need to write p/invoke stuff yourself anymore. https://github.com/microsoft/cswin32 creates methods and all related structs for you. It's also AOT compatible (if you specify it). It works for calling C and COM functions.
I mean, not like this brings Windows development anywhere close to "modern", if anything, it feels like you're moving into the opposite direction, but at least this solves the "The modern APIs don't provide the specific functionality I need" problem that plagues all of Microsoft's "nice", "modern" abstractions…
This is discussed in the article, including why I tried it and ended up reverting to normal P/Invoke.
2026 and people are complaining about the oldest, most stable gui api available, seems right on target
Honestly, if app complexity and size justifies few more MBs of bloat, Python + Pyside is the best option to make UIs, be it Win-only or cross-platform. You get the power of Qt with stuff like hardware-accelerated QGraphicScene exposed via nice, concise, high-level language that also gives you access to some best-in-class libraries. Performance hit is negligible if you know what you are doing (what may not be the case in 2026 and age of vibe-coding).
Unless, of course, you tend to whine about "complex licensing", i.e. people wanting to make money as you do.
This all seems like a direct result of measuring employee performance using "impact".
Unpopular opinion: FreePascal is perfectly capable of all that and produces tiny native executables. Their clone of Delphi's Visual Component Library - Free Component Library - is rich in features and don't change every year like those Microsoft toolkits.
I needed recently to make an exe that would work on anything from 32-bit Windows 95 up to and including Windows 11 (to accommodate some old machines on production lines), and the only language that made that easily achievable was FreePascal. I think it can also handle the older Windows NT if that is a requirement. There are lots of architectures supported with a single code base.
But for many the Pascal language is just to be laughed upon. Well, I make fast money using it and laugh from JavaScript.
Steve Gibson, Gibson Research.
https://www.grc.com/freepopular.htm
Just scroll down the page and look at the size of the completely self-contained executable programs. THIS is what Win32 is capable of. Something we always had with Win32 that was thrown away with .Net and C#.
And _please_ just spare me your opinions of how Steve Gibson "doesn't know anything about security". That's not what's important here. What's important is how freakin' small his full-on GUI stand-alone executables are.
EDIT: Just noticed this on his page.
Total Historical Count of files downloaded from this page: 52,292,601
.NET runtime has been bundled with Windows since Win2003.
And if you don't have to drag the runtime around, .NET binaries are even smaller than that, since the bytecode is more compact.
TCC is less than a meg to download supports win32 very well and as an added bonus created executables run fine under linux wine.
Why wouldn't it?
You missed something.
With Delphi creating of Native Windows Desktop Applications is a piece of cake (also does MacOS, iOS, Android and partially Linux). Yes it is by now obscure and expensive tool but I still use it to maintain my existing native GUI desktop applications. It is incredibly easy to use / develop with and single exe no dependencies deployment mode is superior. Compatibility between Windows versions is stellar as well.
There is also an opensource version of Delphi called Lazarus which is way less polished.
Interestingly, no mention of WTL
Ahah, I knew I missed one!
I originally had ATL in there, but my proofreading squad (Claude and ChatGPT) told me that ATL was a more niche thing for COM, and looking at the Wikipedia article I was convinced they were right.
But WTL was what I was thinking of---the step between the MFC and .NET that I forgot.
WTL was never a "step between the MFC and .NET" in any meaningful sense. It was more like a very lightweight subset of MFC+ATL, never officially supported or recommended, just something that Microsoft used internally that it decided to publish and then community picked up.
> but my proofreading squad (Claude and ChatGPT) told me
With all due respect (seriously): fuck off man
This is why you don’t use these stupid fucking tools for this
> This is why...
...but they were correct. The GP just didn't remember the proper name and asked about a different thing.
There seems a lot of conflation between GUI frameworks and interacting with the OS in this article.
[dead]
[dead]