[Цитировать]

    conty9
  • 100
  • Стаж: 3 года
  • Сообщений: 915
  • Репутация:69

    [+] [-]
Решил создать отдельную тему с практическими рекомендациями для конструкторов. Поскольку некоторые вопросы всплывают часто, а я забываю, где уже отвечал на них.
Все это - лишь мои досужие домыслы ae , и я могу ошибаться в некоторых вопросах, так что прошу воспринимать все это с долей скептицизма. af
Тему я буду периодически чистить, а ответы на вопросы постараюсь добавлять в соответствующий (или новый) раздел.-

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


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

Напомню, что править bootmgr можно, например, с помощью WBM CUSTOMIZER.
Примерное содержание boot.ini (Guest.ini, ну или как там вы его обзовете в патченном bootmgr)
iftitle for bootmgr
[boot loader]
[operating systems]
C:\_WIN\BOOT\_WIN_LOADER.LDR="Multiboot Collection Full v.1.7"
C:\_WIN\BOOT\AWBL_LOADER.LDR="AntiWinBlock 3.1 FINAL"
C:\_WIN\BOOT\SSTR_LOADER.LDR="Sergei Strelec 2015 v.8.3 Win8-8.1(x86/x64/Native x86)"
C:\SSTR\grldr="Strelec - Grub4Dos menu"
C:\_WIN\BOOT\PASS_LOADER.LDR="BootPass 4.0.7 Mini"
Примечание: текстовое меню позволяет загружать исключительно загрузчик предыдущего поколения (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 - это мини-ОС на базе Linux, задача которой запустить загрузчик. Загрузчиком служит файл из папки 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-архива).
Положа руку на печень ae , признаюсь: лучший вариант перепаковки - это упаковка "с нуля". Она позволит добиться минимального размера архива. И для такой упаковки вполне достаточно единственного файла - imagex.exe от Vista (такой вариант работоспособен под всей линейкой ОС, начиная от ХР и заканчивая 10-й). Его можно взять, например, из сборки 2k10 (в папке 2k10\WinPE\Repack.Wim).
Распаковываем нужное ядро в рабочую папку (индекс "1" для одноиндексного ядра, т.е., в рабочей папке должен быть подкаталог 1 с содержимым диска X:\). В ту же папку закидываем imagex.exe и бАнТиК такого содержания
imagex.exe /capture /compress maximum /boot .\1 .\W7x64PE.WIM "W7x64PE"
где W7x64PE.WIM - имя нового архива, а W7x64PE - его метка (в большинстве случаев может быть произвольной).
Правим в распакованном ядре необходимое, и упаковываем его батником. Для максимального сжатия после упаковки ядра можно пройтись утилитой 78RePack, режим UltraPack - это позволит дополнительно уменьшить ядро на пару мегабайт.
Для многоиндексных ядер необходимо знать, для чего предназначены индексы, чтобы правильно подправить сборку. Поэтому лучше использовать авторские скрипты для перепаковки (например, в 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Мб)
REGEDIT4
[HKEY_LOCAL_MACHINE\System\ControlSet001\Services\FBWF]
"WinPECacheThreshold"=dword:00000100
Заменяем HKEY_LOCAL_MACHINE\System на HKEY_LOCAL_MACHINE\0s, получим:
REGEDIT4
[HKEY_LOCAL_MACHINE\0s\ControlSet001\Services\FBWF]
"WinPECacheThreshold"=dword:00000100
Этот рег-файл можно применить к смонтированному как 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_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"
; Отключить вывод сообщений об ошибках (например, при обращении к "пустому" кардридеру)
; Включить -> "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
...
Продолжение - в первом сообщении темы...


Последний раз редактировалось: conty9 (2015-11-14 11:13), всего редактировалось 85 раз(а)

[Цитировать]

    conty9
  • 100
  • Стаж: 3 года
  • Сообщений: 915
  • Репутация:69

    [+] [-]
В шапке закончилось "место", продолжу в этом сообщении.

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

Часто бывает, что конкретный загрузчик (например, 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
set MyName=2k10\Programs-2k10\FileManager\FAR\far.cmd
for %%I in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%I:\%MyName% start "" %%I:\%MyName%&&exit
echo УВЫ, ничего не найдено!
exit
Нюанс (в применении к WinPE) заключается в том, что поиск с использованием If exist под WinPE может "стопориться" на поврежденных разделах, или на отсутствующих носителях в картридере/CD/DVD. В таком случае WinPE выдаст соответствующее предупреждение, которое нежелательно (особенно если оно будет повторяться несколько раз). Избежать подобной ситуации можно разными способами:
1. Использовать команду Dir для проверки "валидности" файла на разделе (мое ноу-хау). Эта команда работает в самых урезанных ОС, и при ошибке не вызывает консольное окно. Вариант скрипта с её использованием:
set MyName=\2k10\Programs-2k10\FileManager\FAR\far.cmd
for %%I in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do dir %%I:%MyName%&&start "" "%%I:%MyName%"&&exit
echo УВЫ, ничего не найдено!
exit
MyName - переменная, указывающая на файл, который нужно найти и запустить. Как работает скрипт: перебор всех буковок от C до Z. Для каждой с помощью Dir проверяется наличие файла. Если он найден (сработает &&) - тогда запуск нашего файла и выход из перебора. Если не найден, тогда вывод сообщения (УВЫ...) и выход.
2. В принципе, можно использовать и If exist, если ПРЕДВАРИТЕЛЬНО отключить вывод окна сообщения об ошибке. За это отвечает значение ErrorMode ключа реестра HKLM\System\CurrentControlSet\Control\Windows, "2" - отключить, "0" - обычное поведение. Скрипт тогда будет выглядеть так:
set MyName=2k10\Programs-2k10\FileManager\FAR\far.cmd
reg.exe add HKLM\System\CurrentControlSet\Control\Windows /v ErrorMode /t REG_DWORD /d 2 /f
for %%I in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%I:\%MyName% start "" %%I:\%MyName%&&goto:back
echo УВЫ, ничего не найдено!
:back
reg.exe add HKLM\System\CurrentControlSet\Control\Windows /v ErrorMode /t REG_DWORD /d 0 /f
exit
Т.е., сначала отключаем вывод сообщений, потом поиск, и в конце - включение вывода.
Примечание: на очень сильно урезанных 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" - путь к меню)
bcdedPE.exe /store "путь\...\BCD" /enum
bcdedPE.exe /store "путь\...\BCD" /enum /v
Ключ /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.


Последний раз редактировалось: conty9 (2016-06-03 08:29), всего редактировалось 25 раз(а)

[Цитировать]

    conty9
  • 100
  • Стаж: 3 года
  • Сообщений: 915
  • Репутация:69

    [+] [-]
12230conty9Напишите как организовать нативную загрузку для Wim сборок?
rockdgon, для организации наитив-загрузки нужны две вещи - собрать наитив-ядро (на практике, можно как базовый вариант использовать наитив-ядра от 2k10 для 2003/7/8 или наитив-ядро от Ruslive для ХР, с минимальными правками) и перепаковать (как мультииндексный архив) основное ядро - чтобы оно могло использоваться при наитив-загрузке. Еще одно важное условие - в качестве оболочки должен использоваться PECMD.
Если интерес конкретный - пиши в ПМ, попробую помочь (в рунете из "спецов" по наитивке есть только два человека - я и Xemom1, и все имеющиеся в русских сборках наитивки делал я на базе наработок китайцев и при помощи Xemom1).


Последний раз редактировалось: conty9 (2015-10-16 18:44), всего редактировалось 2 раз(а)

[Цитировать]

    SV-2k10
  • 437
  • Стаж: 2 года 9 месяцев
  • Сообщений: 278
  • Репутация:16

    [+] [-]
conty9, Привет.
Вот могу предложить добавить ветку под примерным названием – Редактирование BCD:
Ну и начать его с ликбеза на тему
Как редактировать Tools menu файла BCD:
Править/добавлять/удалять строчки … или полностью удалить пункт Tools menu.

[Цитировать]

    rockdgon
  • 1013
  • Стаж: 2 года 5 месяцев
  • Сообщений: 99
  • Репутация:0

    [+] [-]
А я заметил что BootICE не до конца позволяет редактировать BCD файл - хоть и удобна в редактировании позиций загрузочного меню. В BcdTool же можно посмотреть список всех настроек, а именно путь к папке с шрифтами. Сборщики могут запороться на моменте, когда они поправили bootmgr под свою сборку, а русский шрифт так и не отображается - загвоздка в файле BCD!

[Цитировать]

    Joker-2013
  • 1039
  • Стаж: 2 года 5 месяцев
  • Сообщений: 2366
  • Репутация:94

    [+] [-]
  • Откуда: Админ от сюда
rockdgon, в Pro режиме все видно.

[Цитировать]

    rockdgon
  • 1013
  • Стаж: 2 года 5 месяцев
  • Сообщений: 99
  • Репутация:0

    [+] [-]
Joker-2013 - странно но у меня в Pro режиме BootICE не видно globalsettings, там где прописан путь к папке с шрифтами

[Цитировать]

    Joker-2013
  • 1039
  • Стаж: 2 года 5 месяцев
  • Сообщений: 2366
  • Репутация:94

    [+] [-]
  • Откуда: Админ от сюда
тут я писал:
Автор в последних версиях убрал возможность редактирования глобальных настроек.


Последний раз редактировалось: Joker-2013 (2017-04-18 19:38), всего редактировалось 1 раз

[Цитировать]

    SunOK
  • 9
  • Стаж: 3 года 1 месяц
  • Сообщений: 498
  • Репутация:15

    [+] [-]
  • Откуда: Україна, Перлина Поділля
rockdgon, Joker-2013, вот поэтому бутайс годится только для полевых условий. А для глобальной модификации - VisualBCD (правда правда только на рабочей ОС идет из-за .NET) или BCDtool. А самый хардкор - через Regedit.

[Цитировать]

    puhpol
  • 2
  • Стаж: 3 года 1 месяц
  • Сообщений: 1051
  • Репутация:26

    [+] [-]
Приветствую господа!
Для "Инженеров" и "Конструкторов" могу сделать "галерею" (загрузка картинок на наш сервер).

[Цитировать]

    naifle
  • 762
  • Стаж: 2 года 7 месяцев
  • Сообщений: 377
  • Репутация:6

    [+] [-]
13333
Для "Инженеров" и "Конструкторов" могу сделать "галерею" (загрузка картинок на наш сервер).
Согласен на галерею, удобная штука будет.

[Цитировать]

    conty9
  • 100
  • Стаж: 3 года
  • Сообщений: 915
  • Репутация:69

    [+] [-]
Обновил картинки под спойлером "HEX-правка распакованной версии bootmgr" и перенес "полноразмерный" вариант в шапку.
...
Давно просили: Редактирование BCD-меню загрузчика bootmgr. Как смог, так и описал.

[Цитировать]

    zdoba
  • 138
  • Стаж: 2 года 11 месяцев
  • Сообщений: 337
  • Репутация:6

    [+] [-]
  • Откуда: Россия
conty9, Низкий тебе поклон! aa az

[Цитировать]

    Nentrey
  • 2079
  • Стаж: 2 года
  • Сообщений: 1
  • Репутация:0

    [+] [-]
Давно хотел сказать conty9 от всей души! .. az твои сборки не раз меня выручали... С наступившим НГ здоровья и благополучия!

[Цитировать]

    mat.86
  • 14134
  • Стаж: 1 год 5 месяцев
  • Сообщений: 26
  • Репутация:0

    [+] [-]
conty9, здравствуйте aa , когда то немножко общались с вами на ru_board af в разделе по Bart Pe. Сейчас перехожу с BartPe (на основе xp) на WinPe (на основе win7), как всегда делаю мини сборку загружающуюся полностью в память. Помогли некоторые вещи с вашего бессменного 2k10 ay . Некоторые утилиты взял в свою сборку, некоторые вещи подсмотрел как у вас реализованы, также помогла ваша инструкция по правке bootmgr и bcd, чтобы все переместить в папку со своим именем. Потом наткнулся на этот форум, нашел уже удобную утилиту BMplus. Спасибо вам за ваш труд огромное .
И собственно вопросы. 1)Размер диска X:\ (используется RAM-диск MicroSoft). Если поставить размер допустим 1гб рамдиска, а озу будет 512мб (старая машина), будут ли ошибки?
2)Сейчас запускаю winpe на старой машине 256мб озу ddr1, не грузиться вылетает ошибка что-то с bcd, Bartpe (wim-упаковка на основе хр) естественно грузится нормально. Скажите возможен ли запуск WinPe не из bootmgr, а на основе старого setupldr.bin ? Если вместо bartpe ложу Winpe с таким же именем, идет распаковка wim архива в память и на этом останавливается, можно ли как то дальше запустить? Может можно поправить файлик C9NE? У меня он такого содержания:
[SetupData]
BootDevice="ramdisk(0)"
BootPath="\windows\System32\"
OsLoadOptions="/fastdetect /minint /rdimageoffset=8192 /rdimagelength=3161088 /rdpath=BWIM\BartPE.wim"

Страница 1 из 3


Показать сообщения:    

Текущее время: 16-Дек 16:06

Часовой пояс: UTC + 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы можете скачивать файлы