0

微软是如何为 DLL 想出这些奇怪的名字的？

在 System32 下：

  • OUTLFLTR.DLL
  • REFIEBAR.DLL

在办公室目录下：

  • dfshim.dll
  • KBDFA.DLL

不是更好的全名来更好地理解他们的角色吗？
他们遵循特定的命名惯例吗？
而且，当您构建 Dll 时，您通常会遵循一种模式来给它们命名吗？

4

1 回答 1

2

就像评论者 Ic。说，这些名称符合旧的 8.3 命名约定：文件名由 8 个字符组成，一个句点表示文件扩展名的开始，以及一个 3 个字符的文件扩展名。这是 DOS 时代的标准，通过 16 位 Windows 维护，并且随着 32 位 Windows 引入长文件名支持而逐渐取消。

但即使支持长文件名，系统文件仍然倾向于遵循旧的 8.3 命名约定。有多种原因，链接的文章对此进行了详细讨论。像往常一样，向后兼容性很重要。还有一个事实是，大多数名称都是多年前选择的，当时是在 Windows NT 的开发过程中，它必须在不一定支持长文件名的 FAT 卷上运行。就像 Raymond 所说，长文件名支持在 Windows XP 中变得无处不在，在那里您可以找到一些使用超过 8 个字符的文件名的系统文件，但它们仍然相对较少。

尽管您的一些示例来自 Microsoft Office，但 Office 团队可能会遵循 Windows 团队的示例（和建议）。更不用说很久以前它们可能被命名为 Office 的早期版本之一（我们现在使用的是版本15！），并且由于向后兼容性的原因，现在无法更改名称。

所以是的，如果情况允许，他们可能会给他们一个更好的名字。当前版本的 Windows 包含大量名称较长的文件。许多第三方软件使用名称较长的 DLL。如果你这样做，你可能不会有任何麻烦。但有时，尤其是在编写关键操作系统组件时，安全性和可接受性的保证比虚荣心更重要。此外，如果您的文件名对于普通人来说是可以理解的，您在乎什么？无论如何，他们不应该窥探系统文件。

其中一些也适用于第三方应用程序开发人员。您需要选择对您和您的团队有意义的名称，但您的用户没有理由需要了解您的命名约定。DLL 不适合它们，它们是您的应用程序的私有支持文件。在这个时间点，对于新的开发，我不会担心使用长文件名，但你仍然需要输入它们，所以没有理由疯狂。

请注意，尽管这不是 .NET 问题，但托管代码领域的情况发生了根本性的变化。文件名的长度几乎爆炸了，完全放弃了旧的 8.3 格式。您经常看到类似Microsoft.VisualStudioAnalyzer.PrimaryEventCollector.dll. 托管 DLL 使用基于元数据而不仅仅是文件名的完全不同的机制来识别和加载，因此它们不必担心困扰本机 DLL 的问题。如果您是 .NET 开发人员，那么这是一个完全有效的模型。

于 2013-07-23T11:42:02.417 回答