Microsoft System Installation

В конце августа Microsoft выпустила Windows NT 5.0 Beta 2, и сейчас уже опубликовано довольно много информации об этой операционной системе.

Windows NT 5.0 будет содержать технологии, облегчающие создание и поддержание больших сетей на базе Windows NT и уменьшающие стоимость владения компьютером.

Одним из нововведений является технология установки программных продуктов (и, возможно, частей самой ОС), названная Microsoft System Installation (MSI), или Microsoft Windows Installer. Частично MSI будет работать в Windows NT 4.0, Windows 95 и Windows 98, если на них установлен Microsoft Internet Explorer 4.01 Service Pack 1 с Active Desktop. Работу новой системы установки тестеры бета-версии Microsoft Office 9 могут оценить уже сегодня; остальные пользователи, я надеюсь, смогут увидеть ее тоже довольно скоро в продуктах Microsoft и других компаний.

Старые проблемы

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

Процесс не лишен недостатков. Об одном из них мы уже сказали: если при работе с программой будет обнаружена потребность еще в каком-либо функциональном модуле, то ПО придется переустановить.

При этом пользователь должен четко представлять назначение каждого модуля в программе. Для опытных пользователей это не является проблемой, и они достаточно ясно понимают, от чего отказываются, что устанавливают на локальный диск, а что будут загружать с CD-ROM или из сети. Менее опытные используют "типичный" вариант установки и часто даже не знают, от каких - может быть, нужных именно им - функций они отказались. Легко предсказать, что это может привести к неэффективному использованию купленных продуктов.

Другой недостаток - большая нагрузка на системных администраторов. Они должны информировать всех пользователей о появлении нового ПО, консультировать по установке и, может быть, повторять весь процесс установки ПО столько раз, сколько рабочих станций находится на их попечении.

И, наверное, самым серьезным недостатком следует считать отсутствие какого-либо стандарта на процедуру установки, на процедуру деинсталляции, на способ определения того, какие файлы будут установлены в системные директории, и получение другой информации об устанавливаемом программном обеспечении. Все сведения, которые типичный инсталлятор сообщает операционной системе о программе, - это только название продукта и имя исполняемого файла, который надо запустить для удаления этой программы. (В Windows 98 эта информация хранится в реестре HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows\CurrentVersion\Uninstall\ <ProductName>.) Все это зачастую приводит к конфликту различных версий динамических библиотек, к сложностям удаления продукта с компьютера и в результате - к постепенной деградации операционной системы из-за большого количества "мусора" и разнообразных конфликтов.

Новые возможности

Возможности нового инсталлятора позволяют избавиться от перечисленных выше недостатков. Программы, инсталлируемые с помощью MSI, могут динамически, во время работы, без вмешательства пользователя менять свою конфигурацию. (Здесь под конфигурацией программы понимается набор установленных функциональных модулей.) Изменение конфигурации может происходить как по требованию самой программы, если она обнаруживает, что пользователь пытается воспользоваться не установленным компонентом, так и по требованию операционной системы и других программ.

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

Первый пример: на компьютер установили MS Word и не поставили конверторы форматов других текстовых процессоров в формат MS Word. Через какое-то время возникла необходимость открыть файлы, созданные редактором WordPerfect. Word, обнаружив нехватку компонента, сам установит его. От пользователя требуется только вставить CD-ROM c дистрибутивом, а если дистрибутив находится в сети, то не понадобится даже этого.

Второй пример: из всего MS Office пользователь решил установить только MS Word. На диск действительно установится только MS Word, однако теперь попытка открыть .mdb-файл приведет к установке MS Access и последующему открытию этого файла.

Третий пример: администратор устанавливает новую программу (например, Acrobat Reader) на сервер. На каждой рабочей станции автоматически появляется ссылка на эту программу (shortcut) и ассоциация расширения .pdf c Acrobat Reader, но сам продукт не инсталлируется на компьютер, пока пользователь явно не воспользуется им, например, попытавшись открыть файл с расширением .pdf.

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

Принципы работы MSI

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

Копирование файлов, запись в реестр, регистрация компонентов и некоторые другие действия теперь выполняет не программа-инсталлятор, а ОС, точнее, MSI. Вся информация, необходимая для установки программного продукта (кроме самих устанавливаемых файлов), содержится в файле msi. Данные этого файла в процессе установки интерпретирует процессор (engine), входящий в состав MSI. Файлы с расширением .msi ассоциированы с этим процессором, и их открытие приводит к запуску процедуры установки продукта.

Фактически в этих файлах содержится реляционная база данных, описывающая функциональные модули программы (program’s features), компоненты программы, файлы, входящие в программу, COM-серверы и действия, которые необходимо выполнить при установке каждого компонента.

С обнаруженными в дистрибутиве функциональными модулями, в зависимости от желания пользователя и требований программного продукта, MSI может поступить четырьмя способами: установить на локальный диск, настроить модуль на работу непосредственно с дистрибутива (например, с CD-ROM или сетевого сервера), объявить (advertise) модуль или приложение целиком или не устанавливать модуль.

Принципиально новой является возможность объявить модуль в операционной системе. При объявлении функционального модуля MSI не копирует файлы, входящие в состав модуля, но регистрирует COM-объекты, создает shortcuts и ассоциации с расширениями файлов, которые ссылаются не на реальные файлы, а содержат специальные инструкции для MSI. При попытке воспользоваться такими ссылками MSI осуществляет реальную установку на компьютер файлов, входящих в функциональный модуль.

С помощью объявления модулей можно автоматически добавлять необходимую пользователю функциональность. MSI может также использовать базу данных функциональных модулей, хранящуюся на сервере, в службе директорий Active Directory. Это позволяет администратору поместить дистрибутив на сервер и объявить входящие в него модули сразу на всех рабочих станциях.

Принцип реализации механизма объявлений довольно прост. Например, для того, чтобы поддерживать объявление COM-объектов, необходимо немного переделать ole32.dll, а точнее, функции, использующиеся для создания COM-объектов: CoCreateInstance, CoCreateInstanceEx. Эти функции находят в реестре записи, соответствующие создаваемому объекту, и по этим записям определяют имя файла (динамической библиотеки или исполняемого файла), в котором находится реализация требуемого COM-объекта. Теперь в записях может находиться специальная информация (скорее всего, GUID-компонент программного обеспечения или идентификатор программного продукта и функционального модуля в нем), по которой ole32.dll понимает, что для доступа к COM-объекту необходимо сначала установить его, и передает соответствующий запрос в MSI. После завершения установки объекта ole32.dll уже может вернуть указатель на него в сделавшую запрос программу (см. рис.).

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

Структура программного продукта

Для использования MSI необходимо структурировать программный продукт. Продукт разделяется на функциональные модули (features), которые пользователь может пожелать или не пожелать установить. Функциональные модули состоят из компонентов (components). Компоненты - это объекты программы, которые могут совместно использоваться как различными функциональными модулями, так и различными программами.

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

Структура базы данных

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

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

Особенности разработки

Ожидается, что компании, выпускающие средства подготовки дистрибутивов (InstallShield, Great Lakes Software’s Wise, Seagate’s WinInstall), создадут версии своих продуктов для работы с MSI, и разработчики, использующие эти средства, смогут без проблем подготовить новые версии дистрибутивов.

Для прикладных программ разработан интерфейс, реализованный в MSI.DLL и описанный в MSI.H. С помощью этого интерфейса программы смогут контролировать и динамически изменять свою конфигурацию. Для того чтобы программа работала правильно, надо помнить, что прежде, чем из одного компонента обратиться к другому, необходимо проверить его наличие на компьютере и при необходимости установить. Соблюдение этого правила будет, видимо, самой сложной задачей при разработке программного обеспечения.

Желающие разработать собственные системы подготовки дистрибутивов или создать дистрибутив "руками" могут найти в MSDN полную документацию по структуре таблиц msi и правилам их интерпретации.

В заключение хочу еще раз сказать, что попробовать технологию MSI можно, поставив себе на компьютер (c Windows NT 5.0 beta 2 или Windows 98 + IE 4.01) Microsoft Office 9.0 beta. Вести разработку программ, в которых будет использоваться MSI, тоже можно уже сейчас с помощью Visual Studio 6.0.