CRuntime 混合非问题似乎无法解释以及如何明智地升级代码库

Question

对于我对这个主题缺乏了解，我深表歉意。我对我所读到的内容有点不确定，尤其是它与我们的现实世界来源/场景之间的关系以及如何继续前进。

摆在我面前的工作是升级一个大型且古老的 VC++ 代码库（目前作为 Visual Studio 2010 项目构建和运行正常）以使用 VS2013 IDE/编译器工具。到目前为止，它已经使用 VS2010 工具和 IDE 成功构建了大约 6 年，并且被认为是稳定的。以 7 / 8 / 10 为目标。

我开始研究 VS2013 IDE/编译器/链接器升级的潜在问题，并遇到了混合 CRT 库的问题（很多警告，报告了很多问题，我对 CRT 问题了解不多）。我没想到会发现问题，因为我们的代码目前很稳定 - 但以下（？噩梦？）很快就变得明显了。

我从这里开始，这让我大开眼界： http://siomsystems.com/mixing-visual-studio-versions/

并最终发现我有以下组合：

Application.exe     statically links LIBCMT.lib using VS2010 toolchain (- but isnt LIBCMT very old, like VC6?)
lib A           statically links LIBCMT.lib. This is our library. Same as above.
lib B           statically links LIBCMT.lib. This is our library. Same as above.
lib C           statically links with "-MT". Not our library (& no clue as to which version of LIBCMT. Could be anything)
dll 1           dynamically links MSVCRT.dll. Not our dll. (again, isnt this VC6, or very old? Reading suggests could be v4.2 - v6)
dll 2           as dll1
Windows dlls...     Many of these. Eg, wininet, depends on MSVCRT.dll (MSVCR1xx version expected, but old MSVCRT referenced!)

（为了找到依赖关系，我在库中搜索了“cl.exe”并记下了编译选项或使用了dumpbin。）

现在，为了增加我的不确定性，Visual Studio 调试器“模块”窗口只显示一个 MSVCRT.dll。也许这就是它看起来稳定的原因（？） - 但我希望上面显示的依赖项能够发挥作用 - 而不是那些旧的 MSVCRT 引用（Ps。我已经练习了那些 libs/dlls 以在运行时访问它们的功能 & 看到没有更改为加载的模块）。

所以，我的问题：

1. 很明显，但是：其他人是否与我一样关注此应用程序中明显混合的 C 运行时？

2. 据我所知**，跨 dll 边界传输的数据类型只是基元和基元数组。在不同的 CRT 中没有创建/释放内存，没有传递文件指针，没有请求环境变量等，AFAIK。此外，没有从共享标头实例化的结构。如果我在这方面绝对正确，这可能是混合 CRT 可以与我的应用程序一起工作的原因吗？

** 我确实需要彻底检查这是否属实。

1. 在迁移到 VS2013 工具链（编译器/链接器）时，我想更改我们的 exe 和库以使用动态 CRT。我的概念是尽量减少 CRT 的任何可能组合，所以我认为最好的计划是让尽可能多的库使用单个动态 CRT（MSVCR120.dll？） - 正如我在某处读到多个动态 CRT 的地方被加载，一个单一的将实际使用。有人可以确认是这种情况吗？这是一个合理的策略吗？或者，有了这样的图书馆遗产，有没有更好的方法？

2. 如果单个 MSVCRxxx 版本将由多个 dll/lib 加载，我们可以说它将/应该在任何特定的 Windows 7/8/10 pc 上吗？ （例如，最旧版本、最新版本、加载的第一个需求？）

我可能想多了，但是网上的各种警告和我看似混合的 CRT 应用程序让我担心。

我认为这涵盖了它。非常感谢任何意见。

感谢阅读。

2016 年 7 月 20 日编辑： 我刚刚看到这篇文章，我认为它与考虑相同问题的任何人相关：http://www.davidlenihan.com/2008/01/choosing_the_correct_cc_runtim.html

谢谢！

Answer 1

我相信您的#3 策略是最好的方法。在您的示例案例中，lib C 可能是一个问题。 如果在 "."microsoft DLL search order link. 中找不到，则加载的确切 DLL 由 %PATH% 环境变量指定 您可以使用 Microsoft 的 Dependancy walker depends.exe 查看应用程序将使用哪些 DLL。

这应该可以解决除您的 LibC 案例之外的所有问题。