Установщик Windows

Установщик Windows был разработан в 1995—1998 годах под кодовым названием Darwin. Первые версии назывались Microsoft Installer, отсюда стандартное расширение установочного пакета — .msi^[3].

Первая версия установщика появилась в начале 1999 года для инсталляции Microsoft Office 2000. В том же году Установщик стал частью Windows 2000. Microsoft активно поощряла переход разработчиков на новый вариант, включив в требования к программам, желающим получить знак Windows 2000 Logo, обязательное использование Windows Installer.

Установщик Windows стал значительным шагом вперёд по сравнению с предыдущим установщиком Microsoft — Setup API (ACME Setup): появились поддержка GUI, деинсталляция и откат на любом этапе установки (в том числе при удалении), корректная работа с правами доступа и другие преимущества, что сделало его полноценной альтернативой существовавшим на рынке установочным пакетам.

В будущих обновлениях ожидается появление формата .MSIX, который станет гибридом .APPX и .MSI, что позволит устанавливать приложения UWP вне Microsoft Store.

Пакет описывает установку одного или нескольких продуктов, идентифицируемых с помощью GUID. Продукт состоит из компонентов, сгруппированных по функциям. Установщик Windows не управляет зависимостями между продуктами.

Каждая установленная программа (или набор программ) — продукт. Продукт идентифицируется уникальным GUID (ProductCode), по которому производится идентификация; вместе с номером версии (ProductVersion) проводится управление версиями файлов и разделов реестра.

Пакет включает дополнительную логику и метаданные, управляющие выполнением при запуске. Например, при изменении EXE файла в продукте надо сменить ProductCode или ProductVersion, а при изменениях только метаданных — PackageCode.

Функция — иерархическая группа компонентов. Она может состоять из любого числа компонентов и субфункций. Небольшие пакеты могут содержать только одну функцию; более сложные программы позволяют пользователю выбрать, что именно установить.

Автор пакета определяет набор функций продукта. Например, текстовый процессор может разделить на разные функции собственно программу, файлы справки, модули проверки правописания и шаблоны.

Компонент — минимальная единица продукта, устанавливаемая исключительно целиком. Компоненты включают программы, папки, COM-объекты, записи реестра, ярлыки. Пользователь напрямую с компонентами не работает.

Компоненты глобально идентифицируются по GUID, что позволяет использовать их в разных функциях или пакетах (например, через модули объединения).

Ключевой путь — файл, раздел реестра или источник ODBC, который объявлен критически важным для компонента. Обычно это файл, называемый файлом-ключом. Component может содержать не более одного ключевого пути; если не задан, ключевым считается папка назначения. При запуске MSI-программ установщик проверяет наличие ключевых путей и при несовпадении (например, отсутствует файл-ключ) повторно устанавливает компонент (самовосстановление). Два компонента не могут иметь одинаковый ключевой путь.

Создание MSI-пакета для нового приложения связано с определением размещения файлов, настроек реестра, а также пользовательских действий, часто реализуемых через DLL. Для этого существуют коммерческие и открытые инструменты, включая Visual Studio (до версии 2010 штатно, позже с расширениями), InstallShield и WiX. Пакетирование сопровождается настройкой интерфейса (последовательность диалогов, элементы управления) и поведением установки, в том числе поддержкой «тихой» установки. Готовый пакет «компилируется» в файл .msi.

Пользовательский интерфейс установки настраивается инженером-установщиком. Доступен ограниченный набор элементов управления, из которых формируются диалоговые окна. Пакет может быть настроен для установки без пользовательского интерфейса (автоматический режим).

Microsoft предоставляет набор инструментов ICE (internal consistency evaluator) для проверки MSI-пакета на ошибки и несоответствия (файлы CUB с пользовательскими проверками). Проверка осуществляется средствами Orca, msival2 или встроенными в отдельные среды разработки инструментами.

Примеры проверок ICE:

• ICE09: проверка пометки компонентов, размещаемых в системной папке, как постоянных;
• ICE24: проверка корректности заполнения кода продукта, версии и языка;
• ICE33: таблица реестра не должна использоваться для определённых данных, которые должны быть вынесены в отдельные таблицы (класс, расширение, глагол и т. п.).

Устранение ошибок и предупреждений при проверке ICE является обязательным этапом выпуска пакета.

Файл .msi — составной документ OLE, содержащий небольшую реляционную базу данных с десятками связанных таблиц, описывающих продукт и установку. Строковые данные хранятся отдельно, а в таблицах используются ссылки — это позволяет избегать дублирования строк и уменьшать размер файла.

Помимо базы, структура файла .msi допускает хранение пользовательских скриптов и вспомогательных DLL, необходимых для установки, а также компонентов непосредственно в виде архивов .cab. Устанавливаемые файлы могут находиться и вне MSI-пакета — запакованные или нет, с сохранением иерархии папок.

Процесс установки делится на этапы: сбор информации, выполнение ошибки (откат), и собственно установка.

Этапы установки состоят из последовательности действий (actions), определённых в базе MSI: для каждого задаётся порядок (номер), а при необходимости — условия выполнения.

Большинство действий — стандартные, но есть возможность добавить пользовательские (custom actions).

Пользовательские действия реализуют через скрипты (JScript, VBScript, Eclipse Script) или DLL (написанные на C, C++ и др.). Скрипты или DLL помещают в msi-файл и извлекают в Windows\Installer с уникальными именами (например, MSIF65E.tmp) при запуске установки.

На этом этапе Windows Installer собирает команды (от пользователя или программно) по установке или удалению функций, описанных в продукте, и формирует внутренний сценарий для следующего этапа. Этот этап также называется непосредственным режимом (immediate mode).

На данном этапе установщик выполняет сценарий без взаимодействия с пользователем, используя привилегии службы LocalSystem — даже если запуск осуществлён ограниченным пользователем. Этот этап часто называют отложенным режимом (deferred mode).

Если действие установки завершается ошибкой или пользователь отменяет процесс, все изменения откатываются для возврата системы в исходное состояние. Это обеспечивается наличием «обратных» действий, в том числе для пользовательских сценариев^[4].

Установщик Windows может рекламировать продукт, не устанавливая его полностью^[5]. Продукт появляется у пользователя, но реально устанавливается только при первом запуске (например, из меню «Пуск»). Пакет может быть объявлен администратором через групповую политику Windows, иные средства развёртывания или запуском msiexec с ключами /jm (для устройства) либо /ju (для пользователя). Некоторые MSI-пакеты, созданные в InstallShield, могут препятствовать использованию некоторых возможностей MSI.

Пользователь должен обладать правами администратора, чтобы завершить рекламируемую установку.

Как и реклама, установка по требованию позволяет установить функцию в момент первого её использования пользователем^[2].