VS2017和VS2015应用程序与dll之间的官方二进制不兼容是否准确?

-MS docs声明VS2015和VS2017 LIB之间的二进制兼容性为 ,而我认为这必然是双向的。陷阱在哪里?

• officially binary compatible VS2015和VS2017之间。
• 具体来说,从2017年起,您可以将VS2015 C++应用程序与MSVCRT140版本配合使用。( VCRedist backwards compat )
• official documentation site 州a 令人困惑的限制 .

背景/相关问题:

• Is Visual-C++-2017 binary compatible with VC++-2015?
• Questions about "Binary Compatibility between Visual Studio 2015 and Visual Studio 2017"
• Binary compatibility between VS2017 and VS2015

我发现令人困惑的限制是:

这条规则有两个例外。在以下情况下,无法保证二进制兼容性:

消费时 使用版本更高的工具集构建的库 . 例如,与编译器版本19.12编译和链接的程序可以使用19.0到19.12编译的库。

这个警告在技术上既草率又令人困惑。技术原因是什么?

我说它是草率的,因为它是不完整的,因为可执行文件和DLL之间的接口是相当对称的,但这个项目符号只涵盖“应用程序”。

具体来说, 假设所有模块都是根据动态CRT版本构建的,并且此动态CRT版本是可用的最新版本,我看到了以下组合,其中二进制兼容是一个问题:

• my_2017.exe <-> my_2015.dll --表面上支持
• my_2015.exe <-> my_2017.dll --似乎不受支持
• my_2017.exe <-> my_2015.dll <-> my_2017_x.dll

必须双向运行 ,我不太明白我们在这里会突然出现不兼容:API调用可以双向进行(回调等),对象可以双向“移动”,甚至DLL加载的顺序也可以混合。

如前所述 是 有限:

• 如果我的应用程序想要使用任何 VC14* 在编译库时,我“正式”仍然必须确保我的应用程序是用“最新版本”构建的。
• VC14* DLL是否兼容?
• 有了VCRedist,我们有了 这种情况似乎 不支持 允许 从2015应用程序中消费VC2017库(本例中为CRT)!

那么,为什么(!)这在某种程度上是有限的吗?它与dll之间的依赖关系以及反向(!)有什么关系CRT dll版本要求。