ntstatusquo

Nothing wrong with using AI for software development, but your product landing page being chock full of LLM-isms is an honest signal about how much care was put into this project.

Also, it somehow, bafflingly, against all odds, manages to use 60% more memory and 3x as much CPU as the underwhelming XAML task manager that comes with windows. How about we figure out how to use fewer resources, rather than way more resources, than the already unreasonably inefficient thing that Microsoft ships?

Also, I find it funny that this TMOG thing seems to apply a special rule such that its own process does not appear in the dashboards by default.

My one data point is that Casey’s handmade hero series, and his immediate mode gui video from way back in 2005, are what introduced me and some friends to an entirely new way to build graphical user interfaces, and I do feel a great appreciation for that. Guys like Ryan Fleury (of RadDbg) and Vjekoslav Krajacic of Filepilot similarly credit Casey with their “radicalization” :) To your point though, it was less about specific technical knowledge conveyed by these videos and more about him evangelizing a high level approach that many folks otherwise wouldn’t have considered

True, the project where I used the approach above was a TUI, so windows terminal sort of eats the impact of stuff like user32 and dwrite for you.

One trick I know of to make user32 a bit more lightweight is to call ImmDisableIme prior to creating your first window. This disables a lot of the TSF integration, which is notably quite slow. Not sure if it impacts memory footprint but worth a try. It of course does what the name says and disables IME support, so not a viable option if you have users who need IME

You can get a sub 20kb executable with C in MSVC and no weird tricks, i.e. just setting a particular combination of compiler/linker flags, like /NODEFAULTIB, /MERGE, /FILEALIGN:512 etc. Small enough that it's basically nothing, downloads in a couple of seconds over 56k dialup, and you get to use normal tooling. This is the compromise that makes the most sense to me, for products you're actually shipping. If you want to try out the nocrt approach, honestly the LLMs do a fine job of writing you some replacements for the parts of the crt that you likely want i.e. memcpy/memcmp/strlen helpers, with x64/arm64 SIMD and all.

Set /HEAP:4096,4096 and /STACK:65536,4096, write yourself a simple 100 line growable arena implementation, use that, avoid the heap entirely. Very quick and easy way to get a real windows program up and running that uses about 500kb of commit at baseline.

You end up with only ntdll.dll, kernelbase.dll, and kernel32.dll loaded. Trying to eliminate any of these becomes pretty painful and you venture into the territory of weird tricks that are expensive to maintain.

Dave's approach is a fun exercise though.

I can guarantee you that Raymond had zero input on any of these decisions. He values fundamentals, quality, and customer satisfaction more than anybody. But ultimately, is just an "individual contributor" engineer down in the trenches following orders. He probably feels the same way you do about this stuff. The real question for me is, why does a famous person like him, with so many options open to him about where he works and what he works on, continue slogging away in Redmond.

My best guess is that he has devoted most of his working life to Windows, and it would be painful give up on it. He has lived through many dark periods, i.e. ME, Vista, Windows 8, and is probably optimistic about the pendulum swinging back towards quality/fundamentals eventually.

"tell me you're a rust programmer without telling me you're a rust programmer"

My personal favorite is the classic "Walls and Ladders" post about topmost windows: https://devblogs.microsoft.com/oldnewthing/20110310-00/?p=11...

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"

I hesitate to make this sound positive, but to their credit, the leadership at Microsoft who likely steered the weather app towards using the web stack at least correctly identified a major problem: there is not a single good native UI framework for Windows today.

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

Lots of iGPUs just end up being backed by system memory. But even then, this is a ridiculous hand wavy excuse. A 4000x2000 RGBA buffer is 32MB. That only explains 2.7% of the weather app's devastating memory footprint.

They don't want you to remember that Windows XP's minimum system requirements specified 64MB of RAM. This weather app uses 20 times more memory than an entire operating system from 25 years ago.

Normally I don’t give much attention to online layoff rumors, but George is very credible and allegedly has some inside sources. I do wonder if this will be a tipping point for gaming industry unions.

And yet they can’t build a TUI that scrolls without flickering or uses a reasonable amount of memory

I assume this voluntary retirement offer will be something like 2 weeks of pay per year of service, plus maybe 16 weeks. And you get to keep your unvested stock. If that's not too far off, you'd expect a principal engineer's gross expected value to be something like 800k from such a move. It seems like the net opportunity cost of accepting the VR would play out like:

1) you lose 1 or 2 million net, in the scenario where you would've otherwise stayed working 4 more years. 2) you lose ~200k net, in the scenario where you get another comparable job, but the job search takes 9 months. 3) you come out ahead if you were about to retire/get laid off anyway.

So, I don't think this plan is going to eliminate a random sampling of senior folks. The folks who accept this offer will tend to be ones that don't super enjoy the work itself, or ones that anticipate bad rewards or impending layoff.

In other words, I doubt it will be a sweet enough deal to entice the already-rich, high performing principal engineers, or the passionate nerds who are just there because they want to be.

The graph API gets you 60% of the way there, but sadly, some core functionality is missing, like calls. And even the chat part of the API is throttled aggressively. If the teams graph API were better, we'd have a bunch of nice, lightweight 3p teams clients by now probably. I really wish this were the case, given that I find teams regularly using multiple gigabytes of memory. Even on a beefy dev machine, that's significant. The C++ linker runs out of memory sometimes even on my 96GB workstation, which fails the build. No kidding, the internally documented solution is to terminate your memory-hungry apps (such as teams, edge, vscode) and try again. Or bump your page file size up to something crazy like 100GB, which ends up cutting into the already tiny 250GB C drives we've provided with. Which means your C drive will fill up every 3 weeks and you have to go babysit it by deleting all the bloat folders.

In terms of speed, anecdotally, it seems like it can go either way. Some programs run faster, some run slower. Usage patterns of malloc/free are so varied that it's probably impossible to optimize for one without hurting others.

Not nearly often enough, because most veteran Windows deverlopers don't even know what segment heap is, or that they have a choice. VS code, for example, is still on NT Heap. It is heartbreaking how under-utilized and under-publicized segment heap is. Raymond Chen needs to make a public service announcement or something.

For the question of how to do "segment heap on globally, with a list of exceptions that are still on NT Heap", I believe the "Image File Execution Options" regkey takes precedence over the global one. And the IFEO one lets you explicitly opt out. If you read the whitepaper from Mark Yason's 2016 talk at black hat, they explain how to use these registry keys.

It takes effect on executable launch.

This is a great idea, honestly. PowerToys is open source. There's a decent change that they would be open to such a contribution.

It is a crime that segment heap is over a decade old and still so underutilized. Gamers in particular go to such great lengths to tweak and optimize their windows machines for perf, but I still haven't seen that crowd discussing segment heap anywhere. It's more important than ever with the recent explosion in RAM cost.

It's complicated. It's not always a straightforward space vs time tradeoff. For chromium's allocation patterns, it sounds like segment heap was slower. But BinaryNinja reported the opposite! See https://github.com/Vector35/binaryninja-api/issues/2778

Side note on the Chromium topic: Google Chrome decided NT Heap is still best for their usage, but Microsoft Edge, which is also built on the Chromium, uses segment heap. Not sure what Firefox uses. You can check by attaching WinDbg and doing !heap. Note that not every heap will be segment heap, even if you globally opt into segment heap. Some code paths explicitly create their own heaps as NT heaps.

At the very least, using fewer pages to allocate the same amount of data improves memory locality slightly. Folks should test and see what works best in their applications.

Another benefit of segment heap that we haven't discussed yet is that it's more strict and proactive about detecting problems and terminating. From what I understand, heap metadata is now stored separately from heap data, and they use guard pages. So heap buffer overruns don't overwrite the heap manager's bookkeeping. With NT heap, crashes due to use-after-free might manifest much later and more indirectly. Like, maybe it overwrote the free list, or it overwrote some newer allocation that landed on the same address. So, the crash is usually in some unlucky 'innocent bystander' call stack that worked with the corrupted region. With segment heap, you tend to get earlier, more actionable, specific crashing call stacks, closer to the site of the original bug. So, if you're an engineer who looks at a lot of difficult windows crash dumps involving memory corruption, segment heap makes the challenge slightly more surmountable.

It's a combinination of bit flags. The lowest bit controls whether segment heap is on or off. The 2nd lowest bit bit controls some additional optimizations that go along with it, something about multithreading. A value of 3 (both flags set) gives you identical behavior to what specifying <heapType>SegmentHeap</heapType> in your application manifest does.

Using the application manifest approach is the right way to ship software that opts into segment heap. The registry thing is just a convenience for local testing.

Windows developer here. After reading this post, my gut instinct is that this is due to something called 'segment heap'.

A bit of backstory: there are two, totally independent implementations behind the Windows heap allocation APIs (i.e. the implementation code behind RtlHeapAlloc and RtlHeapFree, which are called by malloc/free). The older of the two, developed uring the Dave Cutler era, is known as the "NT heap". The newer implementation, developed in the 2010s, is known as "segment heap". This is all documented online if anyone wants to read more. When development on segment heap was completed, it was known to be superior to the NT heap in many ways. In particular, it was more efficient in terms of memory footprint, due to lower fragmentation-related waste. Segment heap was smarter about reusing small allocations slots that were recently free'd. But, as ever, Windows was very serious about legacy app compat. Joel Spolsky calls this the 'Raymond Chen camp'. So, they didn't want to turn segment heap on universally. It was known that a small portion of legacy software would misbehave and do things like, rely on doing a bit of use-after-free as a treat. Or worse, it took dependencies on casting addresses to internal NT heap data structures. So, the decision at the time was to make segment heap the default for packaged executables. At that time, Windows Phone still existed, and Microsoft was pushing super hard on the Universal platform being the new, recommended way to make apps on Windows. So they thought we'd see a gradual transition from unpackaged executables to packaged, and thus, a gradual transition from NT heap to segment heap. The dream of UWP died, and the Windows framework landscape is more fragmented than ever. Most important software on Windows is still unpackaged, and most of it runs on x64.

Why does this matter? Because segment heap is also enabled by default on arm. Same logic as the packaged vs unpackaged decision. Arm64 binaries on Windows are guaranteed not to be ancient, unmaintained legacy code. Arm64 windows devices have been a big success, and users widely report that they feel more responsive than x64 devices.

A not insignificant part of why Windows feels better on arm is because segment heap is enabled by default on arm.

I'd be interested to see how this test turns out if you force segment heap on x64. You can do it on a per-executable basis via creating a DWORD value named FrontEndHeapDebugOptions under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<myExeName>.exe, and giving it a value of 8.

You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap, and giving it a value of 3. I do this on my dev machine and have encountered zero problems. The memory footprint savings are pretty crazy. About 15% in my testing.

Nothing to add other than that I agree, and this is a easy to understand, correct way of framing the problem. But the framing probably won't convince exuberant AI folks. These tools are incredibly powerful, but they can only take you faster in the direction you were already going. Using them responsibly requires discipline, and not everyone has it, and we're about to undertake a grand social experiment in seeing how it plays out.

Unnecessary complexity was already a big problem in software prior to LLMs, and I think we're about to see it become, unbelievably, a much much bigger problem than before. My personal belief is that there are a lot of exponential harms that stack up as complexity increases:

1) Difficulty of understandinga codebase rises expontentially with code size. A 100kLOC codebase is more than 10x harder to understand than a 10kLOC codebase. 2) Large codebases get larger faster, classic snowball effect. Implementing a given feature against a larger codebase requires a larger change, even if it's the ideal, perfect change. Plus, ast shortcuts and bad abstractions make future shortcuts and bad abstractions much more likely. 3) Team size increases with codebase size, larger team size triggers Brooks law: number of communication paths grows quadratically with team size.

Prior to LLMs, the world already had large codebases that had essentially become emergent organisms that became so complex, the organizations that created them completely lost control of the ability to work in them effectively. Visual Studio and MSBuild, or Microsoft Teams come to mind. But historically, it was very expensive to get to this point. Now it's going to be much easier

The section coding.pdf has their code style guidelines, colloquially known as Cutler Normal Form, CNF for short. I'm conflicted on it. Definitely overly verbose, but you can't argue with the results of the NT team. Such a rigid style guide almost feels like the technical version of a dress code. And there's an idea called "enclothed cognition" which is like, if you wear a business suit to work, it exerts a subconscious influence that results in you taking the work more seriously, focusing your attention, etc: https://en.wikipedia.org/wiki/Enclothed_cognition

I imagine it would be frustrating to be the windows shell dev who has to investigate the torrent of bizarre memory corruption bugs that inevitably occur on Windhawk users’ machines after major OS updates. There’s really no avoiding it when you detour unstable “implementation detail” sort of functions across the taskbar/systray/start/etc. especially now that c++ coroutines are in widespread usage therein.

But to be fair, I understand the demand for products like this, because of several painful feature takebacks between 10 -> 11. It would be nice if cleaner approaches like wholesale shell replacement were still as straightforward as they were prior to windows 8. The “immersive shell” infra running in explorer + the opaque nature of enumerating installed UWPs + a bunch of other things make that almost impossible today.

Using the UIA tree as the currency for LLMs to reason over always made more sense to me than computer vision, screenshot based approaches. It’s true that not all software exposes itself correctly via UIA, but almost all the important stuff does. VS code is one notable exception (but you can turn on accessibility support in the settings)