ntstatusquo

Raymond's work often uses analogies to everyday, real life situations to make the technical stuff more relatable. Sometimes, these end up being bizarre and even nightmarish. It's like a glimpse into some alternate world where the denizens are adversarial, hyper pedantic, scheming, criminally insane, or just plain stupid.

"Sometimes I’m in a hurry, and I want to make sure I am the next person to get served at the deli counter. To do this, I find whoever has the lowest number, knock them unconscious, and steal their ticket. But sometimes somebody else comes in who’s also in a hurry. That person knocks me unconscious and steals my ticket. My plan is to set my watch alarm to wake me up periodically, and each time it wakes me up, I find the person with the lowest number, knock them unconscious, and steal their ticket. Is there a better way?"

"This is like asking for a cheeseburger and then trying to peel every last bit of cheese off the patty to turn it into a plain hamburger."

"This is like driving up to a bridge, seeing a 'Bridge out of order' sign, then getting out of your car, moving the sign, driving onto the bridge, falling into the river, and then complaining to the car manufacturer that their car doesn’t work."

"This is like calling the natural gas utility company’s emergency number to report a major gas leak in your house. The gas company sends a technician over, and they can’t find any leak. They ask how you came to suspect that there’s a gas leak, and you tell them, 'Oh, I didn’t smell anything. I called you because I’m hoping to learn more about how to recognize the smell of gas. Do you have any tips?'"

"This is like 'I have this cupboard full of rubbish, so I will solve that by nailing the doors shut'"

"It’s like asking, 'What happens to the phrase 1 cup sugar when I eat my cookies?' The phrase 1 cup sugar was part of the instructions for making the cookies"

Jeffrey Snover, creator of powershell, explained it decently well here: https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-...

Was switching to webviews the right solution to that problem? Absolutely not. But at least we can admit they were in a difficult position.

At the time this bloated weather app was probably developed, the choice that most of the rest of the shell and in-box apps were making was C++/WinRT paired with System XAML (i.e. Windows::UI::Xaml aka WinUI 2 aka UWP XAML) via the still-marked-as-experimental-in-2026 islands API (DesktopWindowXamlSource) like the taskbar/control center/file explorer/etc. Or worse, actual UWP, such as the Start Menu, Settings app, or Notification Center. This can have a decent-ish memory footprint - Control Center, for example, uses about 150MB of commit and 30MB of working set. Still not good, but not atrocious either. But even for this mediocre level of performance and efficiency, you end up paying a very high cost in terms of development time and expertise required. This stack "just works" like 70% of the time, but the other 30%, you're scratching your head figuring out where you forgot to hold a strong reference across a co_await boundary. Or figuring out why a XAML ListView corrupted its recycling pool in korea because window messages reentered a nested message loop started by XAML's outbound RPC call that's only made in the TextBlock code for east asian languages. You get a razor thin veneer of user-friendliness, i.e. MVVM, x:bind, co_await ("hey, this is just like C# + WPF!") on top of a 60% finished UI framework and a terrible programming language feature which is quite possibly one of the leakiest abstractions in the history of the world (C++ coroutines). The fact that Raymond Chen managed to write a blog series on C++ coroutines in Windows that is 60 posts long is damning: https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=10...

On top of all this, Microsoft's status in the industry has dropped. And they have absolutely no structured technical training program for new employees. I guess just pray you get paired with a decent mentor. So, young employees fresh out of undergrad who are asked to work in these codebases are super unproductive and make mistakes on a regular basis that cause inscrutable memory corruption bugs.

For a time, leadership was wildly flailing around trying to find some alternative to this madness. At the time when this bloated weather app was developed, the hot idea was that we should be switching to the web stack for native experiences. There was some low effort hand waving about how WebView2 would be continuously improved, we would mitigate the memory footprint by sharing webviews, etc.

My position is that there's no reasonable choice for building efficient native UX on windows today except by targeting a lower level graphics API like DirectX, Vulkan, OpenGL, or even software rendering in GDI, rather than a GUI framework. Most serious software on windows ends up going down the route of literally building their own UI framework, i.e. web browsers, office, adobe suite. If you don't mind the dated look/functionality of win32's stock common controls, that's also a decent option. I've heard that Qt is okay, but haven't tried it.

One final note: if anyone is earnestly wondering whether WinUI 3 is perhaps, finally, an end to all the bloodshed, my take is: no It is (currently) UWP XAML wearing a trenchcoat, plus a needless namespace change that broke compat, plus the baffling choice to run a copy of the compositor in-process in order to - wait for it - be able to ship WinUI 3 apps downlevel to Windows 7 and have acrylic work correctly!!! (to their credit, they have signaled that they are reversing this decision and moving back to the system compositor). WinUI 3 has the potential to be good, but appears to be too underfunded to achieve its potential.

org_chart_with_guns.jpg