“声明”声明是另一种绕过 .dll 地狱的方法吗？
令我惊讶的是，我发现 VB6 代码使用 Declare 语句来定义位于程序文件夹中的 .dll 中的函数，而无需在 Windows 上注册。这似乎是避免 .dll 地狱的超级简单方法，而无需诉诸使用并排清单。我可以在某处阅读更多相关内容吗？有障碍吗？
To my astonishment I found VB6 code that uses Declare statements to define functions in a .dll that lives in the Program Folder without it being registered on Windows. This seems like a supersimple way to avoid the .dll hell without having to resort to using Side by side manifests. Can I read some more about this somewhere? Are there snags?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Declare语句用于“及时”绑定到非 ActiveX DLL。在您的程序“触及”声明的入口点之前，不会尝试加载该库。它基本上与 DLL Hell 主题无关。
混乱的思维甚至会导致人们将 ActiveX DLL 放在 EXE“旁边”，这实际上会导致 DLL 地狱，因为倾向于这样做的人也使用糟糕的技术来安装和卸载应用程序。
这个故事的寓意是：
在安装时，永远、永远、永远不要将 DLL 放在 VB6 应用程序的“旁边”。如果您有不与其他应用程序共享的私有 DLL，即使也可以将它们放入应用程序文件夹下的
libs等文件夹中。可能的例外可能是非 COM DLL，例如您希望使用Declare的DLL。对于舱单也存在很多误解，误解有很多种。您可能想到的是应用程序和程序集清单。
它们可用于在并排安装的库的不同版本之间进行选择，或者可用于隔离应用程序和程序集，这是与 DLL Hell 相关的部分。
当然，应用程序清单可用于指定有关 Windows 应如何运行应用程序的许多其他内容。
The
Declarestatement is used to do "just in time" binding to non-ActiveX DLLs. Until your program "touches" a Declared entrypoint no attempt is made to load the library.It basically has nothing at all to do with the topic of DLL Hell.
Muddled thinking can even lead people to plop ActiveX DLLs "next to" the EXE which actually can result in DLL Hell because people who tend to do this also use poor techniques for installing and uninstalling applications.
Moral of the story:
Never, never, never put DLLs "next to" your VB6 application on installation. If you have private DLLs that are not shared with other applications even then put them into a
libs, etc. folder under the application folder. Possible exception might be non-COM DLLs, such as those you expect to useDeclarewith.There is also a great deal of misunderstanding about manifests, of which there are multiple kinds. The ones you are probably thinking of are application and assembly manifests.
These can be used for selecting among different versions of a library installed Side by Side, or they can be used to isolate applications and assemblies which is the part that has bearing on DLL Hell.
Of course application manifests can be used to specify quite a few other things about how Windows should run the application.
Windows 在记录良好的文件夹序列中搜索 LoadLibrary< /a> （VB6 在幕后使用它来解析 Declare 声明）。由于搜索文件夹列表中的第一个位置是应用程序自己的文件夹，因此您的发现非常有意义。
但它在很大程度上并不能解决“DLL 地狱”问题。例如，它不适用于系统 DLL，因为 Windows 预加载了其中的大部分。此外，如果 DLL 已加载到内存中，Windows 可能会使用该 DLL 的副本（不共享数据，但可以重用代码）。
这就是创建清单的部分原因；它们允许应用程序严格定义系统 DLL 所需的版本，以提供某些功能。 VB6 的技术是老式的（就像 VB6 一样）。
Windows searches in a well-documented sequence of folders for LoadLibrary (which VB6 uses behind the scenes to resolve Declare declarations). Since the first location on the list of search folders is the app's own folder, your discovery makes perfect sense.
It doesn't resolve the "DLL hell" issue for the most part, though. It can't work for system DLLs, for instance, because Windows preloads most of them. Also, if a DLL is already loaded into memory, Windows may use that copy of the DLL (not sharing data, but code can be reused).
That's part of the reason that manifests were created; they allow an application to strictly define required versions of system DLLs in order to provide certain functionality. VB6's technique is old fashioned (just like VB6).