微软是如何为DLL想出这些奇怪的名字的？
在System32:下
- outfltr.DLL
- REFIEBAR.DLL
在办公室目录下：
- dfshim.dll
- KBDFA.DLL
难道没有更好的全名来更好地理解他们的角色吗
他们是否遵循特定的命名规则
而且，当你构建DLL时，你通常会遵循一个模式来给它们命名吗？
喜欢评论Ic。也就是说，这些名称符合旧的8.3命名约定：文件名为8个字符，一个句点表示文件扩展名的开始，文件扩展名为3个字符。这是DOS时代的标准，通过16位Windows进行维护，直到32位Windows引入长文件名支持后才逐渐取消。
但是，即使支持长文件名，系统文件仍然倾向于遵循旧的8.3命名约定。有各种各样的原因，链接的文章对此进行了详细讨论。和往常一样，向后兼容性是一个很大的问题。还有一个事实是，大多数名称都是多年前在Windows NT开发过程中选择的，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开发人员，这是一个非常有效的模型。