微软解释 Windows 11 为何仍沿用 MS-DOS 文件名，以及为何无法更改它们

为什么 Windows 11 的核心系统文件仍沿用 DOS 时代的名称

Windows 11 26H2 是微软最新的桌面操作系统版本，但其中一些最重要的文件，包括 kernel32.dll、user32.dll 和 ntoskrnl.exe，名称看起来却像是为 MS-DOS 编写的。它们遵循一种名为 8.3 的旧命名规则，而 Windows 保留这套规则是为了确保兼容性。

Raymond Chen在 Windows 团队工作了 30 多年。他曾解释过，为什么微软宁愿沿用一种缺点早已广为人知的格式，也不愿换用可能引发其他问题的新格式。

在我运行 Windows 11 26H2 的电脑上，文件资源管理器采用了圆角和 Fluent 图标，但它们掩盖不了 System32 文件夹里那些看起来仿佛属于 1990 年软盘时代的文件名。

Windows 11 26H2 的 System32 文件夹中，kernel32.dll 等核心文件仍采用 8.3 格式命名。图片来源：Windows Latest

什么是 8.3 文件名？MS-DOS 为什么要采用这种格式？

可能有人不知道，8.3 是 MS-DOS 使用的文件命名规则（没错，历史相当悠久）。文件名中，点号前最多可有 8 个字符，点号后最多可有 3 个字符（即扩展名），所以 8.3 文件名最长为 12 个字符，包含点号。微软的文件系统规范还规定，8.3 文件名只能使用 ASCII 字符，不能包含空格，也不能有多个点号。

System32 中一些最古老的文件遵循这项规则，而 Windows 安全中心服务等较新的组件则完全不符合。

文件名名称 + 扩展名符合 8.3 格式？kernel32.dll8 + 3是ntoskrnl.exe8 + 3是user32.dll6 + 3是hal.dll3 + 3是SecurityHealthService.exe21 + 3否

 

MS-DOS 会以大写形式显示这些名称，所以如果你在 90 年代用过电脑，KERNEL32.DLL 可能会更眼熟。Windows 默认不区分文件名的大小写，因此 kernel32.dll 和 KERNEL32.DLL 基本上是同一个文件。

但为什么限制是 8 个字符加 3 个字符？Chen 在 2009 年发表于 Old New Thing 博客的一篇文章中解释过：“这是从 CP/M 沿袭下来的。” CP/M 是 Gary Kildall 于 1974 年为早期微型计算机开发的操作系统。MS-DOS 努力保持与 CP/M 的兼容性，文件名也不例外。

有意思的是，就连 Chen 也不知道 CP/M 为什么选了这两个数字。他指出，CP/M 目录格式中有两个保留字节，本可以将名称长度扩展到 10.3；他猜测，8 只是个方便的数字。

Windows 11 26H2 的 System32 文件夹中，ntoskrnl.exe 等核心文件仍采用 8.3 格式命名。图片来源：Windows Latest

当然，在 Windows 11 中，8.3 只是沿袭下来的命名习惯。默认文件系统 NTFS 支持最长 255 个字符的文件名，而 Windows 从 90 年代中期起就支持长文件名了。

Raymond Chen 解释：Windows 为何让最古老的系统文件继续使用 8.3 名称

早在 2007 年的一篇文章中，Chen 就曾推测过一些可能的原因，但这些并非微软的官方说法。

最显而易见的原因是，程序一旦与某个 DLL 建立链接，就不能更改它的名称，因为程序会按名称查找该文件。如果微软明天把 user32.dll 改了名，几十年来的 Windows 应用就会去寻找一个已经不存在的文件。没错，这就是为了兼容性！

Windows 95 也不要求系统盘支持长文件名，部分原因是使用漫游配置文件的公司可能依赖无法处理长文件名的服务器，因此每个 Windows 95 系统文件都必须符合 8.3 格式。Chen 认为，直到 Windows 2000，Windows NT 仍允许系统盘使用只支持短文件名的 FAT；而长文件名直到 Windows XP 才成为必需。

即使到了 XP 时代，长文件名也带来了一些额外麻烦。Windows 可以为每个长文件名生成一个短别名。比如，如果安装程序要把 shellstyle.dll 复制到一个已有 shellstuff.dll 的文件夹中，新文件很可能会被命名为 SHELLS~2.DLL。一些程序会将这些别名写死在代码中，而 Chen 表示，许多应用都假定 Program Files 位于 C:\PROGRA~1。

出于好奇，我在运行 26H2 的电脑 C 盘上执行了 dir /x，发现 Program Files 仍显示为 PROGRA~1。微软的 NTFS 文档解释了原因：新格式化的卷默认禁用短文件名，但系统卷会继续启用，以保证应用兼容性。

Windows 11 命令提示符中运行 dir x 后，Program Files 旁显示 PROGRA~1。图片来源：Windows Latest

风险在于同一个 DLL 可能有两个名称。Windows 加载程序会把 DLL 的短名称和长名称视为两个不同的模块，因此一个进程可能在内存中加载同一 DLL 的两个副本，各自拥有独立的全局变量。Chen 将这种情况比作自己小时候去迪士尼乐园：他和弟弟在 Autopia 项目的一个出口等着，父母却在另一个出口等着，双方都不知道有两个出口。这经历恐怕挺令人难受！

Chen 提出的最后一个理由最让我信服。他写道：“8.3 名称带来的所有问题都已为人熟知，也都在掌控之中。”他还补充说，在一个已经运转良好的系统中改用长文件名，只会带来一整套全新的问题。

在我看来，这个理由到了 2026 年更站得住脚。微软正在用 WinUI 3 重写已有数十年历史的对话框，而新的“属性”对话框甚至还得兼顾那些会给旧版对话框添加自定义选项卡的第三方应用。重命名 kernel32.dll 会造成远不止几个选项卡的问题，也不会让电脑变得更快或更安全。

讽刺的是，许多人认为未来会取代 NTFS 的文件系统 ReFS 已不再支持短文件名。如果旧应用在 ReFS 驱动器上查找 8.3 格式的文件，就会直接崩溃。这恰好说明了微软为何没有改动 NTFS 上的 System32 文件名。

所以下次在蓝屏崩溃报告中看到 ntoskrnl.exe 时，不妨想想：它的名称遵循的是 Windows 从一款 1974 年的操作系统继承下来的规则，而微软有充分理由让它保持原样。Chen 在 2003 年谈到旧界面时也表达过类似观点：拥有数千名员工的公司讨厌界面改动，因为重新培训的成本高达数百万美元。你愿意为了让 System32 看起来更整洁，而让应用无法启动吗？我可不愿意。