尽管Windows 11已经采用现代化的界面设计，拥有圆角窗口、Fluent Design图标以及不断扩展的云服务和人工智能功能，但在操作系统最核心的部分，仍然可以找到大量来自数十年前的历史遗留设计。其中一个典型例子，就是Windows系统文件至今仍沿用符合MS-DOS时代命名规则的短文件名。 在Windows 11 26H2中，System32系统目录内仍然存在大量看起来颇为古老的文件，例如kernel32.dll、user32.dll和ntoskrnl.exe。这些文件名并非微软随意选择的结果，而是与早期个人电脑操作系统的历史密切相关。微软资深工程师雷蒙德·陈（Raymond Chen）曾多次解释，Windows之所以长期保留这些设计，核心原因在于向后兼容性。 这种命名规则被称为8.3文件名格式。按照这一规则，文件名在扩展名之前最多只能包含8个字符，扩展名最多为3个字符，中间使用一个句点分隔。因此，一个完整的8.3文件名最多包含12个字符，包括句点在内。 例如，kernel32.dll的主文件名kernel32恰好包含8个字符，扩展名dll包含3个字符；ntoskrnl.exe同样符合这一规则；user32.dll和hal.dll也都属于典型的8.3格式文件名。 相比之下，Windows 11中一些较新的系统组件已经不再遵循这一限制。例如，Windows安全中心相关服务所使用的SecurityHealthService.exe，其主文件名远远超过8个字符。这说明微软并没有要求所有现代Windows组件继续采用旧式命名规则，而是让一些历史悠久的核心文件保留原有名称。 在MS-DOS时代，8.3格式具有明确的技术背景。当时的文件系统设计受到早期个人电脑操作系统能力的限制，文件名长度受到严格约束。文件名不能包含空格，也不能随意使用多个句点，并且只能使用规定范围内的字符。 这一限制还与更早的CP/M操作系统有关。CP/M由加里·基尔达尔于1974年开发，是早期微型计算机领域的重要操作系统之一。微软在开发MS-DOS时，十分重视与当时已有软件和使用习惯的兼容性，因此沿用了CP/M所采用的文件命名方式。 微软工程师雷蒙德·陈早在2009年就曾在个人技术博客The Old New Thing中解释过这一历史渊源。他指出，8.3命名规则实际上是从CP/M时代延续下来的遗留设计。不过，即使是长期参与Windows开发的陈，也无法确定CP/M最初为何恰好选择8个字符作为文件名长度、3个字符作为扩展名长度。 他曾推测，这可能只是当时一种方便的设计选择。根据其对早期文件系统结构的分析，CP/M的目录格式中甚至存在可以用于扩展文件名长度的空间，因此8.3并不一定是当时硬件或存储技术所能达到的绝对极限。 真正让这套旧式命名规则延续至今的，是它在操作系统发展过程中逐渐形成的兼容性依赖。 在Windows中，许多应用程序需要通过特定文件名访问动态链接库，也就是通常所说的DLL文件。程序在编译和链接过程中，会建立与相关系统组件之间的依赖关系。如果微软突然更改某个核心DLL的名称，依赖该文件的程序就可能无法按照原来的方式找到它，进而出现启动失败、功能异常或其他兼容性问题。 以user32.dll为例，它是Windows图形用户界面基础设施的重要组成部分，许多Windows应用程序都依赖其中提供的功能。假如微软决定将其改名为一个更符合现代命名习惯的名称，那么大量现有软件就可能需要相应修改。 问题在于，Windows的使用范围极其广泛，历史上开发的软件数量庞大，微软无法保证所有程序都能及时更新。即使一个文件名在今天看来不够美观或不够直观，只要仍有软件依赖它，贸然修改就可能造成难以预测的后果。 因此，Windows的文件命名规则并不是单纯的外观问题，而是涉及操作系统接口、程序依赖关系以及长期兼容性的技术问题。 微软面临的困境是，保留旧名称虽然让系统看起来不够现代，却能够避免破坏大量现有软件；如果为了统一命名风格而修改名称，则可能带来更大的兼容性风险。对于需要支持数十年软件生态的操作系统而言，前者往往是更稳妥的选择。 这种历史遗留现象并不限于8.3文件名。Windows还保留着许多来自早期DOS时代的特殊设备名称，例如CON、NUL、PRN以及COM1、LPT1等。 这些名称在现代Windows中仍具有特殊含义。例如，NUL通常被用作一个特殊的设备目标，可以将程序输出丢弃到这个目标中；CON则与控制台设备有关。它们并不是普通文件名，系统会按照既定规则对其进行特殊处理。 微软工程师雷蒙德·陈此前也解释过这些名称为何一直存在。早期DOS没有今天这种成熟的多级目录结构，但相关特殊名称已经被软件和批处理脚本广泛使用。随着操作系统增加目录层级和其他功能，微软仍然保留了这些特殊