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?
user____name 2 hours ago [-]
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.
dgxyz 51 minutes ago [-]
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.
lylejantzi3rd 37 minutes ago [-]
But, why? It's been 30 years. You'd think somebody would have figured out how to make a decent GUI toolkit or framework.
dgxyz 16 minutes ago [-]
We just built layers of shit over the ones we have.
cosmic_cheese 2 hours ago [-]
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.
kageroumado 36 minutes ago [-]
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.
steve1977 36 minutes ago [-]
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.
762236 59 minutes ago [-]
This is such a wonderfully beneficial comment to the HN community. It should get an award.
samiv 2 hours ago [-]
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.
raw_anon_1111 55 minutes ago [-]
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)
mcswell 59 minutes ago [-]
Repeat after me: New! Fresh! Clean!
jordand 2 hours ago [-]
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.
cv5005 2 hours ago [-]
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'.
jordand 2 hours ago [-]
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
Dwedit 56 minutes ago [-]
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.
raw_anon_1111 54 minutes ago [-]
That sounds like the same ugly hack that caused programs not to be “32 bit clean” back in the day for Macs
mschuster91 2 hours ago [-]
Doesn't WINE have pretty decent documentation by now from all the reverse engineering?
jordand 2 hours ago [-]
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
sourcegrift 2 hours ago [-]
Wine cannot even install office 2014. It's not really as food as some claim sadly.
anthk 2 hours ago [-]
Lutris can up to 2016.
dgxyz 48 minutes ago [-]
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.
raw_anon_1111 2 hours ago [-]
And the 12 different ways to define a string depending on which API you call
lucianbr 2 hours ago [-]
How does it look? I mean, what do the widgets look like?
cv5005 2 hours ago [-]
This was an MFC project, so your old standard win32 common controls that looks the same since 98 or so.
LAC-Tech 2 hours ago [-]
Winforms?
lol at them still bekng the best option. so much wasted effort trying to replace them
pjc50 2 hours ago [-]
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.
HauntingPin 2 hours ago [-]
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.
bob1029 7 minutes ago [-]
I don't think it's abandoned and it looks like there is a lot of activity around the high DPI concern.
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.
troupo 16 minutes ago [-]
Most apps at the time managed that quite successfully. IIRC Adobe Photoshop was an MFC app. There was no other API but Win32 API.
wolvoleo 2 hours ago [-]
> 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.
aaomidi 1 hours ago [-]
When Microsoft themselves use electron to develop apps what expectations can we have on other devs?
Sindisil 54 minutes ago [-]
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?
sylens 2 hours ago [-]
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
jayd16 25 minutes ago [-]
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.
c-linkage 1 hours ago [-]
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.
domenicd 58 minutes ago [-]
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.
rwmj 1 hours ago [-]
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?
Nice, I didn't know there was a free software version of Delphi nowadays.
mellosouls 44 minutes ago [-]
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.
intrasight 2 hours ago [-]
"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.
fsloth 2 hours ago [-]
"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.
p0w3n3d 22 minutes ago [-]
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.
ashwinnair99 2 hours ago [-]
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.
Smalltalker-80 2 hours ago [-]
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...
pdpi 2 hours ago [-]
> (Win11 reverts).
I must've missed that one. What did they revert?
lpcvoid 2 hours ago [-]
It doesn't matter - what Microslop says and what they do are traditionally very distinct things.
"File explorer launch experience" -hard to tell if this is satire…
mschuster91 2 hours ago [-]
> 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.
PaulKeeble 2 hours ago [-]
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.
ozim 2 hours ago [-]
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.
Boxxed 2 hours ago [-]
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.
IlikeMadison 46 minutes ago [-]
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.
pier25 2 hours ago [-]
Isn’t Microsoft also using React native for desktop stuff?
anthk 2 hours ago [-]
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.
ToucanLoucan 2 hours ago [-]
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”
samiv 2 hours ago [-]
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.
rwmj 57 minutes ago [-]
Just write C++ safely! Why didn't we think of that?
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)
madduci 2 hours ago [-]
MFC is rock solid too
adzm 57 minutes ago [-]
WTL and ATL also, especially if you need to do com stuff
anthk 1 hours ago [-]
And Lazarus/FPC.
lpcvoid 2 hours ago [-]
Lazarus is crazy good, as is Delphi, if you can afford it. wxWidgets is also nice, without the licensing weirdness that is Qt.
steve_taylor 2 hours ago [-]
Lazarus is probably the easiest way to make a lean and fast native Windows app without paying for tooling.
LocalH 51 minutes ago [-]
WinForms forever :evil:
on_the_train 16 minutes ago [-]
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
bentt 2 hours ago [-]
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?
Vedor 2 hours ago [-]
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.
If Unity were to ship platform native replacement for WPF equivalent (hell or even winforms) it would become a really enticing app development platform.
flohofwoe 1 hours ago [-]
> 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.
pier25 2 hours ago [-]
Flutter is probably better suited for apps
jordand 2 hours ago [-]
Unity has a big runtime that needs to be bundled with it to run
moron4hire 2 hours ago [-]
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.
irishcoffee 2 hours ago [-]
Just use Qt. Native, cross-platform, works like a champ.
netbioserror 2 hours ago [-]
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.
tomcam 10 minutes ago [-]
What’s the story for accessibility and non-LTR text boxes?
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.
whobre 2 hours ago [-]
Interestingly, no mention of WTL
domenicd 2 hours ago [-]
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.
livinglist 2 hours ago [-]
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.
anthk 2 hours ago [-]
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.
Rendered at 15:13:04 GMT+0000 (Coordinated Universal Time) with Vercel.
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?
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.
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.
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)
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.
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.
lol at them still bekng the best option. so much wasted effort trying to replace them
https://github.com/dotnet/winforms/issues?q=is%3Aissue%20sta...
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.
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?
It's another example of how they have completely abandoned any attempt at providing a good user experience across their products
It's just a bad idea. Today we just pack in the DLLs and it just works.
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.
I don't think the rapid development cycle argument holds water, when they're shipping a new WebView2 every month.
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?
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.
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.
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.
1. Wow you have great knowledge of windows. Congratulations
2. Boy windows API is a mess.
I must've missed that one. What did they revert?
But in case you want to read yourself: https://blogs.windows.com/windows-insider/2026/03/20/our-com...
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.
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.
Open? You wish.
>and not locked into any single big tech.
DRM and propietary cody tells me otherwise.
Haven't used Qt in a while, but at first glance, seems simpler: https://github.com/fltk/fltk/blob/master/examples/menubar-ad...
But imgui is a breeze of fresh air for internal stuff
Well, if I remember correctly, the Godot editor is written in Godot.
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.
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.
Hobby projects should not be built on a platform that is constantly changing underneath.
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.
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.