Вводная часть. Описание общей структуры аддонов. Основные определения, используемые в дальнейшем

2.1.SpecCase
2.2.KillWFP.lst
2.3.Finish
2.4.DelDrv.lst
2.5DelOC.lst
2.6.Addon.nfo
2.7.Required
2.8.Conflict
2.9.Hive
2.10.Upd
Каждый файл заслуживает детального описания и примеров использования

3.1. SYSOC
3.1.1. dosnet.inf
3.1.2. sysoc.inf
3.1.3. txtsetup.sif
3.1.4. РУководство по INF
3.2. SVCPACK
3.2.1. run
3.2.2. Создание "тихих" инсталяторов.

Txtsetup.sif - это как и понятно из названия файла Text setup system information file - файл установки текстового режима. После текстового режима, этот файл не нужен системе, поэтому он не копируется из дистрибутива не защищен цифровой подписью и не включен в состав файлов защищаемых SFC. В связи с этим, Txtsetup.sif идеально подходит для целей автоустановки, добавления-удаления компонентов и записей реестра.

Добавление\удаление записей

Удалить строку из txtsetup.sif проще простого - любой текстовый редактор это может. Также можно закомментировать строку точкой с запятой (что лучше, если вы не знаете что делаете).
А вот добавить строку сложнее, требуется знать синтаксис.

Синтаксис записи в секции копирования txtsetup.sif:
filename_on_source= diskid, , , , , , , subdir, upgradecode, newinstallcode, spare, spare, newfilename, flag, unknown

Рассмотрим пример:
[locsecw.chm]-файл дистрибутива (понятно, что он находится в i386)
[1] - соответствует секции [SourceDisksNames.x86] в txtsetup.sif. В данном случае параметр [1] означает,
что файл из оригинальной (RTM) сборки. Значение [100], например, означает принадлежность файла к SP1, SP2.
Отвечает на вопрос ОТКУДА?

[,,,,,,,] - пустые параметры отделенные знаками запятой специфика winnt систем. Точные значения неизвестны.

[21] - указывает папку назначения, секция [WinntDirectories], в данном случае %Windir%\Help
Отвечает на вопрос КУДА?

[0] - upgradecode - режим копирования файла. Предназначен для корректного обновления с нижних ОС.
значения:
0-Копировать всегда
1-Копировать только если файл присутствует в папке назначения
2-Не копировать если файл присутствует в папке назначения
3-Не копировать файл

[0] - newinstalcode - указывает на "чистую установку". Опционально. Если не указан, используется значение по умолчанию = 3, файл не копируется.

[localsec.chm] - новое имя, переименовывает при копировании.
Интересное отступление: в первоначальном имени присутствует буква w. Gosh предполагает, что w -сокращение от workstation, а p - Personal. Так планировалось называть версии XP, аналогично Professional и Home.
cmconW.chm = 1, , , , , , , 21, 0, 0, cmconcepts.chm - xp pro txtsetup.sif
cmconP.chm = 1, , , , , , , 21, 0, 0, cmconcepts.chm - xp home txtsetup.sif


[flag] - флаг копирования (подробнее смотрите руководство по работе с inf-скриптами).
[unknown] - пока не могу сказать, что это, но в родном файле используется для драйверов и системных файлов, значения от 2 до 180.

Теперь рассмотрим другой пример:
[_x] означает, что файл дистрибутива не сжат. Если [_x] отсутствует, программа установки предполагает, что файл сжат. Каждый файл XP перечислен в layout.inf, вместе с размером в байтах. Размер в байтах очевидно зависит от того, сжат ли файл или нет. Если txtsetup.sif укажет установке, что файл не сжат, то установщик будет сравнивать размер файла с layout.inf, чтобы удостовериться что размер не был изменен. Если размер файла не соответствует тому, что указан в layout.inf, установка xp может быть прервана ошибкой.

NB.Если устанавливается сторонняя программа, размера и имени которой нет в layout.inf, необходимость использования параметра [_x] отпадает.

NB2 Txtsetup.sif не сообщает установке место нахождение файлов. Его единственная функция скопировать в нужную папку нужный файл. Txtsetup.sif запускается после того как dosnet.inf скопирует дистрибутив в C:\$WIN_NT$. ~ LS. Txtsetup.sif предполагает, что исходные файлы постоянно находятся в этой папке. При установке с CD\DVD
все проще, потому как, файлы сразу переписываются в %windir%. В таком варианте dosnet.inf скорее выполняет второстепенные функции по указанию путей копирования.
Фактически, txtsetup.sif отвечает за копирование файлов, обеспечение удаления старых папок при апгрейде, создании кустов реестра, первоначальной загрузкой критических драйверов.

(с) Gosh http://gosh.msfn.org/txtsetup.htm
-------------------------------------------------------------------
авторский перевод + мелкие дополнения Volk1234

Пример txtsetup.sif для аддона CCleaner

[SourceDisksFiles]
Cleaner.inf = 100,,,,,,,20,0,0
CCleaner.cab = 100,,,,,,_x,,3,3

1. Как видим использован параметр [100] то есть указание на SP2(что не очень принципиально)
2. Inf Файл копируется в папку %Windir%\inf [20] для возможности деинсталяции аддона
3. Cab файл в папку Windows не копируется [,3,3] и несжат[_x](?). Файлы из cab просто устанавливаются с помощью одноименного inf.

SYSOC.INF

Здесь немногое что удалось собрать.
Sysoc - System Optional Components - диспетчер установки дополнительных компонентов ОС.
В процессе выполнения программы установки выполняется файл sysoc.inf, посредством библиотеки ocgen.dll и других.
Состоит в основном из секций [Components] где указываются устанавливаемые дополнительные компоненты.

Синтаксис:
WGA= ocgen.dll, OcEntry, Pck_WGA.inf, HIDE, 7

WGA- имя исполняемой секции
ocgen.dll- библиотека обработчик sysoc
OcEntry- команда ocgen.dll (нечто вроде точки входа)
Pck_WGA.inf- название inf файла устанавливаемого компонента
Hide- скрыть компонент
7- флаг (неизвестно) для ocgen.dll всегда равен 7

-Для интеграции установки через Sysoc в ваш inf-файл необходимо добавить секцию:
-Для размещения вашего приложения устанавливаемого через Sysoc в группе 3rdParty (Программы сторонних разработчиков)
добавьте в исполняемую сециюParent=NonMS и удалите из Sysoc параметр HIDE.
[/code]

-Параметр Modes=0,1,2,3
точное значение не известно, однако разместить его в исполняемой секции можно 2 способами:
Без параметра Modes аддон не будет установлен.

Для примера я выбрал программку Netlook. Причина: желание совместить приятное с полезным, такого аддона еще нет, программка не очень большая,записей в реестр не делает(то есть практически портэйбл), и лично мне пригодится.
Сознательно не использовались средства автоматизации создания аддона (смотрите во втором примере), дабы пример был более наглядным.
Аддон можно скачать здесь и подробно изучить.

Этап один.

После изучения структуры самой программки, я скопировал ее в отдельную папку для экспериментов и распотрошил, извлек все файлы в одну папку. Их оказалось не много не мало, 32 штуки.
Наступило время создать inf файл собственно. Создаем заголовок.
WINDOWS NT стоит использовать вместо CHICAGO, мы же не делаем аддон для win95? Кроме указания на базовый класс установки больше в заголовке ничего не пишем, пока и не нужно.
Затем создаем самую главную секцию нашего inf-файла - исполняемую

Эта секция не обязательно должна иметь такое скучное имя, но поверьте от того, что она есть вам хуже не будет.
Разбираем по строчкам: CopyFiles копирует файлы попутно создавая нужные папки, ProfileItems добавляет ярлык программы. В моем случае ( хороший стиль написания inf-файла :) ) я воспользовался уже кем-то созданной папкой по адресу Пуск\Все программы\Утилиты.
Вроде, все выглядит просто. Но, для того чтобы создать секции копирования, которые так красиво смотрятся в строке CopyFiles=, придется попотеть- создать все эти секции с перечислением файлов вручную. Вам никто не мешает проявить смекалку и используя специальные утилитки получить на руки в текстовом виде список файлов из папки куда вы их "распотрошили".
Секции я поименовал в соответствии с названием папок аддона Copymain - корневая и тд.
Далее прописываем будущую структуру папок в секции [DestinationDirs]
Не буду вас утомлять просто приведу ее
Здесь поясню почему так называется последняя секция. Оказалось, что создатель программы Netlook, ничего не слышал про хороший стиль программирования и присвоил двум файлам в своей программе одинаковое имя. Вот и пришлось один из них переименовать (файлы то лежат вместе), с тем чтобы далее, в секции RenToolsLang при копировании в отдельную папку вернуть все обратно.
И последняя секция, указывающая откуда копировать [SourceDisksNames]. Я запаковал все файлы из одной папки в cab-архив с
гордым именем netlook.cab и прописал его в inf-файле:

Создал секцию добавления ярлыка:

Второй этап.
Поместив inf и cab файлы рядом я проверил как устанавливается приложение. Хорошо устанавливается, клещами не вытянешь.
На этом этапе мы и будем изобретать клещи - секции для удаления нашего приложения (uninstall).
Сразу скажу, мне это далось не легко. В теории (учебнике по INF файлам) все выглядело просто. Указав в исполняемой секции AddReg= Секция добавления строк в реестр мы еще при установке приложения добавляем его в список установки\удаленимя программ.
Сама секция незамысловата и подробно описана в Учебнике. Самая важная строка это
, нижняя запись указывает какую секцию выполнить в inf файле при удалении программы.
Наблюдательный человек сразу заметит, что путь к netlook.inf необычный, %17% = Windows\INF\
Для корректной отработки нам необходимо скопировать наш файл именно в эту директорию. Добавляем в секции копирования
Вот так вот.
Собственно секция которая отвечает за удаление должна выглядеть так: удаление файлов, удаление директорий, удаление записей в реестре, удаление ярлыков программы. У вас, наверняка, как и у меня сразу мелькнула мысль, а может просто удалить всю папку с файлами и подпапками, и дело с концом? Сразу огорчу, не получилось. Оговорюсь, не получилось методами описанными в учебнике. Есть гораздо более действенные способы.
В результате консультаций на форуме, пришлось создавать отдельные секции удаления файлов (по сути дубляж секций COPY). Зато результат был налицо - файлы удалялись.
Дальше я создал секции удаления записей в реестре(сразу после удаления программы она исчезала из списка удаления программ), удаления ярлыка и удаления директорий. Все работало замечательно. Огорчало только, то что директории не удалялись.
Учебник однозначно говорит, что вызвать DelDirs проще простого:
1)Вызвать из секции деинсталяции
2)затем указать саму комманду
3)и уже в секции [dir] указать директорию, которую необходимо прибить.

Не буду вас мучить, мне помогли добрые люди на форуме, и средства автоматизации создания аддонов, которые мы решили здесь не рассматривать.
Оказалось, во-первых DelDirs необходимо запускать только через RunPostSetupCommands, т.к. команда Run, которую я упорно мучил, принадлежит setupapi, а DelDirs запускается через advapi; во-вторых необходимо было прибить всю структуру папок снизу. Только после этого мой скрипт заработал как надо.

Секции деинсталяции аддона
Этап третий.
Создание собственно аддона. Все что мы делали до этого - создание собственного инсталлятора для программы.
Инсталлятор готов, можно использовать его на здоровье. Вспомним структуру аддонов и приступим.
Копируем откуда-нибудь скелет аддона (хороший стиль, это чужой стиль, незабываем :)). Сразу же переименовываем главную папку аддона
своим именем, правим файл Addon.nfo где пишем информацию, которую все равно никто не будет читать. Копируем в папку Files\Forcecopy
cab и inf -файлы. Оттуда их проинтегрирует в i386 скрипт Petya V4sechkin.
Важный момент! Так как мы все делаем вручную, надо проверить папку i386 на предмет совпадений с нашими файлами, дабы не перезаписать что-нибудь важное или просто принадлежащее системе, в любом случае при совпадениях имен система копирует свой родной файл из дистрибутива, а не "чужой". К счастью, я нашел только нечто, с именем NETLOOP.inf.

Теперь нам необходимо создать в корневой папке аддона 3 файла. Начнем по порядку. Сначала наш аддона будет скопирован из дистрибутива
посредством txtsetup.sif при помощи dosnet.inf и только позднее будет обнаружен и установлен через sysoc.inf. В такой последовательности
я и предлагаю создавать файлы, незабывая, что в UpdatePack эти файлы без расширений.
Здесь же в приложениях есть статья про txtsetup . Поверьте, совсем не лишняя в багаже знаний.

txtsetup
Комментировать нечего, inf файл при установке копируется в Windows\INF\, а cab архив не копируется, так как это наш дистрибутив.

dosnet

*здесь d1 это папка i386.

Ну и собственно,

Sysoc
Вроде бы все готово. Однако если подумать, то в файле txtsetup мы не скопировали наш cab -файл. Обязательно надо переделать секцию указывающую
на источник копирования, дабы сообщить где искать cab.
Но еще не все, я как все новички споткнулся на файле sysoc. Запись Netlook=ocgen.dll,OcEntry,Netlook.inf,,7 означает, что будет исполнена
секция [netlook] в файле netlook.inf. А моя исполняемая секция называлась DefaultInstall. Естественно ничего не установилось...
Кроме того, необходимо добавить в наш установочный файл секцию указывающую sysoc, что это "его" компонент и команду для автоустановки аддона:
Также после проверки работоспособности установщика, удаляются записи о копировании inf-файла, так как txtsetup.sif скопирует его самостоятельно.
Теперь аддон готов к интеграции в дистрибутив. Интегрируем, проверяем аддон, проверяем журнал событий и выполняем qfecheck на отсутствие наличия ошибок.

Из названия следует, что данный тип использует оба выше описанных типа SYSOC и SVCPACK. Обычно это необходимо, когда после установки программы требуется
установить обновления, либо, когда некоторые значения записанные программой затираются на более поздних этапах установки. Рассмотрим это на примере аддона WMP 11
Структура папок сложнее, чем у простого аддона:

Как работает этот аддон? Используется специальным образом подготовленный дистрибутив. Описание этого этапа выходит за рамки статьи. Часть дистрибутива замещающая файлы WMP9 размещается в папке аддона Files. При интеграции аддонов в дистрибутив скрипт сжимает файлы и замещает файлы WMP9 файлами WMP11.
Чем хорош этот аддон для нашего примера, он пересекается с еще одним типом аддонов - с заменой системных ресурсов.
Однако цель аддона не только замена системных файлов, но и установка нового медиаплеера. Для установки используется метод SYSOC. Установка происходит с помощью файла wmp11rus.inf на который сделана ссылка в sysoc.inf через одноименный конфигурационный файл. Txtsetup, Dosnet используются для копирования установочных файлов на текстовом этапе.

Однако для того, чтобы медиаплеер остался в составе компонентов Windows и WFP не прервал установку из за неправильных версий файлов, необходимо подсунуть установщику файлы каталогов. Сделать это возможно только на этапе T13 когда устанавливаются обновления через SVCPACK. Вот из за этого, аддон и называется комбинированным. В папку аддона [..Files\ForceCopy\SVCPSCK] помещаются файлы каталогов и скрипт копирует их в одноименную папку дистрибутива. Конфигурационный файл Run отсутствует поскольку .cat-файлы подхватываются скриптом автоматически.

В целом комбинированные аддоны являются более сложным инструментом, но одновременно и более гибким. Они требуют основательной подготовки и знания всех нюансов установки Windows.
Однако, именно этот метод позволяет совместить удобство установки через inf-файл в sysoc.inf и "высокоуровневые" возможности SVCPACK. С практической точки зрения этот способ будет полезен для установки дополнительных компонентов аддона, выполнения действий невозможных на этапе SYSOC. В принципе, возможна и обратная ситуация, когда сам аддон устанавливается через SVCPACK, а некоторые действия необходимо произвести заранее через SYSOC(добавление записей в реестр, копирование файлов).

Изучив структуры папок и конфигурационных файлов скрипта Update Pack, давайте посмотрим как он работает с аддонами.
После выполнения собственных действий скрипт приступает к обработке аддонов.
Аддоны находящиеся в папке скрипта [Addons] обрабатываются в алфавитном порядке.
Скрипт проверяет условия заданные в конфигурационных файлах Required, Conflict и если все нормально продолжает работу, в противном случае выдается ошибка. Затем скрипт выполняет конфигурационный файл Start до начала других действий, далее основные операции с аддонами и последним выполняется конфигурационный файл Finish (при условии конечно, что эти конфигурационные файлы присутствуют в папке аддона).

Обработка файлов в папках аддона.

Структура папок
В корневой папке размещаются конфигурационные файлы аддона для скрипта. Эти файлы никуда не копируются.
В папке Files размещаются собственно файлы аддона. Размещенные в корне этой папки файлы, скрипт копирует в дистрибутивную папку I386 без учета вложенных папок, с заменой файлов в случае совпадения, предварительно сжимая их в CAB-архив и приводя к виду file.ex_ , либо без дополнительной обработки если файл дистрибутива не сжат (пример: Telnet.exe). Все файлы из этой папки должны быть прописаны в конфигурационных файлах txtsetup и dosnet (иначе мастер установки не скопирует их из дитрибутива).

Подпапка Compressed служит для временного хранения ранее сжатых файлов из папки Files. Эти файлы могут использоваться скриптом в дальнейшем для экономии времени на упаковку.

Подпапка ForceCopy служит для прямого копирования размещенных в ней файлов с учетом вложенных папок в I386 без дополнительной обработки.
Пример: файлы из вложенной папки SVCPACK копируются в [..I386\SVCPACK]

Все записи в чистом виде из конфигурационных файлов Dosnet, Txtsetup добавляются в Dosnet.inf, Txtsetup.sif, а записи из Sysoc добавляются в секцию [Components] файла sysoc.inf . Записи из конфигурационного файла Run добавляется в секцию [SetupHotfixesToRun] файла svcpack.inf.

Далее скрипт модифицирует svcpack.inf согласно имен *.cat - файлов размещенных в каталоге SVCPACK аддона (если такие файлы требуются). В секцию [ProductCatalogsToInstall] файла svcpack.inf добавляются имена всех *.cat файлов.

Обрабатывается список файлов, для которых нужно отключить WFP, посредством KillWFP.lst, удалются из дистрибутива и выводятся из под защиты файлы посредством DelDrv.lst, DelOC.lst (патч Sfcfiles.dll);
Также обрабатывается Addon.nfo при сборке все эти файлы сливаются в один ADDONS.TXT, который пишется в корень папки с собираемым дистрибутивом;

Этапы текстового режима различаются в зависимости от режимов установки.
Здесь рассматриваются этапы установки с дистрибутивного CD, из удаленного сетевого дистрибутива, с локального дистрибутива на жестком диске (zip, flash). В принципе мастер установки рассматривает любой вариант установки, кроме установки с CD, как установку из удаленного источника, отсюда и дополнительный этап копирования во временную папку $win_nt$.~ls, перезагрузку и уже только затем копирование в папку установки.

Первый этап проходит в текстовом режиме:

1. Запуск загрузчика установочного диска ntboot.bin (для CD).
2. Запуск bootfix.bin (для CD).
3. Запуск setupldr.bin. Если установка выполняется не с CD, то файл setupldr.bin (запускаемый через winnt.exe) переименовывается в $LDR$ и копируется на диск установки для использования в качестве временного загрузчика для дополнительного этапа копирования.
4. Setupldr.bin ( $LDR$) передают, через winnt.exe, управление Setupdd.sys который с помощью txtsetup.sif и winnt.sif выполняет основные фазы текстового этапа, такие как копирование файлов и сбор информации о оборудовании для последующих этапов установки.
5. Чтение и интерпретация txtsetup.sif, winnt.sif и некоторых других файлов. Для установки не с CD используется dosnet.inf содержащий сведения о файлах в папке $win_nt$.~ls
6. Загрузка драйверов оборудования.
7. Запуск ntoskrnl.exe, ntdll.dll и smss.exe (фактически загружено ядро системы).
8. Копирование файлов с дистрибутивного диска в %WINDIR%. Или в случае установки из удаленного источника(пусть даже со второго раздела диска) копирование производится в локальный источник: папку $win_nt$.~ls. Затем следует перезагрузка и с помощью загрузчика $LDR$ управление передается Setupdd.sys который повторяет этапы 4-8, только на этот раз файлы копируются из $win_nt$.~ls в %WINDIR%.
9. Копирование прототипов реестра в %WINDIR%\system32\config\*.sav , было выполнено вместе с другими файлами, после производится обновление и инициализация реестра с помощью hive*.inf.
10. Setupdd.sys создает файл $wint$.inf в зависимости от конфигурации оборудования и содержимого файлов txtsetup.sif , sysetup.inf, layout.inf, winnt.sif (unnatend.txt). Файлы $wint$.inf (%windir%\System32), sysetup.inf, layout.inf (%windir%\inf) будут использованы мастером установки в графическом этапе установки.
11. Создание загрузочного сектора, загрузчика NTLDR, файла boot.ini.
12. Перезагрузка.

Второй этап продолжается в графическом режиме.

1. T39 – запуск setup.exe который передает управление библиотеке syssetup.dll. Эта библиотека координирует весь процесс установки в графическом режиме, используя информацию для установки из файлов syssetup.inf, $wint$.inf, layout.inf. При этом используется множество динамически подключаемых библиотек, таких как setupapi.dll, netshell.dll, ocgen.dll и др., для выполнения различных действий в процессе установки.
Отрабатывает параметр DetachedProgram секции [GuiUnattended]
2. Загрузка nt5.cat и прочих файлов безопасности каталогов.
3. Запуск ocmanage.dll (диспетчер дополнительных компонентов).
4. Определение установленного оборудования (machine.inf).
5. T37 – установка драйверов устройств.
6. Создание и запуск intl.cpl используя информацию из intl.inf (конфигурируются региональные настройки).
7. Запрос CD-KEY.
8. Установка дополнительных компонентов ОС (sysoc.inf) С помощью sysoc.inf менеджер установки
строит список файлов для установки этих компонентов. Затем этот список сверяется с файлом unatend.txt (winnt.sif) если он есть.
По результатам сверки образуется конечный список устанавливаемых компонентов..
9. T32 – установка поддержки сети.
10. T29 – копирование всех необходимых файлов ОС.
11. T25 – завершение установки.
12. T22 – установка меню «Пуск» (shell.inf) и сохранение сделанных изменений в реестре.
13. T18 – регистрация компонентов (OLE regsrv).
14. T13 – обработка SVCPACK.inf.
14. T12 – запуск $OEM$/Cmdlines.txt.
16. T9 – сохранение параметров, установка административных разрешений для системных папок и реестра, запуск команд из секции [SetupParams].
17. T8 – сохранение настроек (sfc.dll сканирует все системные файлы для создания базы WFP и заменяет неоригинальные файлы).
18. Создание signhash Hardware ID.
19. Удаление временных файлов.
20. Перезагрузка.

Третий этап продолжается в графическом режиме:

1. Включение oobeinfo, активация копии системы.
2. Добавление пользовательских профилей.
3. Применение установок.
4. Настройка пользовательских профилей.
5. Запуск команд из секции GuiRunOnce.
6. Загрузка рабочего стола.


█ Log-файлы создаваемые в процессе установки.

Размещение log-файлов: \%Windir%

◦ Setupapi.log

Файл для Setupapi.dll, которая обрабатывает inf файлы во время установки аппаратных средств и регистрации. Этот файл может содержать записи, которые начинаются c [#E], что указывает на проблемы или ошибки. Мониторит установку через inf-файлы и на установленной системе.

◦ Setuperr.log

Общий журнал ошибок в процессе установки.

◦ Setuplog.txt

Общий журнал установки. Содержит все действия, совершаемые во время последней установки.

◦ Upgrade.txt

Лог менеджера установки, после запуска проверки на совместимость с windows XP.

◦ Setupact.log

Довольно полезный лог, создаваемый во время определения аппаратных устройств и установки драйверов.

◦ Winnt32.log
Содержит информацию о тестовом режиме установки, но создается только в процессе
апгрейда системы, а не установки.

◦ Wsdu.log

Лог динамического обновления установки (только если используется динамическое обновление)

◦ Log-файлы генерируемые дополнительными компонентами.

Это тип аддонов, изменяющих дистрибутив в процессе интеграции обновлений и других аддонов (не всегда), т.е. не в процессе установки в отличие от других типов.
Относятся к категории т.н. служебных аддонов. Позволяет получить функциональность в процессе установки, которую невозможно получить другими способами. Описать типичную структуру такого аддона или привести общую инструкцию не возможно. Причины банальны: изменение ресурсов возможно несколькими способами, требует солидных знаний, долгого тестирования на стабильность.
Пример "мирного" применения аддона изменяющего системные ресурсы: аддон Vista Path изменяющий стандартные иконки на более красивые. Или аддон ZZ_multiboot, не изменяет дистрибутивную папку (I386), но создает структуру папок и записывает необходимые файлы и модифицирует их для получения мульти загрузочного диска. Причем, можно создавать диски N-in-1 (например Windows Home и Proffesional версий + множество вариантов загрузки из стандартного аддона Z_DRV_INST).

Еще пример, аддон Z_DRV_INST не модифицирует файлы в дистрибутиве, но слегка изменяет и дополняет его новой функциональностью (Подменой Setup.exe во время установки и установкой драйверов).

При затрагивании важных системных файлов приходится иметь дело с Windows File Protection. Как ее обойти читайте здесь .

Если по каким- либо причинам использовать патч sfcfiles.dll нельзя или невозможно, можно только посоветовать эту статью раздел Modify PE, про изменение контрольной суммы файлов.

В составе Update pack приcутствует патч SFCfiles.dll написанный участником конференции BoaSoft
Взаимодействовать с патчером возможно путем конфигурационных файлов KillWFP.lst, DelDrv.lst, DelOC.lst.

Синтаксис простой: название файла с расширением для которого необходимо отключить WFP и\или который
необходимо удалить из дистрибутива.

Описание патча sfcfiles.dll предоставим автору:

Зачем это нужно?

Большая часть важных для системы файлов в Windows Xp защищена от удаления и изменения
функцией WPF - windows file protection.

Если Вы хотите удалять или изменять некотрые файлы, то система не даст этого сделать,вернее обойти это можно, но при запуске sfc произойдет замена файлов на оригинальные или же последует вопрос на вставку диска с дистрибутивом.

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

Результат - отсутствующие файлы, Dll hell и падение системы.

Обычно же надо исключить только несколько фалов. Этого легко достичь патчем SfcFiles.dll, заставив ее "забыть" о этих файлах.

Алгоритм работы.

Программа действует очень просто

Какие файлы защищены - это система узнает из SfcFiles.dll. Эта библиотека не несет в себе прямых функций защиты, а только выдает список защищенных файлов.

Там находятся списки защищаемых файлов, целых 5 штук для разных систем:
Xp pro
Xp home
Xp tablet PC
Xp mediacenter
Xp starter

В серверной библиотечке тоже 5 списков, но их назначения (соответствия версиям продуктов) не выяснены.

Система защиты получает список защищенных файлов с полными путями из этой библиотеки, вызывая Api - функцию SfcGetFiles. Нам же нужно, чтобы в этот список не попали нужные нам файлы.

В 3-й версии патчера применен новый алгоритм - патчатся не строковые значения, а таблица указателей. Этих таблиц так же 5 - по числу версий продукта. В этой таблице просто происходит подмена указателей на выводимые из защиты файлы на указатель на любой из оставшихся файлов. В результате при выдаче списка файлов просто некоторые файлы будут присутствовать более одного раза, а работа SFC никак не изменится - все не выведенные файлы будут защищены..

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

NB! Если патчить библиотеку, ранее уже патченную более старыми версиями патчера или другими утилитами, то возможны разные непредсказуемые проблемы.

Проверялось с SfcFiles.dll от windows sp2 rus/ sp2 en/ sp1/2003 server rus.
(Во всей линейке OS одного семейства и сервиспака библиотека одинакова!)

С другими версиями программа так же должна работать.

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

SFC /scannow должно работать!!! Если нет - то увы.

Это тип аддонов изменяющих дистрибутив в процессе интеграции обновлений и других аддонов, т.е. как правило не в процессе установке в отличИе от других типов.

может лучше сначала ?
По-моему т.к. следующее слово начинается с гласной буквы.
?
И вообще получается масло масляное
Вроде так
Может поменять местами, а то получается аддон Files и дистрибутив I386.
Т.к. есть слово необходимо, то уже не нужно слово нужно
Запятая не нужна
По-моему нужна запятая
Может лучше так?
Может это словосочетание убрать? Повтор получается
Запятая не нужна
:)

UpdateCfgSys

Позволяет отредактировать содержимое файла config.sys и указывает на раздел, который может содержать следующие ключевые слова: DevRename, DevDelete, DevAddDev, Stacks, Buffers, Files, LastDrive


UpdateAutoBat

Позволяет отредактировать содержимое файла autoexec.bat и указывает на раздел, который может содержать следующие ключевые слова: CmdAdd (формат: "программа","ключи программы"), CmdDelete (формат: "программа"), UnSet (формат: "имя переменной окружения"), PreFixPath (формат: "числовое значение, числовое значение"), RemOldParh (формат: "числовое значение, числовое значение"), TmpDir (формат: "числовое значение, дальней путь").

SmartReboot

Указывает, будет ли выполняться перезагрузка компьютера после установки сценария. Данное ключевое слово может принимать следующие значения.

— N — никогда не выполнять перезагрузку.
— AS — после установки сценария выполнить перезагрузку, не спрашивая согласия пользователя.
— IS — если система определила, что нужно выполнить перезагрузку, тогда компьютер будет перезагружен. При этом вопрос о перезагрузке задан не будет.
— A — после установки сценария спросить пользователя о перезагрузке компьютера.
— I — если перезагрузка необходима, тогда спросить у пользователя.

BitReg

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

"Корневой раздел", "ветвь реестра", "параметр", "флаг операции", " маска операции", "номер байта параметра"

Корневой раздел

Содержит идентификатор корневого раздела реестра, в котором расположен редактируемый параметр. Идентификатор может принимать следующие значения: HKCU (корневой раздел HKEY_CURRENT_USER), HKLM (корневой раздел HKEY_LOCAL_MACHINE), HKU (корневой раздел HKEY_USERS), HKCR (корневой раздел HKEY_CLASSES_ROOT), HKCC (корневой раздел HKEY_CURRENT_CONFIG),HKR (ветвь реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlClass[{GUID-класса устройства}][номер устройства]).

Флаг

Определяет тип редактирования параметра. Флаг представляет собой битовую маску, некоторые состояния которой представлены ниже.

— 0х00000000 — сбросить биты параметра.
— 0х00000001 — установить биты параметра.
— 0х00040000 — выполнить редактирование в 32-разрядном реестре.

Маска операции

Определяет биты одного байта значения параметра (одной строкой раздела inf-файла можно изменять биты только в пределах одного байта значения параметра), которые должны быть модифицированы. То есть, маска состоит из 8 нулей или единиц. Если установлена единица, тогда соответствующий бит значения параметра (на месте которого указана единица) будет сброшен или установлен в зависимости от флага операции. Маска операции является битовой маской.

Номер байта значения параметр

Определяет байт значения параметра, к которому будет применяться маска операции. Следует помнить, что начало нумерации байтов зависит от типа параметра. Для параметров типа REG_DWORD самый старший (то есть, самый правый) байт имеет номер 0, а для параметров типа REG_BINARY номер 0 имеет самый младший байт (самый левый).

Пример

Вот небольшая статья про CustomDestination. Несмотря на то что описание уже есть в руководстве по inf
файлам, здесь немного другой взгляд на комманду.

CustomDestination

Указывает на разделы inf-файла (через запятую), содержащие определение произвольных LDID-номеров на основе данных, введенных пользователем в появляющемся диалоге. Формат строк данных разделов следующий:

"новый LDID-номер"= "раздел, описывающий сообщение", "флаг".

Новый LDID-номер

Число от 40000 до 50000, используемое в дальнейшем в качестве LDID на введенный путь к папке.

Флаг

Определяет способ построения пользовательского LDID и может принимать следующие значения:

— 1 — выводить диалоговое окно, в котором пользователь должен ввести путь к каталогу, к которому в дальнейшем будет вести создаваемый LDID.
— 2 — каталог, к которому будет вести создаваемый LDID, определяется значением параметра реестра.
— 34 — выводить пользователю диалоговое окно с произвольным текстом. При этом сам каталог, на который будет указывать пользовательский LDID, будет взят из реестра.

Раздел, описывающий сообщение

Параметр реестра, из которого будет браться путь к каталогу, текст, выводимый при отсутствии данного параметра реестра или при вводе пользователем пути к каталогу, а также каталог по умолчанию. Формат содержимого данного раздела следующий:

"корневой раздел реестра", "остальной путь к параметру", "название параметра", "выводимое сообщение", "каталог по умолчанию".

Пример
UpdateIniFields аналог UpdateInis

Указывает на разделы inf-файла (через запятую), содержащие в себе описание действий над содержимым значений полей ini-файлов, которые должны быть выполнены в процессе установки.
В отличии от UpdateInis оперирует с частью строки, а не со строкой в целом.
Формат строк этих разделов следующий:

"название раздела в ini-файле", "название ключевого слова ini-файла без знака =", "старое значение данного ключевого слова", "добавляемое значение нового ключевого слова", "флаг операции"

Флаг операции

Может содержать следующие значения.

— 00 — новое значение будет дописано через пробел к текущему значению редактируемого ключевого слова (используется по умолчанию).
— 01 — новое значение будет дописано через запятую к текущему значению редактируемого ключевого слова.
— в случае единицы впереди * интерпретируется как подстановочный символ, в случае нуля как буквальный символ


Ini2Reg

Указывает на разделы inf-файла (через запятую), содержащие в себе описание добавляемых в реестр строк ini-файла. Формат строк этих разделов следующий:

"название ini-файла", "раздел в ini-файле", "ключевое слово ini-файла", "корневой раздел реестра", "остальной путь к ветви реестра", "флаг"

Корневой раздел

Содержит идентификатор корневого раздела реестра, в котором расположен редактируемый параметр. Идентификатор может принимать следующие значения: HKCU (корневой раздел HKEY_CURRENT_USER), HKLM (корневой раздел HKEY_LOCAL_MACHINE), HKU (корневой раздел HKEY_USERS), HKCR (корневой раздел HKEY_CLASSES_ROOT), HKCC (корневой раздел HKEY_CURRENT_CONFIG),HKR (ветвь реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlClass[{GUID-класса устройства}][номер устройства]).

Флаг

Может содержать следующие значения.

— 0 — после переноса данных в реестр, соответствующие им ключевые слова не будут удаляться из ini-файла. При этом если в реестре уже существует создаваемая ветвь, тогда она переписана не будет. Значение по умолчанию.
— 1 — после переноса данных в реестр, соответствующие им ключевые слова будут удалены из ini-файла. При этом если в реестре уже существует создаваемая ветвь, тогда она переписана не будет.
— 2 — после переноса данных в реестр, соответствующие им ключевые слова не будут удаляться из ini-файла. При этом если в реестре уже существует создаваемая ветвь, ее содержимое будет переписано.
— 3 — после переноса данных в реестр, соответствующие им ключевые слова будут удаляться из ini-файла. При этом если в реестре уже существует создаваемая ветвь, ее содержимое будет переписано.

BackupPath


Определяет папку, в которой будет создан .dat-файл, содержащий в себе значения заархивированных параметров реестра. Значение этого ключевого слова заносится в параметр строкового типа BackupPath ветви реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Advanced INF Setup\"имя архива".

BackupReg

Указывает раздел inf-файла, описывающий все ветви реестра и параметры, значения которых будут занесены в архив. Формат строк раздела следующий:

"корневой раздел реестра", "остальной путь к архивируемой ветви", "параметр, значение которого нужно заархивировать".

PreRollBack

Указывает раздел inf-файла, являющийся начальным при восстановлении настроек реестра (то есть, при запуске inf-файла при помощи команды rundll32.exe ADVPACK.dll, LaunchINFSectionEx "имя информационного файла", "начальный раздел",,64).

ComponentName


Определяет имя создаваемого архива. Данное имя будет использоваться как в качестве имени создаваемого .dat-файла, так и в качестве имени раздела ветви реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Advanced INF Setup, содержащего настройки восстановления параметров реестра из данного архива.

Общий пример для команд ComponentName, ComponentVersion, PreRollBack, BackupReg.
[.Security]

С помощью inf-файлов можно не только копировать файлы, но и назначать права доступа к копируемым файлам. Для этого и предназначен раздел вида "имя раздела, описывающего копируемые файлы».Security" В этом разделе содержится строка DACL, присваиваемая всем файлам, определенным в соответствующем разделе, указанном в ключевом слове CopyFile.

Пример
PerUserRemove

Если существует секция PerUserInstall, то должна быть и обратная PerUserRemove (подглядел в инстале Win 98)
Данная секция обратна секции PerUserInstall и скорее всего отвечает за выведение из списка Active Setup.

Пример:

В данном примере рассмотрим устройство аддона-конструктора.
В основе аддона - возможность создания "тихой" установки K-lite с помощью ключа
инсталятора -unnatended. После запуска установки с этим ключом происходит, эмуляция
установки с обычном набором окошек: выбор папки установки, выбор устанавливаемых
кодеков. В результате мы получаем набор файлов для автоматической установки программы:
klmcp.ini, klmcp.bat и сам дистрибутив, переименованый в klmcp.exe, для краткости.
Автоустановка запускается через командный файл который состоит из одной строки
запускающий установку в "тихом" режиме и подключающий ini- файл с настройками:

Вобщем то приведенной информации достаточно чтобы создать аддон типа SVCPACK, запаковав
файлы Winrar в виде SFX архива, с "тихим" запуском батника при распаковке.
Для создания же конструктора лучше сократить количество действий пользователя при его сборке. Автор
аддона рассудил также и решил создать комбинированный конструктор (Sysoc+svcpack).

Посмотрим на структуру папок готового аддона:

На текстовом этапе файлы аддона копируются во временную папку %Windir%\Temp\KL:

KLITE.infФактически это и все что делается на текстовом этапе через Sysoc.

Установка кодеков происходит на Т13, для чего через Run создан пустой 7zip SFX-архив
с командами установки в коментарии архива.

klite.exe
Как видно ничего сложного, запускается коммандный файл в скрытом режиме, в качестве
папки источника для установки указана "%SystemRoot%\\Temp\\KL", куда на текстовом режиме
установки Windows , были скопированы необходимые файлы. Затем временная папка удаляется.

Это весь аддон. Как видно ничего сложного нет. Файлы установки лежащие в папке аддона
Files\ForceCopy можно заменять новыми версиями K-lite, по мере необходимости.
Можно спорить со способом реализации аддона выбранным автором, но аддон работает и это главное.

---

---

---

---

Цифровой префикс Назначение Пример
0 Служебные
0-HTMLINFO
1 Аддоны базового набора
1-BASECSP
1-FLASH
1-HDA
1-IE
1-IMAPI2
1-MMC3
1-MSXML
1-MU
1-PKGINST
1-PNRP
1-RDC6
1-ROOTSUPD
1-WEBFLDRS
1-WGA
1-XPNETDG
2 Разного рода обновления и дополнения встроенных компонентов ОС.
2-SHOCKWAVE
2-DOTNET35
2-DX9U
2-HTMCD
2-WMP11RUS
3 Неофициальные обновления или не рекомендуемые обновления ОС.
3-KB893056-MSGINA
3-KB901190-IME
3-EXTREMEPACK
4 Хаки
4-OOBE
4-RAID
4-RCADMIN
4-NODEP
5 Различные DLL и OCX файлы
5-EXPEXT
5-HASHTAB
5-PRIO
5-TARGET
6 Аддоны, предназначенные для внесения изменений в реестр и настройки ОС
6-UNPNC
6-XPRIGHTS
6-MYCUSTOM
7 Программы сторонних производителей.
7-WINRAR
7-EMEDITOR7
7-REGSHOT
7-SALAMANDER
7-VOLUMEC
8 Аддоны, предназначенные для удаления компонентов ОС и драйверов.
8-DEL_CAM
8-DEL_LANDRV
8-DEL_MODEM
8-DEL_MULTIPORT
8-DEL_PRN
8-DEL_SCANER
8-DEL_SCSI-4
8-DEL_VIDEODRV
8-DELBMPINWIN
8-DELGAMES
8-DELMOUSETOUR
8-DELNETMEETING
8-DELPINBALL
8-DELSCR
8-DELWINTOUR
8-DELWMPTOUR
8-DELZONEGAMES
9 Служебные. Предназначены для пост-обработки информации или создания образа.
9-ZLOG
9-BCDW

Бродя по темным закоулкам Technet и просматривая одним глазом DDK и SDK KIT для Win98 я наткнулся на описание
загадочной секции использующейся для установки через sysoc.inf. Я подозревал, что это штатная секция INF файлов, просто не сильно
афишировавшаяся. Итак,

Секция [Optional Components]

Синтаксис:


Данная секция служит для добавления устанавливаемого приложения в список оснастки "Установка\Удаление программ \Компоненты Windows"
Секция не будет исполнена при попытке выполнить файл по правому щелчку мышью, через команду [Setupx.dll InstallHinfSection точка_входа] также
нельзя выполнить [Optional Components]. В первом случае будет выполнятся секция [DefaultInstall], во втором секция указанная точкой входа. Параметры
[Optional Components] будут игнорированны.

Насколько я понимаю для обработки дополнительных инструкций секции [Optional Components] и существует sysoc.inf, ocgen.dll, sysocmgr.exe.
В основном инструкции [Optional Components] служат для управления отображения компонентов в окне "Компоненты Windows".

Вернемся к синтаксису, в секцию установки могут быть добавлены следующие инструкции ОС:


OptionDesc это строковой параметр задающий название дополнительного компонента отображающегося в "Компоненты Windows". Может быть задан через Strings.

Tip это текст подсказки в поле "Описание", ограничение - 255 символов. Может быть задан через Strings.

IconIndex это иконка которая будет отображатся рядом с названием компонента, привожу список в оригинале:

Parent это инструкция указывабщая является ли компонент подчиненным или родительским. Если параметр отсутствует, то менеджер дополнительных компонентов
считает что компонент родительский. Если указать несуществующий родительский компонент (например сам аддон) менеджер компонентов зависнет в попытке найти такого родителя.
Для всех Авторов Аддонов должен быть только один вариант Parent=NonMS (аддон 3dParty)- дабы не загаживать менеджер дополнительных компонентов (конечно, кроме особых случаев).

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

Include присоединяет inf- файл стороннего компонента к текущей установке, что позволяет ссылатся на секции в присоединенном файле

InstallDefault скорее всего досталось в наследство от Win98, я пробовал ставить аддон с этим параметром=1 вместо Modes=0,1,2,3 , аддон не поставился, но в списке
компонентов появился и позволил доустановить себя. У кого получится отпишитесь. Пока могу посоветовать использовать Modes=0,1,2,3.

Пример:

Может лучше так: Аддоны в зависимости от целей и способов интеграции в дистрибутив делятся на 4 типа
Нужна запятая
Может лучше: Аддоны этого типа устанавливаются с помощью INF скриптов
unattend.txt
некрасиво выглядит. Нельзя сделать, чтобы строка продолжалась?
Аналогично
Аналогично

Inf- файл можно выполнить путем вызова из коммандной строки через системную библиотеку Rundll32.exe.(также в Win98 Rundll.exe).
Кроме того Rundll32 можно вызывать прямо из inf- файла используя RunPreSetupCommands, RunPostSetupCommands(например вызвать секцию из другого\текущего inf- файла.)


1.Вызов через интерпретатор Setupx.dll

Синтаксис:

RunDll32.exe setupx.dll(setupapi.dll), InstallHinfSection <section> <reboot-mode> <inf-name>

1. <section> - Исполняемая секция
2. <reboot-mode> - Флаг перезагрузки
3. <inf-name> - имя и путь к inf- файлу

После такого вызова в inf-Файле setupx.dll повторно ее вызывать нельзя, так как это может привести к перезагрузке
или другим неприятным последствиям. Для многократных вызовов из файла интерпретатора лучше использовать RunOnce (см.ниже)

Имя исполняемой секции: если секция с таким именем не будет найдена, то ничего не будет "выполняться", и сообщений об ошибках тоже не будет.

Флаги перезагрузки

Как интерпретатор определяет необходимость перезагрузки? - Если при "выполнении" обновлялись системные файлы и хотя бы один из них не смог быть
обновлён из-за того, что в это время использовался системой, то перезагрузка необходима (сразу после перезагрузки произойдёт обновление файлов и процесс будет завершён).

RUNDLL32.EXE может работать в режиме совместимости с 9X (rundll32 setupx.dll) и в режиме
совместимости с NT (rundll32 setupapi). Одним из отличий 9X и NT вариантов выполнения является набор используемых констант LDID (logical directory identifier)

Важно! Именно через Setupx.dll (Setupapi.dll), происходит выполнение inf- файла при запуске его из контектного меню командой "Установить".


2. Вызов через advpack.dll

Синтаксис

RunDll32.exe advpack.dll, LaunchINFSectionEx <inf-file>, <section>, <cab>, <flag1>, <flag2>, 0


1. <inf-file> имя и путь к inf- файлу
2. <section> Исполняемая секция
3. <cab> Путь к cab- файлу если inf запакован.(в этом случае параметр <inf-file> просто содержит имя файла без пути)

4. flag1 - Флаг режима установки
Данные флаги могут складыватся, например, довольно распрастраненный режим Quiet|Backup (32+4) = 36

5. flag2- Флаг перезагрузки

Без данного флага используется Smart Reboot, т.е. перезагрузка по требованию.
6. 0- nShow не использутся = 0 приведен только для информации о синтаксисе функции.

пример с распаковкой inf из cab
пример с откатом установки inf
Важно! При использовании в inf- файле инструкции Reboot и вызове через Rundll32 данного inf- файла, будет обработан режим перезагрузки указанный в строке вызова через Rundll32. Напомню в учебнике по Inf написано:
Не стоит забывать про это !

Важно! Синтаксис описанных команд содержит запятые и пробелы, незабывайте их ставить, иначе команда несработает.

Использование RunOnce

Для запуска исполняемых файлов после того, как inf- файл исполнен, можно использовать RunOnce. Команды из RunOnce выполняются
после перезагрузки или следующего входа в систему.

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

Для "тихого режима" добавляется путь к приложению в ветку реестра:
HKLM, Software\Microsoft\Windows\CurrentVersion\RunOnce, "APPNAME", "APP_PATH"

Для режима с отображением установки в виде окна со списком устанавливаемых программ добавляется путь к приложению в ветку реестра:
HKLM, Software\Microsoft\Windows\CurrentVersion\RunOnce\Setup, "APPNAME", "APP_PATH"

"APPNAME" - во втором варианте будет отображатся в окне установки.