Диссертация Кочарян С.Г (1195361), страница 5
Текст из файла (страница 5)
%token% = model_section_name
В секции может быть много поставщиков и, соответственно, ссылок на секции описания моделей. Вот один из примеров DDK:
[Manufacturer]
%ATAPI_CHGR% = atapi_chgr
%CHINON% = chinon_cdrom
%DENON% = denon_cdrom
%FUJITSU% = fujitsu_cdrom
%HITACHI% = hitachi_cdrom
%HP% = hp_cdrom
%MITSUMI% = mitsumi_cdrom
%NEC% = nec_cdrom
%OTI% = oti_cdrom
%PIONEER% = pioneer_cdrom
%WEARNES% = wearnes_cdrom
%GenManufacturer% = cdrom_device
Данная секция описания поставщиков содержит 12 записей о поставщиках. Слева указаны маркеры (token – идентификаторы, обособленные двумя знаками процента, см. ниже), которые позже, в том же inf-файле в секции «Strings», соотнесены со строками-названиями производителей в полной текстовой форме. Справа от знака равенства указаны имена секций (например, секции «atapi_chgr » ), описывающих установку программного обеспечения для моделей аппаратуры данного производителя (ссылки на секции моделей), которые были в этом файле рассмотрены позже.
Другая форма возможна для операционных систем, начиная с Windows XP, где можно указывать разные секции моделей в связи с версией операционной системы. В результате строки в секции «Manufacturer» приобретают вид:
%token%= model_section_name[,TargetOS] [,TargetOS]
Например, для Windows Server 2003:
[Manufacturer]
%MSFT%=Microsoft_Model_Section, NT.5.2
Соответственно, секции моделей будет начинаться так:
[Microsoft_Model_Section]; допустимо для ОС систем до и включая
<тело секции моделей> ; Windows XP
[Microsoft_Model_Section.NT.5.2] ; для Windows Server 2003
<тело секции моделей>
Значение маркера следует раскрыть в секции [Strings].
Для секции описания производителя [Manufacturer] возможна и другая форма (содержащая только идентификатор производителя, являющийся одновременно и ссылкой на секцию моделей), например:
[Manufacturer]
"Microsoft"
Тогда и секция описания модели будет выглядеть иначе, например:
[Microsoft]
<тело секции моделей>
Таким образом, секция описания поставщиков является связкой между идентификаторами поставщиков, чье оборудование обслуживается устанавливаемым inf-файлом программным обеспечением, и наборами моделей аппаратуры от каждого из них. В подавляющем большинстве случаев inf-файл содержит одного поставщика и, соответственно, одну секцию моделей.
На рисунке 4.1 показана взаимосвязь между секциями inf-файла. Каждая запись в секции описания поставщиков [Manufacturer] указывает на секцию описания моделей для данного поставщика. В этой секции моделей вводятся уже записи, указывающие на секции, описывающие собственно установку программного обеспечения, то есть копирование файлов (откуда/куда), изменения в Системном Реестре и т.п.
Рисунок 4.1 – Взаимосвязь между секциями
4.1.3 Секция описания моделей аппаратуры «Models»
Для каждого поставщика, указанного в секции [Manufacturer], должна быть представлена соответствующая секция описания моделей его аппаратуры [Models]. Имя данного типа секций не может быть жестко регламентировано, потому что разработчик сам задает его в секции [Manufacturer].
В каждой такой секции [Models] записи представляются по следующей форме:
device_description = install_section_name,hw_id[,compatible_id...]
где device_description представляет собой уникальный набор видимых символов либо маркер, обязательный для определения в секции [Strings]. Данная строка будет предъявляться пользователю во время инсталляционного диалога, так что имеет смысл позаботиться о поддержке нескольких языков.
Значение install_section_name представляет собой ссылку на секцию, описывающую собственно действия по инсталляции для данной модели (в документации DDK такого типа секции обозначены как [DDInstall]).
Значение hw_id является PnP идентификатором, возвращаемым аппаратным устройством во время опроса PnP-совместимой шины. Например, USB\VID_04B4&PID_1002 определяет плату тестового набора фирмы Cypress (так называемый EZUSB Kit). Любое количество значений compatible_id может быть приведено для обозначения того, что та же самая инсталляционная запись должна быть использована для указанного в этом списке устройства.
Применение одной и той же группы символов может сбить с толку начинающего разработчика inf-файлов. Рассмотрим показательный пример из DDK для Windows XP.
[Version]
Signature = "$Windows NT$" ; inf-файл для установки только под NT
Class=System
ClassGUID={4d36e97d-e325-11ce-bfc1-08002be10318}
Provider=%MSFT%
DriverVer= 5/1/2001
[Manufacturer]
%MSFT%=MSFT; со знаками процента - маркер
[MSFT]
%_MCADesc%=_MCA_Inst,_MCA0000
[_MCA_Inst.ntx86]
CopyFiles = _MCA.Files.x86_12
[Strings]
MSFT= "Microsoft" ; раскрываем маркер
_MCADesc= "Microsoft MCA Driver"
В секции [Manufacturer] видим, что маркер %MSFT% "приравнивается" ссылке MSFT. Это означает, что в данной секции описан поставщик Microsoft (именно так раскрывается маркер %MSFT% в секции [Strings]), a модели аппаратуры представлены в секции описания моделей [MSFT].
Переходя к рассмотрению секции моделей, видим маркер %_MCADesc% (раскрываемый как "Microsoft MCA Driver" – для диалога с пользователем при установке), который ассоциирован со ссылкой на секцию установки драйвера [_MCA_Inst]. Правда, эта секция снабжена суффиксом '.NTx86' (регистр не имеет значения), сообщающим о том, что данная секция применима только для установки в операционной системе NT на платформе Intel x86 (в документации DDK такое присоединение суффиксов называется декорированием имен секций).
Начиная с версии операционной системы Windows XP, имя секции моделей может декорироваться идентификатором версии, например:
[Manufacturer]
%MSFT%=MSFT_model
[MSFT_model.NT.5.1] ; Windows XP
[MSFT_model.NT.5.2] ; Windows Server 2003
4.1.4 Секция «CopyFiles»
Секции «CopyFiles » имеют уникальные для INF файла названия, ссылки на них исходят из директив CopyFiles секций [DDInstall]. Соответственно, конкретные имена этих секций определяет сам разработчик inf-файла.
Каждая запись внутри секции [CopyFiles] имеет вид
destination-filename[, source-filename][, temp-filename][, flag]
где destination-filename является целевым (то есть новым, конечным) именем файла после копирования. Предполагается, что и исходный файл имеет такое же имя. В том случае, если исходный файл все-таки называется иначе, необходимо указать source-filename. Требование указывать temp-filename все еще требуется для Windows 98/Me, и это поле вводит промежуточное имя для нового файла до момента первой перезагрузки системы. В Windows 2000/XP/2003 это значение игнорируется.
Значение flag определяет управление новым целевым файлом, что подробнее отражено в таблице 4.1.
Таблица 4.1 – Определение значения flag в записях секции [CopyFiles]
Значение | Символьное имя | Описание |
0x0400 | COPYFLG_REPLACEONLY | Копировать исходный файл только в том случае, если в целевой директории есть файл с таким именем |
0x0800 | COPYFLG_NODECOMP | Копировать без разархивации (если файл обработан архиватором) |
0x0008 | COPYFLG_FORCE_FILE_IN_USE | Если файл с целевым именем в целевой директории сейчас открыт, то следует копировать исходный файл в файл с временным именем, форсировать перезагрузку, после чего переименовать временный файл |
0x0010 | COPYFLG_NO_OVERWRITE | Не переписывать существующие одноименные файлы в целевой директории |
0x1000 | COPYFLG_REPLACE_BOOT_FILE | Файл является частью системной загрузки, форсировать перезагрузку системы |
Продолжение таблицы 4.1
Значение | Символьное имя | Описание |
0x2000 | COPYFLG_NOPRUNE | Осуществить копирование, даже если инсталлятор не считает эту операцию целесообразной |
0x0020 | COPYFLG_NO_VERSION_DIALOG | Не переписывать одноименные существующие файлы, которые датированы как более новые, нежели предназначенные к записи (игнорируется, если инсталлируемый пакет имеет цифровую подпись) |
0x0004 | COPYFLG_NOVERSIONCHECK | Всегда переписывать целевые файлы (флаг игнорируется, если инсталлируемый пакет имеет цифровую подпись) |
0x0040 | COPYFLG_OVERWRITE_OLDER_ONLY | Переписывать только те существующие файлы, которые являются более старыми, чем имеющиеся в пакете (данный флаг игнорируется, если инсталлируемый пакет имеет цифровую подпись) |
Окончание таблицы 4.1
Значение | Символьное имя | Описание |
0x0001 | COPYFLG_WARN_IF_SKIP | Предупреждать пользователя о возникшей необходимости пропустить переписывание файл (игнорируется, если инсталлируемый пакет имеет цифровую подпись) |
0x0002 | COPYFLG_NOSKIP | Запретить пользователю выбор возможности пропуска каких-либо файлов при копировании (всегда применяется, если инсталлируемый пакет имеет цифровую подпись) |
Для описания сложного управления необходимо выполнять ИЛИ над операндами – для получения одновременного воздействия указываемых вариантов. Некоторые варианты взаимно исключают друг друга (например, COPYFLG_WARN_IF_SKIP и COPYFLG_NOSKIP), поэтому следует в сомнительных ситуациях обратиться к документации.
Так как секции [CopyFiles] не имеют синтаксических средств указывать диск или полный путь к исходному файлу, то следует использовать другие секции, такие как [SourceDisksNames] и [SourceDisksFiles]. Место (конкретные файловые каталоги), куда файлы будут помещены в результате установки, определяется другой секцией, называемой [DestinatonDirs].
Следует отметить, что здесь секция [CopyFiles] описывается, как присутствующая в inf-файле по той причине, что на нее ссылалась директива CopyFiles из секции [DDInstall]. На самом деле, директива CopyFiles может присутствовать и в секции [ClassInstall32], которая посвящена инсталляции нового класса устройств в системе (будет рассмотрена ниже). Вводимая таким образом секция [CopyFiles] должна быть построена по таким же правилам, как указано здесь.
4.1.5 Секции «ServiceInstall»
Секции типа [ServiceInstall] предназначены для заполнения или модификации подраздела Системного Реестра, описывающего загрузку драйвера в сервисном подразделе для данного драйвера, а именно – в подразделе HKLM\System\CurrentControlSet\Services\<service-name>. Здесь <service-name> – это значение поля service-name, указанное в директиве AddService в секции [DDInstall.Xxx.Services]. Конкретное имя секции типа [ServiceInstall] выбирается разработчиком inf-файла. Декорирование имен секций данного типа (с целью отразить ее предназначение для конкретной версии системы) уже не имеет смысла и не воспринимается, поскольку эта принадлежность должна была быть введена раньше – на уровне секций [DDInstall.Xxx.Services]. Описание директив для секций типа [ServiceInstall] приводится в таблице 6, причем директивы ServiceType, StartType, ErrorControl и ServiceBinary являются обязательными. Эти директивы однозначно определяют информацию (значения одноименных параметров), которая появится в Системном Реестре в сервисном подразделе для данного драйвера.
Таблица 4.2 – Записи секции [ServiceInstall]
Запись | Значение поля |
DisplayName | Развернутое наименование драйвера, выводится на экран Мастером Установки Оборудования |
Description | Краткое описание назначения драйвера или сервиса, выводится Мастером Установки Оборудования |
ServiceType | Для драйвера режима ядра 0x01 (см. также Приложение В) |
Окончание таблицы 4.2
Запись | Значение поля |
StartType | Определяет момент загрузки драйвера |
ErrorControl | Распоряжение относительно возникающих ошибок: |
ServiceBinary | Путь к файлу драйвера |
AddReg | Вводит (через запятую) ссылки на секции типа [AddReg], в которых описываются действия над Реестром, которые следует выполнить дополнительно к описанным в данной секции |
LoadOrderGroup | Идентифицирует группу, в которой должен загружаться драйвер (возможные группы можно увидеть в разделе Системного Реестра HKLM\System\CurrentControlSet\Control\GroupOrderList) |
Dependencies | Указывает сервисы (драйверы) или группы загрузки, которые должны быть загружены к моменту загрузки драйвера. Имена групп выделяются при вводе предшествующим им знаком '+'. |
Директивы LoadOrderGroup и Dependencies широко используются при установке драйверов SCSI устройств и фильтр-драйверов.