混合来自不同MSVC的DLL时的不同行为 [英] different behavior when mixing DLLs from different MSVC
问题描述
我知道混合来自不同MSVC的DLL是不好的，应该避免。
在这里我想知道他们不同行为的原因。
I know that mixing DLLs from different MSVC is bad and should be avoided. Here I would like to know the reason of their different behavior.
背景：
具有（XXX.dll，XXX.lib和XXX.h附带的第三方库）
我在我的应用程序中使用了隐式链接。
它们都是x64。
Having 3rd party library shipped with (XXX.dll, XXX.lib and XXX.h) I use it in my application with implicit linking. They are all x64.
- 我的应用是使用 MSVC 2015 构建的。
- 第三方XXX.dll显然是用 MSVC 2008 和
- 构建的。在从XXX.dll的函数调用中
- 例如
int __stdcall func1（const char * arg）;以字符串作为参数 - 例如
int __stdcall func2（char * arg）;获取由DLL填充的字符串
- my application is built with MSVC 2015.
- The 3rd party XXX.dll is apparently built with MSVC 2008 and
- Unfortunately there is pointer involved in function calls from XXX.dll
- e.g.
int __stdcall func1(const char * arg);to have string as argument - e.g.
int __stdcall func2(char * arg);to get string filled by DLL
不同的设置：
在Windows 7（x64）上
工作正常。
在Windows 10（x64）上
由于读取无效的内存位置，我从XXX.dll中获得访问冲突异常。 （即调用
int __stdcall func1（const char * arg）;）I get access violation exception from XXX.dll due to reading invalid memory location. (i.e. calling
int __stdcall func1(const char * arg);)Exception thrown at 0x000001EF05A2BBB9 (XXX.dll) in Application.exe: 0xC0000005: Access violation reading location 0x00000000074A3A68.（当有两个CRT /堆且指针传输不起作用时，这听起来很合理。）
(it sounds reasonable when there are two CRTs/Heaps and pointer transfer will not work.)
问题：
为什么它可以在Windows 7上运行？
Why it works on Windows 7?
我使用相同的MSVC2015工具链，并且预期会有相同的行为。
还是与操作系统相关？I use the same MSVC2015 tool-chain and would expect the same behavior. Or is there something OS related?
谢谢。
推荐答案
确实，原始问题并非真正有效。
当我查看堆栈跟踪时。Indeed, the original question is not really valid. When I look at stack trace. The exception is actually thrown by a (msvcr90.dll) thread from the XXX.DLL.
这里是更详细的问题
调试第三缔约方DLL升级到Windows 10后导致访问冲突
这篇关于混合来自不同MSVC的DLL时的不同行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
