Общие подходы к интеграции приложений в WinPE

Изначально сборки WinPE не представляют особого инструментария без набора добавочного софта. Поэтому в полный рост стоит проблема выбора приложений и способов их интеграции в сборку. В принципе, любой процесс создания интегрированного софта сродни созданию портативного приложения и поэтому на него распространяются все принципы портабелизации.
Интеграция хранимых файлов:
1.1 - Прямая интеграция при которой в сборку помещаются все необходимые папки и файлы
1.2 - Использование контейнеров с распаковкой в момент запуска(rar, 7z, классические портативки и так далее)
1.3 - Использование контейнеров допускающих использование без распаковки (wim,zip,cab)
Интеграция информации реестра:
2.1 - Добавление в реестр записей в момент сборки. Добавление описания служб уровня ядра за счет запуска через TXTSETUP.SIF/TXTSETUP.OEM.
2.2 - Добавление в реестр записей используя скрипт запуска(REG-файлы, INF-файлы, прямые записи через REG.EXE, динамическая регистрация библиотек через REGSVR32.EXE, добавление служб через SC.EXE и так далее)

Рассмотрим подробнее достоинства и недостатки данных методик.
1.1
Достоинства: При таком способе файлы доступны без добавочных телодвижений. Возможно сразу назначить нужные асоциации в системе. Возможен прямой запуск приложения. Не требуется добавочная память и/или дисковое пространтво для запуска приложения.
Недостатки: В сборке занимает полный объем(файлы неупакованы и в общей ситуации фрагментарно разбросаны по диску). Время считывания файлов может быть значительно по тем же причинам. Невозможно создание файлов в папке программы в случае запуска с readonly-носителя без применения FBWF.
Показания к применению: Для небольших, по размеру и количеству файлов, программ. Для постоянно используемых в системе программ - например для базовой оболочки. Использование в сборках предназначенных для систем с малым/сверхмалым объемом RAM.

1.2
Достоинства: В сборке занимает меньший объем за счет высокой степени упаковки. Хорошая модульность - обновление заменой одного файла. Высока степень целосности данных приложения за счет использования контейнера. Данные программы расположены в одном файле. При распаковке на RAM-диск высока скорость считывания в процессе работы. Возможность создания файлов в папке программы.
Недостатки: Требуется добавочная память и/или дисковое пространтво для запуска приложения.
Показания к применению: Приложения требующие создания временных файлов в папке программы. Приложения небольшие по размеру, но с большим количтвом файлов. Использование в сборках предназначенных для систем с большим объемом RAM.

1.3
Достоинства: В сборке занимает меньший объем за счет средней степени упаковки. Хорошая модульность - обновление заменой одного файла. Высока степень целосности данных приложения за счет использования контейнера. Данные программы расположены в одном файле. Не требуется добавочная память и/или дисковое пространтво для запуска приложения.
Недостатки: Невозможно создание файлов в папке программы в случае мотирования с readonly-носителя без применения FBWF либо монтирования только на чтение.
Показания к применению: Любые приложения с запуском "по-требованию".

2.1
Достоинства: Записи в реестре доступны сразу после старта системы. Не требуется время на выполнение добавочных скриптов. Возможен автоматический запуск описанной службы при старте системы.
Недостатки: Увеличение размера реестра и времени старта системы. Невозможна динамическая прописка вычисляемых ключей в реестре за исключением переменных окружения(когда приложение допускает их использование).
Показания к применению: Для общесистемых или используемых при каждом запуске приложений и служб. В частности драйвера SCSIRAID для не RAM/WIM сборок. В основном сочетается только с файловым методом 1.1

2.2
Достоинства: Не изменяет размер реестра, что уменьшает время старта системы. Возможна динамическая прописка вычисляемых ключей в реестре. Возможно использование приложения в качетве портативного из любого места запуска.
Недостатки: Записи в реестре недоступны сразу после старта системы. Требуется время на выполнение добавочных скриптов.
Показания к применению: Любые приложения с запуском "по-требованию".

Заключение: На данный момент может применяться разнообразное одновременное сочетание файловых и реестровых методик, но сочетание методик 1.3 и 2.1 наиболее оптимально по используемой памяти и занимаемому объему.