Установщик Windows

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Установщик Windows
Тип Установщик
Разработчик Microsoft
Операционная система Windows
Аппаратная платформа Windows
Последняя версия 5.0[1] (22 июля 2009 года)
Лицензия Пользовательское соглашение Microsoft
Сайт learn.microsoft.com/ru-r…

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

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

История[править | править код]

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

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

Откат[править | править код]

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

Версии[править | править код]

Версии[править | править код]

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

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

Установка по требованиям[править | править код]

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

Примечания[править | править код]

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

Ссылки[править | править код]