潜在的DLL兼容性问题的摘要？

Question

当（非托管）Win32程序（或其他DLL）调用（非托管）Win32 DLL时，我的理解是存在许多可能导致问题/崩溃的潜在不兼容性。

例如，如果程序P调用DLL D，并且P使用Visual Studio 2013编译为目标Windows SDK版本8，并且D编译为使用Visual Studio 2017以Windows SDK版本10为目标，我理解他们将访问不同的msvc运行时DLL，可能会导致问题。例如，如果D使用new分配内存并将其传递回P，并且P尝试delete它，则会发生崩溃，因为P和D正在使用两个不同的运行时，每个运行时都维护自己的堆。

类似地，如果P是使用运行时类型信息（RTTI）构建的而D不是，我的理解是，当P分配一个类实例（对于每个在公共.h文件中引用的类型）时，可能存在崩溃的不兼容性。 ）并将其传递给D，因为虚函数表和/或结构字段之间的填充不同。

我试图了解可能存在的其他不兼容性。理想情况下，我想找到一个完整的清单。以下是一些可能的想法：

• 结构成员对齐（类似于RTTI问题）
• 使用多字节字符集与使用Unicode字符集（如果传递/返回字符串对象，可能会导致问题？）
• 省略（与不省略）帧指针（或者这可能不适用，因为跨程序/ DLL的函数调用机制不同于此标志与内部函数调用机制有关？）
• 启用（或禁用）C ++异常（异常处理适用于DLL调用，如果它们都是在启用异常并使用相同的运行时构建的？）
• 其他？

编辑

我问这个问题是一般的好奇心，但也因为我在我的程序中使用DLL进行随机堆损坏，而我正在试图弄清楚可能是什么问题。

我的问题结果是我正在链接一个过时的DLL导入库。我不确定为什么程序没有错误地启动，为什么它基本上运行正常但是间歇性堆损坏。我相信如果新的DLL提供旧DLL导入库提供的功能的超集，它只能无错误地启动。然后我不确定该机制是否是C / C ++运行时库中的不匹配，或者可能是函数参数的变化而没有功能签名的重大变化？

无论如何，我猜想链接过时的DLL导入库可以添加到列表中，尽管它比其他人提到的错误更少。

Answer 1

一个非常常见的错误是在dll接口中使用标准库东西或其他编译器实现/版本相关的功能。这通常只有在双方（dll及其用户）使用相同版本的编译器时才有效，即使这样，当其中一个构建时启用了DEBUG而另一个构建了NDEBUG时，可能会出现不兼容。

仅在dll接口中使用c兼容类型等。