Comment by kh9000
10 hours ago
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.
How often does software actually ship with the opt in for segment heap turned on though ?
Anyway to globally turn it on when a blacklist or denylist or whatever in case something individual acts up ?
Would the (not Framework) .NET apps I work on benefit from this?
Any app using memory allocation functions would benefit from a newer heap implementation independently of a technology it's created with, unless it's actively constrained by compatibility burdens. In case of .NET, the memory layout compatibility is not something you usually care about unless the app loads old 3rd party .DLLs through P/Invoke. So for 99.9% of .NET (not Framework) apps, the segment heap should work just fine.