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.

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.

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?

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 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.

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.

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.

> 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.

> 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.

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…

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

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.

TCC is less than a meg to download supports win32 very well and as an added bonus created executables run fine under linux wine.

TCC supports win32 and is less than a meg download and as an added bonus supports linux very well thanks to wine.

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...

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.

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?

> 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.

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.

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.

"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.

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.

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.

> 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.

> 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.

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.

Lazarus is crazy good, as is Delphi, if you can afford it. wxWidgets is also nice, without the licensing weirdness that is Qt.

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.

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”.

*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.

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.

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.

This all seems like a direct result of measuring employee performance using "impact".

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.

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…

Best framework for this is Qt.

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.

WinForms forever :evil:

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 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?

come back home Delphi 7, all is forgiven

There seems a lot of conflation between GUI frameworks and interacting with the OS in this article.

>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.

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.

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.

Interestingly, no mention of WTL

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.

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

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.

[dead]