ucrtbase 和编译器可再发行组件在程序加载时发现_how_？

Posted 2023-02-21

【中文标题】ucrtbase 和编译器可再发行组件在程序加载时发现_how_？

【英文标题】：ucrtbase and compiler redistributables found _how_ at program load time?

【发布时间】：2016-02-03 00:36:59

【问题描述】：

一些 DLL 是特殊的，操作系统将加载官方安装的副本，无论是否在 PATH 上找到另一个同名的文件。

是什么让它特别？

在早于 Win10 的 Windows 版本上，“通用 CRT”可能通过 MS 提供的官方安装程序安装。是不是碰巧把它放在了found 所在的 System32 目录中，还是它也使它特殊？

对于编译器 RTL 再分发（msvcp140.dll、vccorlib140.dll、vcruntime140.dll）也是如此。

我怀疑那些在本地放置这些文件的程序，在与 EXE 相同的目录中，并将该目录放在 PATH 上，会导致不相关的程序中的加载错误。特别是，如果在路径中找到其中一个 DLL 并且是错误的平台（32 位与 64 位），这将导致在程序尝试运行时出现一个神秘的对话框。

尽管不鼓励在本地安装上述 DLL 以支持使用官方安装程序，但这是否真的有效，或者每个应用都需要在本地安装以防止被 PATH 上完全不相关的程序损坏？

“本地安装”程序（即将所有内容解压到一个目录并从那里运行）如何应对？我对 VS2015、32 位和支持最多种类的旧操作系统特别感兴趣。

【问题讨论】：

为避免疑问，这并不能回答您的问题，但是：程序真的不应该将重新分发的 DLL 放在路径上。这是一个非常糟糕的主意。

【参考方案1】：

我意识到这是可行的，因为

安装位置是System32目录 首先检查 System32 目录，然后再检查 PATH。

因此，如果 DLL 搜索仅遵循记录的规则，则 PATH 上的其他程序不会在 DLL 实际上正确安装的情况下毒害 DLL 加载。

我没有详细检查是否有任何感兴趣的 DLL 具有除此之外的神奇行为，这样它就会忽略加载顺序和搜索选项，这些选项会导致在普通 DLL 中找到一些其他文件。但我希望操作系统知道的 ms-api-* 文件确实是硬连线的（而旧操作系统不知道的那些文件是平凡的）。