3 ms·

> You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment He

> 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 had previously seen this described as 0 vs non-zero. Since you have some inside experience :), anything special about 3 instead? What about 2? How would I find these value meanings out on my own (if that's even possible)? Thanks!

ntstatusquo 6mo 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.
- Melatonic 6mo ago
  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 ?
  - ntstatusquo 6mo ago
    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.
    - Melatonic 6mo ago
      Besides better ram utilisation is it offering actual performance improvements (regardless of ram availability) ? Need to read more about this
      - ntstatusquo 6mo ago
        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.
- lloydatkinson 6mo ago
  Would the (not Framework) .NET apps I work on benefit from this?
  - garganzol 6mo ago
    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.
- zamadatix 6mo ago
  Much thanks, this is why I come to HN!

ntstatusquo 6mo 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.

Melatonic 6mo ago
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 ?
- ntstatusquo 6mo ago
  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.
  - Melatonic 6mo ago
    Besides better ram utilisation is it offering actual performance improvements (regardless of ram availability) ? Need to read more about this
    - ntstatusquo 6mo ago
      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.
lloydatkinson 6mo ago
Would the (not Framework) .NET apps I work on benefit from this?
- garganzol 6mo ago
  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.
zamadatix 6mo ago
Much thanks, this is why I come to HN!