VS2017 和 VS2015 app vs. dll 之间的官方二进制不兼容准确吗？
Is the official binary incompatibility between VS2017 and VS2015 app vs. dll accurate?
TL;DR - MS 文档指出 VS2015 和 VS2017 库之间的二进制兼容性是单向，而我会假设它必然是双向的。问题在哪里？
首先，对于背景：
- 任何 MSVC++ 构建的库都在 VS2015 和 VS2017 之间officially binary compatible。
- 具体来说，您可以将 VS2015 C++ 应用程序与 2017 年的 MSVCRT140 版本一起使用。(VCRedist backwards compat)
- official documentation site 陈述了一个令人困惑的限制。
背景/相关问题：
我发现的令人困惑的限制是：
There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:
...
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.
恕我直言，这个警告在技术上既草率又令人困惑。技术原因是什么？
我说它草率是因为它不完整，因为可执行文件和 DLL 之间的接口是相当对称的，但此项目符号仅涵盖 "the application"。
特别地，和假设所有模块都是针对动态 CRT 版本构建的，并且此动态 CRT 版本是可用的最新版本，我看到以下组合，其中二进制兼容是一个问题:
my_2017.exe <-> my_2015.dll -- 貌似支持my_2015.exe <-> my_2017.dll--貌似不支持my_2017.exe <-> my_2015.dll <-> my_2017_x.dll -- 现在呢，"direction" 这个受支持的 btw DLL 是什么？
由于二进制兼容 - 纯粹从 binary/interface 的角度来看 - 必须 运行 双向 ，我不太明白我们突然可以从哪里得到一个此处不兼容：API 调用可以双向（回调等），对象 "move" 双向，甚至 DLL 加载的顺序也可以混合。
恕我直言，这是很重要的一点，因为这意味着二进制兼容性 如所述 严重 受限：
- 如果我的应用程序想要使用任何
VC14* 编译库，我 "officially" 仍然必须确保我的应用程序是使用 "newest version". 构建的
- 另一方面，如果不构建 "application"，但有一个 DLL，我似乎可以使用任何其他
VC14* DLL 并兼容？
- 对于 VCRedist，我们正好 看似不支持 的情况，即我们 允许从 2015 年的应用程序中使用 VC2017 库（在本例中为 CRT）！
问题
那么，为什么（！）如此受限，它与 dll 间依赖关系以及反向（！）CRT-dll 版本要求有何关系。
Microsoft 已更新其文档，当前版本 https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 的相关部分如下：
C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2019
...
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.
没有直接的 GitHub/MS-Docs 问题，但这个限制更有意义：它只是讨论 可再发行 的兼容性要求，并且要求VC 至少与正在使用的最新模块一样新的运行时版本。
这当然是有道理的，因为这不仅仅是纯粹的二进制兼容性。
当然，我在问题中所说的仍然有效：任何（旧的）VS2015 应用程序必须与（新的）VS2019 可再发行组件兼容，所以我猜所有界面表面 VCRedist- VC曾经公开的 14.0 应该是二进制兼容的。
TL;DR - MS 文档指出 VS2015 和 VS2017 库之间的二进制兼容性是单向，而我会假设它必然是双向的。问题在哪里？
首先，对于背景：
- 任何 MSVC++ 构建的库都在 VS2015 和 VS2017 之间officially binary compatible。
- 具体来说，您可以将 VS2015 C++ 应用程序与 2017 年的 MSVCRT140 版本一起使用。(VCRedist backwards compat)
- official documentation site 陈述了一个令人困惑的限制。
背景/相关问题：
我发现的令人困惑的限制是：
There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:
...
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.
恕我直言，这个警告在技术上既草率又令人困惑。技术原因是什么？
我说它草率是因为它不完整，因为可执行文件和 DLL 之间的接口是相当对称的，但此项目符号仅涵盖 "the application"。
特别地，和假设所有模块都是针对动态 CRT 版本构建的，并且此动态 CRT 版本是可用的最新版本，我看到以下组合，其中二进制兼容是一个问题:
my_2017.exe <-> my_2015.dll-- 貌似支持my_2015.exe <-> my_2017.dll--貌似不支持my_2017.exe <-> my_2015.dll <-> my_2017_x.dll-- 现在呢，"direction" 这个受支持的 btw DLL 是什么？
由于二进制兼容 - 纯粹从 binary/interface 的角度来看 - 必须 运行 双向 ，我不太明白我们突然可以从哪里得到一个此处不兼容：API 调用可以双向（回调等），对象 "move" 双向，甚至 DLL 加载的顺序也可以混合。
恕我直言，这是很重要的一点，因为这意味着二进制兼容性 如所述 严重 受限：
- 如果我的应用程序想要使用任何
VC14*编译库，我 "officially" 仍然必须确保我的应用程序是使用 "newest version". 构建的
- 另一方面，如果不构建 "application"，但有一个 DLL，我似乎可以使用任何其他
VC14*DLL 并兼容？ - 对于 VCRedist，我们正好 看似不支持 的情况，即我们 允许从 2015 年的应用程序中使用 VC2017 库（在本例中为 CRT）！
问题
那么，为什么（！）如此受限，它与 dll 间依赖关系以及反向（！）CRT-dll 版本要求有何关系。
Microsoft 已更新其文档，当前版本 https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 的相关部分如下：
C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2019
...
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.
没有直接的 GitHub/MS-Docs 问题，但这个限制更有意义：它只是讨论 可再发行 的兼容性要求，并且要求VC 至少与正在使用的最新模块一样新的运行时版本。
这当然是有道理的，因为这不仅仅是纯粹的二进制兼容性。
当然，我在问题中所说的仍然有效：任何（旧的）VS2015 应用程序必须与（新的）VS2019 可再发行组件兼容，所以我猜所有界面表面 VCRedist- VC曾经公开的 14.0 应该是二进制兼容的。