VS2017和VS2015应用程序与dll之间的官方二进制不兼容性准确吗? [英] Is the official binary incompatibility between VS2017 and VS2015 app vs. dll accurate?
问题描述
TL; DR -MS文档指出，VS2015和VS2017库之间的二进制兼容性是单向的，而我认为它必然是双向的.渔获物在哪里?
TL;DR - The MS docs state that binary compatibility between VS2015 and VS2017 libs is one-way, while I'd assumed it is necessarily two-way. Where's the catch?
首先，对于背景:
- 任何MSVC ++构建的库都是 VCRedist向后兼容)
- 官方文档网站指出了一个令人困惑的限制.
- Any MSVC++ built libraries are officially binary compatible between VS2015 and VS2017.
- Specifically, you can use your VS2015 C++ app with the MSVCRT140 version from 2017. (VCRedist backwards compat)
- The official documentation site states a confusing restriction.
背景/相关问题:
- Visual-C ++-2017二进制与VC ++兼容吗? 2015年?
- 有关"Visual Studio 2015和Visual Studio 2017""
- VS2017与VS2015之间的二进制兼容性
- 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
我发现令人困惑的限制是:
The confusing restriction I find is:
此规则有两个例外.在以下情况下不能保证二进制兼容性:
There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:
...
使用使用版本大于用于编译和链接应用程序的工具集的工具集构建的库时.例如，编译并与编译器版本19.12链接的程序可能会消耗从19.0到19.12为止编译的库.
When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume libraries that are compiled with 19.0 up through 19.12.
恕我直言，这个警告在技术上既草率又混乱.技术原因是什么?
This caveat is, IMHO, both technically sloppy and confusing. What would the technical reason be for that?
我之所以说这很草率是因为它不完整，因为可执行文件和DLL之间的接口是对称的，但是此项目符号仅涵盖应用程序".
I say it's sloppy because it is incomplete, because the interface between an executable and a DLL is pretty syymetric, but this bullet only covers "the application".
具体来说，和假定所有模块都是针对动态CRT版本构建的，并且此动态CRT版本是可用的最新版本，我看到以下组合存在二进制兼容性的问题:
Specifially, and assuming all modules are built against the dynamic CRT version and this dynamic CRT version is the newest version available, I see the following combinations where binary compat is an issue:
-
my_2017.exe <-> my_2015.dll-似乎受支持 -
my_2015.exe <-> my_2017.dll-似乎不受支持 -
my_2017.exe <-> my_2015.dll <-> my_2017_x.dll-现在，该btw DLL在哪个方向"上受支持?
my_2017.exe <-> my_2015.dll-- seemingly supportedmy_2015.exe <-> my_2017.dll-- seemingly unsupportedmy_2017.exe <-> my_2015.dll <-> my_2017_x.dll-- what now, in which "direction" is this supported btw DLLs?
由于二进制兼容-纯粹从二进制/接口的角度出发-必须双向运行，所以我不太清楚我们在哪里突然遇到不兼容的地方:API调用可以双向运行(回调等)，对象会同时移动"，甚至可以混合DLL加载的顺序.
Since binary compat - purely from the binary/interface perspective - must run both ways, I don't quite see where we suddenly could get an incompatibility here: API calls can go both ways (callbacks etc.), objects "move" both ways, even the order of DLL loading can be mixed.
这是恕我直言的要点，因为它表示二进制兼容性 受几分限制:
This is an important point IMHO, as it means the binary compatibility as stated is severly limited:
- 如果我的应用程序要使用任何
VC14*编译的库，我仍"必须仍然确保我的应用程序是使用最新版本"构建的. - 另一方面，如果不构建应用程序"但拥有DLL，我似乎可以使用任何其他
VC14*DLL并兼容吗? - 使用VCRedist，我们已经完全一个看似不受支持的情况，即我们被允许使用VC2017库(在这种情况下为CRT)来自2015年的应用！
- If my application want's to consume any
VC14*compiled library, I "officially" still must make sure that my application is built with the "newest version". - On the other hand, if don't build an "application", but have a DLL, I can seemingly consume any other
VC14*DLL and be compatible? - With the VCRedist, we have exactly the case that is seemingly unsupported, namely we are allowed to consume a VC2017 library (CRT in this case) from a 2015 app!
所以，为什么(！)受到这种局限性，以及它与dll之间的依赖关系以及反向(！)CRT-dll版本要求之间的关系.
So, why(!) is this limited in the way it is, and how does it relate to inter-dll dependencies and also the inverted(!) CRT-dll version requirement.
推荐答案
Microsoft has since updated their docs, the relevant section of the current version of https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 reads:
Visual Studio 2015和Visual Studio 2019之间的C ++二进制兼容性
...
C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2019
...
当您混合使用不同支持版本的MSVC工具集构建的二进制文件时， 您的应用程序在其上运行的Visual C ++可重新分发的版本不能旧 比使用的任何工具集版本 来构建您的应用程序或它消耗的任何库.
When you mix binaries built with different supported versions of the MSVC toolset, the Visual C++ redistributable that your application runs on cannot be older than any of the toolset versions used to build your app or any libraries it consumes.
The diff is at https://github.com/MicrosoftDocs/cpp-docs/commit/a505dccfb31eb49c2ffece4dabd24a0a61b1fcb3#diff-d488b4c71be450b2a39cdce495c229bf
没有直接的GitHub/MS-Docs问题，但是这个限制更有意义:它只是谈论 redistributable 的兼容性要求，并且要求VC运行时版本必须至少与使用中的最新模块一样最新.
There is no direct GitHub/MS-Docs issue for this, but this limitation makes a lot more sense: It just talks about the compatibility requirements of the redistributable, and requiring a VC runtime version that is at least as current as the newest module in use.
这当然是有道理的，因为这不仅是纯二进制兼容性.
This, of course, can make sense, as this is not only pure binary compatibility.
当然，我在问题中所说的仍然是正确的:任何(旧)VS2015应用程序必须与(新)VS2019可再发行版本兼容，因此我猜想VCRedist-VC14.0公开的所有界面都应该是二进制兼容.
Of course, what I said in the question still is valid: Any (old) VS2015 application must be compatible with the (new) VS2019 redistributable, so I guess all the interface surface that VCRedist-VC14.0 ever exposed should be binary compatible.
这篇关于VS2017和VS2015应用程序与dll之间的官方二进制不兼容性准确吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
