Who allocates heap to a DLL? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form.开发者_StackOverflow中文版 For help clarifying this question so that it can be reopened, visit the help center. Closed 12 years ago.

Suppose I develop a DLL, say 1.dll using MS visual studio 2005/2008, then I link this DLL to a console application, say 1.exe, at load time (using header file and .lib file) then When inside DLL, if I am allocating memory at run time, then who allocates heap (free store) to the DLL.

As I understand that DLL uses process's address space for data, code and stack.

---

When you make a Dll - you always write it in some Language - in your case C++ using Visual Studio 2005 or 2008.

In which case it is the C++ runtime that is responsible for creating its freestore and deciding how to allocate it.

Specifically, if you use the Dll runtime option, then a single dll - msvcrtxx.dll - manages a single freestore that is shared between all dll's, and the exe, that are linked against that dll.

If you use the static runtime option when beuiding your exe and dlls, then the exe and each dll gets its own instance of libc built in, with its own freestore management.

---

When you execute code inside a DLL the code is executed in the context of your process and on the thread that is calling and, in that way, memory is allocated in your process space.

The implementation of the DLL can of course span new threads or new processes. In the latter case the memory allocation will take place in the new forked process.

That means when 1.exe executes the DLL all memory allocated (including the stack) goes to your process memory space (i.e. if the DLL allocates 1 GB of memory then it will reflect in your process memory consumption).

---

You do the memory management. DLLs have separate heaps, so you need to do the management yourself. Of course, depending on your environment, there may be an specialized new/delete available for your convenience.

There are two types of dynamic memory to handle, and to keep apart:

• You can use the calling process' heap, but that will be a different one for every calling process, obviously. So you use that only for data depending on the caller.

• For the memory your DLL uses in general, independent of caller, you'll have to get a separate "private" heap, using HeapCreate and its sibling functions.

Be careful not to pass on the responsibility for that memory to anything else. What your DLL allocates, your DLL will delete - otherwise, you'll get trouble. That should be the basic rules, but over GC some people forget how use memory responsibly, so I mention it.