Содержание
Windows 95 не распознавала установщики по сложной логике. Система просто смотрела на имя EXE-файла и искала там слова вроде setup, install и inst.
Об этом рассказал ветеран Microsoft и хранитель многих странных историй Windows Рэймонд Чен в блоге Old New Thing. История звучит смешно в 2026 году, но для середины 90-х это была рабочая страховка от хаоса в установщиках.
Windows 95 угадывала установщик по имени файла
Логика Windows 95 держалась на коротком списке строк. Если имя программы содержало одно из этих слов, система считала ее установщиком и запускала проверку системных файлов после завершения работы программы.
- setup: типичное имя установщика в Windows 3.x и Windows 95
- install: расширенный вариант, хотя он уже содержит inst
- inst: короткая строка для имен вроде blahinst.exe
- imposta: вариант, который Чен назвал своей догадкой для итальянского
- ayarla: догадка для турецкого
- felrak: догадка для венгерского
Чен отдельно заметил, что строка install дублировала inst. Любое имя с install уже проходило по короткому совпадению. По его версии, inst могли добавить позже, чтобы поймать больше старых установщиков, а старую строку просто не удалили.
Если имя EXE-файла не проходило проверку, Windows 95 делала второй тест. Система искала слово Setup уже в пути к файлу. То есть программа могла лежать в папке с подходящим названием и всё равно запустить защитный механизм.
У этой схемы были очевидные промахи. Установщик с необычным именем мог пройти мимо проверки. А обычная программа с именем вроде instant.exe, наоборот, могла включить лишнюю проверку.
Зачем системе вообще понадобилась такая эвристика
В 90-е установщики часто перезаписывали общие DLL без нормальной проверки версий. Microsoft рекомендовала заменять файл только более новой копией, но многие программы игнорировали это правило.
Типичный сценарий выглядел неприятно. Установщик приносил DLL от Windows 3.1, клал ее поверх более свежей версии из Windows 95, а затем ломались программы, которым нужен был актуальный системный файл. Для пользователя это выглядело как внезапная поломка после установки совершенно обычного приложения.
В марте 2026 года Чен уже описывал сам механизм восстановления в Old New Thing. Windows 95 хранила резервные копии часто повреждаемых файлов в скрытой папке C:\Windows\SYSBCKUP. После работы подозрительного установщика система проверяла замененные файлы и возвращала правильные версии.
Проверку часто откладывали до следующей загрузки. Причина простая: некоторые установщики не могли заменить файл, пока Windows его использовала. Они выходили в MS-DOS, запускали batch-файл, меняли DLL и перезагружали систему.
Для мультимедийных драйверов Microsoft добавила отдельную живую проверку после установки через INF-файл. Чен объяснил это частыми проблемами с такими драйверами: они особенно любили перетирать системные DLL.
Windows 2000 убрала гадание по названиям
Windows 2000 заменила эту хрупкую схему на Windows File Protection. Новая система следила за изменениями файлов через Winlogon и восстанавливала защищенные копии из кэша %WinDir%\System32\dllcache.
Здесь уже не требовалось угадывать установщик по имени. Защита реагировала на изменение файла, а не на слово setup в названии программы. Для администраторов и сборщиков ПК это был более предсказуемый подход.
Позже Windows ME получила похожую System File Protection. Начиная с Vista, Microsoft перешла на Windows Resource Protection. Эта система защищает файлы через списки контроля доступа, а не только через восстановление из кэша.
Команда sfc /scannow, которую пользователи Windows 11 до сих пор запускают для ремонта системных файлов, выросла из этой линии защитных механизмов. В исходном списке Windows 95 было шесть строк: setup, install, inst, imposta, ayarla и felrak.
