Практикум, или FAQ по мультизагрузке. Полезные советы.

Если конструкторам интересно - как сделать подхват текстового меню в bootmgr...

Возможность подхвата изначально заложена в bootmgr, для совместимости с загрузчиком более ранних ОС (NTLDR). При запуске меню bootmgr проверяет корень загрузочного раздела на наличие файла boot.ini. Если таковой найден, тогда прописанное в нем добавляется в конец BCD-меню. В применении к сборкам это не всегда удобно, лучше изменить это имя. Если возникнет желание "задвинуть" файл в "свою" папку, то возникнет проблема с ограничением длины пути/имени. Я обошел эту проблему следующим образом: путь указал на свободном месте ("освободилось" оно после удаления \CMLDR). А потом заменил все вызовы адреса нахождения \boot.ini на адрес нового варианта (\2k10\Guest.ini). Если путь получится еще длиннее, можно перенести в другое свободное место (например, прописать вместо китайских/японских шрифтов, естественно, с изменением адреса вызова).

Напомню, что править bootmgr можно, например, с помощью WBM Customizer или BMplus.
Примерное содержание boot.ini (Guest.ini, ну или как там вы его обзовете в патченном bootmgr)Примечание: текстовое меню позволяет загружать исключительно загрузчик предыдущего поколения (NTLDR), GRLDR, копии загрузочной области и некоторые сторонние загрузчики (например, Xorboot). Загрузить другой bootmgr, Wim/VHD прямо не получится. Хотя и можно - если сделать комплект из "костыля" на базе XorBoot/GRLDR, загружающий "другой" bootmgr (при необходимости, со своим же мономеню, автоматически запускающем Wim/VHD-загрузку).

По моему мнению, очень желательно при сборке WinPE соблюдать такие требования:

1. Размещать ВСЮ сборку (кроме EFI - увы, с этим ничего не поделать) в "своей" папке с уникальным именем.
2. Копию основного загрузчика (bootmgr) с "привязкой" к своей папке держать внутри этой папки, и все переходы между загрузчиками привязывать именно к этой копии (а не к корневому bootmgr). Создать загрузчик под свое уникальное имя папки можно с помощью утилиты BMplus.
3. Сделать костыль на базе XorBoot или Grub4Dos для загрузки bootmgr из "своей" папки (для перехода из "других" bootmgr). Для генерации костыля можно использовать, например, XBplus (для поддержки работы на CDFS/UDF /компакт-дисках/ обязательно использовать версию 1.0).
4. Реализовать возможность подхвата текстового меню (тоже из "своей" папки), для несложной организации переходов/возвратов в другие сборки.
Такая схема позволить конечным пользователям (или сборщикам) легко компоновать разные сборки с минимальными затратами времени.
Например, если использовать такую схему в этой сборке, можно вызовы костылей всех авторских сборок перенести из меню BCD в текстовое, что позволит с легкостью подправлять меню под свой "набор". А в BCD оставить только базовый функционал...

Небольшая справка по UEFI и GPT...

UEFI - это, по-сути, мини-ОС, задача которой запустить загрузчик. Загрузчиком служит файл из папки efi\boot: bootx64.efi для UEFIx64 или bootia32.efi для UEFIx32. Также в совместимом режиме Legacy Mode (если он поддерживается UEFI, зачастую это реализовано в x64-версии UEFI) возможна эмуляция Bios-загрузки (загрузка из MBR).
Примечание: опция "Legacy Mode / Legacy Boot" у некоторых производителей может называться иначе - "Boot List Option", "CSM" (Compatibility Support Module), "CMS OS", "Boot Mode".
UEFI поддерживает загрузку ОС/РЕ как с GPT-разделов (только из разделов FAT/FAT32), так и MBR HDD (если поддерживается "Legacy Mode").
Примечание: в классической реализации UEFI отсутствуют драйверы NTFS, поэтому такие разделы UEFI просто "не увидит" (и, соответственно, не сможет из них загрузиться). Некоторые производители (в новых реализациях UEFI) могут включать этот драйвер, тогда на таких ПК можно загрузиться и с NTFS-разделов. Но для гарантированной загрузки на различных ПК лучше форматировать загрузочный раздел в FAT/FAT32.
BIOS позволяет загружаться только из MBR-записи HDD. Хотя, после загрузки ОС на базе Windows 7 и выше, может полноценно работать и с GPT-разделами HDD HDD.
Примечание: работа с GPT-разделами также реализована в ОС Windows 2003 Server, но с некоторыми ограничениями (размер HDD не более 3Тб).
Использование GPT на практике не дает никаких преимуществ перед MBR, и, по сути, обязательно только для накопителей емкостью от 3Тб и больше (ограничение MBR - 2Тб). В то же время применение MBR позволяет использовать устройство для широкого спектра машин (как для Bios, так и для UEFI, с возможностью загрузки из устройства).
Примечание: загрузка в UEFI-режиме из MBR-раздела не отличается от загрузки из GPT-раздела. Требуется только загрузочный раздел под FAT(32) с загрузчиком нужной разрядности в папке efi\boot. Из этого выплывает требование для совмещения загрузки Bios/UEFI на одном накопителе: FAT(32)-раздел (обязательно MBR), UEFI-загрузчик(и) (в папке efi\boot) и MBR-загрузчик (прописка в загрузочной области MBR/PBR). Также возможно производить загрузку Bios/UEFI из разных разделов одного MBR-накопителя - например, Bios-загрузку из первого раздела (FAT32/NTFS/ExFAT) и UEFI-загрузку из второго FAT(32). В качестве накопителя можно использовать как обычный HDD/USB-HDD, так и UFD (флешку). С флешками может возникнуть в данном случае сложность: поскольку ОС Windows считает флешки removable-устройствами, то второй раздел на флешке под ОС подключить не удастся. Подробнее этот вопрос я рассмотрел в шапке UTmake, тут лишь уточню - для DOS/Linux два раздела на флешке - это обычные два раздела, и ограничений по работе с ними на уровне загрузки нет.
Возможность загрузки и работы ОС в EFI-режиме реализована в ОС Windows 8 и новее (8.1, 10, ...), а также с ограничениями - в ОС Windows 7x64 (для 7x86 эта возможность отсутствует - не реализована производителем).
Примечание: ограничения для Windows 7x64 связаны с тем, что в этой ОС еще не было цифровых подписей файлов, поэтому загрузка и работа EFI-версии 7x64 возможна лишь при условии отключения "Secure Boot" (которая занимается проверкой цифровой подписи).
Чтобы установить EFI-ОС, необходимо загружать WinPE только в EFI-режиме.
Под UEFIx32 (обычно используются на планшетах, реализуются только для 32-битных процессоров) - возможна EFI-загрузка исключительно х86-разрядных PE/ОС (запускается загрузчик bootia32.efi). Можно загрузить WinPE/ОС на базе 8-ки и новее.
Под UEFIx64 (используются практически на всех новых ПК и ноутбуках, 64-битный процессор) - возможна EFI-загрузка исключительно х64-разрядных PE/ОС (запускается загрузчик bootx64.efi). Можно загружать WinPE/ОС на базе 8-ки и новее (либо 7x64 с отключеным "Secure Boot").
Примечание: в UEFIx64 отсутствует поддержка x32, поэтому использование каких-либо x32-версий EFI-утилит полностью исключено. То же касается использования в UEFIx32 64-битовых версий. И, естественно, полностью исключено использование не-EFI версий загрузчиков и утилит.
Порядок загрузки в EFI-режиме и установки EFI ОС:
1. Загружается загрузчик (соответствующей разрядности), который находится по пути efi\boot\bootx64.efi (х64) или efi\boot\bootia32.efi (х32)
2. Загрузчик загружает своё меню BCD (файл efi\microsoft\boot\BCD).
Примечание: для WinPE-сборок, в которых совмещена возможность загрузки как в x64, так и в x32 режимах, часто применяют пропатченную версию bootia32.efi. В пропатченной версии изменено имя меню BCD на B32, что позволяет разделить менюшки по разрядности (BCD - меню для x64, и B32 - для x32-реализации UEFI). Применение патча именно для bootia32.efi допустимо, поскольку проверка цифровой подписи (Secure Boot) в x32-реализациях UEFI отсутствует (по крайней мере, пока не встречается).
3. Из меню загружается ядро (например, boot.wim), в котором должен быть EFI-загрузчик ядра для загрузки в EFI-режиме (как и в install.wim/esd, он находится по пути Windows\System32\Boot\winload.efi).
4. Только из WinPE, загруженного в EFI-режиме, возможно установить EFI-версию ОС. При этом в установочном архиве (install.wim/esd), обязательно должен присутствовать EFI-загрузчик ядра (Windows\System32\Boot\winload.efi), а разрядность ОС должна соответствовать реализации UEFI (x64 или x32). EFI-загрузчик ядра есть в Windows 7 x64 и в более новых 8/8.1/10.
Примечание: стоит учитывать ограничения на установку EFI ОС 7x64 (необходимо отключение Secure Boot, иначе установленная ОС не сможет загружаться).

Ограничения по использованию загрузочных файлов на различных носителях.

Предыстория: бывает, что при загрузке пересобранного копакта или заливке на флешку сборка перестает загружаться. Причем оригинал загружается, и заливка на другую флешку - тоже работает. Кажется, мистика какая-то... Оказывается - НЕТ.
Вся проблема кроется в том, что некоторые файлы, участвующие в загрузке, должны находиться в начале нашего накопителя, иначе при загрузке они просто "не находятся"!
Перечислю эти файлы: сами загрузчики; шрифты, используемые в меню; фоновые картинки; wim-ядра на базе ХР/2003; "костыли" для переходов.
Ограничение для FAT/NTFS/ExFAT раздела USB-HDD/UFD (флешки): перечисленные файлы должны находиться в пределах первых 32Гб раздела.
Ограничение для CDFS раздела (компакт-диски): в пределах 1Гб (точно не определял границу, но примерно так).
Ограничение для UDF раздела (компакт-диски): в пределах 2-4Гб (точно не определял границу, но примерно так). Загрузка wim-ядер на базе ХР/2003 из UDF-раздела не поддерживается.

HEX-правка распакованной версии bootmgr - МНОГО ПОЛНОРАЗМЕРНЫХ КАРТИНОК!

Не смотря на наличие таких инструментов, как BMplus или WBM CUSTOMIZER, иногда возникает необходимость подправить bootmgr ручками. Вот и попробую рассказать, как это делаю я.
Издеваться над bootmgr будем с помощью HEX-редактора Hiew (это один из самых навороченных НЕХ-редакторов). Если его у вас нет, но имеется под руками сборка 2k10 - не беда, этот редактор встроен в файловый менеджер FAR сборки. Где брать распакованный bootmgr.exe? Ну, если вы собрались редактировать, значит, уже имеется. :)
Запускаем в рабочей папке hiew.exe bootmgr.exe (или в FAR 2k10 становимся на файл bootmgr.exe и жмем Alt+F4). По F8 выбираем кодировку (для bootmgr это будет Unicode). Все, можно работать.

Для начала поищем, где скрывается ссылка на меню BCD. Жмем F7, набираем имя BCD.

Нам повезло - первая же найденная ссылка - как раз то, что нас интересует (в тексте еще встречается это имя, но там оно используется в подсказках). Для того, чтобы перейти из режима просмотра в режим правки, нажимаем F4 и выбираем HEX.

Теперь у нас будет две панели: левая с HEX-кодами и правая - обычная текстовая. Для начала правки F3, для перехода между панелями - Tab (кое-что легче вводить кодами, а кое-что - текстом). Попробуем изменить \boot\BCD на \2k10\B64.

Получилось? Если результат вас удовлетворил, нажимаем F9. Все, изменения внесены в bootmgr.exe, и теперь свое меню B64 он будет искать в папке \2k10.
Попробуем изменить путь к текстовому меню boot.ini. Переходим к началу файла (Ctrl+Home) и запускаем поиск (F7), вводим boot.ini. В результате поиска можно найти 2 результата (\BOOT.INI и \boot.ini). Уточню, что, по моим данным, bootmgr использует вторую ссылку, и, при каких условиях используется первая - я не знаю. Но - перестрахуемся, и будем править обе ссылки.

Тут возникает сложность: места, отведенного для ссылки (8 символов, ссылка должна заканчиваться кодом 00) - слишком мало, чтобы переделать ссылку на название в "своей" папке. Но... вопрос, в принципе, решаем. Для этого нужно вначале записать себе адреса, по которым находится первый символ ссылки "\". Для загрузчика 10-ки это 00.40.43.E0 (\BOOT.INI) и 00.40.44.44 (\boot.ini). Чтобы узнать этот адрес, можно курсором в правой панели перейти на первый символ, и адрес будет указан сверху справа (на скриншоте левее надписи Hiew).
Теперь нам нужно найти "свободное" место, где мы могли бы прописать "длинную" ссылку, к примеру, \2k10\GuestPE\Guest.ini. Сразу скажу, что для этого вполне можно пожертвовать ссылками на корейские/японские/китайские шрифты. Поскольку для европейских языков (в том числе и кириллицы), при загрузке используется единственный шрифт - wgl4_boot.ttf. Поэтому снова - к началу файла (Ctrl+Home), поиск (F7), ищем по значению .ttf .

Нашли? Теперь значения ja \jpn_boot.ttf ko \kor_boot.ttf zh-CN zh-CHS zh-Hans \chs_boot.ttf zh-TW zh-CHT zh-HK zh-Hant \cht_boot.ttf нужно "забить" нулями (в левой панели).

Подтверждаем изменение по F9. Всё, теперь у нас имеется место, куда можно вписать "длинные" пути. Что мы и сделаем (F3, вводим на освободившемся месте новые пути). Теперь по адресам 004056D0 и 00405700 (смотреть адрес нужно ПОСЛЕ подтверждения правки по F9!) у нас имеются новые ссылки.

Осталась одна мелочь - нужно заменить вызов "старых" записанных адресов (00.40.43.E0 и 00.40.44.44) на "новые" (00.40.56.D0 и 00.40.57.00). Для этого переходим к началу файла (Ctrl+Home), и по F4 выбираем декодирование файла. Теперь НЕХ-редактор показывает содержимое на Ассеблере. Производим поиск по F7 Hex-значений адреса. Уточню, что адреса в Ассемблере хранятся в обратном порядке, поэтому вместо 00.40.43.E0 ищем E0.43.40.00.

Нашли (справа видно, что идет указание на \BOOT.INI)? Замечательно. По F3 заменяем E0.43.40.00 на D0.56.40.00 (или 00.40.56.D0 в обратном порядке). Жмем F9 для подтверждения изменений - и убеждаемся, чт справа указание изменилось на новый "длинный" путь.

На всякий случай повторяем поиск E0.43.40.00 (чтобы убедиться, что других вызовов этого адреса нет... если есть - тогда заменяем ВСЕ E0.43.40.00 на
D0.56.40.00). В конкретном случае - вызов адреса с \BOOT.INI только один, поэтому и только одна замена. Аналогично ищем и заменяем 00.40.44.44 на 00.40.57.00 (в обратном порядке).

Кроме замены пути к текстовому меню, можно заменить путь в BCD (если в "штатном" месте расположения не получается вписать "длинный" путь). Поступаем так же - вписываем путь на освободившемся от "узкоглазых" шрифтов месте, производим поиск обращений к "старому" адресу и замену их на "новый". Еще раз напомню: нужно ПРОВЕРИТЬ и ЗАМЕНИТЬ ВСЕ обращения к "старому" адресу (а для BCD - это 5 мест!).
Кроме вышеописанного, рекомендуется заменить имя wgl4_boot.ttf на более короткое boot.ttf.

Это нужно, если предусматривается использование загрузчика на CDFS компакт-диске (под CDFS необходимо использовать имена в формате 8.3, и шрифт с именем wgl4_boot.ttf просто не будет найден). Самое простое решение - изменить в bootmgr \wgl4_boot.ttf на \boot.ttf, а в папку шрифтов поместить оригинальный wgl4_boot.ttf и его копию под именем boot.ttf. Тогда под CDFS будет использоваться boot.ttf, а для остальных ф/с - wgl4_boot.ttf.
Осталось подправить путь к папке шрифтов. Он находится чуть ниже указания wgl4_boot.ttf (boot.ttf), можно искать по \boot\fonts. Тут просто заменяем путь на желаемый (например, \2k10\fonts).

Последний "штрих" - правка вида BCD-меню. Но, это уже в тему WBM CUSTOMIZER, там собрано много интересных наработок. Я лишь уточню, что править нужно ресурс BOOTMGR.XSL (вытащить/заменить ресурс можно, например, с помощью Restorator или другой программы для работы с ресурсами исполняемых файлов). Желательно перед заменой "подогнать" размер BOOTMGR.XSL до 50956 байт (при изменении размера возможны проблемы при упаковке).
Может, кому-то так будет легче: сделал два загрузчика (от 8.1sp1 и 10). Собрал всё нужное в одном месте (заместо узкоглазых шрифтов) и заменил все переходы. Можно искать\заменять под любой проект без дополнительных правок, ищем по "EFI\CORE" и правим под свои пути. Вид меню не менял (ресурс BOOTMGR.XSL - оригинальный).
Новые пути: EFI\CORE\BCD, EFI\CORE\GUEST.INI, EFI\CORE\FONTS. Плюс подправлено имя wgl4_boot.ttf на boot.ttf.

Что такое натив-режим загрузки ядра, преимущества и недостатки.

При натив-загрузке (этот способ загрузки позаимствован из мира Linux), ядро состоит, как минимум, из двух частей. Первая часть - это натив-ядро, специально подготовленное минимальное ядро (без графической оболочки). После загрузки натив-ядра в нем отрабатывает натив-программа (native.exe, made in China), выполняющая скрипт, который производит поиск носителя (CD/DVD/HDD/USB-HDD/UFD) со сборкой и монтирует "полное" ядро (т.е., всё, что нужно для запуска графической оболочки и РЕ-окружения), либо отдельные необходимые части (теперь такое встречается редко).
Плюсы:
1. Быстрая загрузка на USB 1.x. Вместо обычных 5-10 мин на USB 1.2 - около 1 минуты.
2. Меньшее потребление памяти (для сборки Strelec - меньше на ~250Мб). Высчитать уменьшение потребления памяти при загрузке несложно - приблизительно оно равно разнице между основным и натив-ядром.
3. Пониженные требования к CPU (ядро Native Mode сборок на базе 7/8 может быть пропатчено для работы с CPU начиная с P4/Athlon), отключена проверка NX-бита.
Минусы:
1. Привязка к носителю (при его извлечении - PC "зависнет").
2. Более медленная работа ядра (поскольку всё загружается не из быстрого РАМ-диска, а c медленного носителя). На практике особых "тормозов" не ощущается.
3. Некорректно работает RunScanner (утилита для перенаправления программ на работу с реестром целевой ОС), перенаправления на реестр целевой ОС не происходит.
4. Для совместимости со старыми CPU отключена поддержка мультиядерности и РАЕ.
Совет: На современных PC лучше использовать обычный режим загрузки.
Конструкторские нюансы:
1. Поскольку натив-режим предназначен, прежде всего, для загрузки с минимальным потреблением памяти (старые ПК), то практические реализации имеются только для х86-ядер (ХР/2003/7/8).
2. Для минимизации размеров натив-ядра, в него включается минимальный набор драйверов контроллеров. Поэтому поддержка SCSI/Raid практически отсутствует (а в сборках на базе ХР/2003 - и поддержка SATA ограничена), а поддержка USB 3.0 имеется только в сборках на базе 8-ки.
3. Обязательным условием реализации натив-загрузки является использование imagex.exe и сопутствующих драйверов из комплекта Vista. Что может вызвать проблемы при использовании современных версий Dism.
4. Натив-режим можно реализовать для сборок на базе ХР/2003/7/8. Для РЕ на базе более новых ОС (8.1/10) реализация на данный момент невозможна (конфликт с новыми версиями Dism).
5. Для совмещения натив и обычной (РАМ-загрузки), применяют особенную упаковку основного ядра. Упаковка заключается в том, что wim-ядро состоит из нескольких индексов: первые соответствуют корневым папкам, а последний (загрузочный) - полному ядру. Причина в том, что при натив-загрузке нельзя смонтировать весь диск X:\, а обязательно монтировать по всем его корневым папкам. К примеру в 8х86 из 2k10, индекс "1" монтируется как x:\users, "2" - x:\ProgramData, "3" - "x:\program files", "4" - x:\sources, "5" - x:\windows. Ну, а "6" - это полное ядро, которое загружается при обычной РАМ-загрузке. Возможно, это удивит, но такая упаковка практически не увеличивает размер упакованного ядра (по сравнению с "одноиндексным"), поскольку wim-формат изначально приспособлен к мультииндексности с пересекающимися файлами.

Размер диска X:\ (используется RAM-диск MicroSoft).

Физическое ограничение для RAM-диска MicroSoft, используемого для создания диска X:\, составляет 160Мб (значение WinPECacheThreshold 0A0) для сборок на базе ХР/2003 и 1024Мб (WinPECacheThreshold 400) для 7-ки и выше. Большее значение можно установить (оно будет отображаться в свойствах X:\). Но реально при заполнении несжимаемыми данными (уточню - все внесенные данные на RAM-диск MicroSoft - сжимаются) более указанных размеров диск "переполняется" даже при достаточном количестве ОЗУ. Имхо, драйвер RAM-диска MicroSoft сделан очень рационально: даже если указать WinPECacheThreshold 400, то реальное потребление памяти при загрузке не увеличится, она будет потребляться только при заполнении диска (копировании туда данных/программ/драйверов). Причем (и это отличительная черта именно MicroSoft-вского драйвера!) при удалении добавленных данных задействованная под них память освобождается и возвращается системе. К примеру, ходовой ImDisk память в систему не возвращает, а Primo RAM disk возвращает, но не полностью.
Размер RAM диска устанавливается в реестре по пути [HKLM\System\ControlSet001\Services\FBWF], параметр WinPECacheThreshold)
Если значение = 400, то это означает 1024Мб, значение = 300 означает 768Мб, значение = 200 означает 512Мб, значение = 100 означает 256Мб. Если удалить вообще параметр WinPECacheThreshold, то размер RAM диска будет 32МБ (значение по-умолчанию).
Итог: под РЕ на базе 7-10 вполне можно указать WinPECacheThreshold 400 (можно даже 800, если больше - мало практической пользы), влияния на потребление памяти сборкой при запуске это не оказывает. Это значение нужно указать ДО загрузки (нужно править файл реестра в ядре), поскольку RAM-диск X:\ создается при запуске РЕ. Но, если памяти (ОЗУ) мало, то даже при незначительном заполнении данными X:\ туда нельзя будет записать что-либо (хотя циферку будет показывать "правильную" - мол, на X:\ места 1Гб). К примеру, на ПК с ОЗУ 1Гб при загрузке примерно 300Мб "отъест" само ядро, примерно 200-300 Мб занимает ОС в памяти плюс программный пакет (если он копируется на X:\) - ещё 200-300Мб. Т.е., под данные на RAM-диске остается очень мало, 100-200Мб. Если это понимать (что чудес не бывает, и нельзя при 1Гб ОЗУ сделать реальный размер RAM-диска больше свободной памяти - тот же 1Гб), то можно менять...
Примечание: часто пользователей удивляет такое - после запуска WinPE размер X:\, к примеру, 256Мб. Хотя ядро (все файлы на X:\) может занимать значительно больше! Объясню этот момент. При загрузке WinPE wim-ядро (в упакованном виде) загружается в память (занимая количество ОЗУ, соответствующее wim-архиву) и монтируется как диск X:\. Таким образом, файлы ядра во время работы... работают из загруженного в память wim-архива. Но для работы РЕ необходимо изменять некоторые файлы (как минимум, файлы реестра), поэтому задействуется фильтр FBWF, позволяющий записывать изменения на диске X:\ в память. Это приводит к доступности работы диска X:\ на запись. И именно значение указанной для FBWF памяти определяет отображаемое значение размера X:\. При заполнении данными (копировании файлов на X:\), либо при изменении файлов wim-архива (и даже их удалении - это ведь тоже изменение), происходит уменьшение свободного места на X:\. При этом скопированные на X:\ данные, по возможности, сжимаются (динамическое сжатие). Заполнение X:\ происходит, если заканчивается свободная память, либо для сжатых данных превышено значение WinPECacheThreshold. И тут возможен другой "странный" факт: вроде бы место есть, но при копировании - ошибка (места нет). Никаких чудес... данные должны где-то храниться, и если памяти не хватает - ничего тут не поделаешь.

Как перепаковать (упаковать) wim-ядро.

Такой вопрос часто возникает у начинающих репакеров (хочется что-то изменить в сборке). В таких случаях MS рекомендует использовать Dism, что не всегда удобно (а порой и невозможно - например, под ХР/2003). Есть и другие варианты решения - использовать GUI (например, GimageX) или даже 7-zip (крайние версии отлично справляются с изменением wim-архива).
Положа руку на печень , признаюсь: лучший вариант перепаковки - это упаковка "с нуля". Она позволит добиться минимального размера архива. И для такой упаковки вполне достаточно единственного файла - imagex.exe от Vista (такой вариант работоспособен под всей линейкой ОС, начиная от ХР и заканчивая 10-й). Его можно взять, например, из сборки 2k10 (в папке 2k10\WinPE\Repack.Wim).
Распаковываем нужное ядро в рабочую папку (индекс "1" для одноиндексного ядра, т.е., в рабочей папке должен быть подкаталог 1 с содержимым диска X:\). В ту же папку закидываем imagex.exe и бАнТиК такого содержаниягде W7x64PE.WIM - имя нового архива, а W7x64PE - его метка (в большинстве случаев может быть произвольной).
Правим в распакованном ядре необходимое, и упаковываем его батником. Для максимального сжатия после упаковки ядра можно пройтись утилитой 78RePack, режим UltraPack - это позволит дополнительно уменьшить ядро на пару мегабайт.
Возможно, некоторым понравится утилитка PEpackX10, позволяющая комплексно перепаковать несколько ядер с максимально возможным сжатием (совместимым с загрузкой).
Для многоиндексных ядер необходимо знать, для чего предназначены индексы, чтобы правильно подправить сборку. Поэтому лучше использовать авторские скрипты для перепаковки (например, в 2k10 это скрипт 2k10\WinPE\Repack.Wim\repack.cmd).

Как подправить реестр в готовом WinPE...

Иногда возникает желание подправить параметры реестра в "чужой" сборке (поскольку после загрузки это делать не всегда получается - некоторые значения реестра работают при запуске до перезагрузки... т.е., для WinPE - всегда). В общем и целом, это не сложно. Нам понадобится редактор реестра. Лично я рекомендую RegWorkshop (имеется в 2k10), по удобству использования - это один из лучших редакторов. Если кто сомневается - попробуйте поискать часто повторяющееся значение в regedit и RegWorkshop. И увидите разницу. А уж возможность замены (как всего найденного, так и отмеченных значений) на новое - большого стоит.
Итак, приступим. Для начала необходимо распаковать ядро. Проще всего это сделать с помощью крайних версий 7zip (15.XX). Реестр - это набор файлов в папке Windows\System32\config. Причем отдельные кусты соответствуют отдельным файлам. В частности, куст HKCU - это файл DEFAULT, HKLM\Software - файл SOFTWARE, HKLM\System - файл SYSTEM. Остальные кусты в WinPE обычно пустые, поэтому на них можно не обращать внимание.
Для того, чтобы подправить (добавить/удалить) значение из куста реестра, запускаем RegWorkshop, "Файл\Загрузить куст". Выбираем первый файл, зададут запрос - название раздела и позволят выбрать, куда монтировать (дефолтное значение HKLM оптимальнее всего). Название раздела можно выбрать попроще (я обычно использую 0, 1, 2 или 0d, 0w, 0s для файлов DEFAULT/SOFTWARE/SYSTEM соответственно - чтобы смонтированные кусты были вместе и легко идентифицировались). После монтирования всех (или только нужных) кустов можно приступать к правке. Если использовались названия 0d, 0w, 0s, тогда нужно учитывать соответствия:
куст HKCU (WinPE) -> у нас теперь подключен как HKLM\0d
куст HKLM\Software (WinPE) -> HKLM\0w
куст HKLM\System (WinPE) -> HKLM\0s
Таким образом, если правка производится с помощью рег-файлов, в них обязательно нужно предварительно исправить (заменить) все пути к обрабатываемому ключу.
Например, имеется файл реестра для выбора размера диска X:\ при загрузке (00000100=256Мб)Заменяем HKEY_LOCAL_MACHINE\System на HKEY_LOCAL_MACHINE\0s, получим:Этот рег-файл можно применить к смонтированному как HKLM\0s файлу куста реестра SYSTEM.
Какие твики можно применить для реестра? Разные. И довольно часто они отличаются от обычных твиков. Например, куста HKLM\SYSTEM\CurrentControlSet не существует, он формируется на основе куста HKLM\System\ControlSet001, поэтому изменять нужно именно там. Теме твиков для WinPE, думаю, посвящу отдельный раздел справки.
Будем считать, что мы применили нужные изменения. Самый простой путь - выгрузить кусты реестра. Для этого становимся курсором на нужный куст, и в меню RegWorkshop - "Файл/Выгрузить куст".
Но!!! Я рекомендую сделать иначе. Все дело в том, что в кусте сохраняется разный мусор от правок, и если просто выгрузить куст, то мусор останется на месте, а сам куст может быть фрагментирован. Поэтому ПЕРЕД выгрузкой куста лучше сделать его копию (ПКМ на кусте, экспортировать). В открывшемся окне выбираем имя, и - ОБЯЗАТЕЛЬНО! - тип файла - "Файлы кустов реестра". После этого можно спокойно выгружать куст. В результате такой операции мы получим 2 файла кустов реестра: первый - который мы монтировали (с мусором и фрагментацией), и второй - очищенный от мусора и дефрагментированный (с выбранным нами названием и расширением *.reg). Для возврата в сборку рекомендую использовать именно второй файл (переименовав его на имя оригинального куста). Такой файл меньше по размеру и лучше упакуется в wim-архив.
Примечание: таким же способом можно дефрагментировать и очистить от мусора кусты реестра обычной "лежачей" ОС (сделав это из-под WinPE). Так же можно поступить и с BCD-меню (возможно, вы удивитесь - но это ТОЖЕ КУСТ РЕЕСТРА). Если какой-либо из разделов куста не поддается редактированию - вполне вероятно, что просто заблокированы права доступа к нему. Чтобы разблокировать их, в RegWorkshop становимся на раздел, ПКМ - "Разрешения", и добавляем права для текущего пользователя. После этого можно будет редактировать.
Осталось только вернуть подправленные кусты в распакованное ядро и заново его собрать. Ну, это я уже описывал.
Примечание: после редактирования кустов реестра часто создаются различные файлы с расширением *.regtrans-ms и *.LOG*. Эти файлы не нужны. Поэтому перед сборкой ядра рекомендую проверить содержимое папки Windows\System32\config, если в ней имеются такие файлы - их спокойно можно удалить (по-сути, в этой папке должны остаться только файлы кустов реестра БЕЗ РАСШИРЕНИЯ, ну и подкаталоги - если имеются).

Некоторые из твиков реестра для WinPE.

; Отключить автозапуск дисков при подключении (всплывающее окно с предложением открыть диск)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoDriveTypeAutoRun"=dword:000000ff
; Команды в "Пуск\Выполнить"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU]
"a"="regedit\\1"
"b"="cmd\\1"
"c"="ping 192.168.1.1\\1"
"MRUList"="acb"
; Разрешение 1024х768х32 60Гц
[HKEY_LOCAL_MACHINE\System\ControlSet001\Services\VgaSave\Device0]
"InstalledDisplayDrivers"=hex(7):76,00,67,00,61,00,00,00,66,00,72,00,61,00,6d,\
00,65,00,62,00,75,00,66,00,00,00,76,00,67,00,61,00,32,00,35,00,36,00,00,00,\
76,00,67,00,61,00,36,00,34,00,6b,00,00,00,00,00
"VgaCompatible"=dword:00000001
"DefaultSettings.BitsPerPel"=dword:00000020
"DefaultSettings.XResolution"=dword:00000400
"DefaultSettings.YResolution"=dword:00000300
"DefaultSettings.VRefresh"=dword:0000003c
; VGA-Accelerator (ускорение прорисовки c VGA-драйвером)
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\VgaSave\Device0]
"Acceleration.Level"=dword:00000005
; Решение для корректного отображения кириллицы в программах
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontMapper]
"ARIAL"=dword:000000cc
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
"Arial,0"="Arial,204"
"Comic Sans MS,0"="Comic Sans MS,204"
"Courier,0"="Courier New,204"
"Courier,204"="Courier New,204"
"MS Sans Serif,0"="MS Sans Serif,204"
"Tahoma,0"="Tahoma,204"
"Times New Roman,0"="Times New Roman,204"
"Verdana,0"="Verdana,204"
; Отключить вывод сообщений об ошибках (например, при обращении к "пустому" CardReader-у)
; Включить -> "ErrorMode"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Windows]
"ErrorMode"=dword:00000002
; Панель быстрого доступа дисков
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\comdlg32\PlacesBar]
"Place0"="B:\\"
"Place1"="C:\\"
"Place2"="D:\\"
"Place3"="X:\\"
"Place4"="Y:\\"
; Переключение раскладки клавиатуры по Ctrl+Shist
[HKEY_CURRENT_USER\Keyboard Layout\Toggle]
"Hotkey"="2"
"Language Hotkey"="2"
"Layout Hotkey"="1"
; Включить NumLock при загрузке ("InitialKeyboardIndicators"="0" - отключить)
[HKEY_CURRENT_USER\Control Panel\Keyboard]
"InitialKeyboardIndicators"="2"
; Отключить переключение на арабские шрифты
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack]
; Черный цвет фона
[HKEY_CURRENT_USER\Control Panel\Colors]
"Background"="0 0 0"
; Размер диска X:\ (0x100=256Mb, 0x200=512Mb, 0x400=1024Mb, 0x800-2048Mb
; Под ХР/2003 максимальный реальный размер 160Мб, для 7/8/ - 1024Мб
; Рекомендую для ХР/2003 -> 0x200, для 7/8/... -> 0x800
[HKEY_LOCAL_MACHINE\0\ControlSet001\Services\FBWF]
"WinPECacheThreshold"=dword:00000200
; Автоматически упорядочивать значки на раб.столе
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags\1\Desktop]
"FFlags"=dword:00000225
"Sort"=dword:00000001
;Отключить значки в трее
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"HideSCAHealth"=dword:00000001 Отключить значок "Центр поддержи"
"HideSCAVolume"=dword:00000001 Отключить значок "Громкость"
"HideSCAPower"=dword:00000001 Отключить значок "Батарея"
"HideSCANetwork"=dword:00000001 Отключить значок сети
"HideClock"=dword:00000001 Отключить часы
"NoTrayItemsDisplay"=dword:00000001 Отключить все,кроме часов и языковой панели
; Отключить перевод времени на летнее
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\TimeZoneInformation]
"DisableAutoDaylightTimeSet"=dword:00000001
; Не напоминать о нехватке места на дисках
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoLowDiskSpaceChecks"=dword:00000001
; Отключить автозапуск дисков при подключении (autorun.inf)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoDriveAutoRun"=dword:00000000
; Отображать встроенные значки DLL
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\dllfile\DefaultIcon]
@=hex(2):25,00,31,00,00,00
; Выключить резервирование памяти
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Memory Management\PrefetchParameters]
"EnablePrefetcher"=dword:00000000
; Дополнительные значки в "Мой компьютер"
; Беспроводные сети (управление)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{1FA9085F-25A2-489B-85D4-86326EEDCD87}]
; Компьютер (диспетчер устройств)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{20D04FE0-3AEA-1069-A2D8-08002B30309D}]
; Все элементы панели управления
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{21EC2020-3AEA-1069-A2DD-08002B30309D}]
; Выполнить
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{2559A1F3-21D7-11D4-BDAF-00C04F60B9F0}]
; Корзина
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{645FF040-5081-101B-9F08-00AA002F954E}]
; Параметры папок
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{6DFD7C5C-2451-11d3-A299-00C04F8EF6AF}]
; Центр управления сетями
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{8E908FC9-BECC-40f6-915B-F4CA0E70D03D}]
; Сетевые подключения
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{992CFFA0-F557-101A-88EC-00DD010CCC48}]
; Система
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{BB06C0E4-D293-4f75-8A90-CB05B6477EEE}]
; Экран
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{C555438B-3C23-4769-A71F-B6D3D9B6053A}]
; Администрирование
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{D20EA4E1-3957-11d2-A40B-0C5020524153}]
; Использовать корзину при удалении файлов
; dword:00000000 - удалять в корзину (default), dword:00000001 - не использовать корзину
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoRecycleFiles"=-
; Настройка меню по нажатию ПКМ
[HKEY_CLASSES_ROOT\Directory\Background\shell\Task Manager]
@="Диспетчер задач"
"Icon"="taskmgr.exe"
[HKEY_CLASSES_ROOT\Directory\Background\shell\Task Manager\command]
@="taskmgr"
[HKEY_CLASSES_ROOT\Directory\Background\shell\System Properties]
@="Свойства системы"
"Icon"="imageres.dll,-149"
[HKEY_CLASSES_ROOT\Directory\Background\shell\System Properties\command]
@="control sysdm.cpl"
[HKEY_CLASSES_ROOT\Directory\Background\shell\Folder Options]
@="Свойства папки"
"Icon"="imageres.dll,-166"
[HKEY_CLASSES_ROOT\Directory\Background\shell\Folder Options\command]
@="control folders"

Результаты тестирования бэкапперов (из сборки 2k10)

Подробнее можно почитать в теме Программы для резервного копирования диска/ОС (Backup, образ)
Провел довольно таки масштабное тестирование бекапперов, собранных в 2k10. В качестве исходника для создания бекапа использовалась моя рабочая ОС Windows 7, установленная на дешевеньком SSD Kingston 60Gb. На диске занято примерно 32Гб, файлы подкачки/гибернации отсутствуют. Архив создавался на обычный (недавно отформатированный) HDD Samsung 500Gb. Процессор Celeron G1820 (2.7GHz, двухядерный, без HT). Тестирование производилось под WinPE 8х86 (2k10), свободной памяти в системе около 3Gb. Перед каждым запуском бекаппера РЕ перезагружалась, созданные ранее бекапы удалялись. Также, для оценки перехода на х64, создал 2 бекапа под 8х64 (2k10), свободная память 15Gb - DriveSnapShot64 и ShadowProtect64.
Время (мин.сек) / размер архива (Гб) - Название программы (версия) Вариант сжатия
==============================================================
03.40 / 18.3 - Acronis TIH 2014 6673 std
03.45 / 18.8 - Acronis TIEES 9.7 std
05.19 / 19.1 - Active@ DiskImage 7.04 std
05.20 / 19.7 - TeraByte Image 2.97c SpeedA
05.30 / 18.9 - ShadowProtect 5.2.4 std
05.32 / 18.1 - DriveSnapShot 3.9.2015 ===
05.33 / 20.2 - Paragon12 10.1.21.471 fast
05.46 / 18.1 - DriveSnapShot64 3.9.2015 ===
05.54 / 18.2 - ShadowProtect64 5.2.4 max
06.14 / 19.4 - HDClone 5.1.4 quick
06.40 / 19.2 - TeraByte Image 2.97c SpeedB
06.42 / 18.2 - ShadowProtect 5.2.4 max
07.26 / 19.4 - AomeiBackupper 3.1 std
08.14 / 17.2 - Active@ DiskImage 7.04 max
12.10 / 17.7 - AomeiBackupper 3.1 max
12.15 / 17.1 - TeraByte Image 2.97c SizeA
12.18 / 19.9 - Eassos SysRestore 2.01 fast
12.31 / 17.1 - R-Drive 6.0.6007 std
21.00 / 20.1 - Ghost 12.0.0.8006 fast
21.40 / 20.3 - Ghost 8.3.0.1331 fast
22.30 / 16.6 - Acronis TIH 2014 6673 max
23.20 / 16.6 - Acronis TIEES 9.7 max
26.30 / 16.8 - TeraByte Image 2.97c SizeF
28.50 / 17.5 - Ghost 8.3.0.1331 max
39.46 / 17.2 - HDClone 5.1.4 std
41.00 / 17.1 - DriveCloner 6.0 std
48.06 / 16.7 - DriveCloner 6.0 max

Что такое 'костыли' и зачем они нужны...

Часто бывает, что конкретный загрузчик (например, bootmgr) не умеет загружать желаемое (например, другой bootmgr, или образ флоппика/компакта). Но при этом, есть возможность загрузить сторонний загрузчик, который это умеет. В качестве стороннего загрузчика могут выступать, например, GRLDR /Grub4Dos/, Wee (базируется на урезанной версии Grub4Dos), Grub2, XorBoot. Если такой загрузчик позволяет "прозрачно" (т.е., без отображения собственного меню - сразу запускается желаемое) загрузить то, что нам нужно, то его называют "костылем". В зависимости от задач "костыли" могут быть разными.
Примечание: очень важна поддержка "костылем" различных файловых систем. Например, для Windows-загрузчиков актуальна поддержка FAT(32)/NTFS (обычно применяются на HDD), ExFAT (новая ф/с, разработана для флеш-накопителей, является развитием FAT32), CDFS/UDF (файловые системы компакт-дисков CD/DVD).
1. Костыль на базе GRLDR /Grub4Dos/. Плюсы: может загружать практически все, есть развитая система "программирования" (т.е., возможно скомбинировать несколько действий), поддерживает все необходимые файловые системы, меню может быть интегрировано в сам загрузчик, обширная поддержка загрузки образов. Минусы: довольно большой размер, длительный запуск, неотключаемая индикация процесса запуска.
2. Костыль на базе GRUB2. Довольно перспективный загрузчик (в связи с поддержкой EFI, имеется соответствующая версия). По возможностям немного уступает Grub4Dos. Плюсы: поддержка EFI, есть развитая система "программирования" (т.е., возможно скомбинировать несколько действий), поддерживает все необходимые файловые системы. Минусы: неинтегрируемое меню, большой размер, медлительность, неотключаемая индикация процесса.
3. Костыль на базе Wee (этот загрузчик имеется в BootIce). Компактная версия Grub4Dos с сильно урезанными возможностями. Изначально сделан как MBR-загрузочная запись с интегрированным меню, но ничто не мешает использовать его под наши задачи. Плюсы: миниатюрный, встроенное меню, работает быстро и незаметно. Минусы: поддерживает только FAT(32)/NTFS, нет поддержки загрузки образов.
4. Костыль на базе XorBoot. Загрузчик от создателя BootIce, предназначен для установки в MBR с интегрированным меню. Плюсы: поддерживает все актуальные ф/с (последние версии загрузчика), встроенное меню, имеется поддержка загрузки образов (хотя и значительно хуже Grub4Dos), работает быстро и незаметно. Минусы: все версии - беты (можно рекомендовать к использованию версии 0.61, 0.68, 0.73), запуск с поиском работает только на ф/с FAT(32)/NTFS/ExFAT (на CDFS/UDF работает только прямой запуск).
5. Костыль на базе Syslinux/Isolinux. Загрузчик очень хорош по загружаемости (особенно версии 3.86 и 4.07), в основном используется для загрузки Linux-систем. Плюсы: широкий спектр загрузки, загрузка образов, неплохая скорость загрузки. Минусы: не поддерживает ExFAT (а NTFS поддерживается только с версии 4.07), внешнее меню, неотключаемая индикация процесса загрузки, невозможно загрузить из GRLDR или Bootmgr (без костыля).

По поводу других вариантов - если вам известен какой - пишите. Как видим, идеальных "костылей" пока нет. :)

Варианты CMD-скрипта для поиска (на всех дисках) и запуска программы (или другого скрипта)

0. Обычно для поиска используется скрипт такого вида, на базе команды If existНюанс (в применении к WinPE) заключается в том, что поиск с использованием If exist под WinPE может "стопориться" на поврежденных разделах, или на отсутствующих носителях в картридере/CD/DVD. В таком случае WinPE выдаст соответствующее предупреждение, которое нежелательно (особенно если оно будет повторяться несколько раз). Избежать подобной ситуации можно разными способами:
1. Использовать команду Dir для проверки "валидности" файла на разделе (мое ноу-хау). Эта команда работает в самых урезанных ОС, и при ошибке не вызывает консольное окно. Вариант скрипта с её использованием:MyName - переменная, указывающая на файл, который нужно найти и запустить. Как работает скрипт: перебор всех буковок от C до Z. Для каждой с помощью Dir проверяется наличие файла. Если он найден (сработает &&) - тогда запуск нашего файла и выход из перебора. Если не найден, тогда вывод сообщения (УВЫ...) и выход.
2. В принципе, можно использовать и If exist, если ПРЕДВАРИТЕЛЬНО отключить вывод окна сообщения об ошибке. За это отвечает значение ErrorMode ключа реестра HKLM\System\CurrentControlSet\Control\Windows, "2" - отключить, "0" - обычное поведение. Скрипт тогда будет выглядеть так:Т.е., сначала отключаем вывод сообщений, потом поиск, и в конце - включение вывода.
Примечание: на очень сильно урезанных WinPE значение ErrorMode может игнорироваться. Так что желательно проверить поведение под конкретной сборкой.
3. Как вариант - можно использовать сторонние утилиты для поиска. Правда, проверять их "умение" не выводить окно ошибки под WinPE нужно индивидуально.
Какой вариант использовать? Для использования под обычной ОС - можно и 0. Под WinPE в обычных батниках - лучше всего вариант 1. Вариант 2. подойдет для реализации на интерпретаторах (к примеру, скрипты PECMD).

Два раздела на флешке - зачем это нужно и реализация такой возможности с помощью UTmake

Предистория: для гарантированной загрузки в EFI-режиме носитель должен быть отформатирован в FAT/FAT32, поскольку EFI производит поиск загрузчика по пути efi\boot\bootx64.efi (или efi\boot\bootia32.efi для 32-битовой реализации EFI - она встречается на х86-планшетах) только в FAT/FAT32-разделах. И тут появляется противоречивое требование: FAT32-разделы не поддерживают файлы размером более 4Гб (4 294 967 295 байт или 2 в степени 32-1), а большинство дистрибов (install.wim) превышают его. Т.е., обязательно использовать NTFS. А, с другой стороны - обязателен FAT32, иначе EFI не загрузит этот носитель. Ради справедливости отмечу, что в последних реализациях UEFI некоторые производители (в частности, Asus) начали добавлять в UEFI драйвер NTFS, т.е., на таких ПК возможна EFI-загрузка из NTFS-носителя... но тут без гарантий.
Как поступить? Если бы мы имели дело с HDD, вывод простой: использовать два раздела. Один - FAT32 с EFI-загрузчиком. Другой - NTFS с дистрибутивами. Но тут мы наталкивается на другое ограничение, уже Windows: эта ОС "не знает", что Removable-накопители (а к ним относится и флешка!) могут иметь несколько разделов. И поэтому она отображает только один раздел (первый указанный в MBR). Для решения этой проблемы есть, как минимум, два пути.
Первый из них - кардинальное решение. Заключается в том, чтобы найти (например, тут или тут... или даже у китайцев) и использовать утилиту для "прошивки" флешки. Ведь вся хитрость в том, что за идентификацию накопителя (Removable) отвечает один бит в её прошивке или чипе-контроллере. И в некоторых утилитах предусмотрено "превращение" флешки в USB-HDD. После такой операции Золушка флешка будет распознаваться Windows как HDD со всеми вытекающими. Кстати, сейчас это становится очень актуально: всё больше появляется флешек 64/128Гб, на которых FAT32 использовать почти невозможно (т.е., можно, но через ж...). Для таких флешек приходится использовать NTFS либо ExFat (последняя - это вариация FAT32 с поддержкой для больших файлов... но, увы, эта файловая система очень слабо поддержана загрузчиками). Ограничение первого варианта - это потеря гарантии, возможное повреждение флешки, и т.п.. Т.е., сама операция несложная, но некоторая подготовка нужна: определить контроллер флешки и флеш-память (помогут утилиты ChipEasy и/или GetFlashInfo), найти подходящую программу и разобраться с настройками...
Другой путь - чисто программное решение. Всё дело в том, что для DOS/Bios/EFI правильно отформатированная (т.е., многораздельная) флешка и USB-HDD - это одно и то же. Т.е., при EFI-загрузке из такой флешки достаточно, чтобы на ней был FAT32-раздел с EFI-загрузчиком. Т.е., можно (нужно!) разделить сборку на два раздела: первый - с NTFS (будет доступен под Windows), и второй, загрузочный (обязательно первичный/активный) - под FAT32. Методика подготовки такой флешки: используем менеджер дисков (например, удобно это сделать в Paragon HDM) для разбивки флешки на разделы: первый - под NTFS, второй - под FAT32. Размер второго определяем, исходя из размера загрузочных файлов, которые не будут нужны после загрузки ОС/WinPE. В применении к нашим реалиям это будут загрузчики, их окружение и wim-ядро. Определяем с некоторым запасом этот размер, и получим размер первого раздела как разницу между полной емкостью флешки и размером второго раздела. После разбивки ОС присвоит буковку первому разделу, а второй будет недоступен... но ничего страшного. Теперь используем утилиту BootICE. Выбираем в ней свой накопитель, нажимаем "Parts Manage". В управлении раздела выбираем второй раздел, кнопка "Unhide". Всё, теперь первый раздел станет невидимым, но мы получим доступ ко второму разделу. На этот раздел мы копируем необходимое (загрузчики и прочее). Если нужно, чтобы флешка была DOS-загрузочной, подключаем свой загрузчик. После выполнения всех операций повторяем манипуляции в BootICE - "Unhide" для первого раздела. Теперь первый раздел будет всегда у нас под руками в ОС/РЕ, а второй будет содержать загрузочные файлы, и из него будет производиться загрузка.
Ещё один вариант реализации - это помещение на второй (скрытый) раздел только файлов, необходимых для EFI-загрузки. В частности, это папка EFI и загрузчики bootmgr.efi и bootm32.efi (для х64 и х32 соответственно). Но при использовании варианта загрузки от MicroSoft придётся вручную в EFI BCD-меню (efi\microsoft\boot\BCD) указывать путь к ядрам/шрифтам/boot.sdi на первом разделе КОНКРЕТНОГО накопителя (т.е., эту операцию не автоматизируешь). Более простой вариант - использовать на втором разделе grub2.efi, в котором есть возможность подключения драйвера NTFS/ExFAT и последующего поиска и запуска EFI-загрузчика от MicroSoft на NTFS/ExFAT разделе (т.е., первом). Тогда значительно упрощается работа со вторым разделом (по-сути, нам нужно только один раз сконфигурировать второй раздел). Как вариант, можно использовать мою заготовку для 2k10. Нужно только подправить путь к файлу-маркеру (поиск производится именно по нему, чтобы исключить ложный переход к папке EFI с ОС пользователя). Путь к маркеру прописан в efi\boot\grub.cfg:
search --set=root -f /2k10/winpe/w8x64pe.wim
В таком варианте EFI-загрузка будет происходить следующим образом: UEFI -> Grub2.efi -> Загрузка драйвера NTFS/ExFAT -> Поиск файла /2k10/winpe/w8x64pe.wim -> Загрузка из EFI-папки в корне с файлом /2k10/winpe/w8x64pe.wim (т.е., загрузка EFI-меню MicroSoft). Что хорошо в данном варианте - так это то, что Grub2.efi полностью сертифицирован под UEFI. Более того, сам UEFI - это и есть оболочка на базе Grub2. Кроме того, Grub2.efi позволяет загружать не только загрузчик от мелко-мягких, но и многие другие. Но это уже отдельная история.
В UTmake имеется возможность реализации последнего варианта при переразбивке флешки. Если для флешки выбрана файловая система NTFS/ExFAT, то станет доступным создание второго раздела... Также, при наличии sfx-архива (файл Flash2Ptn.exe в папке Utilites - это заготовка для EFI-загрузки) с набором необходимых для загрузки файлов производится расчёт необходимого размера этого раздела (чуть больше размера файлов) - режим "Autosize". После запуска переразбивки на флешке создаются первый раздел (ёмкость флешки минус резерв для второго раздела) и второй. После этого второй раздел временно устанавливается видимым и на него копируется содержимое Flash2Ptn.exe. После чего видимым вновь назначается первый (основной) раздел.
Также вручную можно реализовать второй вариант - разместить все загрузочные файлы на скрытом разделе. Инструментом для этого служит кнопка обмена разделов на флешке ("P2" - "B") и прямые руки пользователя.
При обычном форматировании (как средствами утилиты, так и средствами ОС) второй раздел не затрагивается.

Редактирование BCD-меню загрузчика bootmgr

Познавательная статья по загрузке и правке BCD, очень рекомендую прочитать.
Предыстория. В версиях загрузчика NTLDR для 2000/ХР/2003 загрузочное меню было текстовым, и с его правкой ни у кого проблем не возникало. Но, начиная с Vista (с переходом на загрузчик bootmgr) все изменилось. Меню стало представлять собой не текстовый файл, а... куст реестра! Причем с довольно сложной и развитой структурой. И практически единственным инструментом для его правки стала консольная утилита bcdedit.exe. А как же имеющиеся программы для правки BCD, спросите вы? Все очень просто - все эти программы - только лишь GUI-оболочки, позволяющие удобно использовать все ту же bcdedit.
Кратенько попробую охарактеризовать известные мне BCD-редакторы:
1. BCD edit из программы BootICE. Плюсы: работает под всеми ходовыми ОС и WinPE, два режима редактирования (профессиональный и облегченный). Минусы - неверные названия некоторых ключей (что сбивает с толку после bcdedit), прочие мелкие ошибки.
2. EasyBCD - самый известный в среде обычных пользователей редактор. Благодаря ему меня не раз уверяли, что bootmgr без проблем умеет загружать образы. Но - это не так. Итак, плюсы: довольно простой и симпатичный интерфейс, возможность задействовать "костыли" на базе NeoGrub (разновидность Grub4Dos) для загрузки образов, мультиязычность. Минусы: требуется поддержка NetFrameWork, плохо подходит для серьезного "ковыряния" в меню.
3. Visual BCD Editor - довольно старая программа, до сих пор не добравшаяся до релиза. Тем не менее, довольно удобна в качестве "профессионального" редактора. Минусы - требуется поддержка NetFrameWork, невозможна работа в ОС/РЕ ниже Vista.
4. BCDtool (китайская утилитка, русифицирована мною). Её можно найти в 2k10 (2k10\Programs-2k10\BootRecovery\BcdTool) или в шапке темы BMplus. Небольшой, но очень интересный и "правильный" инструмент, классический GUI для bcdedit. Плюсы: не требует установки и поддержки NetFrameWork; работает под всеми ходовыми ОС и WinPE (bcdedit от 8.1 "вшит" мною); имеется возможность увидеть все разделы (включая скрытые из меню), можно "подсмотреть" команды bcdedit (для этого идем в "Настройки"). Недостаток, имхо, только один - нет возможности простой сортировки пунктов меню и назначения пункта загрузки по-умолчанию. Поэтому результат работы BCDtool я обычно "шлифую" под другими редакторами (сортирую, назначаю дефолтный пункт).
5. Boot Builder by AEK (Yahoo000) (автор нескольких WinPE). Программу можно найти в 2k10 (2k10\Programs-2k10\BootRecovery\BootBuilder). Плюсы: интересный вариант отображения информации (в текстовом виде) и правки (тоже можно подсмотреть команды bcdedit). Недостатки: под ОС "норовит" записать изменения в меню загрузки ОС (а не в то, что правится), посему может "испортить" загрузку ОС.
6. Так же, к редакторам можно отнести программы с довольно скромными возможностями по редактированию меню (в основном, они предназначены для восстановления загрузки): BellaVista и Active@ BCD Editor.
Ну, с прелюдией мы закончили. Перейдем к практике. Сразу скажу, я буду описывать правку меню с помощью BCDtool.
Для того, чтобы изменить наше меню, запускаем программу. По-умолчанию она загрузит системное меню (C:\Boot\BCD). Нам нужно выбрать "своего" пациента - "Меню\Открыть". Я издевался над меню из "Мультизагрузочного 2k10".

В левой панели становимся на "Диспетчер загрузки" и смотрим справа, что тут наворочено. Собственно, тут находится все наше загрузочное меню (если быть точнее, то это хранилище BCD - Store). Слева - параметр, справа - его значение. По порядку:
идентификатор={bootmgr} - как будто BCD-меню может кто-то, кроме bootmgr использовать. :)
description=Windows Boot Manager - описание, что это таки "бут манагер".
inherit={globalsettings} - внедренные параметры из записи в хранилище {globalsettings}. Очень интересный пункт, который многие сборщики игнорируют - А ЗРЯ!!! Суть в следующем: если у нас в меню имеется запуск нескольких WinPE, то МНОГИЕ параметры у них идентичные. Эти идентичные параметры можно (и даже НУЖНО!) вынести в {globalsettings}. Тогда для каждого пункта их прописывать не нужно, достаточно указать inherit={globalsettings} и они будут использованы из глобального списка. А уж, если один из параметров не должен соответствовать глобальным установкам, тогда указываем только его и inherit={globalsettings} - тогда этот параметр будет использован вкупе с остальными из {globalsettings} (т.е., указанный в своем разделе имеет высший приоритет).
default={default} - тут указано, что по-умолчанию будет загружаться запись {default}. Правда, на самом деле {default} - это псевдоним настоящего идентификатора (что-то вроде {24809d60-d80b-11e2-98a1-50e54938a1e5}). Т.е., при назначении любого пункта по-умолчанию "добряга" bcdedit заменяет его отображаемый идентификатор на {default}. Сравните результат выполнения ("путь\...\BCD" - путь к меню)Ключ /v как раз указывает bcdedit не подменять идентификаторы псевдонимами.
Псевдоним - это как табличка "Лидер" на первой машине в гонке, скрывающая её номер. Но табличку легко перевесить, если "лидер" изменится.
resumeobject={13d539a6-31de-11e0-b30a-89ba2320bc47} - идентификатор для загрузки после спящего режима (для WinPE-сборок не актуально)
displayorder={6df7143c-6c07-11e4-932a-1078d226adbb} {16d3d9a3-30ec-11e3-aa78-005056c00008}....{465026bc-d80c-11e2-98a1-50e54938a1e5} - а это наш список главного меню (перечисление идентификаторов, отображаемых в меню)
toolsdisplayorder={52a21b27-de77-11e2-b691-005056c00008}...{b2721d73-1db4-4c62-bf78-c548a880142d} - аналогично, но для меню инструментов.
timeout=30 - время (в сек.) до старта автозагрузки (пункта, указанного в default)
displaybootmenu=Yes - отображать меню загрузки или скрыть его (значение "No").
Кроме указанных, возможны и прочие параметры со своими значениями. В меню от 2k10 их нет, поскольку я их перенес в {globalsettings}.
locale=ru-RU - язык
nointegritychecks=Yes - не проверять целостность bootmgr (обязательно нужно указывать для правленных версий загрузчика, иначе при загрузке получим ошибку).
Идем в "Настройки", отмечаем "Показывать весь список", ну и заодно "Показать историю команд" (для отображения выполняемых команд bcdedit в новой нижней панели. После этого количество отображаемых разделов у нас увеличится. Перейдем (в левой панели) сразу в "Глобальные параметры"

И увидим, как можно упростить себе задачу при правке меню (а, попутно, и уменьшить размер самого меню!), если вынести одинаковые параметры из каждого пункта в одно общее место - {globalsettings}:
identifier={globalsettings} - идентификатор (точнее, псевдоним) раздела глобальных установок
path=\Windows\system32\boot\winload.exe - это путь запуска загрузчика, одинаковый для всех WinPE на базе Vista...10.
locale=ru-RU - язык (одинаковый для сборок)
loadoptions=DDISABLE_INTEGRITY_CHECKS - в общем-то, вроде это дубликат testsigning=Yes (отключить проверку целостности загрузчика). Для перестраховки.
fontpath=\2k10\Fonts - путь к шрифтам (если путь указан неверно либо шрифт не найден, bootmgr запустится в текстовом режиме 720х400, а WinPE при загрузке отключит анимацию, загрузочный экран будет как у Vista).
inherit={dbgsettings} {emssettings} {badmemory} - какие-то дополнительные внедренные параметры, не вникал (ставятся по-умолчанию)
nointegritychecks=Yes - отключить проверку целостности загрузчика
testsigning=Yes - отключить проверку цифровой подписи (для установки неподписанных драйверов)
Перейдем теперь в раздел (левая панель) "Настройка параметров RamDisk"
ramdisksdidevice=boot - указывает, что мы будем загружать РАМ-ядро из загрузочного диска (без привязки к конкретному устройству)
ramdisksdipath=\2k10\boot.sdi - указывает путь к файлу boot.sdi (необходим для создания виртуального электронного диска в оперативной памяти). Без этого файла WinPE не загрузится (голубой экран без признаков жизни). Отдельно хочу обратить внимание, что некоторые BCD-редакторы не позволяют редактировать этот параметр (устанавливая его по-умолчанию как \Boot\boot.sdi - что для "однопапочных" сборок критично). У BCDtool с этим проблем нет (как у оригинального bcdedit).
Для интереса можете пробежаться по остальным пунктам (не включаемым в меню). Там ничего важного, имхо, нет.
Теперь можно перейти к списку основного меню, загрузка WinPE. Например, третий пункт "Загрузка Windows"

identifier={47df11fa-d80a-11e2-98a1-50e54938a1e5} - идентификатор
device=ramdisk=[boot]\2k10\WinPE\W7x86NE.wim,{ramdiskoptions} - указание, что производится загрузка на РАМ-диск ядра из [boot]\2k10\WinPE\W7x86NE.wim (напомню, [boot] - означает диск, с которого произведена загрузка), с параметрами из {ramdiskoptions}
description=* Win7Live x86 Native (Old PC, boot on USB 1.2) RAM = 256...768 Mb - имя, отображаемое на экране
inherit={globalsettings} - использовать глобальные параметры
osdevice=ramdisk=[boot]\2k10\WinPE\W7x86NE.wim,{ramdiskoptions} - аналогично device
systemroot=\Windows - системный каталог
kernel=ntoskrnl.exe - можно указать загружаемое ядро (если их, например, несколько)
nx=AlwaysOff - nx - настройки безопасности (отключить)
detecthal=Yes - автоопределение конфигурации оборудования и создание уровня программного доступа к нему
winpe=Yes - что это WinPE-режим загрузки
Кроме ОС и WinPE, bootmgr умеет загружать загрузчики предыдущего поколения (NTLDR и маскирующийся под него GRLDR) и загрузочные записи. Тут вообще все просто. Становимся слева на любой "Загрузчик прежних версий".

Идентификатор, устройство (все то же - boot), путь к загрузчику (C9DP.bin - это GRLDR с встроенным меню), описание. Аналогично прописывается запуск загрузочных записей (GRLDR так тоже запускается).
Артподготовку мы провели. Теперь самый интересный вопрос - а как же СОЗДАТЬ новый пункт меню? Тут все ОЧЕНЬ просто: "Редактировать\Создать...".
Создать запись NT6.x ... - предназначено для создания записи загрузки обычной ОС
Создать запись real-mode ... - для создания записи загрузки из загрузочной записи
Создать запись NT5.x ... - загрузка NTLDR / GRLDR
Создать запись загрузки из RAM-диска - загрузка ядра WinPE
Создать запись настройки отладчика - скорее всего, это вам никогда не понадобится.
Впрочем, обычно НАМНОГО проще не создавать запись заново, а просто скопировать подходящий вариант в новый ("Редактировать\Копировать выбранный пункт"). При этом ему будет присвоен новый идентификатор и название. Останется только подправить нужное.
"Показывать эту запись в списке загрузки" - значит, отображать в меню загрузки нужное (при создании или копировании пунктов они автоматически вносятся в меню загрузки).
"Скрыть эту запись в списке загрузки" - запись останется, но будет скрыта из меню загрузки. Как её показать, вы уже знаете. :)
"Удалить выбранный пункт" - без комментариев... Туды его, в качель!
Вот и все по редактированию. Несколько советов попутно:
1. Перед редактированием делайте копии исходного файла (дабы не было мучительно больно, когда дверьми прищемит орешки). Особенно, если правите системное меню ОС.
2. Если правка системного меню невозможна, значит, оно подгружено в реестр как куст HKEY_LOCAL_MACHINE\BCD0000000x - выгрузите этот куст или назначьте права доступа. Не волнуйтесь, при следующей загрузке ОС права будут сброшены, а куст загружен.
3. Размер файла меню можно дополнительно (кроме использования глобальных установок) уменьшить, удалив весь мусор с помощью обычного редактора реестра. Для этого загружаем BCD как куст (в regedit становимся на раздел HKLM или HKU, "Меню\Загрузить куст"). Выбираем наш файл меню, указываем имя раздела (к примеру, "0"). Становимся на этот раздел ("0"), ПКМ\Экспортировать. Набираем новое имя и обязательно выбираем "тип файла" - файлы кустов реестра. ОК - и мы получим копию нашего куста (то бишь, BCD-меню) без мусора (оставшегося от предыдущих правок). Расширение у этого файла будет reg - но пусть вас это не обманывает, это именно куст. После этого на "0" "Меню\Выгрузить куст". Сохраненную копию переименовываем на BCD. Готово. Впрочем, эту операцию можно упростить, если использовать BCDimpex. В ней открываем наш BCD Import from... и жмем Rebuild Only. Все - на выходе в папке программы получим "высушенный" файл BCD.rebuild.

Как найти и заменить ресурс, в котором имеется какая-то надпись (на экране, при загрузке, сообщение вируса). Много картинок!

Толчком для написания послужил этот скрипт. Я уже давно использую способ поиска текста намного проще и эффективнее.
Нам понадобится файловый менеджер FAR (да простят меня пользователи TC - в нём тоже есть подобный поиск, но возможности поскромнее), редактор ресурсов Restorator (либо любой другой). В некоторых случаях придётся использовать НЕХ-редактор (я использую Hiew32, он у меня встроен в самораспаковку менеджера FAR из сборки 2k10).
Итак, нас раздражает надпись "Тестовый режим" на экране РЕ. Мы точно знаем, что эта надпись находится в ядре самой сборки - потому как больше негде! ))

Порядок действий.
Вначале распаковываем wim-ядро сборки в любой временный каталог, желательно на диск пошустрее (к примеру, я для этого использую РАМ-диск в памяти). К слову, FAR умеет искать и прямо в архивах (к коим относится и wim-ядро при наличии плагина 7-zip). Но поиск в архиве занимает намного больше времени, чем поиск в предварительно распакованном ядре, поэтому лучше распаковать.
Переходим в FAR в папку с распакованным ядром и выбираем поиск (Alt+F7). Маску оставляем *.*, вбиваем нужное в "Содержащих текст" и обязательно выбираем "Все стандартные кодовые страницы" (мы ведь заранее не знаем, в какой кодировке будет текст).

"Нажми на кнопку - получишь результат!" Надпись "Поиск закончен" появится после полного завершения сканирования папки.

Как результат мы получили 4 файла. Причём два из них в каталоге WinSxS - это просто копии. Думаю, понятно, что вероятность того, что искомая фраза в интерфейсе используется именно из файла shell32.dll.mui намного выше, чем из fsutil.dll.mui. Это не всегда так, но в данном примере - так. Осталось найти и заменить надоедливую надпись. Для этого подойдёт Restorator.
Чтобы открыть файл с расширением mui, нужно пойти на небольшую хитрость: в строке ввода имени указываем *.*, тогда в проводнике будут отображены все типы файлов. Либо можно указать сразу же полное имя файла.
Ctrl+F, вводим снова искомую строку, ищем и находим нужное.

Там же рядом присутствуют надписи "Безопасный режим", "Пробная версия"... Думаю, дальше всё понятно.
Отмечу, что надпись Build 15063.rs2.... найти было бы невозможно. Поскольку она создана из составляющих - слова Build и переменной № версии. Но тут нам очень повезло, ведь рядом с "Тестовый режим", в строке 2882 указано %ws Build %ws, и это очень напоминает индикацию номера сборки. Так что можно попытать счастья.
Для закрепления - ещё один пример.
Надпись при загрузке ядра 7х86 из сборки 2k10.
Отдельно отмечу, что некоторые надписи, появляющиеся в момент загрузки, используются из самого загрузчика bootmgr (или его MUI), а некоторые - из ядра. "Разделительной чертой" служит момент окончания загрузки ядра в память.

Производим поиск по аналогичному шаблону

Результат

Попробуем провести правку не Restorator (ведь не все ресурсы можно открыть редактором ресурсов, кое-какие файлы при отсутствии "фирменного" редактора можно подправить только НЕХ-редактором). Если используется FAR из 2k10, становимся на файл и нажимаем Alt+F4 (вызываем Hiew32).

К слову, этот редактор имеет ограничения по поддержке кириллицы и пробелов, поэтому, если файл не открывается - просто временно переименуйте его на имя попроще (в формат 8.3).
По F7 вызываем строку поиска, вбиваем искомую надпись... И облом, не найдено... Причина очень проста: кодировка не совпадает. Нажимаем F8, выбираем другую кодировку, снова ищем...

Наконец, в кодировке Unicode (большинство win-файлов именно в ней хранят ресурсы), находим искомое.

Чтобы перейти в режим HEX-правки, жмём F4 и выбираем HEX, немного пролистываем вниз (в НЕХ-режиме количество отображаемого текста на экране меньше) - заново находим искомую надпись.

По F3 переходим в режим редактирования, по TAB - на правую панель. Правим нашу надпись под свой вкус. По F9 вносим изменение в файл.

Всё, готово! Теперь можно пересобрать ядро, протестировать загрузку и оценить результат.
Как быстро проверить - то или не то - мы нашли/заменили?
Можно, конечно, пересобрать ядро, запустить в эмуляторе и оценить результат. Но на практике для РЕ-сборок есть решение попроще. По крайней мере, если ядро базируется на PeCMD и есть возможность перезагрузить оболочку. Итак: просто загружаемся под РЕ. Переименовываем файл, который нам нужно будет подменить модифицированным (просто удалить его часто не получится - он может блокироваться системой). После переименования копируем наш мод-файл и перезагружаем оболочку (убиваем проводник Explorer.exe, и потом, если он не запустился сам - запускаем его вручную).
Такой подход удобен тем, что можно быстро подправить нужное прямо под РЕ и сразу же увидеть результат.
Замечание: а что, если в результате поиска мы нашли несколько потенциальных кандидатов на правку, как определить виновника без лишних усилий и тестирований? Я поступаю так: вместо исправления надписи сразу во всех, просто вношу вместо первого символа порядковый номер (1-9, буквы по алфавиту). Потом смотрю, какой номер высветится в тесте.
Ограничение на поиск - упакованные файлы. К счастью, FAR автоматически распакует стандартные архивы (zip, 7zip, rar, прочие) и произведёт поиск внутри файлов в архиве. Но файлы, упакованные пакерами (UPX, mpress, PEcompact и т.д.) FAR не распакует, и, соответственно, если текст находится внутри такого файла - он не будет найден.
Где всё это можно использовать? Не поверите - очень во многих случаях. Пример из жизни: вирус-червь. Ни один антивирь не находил, ОС переставлять было нельзя. А вирус просто прописывал свою страничку везде. Пришлось пройти поиском по системному диску (под РЕ, чтобы было проще и быстрее) - искал страничку. Нашлась в профильном каталоге, у черта на колючках! Второй этап - найти, кто запускал этот файл... По сути, второй пример: нужно удалить драйвер (либо любой файл, прописанный в системе). Оказалось, что драйвер запускается в реестре (были найдены все улья реестра), и с помощью "безобидного" файла, имитирующего системный. Поиск в реестре и очистка - с помощью RegWorkshop (мегаудобная штука в плане поиска).

Отключение кеширования при записи на FAT/FAT32-раздел USB сменных накопителей (флешек)

Кеширование записи в РЕ может сыграть злую шутку с пользователем. Например, пользователь решил скопировать свои данные на флешку. После того, как визуально данные "скопировались", он производит перезагрузку - и оказывается, всё впустую. С другой стороны - даже если пользователь знает о кешировании, то ему приходится (на всякий случай!) ждать намного дольше окончание копирования, чтобы перестраховаться.
К сожалению, я пока не знаю решения, позволяющего полностью отключить кеширование для съёмных накопителей. Но, по крайней мере, для FAT-разделов флешек есть возможность это сделать. Проблема кроется в отсутствии в ядре некоторых РЕ системной библиотеки dskquota.dll. Если она имеется в ядре, кеширование записи на сменные накопители по-умолчанию отключено (идентично обычной ОС). Если библиотека отсутствует, тогда по-умолчанию кешируются все накопители. Для х64-ядер с поддержкой 86-подсистемы нужны обе библиотеки (х86 + х64) - они работают отдельно для х86 и х64 режимов.

Загрузка Windows в режиме Legacy BIOS

Порядок загрузки в режиме Legacy BIOS:
1. Инициализация BIOS, определение подключенного "железа".
2. Обращение к первому накопителю, указанному в списке загрузки. Если загрузка невозможна, перебор всех накопителей из списка, при неудаче - сообщение о невозможности загрузки.
3. Если накопитель загружаемый, считывается MBR-загрузчик. Он, в свою очередь, считывает PBR-загрузчик (загрузчик, прописанный в активном разделе).
Примечание: Некоторые альтернативные MBR-загрузчики игнорируют PBR и умеют напрямую выполнять какое-то действие. Например, загрузчик на базе WEE может содержать своё меню загрузки, а Plop Boot Manager - целый менеджер загрузки.
4. PBR-загрузчик (либо альтернативный MBR-загрузчик) могут запускать непосредственно загрузчик в файловой системе накопителя. Для мира MS - это NTLDR (Windows 200*/XP) или Bootmgr (Windows 7...10).
5. Загрузчик считывает своё меню. Для NTLDR это файл boot.ini в корне загрузочного диска, для Bootmgr - файл BCD в папке Boot.
Примечание: Меню загрузки, при нестандартном размещении самого загрузчика (не в корне диска) от MS, может находиться рядом с самим загрузчиком. Такое меню будет использовано в первую очередь. Т.е., вначале читается меню рядом с загрузчиком, а при его отсутствии - по стандартному пути. Стандартный путь к меню и/или его имя - можно изменить в самом загрузчике. В NTLDR это правится НЕХ-редактором. А в Bootmgr немного сложнее, нужно вначале распаковать загрузчик специальным распаковщиком, подправить его НЕХ-редактором и упаковать обратно. Как один из вариантов, можно использовать BMplus.
6. После чтения меню загрузки и выбора загрузки ОС производится запуск загрузчика ОС. Для Windows 7...10 это файл Windows\System32\Boot\winload.exe. Для Windows 200*/XP имя этого файла зависит от конфигурации железа (одноядерный CPU, многоядерный, поддержка PAE и т.п.). Обычно Windows\system32\ntoskrnl.exe (или ntkrnlmp.exe).
Примечание: В применении к WinPE с RAM-загрузкой (wim-архив ядра), перед загрузкой производится монтирование wim-архива как RAM-диска X:\.
7. Загрузчик ОС загружает ядро, драйвера, и т.д., и т.п.
-
Схематично порядок загрузки Windows 200*/XP: Bios -> HDD -> MBR -> PBR -> NTLDR -> boot.ini -> ntoskrnl.exe
Схематично порядок загрузки Windows 7...10: Bios -> HDD -> MBR -> PBR -> Bootmgr -> BCD -> winload.exe
-
Изменение путей (например, для переноса РЕ-сборки в свою, именную, папку):
1. Загрузочную запись в PBR можно подправить в BootIce - эта утилита позволяет изменить имя загрузчика NTLDR (Bootmgr) на другое. То же можно сделать и НЕХ-редактором. Но - только имя, не длиннее названия оригинала.
Примечание: Если нужен загрузчик для запуска NTLDR/Bootmgr с произвольным именем в папке, для запуска под любой поддерживаемой файловой системой, придется использовать альтернативные загрузчики. Например, XorBoot, Grub4DOS, Grub2, Wee, Syslinux. Также альтернативные загрузчики позволяют запускать из одного Bootmgr второй (напрямую Bootmgr не позволяет загружать своего собрата). Промежуточные загрузчики также называют "костылями", небольшой обзор имеется в Практикуме, спойлер "Что такое 'костыли' и зачем они нужны...".
2. Загрузчики NTLDR/Bootmgr могут запускаться с любого места, с учетом поддерживаемых файловых систем (в частности, NTLDR не работает с ExFAT, а Bootmgr работает только, если он был запущен корректной версией PBR-загрузчика от MS для ExFAT).
3. Меню загрузчиков NTLDR/Bootmgr можно положить рядом с ними (тогда правка не нужна). Если меню находятся не рядом, необходимо править стандартные пути/названия в самих загрузчиках.
4. Пути к файлам wim-архивов прописаны в меню загрузки, правятся соответствующими инструментами.
Примечание: Для корректной загрузки ядра в Bootmgr также необходима правильная прописка к шрифтам (нужно править Bootmgr) и файлу boot.sdi (этот файл необходим для создания RAM-диска, путь к нему прописан в меню загрузки BCD).

Загрузка Windows в режиме UEFI

Порядок загрузки в режиме UEFI:
1. Инициализация UEFI, определение подключенного "железа".
2. UEFI базируется на принципиально новой топологии кода, которая называется "драйверность". По сути, это полноценная операционная система. Поэтому, в зависимости от настроек, меню начальной загрузки может отличаться. Это может быть выбор всех доступных накопителей (причем для некоторых есть два варианта загрузки - EFI или Legacy), запуск встроенной или внедрённой оболочки, и т.д.. Если рассматривать именно загрузку в EFI-режиме, то она происходит проще, чем для Legacy-варианта. UEFI напрямую запускает загрузчик из каталога efi\boot. Имя загрузчика зависит от разрядности процессора (и, соответственно, разрядности самой UEFI). Для 32-битовых систем это файл bootia32.efi, для 64-битовых - bootx64.efi. Стиль разделов MBR или GPT не играет роли, UEFI работает с обоими вариантами (загрузчики в MBR/PBR игнорируются). А вот файловая система важна - исключительно FAT/FAT32.
Примечание: Некоторые производители интегрируют в UEFI драйвера NTFS (в частности, так делает ASUS). На таких UEFI возможна загрузка из NTFS-раздела. Но это, скорее, исключение, чем правило.
Правка загрузчиков не составляет проблем, поскольку файлы неупакованы. Но файлы обладают цифровой подписью (ЦП), которая проверяется в режиме загрузки Secure Boot. При несоответствии ЦП загрузка в режиме Secure Boot станет невозможна. Как частичное решение проблемы, допустима НЕХ-правка загрузчика bootia32.efi (поскольку в UEFIх32 очень-очень редко используется Secure Boot).
Загрузчики от MS "умеют" загружать исключительно только "свои" продукты: тест памяти и загрузчик ОС MS. "Переходы" на сторонние загрузчики/утилиты и другую копию загрузчика невозможны. Альтернативные загрузчики (EFI-версии Grub2, XorBoot, прочие) могут загружать загрузчик от MS, но обратный переход невозможен.
3. Загрузчик считывает своё меню, efi\microsoft\boot\BCD. Имя меню идентично для обеих версий загрузчика, и для 32-битовых реализаций, и для 64-битовых. Что, безусловно, неудобно. Именно поэтому желательно разделить меню на 64-разрядную версию и 32-разрядную (путём правки bootia32.efi).
Примечание: Разделение меню по разрядности очень важно, поскольку версии несоответствующей разрядности несовместимы. Т.е., 32-битовая ОС/РЕ не работает в UEFIх64 и наоборот. Так что удобно в х64-меню указать х64 ОС, а в х32, соответственно - х32.
Меню загрузки от MS, может находиться рядом с самим загрузчиком. Такое меню будет использовано в первую очередь. Т.е., вначале читается меню рядом с загрузчиком, а при его отсутствии - по стандартному пути.
4. После чтения меню загрузки и выбора загрузки ОС производится запуск загрузчика ОС. Для Windows 7...10 это файл Windows\System32\Boot\winload.efi.
Примечание: В применении к WinPE с RAM-загрузкой (wim-архив ядра), перед загрузкой производится монтирование wim-архива как RAM-диска X:\.
5. Загрузчик ОС загружает ядро, драйвера, и т.д., и т.п.
Примечание: В Windows 7 х64 отсутствуют ЦП файлов. Поэтому для этой ОС загрузка в режиме возможна исключительно с выключенным Secure Boot.
-
Схематично порядок загрузки Windows 7...10: UEFI -> HDD FAT/FAT32 -> bootx64.efi/bootia32.efi -> BCD -> winload.efi
-
Изменение путей (например, для переноса РЕ-сборки в свою, именную, папку):
1. Загрузить EFI-загрузчик можно исключительно по стандартному пути. Если используются альтернативные загрузчики - тогда возможно создание меню загрузки EFI-утилит от разных производителей и переход к меню загрузки ОС/РЕ от MS. Но, в таком случае, появляются проблемы с загрузкой в режиме Secure Boot, частично решаемые использованием Shim\PRELoader с установкой ключей в UEFI.
2. Меню загрузчиков от MS bootx64.efi/bootia32.efi (по сути, это bootmgr.efi) можно положить рядом с ними (тогда правка не нужна). Если меню находятся не рядом, необходимо править стандартные пути/названия в самих загрузчиках (на практике - применимо только для х32-версии).
3. Пути к файлам wim-архивов прописаны в меню загрузки, правятся соответствующими инструментами.
Примечание: Для корректной загрузки ядра в Bootmgr также необходима правильная прописка к шрифтам (если пути нестандартные, нужно править Bootmgr) и файлу boot.sdi (этот файл необходим для создания RAM-диска, путь к нему прописан в меню загрузки BCD).

Как работает RAM-диск MicroSoft (по результатам моих экспериментов):

а) Все скопированное туда динамически сжимается (т.е., например, обычные тексты займут в несколько раз меньше места, да и обычные EXE/DLL могут сжиматься порой вдвое/втрое). Это можно использовать - например, задать размер RAM-диска 2Гб (при том, что реальный размер будет ограничен 1Гб, ограничение установок драйвера обычно в 2 раза больше - зависит от поколения драйвера) - такой финт позволит устанавливать программы, которым мало 1Гб для установки. С учетом динамического сжатия занимаемый в памяти объем такой программы будет в полтора-два раза меньше на RAM-диске MicroSoft.
б) Естественно, при использовании RAM-диска MicroSoft никаких чудес не происходит: при наличии, например, всего 256Мб свободной памяти - туда можно будет записать только 256Мб несжимаемых данных (для данных, которые сжимаются динамически - зависит от степени сжатия). Причем это произойдет независимо от того, какой предел размера RAM-диска у нас установлен: 512Мб/1Гб/2Гб. А вот если размер RAM-диска установлен меньше размера свободной памяти, тогда работает именно программное ограничение.
в) При удалении данных из RAM-диска MicroSoft память ПОЛНОСТЬЮ возвращается системе (отмечу, что это на 100% характерно только для RAM-диска MicroSoft) и может быть задействована повторно.
г) При 100%-ном заполнении памяти ("забиваем" RAM-диск данными до упора) поведение разных WinPE отличается: возможна как "правильная реакция" - т.е., сообщение о нехватке памяти, так и банальное зависание. Какими настройками это определяется - не знаю.