> It feels like there was kind of a sweet spot before GPUs took over everything where there's software like demos and games that likely don't require a lot of Windows API and are possibly old enough to be possible to emulate on one of these fast new Macs.
I'm reminded of FamiTracker, one of these traditional Win32 (MFC eew) apps which has managed to survive into the modern day with a technological stack largely unchanged, outside of newer compilers and me replacing DirectSound with WASAPI in Dn-FT. But even in simple apps there's a surprising amount of complexity, ranging from threading deadlocks from poor architecture, to a Wine bug causing the window to fail to redraw when resized (https://bugs.winehq.org/show_bug.cgi?id=52903, related https://bugs.winehq.org/show_bug.cgi?id=52515).
I’d imagine there might still be a surprising number of MFC apps still in circulation.
PuTTY, for example, uses MFC (I’d completely forgotten MFC was a thing until I had to write a custom port of PuTTY for a previous company ~5 years ago).
The issue for a lot of devs is if you want to use any of the new stuff you can't ship a single file portable executable. You have to do a packaged installer. So MFC warts and all can still be faster and lighter than other options unfortunately. I was hoping WinUI3 would have a way to do single file delivery but it doesn't as far as I can tell.
For GUI things, I prefer a nice installer that will place the files in a sensible location (Program Files) and that will give me a shortcut in the Start Menu, I don't need a single file - and I suppose most users are likely to misplace the single executable or keep it in the Downloads folder forever.
Also, what counts as a single file? You can ship a (modern) C# app as a single-file executable. It will be hundreds of megabytes, but to the user, it's just a single file.
A nice installer is ideal, but more work to setup I think (I've never figured out how to write an installer so far). And I want the ability to download many versions and put them side by side for eg. running old versions, or bisecting bugs.
In my case the app in question is about ~6MB and an occasionally used utility, I could make a setup version that dynamically loads things... but why? Most users would prefer to just use it, delete it, and if they need it again grab it again.
Oh I've had so many nightmares trying to extract the underlying files from Inno Setup installers. 7-Zip doesn't work, innoextract and such is fiddly to find and IIRC doesn't work 100% of the time (forgot).
In fact, I just upgraded an MFC music application[0] to VS2022 and 64-bit this year, marking the first release in 15 years.
I'm not a Windows developer, and had to learn it while working on this upgrade. The MFC documentation has clearly atrophied, but has far as I can tell, there's also not blessed upgrade path for C++ applications.
There is C++/WinRT + WinUI 3, but looking at the screenshot that will pretty much require re-designing the whole UI so it's not going to be a simple upgrade.
It's a technical application, so I'm not entirely thrilled by doing that. I just looked for documentation to replace a popup or preference window with WinUI 3, but didn't see anything that made sense for me.
I'm reminded of FamiTracker, one of these traditional Win32 (MFC eew) apps which has managed to survive into the modern day with a technological stack largely unchanged, outside of newer compilers and me replacing DirectSound with WASAPI in Dn-FT. But even in simple apps there's a surprising amount of complexity, ranging from threading deadlocks from poor architecture, to a Wine bug causing the window to fail to redraw when resized (https://bugs.winehq.org/show_bug.cgi?id=52903, related https://bugs.winehq.org/show_bug.cgi?id=52515).