DLL内存管理

Question

我对Windows如何管理.dll的内存几乎没有疑问。

• 当.dll加载到主机进程时，如何管理内存？

• .dll是否可以访问主机进程可用的整个内存或只是其中的一部分？ 即，当.dll中的函数分配内存时是否存在限制？

• STL类如dll使用的字符串，向量（动态增加存储）等，在这里没有问题吗？

Answer 1

.dll是否可以访问主机进程可用的整个内存或只是其中的一部分？ 即，当.dll中的函数分配内存时是否存在限制？

在将DLL加载到主机进程之后，对于DLL中的“生活”代码与原始可执行模块中的“生活” 代码没有任何区别。 对于正在执行的进程，所有内存范围都是相同的，无论它们来自DLL还是来自原始可执行文件。

关于DLL中的代码可以做什么与原始exec模块中编译的代码可以做什么没有区别。

这就是说，使用堆时存在差异-这是在问题解释Space_C0wb0y中提供的链接的评论

STL类如dll使用的字符串，向量（动态增加存储）等，在这里没有问题吗？

如果您在DLL的界面中使用它们，它们将创建问题（可解决的问题，但仍然存在）。 如果您不在DLL接口级别上使用它们， 则不会 （或者应该仅在非常罕见的情况下）创建问题。 我相信还有一些更具体的问题和答案。

基本上，如果在接口级别使用它们，DLL和EXE必须使用“完全”相同的标志进行编译，即类型需要二进制兼容。 即如果你的DLL中的编译器标志（优化等）与EXE中的那些不同，那么std::string在EXE与DLL中的内存中的布局不同，然后在两者之间传递一个字符串对象将导致崩溃或无声错误（或恶魔飞出你的鼻子）。

如果您只使用函数内部的STL类型或DLL内部的函数，那么它们与EXE的兼容性无关紧要。

Answer 2

“内存管理”通常是一种分裂责任。 操作系统将大块地址空间分配给运行时，然后运行时将较小的位交给程序。 该地址空间可能有也可能没有分配RAM。 （如果没有，将有交换空间来支持它）

基本上，当加载DLL时，Windows为代码和数据段分配地址空间，并调用DllMain() 。 C ++编译器将安排从DllMain()调用全局ctors。 如果它是用C ++编写的DLL，它可能依赖于C ++运行时DLL，而后者依赖于Kernel32.DLL和User32.DLL。 Windows了解此类依赖关系，并将安排以正确的顺序加载它们。

证明只有一个地址空间，因此DLL可以访问进程的所有内存。 如果在两个进程中加载​​DLL，则会有两个代码和数据的逻辑副本。 （代码和只读数据的副本可能共享相同的物理RAM）。

如果DLL使用OS函数分配内存，Windows将把内存分配给DLL进行分配的进程。 进程必须返回内存，但进程中的任何代码都可以这样做。 如果你的DLL使用C ++函数分配内存，它将通过在C ++运行时DLL中调用operator new来实现。 必须通过在（相同的）C ++运行时DLL中调用operator delete来返回该内存。 同样，谁做到这一点并不重要。

像vector<>这样的STL类可以多次实例化，但只要你使用相同的编译器就没关系。 所有实例化都将基本相同，并且所有实例都将向量的内存返回到相同的释放函数。

这个解释有两个主要假设：

1. EXE及其DLL都使用相同的编译器进行编译
2. EXE及其DLL都链接到C ++运行时DLL（即不静态链接）

如果要发布单个自包含的EXE，则对C ++运行时的静态链接很有用。 但是，如果您已经加载了DLL，那么您应该将C ++运行时保留在自己的DLL中。