- Введение
- Основные особенности Boot Scriptor
- Сборка дистрибутивов
- Дополнительный сервис
- Файл конфигурации меню проекта
- Создание образа проекта
- Вместо заключения
В настоящее время рынок операционных систем довольно насыщен, и системным администраторам порой становится тяжело в поддержке рабочих мест - особенно, если парк машин содержит самые разные ОС. Зачастую приходится постоянно при себе иметь несколько дистрибутивов с операционными системами на всякий случай, что несколько неудобно.
Выходом из данной ситуации является создание загрузочного диска с несколькими операционными системами при помощи специальных BootCD-менеджеров. В этом спектре, так же, как и на рынке ОС, существует достаточно предложений. Однако в данной статье рассмотрим один из самых гибких менеджеров подобного плана - Boot Scriptor. Его возможности очень богатые, однако нас интересует лишь запуск стартовых сценариев и аппаратная эмуляция дисков, что, в частности, и предоставляет рассматриваемый продукт.
Boot Scriptor является свободно распространяемым продуктом под лицензией NASM и представляет собой программный продукт с очень высокой степенью интерактивности загрузки с определенного устройства (CD/DVD ROM). Он базируется на концепции Diskem1x от Bart Lagerweij и снабжен целым рядом команд, позволяющих загружать систему огромным количеством вариантов, определяемых гибкостью конфигурирования меню. По большому счету, Boot Scriptor предоставляет возможности, подобные Diskem1x, однако дополненные целым рядом оригинальных особенностей и интерфейсом других программных продуктов таких, как ISOlinux/Memdisk и Ranish Partition Manager (RPM), так же являющихся свободно распространяемым, но уже по GNU GPL. Все эти особенности реализуются через консольный интерфейс или через набор простейших файлов-скриптов. «Free-природа» Boot Scriptor - это довольно весомый аргумент в отличие от остальной массы коммерческих продуктов подобного плана. На данном менеджере основаны практически все широко известные релизы «N-in-1» (схема, указывающая, сколько различных программных продуктов содержится на одном диске).
Основные особенности Boot ScriptorОсновные особенности Boot Scriptor можно описать следующим образом:
- Очень гибкий управляющий интерфейс работы в командном интерпретаторе.
- Загрузка с FDD, HDD, CD/DVD-ROM, или любого локального устройства, определенного в BIOS.
- Гибкая проверка возможности загрузки с вновь присоединенных устройств.
- Интерфейс Memdisk и Diskemu для возможности аппаратной эмуляции загрузки с виртуальных FDD/HDD.
- Загрузка с использованием образов, базирующихся на ядре Linux, DOS и т.д.
- Возможность использования в качестве загрузчика второго уровня загрузочного сектора как от CD/DVD, так и от других программ с загрузчиком небольших размеров.
- Управление разделами локального HDD через интерфейс RPM.
- Интерактивное скрипт-меню с использованием полноценной графики или форматированного текста с использованием псевдографики, или просто форматированного текста.
- Возможность навигации по структуре каталогов CD/DVD еще до выполнения процедуры загрузки.
- Вывод содержимого текстовых файлов на CD/DVD.
Структура полного комплекта Boot Scriptor включает в себя каталог \BSCRIPT\ со следующими ключевыми файлами:
\BSCRIPT\MODULES\ISOLINUX\MEMDISK - модуль эмуляции диска
\BSCRIPT\MODULES\PART.EXE - менеджер по работе с разделами
\BSCRIPT\MODULES\[MODULE].BSM - сервисные модули RPM
\BSCRIPT\BSCRIPT.BIN - ядро Boot Scriptor
\BSCRIPT\BSCRIPT.INI - файл стартового меню
\BSCRIPT\BSCRIPTW.COM - командный интерпретатор-оболочка
\BSCRIPT\LOADER.BIN - загрузочный сектор (точнее - его файловая копия)
Подробнее останавливаться на описании и возможностях данного продукта в рамках настоящего материала нет смысла - достаточно отметить, что по техническим характеристикам он соответствует требованиям для реализации мультизагрузочных дисков и является совершенно бесплатным.
Цель данной статьи - продемонстрировать не только общую схему создания мультизагрузочного диска, но и параллельно от начала и до конца на конкретном примере по шагам создать проект. Причем, создание не просто мультизагрузочного диска, а диска с локализированными (то есть с языками, отличными от английского) не родственными (не из одного семейства) NT-based Windows ОС (NT/2000/XP/2003), что является более тяжелой задачей. В чем именно состоит трудность, станет понятно далее. Кроме этого, в процессе описания будет дан ряд полезных советов по созданию максимально гибкого загрузочного диска, и указанные некоторые важные моменты, на которые стоит обратить внимание.
Сборка дистрибутивовДля начала немного о самом загрузочном диске Windows NT-base с локализованной ОС. Так, стандартный загрузочный сектор (далее для краткости просто загрузчик) компакт-диска с оригинальной структурой дистрибутива Windows NT-based в своем теле содержит логическую ссылку на загрузочный сектор (BOOTSECT.DAT) и загрузчик сценария (SETUPLDR.BIN), располагающиеся в папке \I386\ (собственно, сам дистрибутив), которая находится в корневом каталоге проекта диска (здесь и далее указывается как \ ). Загрузчик сценария, в свою очередь, активизирует модуль обнаружения аппаратуры (NTDETECT.COM) и производит поиск файла описания сценария установки (TXTSETUP.SIF), в котором содержатся ссылки на файлы дистрибутива, их логические соответствия и т.д. В локализованных версиях в загрузчике SETUPLDR.BIN содержится ссылка на "контейнер" со шрифтами (BOOTFONT.BIN), который позволяет в начальной стадии запуска программы установки выводить сообщения на определенном языке, содержащем символы, отличные от английского алфавита.
Структура папок загрузочного диска представляет собой корневую иерархию - то есть все папки дистрибутива находятся в корневом каталоге, что, разумеется, при таком подходе изначально исключает возможность создания диска с содержанием нескольких ОС, с сохранением оригинальной иерархии дистрибутива без специальных средств.
Выходом из данной ситуации является разнесение дистрибутивов операционных систем в новом проекте по отдельным папкам и перенаправление поиска загрузчика, исполняемого модуля, сценария установки, а также конечных файлов дистрибутива конкретной ОС. Для реализации этой идеи можно воспользоваться копиями консоли восстановления (CMDCONS - интерфейс командной строки, являющийся самодостаточной автономной системой, с помощью которой можно выполнять самые различные задачи, как запуск и остановка служб, а также осуществлять доступ к локальному диску, включая файловую систему NTFS) ОС, дистрибутивы которых принимают участие в конечном проекте. Эти копии размещаются в \ , задав папкам, где будут находиться эти копии, разные имена, содержащие четыре символа (почему именно четыре, станет понятно далее): цифры и буквы, не чувствительные к регистру (не различающие заглавную и маленькую). Сами же дистрибутивы необходимо скопировать в какой-нибудь каталог - для каждого дистрибутива отдельный.
Таким образом, механизм работы "нового" загрузочного диска получается следующий: загрузчик Boot Scriptor (LOADER.BIN) инициирует стартовое меню (BSCRIPT.INI), где исполняется команда отработки загрузчика второго уровня, являющегося уже файловой (причем, модифицированной - об этом далее) копией загрузочного сектора оригинального загрузочного диска с дистрибутивом ОС. В свою очередь, этот загрузчик перенаправляет поиск в каталог с копией консоли восстановления, а не в папку с дистрибутивом (\I386\). Далее выполняется программа отработки стандартного стартового сценария установки ОС, только на этапе поиска файлов дистрибутива модифицированный (об этом ниже) файл описания сценария установки (TXTSETUP.SIF) делает второе перенаправление по новому пути, где располагается уже в конечном проекте папка \I386\ с исходными файлами. Иными словами, происходит практически все то же самое, что и в оригинале, за исключением того, что осуществляется двойное перенаправление к папке с файлами дистрибутива.
Схематически структура конечного проекта выглядит следующим образом (отражены только основные моменты):
\
\BSCRIPT\
\[ROOT]\
\[ROOT]\[XXXX]\
\[ROOT]\[XXXX]\[XXXX_LABEL(S)]
\[ROOT]\[XXXX]\I386\
\[CMDCONS[XXXX]]\
[ALL_XXXX_LABEL(S)]
[BOOTLOADER(S)[XXXX]].DAT
Здесь:
\BSCRIPT\ - папка с содержимым Boot Scriptor.
\[ROOT]\ - основная папка, в которую копируются дистрибутивы необходимых ОС, обычно называемая ROOT (понятно, что имя этой папки может быть любое другое).
\[ROOT]\[XXXX]\ - каталог [XXXX] с дистрибутивом конкретной ОС.
[XXXX_LABEL(S)] - маркерные файлы конкретного дистрибутива, которые должны находиться в соответствующем \[ROOT]\[XXXX]\ каталоге.
\[CMDCONS[XXXX]]\ - каталог копии консоли восстановления конкретной ОС.
[ALL_XXXX_LABEL(S)] - маркерные файлы дистрибутивов (не одного какого-то, а ВСЕХ), которые будут в проекте - все эти файлы ото всех дистрибутивов в корневом каталоге.
[BOOTLOADER(S)[XXXX]].DAT - загрузчики второго уровня (файловая копия загрузочного сектора оригинального исходного диска) для определенного дистрибутива. Вообще, эти копии загрузочного сектора могут иметь самое различное расширение, типичное для загрузочного сектора или формата образа (DAT/IMG/BIN/и т.д.) - в конечном счете, это не имеет значения, поскольку процедура "прикрепленной" загрузки chain ориентируется по содержимому файла. Грубо говоря, расширение для загрузчиков второго уровня можно задавать "произвольно", однако обычно встречаются варианты *.DAT и *.BIN.
Собственно, структура проекта может немного отличаться от описываемой тут, и подходы могут быть разные - это станет понятно по окончании прочтения статьи. Просто в данном материале рассматривается, так сказать, универсальный «классический» вариант.
Далее будет описана общая схема создания мультизагрузочного диска на основе Boot Scriptor и параллельно по пунктам рассмотрен конкретный пример. Там, где это необходимо, будет представлена схема изменения содержимого проектов с отражением именно характерных моментов.
Пусть имеется некоторое количество локализированных дистрибутивов, которые необходимо разместить на одном диске и обеспечить исполнение стартового сценария каждого из дистрибутивов, как это делается на оригинальном, с корректным отображением символов локализации при исполнении сценария установки.
На данном этапе считается, что все дистрибутивы подготовлены, выполнены их необходимые обновления (например, интегрирован сервис-пак), сами дистрибутивы уже скопированы в соответствующие папки \[ROOT]\[XXXX]\ проекта и имеются в наличии необходимые файлы загрузчиков от дисков с этими дистрибутивами (можно взять откуда-нибудь уже готовые, или скопировать с имеющегося источника при помощи программы ISOBuster).
Например, возьмем за исходные данные следующее: пусть наш проект будет находиться на диске C:\ в каталоге \PROJECT\ (полный путь - C:\PROJECT\) - соответственно каталог \PROJECT\ является корневым каталогом проекта ( \ ). Пусть необходимо создать диск с дистрибутивами операционных систем Windows 2000 Professional и Windows XP Professional русской локализации, с возможностью отдельной загрузки установочного сценария каждой.
Для начала помещаем в корневой каталог проекта ( \ ) сам Boot Scriptor: просто копируем полностью всю папку \BSCRIPT\ из комплекта, закачанного с сайта, как есть (структура была представлена выше).
Теперь создаем в корневом каталоге проекта ( \ ) папку \ROOT\, в которую помещаем подкаталоги с дистрибутивами операционных систем, принимающих участие в нашем проекте: например, подкаталог \W2KP\ для Windows 2000 Professional и подкаталог \XPPC\ - для Windows XP Professional. При задании имени папки старайтесь уложиться в ЧЕТЫРЕ символа (на этом этапе данное требование является скорее рекомендацией, но для простоты соответствия обязательному требованию, которое будет указано ниже, стоит ограничиться). После того, как с соответствующих исходных дисков скопированы дистрибутивы данных ОС и над ними произведены все необходимые действия, конечное содержимое копируем в папки проекта \ROOT\W2KP\ и \ROOT\XPPC\ для Windows 2000 Professional и Windows XP Professional соответственно. Это необходимо сделать так, чтобы корневая структура исходного оригинального дистрибутива (имеется ввиду исходный диск с ОС, откуда берется материал для проекта, и предполагается, что он структурно сохранил свою оригинальность) являлась вложением второго уровня. То есть в результате в нашем проекте на данном этапе получается следующая структура («ориентир» - папка \I386\, являющаяся корневой папкой исходного дистрибутива):
\
\BSCRIPT\
\ROOT\W2KP\I386\
\ROOT\W2KP\
\ROOT\XPPC\I386\
\ROOT\XPPC\
Образ загрузчика (копия загрузочной области CD с дистрибутивом размером 2048 байт) достать очень просто - рекомендуется воспользоваться программой ISOBuster. Запустив ISO Buster и открыв CD (или образ, если исходный материал в таком формате) с дистрибутивом, выберите в представленной слева древовидной структуре диска ветку с загрузчиком (Bootable CD, если это действительно загрузочный диск) и в основном окне увидите среди всего прочего файл вида [FILENAME].IMG (на CD c дистрибутивом Windows ОС обычно это «MICROSOFT CORPORATION.img»). Правой кнопкой мыши вызовите на этом файле контекстное меню и извлеките (Extract [filename].img) его, сохранив на диске.
После того, как весь необходимый материал для создания проекта уже имеется, дальнейшие действия удобно разделить на этапы.
Внимание! Начиная с этого момента, никаких манипуляций с содержимым каталогов дистрибутивов (папки в каталоге \[ROOT]\[XXXX]\ проекта) в следующем описании подготовки проекта НЕ производится! Все нижеследующие действия НЕ касаются каталога \[ROOT]\ и всех его подкаталогов!
Внимание! В пределах данной статьи НЕ рассматривается работа в командном интерпретаторе Boot Scriptor (BSCRIPTW.COM)! Все последующие действия производятся в типичных оболочках и файловых менеджерах (кому как удобнее) Windows типа проводник, FAR, TC, Frigat и т.д. Структура Boot Scriptor на всем протяжении подготовки проекта играет исключительно «пассивную» роль. Единственное, что потребуется в дальнейшем изменить в каталоге \BSCRIPT\ - это создание файла меню BSCRIPT.BIN и копирование образов виртуального FDD - больше никаких других действий в пределах этого каталога НЕ производится, и интерпретатор BSCRIPTW.COM НЕ запускается! Возможно, что все нижеописанные манипуляции можно производить и в оболочке Boot Scriptor, но в данном материале это НЕ рассматривается!
Итак, вот типовая поэтапная схема подготовки проекта:
- Файлы [BOOTLOADER(S)[XXXX]].DAT в корневом каталоге проекта представляют собой, как уже отмечалось, ни что иное, как файловую копию загрузчика исходного CD с дистрибутивом конкретной ОС. Берется стандартный загрузчик от каждого дистрибутива, который принимает участие в проекте, открывается любым редактором, там ищется комбинация SETUPLDR.BINBOOTFIX.BINI386 (ссылка на загрузчик модуля сценария) в практически самом конце, и меняются последние четыре символа (I386) на имя папки, которое в последствии будет дано \[CMDCONS[XXXX]]\ конкретного дистрибутива. Внимание! Необходимо уложиться именно в четыре символа - не больше, не меньше! Произвести данные манипуляции со всеми загрузчиками, от каждого дистрибутива, после чего их переименовать - для удобства, скажем, именами каталогов соответствующих [CMDCONS[XXXX]]. Полученные файлы положить в \ проекта.
Например, образ загрузчика CD дистрибутива Windows 2000 Professional, извлеченного на предыдущем этапе, переименовываем в W2KP.DAT, а образ загрузчика CD дистрибутива Windows XP Professional - в XPPC.DAT и копируем полученные файлы в корневой раздел проекта. То есть теперь наш проект «расширился» до такой структуры:
\
\BSCRIPT\
\ROOT\W2KP\I386\
\ROOT\W2KP\
\ROOT\XPPC\I386\
\ROOT\XPPC\
W2KP.DAT
XPPC.DAT
Теперь открываем любым редактором файл W2KP.DAT и ищем последовательность SETUPLDR.BINBOOTFIX.BINI386, где изменяем последние четыре символа (I386) на имя папки копии консоли восстановления, состоящее именно из ЧЕТЫРЕХ символов, которое определили в начале - W2KP. В результате последовательность примет вид SETUPLDR.BINBOOTFIX.BINW2KP. Файл XPPC.DAT отредактировать аналогичным образом, изменив последние четыре символа последовательности на имя соответствующей CMDCONS - SETUPLDR.BINBOOTFIX.BINXPPC . - Маркерные файлы. Внимание! НЕ забывайте, что с интегрированием сервисных дополнений к существующим маркерам добавляется еще один. Эти маркерные файлы необходимо, как говорилось выше, скопировать в \ от каждого дистрибутива. Также собственные маркеры должны быть в соответствующих каталогах - \[ROOT]\[XXXX]\ .
Например, на данный момент для семейства Windows 2000 существует четвертый по счету релиз сервисного дополнения (SP4), а для семейства Windows XP - второй (SP2). Соответственно, если в нашем проекте дистрибутивы подверглись обновлению этими сервисными дополнениями, то наборы маркерных файлов для них будут следующими: для Windows 2000, SP4 - CDROM_IP.5, CDROM_NT.5, CDROMSP4.TST, а для Windows XP, SP2 - WIN51, WIN51IP и WIN51IP.SP2.
В результате, на данном этапе наш проект уже будет иметь такую структуру:
\
\BSCRIPT\
\ROOT\W2KP\I386\
\ROOT\W2KP\
\ROOT\XPPC\I386\
\ROOT\XPPC\
W2KP.DAT
XPPC.DAT
CDROM_IP.5
CDROM_NT.5
CDROMSP4.TST
WIN51
WIN51IP
WIN51IP.SP2 - Копии консоли восстановления. В каталоги \[CMDCONS[XXXX]]\ необходимо скопировать содержимое консоли восстановления - свою для каждого дистрибутива. Не смотря на то, что содержимое [CMDCONS[XXXX]] представляет собой просто некоторый набор файлов из дистрибутива, приводить здесь список этих файлов бессмысленно, так как он разный у дистрибутивов разных ОС. Кроме этого, список файлов даже в пределах одной ОС может расширяться в зависимости от модернизации дистрибутива сервисным дополнением. Таким образом, есть два пути.
Первый путь сводится к тому, что консоль восстановления сама по себе переписывается из дистрибутива в УЖЕ установленную на ПК операционную систему. Произвести это очень просто: загрузиться в необходимую ОС, зайти в каталог с ее дистрибутивом и выполнить WINNT32.EXE /CMDCONS - в результате на загрузочном диске появится скрытый (обратите внимание!) каталог \CMDCONS\, содержимое которого и используется в проекте. Таким образом, необходимо создать для каждого из дистрибутивов проекта свою CMDCONS. Однако, честно говоря, совершенно не обязательно устанавливать каждую ОС отдельно и выполнять из ее родного дистрибутива команду установки консоли восстановления. Поэтому этот длительный способ может быть укорочен: из любой установленной Windows NT-based системы можно установить консоль восстановления от любой Windows NT-based операционной системы отдельно взятого дистрибутива, поскольку результатом выполнения WINNT32.EXE /CMDCONS является обычное копирование файлов по списку, находящемуся в определенном файле дистрибутива.
Будьте внимательны! Мастер установки консоли восстановления перепишет в созданную им папку \CMDCONS\ на системном диске файл ответов WINNT.SIF, включающий текущие (!) настройки системы, из которой производится установка. Для исключения этих настроек в ходе установки системы из уже готового проекта удалите этот файл (WINNT.SIF) из каталога \[CMDCONS[XXXX]]\ конечного проекта. Далее будет рассказано как внедрить в проект дополнительно (!) возможность автоматической установки системы с использованием файла(ов) ответов.
Второй путь состоит в обычном выборе и копировании «руками» необходимого набора файлов из списка, упоминавшегося выше. Этот список находится в разделах [FloppyFiles.0], [FloppyFiles.1], [FloppyFiles.2], [FloppyFiles.3] и [CmdConsFiles] файла \I386\DOSNET.INF конкретного дистрибутива. Иными словами, все файлы, входящие в состав аварийного комплекта загрузочных дискет определенного дистрибутива, и являются его набором CMDCONS. То есть, можно просто запустить программу создания консоли восстановления (для каждого дистрибутива - свою) и потом все полученное содержимое скопировать в определенную папку \[CMDCONS[XXXX]]\ проекта, или распаковать в определенную папку \[CMDCONS[XXXX]]\ образы (IMG) четырех загрузочных дискет, обычно идущих в составе дистрибутива. Или же просто выбрать файлы по списку из DOSNET.INF «руками» из самого дистрибутива (каталог \I386\). В результате получится набор из приблизительно от 130 до 190 файлов (в зависимости от локализации), плюс несколько файлов (обычно два: NTDLL.DLL и SMSS.EXE) в подкаталоге \[CMDCONS[XXXX]]\SYSTEM32\ .
Отдельно необходимо отметить, что в списке копируемых файлов \I386\DOSNET.INF указаны их полные имена, тогда как в «исходном» состоянии у большинства этих файлов (не у всех) последняя буква в расширении «заменена» подчеркиванием - это значит, что это CAB-архив, внутри которого содержится конечный файл с полным именем. Однако необходимо копировать в папку \[CMDCONS[XXXX]]\ файлы в исходном состоянии, как именно они и лежат в дистрибутиве - с подчеркиванием вместо последней буквы расширения, то есть, НЕ извлекая их из архива.
Например, для нашего проекта в корневом разделе создаем каталоги \[CMDCONS[XXXX]]\ дистрибутивов с именами, которые были использованы в пункте 1 редактирования файлов-загрузчиков: \W2KP\ и \XPPC\ . После этого копируем в каталог проекта \W2KP\ необходимый набор файлов из дистрибутива (\ROOT\W2KP\I386\), согласно списку из файла \ROOT\XPPC\I386\DOSNET.INF, разделы [FloppyFiles.0], [FloppyFiles.1], [FloppyFiles.2], [FloppyFiles.3] и [CmdConsFiles]. Далее копируем в каталог проекта \XPPC\ необходимый набор файлов из дистрибутива (\ROOT\XPPC\I386\), согласно списку из файла \ROOT\XPPC\I386\DOSNET.INF, разделы [FloppyFiles.0], [FloppyFiles.1], [FloppyFiles.2], [FloppyFiles.3] и [CmdConsFiles].
Если этот способ для вас затруднителен, то просто, находясь в уже установленной NT-based системе (если вы собираете проект в Windows 9x, то этот шаг в таком случае выполнить не удастся), зайдите в каталог \ROOT\W2KP\I386\ и выполните WINNT32.EXE /CMDCONS , после чего файлы из созданного на системном диске скрытого (обратите внимание!) каталога \cmdcons\ перепишите в папку \W2KP\ проекта. Теперь удалите с системного диска каталог \cmdcons\ , чтобы не возникло путаницы в файлах и выполните все действия, описываемые выше для дистрибутива \ROOT\XPPC\I386\ : исполните оттуда WINNT32.EXE /CMDCONS и файлы из вновь созданного на системном диске скрытого каталога \cmdcons\ перепишите уже в папку \XPPC\ проекта. Внимание! НЕ забывайте про упомянутый выше автоматически создаваемый мастером файл WINNT.SIF!
Таким образом, на данном этапе проект выглядит уже так:
\
\BSCRIPT\
\ROOT\W2KP\I386\
\ROOT\W2KP\
\ROOT\XPPC\I386\
\ROOT\XPPC\
\W2KP\SYSTEM32\
\W2KP\
\XPPC\SYSTEM32\
\XPPC\
W2KP.DAT
XPPC.DAT
CDROM_IP.5
CDROM_NT.5
CDROMSP4.TST
WIN51
WIN51IP
WIN51IP.SP2 - Файл SETUPLDR.BIN. В переписанных уже каталогах \[CMDCONS[XXXX]]\ (в каждом отдельно) необходимо открыть в любом редакторе этот файл (SETUPLDR.BIN) и найти в нем ссылки на каталог \I386\ (просто ищется последовательность символов I386), и как в пункте 1 изменить I386 на имя соответствующей папки \[CMDCONS[XXXX]]\. Произвести данные изменения в каждом файле SETUPLDR.BIN соответствующего каталога \[CMDCONS[XXXX]]\ .
Например, в нашем проекте открываем в любом редакторе файл \W2KP\SETUPLDR.BIN и ищем в нем I386 последовательности, заменяя их на имя каталога копии консоли восстановления, в которой находится редактируемый файл - W2KP. То же самое производим и с загрузчиком сценария \XPPC\SETUPLDR.BIN, заменяя встречающиеся последовательности I386 на XPPC.
- Файл TXTSETUP.SIF. В переписанных уже каталогах \[CMDCONS[XXXX]]\ (в каждом отдельно) необходимо открыть в любом редакторе этот текстовый файл (TXTSETUP.SIF) и найти в нем параметр SetupSourcePath - это путь к содержимому дистрибутива. По умолчанию он соответствует корневому разделу (SetupSourcePath = "\"), так как на оригинальном диске папка \I386\ находится именно в корневом разделе диска. Соответственно, необходимо перенаправить поиск источника файлов в новое месторасположение папок с дистрибутивами - это \[ROOT]\[XXXX]\ . Изменить в TXTSETUP.SIF соответствующих \[CMDCONS[XXXX]]\ пути к соответствующим дистрибутивам.
Например, в нашем проекте открываем в любом редакторе файл \W2KP\TXTSETUP.SIF, ищем в нем параметр SetupSourcePath и меняем путь на соответствующий путь к дистрибутиву в проекте: SetupSourcePath = "\ROOT\W2KP\" (не забывайте путь к каталогу завершать обратным слешем!). Тоже самое производим и с файлом сценария \XPPC\TXTSETUP.SIF, заменив SetupSourcePath = "\" на SetupSourcePath = "\ROOT\XPPC\".
- Локализация стартового сценария установки дистрибутива. Поскольку в проекте используются, как отмечалось выше, локализованные дистрибутивы, то необходимо обеспечить корректное отображение символов алфавита соответствующей локали. Для этого файл с набором локализированных символов (BOOTFONT.BIN), который лежит в папке \I386\ дистрибутива необходимо разместить в \ проекта. Однако в проекте имеются, как отмечалось в задании, не родственные ОС, которые используют разные наборы BOOTFONT.BIN. Соответственно, два и более файла с одинаковым именем в одном каталоге существовать не могут! Выход - изменить имена файлов BOOTFONT.BIN, после чего в файле SETUPLDR.BIN, который ссылается на данный «контейнер», соответствующего \[CMDCONS[XXXX]]\ изменить в любом редакторе все упоминания о BOOTFONT.BIN на новое имя файла. Внимание! Новое имя файла BOOTFONT.BIN должно содержать восемь символов (именно столько символов в имени BOOTFONT) - не больше, не меньше! Произвести модификации файлов \[CMDCONS[XXXX]]\SETUPLDR.BIN тех дистрибутивов, имена файлов BOOTFONT.BIN которых были изменены.
Например, в нашем проекте файл \ROOT\W2KP\I386\BOOTFONT.BIN копируем в \ под именем, допустим, BOOTFNTW.BIN, а файл \ROOT\XPPC\I386\BOOTFONT.BIN - под именем BOOTFNTX.BIN. Теперь открываем в любом редакторе файл \W2KP\SETUPLDR.BIN, делаем поиск последовательности BOOTFONT.BIN и заменяем его на новое имя файла - BOOTFNTW.BIN. То же самое производим и с файлом \XPPC\SETUPLDR.BIN : заменяем встречающиеся последовательности BOOTFONT.BIN на BOOTFNTX.BIN.
Так, на заключительном этапе данного раздела проект выглядит следующим образом:
\
\BSCRIPT\
\ROOT\W2KP\I386\
\ROOT\W2KP\
\ROOT\XPPC\I386\
\ROOT\XPPC\
\W2KP\SYSTEM32\
\W2KP\
\XPPC\SYSTEM32\
\XPPC\
BOOTFNTW.BIN
BOOTFNTX.BIN
W2KP.DAT
XPPC.DAT
CDROM_IP.5
CDROM_NT.5
CDROMSP4.TST
WIN51
WIN51IP
WIN51IP.SP2 - Введение отдельной возможности автоматической установки системы. Думается, неплохим ценным советом будет добавление возможности запуска из меню как традиционной инсталляции «вручную», так и автоматической установки (так называемый, unattended-режим). Для реализации этого момента необходимо создать еще одну, если так можно выразиться, копию копии консоли восстановления: после того, как все предыдущие пункты подготовки проекта сделаны, необходимо скопировать готовые копии консоли восстановления в папки с другим именем, разумеется. Разницей в содержимом исходной папки \[CMDCONS[XXXX]]\ и скопированной с другим именем (\[NCMDCONS[XXXX]]\) будет отдельно созданный и дополнительно скопированный в «новую» папку файл WINNT.SIF, содержащий необходимые данные сценария типа ответов на вопросы, возникающие у мастера установки в процессе инсталляции. Данный файл создается при помощи специальной программы «Диспетчер установки» (файл SETUPMGR.EXE), находящейся в файле \SUPPORT\TOOLS\DEPLOY.CAB дистрибутива. Подробности создания файла ответов - тема отдельного материала, о чем можно подробнее ознакомиться в специальном руководстве, идущим в составе дистрибутива (файлы DEPLOY.CHM и REF.CHM в составе \SUPPORT\TOOLS\DEPLOY.CAB дистрибутива). Уровень автоматизации установки зависит от выбранных в процессе создания файла ответов настроек.
Кроме того, необходимо скопировать уже модернизированный загрузчик (пункт 1) от определенного дистрибутива в корневом разделе проекта под другим именем и в нем редактором произвести корректировку пути к новой папке \[NCMDCONS[XXXX]]\ . Далее, как и в пункте 4, необходимо отредактировать файл \[NCMDCONS[XXXX]]\SETUPLDR.BIN, заменив ссылку \[CMDCONS[XXXX]] на \[NCMDCONS[XXXX]]. Пункт 5 разумеется, выполнять не нужно, так как источник файлов дистрибутива остается неизменным.Например, в нашем проекте копируем папку \W2KP\ с ее содержимым в папку с именем, допустим, \W2KU\ , а каталог \XPPC\ - в каталог с именем \XPPU\ . После создания файла ответов WINNT.SIF для каждого из дистрибутивов ОС, копируем эти сценарии в соответствующие каталоги \W2KU\ и \XPPU\.
Следующим шагом, копируем файл проекта W2KP.DAT в W2KU.DAT, а XPPC.DAT - в XPPU.DAT. Далее открываем любым редактором W2KU.DAT и в последовательности SETUPLDR.BINBOOTFIX.BINW2KP делаем корректировку одного символа на SETUPLDR.BINBOOTFIX.BINW2KU (не забывайте, что в данном случае мы редактируем уже модернизированный файл!). С файлом XPPU.DAT поступаем аналогичным образом: в редакторе последовательность SETUPLDR.BINBOOTFIX.BINXPPC исправляем на SETUPLDR.BINBOOTFIX.BINXPPU .
И, наконец, открываем в любом редакторе файл \W2KU\SETUPLDR.BIN и ищем в нем теперь уже последовательность W2KP (не забывайте, что в данном случае мы редактируем уже модернизированный файл!), заменяя на W2KU. Тоже самое производим и с загрузчиком сценария \XPPU\SETUPLDR.BIN, заменяя встречающиеся последовательности XPPC на XPPU .
Таким образом, структура «модернизированного» проекта будет следующей:
\
\BSCRIPT\
\ROOT\W2KP\I386\
\ROOT\W2KP\
\ROOT\XPPC\I386\
\ROOT\XPPC\
\W2KP\SYSTEM32\
\W2KP\
\W2KU\SYSTEM32\
\W2KU\
\W2KU\WINNT.SIF
\XPPC\SYSTEM32\
\XPPC\
\XPPU\SYSTEM32\
\XPPU\
\XPPU\WINNT.SIF
BOOTFNTW.BIN
BOOTFNTX.BIN
W2KP.DAT
W2KU.DAT
XPPC.DAT
XPPU.DAT
CDROM_IP.5
CDROM_NT.5
CDROMSP4.TST
WIN51
WIN51IP
WIN51IP.SP2Таких вариантов установки можно создать несколько, используя различного содержания файл WINNT.SIF с разным уровнем автоматизации. Однако обратной стороной медали является необходимость создания отдельной копии консоли восстановления для каждого последующего файла. Если есть в этом необходимость, выполните вышеописанную процедуру для каждого последующего случая.
Готовые примеры файла-сценария полностью автоматической установки системы с единственным вопросом выбора логического диска для Windows 2000 и Windows XP прилагаются.
Дополнения и соответствия определенным вариантам запуска инсталляции ОС будут рассмотрены ниже, в разделе, посвященном конфигурации файла меню (\BSCRIPT\BSCRIPT.INI) менеджера Boot Scriptor.
Дополнительный сервис
Было бы опрометчиво не воспользоваться еще одной замечательной возможностью Boot Scriptor - эмуляцией загрузки с FDD: Boot Scriptor способен разворачивать образ загрузочной дискеты формата IMG (не компрессированный формат) размера 1.44/2.88 МБ.
Так, можно запастись некоторым количеством образов дискет полезных программ и загружать их через соответствующие пункты меню - это могут быть утилиты по работе с разделами, по работе с HDD, разного рода тестовые утилиты проверки компонент системы и т.д.
Если нет готовых образов, то их можно создать при наличии определенных программ. Зачастую бывает так, что размер необходимой программы оказывается больше 1.44МБ и даже 2.88МБ. Кроме того, для экономии места можно объединять несколько утилит, не требующих персональной загрузки, в одном образе. В этом случае необходимо пользоваться утилитой по созданию электронного диска (виртуально созданный логический раздел определенного размера за счет использования части верхней памяти общего объема системного ОЗУ) и каким-нибудь консольным архиватором.
Ниже будет приведен пример создания образа дискеты основе MS DOS/PC DOS с использованием архиваторов RAR и ACE. Последняя версия RAR, работающего под DOS - 2.50. Последняя версия ACE работающего под DOS - 2.04. В случае RAR используется штатный модуль распаковки UNRAR.EXE, так как эта версия не способна создавать самораспаковывающийся архив (SFX-модуль) - в отличие от RAR, консольный архиватор ACE умеет создавать SFX-архивы. Рассматривается два архиватора потому, что каждый из них сжимает что-то лучше, а что-то хуже, и в конечном итоге необходим индивидуальный подход.
Например, реально удалось создать загрузочную дискету на 1.44МБ, куда совершенно легко уместился полный комплект утилит DAO16 - CDROM DISC-AT-ONCE RECORDING PROGRAM от Golden Hawk Technology общим объемом почти в 7МБ, которые с легкостью сжались в SFX-ACE архив до 595Кб (максимальная степень сжатия, версия компрессии 2.0, непрерывный архив, 4096КБ размер тома). При этом на дискету также уместились драйвера инициализации всех типов CDROM и USB-устройств.
Для облегчения работы создается загрузочный диск один раз, после чего, вооружившись программой WinImage, образы можно «штамповать» по образу и подобию. Выбор ОС зависит от конкретного содержимого диска: если это утилита для тестирования или просто необходимо выполнение банальной загрузки, рекомендуется PC DOS, если дальнейшая работа связана непосредственно с разделами, то тогда, вероятно, MS DOS 6.xx/7.xx. Не последним аргументом является и объем, занимаемый системными файлами на дискете - в общем, это уже скорее индивидуальный подход. После того, как создан загрузочный диск, можно смело удалять все, кроме трех системных файлов: COMMAND.COM, IO.SYS и MSDOS.SYS.
Вот пример-схема (в этом разделе не рассматривается подробный процесс создания образа какой-то конкретной загрузочной дискеты) содержимого конечного образа дискеты со сценарием выполнения разархивации RAR-архива на создаваемый электронный диск:
AUTOEXEC.BAT
[RAR-ARCHIVE].RAR
COMMAND.COM
CONFIG.SYS
HIMEM.SYS
IO.SYS
MSDOS.SYS
UNRAR.EXE
XMSDSK.EXE
Здесь XMSDSK.EXE - это программа создания электронного диска, XMSDSK: adjustable XMS RAMdisk, Franck UBERTO 38000 Grenoble - FRANCE. Разумеется, можно использовать любую другую утилиту по созданию электронного диска - скажем, тот же RAMDRIVE.SYS из комплекта MS DOS.
Содержимое файла CONFIG.SYS обычно типично, если нет необходимости грузить какие-нибудь менеджеры памяти (EMM/QEMM), драйвера устройств (например, CD/DVD-ROM, USB...) и т.д.
Несравненно больший интерес представляет сценарий выполнения AUTOEXEC.BAT. Вот шаблон для настоящей дискеты. Понятно, что размер создаваемого электронного диска [EDSKSIZE] и буква, назначенная электронному диску [EDRVLTR], могут быть любые (размер указывают немногим более чем исходный объем файлов в архиве - обычно 4096 в большинстве случаев хватает с избытком):
- начало AUTOEXEC.BAT -
SET RAMDRIVE=[EDRVLTR]
XMSDSK [EDSKSIZE] [EDRVLTR]: /y
SET TEMP=%RAMDRIVE%:\
SET TMP=%RAMDRIVE%:\
COPY A:\UNRAR.EXE [EDRVLTR]:\
[EDRVLTR]:
UNRAR x A:\[RAR-ARCHIVE].RAR [EDRVLTR]:\
[далее уже следуют сценарии, которые необходимо автоматически выполнить после того, как архив с содержимым распакован на диск]
...
- конец AUTOEXEC.BAT -
Теперь рассмотрим пример содержимого конечного образа дискеты со сценарием выполнения разархивации содержимого самораспаковывающегося ACE-архива на создаваемый электронный диск:
AUTOEXEC.BAT
[ACE-SFX].EXE
COMMAND.COM
CONFIG.SYS
HIMEM.SYS
IO.SYS
MSDOS.SYS
XMSDSK.EXE
С файлом CONFIG.SYS все ясно. В шаблоне AUTOEXEC.BAT изменения будут только в одной строке:
- начало AUTOEXEC.BAT -
SET RAMDRIVE=[EDRVLTR]
XMSDSK [EDSKSIZE] [EDRVLTR]: /y
SET TEMP=%RAMDRIVE%:\
SET TMP=%RAMDRIVE%:\
A:\[ACE-SFX].EXE x [EDRVLTR]:\
[далее уже следуют сценарии, которые необходимо автоматически выполнить после того, как архив с содержимым распакован на диск]
...
- конец AUTOEXEC.BAT -
Отдельно хочется обратить внимание на то, что при создании архива в его «корневой каталог» следует помещать копию командного интерпретатора (COMMAND.COM) используемой в образе дискеты ОС. Или его можно просто копировать с системной дискеты в корневой каталог электронного диска - тогда необходимо в файле AUTOEXEC.BAT добавить строку COPY A:\ COMMAND.COM [EDRVLTR]:\, после строки создания самого электронного диска, разумеется. Иными словами, присутствие на электронном диске командного интерпретатора необходимо, и как он туда попадает - дело индивидуального подхода, и два возможных варианта были рассмотрены.
Файл конфигурации меню проекта
Файл \BSCRIPT\BSCRIPT.INI является файлом загрузочного меню - тут задаются сценарии загрузки, иерархия меню, оформление и многое другое. По сути, его структура является своего рода гибридом содержимого файлов CONFIG.SYS и AUTOEXEC.BAT обычного DOS - разница в используемых командах и формате записей.
Типичная структура BSCRIPT.INI может быть представлена следующей схемой (комментарии к конкретному событию будут строкой выше через #):
# Процедура очистки экрана. Обязательно указывается в начале
# каждого отдельного раздела меню.
cls
# Задание цвета секции. Действует от момента задания и до следующего
# задания color [COLORCODE].
# Коды соответствия цветов можно взять в документации Boot Scriptor.
color [COLORCODE]
# Вывод текстовой информации. Здесь описывается сам текст меню.
# Если необходимо вставить пустую строку-разделитель, то задается
# без текста: print "\n" .
print "[TEXT]\n"
# Таймер ожидания события в секундах [TIMESEC] и выполнение события [KEY]
# по истечению указанного времени.
# То есть, вместо [TIMESEC] указывается, сколько секунд необходимо ждать
# нажатия определенной клавиши, и если
# по истечению этого времени ни одна клавиша не была нажата, то автоматически
# выполняется нажатие заданной в строке клавиши [KEY].
getkey [TIMESEC] setkey [KEY]
# Описание перехода по событию в определенную секцию. То есть, при нажатии
# определенной клавиши [KEY] осуществляется переход к определенной секции
# меню [SECTION], которая описана ниже.
onkey [KEY] goto [SECTION]
# Описание загрузки по событию. То есть, при нажатии определенной клавиши [KEY]
# выполняется загрузка с определенного устройства, имеющего уникальный код
# [BOOTCODE]. Список соответствия устройствам кода можно узнать в документации
# Boot Scriptor. Например, код 0x00 соответствует НГМД (флоппи-дисководу),
# а 0x80 - первому загрузочному разделу НЖМД (винчестер).
onkey [KEY] boot [BOOTCODE]
# Начало описания секции меню.
[SECTION]:
# Обязательная очистка экрана.
cls
# Описание выполнения по событию [KEY] запуска эмуляции (memdisk) образа
# [IMAGE].IMG. То есть, при нажатии определенной клавиши [KEY] выполняется
# запуск модуля эмуляции виртуального диска (memdisk), который выполняет
# программу развертывания определенного образа [IMAGE].IMG.
onkey [KEY] memdisk [IMAGE].IMG
# Начало описания секции меню.
[SECTION]:
# Переход в определенный каталог. В данном случае - корневой.
cd \
# Выполнение запуска загрузочного сектора второго уровня. То есть, внутренняя
# команда chain выполняет последовательность загрузки boot-сектора
# [BOOTLOADER[XXXX]].DAT, который был скопирован, переименован.
chain [BOOTLOADER[XXXX]].DAT
Например, вот таким может быть меню нашего проекта (самый простой вариант):
--- начало BSCRIPT.INI ---
cls
color 0x09
print "\n"
print "\n"
print "Microsoft Windows 2000/XP System Installation\n"
print "\n"
print "\n"
print "1) Install Windows 2000 Professional, SP4, Rus\n"
print "2) Unattended Install Windows 2000 Professional, SP4, Rus\n"
print "\n"
print "3) Install Windows XP Professional, SP2, Rus\n"
print "4) Unattended Install Windows XP Professional, SP2, Rus\n"
print "\n"
print "\n"
print "5) NT Password Admin\n"
print "\n"
color 0x05
print "b) Wariable Boot Operation Systems\n"
print "\n"
color 0x0F
print "a) Boot to Floppy Drive A:\ (0x00)\n"
color 0x0E
print "\n"
print "Esc) Boot to first hard drive (0x80) [Default]\n"
print "\n"
color 0x0B
print "Choose one: \n"
color 0x0F
getkey 30 setkey esc
onkey 1 goto w2kp
onkey 2 goto w2ku
onkey 3 goto xppc
onkey 4 goto xppu
onkey 5 memdisk ntadmin.img
onkey a boot 0x00
onkey b goto boot
onkey esc boot 0x80
getkey
boot:
cls
color 0x09
print "\n"
print "\n"
print "Wariable Boot Operation Systems\n"
print "\n"
print "1) Microsoft DOS 6.22\n"
print "2) IBM PC-DOS 7.0\n"
print "3) Windows 98 4.10.2222\n"
print "4) Windows 98 + NTFSPro\n"
print "5) GNU-Linux\n"
print "\n"
color 0x0F
print "x) Boot to Floppy Drive A:\ (0x00)\n"
color 0x0E
print "\n"
print "Esc) Boot to first hard drive (0x80) [Default]\n"
print "\n"
color 0x0B
print "Choose one: \n"
color 0x0F
getkey 30 setkey esc
onkey 1 memdisk boot_msd.img
onkey 2 memdisk boot_pcd.img
onkey 3 memdisk w98.img
onkey 4 memdisk w98_ntfs.img
onkey 5 memdisk gnulinux.img
onkey x boot 0x00
onkey esc boot 0x80
w2kp:
cd \
chain W2KP.DAT
getkey
goto exit
w2ku:
cd \
chain W2KU.DAT
getkey
goto exit
xppc:
cd \
chain XPPC.DAT
getkey
goto exit
xppu:
cd \
chain XPPU.DAT
getkey
goto exit
exit:
end
--- конец BSCRIPT.INI ---
Думается, что нет смысла специально что-то описывать и комментировать - содержимое этого файла просто и понятно с учетом небольшого описания выше схемы и назначения ключевых вызовов.
Стартовое меню может представляться как в тексте, так и в полной графике (исходным материалом является BMP-формат, конвертируемый специальной утилитой Boot Scriptor Image conversion utility), однако, даже в тексте можно задавать довольно красивый интерфейс. Оформление меню в графике - это довольно трудоёмкая процедура. Примеры оформления меню можно посмотреть на сайте Boot Scriptor.
Создание образа проекта
После того, как все образы дискет созданы и проверены на работоспособность (ее лучше проверять в целях экономии времени на какой-нибудь виртуальной машине: Connetix/Microsoft Virtual PC или VMware), и файл BSCRIPT.INI полностью отредактирован, необходимо скопировать все файлы образов дискет *.IMG и BSCRIPT.INI в каталог \BSCRIPT\ проекта.
Таким образом, финальная структура нашего «модернизированного» проекта будет следующей:
\
\BSCRIPT\
\BSCRIPT\BSCRIPT.INI
\BSCRIPT\[IMAGES].IMG
\ROOT\W2KP\I386\
\ROOT\W2KP\
\ROOT\XPPC\I386\
\ROOT\XPPC\
\W2KP\SYSTEM32\
\W2KP\
\W2KU\SYSTEM32\
\W2KU\
\W2KU\WINNT.SIF
\XPPC\SYSTEM32\
\XPPC\
\XPPU\SYSTEM32\
\XPPU\
\XPPU\WINNT.SIF
BOOTFNTW.BIN
BOOTFNTX.BIN
W2KP.DAT
W2KU.DAT
XPPC.DAT
XPPU.DAT
CDROM_IP.5
CDROM_NT.5
CDROMSP4.TST
WIN51
WIN51IP
WIN51IP.SP2
Теперь, когда все исходные данные для нового диска готовы, необходимо сделать образ проекта. Для этого можно использовать любую программу/утилиту для создания образов загрузочных дисков: например, CDIMAGE CD-ROM and DVD-ROM Premastering Utility от Microsoft или UltraISO от EZB Systems.
CDIMAGE CD-ROM and DVD-ROM Premastering Utility от Microsoft - это очень компактная, мощная и правильная утилита, работающая в режиме командной строки под Windows NT-based ОС (с Windows 9x/Me не совместима). Формат командной строки для создания образа в общем виде можно использовать следующий:
CDIMAGE.EXE -l[метка_диска] -b[\путь_к_файлу_загрузчика\][loader.bin] -h -n -m -oi -x -e [\путь_к_папке_c_исходными_файлами_проекта\] [\путь_к_конечному_образу\][имя_образа].iso
Если возникла необходимость поэкспериментировать с опциями, то вот их полный список:
-l - метка тома без пробелов (то есть -lMYLABEL).
-t - временная метка для всех файлов и папок без пробелов, с любым разделителем (то есть -t12/31/2000,15:01:00).
-g - кодировать всемирное время вместо локального.
-h - включить скрытые файлы и папки.
-n - разрешить длинные имена файлов (длиннее стандартных DOS 8.3 имён).
-nt - разрешить длинные имена, совместимые с NT 3.51 (ключи -nt и -d нельзя использовать вместе).
-d - не переводить имена нижнего регистра в верхний.
-c - использовать имена ANSI вместо OEM из источника.
-j1 - включить имена Joliet Unicode, а также создать DOS 8.3 совместимые имена в пространстве имён ISO-9660 (могут быть прочитаны либо по таблице Joliet, либо по таблице ISO-9660, но некоторые из имён в формате ISO-9660 могут быть изменены для соответствия ограничениям DOS 8.3 и/или ISO-9660).
-j2 - включить имена Joliet Unicode без стандартных ISO-9660 имён (требуется операционная система Joliet для чтения файлов с CD) При использовании ключей.
-j1 - или -j2, ключи -n, -nt, и -d неприменимы и не могут быть использованы.
-js - файл "readme.txt" в пространстве не-Joliet для образов, созданных с ключом.
-j2 - (то есть -jsc:\location\readme.txt). Этот файл будет видим как единственный файл в корне диска на системах, не поддерживающих формат Joliet (Windows 3.1, NT 3.x, и др.).
-u1 - включить имена "UDF-Bridge".
-u2 - включить файловую систему "UDF" без зеркальной системы ISO-9660 (подразумевает UDF-совместимую операционную систему для чтения этих файлов).
-ur - не-UDF "readme.txt" файл для образов, созданных с ключом -u2 (то есть -usc:\location\readme.txt). Этот файл будет видим как единственный файл в корне диска на системах, не поддерживающих формат UDF.
-us - разредить файлы UDF.
-ue - включить данные файла в расширенные свойства UDF.
-uf - включить свойства UDF FID.
-uv - обеспечить совместимость видеозон UDF Video Zone.
-b - "El Torito" файл с загрузочным сектором без пробелов (то есть -bc:\location\cdboot.bin).
-p - ID платформы для загрузочного каталога "El Torito".
-e - Не ставить режим эмуляции флоппи в каталоге загрузки El Torito.
-s - подписать файл образа электронной подписью (без пробелов, указать RPC-сервер и конечное имя, например - sServerName:EndPointName).
-x - вычислить и создать значения "AutoCRC" в образе.
-o - оптимизировать место однократным включением повторяющихся файлов(ключи -o можно комбинировать, например, -ocis):
-oc - медленное вычисление дубликатов с использованием бинарного сравнения вместо значений хэшей MD5;
-oi - игнорировать точное совпадение времени при сравнении файлов;
-os - показать дубликаты при создании образа.
-w - уровень предупреждений с числом (то есть -w4):
-w1 - сообщать о несовместимых именах или вложенности ISO или Joliet;
-w2 - сообщать о несовместимых с DOS именах;
-w3 - сообщать о пустых файлах;
-w4 - сообщать имя каждого файла, помещённого в образ.
-y - тестовый ключ с последующим числом (то есть -y1), используемый для создания нестандартных вариантов ISO-9660 для тестирования:
-y1 - включать замыкающий номер версии ';1' в именах файлов (7.5.1);
-y2 - округлять размер папок до кратного 2K (6.8.1.3);
-y5 - записывать папку \i386 в первую очередь, в обратном порядке сортировки;
-y6 - выровнять границы записей папок точно по концам секторов (ISO-9660 6.8.1.1 совместимо, но не понимает MSCDEX);
-y7 - предупреждать о создании коротких имён для 16-битных приложений под NT 4.0;
-yb - размер блока в 512 байт вместо 2048 байт;
-yd - подавить предупреждения о неодинаковых файлов;
-yс - совпадающими первыми 64K;
-yl - UDF - длинные объявления в файловых входах вместо коротких;
-yr - UDF - номер объявления случаен;
-yw - открыть файлы источника с доступом для записи;
-yt - сегмент загрузки в шестн. для El Torito образа загрузки (т.е. -yt7C0);
-yf - использовать более быстрый метод создания коротких имён.
-k - (keep) создать образ, даже если не удаётся открыть некоторые из файлов источника.
-m - игнорировать максимальный размер образа в 681,984,000 байт.
-a - итог размещения показывает размер файлов и папок.
-q - только сканировать источник, не создавать файл образа.
Внимание! Некоторые замечания и ограничения при использовании CDIMAGE:
- НЕ указывайте в качестве пути к конечному образу папку с исходными файлами проекта! То есть, конечный ISO-образ проекта НЕ должен создаваться внутри структуры каталогов проекта!
- НЕ запускайте выполнение компиляции образа с папки проекта! То есть, запускаемая на выполнение утилита CDIMAGE.EXE не должна располагаться внутри структуры каталогов проекта!
- НЕ указывайте в качестве пути к загрузчику проекта путь к загрузчику, находящемуся в папке \BSCRIPT\ проекта! То есть, файл LOADER.BIN, который используется в качестве загрузчика в командной строке CDIMAGE, не должен располагаться внутри структуры каталогов проекта!
- Свободного места на диске, куда создается конечный ISO-образ, необходимо как минимум столько же, сколько занимает исходный материал самого проекта!
- При превышении суммарного не упакованного размера проекта свыше 4 Гигабайт образ необходимо собирать на NTFS-разделе ввиду ограничений максимального размера файла в FAT32. К сожалению, в CDIMAGE не введена процедура завершения приложения по факту превышения допустимого размера - программа с самого начала устанавливает жесткое условие.
Как говорилось выше, пусть наш проект находится на диске C:\ в каталоге \PROJECT\ (полный путь - C:\PROJECT\). Таким образом, с учетом полного пути получили следующую структуру каталогов проекта (отразим только ключевые моменты):
C:\PROJECT\BSCRIPT\
C:\PROJECT\ROOT\
C:\PROJECT\W2KP\
C:\PROJECT\W2KU\
C:\PROJECT\XPPC\
C:\PROJECT\XPPU\
C:\PROJECT\BOOTFNTW.BIN
C:\PROJECT\BOOTFNTX.BIN
C:\PROJECT\W2KP.DAT
C:\PROJECT\W2KU.DAT
C:\PROJECT\XPPC.DAT
C:\PROJECT\XPPU.DAT
Файлы CDIMAGE.EXE и LOADER.BIN, как указано выше, необходимо скопировать из папки проекта в другое место - допустим, в корневой каталог диска C:\ . Конечный образ проекта будет создаваться, допустим, на этот же диск, в корневой каталог с именем WIN2KXP.ISO. В качестве "косметических" целей зададим метку диска "WIN2KXP". Таким образом, полная командная строка будет выглядеть так:
C:\CDIMAGE.EXE -lWIN2KXP -bC:\LOADER.BIN -h -n -m -oi -x -e C:\PROJECT\ C:\WIN2KXP.ISO
При создании образа при помощи UltraISO все просто и понятно - программа имеет дружественный графический интерфейс, прекрасно работает, в частности, под Windows 9x/Me и не имеет последних двух ограничений, указанных выше для CDIMAGE. Необходимо только не забыть включить оптимизацию (аналогично действию опции -o у CDIMAGE) в разделе File => Properties => Optimize, и загрузить файловую копию загрузочного сектора Boot Script (LOADER.BIN) через меню Bootable => Load Boot File...
Наконец, когда ISO-образ создан и его размер способен уместиться на удобный вам носитель, можно создавать загрузочный диск - программ для этого существует великое множество: Nero Burning ROM от Ahead Software AG, Easy Media CD Creator от Roxio, DiscJuggler от Padus и т.д.
Вместо заключения
В качестве заключительных штрихов необходимо отметить несколько моментов оптимизации конечного объема образа проекта. Так, опция -o у CDIMAGE и Optimize у UltraISO дает возможность физически разместить повторяющиеся одинаковые по размеру и содержанию файлы всего один раз, а последующие - с использованием только своего рода «таблицы ссылок», которая практически не занимает места. Таким образом, можно создать (и создают) диски, например, с полным семейством определенной ОС, у которых большинство файлов полностью идентично и разница между «родственными» редакциями обычно в пределах 10-20 МБ. Например, так и создаются наборы «N-in-1», где, размещая в проекте, например, все семейство Windows XP (Home, Professional, TabletPC и Media Center Edition с OEM, Retail и Corporate вариантами лицензирования) общим объемом проекта более ШЕСТИ ГИГАБайт, в итоге получается один стандартный CD объемом до 700МБ после оптимизации. То есть, при полном размере дистрибутива Windows XP в районе 520МБ разница между редакциями в сумме набирается не более 100-150 МБ - остальной полностью идентичный контент «поглощается» оптимизацией. Как можно догадаться, используемые в проекте копии и копии копий консоли восстановления тоже являются прямым повторением существующих файлов в дистрибутиве, что также благополучно оптимизируется.
Однако другое дело, когда в проекте принимают участие не родственные ОС - в таком случае вероятность использования повторяющихся файлов фактически мизерная (за исключением копий консоли восстановления) - обычно не более 1-2 %. Поэтому выходом для возможности размещения на одном диске описываемого в примере проекта, содержащего дистрибутивы Windows 2000 и Windows XP, как это не печально, является физическое урезание содержимого дистрибутивов. Так, в установке операционной системы играет роль исключительно папка \I386\ - остальное с чистой совестью можно удалить, однако, это даст не очень большую экономию места. Гораздо большего можно добиться, удалив подкаталоги \LANG\ (поддержка отображения экзотических южных и восточных языков) и \WIN9XMIG\ (возможность миграции с Windows 9x/Me) папки \I386\ - как показывает практика, эти моменты используются крайне редко. А вот на первый взгляд «подозрительные» подкаталоги \COMPDATA\, \WIN9XUPG\ и \WINNTUPG\ крайне рекомендуется оставить: в процессе установки их содержимое не используется, зато без них невозможно установить в системе консоль восстановления (кстати, за факт успешного выполнения WINNT32.EXE /CMDCONS отвечает поддиректория \COMPDATA\ - причем, не просто ее наличие, а фактическое содержимое - никогда бы не подумал, что каталог с самыми обычными типичными текстовыми файлами «Сведений о совместимости» может играть такую роль), да и суммарный объем их обычно составляет чуть более 6МБ. Лишним, думается, упоминать, что подкаталоги \ASMS\ и \DRW\ трогать ни в коем случае нельзя!
При таком сокращении содержимого дистрибутивов в конечном итоге создается экономия около 110-120 МБ в стандартном 700МБ образе, которые можно использовать для добавления в проект Windows 95 и даже Windows 98, что иногда бывают актуально. Если же проект ориентирован на 800МБ CD- или же на DVD-диск, то нехватка свободного места перестает быть сдерживающим фактором.
Поскольку оригинальный инсталляционный диск с Windows 9x не имеет собственного загрузчика, то необходимо создать загрузочную дискетку под DOS или воспользоваться уже имеющимся образом - три системных файла, про которые писалось выше, плюс драйвер верхней памяти (HIMEM.SYS), устройства CD-ROM ([CDROM_DRIVER].SYS) и MSCDEX.EXE будет совершенно достаточно.
Далее необходимо составить собственные CONFIG.SYS и AUTOEXEC.BAT с последовательностью инициализации CD-ROM так, чтобы драйвер MSCDEX.EXE присваивал системному устройству ([DEV_NAME]) конкретную фиксированную букву ([CDROM_LETTER]). В конечном итоге последней строкой в AUTOEXEC.BAT должен идти запуск программы установки со ссылкой на каталог с файлами дистрибутива ([DIST_CAT]). Схематически это будет выглядеть таким образом:
- начало AUTOEXEC.BAT -
MSCDEX.EXE /D:[DEV_NAME] /L:[CDROM_LETTER]
[CDROM_LETTER]:\[PATH_TO_WIN9X_DIST_CAT]\SETUP.EXE
- конец AUTOEXEC.BAT -
Если имеется несколько вариантов запуска установки с разного рода автоматизацией (файлы [BATCH_FILE].INF сценария пакетной установки, создаваемые при помощи программы Batch 98, идущей в комплекте с дистрибутивом), или в проекте имеется Windows 95 и Windows 98, то тогда на основе CONFIG.SYS и AUTOEXEC.BAT необходимо создать сложное меню загрузки, каждый пункт которого в конечном итоге будет отличаться одной-единственной строкой запуска сценария установки AUTOEXEC.BAT. Например, для запуска пакетной установки это будет выглядеть следующим образом:
[CDROM_LETTER]:\[PATH_TO_WIN9X_DIST_CAT]\SETUP.EXE [BATCH_FILE].INF
При данном формате запуска INF-файлы пакетной установки должны находится в каталоге с дистрибутивом Windows 9x. В противном случае необходимо будет указывать полный абсолютный путь к файлу сценария:
[CDROM_LETTER]:\[PATH_TO_WIN9X_DIST_CAT]\SETUP.EXE [DRIVE_LETTER]:\[PATH_TO_BATCH_FILE] \[BATCH_FILE].INF
Примеры простого и сложного меню DOS, а также файла пакетной установки прилагаются.
Внимание! По умолчанию программа установки ищет сразу при запуске пакетный файл с именем MSBATCH.INF. Таким образом, если MSBATCH.INF будет находиться в каталоге дистрибутива, то даже без указания его использования программа установки будет принимать указанные в нем значения. Чтобы избежать этого необходимо или изменить имя файла на любое другое, или переместить MSBATCH.INF в другой каталог, а в строке запуска сценария указывать абсолютный путь, как было продемонстрировано выше.
