“声明”声明是另一种绕过.dll地狱的方式吗？

Question

令我惊讶的是，我发现VB6代码使用Declare语句来定义.dll中的函数，它们存在于程序文件夹中而不在Windows上注册。这似乎是一种超级简单的方法，可以避免使用.dll地狱而不必使用并排清单。我可以在某处阅读更多有关此内容的内容吗？有障碍吗？

Answer 1

Windows在LoadLibrary的文件夹记录良好的文件夹中搜索（VB6在幕后使用它来解析Declare声明）。由于搜索文件夹列表中的第一个位置是应用程序自己的文件夹，因此您的发现非常有意义。

尽管如此，它并没有解决“DLL地狱”问题。例如，它不适用于系统DLL，因为Windows会预加载大部分DLL。此外，如果DLL已经加载到内存中，Windows可能会使用该DLL的副本（不共享数据，但可以重用代码）。

这是产生清单的部分原因;它们允许应用程序严格定义系统DLL的所需版本，以便提供某些功能。 VB6的技术是老式的（就像VB6一样）。

Answer 2

Declare语句用于“非及时”绑定到非ActiveX DLL。在程序“触摸”声明的入口点之前，不会尝试加载库。

它基本上与DLL Hell的主题毫无关系。

混乱的思维甚至可以导致人们在“EXE”旁边放置ActiveX DLL，它实际上可以导致 DLL Hell，因为倾向于这样做的人也使用糟糕的技术来安装和卸载应用程序。

1. 设计不良的应用程序部署会在EXE旁边放置一个共同的DLL或OCX。
2. 运行不正确的应用程序运行，VB6运行时无法在注册表中找到类，使用Windows启发式搜索DLL，立即找到EXE旁边的DLL并调用其自注册入口点。
3. 无辜的，设计合理的应用程序B，C，D后来安装使用相同的DLL / OCX，他们的安装人员发现已经注册的库。
4. 设计不良的应用程序A已卸载，通常只需在Program Files中删除其文件夹即可。
5. 应用程序B，C和D（以及使用该库的任何未来应用程序）现在已被破坏 - 由于孤立的组件注册指向不存在的库。

故事的道德：

永远不要永远不要在安装时将DLL放在“VB6应用程序旁边”。如果您的私有DLL未与其他应用程序共享，那么将它们放入应用程序文件夹下的libs等文件夹中。可能的异常可能是非COM DLL，例如您希望使用Declare的那些。

对于清单也有很多误解，其中有多种。您可能正在考虑的是应用程序和程序集清单。

这些可用于在并排安装的库的不同版本中进行选择，或者它们可用于隔离与DLL Hell有关的部分的应用程序和程序集。

当然，应用程序清单可用于指定Windows应如何运行应用程序的其他一些事项。