Ветеран Microsoft Рэймонд Чен объяснил, почему компания предпочитает применять структура имён файлов в стиле MS‑DOS даже в Windows 11. Так, в версии 26 H2 можно встретить kernel32.dll, user32.dll и ntoskrnl.exe. Они следуют старому стандарту именования, известному как «8.3», который Windows сохраняет ради обратной совместимости.

8.3 — это правило именования файлов, применявшееся в MS‑DOS. Имя может содержать до восьми символов до точки и до трёх символов после неё; таким образом, максимальная длина имени в формате 8.3 составляет 12 символов, в том числе точку. В соответствии с спецификации файловой системы Microsoft, имена в формате 8.3 могут состоять только из символов ASCII, не должны содержать пробелов и могут включать не более одной точки.

Некоторые из старейших файлов в папке System32 следуют этому правилу, в то время как более современные компоненты — например, служба «Защита Windows» (Windows Security) — совершенно ему не соответствуют. В MS‑DOS такие имена отображались заглавными буквами, поэтому вариант KERNEL32.DLL может показаться более привычным тем, кто пользовался ПК в 90-х годах. Windows по умолчанию не учитывает регистр при работе с именами файлов, поэтому kernel32.dll и KERNEL32.DLL — это, по сути, один и тот же файл. 

Чен объяснил ограничения символов ещё в 2 009 году в своём блоге «The Old New Thing». «Это наследие операционной системы CP/M», — написал он. CP/M — это операционная платформа, созданная Гэри Килдаллом в 1 974 году для ранних микрокомпьютеров; платформа MS‑DOS стремилась сохранить с ней полную совместимость, в том числе в отношении имён файлов.

При этом даже Чен не знает, почему в CP/M были выбраны именно такие числа. Он отмечает, что два зарезервированных байта в формате каталога CP/M могли бы позволить увеличить длину имён до формата «10.3», и предполагает, что число 8 было просто удобным выбором. Разумеется, в Windows 11 формат «8.3» — это только устоявшаяся традиция именования. Файловая платформа NTFS, используемая по умолчанию, поддерживает длинные имена файлов, а сама Windows работает с длинными именами ещё с середины 90-х годов.

В одной из своих более ранних публикаций, датированной 2 007 годом, Чен рассуждал о возможных причинах этого — не опираясь на официальную позицию Microsoft. Самая очевидная причина заключается в том, что имя DLL‑файла нельзя изменить, если к нему уже привязаны другие программы, поскольку они ищут файл именно по его имени. Если бы Microsoft завтра переименовала user32.dll, то множество приложений для Windows, созданных за последние десятилетия, просто не смогли бы найти нужный файл. 

В Windows 95 системный диск не обязан был поддерживать длинные имена файлов — отчасти потому, что компании, использующие перемещаемые профили пользователей, могли зависеть от серверов, которые не умели функционировать с такими именами. Следовательно все системные файлы Windows 95 должны были соответствовать формату «8.3». По мнению Чена, в Windows NT системный диск с файловой системой FAT допускался вплоть до версии Windows 2000, а обязательная поддержка длинных имен появилась только в Windows XP.

Даже после выхода XP использование длинных имён было сопряжено с определёнными издержками. Windows может разрабатывать короткий псевдоним для каждого длинного имени: в частности, если в папку, где уже есть файл shellstuff.dll, копируется файл shellstyle.dll, то новый файл, скорее всего, получит имя SHELLS~2.DLL. Некоторые программы жёстко прописывают такие псевдонимы в своем коде; по словам Чена, многие приложения «рассчитывают» на то, что папка Program Files находится по адресу C:\PROGRA~1. 

Проблема заключается в том, что один и тот же DLL‑файл может фигурировать под двумя разными именами. Загрузчик Windows воспринимает короткое и длинное имена одного и того же DLL‑файла как два различных модуля. В результате в памяти процесса могут оказаться две копии файла, каждая со своими собственными глобальными переменными. 

«Все проблемы, связанные с именами формата 8.3, хорошо изучены и находятся под контролем», — пишет Чен, добавляя, что переход исключительно на длинные имена лишь породил бы массу новых сложностей в системе, которая и так исправно работает.

Сейчас Microsoft занимается переработкой диалоговых окон, созданных десятилетия назад, переводя их на платформу WinUI 3; при этом даже новое окно свойств должно учитывать наличие сторонних приложений, которые добавляют в старый интерфейс свои собственные вкладки. Переименование kernel32.dll привело бы к гораздо более серьёзным последствиям, чем просто исчезновение нескольких вкладок, при этом компьютер не стал бы ни быстрее, ни безопаснее.

Ещё в 2 003 году Чен приводил аналогичный довод в отношении устаревших элементов интерфейса: компании, в которых трудятся тысячи сотрудников, чрезвычайно негативно относятся к любым изменениям в интерфейсе, поскольку переобучение персонала обходится в миллионы. 

Ранее Чен объяснил, почему одновременное использование нескольких антивирусных программ в одной системе Windows — не лучшая идея.