Windows native app development is a mess

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?

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

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

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?

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.

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

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.

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.

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.

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.

Best framework for this is Qt.

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

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?

WinForms forever :evil:

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

come back home Delphi 7, all is forgiven

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.

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.