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

“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.