Как Windows 95 «угадывала» установщики по имени файла — и почему это иногда давало сбой
Windows 95 определяла программу-установщик всего по шести жёстко закодированным словам в имени исполняемого файла
Если слово совпадало, включался механизм проверки и восстановления системных файлов, повреждённых после работы установщика
Из-за примитивности эвристики обычная программа вроде instant.exe могла случайно запустить эту процедуру впустую
Подход держался на угадывании и был полностью заменён в Windows 2000 на Windows File Protection — уже без анализа имён файлов
Долгое время в Windows 95 оставалась загадка: как система вообще понимала, что только что отработал установщик, и пора проверять, не испортил ли он что-то важное? Ответ оказался неожиданно простым — и неожиданно ненадёжным. Разгадкой поделился инженер Microsoft и неофициальный летописец истории Windows, который годами публикует технические истории о внутренней кухне системы в своём блоге.
Источник изображения - Getty Images
Шесть волшебных слов
Никакого специального флага или системного вызова, сообщающего «сейчас работает установщик», в Windows 95 не существовало. Вместо этого система читала имя запущенного исполняемого файла и сверяла его с коротким списком слов, зашитых прямо в код.
- setup — базовое английское слово
- install — избыточная запись, поскольку любое имя с этим словом уже содержит inst
- inst — сокращённый вариант, добавленный позже для программ вроде blahinst.exe
- imposta — предположительно, итальянский вариант
- ayarla — предположительно, турецкий вариант
- felrak — предположительно, венгерский вариант
Три неанглийских слова инженер прямо назвал собственными догадками, не подтверждёнными носителями языка — отсюда и осторожная формулировка «предположительно» в каждом случае. Он также отметил забавную деталь: когда добавили короткое inst, старое избыточное install из списка почему-то не убрали.
Если имя самого файла не совпадало ни с одним словом, срабатывала вторая проверка — Windows 95 искала подстроку Setup уже во всём пути к исполняемому файлу, а не только в его имени. А для установки мультимедийных драйверов через INF-файлы существовала отдельная, третья проверка в реальном времени: команда, отвечавшая за мультимедиа, заметила, что такие драйверы особенно часто затирают системные библиотеки, и выбила себе персональное исключение из общей логики.
Что именно запускала эта проверка
Обнаружение установщика было не самоцелью, а спусковым крючком для защитного механизма, о котором тот же инженер рассказывал ранее. Корень проблемы уходил в эпоху 16-битной Windows: многие системные компоненты распространялись как часть чужих инсталляторов, и правило Microsoft требовало заменять файл только более новой версией, сверяясь с номером версии уже установленного файла.
На практике это правило массово игнорировалось. Установщик, тащивший в комплекте библиотеки ещё из Windows 3.1, попросту перезаписывал ими свежие файлы Windows 95, не проверяя вообще ничего — и любая программа, зависевшая от актуальной версии, переставала работать.
Как работало резервное копирование в SYSBCKUP
Для самых часто страдающих файлов Windows 95 держала скрытый каталог C:\Windows\SYSBCKUP. Логика была не такой прямолинейной, как кажется на первый взгляд: система не восстанавливала файлы вслепую при любом срабатывании эвристики. После завершения работы распознанного установщика Windows 95 проверяла, был ли файл изменён, и сравнивала номер версии.
Если версия, оставленная установщиком, оказывалась новее версии в резервной копии — именно она копировалась в SYSBCKUP на хранение. Если же установщик подсунул файл со старой версией, происходило обратное: копия из SYSBCKUP возвращалась поверх «понижения», и система оставалась на актуальной версии. Вся эта страховка целиком зависела от первого шага — правильного опознания установщика по имени. Программа с нестандартным названием проходила незамеченной, а обычное приложение вроде instant.exe запускало проверку впустую, ничего при этом не восстанавливая, поскольку восстанавливать было нечего.
Почему проверка иногда ждала перезагрузки
Далеко не всегда система успевала отреагировать сразу. Некоторые установщики не могли заменить файл, занятый работающей Windows, и решали проблему грубо: выходили в MS-DOS, запускали пакетный файл для подмены нужных библиотек и перезапускали систему. Из-за такого сценария процедуре проверки приходилось откладываться до следующей загрузки — только тогда она могла увидеть изменения, внесённые пакетным файлом в обход обычного процесса.
Путь от угадывания к полноценной защите файлов
Подход на основе слов-триггеров прожил ровно до Windows 2000, где его сменила технология Windows File Protection. Новый механизм подписывался на уведомления об изменении файлов через компонент Winlogon и восстанавливал защищённые файлы напрямую из кэша %WinDir%\System32\dllcache — без каких-либо догадок по именам и без ожидания, пока установщик доработает.
- Windows 2000 — Windows File Protection, отслеживание через Winlogon и кэш dllcache
- Windows ME — аналогичная по духу System File Protection
- Windows Vista и новее — Windows Resource Protection, защита через списки контроля доступа (ACL)
Команда sfc /scannow, которую и сегодня используют для восстановления системных файлов в Windows 11, — прямой потомок именно этой линии развития. Разница лишь в том, что современная система заранее знает, какие файлы защищены, и ей больше не нужно угадывать это по слову setup в имени процесса.
