Dll Memory Management

Question

I have few doubts regarding how windows manages a .dll's memory.

• when .dll's are loaded into the host process, how is the memory managed?

• Does .dll get access to the entire memory available to the host process or just a portion of it? i.e is there a limitation when memory is allocated by a function inside the .dll?

• Will STL classes like string, vector (dynamically increasing storage) etc used by the dll, work without issue here?

Answer 1

Does .dll get access to the entire memory available to the host process or just a portion of it? i.e is there a limitation when memory is allocated by a function inside the .dll?

After a DLL has been loaded into the host process, there is no distinction whatsoever for code "living" in the DLL vs. code "living" in the original executable module. For the process being executed all memory ranges are the same, whether they come from a DLL or from the original executable.

There are no differences as to what the code from the DLL can do vs. what the code compiled in the original exec module can do.

That said, there are differences when using the heap - these are explained in the questions Space_C0wb0y provided the links for in the comments

Will STL classes like string, vector (dynamically increasing storage) etc used by the dll, work without issue here?

They will create issues (solvable ones, but still) if you use them in the interface of your DLL. The will not (or should only under very rare circumstances) create issues if you do not use them on the DLL interface level. I am sure there are a few more specific questions+answers around for this.

Answer 2

"Memory management" is a split responsibility, typically. The OS hands address space in big chunks to the runtime, which then hands it out in smaller bits to the program. This address space may or may not have RAM allocated. (If not, there will be swap space to back it)

Basically, when a DLL is loaded, Windows allocates address space for the code and data segements, and calls DllMain(). The C++ compiler will have arranged to call global ctors from DllMain(). If it's DLL written in C++, it will likely depend on a C++ runtime DLL, which in turn will depend on Kernel32.DLL and User32.DLL. Windows understands such dependencies and will arrange for them to be loaded in the correct order.

There is only one address space for a provess, so a DLL will get access to all memory of the process. If a DLL is loaded in two processes, there will be two logical copies of the code and the data. (copies of the code and read-only data might share the same physical RAM though).

If the DLL allocates memory using OS functions, Windows will allocate the memory to the process from which the DLL made that allocation. The process must return the memory, but any code in the process may do so. If your DLL allocates memory using C++ functions, it will do so by calling operator new in the C++ runtime DLL. That memory must be returned by calling operator delete in the (same) C++ runtime DLL. Again, it doesn't matter who does that.

STL classes like vector<> can be multiply instantiated, but it doesn't matter as long as you're using the same compiler. All instantiations will be substantially equal, and all will return the vector's memory to the same deallocation function.

There are 2 main assumptions in this explanation:

1. The EXE and its DLLs are all compiled with the same compiler
2. The EXE and its DLLs all link against the C++ runtime DLL (i.e. not statically linked)

Static linking against the C++ runtime is useful if you want to ship an single, self-contained EXE. But if you're already shipping DLLs, you should keep the C++ runtime in its own DLL too.