"GlobalAlloc" versus "malloc" versus "new"

No real advantange?

However, check this article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/comparing_memory_allocation_methods.asp

Better yet, read the full documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/about_memory_management.asp

Is the memory shared between multiple programs? It would take some effort to recreate that behavior without GlobalAlloc.

Are the blocks resized? If so, the program may be taking advantage of the fact that the handle does not change when reallocations occur. It would take some effort to recreate that behavior without using GlobalAlloc.

Does the program rely on GlobalSize to get the size of a memory block? Again, it would take some effort to recreate that behavior without using GlobalAlloc.

If you don't share memory blocks with other running programs, and you don't rely on reallocations not affecting the handle value, and you don't need to get the size of memory blocks, you are open to easily use alternatives.

For allocations smaller than one megabyte, the heap functions are a good choice. For larger allocations, use VirtualAlloc and VirtualFree using MEM_COMMIT/PAGE_READWRITE and MEM_RELEASE respectively.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/heap_functions.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/virtual_memory_functions.asp

As an added bonus, when using the heap functions, you can create separate heaps for certain areas of the program. When you destroy a heap, it automatically deallocates all blocks inside that heap, without having to worry about freeing each block inside that heap.

Since the program is constantly locking and unlocking the blocks, you may want to create a couple of "wrapper" functions that take the same parameters as GlobalAlloc/GlobalFree/GlobalLock/GlobalUnlock, but instead of returning a handle, it just returns a pointer to the memory block. Then, your "GlobalLock" (maybe call it MyGlobalLock) function would just return the "handle" unmodified, because it is already a pointer. MyGlobalUnlock would do nothing. GlobalAlloc/GlobalFree would pass thru to the heap functions or whatever you want it to really use, and would return the pointer to the actual block instead of a handle.

Again, the above trick would work great, ONLY IF the code does not expect the handle to stay the same when a reallocations occur.

The program uses the GlobalAlloc functions just like a malloc.  It is used to store static image data that is never resized, and whose dimensions are stored in the image height and width vars and is only shared with some dlls.  As far as the program is concerned, all these memory allocation techniques are equivalent.

Compiler and runtime dependancy aren't a problem since the whole project is already in VC++ anyway.  That isn't going to change.  All allocations are at least  half a meg, with most running to 40MB.

One possible way of handling the Windows Alloc functions without needing to keep track of them is to define a CGlobalAlloc object that takes the alloced handle as a constructor.  Add a pointer operator that locks the handle the first time it is called and a destructor that releases the handle.  It would prevent non-freed handles from becoming a problem.  I already do this with critical sections, but it is a great deal of work if a GlobalAlloc is not needed in the first place.

I also note this comment: "The following are the global and local functions. These functions are slower than other memory management functions and do not provide as many features. Therefore, new applications should use the heap functions. However, the global functions are still used with DDE and the clipboard functions."

So the GlobalAllocs should or shouldn't be used?

Nope, no DDE or clipboard, and allocs are relatively infrequent.  The only reason the GlobalAllocs are there is because under VC1.0 the malloc function was limited to 64K.

Okay, thanks.