Neat.

64-bit

heh that snippet should probably free it too before exiting.
(i know by default the system will free the memory, just saying)

blacky: Sure. But it is just simple test. Not worth the extra effort IMO.

As Borsuc already said, (Local|Global)Alloc functions are implemented on top of HeapAlloc for default process heap. Both of them don't compact or whatever in case of allocation failure. Indeed LocalAlloc(LMEM_FIXED,...) almost immediately calls HeapAlloc(BaseHeap,...) and returns pointer it get (SetLastError(ERROR_NOT_ENOUGH_MEMORY) if NULL). XP x86-32 SP3.

Heap functions are useful because you can discard entire private heap with single HeapDestroy(), no matter how complex is your data structure stored inside.

GlobalAlloc has some logic around GMEM_SHARE, this is probably for interprocess communication (DDE, clipboard?).

Local/GlobalAlloc are indeed implemented on top of HeapAlloc, but use an undocumented allocation flag. Generally, don't bother with local/globalalloc in new code but use heapalloc, you'll save a few instruction cycles...

However, when dealing with things where MSDN explicitly specifies you should use local/globalalloc memory (clipboard, createstreamonhglobal), do stick with them - that little magic flag does make the allocation a slight bit different. Last time I dug into the issue (XP SP2, I think - but it's been enough years that it could have been Win2000) the local/globalalloc functions caused some 4 or 8 bytes of information to be prepended to the allocated memory.