Установщик Windows

Установщик Windows
Установщик Windows
Тип	Установщик
Разработчик	Microsoft
Операционная система	Windows
Аппаратная платформа	Windows
Последняя версия	5.0 (22 июля 2009 года)
Читаемые форматы файлов:
Читаемые форматы файлов:
	MSI[вд], Windows Setup Information File[вд] и Windows Setup inf_loc file[вд]
Лицензия	Пользовательское соглашение Microsoft
Сайт	learn.microsoft.com/ru-r…

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

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

История

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

Первая версия 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).

Откат

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

Версии

Версия	Входит в	Также доступно для
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 может рекламировать продукт, а не устанавливать его^[5]. Продукт появится у пользователя, но он фактически не будет установлен до тех пор, пока он не будет запущен в первый раз (с помощью ярлыка в меню «Пуск»). Установочный пакет может быть объявлен администратором с использованием групповой политики Windows, или другого механизма компилирования, или путём запуска исполняемого файла msiexec с помощью /jm (для рекламы для каждого устройства), или /ju (для рекламы для каждого пользователя). Некоторые пакеты MSI, созданные в InstallShield, могут помешать использованию этих, и других встроенных функций MSI.

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

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

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

Примечания

↑ Released Versions of Windows Installer (неопр.). Microsoft Developer Network. Microsoft. Дата обращения: 22 февраля 2015. Архивировано 13 декабря 2014 года.
↑ ¹ ² Installation-On-Demand | Microsoft Docs (неопр.). Дата обращения: 1 июля 2018. Архивировано 1 июля 2018 года.
↑ Rob Mensching. Inside the MSI file format. (неопр.) Дата обращения: 11 апреля 2006. Архивировано 15 января 2009 года.
↑ Rollback Installation | Microsoft Docs (неопр.). Дата обращения: 1 июля 2018. Архивировано 1 июля 2018 года.
↑ Advertisement | Microsoft Docs (неопр.). Дата обращения: 1 июля 2018. Архивировано 1 июля 2018 года.

Ссылки

Раздел Установщик Windows (англ.) MSDN
Официальный сайт
Переведено с Windows Installer
Выпущенные версии установщика Windows
Компоненты установщика Windows

[release_history-1] Released Versions of Windows Installer (неопр.). Microsoft Developer Network. Microsoft. Дата обращения: 22 февраля 2015. Архивировано 13 декабря 2014 года.

[:0-2] ¹ ² Installation-On-Demand | Microsoft Docs (неопр.). Дата обращения: 1 июля 2018. Архивировано 1 июля 2018 года.

[mensching-3] Rob Mensching. Inside the MSI file format. (неопр.) Дата обращения: 11 апреля 2006. Архивировано 15 января 2009 года.

[4] Rollback Installation | Microsoft Docs (неопр.). Дата обращения: 1 июля 2018. Архивировано 1 июля 2018 года.

[5] Advertisement | Microsoft Docs (неопр.). Дата обращения: 1 июля 2018. Архивировано 1 июля 2018 года.

[2]

[1]

[3]

[4]

[5]