Коротко о главном
Откройте C:\Windows\System32 на Windows 11 26H2, и среди современных файлов вроде SecurityHealthService.exe вы увидите kernel32.dll, user32.dll, ntoskrnl.exe и hal.dll. Все они укладываются в формат 8.3: до восьми символов в имени, точка, до трёх символов в расширении.
Это не случайность и не забывчивость Microsoft. Правило 8.3 пришло из CP/M, операционной системы 1974 года, с которой MS-DOS старалась сохранять совместимость. Windows 11 унаследовала его вместе с десятилетиями зависимостей, которые делают простое переименование технически возможным, но крайне рискованным.
Именно поэтому в 26H2 Program Files по-прежнему отвечает на PROGRA~1, а Microsoft не спешит отказываться от коротких имён даже там, где современный NTFS давно поддерживает длинные.
Что такое 8.3 и откуда он взялся
8.3 это соглашение об именовании файлов, которое допускает:
- До восьми символов в основной части имени.
- Точку как разделитель.
- До трёх символов в расширении.
- Только ASCII-символы, без пробелов и без нескольких точек.
Полное имя вместе с точкой не больше 12 символов. kernel32.dll ровно 8 + 3. user32.dll 6 + 3. hal.dll 3 + 3. Все они идеально вписываются в формат.
Откуда взялись именно 8 и 3? Точного ответа нет даже у Microsoft. Рэймонд Чен, ветеран Windows и автор блога The Old New Thing, объяснял, что MS-DOS унаследовала 8.3 от CP/M, но почему CP/M выбрала именно такие числа, он не знает. В структуре каталога CP/M было два зарезервированных байта, которые теоретически позволяли расширить имя до 10.3, но этого не сделали. Возможно, восемь просто показалось удобным числом.
MS-DOS, в свою очередь, тщательно старалась быть совместимой с CP/M, и это одна из причин, почему формат закрепился на десятилетия.
Почему Windows 11 до сих пор это использует
Причина не в том, что Windows 11 «не умеет» длинные имена. NTFS поддерживает имена до 255 символов, и современные компоненты системы этим пользуются: SecurityHealthService.exe 21 символ в основной части, и это никого не смущает.
Проблема в контракте совместимости. Когда миллионы программ ищут файл по конкретному имени, это имя перестаёт быть просто меткой и становится частью системного контракта. Если переименовать kernel32.dll, программа, которая загружает его по имени, просто не найдёт файл.
Рэймонд Чен предполагал, что именно это главная причина, по которой Microsoft десятилетиями не трогает старые имена: программы могут линковаться с DLL по имени, и смена имени сломает их.
Исторически это усугублялось ещё и тем, что Windows 95 не требовала от системного диска поддержки длинных имён. Часть предприятий использовала roaming-профили и серверы, которые не умели работать с длинными именами. Только в Windows XP длинные имена стали обязательным условием.
Пример PROGRA~1: как короткие имена работают сегодня
Классический пример C:\PROGRA~1. Это короткий алиас для C:\Program Files, который Windows генерирует автоматически для совместимости со старым ПО.
Современный NTFS может хранить длинное имя и автоматически создавать короткий алиас с тильдой и номером. Если в папке уже есть shellstuff.dll, а установщик копирует shellstyle.dll, новый файл может получить имя SHELLS~2.DLL, то есть короткое имя генерируется с учётом конфликтов.
Проблема в том, что некоторые программы используют короткие имена напрямую, не потому, что им так удобно, а потому, что когда-то это было единственным способом обратиться к файлу. В итоге «мостик» между поколениями систем превратился в самостоятельную зависимость.
Почему нельзя просто взять и переименовать
На первый взгляд решение кажется простым: переименовать kernel32.dll во что-то более описательное и добавить алиас для совместимости. Но на практике это упирается в несколько проблем.
Первая: линковка по имени. Если программа загружает библиотеку через LoadLibrary("kernel32.dll") или линкуется с ней по имени, переименование без forwarding-механизма сломает её. Технически forwarding shim возможен, но это дополнительный слой сложности и риска.
Вторая: две копии одной DLL. Это самый неочевидный и самый важный аргумент. Если системный файл имеет и длинное имя, и короткий алиас, и две разные части программы загружают его по разным именам, Windows может загрузить две отдельные копии одной и той же DLL в адресное пространство процесса.
Чен демонстрировал это на примере: вызов LoadLibrary("SHELLS~1.DLL"), а затем LoadLibrary("SHELLSTYLE.DLL") приводит к тому, что загрузчик модулей создаёт два разных экземпляра одной библиотеки по разным базовым адресам. Для системы это означает рассинхронизацию состояния, двойной расход памяти и потенциальные ошибки, которые очень трудно диагностировать.
Именно поэтому Microsoft не спешит добавлять длинные имена там, где уже есть короткие: риск получить две копии одного компонента выше, чем выгода от косметического переименования.
Можно ли отключить 8.3 и что будет
Технически отключить создание новых коротких имён можно. Для этого есть команда fsutil 8dot3name, которая позволяет:
-
Запросить текущее состояние:
fsutil 8dot3name query C:. - Изменить поведение для системы или отдельного тома.
- Просканировать зависимости в реестре.
- Удалить существующие короткие имена.
Важно различать два действия:
Отключение создания новых 8.3-имён относительно безопасная операция. Она может ускорить файловые операции на томах с миллионами файлов. Пользователи сообщали об ускорении просмотра папок, поиска и копирования, особенно при работе с внешними дисками и Android-устройствами через USB или FTP. Dell документировала заметное улучшение пропускной способности NTFS на томах с миллионами файлов.
Удаление существующих коротких имён это рискованная операция. Microsoft прямо предупреждает: если удалить 8.3-имена, не проверив записи реестра и зависимости приложений, можно получить непредсказуемые сбои, включая невозможность удалить программу.
Именно поэтому Microsoft не рекомендует слепо следовать советам «отключить 8.3 для ускорения Windows 11»: выигрыш в производительности реальный, но цена в виде сломанных приложений и установщиков может оказаться выше.
Что будет, если полностью отказаться от старых имён
Гипотетически Microsoft могла бы пойти на это, но последствия были бы масштабными:
- Сломались бы программы, которые линкуются с системными DLL по имени.
- Появились бы дубликаты DLL в памяти из-за двух разных имён.
- Установщики и деинсталляторы могли бы перестать работать, если они ссылаются на короткие имена в реестре.
- Старые корпоративные приложения и сценарии развёртывания, рассчитанные на 8.3, перестали бы работать.
Именно поэтому Microsoft выбирает постепенность: новые компоненты получают длинные имена, а старые ядровые файлы остаются как есть. Это не «лень» и не «забывчивость», а осознанный инженерный компромисс между совместимостью и модернизацией.
Часто задаваемые вопросы
Почему kernel32.dll называется именно так, а не длиннее?
Потому что имя укладывается в формат 8.3, унаследованный от CP/M через MS-DOS. Переименование сломало бы совместимость с программами, которые ищут этот файл по имени.
Почему в Windows 11 26H2 всё ещё есть PROGRA~1?
Это короткий алиас для Program Files, который Windows генерирует для совместимости со старым ПО. Некоторые программы используют его напрямую.
Можно ли отключить 8.3 и ускорить Windows?
Отключить создание новых коротких имён можно через fsutil 8dot3name, и это может ускорить файловые операции на больших томах. Но удаление существующих имён рискованно и может сломать приложения или установщики.
Почему нельзя просто переименовать системные DLL?
Программы могут линковаться с ними по имени. Кроме того, если одна и та же DLL загружается по короткому и длинному имени, Windows может создать две копии в памяти, что приведёт к ошибкам и лишнему расходу памяти.
Microsoft когда-нибудь откажется от 8.3?
Компания постепенно добавляет длинные имена для новых компонентов, но ядровые файлы остаются короткими. Полный отказ потребовал бы масштабной переработки совместимости и, вероятно, не произойдёт в обозримом будущем.
Опасно ли отключать 8.3 на домашнем ПК?
Отключение создания новых имён обычно безопаснее, чем удаление существующих. Но перед любыми изменениями стоит сделать резервную копию и протестировать систему. Microsoft не рекомендует удалять существующие короткие имена без анализа зависимостей.
Что в итоге
Windows 11 26H2 выглядит современно, но в её ядре до сих пор живут имена файлов, придуманные для CP/M и MS-DOS. Это не техническое ограничение, а следствие десятилетий совместимости: программы линкуются с DLL по имени, а некоторые используют короткие алиасы вроде PROGRA~1 напрямую.
Отключить создание новых 8.3-имён можно и иногда это даёт прирост производительности, но удаление существующих имён рискованная операция, которая может сломать приложения и установщики. Microsoft выбирает постепенность: новые компоненты получают длинные имена, а старые остаются как есть. Это не идеально, но это цена за то, что программы, написанные десятилетия назад, продолжают работать.
