Установщик Windows ( msiexec.exe , ранее известный как установщик Microsoft , кодовое Darwin[5] представляет собой программный компонент и интерфейс прикладного программирования (API) Microsoft Windows, используемый для установки, обслуживания и удаления программного обеспечения. Установочная информация и, при необходимости, сами файлы упакованы в установочные пакеты , которые представляют собой слабо выраженные реляционные базы данных , структурированные в виде COM-хранилищ и обычно известные как " " из-за их расширений имен файлов по умолчанию. Пакеты с расширениями файлов mst содержат " " установщика Windows, пакеты с msm расширениями содержат "Модули объединения", а расширение файла pcp используется для "Свойств создания исправления". Установщик Windows содержит значительные изменения по сравнению со своим предшественником, . Новые функции включают в себя платформу графическим интерфейсом и автоматическую генерацию последовательности удаления. Установщик Windows позиционируется как альтернатива автономным исполняемым установочным фреймворкам, таким как более старые версии InstallShield и NSIS .

До появления Microsoft Store (тогда называвшегося Windows Store) Корпорация Майкрософт поощряла третьи стороны использовать установщик Windows в качестве основы для платформ установки, чтобы они правильно синхронизировались с другими установщиками и поддерживали согласованность внутренней базы данных установленных продуктов. Такие важные функции, как откат и управление версиями, зависят от согласованной внутренней базы данных для обеспечения надежной работы. Кроме того, установщик Windows способствует реализации принципа наименьших привилегий , выполняя установку программного обеспечения через прокси для непривилегированных пользователей.

История

Windows Installer был разработан в 1995 — 1998 годах и имел вначале кодовое название Darwin . Ранние версии назывались Microsoft Installer , отсюда стандартное расширение файла инсталляционного пакета — .msi .

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

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

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

Логическая структура пакета

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

Продукт

Одна установленная работающая программа (или набор программ) - это продукт . Продукт идентифицируется уникальным идентификатором GUID (свойство ProductCode), обеспечивающим авторитетную идентификацию во всем мире. Идентификатор GUID в сочетании с номером версии (свойство ProductVersion) позволяет управлять выпуском файлов продукта и разделов реестра.

Пакет включает логику пакета и другие метаданные, которые относятся к тому, как пакет выполняется при запуске. Например, изменение EXE-файла в продукте может потребовать изменения ProductCode или ProductVersion для управления выпуском. Однако простое изменение или добавление условия запуска (при этом продукт остается точно таким же, как и в предыдущей версии) все равно потребовало бы изменения PackageCode для управления выпуском самого файла MSI.

Характеристики

Функция - это иерархическая группа компонентов. Компонент может содержать любое количество компонентов и других вспомогательных функций. Пакеты меньшего размера могут состоять из одной функции. Более сложные установщики могут отображать диалоговое окно "пользовательская настройка", в котором пользователь может выбрать, какие функции установить или удалить.

Автор пакета определяет функции продукта. Текстовый процессор, например, может поместить основной файл программы в одну функцию, а файлы справки программы, дополнительные модули проверки правописания и канцелярские принадлежности - в дополнительные функции.

Компоненты

Компонент - это базовая единица продукта. Каждый компонент рассматривается установщиком Windows как единое целое. Установщик не может установить только часть компонента. Компоненты могут содержать программные файлы, папки, COM-компоненты, разделы реестра и ярлыки. Пользователь напрямую не взаимодействует с компонентами.

Компоненты идентифицируются глобально с помощью идентификаторов GUID; таким образом, один и тот же компонент может использоваться совместно несколькими функциями одного и того же пакета или несколькими пакетами, в идеале с помощью модулей объединения.

Ключевые пути

Путь к ключу - это определенный файл, раздел реестра или источник данных ODBC, который автор пакета указывает как критический для данного компонента. Поскольку файл является наиболее распространенным типом пути к ключу, обычно используется термин файл ключа . Компонент может содержать не более одного пути к ключу; если у компонента нет явного пути к ключу, в качестве пути к ключу используется папка назначения компонента. При запуске программы на базе MSI установщик Windows проверяет наличие путей к ключам. Если имеется несоответствие между текущим состоянием системы и значением, указанным в пакете MSI (например, отсутствует файл ключа), соответствующая функция устанавливается повторно. Этот процесс известен как самовосстановление или самовосстановление . Никакие два компонента не должны использовать один и тот же путь к ключу.

Разработка пакетов установщика

Создание установочного пакета для нового приложения не является тривиальным. Необходимо указать, какие файлы должны быть установлены, куда и с какими разделами реестра. Любые нестандартные операции можно выполнять с помощью пользовательских действий, которые обычно разрабатываются в библиотеках DLL. Существует ряд коммерческих и бесплатных продуктов, помогающих в создании пакетов MSI, включая Visual Studio (изначально до версии VS 2010, с расширением в более новых версиях VS), InstallShield и WiX. В разной степени пользовательский интерфейс и поведение могут быть настроены для использования в менее распространенных ситуациях, таких как автоматическая установка. После подготовки установочный пакет "компилируется" путем чтения инструкций и файлов с локального компьютера разработчика и создания файла .msi.

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

Проверка ICE

Корпорация Майкрософт предоставляет набор внутренних средств оценки согласованности (ICE), которые можно использовать для обнаружения потенциальных проблем с базой данных MSI.Правила ICE объединены в файлы CUB, которые представляют собой урезанные файлы MSI, содержащие пользовательские действия, которые проверяют содержимое целевой базы данных MSI на наличие предупреждений и ошибок проверки. Проверку ICE можно выполнить с помощью инструментов Platform SDK Orca и msival2 или с помощью инструментов проверки, которые поставляются с различными средами разработки.

Например, некоторые из правил ICE таковы:

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

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

Физическая структура пакета

Файл .msi представляет собой составной документ OLE (OLE compound document — в том же формате-контейнере хранятся документы Microsoft Word , Excel и т. д.), в котором содержится небольшая реляционная база данных — набор из нескольких десятков взаимосвязанных таблиц, содержащих различную информацию о продукте и процессе установки. При этом все строковые данные в базе хранятся вместе в отдельном потоке документа, а в таблицах базы на них имеются ссылки; таким образом избегают дублирования строк, что значительно уменьшает размер базы.

Кроме базы, структура файла .msi предусматривает помещение туда пользовательских сценариев и вспомогательных DLL , если таковые требуются для установки, а также самих устанавливаемых файлов, запакованных в формате .cab . Файлы можно размещать и отдельно от пакета, в запакованном или распакованном виде (с сохранением структуры каталогов).

Процесс установки

Процесс установки состоит из нескольких этапов — сбора информации, выполнения (собственно установки), а также, возможно, отката (в случае ошибки или отмены установки пользователем).

Действия

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

Большая часть действий — это стандартные действия, характерные для типичного процесса сбора информации и установки. Все эти действия документированы, кроме них, пользователь может определить и свои действия (custom actions).

Действия, определённые пользователем, могут быть либо написаны на одном из скриптовых языков , встроенных в операционную систему ( JScript или VBScript так же и Eclipse, побочный язык от C++), либо размещаться в специально созданной DLL (написанной на таких языках, как C , C++ и т. д.). Файлы с этими действиями помещаются внутрь файла .msi и извлекаются оттуда в начале запуска установки. Эти DLL извлекаются в каталог Windows\Installer, при этом им присваиваются случайные имена, например MSIF65E.tmp.

Сбор информации

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

Этот этап называют также непосредственным режимом (immediate mode).

Выполнение

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

Этот этап иногда называется отложенным режимом (deferred mode).

Откат

Если какое-либо из действий, определённых в сценарии, оканчивается неудачей, или установка в процессе отменяется пользователем, все действия, выполненные до этого места, откатываются , возвращая систему в состояние, бывшее до установки. Откат обеспечивается наличием для каждого действия, вносящего изменение в систему, обратного к нему. Вводя в пакет нестандартные действия, программист также должен создать обратные к ним для правильной работы отката .

Версии

Версии Версия Входит в Также доступно для 1.0 Офис 2000 — 1.1 Windows 2000 RTM, SP1, SP2 Office XP Windows 95, Windows 98 Windows NT 4.0 1.2 Windows Me — 2.0 Windows XP RTM, SP1 Windows 2000 с пакетом обновления 3, SP4 Windows Server 2003 RTM Windows 9x Windows NT 4.0 Windows 2000 3.0 Windows XP с пакетом обновления 2 Windows 2000, по крайней мере, с SP3 Windows XP Windows Server 2003 3.1 Windows XP с пакетом обновления 3 Windows Server 2003 SP1, SP2 Windows XP Professional x64 Edition Windows 2000, по крайней мере, с SP3 Windows XP Windows Server 2003 4.0 Windows Vista RTM, SP1 Windows Server 2008 RTM — 4.5 Windows Vista SP2 Windows Server 2008 SP2 Windows XP, по крайней мере, с SP2 Windows Server 2003, по крайней мере, с пакетом обновления 1 Windows XP Professional x64 Edition Windows Vista Windows Server 2008 5.0 Windows 7 и более поздние версии Windows Server 2008 R2 и более поздние версии —

Прочие возможности

Анонсирование и установка по требованию

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

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

Установка по требованиям

Подобно рекламированию продукта, установка по требованиям устанавливает функцию, как только пользователь пытается её использовать .

Примечания

Ссылки

• (англ.) MSDN
• Переведено с
• Выпущенные версии установщика Windows
• Компоненты установщика Windows

В другом языковом разделе есть более полная статья (англ.) . Вы можете помочь проекту, расширив текущую статью с помощью перевода