When a DLL allocates memory using any of the memory allocation functions (GlobalAlloc, LocalAlloc, HeapAlloc, and VirtualAlloc), the memory is allocated in the virtual address space of the calling process and is accessible only to the threads of that process. |
VirtualAlloc() is the system page allocator on WIN32. HeapAlloc() is a suballocator that manages a block of memory (obtained from VirtualAlloc).
In WIN16, GlobalAlloc() is the main alloator. LocalAlloc() is the allocator that programs can use internally. It all comes from large model DOS programs and its far/near malloc. Anyway, it's all deprecated and the only WIN32 functions that use GlobalAlloc() are those that came over from WIN16; Clipboard, Atom, DDE, COM, ...
If a page is allocated by a DLL function in a process (VirtualAlloc), then any function in the process can free it. That should be obvious.
The problem is that C/C++ programs rarely need pages, they just need blocks of memory without caring about hardware crap, so they always use a suballocator. Memory taken from a suballocator must be free'd back to that suballocator. And that's the basic problem.
Take a Visual C++ built C or C++ app. You can specify how the run time library is linked. If all your modules share the C/C++ runtime library (as a DLL), then you can allocate in one module and free it in another. If you link in any other way, you can't.
Those are the basic issues. For your particular scenario, you'll have to decide if it meets the "one heap" criteria.
Anyway can you please share, how you know all these internals? |
I was around when these things were being developed and lived thru the iterations of the technology. I have loads of books and MSDN used to have a lot of this stuff, but I've noticed that all that low level stuff has been removed.
EDIT: check out
Windows Internals by Russinovich
Windows System Programming by Hart