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

Question

TL; DR -MS文档指出，VS2015和VS2017库之间的二进制兼容性是单向的，而我认为它必然是双向的。渔获物在哪里？

---

首先，背景：

• 在VS2015和VS2017之间，任何officially binary compatible都是MSVC ++构建的库。
• 具体来说，您可以将VS2015 C ++应用与2017年之后的MSVCRT140版本一起使用。（VCRedist backwards compat）
• official documentation site给出了一个令人困惑的限制。

背景/相关问题：

• 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.12到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 –现在，该btw DLL在哪个“方向”上受支持？

由于二进制兼容-纯粹从二进制/接口的角度出发-必须双向运行，所以我不太清楚我们在这里突然会出现不兼容的地方：API调用可以双向运行（回调等），对象会同时“移动”，甚至可以混合DLL加载的顺序。

这是恕我直言的要点，因为它表示所述的二进制兼容性受到严重的限制：

• 如果我的应用程序要使用任何VC14*编译的库，那么我“仍然”仍必须确保我的应用程序是使用“最新版本”构建的。
• 另一方面，如果不是一个“应用程序”，而是拥有一个DLL，看来我可以使用任何其他VC14* DLL并兼容吗？
• 使用VCRedist，我们已经完全一个看似不受支持的情况，即我们被允许使用VC2017库（在这种情况下为CRT）来自2015年的应用！

问题

所以，为什么（！）受到这种局限性，以及它与dll之间的依赖关系以及反向（！）CRT-dll版本要求之间的关系。

Answer 1

Microsoft 自从更新了文档以来，https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017当前版本的相关部分显示为：

  

Visual Studio 2015和Visual Studio 2019之间的C ++二进制兼容性

     

...

     

当您混合使用不同支持版本的MSVC工具集构建的二进制文件时，   您的应用程序在其上运行的Visual C ++可再分发不能旧   比使用的任何工具集版本   来构建您的应用程序或它消耗的任何库。

差异位于https://github.com/MicrosoftDocs/cpp-docs/commit/a505dccfb31eb49c2ffece4dabd24a0a61b1fcb3#diff-d488b4c71be450b2a39cdce495c229bf

没有直接的GitHub / MS-Docs问题，但是这个限制更有意义：它只是谈论 redistributable 的兼容性要求，并且要求VC运行时版本至少与使用中的最新模块一样。

这当然是有道理的，因为这不仅是纯二进制兼容性。

当然，我在问题中所说的仍然是正确的：任何（旧）VS2015应用程序必须与（新）VS2019可再发行版本兼容，因此我猜想VCRedist-VC14.0公开的所有界面都应该是二进制兼容。