New feature - force memory allocation to be above 4GB (for 64bit only)

[mikecopperwhite]

Add a persisted entry to the options menu to the 64bit version of GSN only. If enabled all memory allocations are forced to be above 4GB to help test for 64bit pointer truncation bugs in filters. This will require a restart of GSN before it has any effect.

Adding a similar feature to the 32bit version to force allocations above 2GB to test large address aware 32bit filters is less useful because it limits the total memory available and graphs may fail to run if some filters are not flagged as large address aware in the linker flags. I have no need for this feature personally either.
https://msdn.microsoft.com/en-us/library/wz223b1z.aspx

64bit pointer truncation bugs are hard to find because they only are apparent when the pointer happens to be an address above 4GB.

This technique https://randomascii.wordpress.com/2012/02/14/64-bit-made-easy/ seems to work best for forcing allocated memory above 4GB. The blog author has given permission for his code to be used with a credit. We just need to run a small piece of code in GSN at startup.

There are a few different techniques to force allocated memory to be > 4GB. There is a global AllocationPreference Windows registry entry but that is global in effect, requires a reboot and can cause slow system performance and system instability if you have buggy 64bit apps installed.

Code addresses are less likely to be affected by pointer truncation. I'm not aware of any techniques for controlling the base address when loading a DLL or creating a COM object instance. There is a 'high entropy VA' linker flag which loads DLLs high in the 64bit memory space but this may be ignored if there are DLLs in the process that flag that they can't be relocated or don't support address space randomization. Not sure GSN can do much to help here.
https://msdn.microsoft.com/en-us/library/bb384887.aspx
https://msdn.microsoft.com/en-us/library/dn195771.aspx

I'm not aware of any techniques for controlling the address of the stack to force this above 4GB. To be of any use we'd also need to the same for threads created by filters and DirectShow itself.

[mikecopperwhite]

Option reserves below 2GB on 32bit builds for testing LargeAddressAware code
Option reserves below 4GB on 32bit builds for testing pointer truncation in 64bit code
The 32bit and 64bit options are stored under separate registry key as have quite different effects.

[mikecopperwhite]

The 32bit reserve below 2GB option on the 32bit application can break filters quite easily, perhaps because the filter DLLs aren't flagged as large address aware. The corresponding 64bit option is less likely to break filters unless there are actual pointer truncation bugs.

On my system switching on reserve below 2GB stops the Video Renderer from instantiating due to lack of memory. The Enhanced Video Renderer works fine though.

Perhaps this could be flagged on the UI more emphatically as a 'dangerous' diagnostic feature that may break filters (by design).