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.
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.
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.
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.
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.
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.
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.
> 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.
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.
For those unaware, the current recommended way to develop "native" apps for Windows is to use WinUI3, distributed with the WindowsAppSDK.
Unlike regular Windows SDK, which lets you make use of the functionality provided by the OS, the WindowsAppSDK is entirely separate from the OS and requires the installation of a separate runtime on the user's machine. It also requires installing nuget packages on your machine to use it so good luck if you'd rather use straight CMake instead of Visual Studio.
As far as I can tell, there's no backwards or forwards compatibility, so the end user has to install the specific version of the SDK your app uses, or you need to bundle all the hundreds of DLLs with your app yourself.
A sane person might ask why not just use Qt (smaller distribution!) or Electron (about the same size) at that point, since they're cross platform and you can easily get fluent themes that look the same as WinUI3?
As far as I can tell there's no sane negative answer to this question. It's not like your app's "fluent theme" will be updated alongside the OS, it's no different from Qt or Electron in this regard.
There's no reason to do "native" windows development anymore, unless you mean using raw Win32 with no dark theme or a custom UI built on Direct2D/3D/Write. And if you are doing that, there's absolutely 0 reason to use this CLI.
Couldn't this "dark theme" stuff be mapped onto the user-configurable Win32 color schemes that have been there since the beginning? Did Microsoft break it in Windows 11?
If you use classic unstyled Win32 controls (Windows 95-2000 style) then you can do that. If you use uxthemed Win32 controls (Windows XP onwards) then there's no official dark theme support.
Well, was. Then Facebook AI made a side-step, and stopped focusing on downloadable LLM models, and Ollama is now trying to squeeze their users so they can show profits. r/LocalLlama is also a former shadow of itself, with the top moderator trying to move the community off reddit.
Seems Llamas will disappear as quickly as they became trendy.
I read though the GitHub readme but I'm still unsure what "new" this brings this brings to the table. It seems like a thin wrapper over existing tools. Since Microsoft rarely deprecates and removes anything, this feels like just another unnecessary complexity layer.
I'm not a traditional app dev on Windows though, so I'm likely missing something. For those of you who are more familiar, what about this are you excited about?
It is, but it's like "dotnet new" templates: a means of getting to a working minimal setup that jumps through the Microsoft hoops for you. MSIX and Package Identity are definitely headaches to get set up.
Yes, Package Identity was the bane of my existence for a while. It's wild how MS gated important APIs behind it and then made it so difficult+impractical to work with (I honestly think this is a large part of why WinRT was mostly ignored by developers).
I've moved on, but this looks like it will at least fix some of the paper cuts.
They must be either incapable of binging for matching names, or its a sneaky strategy to bury, by influence, the existing winapps project https://github.com/Fmstrat/winapps
I reckon that the majority of the HN audience is into older (perhaps more graceful) working technology despite all the fanfare that newer, shinier stuff garners.
> I wonder what would be cutoff age for readers to read it correctly, I guess under 30 read it correctly, and over 40 will many read it as Winamp
I am 17 and I wasn't wearing my glasses and I was really speaking winamp until I read your comment then scrolled back again to realize it was winapp
My bet is that I spend time on HN so I knew what winamp is in more detail but if say friends my age read it & say they use tiktok more, I would say that they wouldn't call it winamp but winapp
So I guess I might be one of the few exceptions but I feel like people on HN are much more likely to read it as winamp than not & age might not be thaaat big of an impact (atleast on HN)
I'm already sold to Claude Code for Windows Desktop development.
Couple of months ago I used some shady C# SDK to build an implementation that interfaces with a very specific hardware component. My only option was Windows Forms, which I don't love very much but I have worked with extensibility in the past.
I did not have a lot of faith, because of how weird it feels to ask an LLM to work with a design.cs file, but what I did was just sketch all the design and let Claude do the logic with certain specification on how I wanted to corral the code... App was flawless in about 2 days of work. It's in production now with zero faults.
So, hard to now give this a shot, I already got my go-to tool. Even for something has arcane and obscure as Winforms.
this looks very plainly like "oh shit, devs are having a really hard time actually integrating with our AI services! That must be the only reason we are seeing adoption so slow. quick - throw a wrapper around some boostrappers that can get a green field project prepared for integration with our AI services (and whatever else can be done when you get that set up)."
Ask the marketing department that destroyed one of the most famous brands on earth, MS Office, and renamed it to "Microsoft Copilot 365 app": https://office.com
It's perfectly clear: if you need to run a Windows app on another Windows PC, you just open the Windows app store on your Windows PC to download the Windows app Windows App, a Windows app that lets you connect to and run Windows apps on other Windows PCs.
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.
1 reply →
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.
> 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.
So you're saying that Winapp doesn't kick the llamas' ass?
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.
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.
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.
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
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.
5 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.
> 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.
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
1 reply →
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.
5 replies →
But does it whip the llama's ass ?
For those unaware, the current recommended way to develop "native" apps for Windows is to use WinUI3, distributed with the WindowsAppSDK.
Unlike regular Windows SDK, which lets you make use of the functionality provided by the OS, the WindowsAppSDK is entirely separate from the OS and requires the installation of a separate runtime on the user's machine. It also requires installing nuget packages on your machine to use it so good luck if you'd rather use straight CMake instead of Visual Studio.
As far as I can tell, there's no backwards or forwards compatibility, so the end user has to install the specific version of the SDK your app uses, or you need to bundle all the hundreds of DLLs with your app yourself.
A sane person might ask why not just use Qt (smaller distribution!) or Electron (about the same size) at that point, since they're cross platform and you can easily get fluent themes that look the same as WinUI3?
As far as I can tell there's no sane negative answer to this question. It's not like your app's "fluent theme" will be updated alongside the OS, it's no different from Qt or Electron in this regard.
There's no reason to do "native" windows development anymore, unless you mean using raw Win32 with no dark theme or a custom UI built on Direct2D/3D/Write. And if you are doing that, there's absolutely 0 reason to use this CLI.
> Win32 with no dark theme
Couldn't this "dark theme" stuff be mapped onto the user-configurable Win32 color schemes that have been there since the beginning? Did Microsoft break it in Windows 11?
If you use classic unstyled Win32 controls (Windows 95-2000 style) then you can do that. If you use uxthemed Win32 controls (Windows XP onwards) then there's no official dark theme support.
At first I was like... what does Winamp have to do with apps development?
Llamas are hot again.
Well, was. Then Facebook AI made a side-step, and stopped focusing on downloadable LLM models, and Ollama is now trying to squeeze their users so they can show profits. r/LocalLlama is also a former shadow of itself, with the top moderator trying to move the community off reddit.
Seems Llamas will disappear as quickly as they became trendy.
I read though the GitHub readme but I'm still unsure what "new" this brings this brings to the table. It seems like a thin wrapper over existing tools. Since Microsoft rarely deprecates and removes anything, this feels like just another unnecessary complexity layer.
I'm not a traditional app dev on Windows though, so I'm likely missing something. For those of you who are more familiar, what about this are you excited about?
It is, but it's like "dotnet new" templates: a means of getting to a working minimal setup that jumps through the Microsoft hoops for you. MSIX and Package Identity are definitely headaches to get set up.
Yes, Package Identity was the bane of my existence for a while. It's wild how MS gated important APIs behind it and then made it so difficult+impractical to work with (I honestly think this is a large part of why WinRT was mostly ignored by developers).
I've moved on, but this looks like it will at least fix some of the paper cuts.
They must be either incapable of binging for matching names, or its a sneaky strategy to bury, by influence, the existing winapps project https://github.com/Fmstrat/winapps
Microsoft are incapable of naming things. This is the "Xbox one series X" of desktop development.
I don't honestly think it's unreasonable to ignore third-party projects that are polluting your own namespace, so to speak.
Their own namespace starts with "Microsoft ...".
3 replies →
It's the second time I see it on HN and read Winamp.
obvious mistake, same here
I wonder what would be cutoff age for readers to read it correctly, I guess under 30 read it correctly, and over 40 will many read it as Winamp
I'm 20 and I read Winamp, ha.
I reckon that the majority of the HN audience is into older (perhaps more graceful) working technology despite all the fanfare that newer, shinier stuff garners.
> I wonder what would be cutoff age for readers to read it correctly, I guess under 30 read it correctly, and over 40 will many read it as Winamp
I am 17 and I wasn't wearing my glasses and I was really speaking winamp until I read your comment then scrolled back again to realize it was winapp
My bet is that I spend time on HN so I knew what winamp is in more detail but if say friends my age read it & say they use tiktok more, I would say that they wouldn't call it winamp but winapp
So I guess I might be one of the few exceptions but I feel like people on HN are much more likely to read it as winamp than not & age might not be thaaat big of an impact (atleast on HN)
I'm already sold to Claude Code for Windows Desktop development.
Couple of months ago I used some shady C# SDK to build an implementation that interfaces with a very specific hardware component. My only option was Windows Forms, which I don't love very much but I have worked with extensibility in the past.
I did not have a lot of faith, because of how weird it feels to ask an LLM to work with a design.cs file, but what I did was just sketch all the design and let Claude do the logic with certain specification on how I wanted to corral the code... App was flawless in about 2 days of work. It's in production now with zero faults.
So, hard to now give this a shot, I already got my go-to tool. Even for something has arcane and obscure as Winforms.
this looks very plainly like "oh shit, devs are having a really hard time actually integrating with our AI services! That must be the only reason we are seeing adoption so slow. quick - throw a wrapper around some boostrappers that can get a green field project prepared for integration with our AI services (and whatever else can be done when you get that set up)."
I think this uses dockur to run the windows VM. That's also an awesome project.
I develop C++ software for Windows and couldn’t understand the point of this
Nevermind, this was probably a team meeting some KPIs to show value, this is useless.
Great, thats not going to get confused with "Windows App" which is the new confusing and impossible to google name for Remote Desktop
How is such a product decision even possible? Genuinely curious.
Ask the marketing department that destroyed one of the most famous brands on earth, MS Office, and renamed it to "Microsoft Copilot 365 app": https://office.com
5 replies →
Or Winamp. I read it couple of times before I noticed it is not Winamp.
Winapp, it really whips the LLMas ass
3 replies →
I just realized it now after reading your comment, I opened first comments to find out what's new about Winamp before opening the site
Windows App is the biggest naming blunder in history. Impossible to find relevant information.
It's perfectly clear: if you need to run a Windows app on another Windows PC, you just open the Windows app store on your Windows PC to download the Windows app Windows App, a Windows app that lets you connect to and run Windows apps on other Windows PCs.
1 reply →
I read a Reddit comment on the thread for this where they suggested this was only made because of the old "windev vs devdiv" rivalry.
If their stack wasn't so fucked up it wouldn't need this wrapper.
(ex windows dev)
Why am I reading winamp. Took me a minute to figure out.
Once again, a useless, bug-ridden, layer of complexity by Microsoft on an already messy stack. What could possibly go wrong?
Seriously, bring Winamp back! It will really whip the Llama’s ass.
Winapp, NOT Winamp!