Инженер-программист Рэймонд Чэнь, ветеран разработки Windows, раскрыл детали механизмов обеспечения целостности операционной системы периода Windows 95. Задачей инженеров Microsoft на тот момент было предотвращение «DLL hell» — ситуации, когда стороннее программное обеспечение или игры в процессе установки перезаписывали системные компоненты более старыми версиями из своих дистрибутивов, что приводило к дестабилизации всей ОС.
Методология защиты системных файлов
Официальные рекомендации Microsoft предписывали разработчикам сторонних приложений проводить предварительную проверку версий системных библиотек в целевой директории. Согласно гайдлайнам, обновление файла требовалось лишь в том случае, если версия в установочном пакете была новее установленной. Однако на практике этот регламент соблюдался далеко не всеми: установщики зачастую принудительно копировали старые версии DLL, игнорируя существующие в системе файлы, что приводило к сбоям компонентов платформы.
Для купирования подобных инцидентов инженеры выбрали путь скрытого восстановления. В Windows 95 была реализована скрытая директория «C:\Windows\SYSBCKUP», куда помещались резервные копии критически важных системных файлов. Алгоритм работы системы сводился к мониторингу состояния файлов сразу после завершения цикла установки стороннего ПО: ОС проводила фоновую проверку и автоматически восстанавливала те компоненты, которые были некорректно заменены установщиком.
Противостояние архитектурным ограничениям
Технически Microsoft могла бы ограничить права установщиков на запись в системные директории, однако от этого решения отказались из-за неизбежных ошибок и сообщений о сбоях, которые возникали бы у рядовых пользователей при каждой такой попытке записи. Создание препятствий для работы стороннего софта привело бы к массовому недовольству, поэтому разработчики Windows выбрали подход «тихого исправления».
Подобный подход стал ответом на агрессивные методы разработчиков того времени. Некоторые установщики, стремясь обойти системные блокировки, прибегали к сценариям с принудительной перезагрузкой ОС, после которой специализированные скрипты заменяли файлы до инициализации основной графической оболочки. В конечном итоге, отказ от жестких ограничений в пользу автоматического восстановления резервных копий позволил соблюсти баланс между стабильностью системы и совместимостью со сторонним ПО, а с течением времени проблема была нивелирована за счет перехода к использованию изолированных установщиков для отдельных компонентов системы.
