地狱图书馆(又名 DLL 地狱)

发布于 2024-09-10 14:04:10 字数 609 浏览 2 评论 0原文

在我的一个项目中,我使用一个 Delphi 应用程序,它动态加载一个包装器 DLL(导出 C 风格函数),而该包装器 DLL 又静态链接到一堆第三方 DLL。

它在我的测试机器上工作正常,但在我的客户计算机上,它无法初始化,并出现错误消息,例如“在 TMYlibrary.dll 中找不到入口点 _somefunction@4AKKZ”。

经过对 sysinternal 的进程监视器进行一些调查后,我意识到 Windows 会首先在 windows/sytem32 中查找 DLL,因此如果 system32 中存在名为类似于 my DLL 的 DLL,Windows 会选择该DLL并尝试在其中找到我的函数入口点 - 这会失败。

您知道可以更改 Windows DLL 的搜索行为吗?


其他信息

  • [更新] .exe 文件位于应用程序文件夹树的顶层。
  • Wrapper 和第 3 方 DLL 均位于我的应用程序文件夹的子文件夹 /bin 中,
  • 开发平台是 windows XP/7,使用 VS2008 作为 dll,使用 Delphi 2010 作为应用程序

In a Project of mine, I use a Delphi Application which dynamically loads a wrapper DLL (exporting C-Style functions) which in turn is statically link against a bunch of 3rd party DLLs.

It works fine on my test machines, but on my customers computer it failed to initialize with an error Message like "Couldn't find entrypoint _somefunction@4AKKZ in TMYlibrary.dll".

After some investigation with sysinternal's process monitor, I realized that Windows would look fror DLLs in windows/sytem32 first, so if a DLL named similar to my DLL was present in system32, windows would pick that one and try to find my function entry points in it - which would fail.

Do you know of a possiblity to change windows' DLL the searching behaviour?


Additional Information

  • [Update] The .exe file is located on the top level of the application's folder tree.
  • The Wrapper and the 3rd-party-DLLs ar e both located in the Subfolder /bin of my apps Folder
  • Dev platform is windows XP/7, using VS2008 for the dlll and Delphi 2010 for the application

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

无人接听 2024-09-17 14:04:10

我自己找到了另一个解决方案:

SetDllDirectory 在要查看的位置列表中添加了一个额外的搜索路径。

来自 http://msdn.microsoft.com /en-us/library/ms686203%28v=VS.85%29.aspx

调用SetDllDirectory后,DLL搜索路径为:

  1. 加载应用程序的目录。
  2. 由 lpPathName 参数指定的目录。
  3. 系统目录。使用 GetSystemDirectory 函数获取
    该目录的路径。的名字
    该目录是System32。
  4. 16 位系统目录。没有函数可以获取
    该目录的路径,但它是
    搜索过。该目录的名称
    是系统。
  5. Windows 目录。使用GetWindowsDirectory函数获取
    该目录的路径。
  6. PATH 环境变量中列出的目录。

(也许我应该在发帖之前先用谷歌搜索一下;)

I found another solution myself:

SetDllDirectory adds an additional search path to the list of locations to look at.

From http://msdn.microsoft.com/en-us/library/ms686203%28v=VS.85%29.aspx

After calling SetDllDirectory, the DLL search path is:

  1. The directory from which the application loaded.
  2. The directory specified by the lpPathName parameter.
  3. The system directory. Use the GetSystemDirectory function to get the
    path of this directory. The name of
    this directory is System32.
  4. The 16-bit system directory. There is no function that obtains the
    path of this directory, but it is
    searched. The name of this directory
    is System.
  5. The Windows directory. Use the GetWindowsDirectory function to get
    the path of this directory.
  6. The directories that are listed in the PATH environment variable.

(maybe i should do my googling before I post on SO ;)

淤浪 2024-09-17 14:04:10

将 DLL 发送到程序的文件夹中。 (与exe文件相同)。

那么 Windows 应该首先尝试您的版本。

Ship the DLL in your program's folder. (same as the exe file).

Then Windows should try your version first.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文