c++ - 我可以将使用 v120_xp 工具集构建的静态库链接到使用 VS2013 中的 v120 工具集构建的 EXE/DLL 吗？

Question

我正在处理一个包含四组 native C++ VS2013 项目的大型代码库。我将这些集合称为 A、B、C 和 D。

集合 A 和 B 中的项目生成 C++ 静态库 (.lib)。集合 C 和 D 中的项目生成 DLL 和可执行文件。

集合 C 中的项目仅链接到集合 A 中的静态库，而集合 D 中的项目链接到集合 A 和集合 B 中的静态库:

              C (.dll, .exe) ----> A (.lib)
                                   ^
                                   |
                                   |
                                   D (.dll, .exe) -----> B (.lib)

我有以下要求:

1. 由 C 组中的项目生成的那些 DLL 和 EXE 必须在 Windows XP 和 Windows 7 上运行；
2. 另一方面，由 D 组中的项目生成的那些 DLL 和 EXE，做不需要在 Windows XP 上运行。

我想做的是使用 v120_xp 平台工具集构建 A 组和 C 组中的项目，以及使用 v120 平台构建 B 组和 D 组中的项目工具集:

                (WinXP, Win7)
                 C [v120_xp] ----> A [v120_xp]    
                                   ^
                                   |
                                   |
                                   D [v120] -----> B [v120]
                                 (Win7 only)

I believe this should not be a problem for projects in set C ，但我关心的是 D 组中的项目。

我尝试对几个小项目执行上述操作，似乎一切正常，但在一般情况下这能保证安全吗？

---

我的研究:

点 2) 在 this question问的问题和我问的差不多，但对于 VS2012。它没有收到答复。

This answer (同样，对于 VS2012)提到:

Long story short, mixing modules that were built with a mix of v110 and v110_xp toolsets is not a problem.

This other answer to the same question ，另一方面，说:

Mixing v110_xp executables and v110 libraries is officially unsupported.

Answer 1

我真的不明白这个问题如何涵盖新的领域。 Steve-o 引用的 Microsoft 支持人员告诉他的所有内容都是准确的。他的结论是，您当然可以调用 Microsoft 支持部门寻求帮助。这是浪费金钱，他们会明确告诉您必须选择 v120_xp 工具集。

这真的很简单，如果你想让可执行文件在 XP 上运行，那么使用 v120_xp 工具集是一个硬性要求。如果你不这样做，那没关系。唯一真正重要的设置是链接器的/subsystem 选项。从 VS2012 开始，工具集对此进行了设置，以便您的可执行文件包含 6.0 作为所需的子系统。从 Vista 开始的 Windows 一代。使用 v120_xp 更改此设置，使用旧值 4.0。以 NT 4.0 开始的一代。 XP 是 5.0 代，它会拒绝运行子系统设置为 6.0 的程序

这个值确实很重要，在某种程度上，操作系统会查看它并决定打开哪个 appcompat 填充程序。 header 中的子系统设置为 4.0 时，Windows 假定您编写的代码没有考虑 Aero。几个 appcompat shim 专门用于打开谎言，让您的程序相信它仍在经典用户界面上运行。宽窗口边框是一个重要的应用程序兼容性问题，CreateWindowEx() 调用采用外部窗口大小，但许多程序真正关心客户区域的大小。

您应该担心的是在您的进程中运行多个版本的 CRT。当模块不使用相同的版本时，往往会发生相当糟糕的事情。就像 DLL 中的一个函数，它返回一个标准的 C++ 库类对象，如 std::string。当客户端代码不使用与 DLL 相同的分配器时，调用失败，它不能可靠地销毁对象。或者更糟的是，如果它使用具有完全不同布局的 std::string 对象的旧版 C++ 库。尤其是 C++11 中的变化使这种情况成为一种常见的事故。

在您的情况下，这不是您必须担心的事情。当您使用/MD 构建时，v120 和 v120_xp 工具集使用完全相同的 CRT 版本、msvcr120.dll 和 msvcp120.dll(正如您应该的那样)。该 CRT 可以在 XP 以及更高版本的 Windows 上运行，它使用 GetProcAddress() 动态绑定(bind)到可能不可用的 winapi 函数。这不是什么新东西，以前的 CRT 版本已经为像 FlsAlloc() 这样的 winapi 函数做了这个，只是更多而已。添加的内容涉及对线程和语言环境的支持。