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.

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\.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.

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

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.