windows - COM 服务器 DLL 依赖项的搜索规则

Question

考虑 Windows 上的以下文件组织:

[app folder]
    app.exe
    [folder 'sub']
        com_server.dll
        regular.dll
        helper.dll

还假设以下情况:

• com_server.dll 和 regular.dll 都静态链接到 helper.dll 中的函数，因此 helper.dll 在加载时加载。
• app.exe 没有静态依赖。
• com_server.dll COM 对象已在 Windows 中注册
• 文件夹“sub”不在系统路径中。

考虑以下情况:

1. app.exe 调用 LoadLibrary( "sub/regular.dll")。这将失败，因为 Windows 将无法找到 helper.dll，这与记录的 DLL 搜索过程一致。
2. app.exe 调用 CoCreateInstance 来创建在 com_server.dll 中实现的对象。这将成功并加载 helper.dll。

主要问题:为什么案例 2 有效？ COM服务器案例的依赖DLL搜索过程的细节是什么？

看起来，当使用 CoCreateInstance 创建 com 对象时，实现 dll 的文件夹会以某种方式添加到依赖项的搜索路径中。这就是正在发生的事情吗？这是有保证的吗？我在任何地方都找不到讨论此案例的任何文档。

Answer 1

让我们看看 LoadLibrary on MSDN 的文档:

If the string specifies a full path, the function searches only that path for the module. If the string specifies a relative path or a module name without a path, the function uses a standard search strategy to find the module; for more information, see the Remarks.

好的，这就解释了上面 #1 的行为。如果你说:

LoadLibrary("C:\\program files\\AppFolder\\Sub\\com_server.dll")

然后它会找到您的依赖 DLL，并且 LoadLibrary 会成功。

至于 COM 如何在 #2 中取得成功，这实际上取决于 com_server.dll 在注册表中为 InProcServer32 项注册的方式。如果它是文件的完整路径，则 LoadLibrary 将按上述方式工作。如果它是相对路径，那么我怀疑 COM 可能会做很多事情来使查找像您这样的 DLL 工作。

一种可能的可能性是 CoCreateInstance 正在调用 LoadLibraryEx设置了 LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR 标志。它甚至可以使用不同的标志组合多次调用 LoadLibrary(Ex)。

另外，考虑到 CoCreateInstance 是一个系统 API，它完全有可能有一个私有(private)的 LoadLibrary 内部版本，允许备用搜索路径。