微软是如何为DLL提出这些奇怪名称的？
在System32下：
在办公室目录下：
为了更好地理解他们的角色，还不是更好的全名吗？ 是否有他们遵循的特定命名协议？ 而且，当你构建Dll时，你通常会遵循一个模式给他们一个名字吗？
答案 0 :(得分：1)
与commenter Ic. said类似，这些名称符合旧的8.3命名约定：文件名为8个字符，表示文件扩展名开头的句点和3个字符的文件扩展名。这是DOS时代的标准版本，通过16位Windows维护，并且随着32位Windows引入了长文件名支持而逐渐解除。
但即使支持长文件名，system files still tend to adhere to the old 8.3 naming convention也是如此。链接文章详细讨论了各种原因。像往常一样，向后兼容性是一个很大的问题。然后事实上，大多数名称都是在多年前，在Windows NT的开发过程中选择的，这些名称必须在FAT卷上运行，而FAT卷不一定支持长文件名。就像Raymond所说，长文件名支持在Windows XP中无处不在，你可以找到一些使用超过8个字符的文件名的系统文件，但它们仍然相对稀少。
虽然您的一些示例来自Microsoft Office，但Office团队可能会遵循Windows团队的示例（和建议）。更不用说它们很久以前就已经被命名为Office的早期版本之一（我们现在就像版本 15 一样！），并且名称不能是现在因为向后兼容原因而改变了。
所以是的，如果情况允许，他们可能会给他们一个更好的名字。当前版本的Windows包含大量具有较长名称的文件。许多第三方软件使用名称较长的DLL。如果你这样做，你可能不会有任何麻烦。但有时候，尤其是在编写关键操作系统组件时，安全性和可接受性的保证优先于虚荣。此外，如果你的文件名对普通人来说是可以理解的，你还在乎什么？无论如何，他们不应该窥探系统文件。
其中一些也适用于第三方应用开发者。您需要选择对您和您的团队有意义的名称，但您的用户没有理由需要了解您的命名约定。这些DLL不适合他们，它们是您应用的私有支持文件。在这个时间点，对于新的开发，我不担心使用长文件名，但你仍然需要输入它们，所以没有理由狂野。
请注意，虽然这不是.NET问题，但在托管代码的世界中，事情发生了根本性的变化。虚拟文件名的长度几乎爆炸，完全放弃旧的8.3格式。您经常会看到Microsoft.VisualStudioAnalyzer.PrimaryEventCollector.dll之类的内容。托管DLL使用完全不同的机制来识别和加载，该机制基于元数据而不仅仅是文件名，因此他们不必担心困扰本机DLL的问题。如果您是.NET开发人员，那么这是一个非常有效的模型。