Comment by pjmlp
5 hours ago
I already mentioned in a few places, this is useless, probably a team having to meet some KPIs, OKRs, or whatever to show their impact value on the next evaluation cycle.
Anything related to WinUI, WinAppSDK, CsWinRT, C++/WinRT is a sea of bugs, broken tooling, and unfulfilled promises, that no one should bother with.
Easily confirmed by going into their public repositories over at Github, or community session recordings over at YouTube.
For those using .NET, keep using Windows Forms or WPF, or reach out to Avalonia and Uno.
For those using C++, the aging MFC has much better tooling as incredible as it sounds, or use instead VCL/Firemonkey (C++ Builder), Qt, wxWidgets,....
For anything else, whatever bindings are available on top of plain Win32.
Sounds very negative, but I can confirm - it's the truth unfortunately.
I'm developing windows desktop apps since nearly 30 years now and tried mostly everything Microsoft has thrown at us - Win32 - WinForms - WPF - WinJS - WinRT - UWP - WinUI - MAUI - not sure if that was all - and Win32 always wins. Everything else is incredible broken and stops being supported in such a short time. It's a shame really.
It is what happens when passionate advocates feel betrayed by all the mismanagement that has happened since Windows 8.
I switched from someone that was kind found of WinRT, as what .NET 1.0 should have been, AOT compiled languages built on top of COM, improving the VB 6 experience, to someone burned out with the experience, back into Web development and distributed systems.
However, Microsoft keeps talking as if everything was tiptop, and that angers me thus I keep track of how bad things still are, and spend time making others aware of the false promises.
For example, I bet no one is aware that C++/WinRT is actually in maintenance, and the team responsible for killing C++/CX, is now having fun with Rust on windows-rs.
Yet Microsoft talks about using C++ to develop WinUI applications, as if the tooling was at the same level as using C++ Builder or Qt/QtBuilder.
I jumped the train when they crashed the Silverlight carriage.
Not to mention, the code is quite obviously vibeslop...
Why are they building CLIs and tooling in this way? Don't they realize that shipping low quality code will eventually hurt them more than whatever UX benefits it gives developers? People will give up on using this quicker than the attention you get from launching it.
Just one example that shows how little they care, since the commit message is obviously written by an agent/LLM, the code surely is as well: https://github.com/microsoft/winappCli/commit/3dead8ed147917...
I think when people heard that Claude Code is now writing itself, they thought "we could do that" and this is their attempt at it. Different people, different results.
I made a small suggeestion in VS Code's Github repo.. it got assigned to a GH Copilot bot, that did the implementation, manually added a couple weeks later and now in release... I was a bit impressed, but then started looking at some of the configs and workflows for .githug, it's impressive but I can't help but think, what a pain to setup/configure.
> when people heard that Claude Code is now writing itself
They should have inspected the code of Claude Code first, and then make a judgement, because these agents are not ready to just write themselves without proper engineering-oversight. I'm guessing the technical debt and bug count will keep increasing until they realize this.
So you're saying that Winapp doesn't kick the llamas' ass?
I read it as Winamp myself at first pass. I don't care as much for the UI today, but really did like their Android app, and am sad it's no longer available. One of the better audio apps I'd tried on Android.
I have no clue about GUI programming, but I eventually came to the conclusion to use Avalonia after even my LLM told me to do it.
If you're using C# this is pretty much your best bet IMO... I think MS really missed the boat by not having a Linux target for MAUI, even if it was just passthrough to GTK (Or Qt).
I don’t rally understand what what they are thinking but it seems MS has given up on windows desktop dev. Even Office is now moving to web technology even if it means to make these apps worse.
Works for me, since I can use it in a browser in Linux... Though some of the new features really tick me off.
Besides Visual Studio (WPF), much of Office 365 (or whatever they renamed it to) is using either React Native (MS edition) or Electron (Web Tech) so their latest code is a mixed bag.
Raw win32 isn't actually that bad now that we have LLMs. I don't even use the cswin32 project anymore because chatgpt is good enough today. I think win32 from modern C#/.NET is a very happy blend when you need that low level access.
What's the best way to get into MFC or Win32 in current year? Is there a canonically best book or tutorial for those wanting to learn?
Same as always, get one of the old books, the good ones back in the day.
Programming Windows, by Charles Petzold
Programming Windows with MFC, by Jeff Prosise
COM / DCOM Primer Plus, by Chris Corry Vincent Mayfield John Cadman
Thank you! Despite being older than me, those books look really thorough and well written. It's sort of crazy that these APIs are still as usable today as they were in 1998
What are Microsoft's own Office Apps built on?
Their own custom framework built on top of Win32, nowadays they also use React Native, and Webview2 with React to share code with the Web versions.
The Web versions also consume C++ via WebAssembly, the mobile versions are a mix of the platform languages + C++.
There are some CppCon talks about how they use C++ in Office.
Building apps on Windows feels like a big PITA to get into. The amount of different frameworks and libraries to work with is perplexing to a new developer and I really do not want to use electron or React or even Qt.
Where do I start? Do you have a compiled version of some information on this?
4 replies →
Looking back on the history of Windows, one of the things that most stands out to me as a user is the utterly insane UX around the C++ redistributable. They really should've figured out a better solution than having every single application ship their own copy along with a separate installer, and then having the installer run always because the developer cannot be sure if it's installed correctly. As I understand it, this might still be a problem with the latest version? If someone like Steve Jobs had been responsible for Windows he would've fought with managers, lawyers, and engineers until the problem was resolved.
This is absolutely baffling that you can't just make an api request and windows deals with installing those redistributables, must have seen that installer pop up close to 80 times in my life. I understand why maybe it was that way pre-internet but really they should have rolled it into windows and made it automatic by now if their dev tools team and windows team can't figure out how to just compile software on their own OS without shipping another bundle beside it.
The newer .msix apps are supposed to be able to handle this, and WinUI3 is supposed to come with a package-dependency that uses the package system to automatically make sure you have the 100+MB library up to date. However, this is the new cool system that nobody uses and doesn't help ordinary devs. They should just ship it in the OS.
> the utterly insane UX around the C++ redistributable
It could be worse—it could be Linux, with no forward compatibility. The VC/C++ redistributable means that applications can be written on modern Windows that targets much older Windows, by simply providing a sidecar installer that brings with it a newer C/C++ standard library. This situation is basically impossible on Linux without messing with Docker.
> means that applications can be written on modern Windows that targets much older Windows
What older windows? Everyone consumer (who are all on forced updates) has to deal with this for the benefit of the small minority on older versions of windows which are probably systems you're not installing new software on anyway.
> Anything related to WinUI, WinAppSDK, CsWinRT, C++/WinRT is a sea of bugs, broken tooling, and unfulfilled promises, that no one should bother with.
Can you add MAUI to this list? Please and thank you.
Sure, I keep forgeting it even exists.
Or just plain Win32, no wrappers! Maybe with coding agents it can have a renaissance.
> plain Win32
Plain Win32 needs a renaissance. I worked with it and felt like a wizard. Message boxes, dialogue boxes, wizards, hammered out in pure C++. Combined with the Windows Implementation Library[1] I was writing fast, modern code.
[1]: https://github.com/microsoft/wil
As side note, WIL was originally introduced for writing drivers in C++ in kernel mode, then expanded to support other workloads on userspace.
Here is the original announcement,
https://community.osr.com/t/the-new-wil-library-for-c-code-i...
Annoyingly many of the new features are WinRT only, so you have to deal with that horror.
I'm a big fan of the MFC/WinForms era stuff myself, but it has one crippling limitation: it doesn't handle display scaling very well at all.
Only AI stuff, there is hardly anything else that depends on WinUI/WinAppSDK.
There are Win32 APIs for HiDPI configuration, the issue is that it isn't automatic, it needs to be on the app manifest or called explicitly, and handle the events for resolution changes.
2 replies →
I have been using WinRT and Win32, and I find WinRT much more pleasant to use
1 reply →