Windows 95 могла принять решение о запуске защитного механизма не по цифровой подписи, не по метаданным и даже не по формату пакета, а по имени EXE-файла. Если в названии встречалось одно из шести слов, система считала, что перед ней установщик, и после его работы проверяла, не были ли испорчены системные DLL. Для разработчиков это хороший привет из эпохи, когда устойчивость платформы держалась на эвристиках, а не на строгих правилах.
О необычной детали из внутренностей старой ОС сообщает Tom's Hardware со ссылкой на инженера Microsoft и давнего летописца Windows Рэймонда Чена. По его словам, Windows 95 искала в имени программы слова setup, install, inst, а также три локализованных варианта: imposta, ayarla и felrak. Если совпадение находилось, система помечала процесс как установку и включала процедуру восстановления системных файлов, которые инсталляторы 1990-х регулярно перезаписывали без оглядки на версии.
С инженерной точки зрения история одновременно смешная и очень практичная. Проблема была реальной: установщик мог принести с собой старую копию общей библиотеки, например еще из эпохи Windows 3.1, поверх более новой версии из Windows 95. После этого ломалось уже не одно приложение, а все, кто зависел от этой DLL. Чтобы не превращать каждую установку в русскую рулетку, Microsoft держала резервные копии часто повреждаемых файлов в скрытом каталоге C:WindowsSYSBCKUP. Дальше система ждала завершения установки, сверяла, что изменилось, и возвращала правильные версии файлов, если инсталлятор успел откатить систему назад.
Ключевое слово здесь именно «ждала». По описанию Чена, проверка нередко откладывалась до следующей загрузки. Причина тоже очень в духе эпохи: некоторые установщики не могли заменить занятый файл из-под Windows, поэтому уходили в MS-DOS, запускали пакетный файл, меняли DLL уже там и только потом перезагружали машину. Если бы Windows 95 пыталась навести порядок сразу, она бы просто не увидела часть изменений. Отсюда и знакомая пользователям тех лет привычка: поставил драйвер, игру или офисный пакет — будь добр перезагрузись.
Здесь особенно интересно не само наличие хрупкой эвристики, а то, насколько честно она отражает состояние экосистемы ПО середины 1990-х. Единых дисциплинированных правил упаковки и обновления тогда фактически не было. Инсталляторы писали кто во что горазд, версиями файлов пренебрегали, а драйверы мультимедиа, как отдельно отмечает Чен, особенно часто затирали системные библиотеки. Поэтому для INF-установок таких драйверов в Windows 95 существовала еще и отдельная «живая» проверка. То есть Microsoft не столько строила красивую архитектуру, сколько ставила заглушки там, где рынок ломал систему быстрее, чем ее успевали чинить.
При этом у такого подхода были очевидные побочные эффекты. Если установщик назывался нестандартно и не содержал нужных фрагментов в имени, защитный механизм мог просто не сработать. А если обычная программа называлась, скажем, похоже на instant.exe, то система рисковала распознать в ней установщик без всякой причины. Сам Чен отдельно замечает еще одну забавную деталь: слово install в списке выглядело почти лишним, потому что уже содержало подстроку inst. Его версия — короткий вариант добавили позже для файлов вроде blahinst.exe, а старый пункт никто не стал убирать. Это мелочь, но очень узнаваемая для любой большой кодовой базы: временное решение закрепляется, переживает несколько релизов и через десятилетия выглядит как археологическая находка.
Для нынешних разработчиков эта история полезна не только как ретро-анекдот про Windows 95. Она хорошо показывает, почему современные механизмы защиты системных файлов вообще появились в том виде, в каком мы их знаем. В Windows 2000 Microsoft ушла от угадывания по имени файла к Windows File Protection: система отслеживала изменения через Winlogon и восстанавливала защищенные компоненты из кэша %WinDir%System32dllcache. Затем в Windows ME появилась сопоставимая защита, а в Vista и более новых версиях эволюция продолжилась уже в виде Windows Resource Protection с опорой на ACL и более формальные механизмы контроля доступа. Даже команда sfc /scannow, которую до сих пор запускают пользователи Windows 11, тянет родословную от тех самых попыток удержать систему в рабочем состоянии, когда сторонний setup-файл жил по своим правилам.
Для бизнеса и продуктовых команд вывод тоже довольно приземленный. Платформа редко становится надежной сразу; обычно она сначала обрастает костылями, потом стандартизируется, а уже затем превращает вчерашнюю эвристику в официальный механизм. История Windows 95 напоминает, что «временное» решение внутри популярной системы может прожить десятилетия хотя бы на уровне идей и интерфейсов. И чем хаотичнее экосистема вокруг продукта, тем выше шанс, что где-то внизу уже работает не элегантная архитектура, а очень старая проверка на слово setup.