This is probably a good document to also read as it does differentiate the slight differences in the GlobalX and LocalX functions.
Comparing Memory Allocation Methods - Win32 apps | Microsoft Docs
Although the GlobalAlloc , LocalAlloc , and HeapAlloc functions ultimately allocate memory from the same heap, each provides a slightly different set of functionality. For example, HeapAlloc can be instructed to raise an exception if memory could not be allocated, a capability not available with LocalAlloc . LocalAlloc supports allocation of handles which permit the underlying memory to be moved by a reallocation without changing the handle value, a capability not available with HeapAlloc
The “reallocation” sounds like “ASLR handles” if such a description exists, it will be interesting to see if windows gives different handle “patterns” but you can tell from updates and the settings MS windows resets after an update where they have been working on the OS. Early windows 10 updates were always resetting various exploit protection settings, not so much of a problem with updates from the last 6 months or so.
Because the different heap allocators provide distinctive functionality by using different mechanisms, you must free memory with the correct function. For example, memory allocated with HeapAlloc must be freed with HeapFree and not LocalFree or GlobalFree . Memory allocated with GlobalAlloc or LocalAlloc must be queried, validated, and released with the corresponding global or local function.
And this is why we have constructors/deconstructores in classes and why .Net exists, ie to free and clean memory properly.
This is also a useful api to be aware of, it seems optimising compilers can cause problems.
ZeroMemory macro (Windows) | Microsoft Docs
To avoid any undesired effects of optimizing compilers, use the SecureZeroMemory function.
So when you read this one
SecureZeroMemory function (Windows) | Microsoft Docs
If ZeroMemory were called in this example instead of SecureZeroMemory , the compiler could optimize the call because the szPassword buffer is not read from before it goes out of scope. The password would remain on the application stack where it could be captured in a crash dump or probed by a malicious application.
What this also says is the stack is vulnerable to sniffing or probing, so MS is giving away their known weaknesses in the OS, emphasis on known. I know Friedrich Linder highlight how easily corrupted the Clarion stack could be with Clarion 7 and this is the Topspeed stack which is not known by as many people, only few know about it.