Interested Article - Установщик Windows
![](/images/008/196/8196356/1.jpg?rand=654390)
![](https://cdn.wafarin.com/avatars/70e42d83c1a00db8ab791df2b4844af4.jpg)
- 2021-02-01
- 1
Установщик
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).
Откат
Если какое-либо из действий, определённых в сценарии, оканчивается неудачей, или установка в процессе отменяется пользователем, все действия, выполненные до этого места, откатываются , возвращая систему в состояние, бывшее до установки. Откат обеспечивается наличием для каждого действия, вносящего изменение в систему, обратного к нему. Вводя в пакет нестандартные действия, программист также должен создать обратные к ним для правильной работы отката .
Версии
Версии
|
---|
Прочие возможности
Анонсирование и установка по требованию
Установщик Windows может рекламировать продукт, а не устанавливать его . Продукт появится у пользователя, но он фактически не будет установлен до тех пор, пока он не будет запущен в первый раз (с помощью ярлыка в меню «Пуск» ). Установочный пакет может быть объявлен администратором с использованием групповой политики Windows, или другого механизма компилирования, или путём запуска исполняемого файла msiexec с помощью /jm (для рекламы для каждого устройства), или /ju (для рекламы для каждого пользователя). Некоторые пакеты MSI, созданные в InstallShield , могут помешать использованию этих, и других встроенных функций MSI.
Пользователь должен иметь права администратора, чтобы завершить рекламируемую установку.
Установка по требованиям
Подобно рекламированию продукта, установка по требованиям устанавливает функцию, как только пользователь пытается её использовать .
Примечания
- . Microsoft Developer Network . Microsoft . Дата обращения: 22 февраля 2015. 13 декабря 2014 года.
- Дата обращения: 11 апреля 2006. 15 января 2009 года.
- . Дата обращения: 1 июля 2018. 1 июля 2018 года.
- . Дата обращения: 1 июля 2018. 1 июля 2018 года.
- . Дата обращения: 1 июля 2018. 1 июля 2018 года.
Ссылки
- (англ.) MSDN
- Переведено с
- Выпущенные версии установщика Windows
- Компоненты установщика Windows
![]() |
В другом языковом разделе
есть более полная статья
(англ.)
.
|
![](https://cdn.wafarin.com/avatars/70e42d83c1a00db8ab791df2b4844af4.jpg)
- 2021-02-01
- 1