尽管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没有今天这种成熟的多级目录结构，但相关特殊名称已经被软件和批处理脚本广泛使用。随着操作系统增加目录层级和其他功能，微软仍然保留了这些特殊名称的行为，以免破坏现有程序。
这一例子说明，Windows并不是一个完全按照现代设计原则重新构建的系统，而是在长期发展过程中不断叠加新功能，同时尽可能保留旧有行为。很多看似过时的细节，实际上已经成为整个软件生态的一部分。
当然，8.3文件名规则并不意味着现代Windows的所有文件都必须受到同样限制。Windows今天支持远远长于8个字符的文件名，也能够处理包含空格和多种Unicode字符的名称。微软的官方文件命名文档还描述了多种文件路径和命名空间规则，允许应用程序在符合相应条件的情况下访问更长的路径。
因此，Windows 11仍然存在符合8.3格式的系统文件，并不代表操作系统仍然使用MS-DOS作为底层运行环境。Windows NT系列拥有独立的内核和系统架构，现代Windows与早期DOS在技术基础上有很大差异。这里延续下来的主要是文件名称以及相关兼容行为，而不是整个操作系统仍受DOS的技术限制。
这也解释了为什么微软能够在现代Windows中引入新的文件系统、改进安全机制并增加人工智能功能，却仍然保留一些看起来极为古老的系统文件名称。操作系统的现代化并不意味着所有历史设计都可以随意删除。
对于普通用户而言，这些名称通常不会造成实际使用上的问题。Windows会通过系统机制处理相关文件，用户不需要因为kernel32.dll或ntoskrnl.exe看起来像几十年前的文件名，就担心系统仍然停留在MS-DOS时代。
真正值得关注的是，Windows的发展始终需要在创新与兼容性之间寻找平衡。对于一个拥有庞大软件生态的操作系统来说，历史遗留设计有时并不是因为开发者没有能力改进，而是因为修改它们的代价可能远远高于保留它们。
从8.3文件名到特殊设备名称，Windows中的许多古老规则都在提醒人们：软件系统并不像普通产品那样，可以通过一次重新设计就彻底抛弃过去。只要旧接口仍被大量程序使用，它们就可能继续存在几十年。
而这或许正是Windows能够长期维持广泛软件兼容性的原因之一。即使操作系统的界面已经发生巨大变化，微软仍然需要确保数十年前开发的软件能够在今天的电脑上继续运行。对于Windows而言，保留这些看似过时的文件名，并不是单纯的历史包袱，更是维持整个软件生态连续性所付出的代价。