Who allocates a bunch of DLLs?

Question

Suppose I develop a DLL, say 1.dll, using MS visual studio 2005/2008, then bind this DLL to a console application, say 1.exe, at boot time (using the header file and .lib file), then When inside DLL, if I allocate memory at runtime, then who allocates a bunch (free store) in the DLL.

As I understand it, a DLL uses an address space for data, code, and a stack.

Answer 1

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

In this case, it is the C ++ runtime, which is responsible for creating its freestore and deciding on its distribution.

In particular, if you use the runtime Dll option, then one dll - msvcrtxx.dll - manages one freestyle that is shared between all dll and exe that are associated with this dll.

If you use a static runtime parameter when executing your exe and dll, then exe and each dll get their own libc instance, built-in with their own freestore control.

Answer 2

When you execute code inside a DLL, the code is executed in the context of your process and in the thread that is being called, and thus memory is allocated in your process space.

A DLL implementation can, of course, span new threads or new processes. In the latter case, memory allocation will occur in a new forked process.

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

Answer 3

Memory management. The DLL has separate heaps, so you need to manage it yourself. Of course, depending on your environment, there may be a special new / delete for your convenience.

There are two types of dynamic memory that you need to process and keep separate:

• You can use the heap calling process , but this will be obvious to every calling process. This way you only use this for caller-specific data.

• For the memory used by your DLL in general, regardless of the caller, you need to get a separate bunch of "private" using HeapCreate and its brother functions.

Be careful not to transfer responsibility for this memory to anything else. What your DLL stands out, your DLL will delete - otherwise you will have problems. These should be the basic rules, but over GC some people forget how to use memory responsibly, so I mention this.