Наследие прошлого в современной Windows 11
Windows 11 выглядит как современная операционная система: скругленные углы, дизайн Fluent, глубокая интеграция облачных сервисов и множество технологий, которые десятилетия назад показались бы невероятными. Однако за этим фасадом скрываются архитектурные решения, существующие уже очень долгое время.
Каждый раз, когда вы сохраняете файл, подключаете накопитель или вводите путь в командной строке, вы сталкиваетесь с правилами, сформированными в эпоху, когда объем памяти ПК измерялся в килобайтах, а место на диске требовало бережного отношения. Современная Windows работает на архитектуре Windows NT, заменившей фундамент MS-DOS на более надежную основу. Тем не менее, Microsoft пришлось сохранить конвенции, к которым было привязано существующее ПО для DOS и Windows. Некоторые из этих идей восходят к системе CP/M, предшествовавшей даже IBM PC, и со временем они стали неотъемлемой частью API Windows, скриптов, установщиков и привычек пользователей.
Почему нельзя назвать файл запрещенным именем
Если в Проводнике создать текстовый документ и попытаться назвать его CON, Windows отклонит действие. То же самое произойдет с именами PRN, AUX, NUL, COM1, LPT1 и рядом других. Смена расширения не поможет: файлы вроде CON.docx или NUL.pdf также непригодны для использования.
Причина этого кроется в MS-DOS 1.0, когда система обращалась к аппаратным устройствам по именам, доступным для ПО как файлы. Программа могла отправить данные на принтер, записав их в PRN. CON обозначал консоль (клавиатуру и экран), AUX относился к вспомогательному последовательному устройству, а NUL работал как «черная дыра» для отбрасываемых данных. Поскольку в DOS 1.0 не было каталогов, двусмысленности не возникало.
Когда в DOS 2.0 появились подкаталоги, эти имена устройств должны были функционировать независимо от текущей папки. Команда вроде COPY FILE.TXT PRN должна была означать «отправить файл на принтер», а не «создать здесь файл с именем PRN». Microsoft сохранила эту интерпретацию, и Win32 до сих пор резервирует эти имена как устройства в стиле DOS. Спустя более сорока лет ПО и скрипты все еще ожидают, что NUL и CON будут работать так же, как на ранних машинах с DOS.
Почему системный диск по-прежнему называется C:
На большинстве ПК с Windows операционная система установлена на диске C:. Если вы подключите другой накопитель, он может получить буквы D:, E: и далее, оставляя A: и B: невостребованными. Первые две буквы с ранних времен существования ПК были закреплены за дисководами для гибких дисков: A: — за первым дисководом, B: — за вторым.
Когда в системе DOS появились жесткие диски, Microsoft нужно было вписать их в существующую схему. Поскольку буквы A: и B: были заняты флоппи-дисководами, первый жесткий диск получил индекс C:. Хотя дискеты исчезли, а современная Windows умеет монтировать тома в папки без присвоения букв, C: остается стандартом из-за десятилетий программного обеспечения, скриптов, документации и пользовательских привычек. Изменение этой буквы не решило бы никаких проблем, но привело бы к серьезным конфликтам совместимости.
Важность обратной косой черты в путях
Пути C:\Data и C:Data выглядят похоже, но в командной строке они могут указывать на разные места. C:\Data — это абсолютный путь: обратная косая черта после буквы диска указывает Windows начать поиск папки Data в корне диска C. C:Data — это относительный путь, который может указывать на папку Data в текущем каталоге на диске C.
Это странное поведение унаследовано от DOS, которая запоминала отдельный «текущий каталог» для каждого диска. Вы могли работать глубоко в папке на диске C:, переключиться на D:, уйти в другую директорию, а затем вернуться к локации на C:, которую запомнила система, без необходимости вводить полный путь. Хотя современные программы Win32 имеют единый текущий каталог для всего процесса, командная строка воссоздает старое поведение для каждого диска ради совместимости. Она даже сохраняет внутренние переменные среды вроде =C:, чтобы помнить, где остановился каждый диск. Именно поэтому в скриптах безопаснее использовать C:\Data: пропуск косой черты сделает путь зависимым от результатов выполнения предыдущих команд.
Призрачная тильда: почему PROGRA~1 всё еще встречается в Windows
Время от времени Windows выдает странные имена вроде PROGRA~1 там, где вы ожидаете увидеть привычную папку Program Files. Эта аббревиатура берет свое начало из старой системы именования файлов 8.3, следы которой до сих пор сохраняются в Windows. Классические имена файлов в DOS были ограничены восемью символами до точки и тремя после нее, что работало без проблем. Однако файл с названием вида Financial_Statement_2026.xlsx в эту систему уже никак не вписывался.
Когда Windows 95 привнесла поддержку длинных имен файлов в потребительскую линейку Microsoft, основанную на DOS, возникла проблема совместимости. Старые DOS-программы и 16-битное программное обеспечение все еще ожидали коротких имен, поэтому Windows должна была хранить альтернативный псевдоним формата 8.3 наряду с длинным именем файла. Именно так появились знакомые сокращения с тильдой: Program Files обычно отображается как PROGRA~1.
Реальные правила именования устроены сложнее, чем простое сокращение имени до шести символов с добавлением знака ~1, особенно когда возникает конфликт нескольких похожих имен. Важно понимать, что и длинное имя, и короткий псевдоним указывают на один и тот же файл или папку. Windows 10 и 11 до сих пор поддерживают имена 8.3, хотя нельзя гарантировать, что каждый файл будет иметь такой псевдоним.
Генерацию коротких имен можно включить или отключить как глобально, так и для отдельного тома, а Microsoft предоставляет для управления этой функцией команду fsutil 8dot3name. В компании предупреждают: не стоит бездумно удалять существующие короткие имена, так как старое ПО может по-прежнему зависеть от них. В ряде случаев удаление этих псевдонимов может привести к поломке приложений или даже сделать невозможным корректное удаление программ.
Звездочка, которая подходит ко всему: почему точка — это не совсем точка
В командной строке конструкция *.* традиционно означает «все файлы в этом каталоге». Если читать это буквально, то значение кажется гораздо более узким, чем то, как Windows использует данную команду на самом деле. Можно было бы ожидать, что такой шаблон означает любое имя файла, за которым следует точка и любое расширение, что должно было бы исключить из выборки файлы без расширения, вроде Notes.
Однако DOS обрабатывала имена файлов иначе. В классическом формате 8.3 имя и расширение хранились как отдельные поля фиксированной длины: первые восемь символов резервировались под имя, а следующие три — под расширение. Точка, которую вы видели на экране, была лишь разделителем между этими полями, а не обычным символом, занимающим место внутри структуры имени файла. Поэтому, когда DOS обрабатывала *.*, первая звездочка соответствовала полю имени, а вторая — полю расширения. У файла без расширения поле расширения все равно существовало, оно было просто пустым, поэтому шаблон подходил в любом случае. Так *.* стала сокращением для «всех файлов».
Win32 отказался от старого алгоритма сопоставления имен файлов DOS, когда длинные имена сделали эту модель непрактичной, но Microsoft сохранила некоторые странности ради совместимости. Одна из них — привычное поведение *.*, которое продолжает означать «все файлы», а не только те, что содержат точку в имени. Изменение этого поведения привело бы к тому, что старые скрипты и программы начали бы пропускать файлы без расширений, с которыми они работали всегда.
Windows хранит своих «призраков»
Эти правила могут казаться почти произвольными на современном ПК с Windows 11, так как условия аппаратного и программного обеспечения, породившие их, исчезли десятилетия назад. CON, C:, PROGRA~1, C:Data и *.* имели гораздо больше смысла в мире дискет, коротких имен файлов и программ, написанных под конвенции DOS. Это далеко не единственные «окаменелости», сохранившиеся до наших дней.
Windows 11 по-прежнему поддерживает множество устаревших функций, поскольку Microsoft десятилетиями сохраняла поведение, которого могут ожидать существующие оборудование и программное обеспечение. В большинстве случаев вы никогда не замечаете этой истории. Однако время от времени, пытаясь назвать файл CON или задаваясь вопросом, почему алфавит дисков начинается с C:, вы сталкиваетесь с тем, что DOS буквально проглядывает сквозь «половые доски» системы.
Дополнение к истории системных ограничений Windows
Важно дополнить контекст о том, как именно сформировались эти архитектурные «окаменелости». Истоки многих из них уходят даже дальше, чем принято считать в массовом представлении о MS-DOS. Некоторые концепции восходят к системе CP/M, которая появилась еще до создания первого IBM PC. Со временем эти идеи настолько глубоко вросли в Windows API, скрипты и установщики, что стали негласными «законами», определяющими поведение современных файлов и путей.
В вопросе дисковых накопителей стоит уточнить важную техническую деталь: в эпоху становления PC некоторые компьютеры с единственным физическим дисководом могли эмулировать наличие двух устройств. Система запрашивала у пользователя смену дискеты каждый раз, когда программное обеспечение обращалось то к диску A:, то к диску B:. Именно эта логическая гибкость заставила Microsoft закрепить первые две буквы алфавита за сменными носителями, сделав C: «домом» для первого жесткого диска. Сегодня, когда дискеты стали историей, вы можете присвоить буквы A: или B: другим томам, но перенос системного раздела в начало алфавита создал бы невероятные проблемы совместимости с тысячами старых скриптов и документацией, завязанной на жестко заданный путь к диску C:.
Также стоит обратить внимание на механизм работы командной строки с путями. Система запоминает «текущий каталог» для каждого диска отдельно благодаря внутренним переменным среды, таким как =C:. Это позволяет пользователю, например, работать глубоко внутри папки на диске C:, перейти на D:, выполнить ряд действий там, а затем вернуться к ранее заданной точке на диске C:, просто переключившись на него, без необходимости указывать полный путь заново. Win32-приложения сегодня используют единый для процесса текущий каталог, однако командная строка намеренно воспроизводит старое «раздельное» поведение для обеспечения совместимости.
Касательно коротких имен файлов (8.3), необходимо отметить, что процесс их генерации не так примитивен, как кажется. Если в системе возникает конфликт имен при попытке создать сокращение PROGRA~1, Windows задействует более сложный алгоритм обработки для формирования уникальных псевдонимов. Хотя компания Microsoft и предоставляет инструмент fsutil 8dot3name для управления этой функцией, она настоятельно рекомендует не удалять существующие короткие имена, так как некоторые старые приложения могут потерять работоспособность или перестать корректно удаляться, если лишатся своего «короткого» идентификатора.
