» Windows Preinstallation Environment(WinPE) и BartPE LiveCD 5

Да. Я выбирал и "ACPI мультипроцессорный ПК" и "Мультипроцессорный MPS".
Грузятся оба, а Диспетчер Задач так и показывает одно ядро.

m0nty2k5 Использую для поддержки ACPI Multiprocessor PC плагин http://narod.ru/disk/2056155000/0-mp.inf.html показывает все доступные ядра в Диспетчере задач, (на DualXeon наблюдал восемь), скорость упаковки WinRAR возрастает процентов на 20-30, сбоев на современных платах с ACPI не наблюдал под Intel/AMD, не грузится либо падает в синий экран на AT платформах и древних платах.
Если не получиться скачать [more=здесь ссылка] http://forum.ru-board.com/topic.cgi?forum=62&topic=14026&start=632&limit=1&m=1#1 [/more] на плагин в явном виде. Загружаем проект без входа в меню по F6, F5

Впервые встречаюсь с такой ошибкой, (перед загрузкой рам-диска), да еще и из созданного самим ramboot.exe iso-образа. И реал-машина и VMware. Ничего радикально не менял по ср. с предыдущим рабочим вариантом, только в кастом-конфиг ярлычки и квик-ланч. Она же но в виде mini-nt работает.

(3.5Кб)
Чтобы это значало?

7sh3
почему не работают иконки хардов? В винде работает.

Цитата:

[Software.AddReg]
0x1,"Microsoft\Windows\CurrentVersion\Explorer\DriveIcons\X\DefaultIcon",,"X:\I386\X.ico,0"
0x1,"Microsoft\Windows\CurrentVersion\Explorer\DriveIcons\B\DefaultIcon",,"X:\I386\B.ico,0"
0x1,"Microsoft\Windows\CurrentVersion\Explorer\DriveIcons\C\DefaultIcon",,"C:\1.ico,0"

yurkesha
я добавил в сборку, появилось это меню

Цитата:

Setup could not determine the type of computer you have, or you have
chosen to manually specify the computer type.
Select the computer type from the following list, or select "Other"
if you have a device support disk provided by your computer manufacturer.
To scroll through the menu items press up arrow or down arrow.
________________________________________________________
| ACPI oднoпpoцeccopный ПK
| Koмпьютep c интepфейсом ACPI
| Compaq SystemPro Multiprocessor или 100% совместимые
| 0днoпpoцeccopный MPS
| Mультипpoцeccopный MPS
| Стандартный компьютер
| Стандартный компьютер c пpoцeccopoм C-Step i486
| Other
|_______________________________________________________|
ENTER=Select F3 =Exit

попробовал варианты:
Koмпьютep c интepфейсом ACPI
Compaq SystemPro Multiprocessor или 100% совместимые
Mультипpoцeccopный MPS
... ни в одном из случаев не заработали два ядра. Смотрел в диспетчере задач, на вкладке "Быстродействие". Попробовал вариант Other, но к сожалению у меня нет дисковода A, который он просил.

Гм, причина ошибки банальна - нехватка памяти, и грустная - у меня на хосте глюкнул второй модуль памяти, а я и не заметил... Больше он не видится в биосе, и соседний пустой слот / протирка контактов не помогает, придется в сервис или новый

AZJIO
плаг который предложил использовать nat27 неуниверсален... Нормально он работает только на многопроцессорных машинах.
Проблема в том что ядро и hal должны быть синхронны - то есть для многопроцессорного ядра надо использовать многопроцессорный hal.
Чтобы "обойти" эту проблему cdob поступил радикально - убрал описания стандартных и юнипроцессорных однопроцессорных hal-ов... Вот и имеем результат...

Добрый вечер. Подскажите пожалуйста где можно скачать антивирь с монитором. Например NOD32 (нужен только AMON). Спасибо.

yurkesha
Кстати, я его только что проверил, работает, а что не универсален ясно.

---

Так как в LiveCD всё таки есть неудаляемые файлы, например "C:\Windows\system32\Macromed\Flash\FlashUtil9f.exe", возможно и с файлами висты будут те же проблемы, а давать доступ к тысяче файлам тоже делается не в секунду, то вот прога Mst.TotalAccess.Disk.PRO, переделанная в плагин. пароль ru-board.

yurkesha
А такой вариант возможен:
инф от cdob оставить, но в сборку включить все халы, а при загрузки по F5 был бы выбор для однопроцессорных компов... проверять уже некогда, спать уже некогда... на работу...

Насколько я понял, они и так оттуда не удаляются и все включены, однако вследствии того что перманентно используется мультипроцессорное ядро и для мульти- и для одно-процессорных систем (@SourcePath@I386\ntkrnlmp.exe=2,NTOSKRNL.EXE) - необходимо чтоб не был загружен однопроцессорный хал, и инфа о их загрузке для однопроцессорных систем убрана ([DelLine]), о чем и написал yurkesha
yurkesha
Т.е. на однопроцессорных тоже грузится мульти как ядро, так и хал?

jCHex
проблема не в том что используется неродное ядро и hal - проблема в том что в этой ситуации происходит зависание либо ребут...
Ходят слухи(щас проверяю) что может помочь подмена setupldr.bin на аналогичный файл из комплекта WINXP SP1 либо WIN2003 без SP... Предполагается что при их использовании стартует нужное ядро а не ntoskrnl.exe... Но насколько я помню с подменой были какие-то проблемы...

Понял.
Ага, про те setupldr.bin даже cdob в плаге написал, правда 2003 SP1:
;XP and 2003 SP1 setupldr.bin loads file ntkrnlmp.exe

Ну, если не ошибаюсь, способ поуниверсальней без использования чужого setupldr.bin все же есть. Например с мультизагрузкой из BCDW - однако выбор вручную Но можно конечно поставить и таймер на наболее нужную/частую.
[more]Мультизагрузка в BCDW с выбором WinXPE Uniprocessor / Multiprocessor
В BCDW.INI два пункта:
\I386\SETUPLDR.BIN ; Windows XPE однопроцессорная
\I386\SETUPMDR.BIN ; Windows XPE мультипроцессорная
Собираем без плага, но с:
[SourceDisksFiles]
hal.inf=20
hal.dll=2
halaacpi.dll=2
halacpi.dll=2
halapic.dll=2
halmacpi.dll=2
halmps.dll=2
ntkrnlmp.exe=2
ntkrnlpa.exe=2
ntkrpamp.exe=2
ntoskrnl.exe=2
[SourceDisksFiles.2600]
halsp.dll=2

Затем копируем SETUPLDR.BIN в SETUPMDR.BIN, TXTSETUP.SIF в MXTSETUP.SIF
В SETUPMDR.BIN заменяем (напр. в WinHex) все ntoskrnl.exe на ntkrnlmp.exe , все txtsetup.sif на mxtsetup.sif
В MXTSETUP.SIF заменяем в секции [Hal.Load] строки:
mps_up = halapic.dll
mps_mp = halapic.dll
syspro_mp = hal.dll
acpiapic_mp = halaacpi.dll
acpiapic_up = halaacpi.dll
на
mps_up = halmps.dll
mps_mp = halmps.dll
syspro_mp = halsp.dll
acpiapic_mp = halmacpi.dll
acpiapic_up = halmacpi.dll

А строки
486c_up = hal.dll
acpipic_up = halacpi.dll
e_isa_up = hal.dll
удаляем.

Это лишь пример. То, что для варианта мульти - тоже самое делает плаг. Т.о. если будет запущен ошибочный выбор - ошибочного сочетания мультиядро+одно-хал не будет, хоть что-то...

Добавлено:
* Возможно, помимо того потребуется еще и заменить в SETUPMDR.BIN строку \i386\SETUPLDR на \i386\SETUPMDR , и строку \i386\setupldr.pdb на \i386\setupmdr.pdb

Разовьем идею дальше Если используется рам-сборка, то действия аналогичны:
1) BCDW сажаем разумеется снаружи рам-бута, в корень диска.
2) Остальные изменения производим внутри сборки до собирания ramboot, за исключением SETUPMDR.BIN - его делаем из того SETUPLDR.BIN, который рядом с Boot.img, ложим тоже рядом.

Однако, могут оказаться необходимыми эти [*] изменения для рам-сборки.

И не забываем про путь i386 - если для рам используется иной (напр. r386) - соотв. меняем на него а) в BCDW и б) в SETUPLDR.BIN и SETUPMDR.BIN рядом с Boot.img (для r386 готовый вариант есть в конструкторе)[/more]
Но хочется ж автоматом... Мед всегда слаще из бочки

nat27
Разумеется, ничто не мешает. Но зачем для универсального диска/usb вешать два проекта, если достаточно например того что я описал с одним
-
Весь этот способ - лишь предположение, надо проверять, сейчас нет под рукой мультиядерника.

При использовании плагина от cdob грузится мульти ядро и хал, универсальности нет, но большинство компьютеров сейчас содержат процессора с двумя и более ядрами. На одноядерных (селерон, семпрон) процессорах использование мульти ядра и хала обычно проблем не вызывает(могу отметить единичные случаи сбоев - когда оборудованию более 3-4 лет). Как правило, заранее известно каким процессором оборудован компьютер. Что мешает подготовить два проекта, один Uniprocessor, другой Multiprocessor и грузить их по типу железа.

т.е. - таки 2е сборки?..
или я туплю?..

Skif_off
Просто раскидать файлы не поможет в XP SP2 - она видимо все равно грузит ntoskrnl.exe
То, что я описал - тоже вариант, но не проверено, зато универсально и красиво

Цитата:

и красиво

это да...

jCHex
Цитата:

Весь этот способ - лишь предположение, надо проверять

будет результат, сообщи. У меня наготове лежат разные проекты: DVD Multi / DVD Uniprocessor на каждом с помощью BCDW выбирается три варианта загрузки - c DVD\RAMBoot 1Gb ОЗУ\RAMBoot 512Mb ОЗУ + досовские утилиты для разбиения разделов и пр. необходимость(как то дрова и дистры). Для древних машин CD с обычной Uniprocessor загрузкой - ничего не мешает быстро прицепить DVD. На USB Flash 1Gb залита Minint Uniprocessor, потому как ramboot с USB долго грузиться. Да еще пара CF 2GB 266x c переходником на IDE + PromiseTX133 PCI это для быстрой (до 20-30сек.) загрузки при отладке(виртуальные машины не дают полноты картины, особенно при настройке дров) либо когда открытый комп, а обычно я их открываю. При сборке Uniprocessor в проекте ничего дополнительно не включаю, по умолчанию он такой сам собирается, а для Multiproceesor только 0-mp.inf от cdob включаю и все, проекты получаются с одним именем Boot.img вот их раскладываю по разным папкам, а дальше - тут уже не раз обсуждалось как все это организовать в BCDW.

У кого есть многоядерник проверить вот такую штучку? Плагин, и не только.
Multiprocessor support (Multiprocessor.rar, 355 Кб)
Исправлена ошибка у автозапуска bcdw_patch.cmd для ram-варианта
Попробовал собрать. Версия может быть с ошибками, хотя и перебрал все уже вроде внимательно
На моей VMware под 1ноядерным хостом не работает
К сожалению, не знаю возможностей непосредственно из плагина проводить постобработку в конктрукторе (после всех операций), поэтому отредактировал postprocessing\custom_commands.cmd. В него добавлена только проверка плагина на включен/выключен (причем если самого плагина нет - она не напишет ошибок) и запуск его постобработки.
Плагин работает почти как описанно мной выше, и выводит окошко для автопатча конфига BCDW (перед созданием iso-образа, процесс сборки приостанавливается).
Плагин предназначен только для "Базовый конструктор (26.03.2008) BartPE+XPE" (в шапке) и патченный SETUPLDR.BIN у него из русской Windows XP SP2 (англ. нет), и подразумевает наличие BCDW, либо включенным плагином, либо вручную в каталоге этого плагина.
Установка: копируем в соответствии с каталогами plugin и oem1 в архиве, с заменой custom_commands.cmd. Затем когда собираем сборку - включаем нужный вариант из двух плагинов (для обычной или ram-сборки).
Если собирается ram-сборка:
1) Для автоматического запуска патчинга конфига BCDW - копируем папку BCDW в каталог плагина, а) До запуска сборки - патч запустится сам б) После сборки - вручную запускаем bcdw_patch.cmd. Патч ничего не делает без вашего ответа.
2) После ramboot.exe добавляем ручками из соотв. папки ramboot_i386 / ramboot_r386 файл SETUPMDR.BIN в вашу i386 / r386 (в которой Boot.img).
остальные файлы в ramboot_r386 - из конструктора оригинальные для этого варианта, просто положил для удобства
Разница между вариантами плагина обычный/ram пока только в том, что для ram не копируется патченный лоадер - его менять снаружи сборки

Внимание, 1) у плага стоит жесткая привязка к имени его каталога и *.inf-ов 2) Использовал интересную программку - текстовый процессор командной строки AWK, впервые увидел и впервые писал Но учтите, она по лицензии gnu, и здесь правильно не соблюдается

Спасибо yurkesha и конечно cdob!

Если заработает - подумаю как улучшить

Вобщем в результате экспериментов подтверждено поведение setupldr.bin при загрузке в сборке на базе WinXP SP2:
winxp sp1 грузит ntkrnlmp.exe всегда
winxp sp2 грузит ntoskrnl.exe всегда
winxp sp3 грузит ntoskrnl.exe всегда
win2003 sp1 вызывает ошибку отсутствия ntldr
win2003 r2 вызывает ошибку отсутствия ntldr
Соответственно нет необходимости помещать в сборку файлы ntkrnlpa.exe и ntkrpamp.exe
Далее судя по OPK от Win2003 при сорцах win2003 setupldr.bin будет всегда загружать ntkrnlmp.exe
Остался единственный неотслеженный процесс до старта ядра - ntdetect.com - его вызов обеспечиватся через txtsetup.sif и допускает указание имени и относительного расположения этого файла(в секции [ntdetect]). Может с нм можно устроить автовыбор...
Ну а выбор нужного hal легко делается в секции [Hal.Load] - там все нормально отрабатывает...

Да, а в NTDETECT.COM дело уже посерьезней... Без патча кода (и понимания его ) не обойтись. Кто у нас умеет такое? А в ramboot.exe ув. NIKZZZZ его откуда-то брал, или сам патчил?
Да и серьезное подозрение, что конкретно с ним может не помочь, подозреваю он может не влиять на запуск ядра... Как по идее собсно и есть (детект отборудования, "is responsible for detecting basic hardware that will be required to start the operating system")
Однакож для ramboot его патчат, неспроста
Вот и вопрос: с какой целью он патчится для ramboot / для usb-pe?

yurkesha
Смотря на эти строки, при выборе mps_mp должно произойти копирование halmps.dll в hal.dll, и ntkrnlmp.exe в ntoskrnl.exe, ведь в любом случае грузится hal.dll. И почему в секциях [hal] и [Hal.Load] код mps_mp, а в [SpecialFiles] код - Multiprocessor, может поменять на mps_mp мысли вслух...

Цитата:

[hal]

486c_up = hal.dll ,2,hal.dll
acpipic_up = halacpi.dll ,2,hal.dll
e_isa_up = hal.dll ,2,hal.dll
mps_up = halapic.dll ,2,hal.dll
mps_mp = halmps.dll ,2,hal.dll
syspro_mp = halsp.dll ,2,hal.dll
acpiapic_up = halaacpi.dll,2,hal.dll
acpiapic_mp = halmacpi.dll,2,hal.dll


[Hal.Load]

486c_up = hal.dll
acpipic_up = halacpi.dll
e_isa_up = hal.dll
mps_up = halapic.dll
mps_mp = halapic.dll
syspro_mp = hal.dll
acpiapic_mp = halaacpi.dll
acpiapic_up = halaacpi.dll

[ntdetect]
486c_up = NTDETECT.COM,"\"
acpipic_up = NTDETECT.COM,"\"
e_isa_up = NTDETECT.COM,"\"
mps_up = NTDETECT.COM,"\"
mps_mp = NTDETECT.COM,"\"
standard = NTDETECT.COM,"\"
syspro_mp = NTDETECT.COM,"\"
acpiapic_mp = NTDETECT.COM,"\"
acpiapic_up = NTDETECT.COM,"\"

[SpecialFiles]
Multiprocessor = ntkrnlmp.exe,2,ntoskrnl.exe
Uniprocessor = ntoskrnl.exe,2
MPKrnlPa = ntkrpamp.exe,2,ntkrnlpa.exe
UPKrnlPa = ntkrnlpa.exe,2
mouseclass = mouclass.sys,4
keyboardclass = kbdclass.sys,4

Попробовал в секции добавить строки, но не сработало

Цитата:

[SpecialFiles]
acpiapic_mp = ntkrnlmp.exe,2,ntoskrnl.exe
syspro_mp = ntkrnlmp.exe,2,ntoskrnl.exe
mps_mp = ntkrnlmp.exe,2,ntoskrnl.exe


[Computer]
mps_mp = "Њг«мвЁЇа®жҐбб®а-л© MPS",files.ntkrnlmp.exe, halmps.dll

jCHex
Идея с TXTSETUP.SIF и SETUPLDR.BIN рабочая, а образ к сожалению нет. Проблема в NTOSKRNL.EXE, в одноядерной сборке он родной, а в двухядерной - переименованный NTKRNLMP.EXE. Если я загружался с TXTSETUP.SIF - как одноядерник, с родным NTOSKRNL.EXE, то двухядерная система останавливалась на "Плиз уайт" - пожалуйста подождите. Если загружался с переименованным NTKRNLMP.EXE в NTOSKRNL.EXE, то одноядерная система висла на процессе определения устройств HW. Соответственно вторые родные варианты естественно грузились без проблем. Файлы использовал такие:

Цитата:

SETUPLDY.BIN (SETUPLDR > SETUPLDY, TXTSETUP.SIF > TXYSETUP.SIF)
SETUPLDZ.BIN (SETUPLDR > SETUPLDZ, TXTSETUP.SIF > TXZSETUP.SIF)
TXYSETUP.SIF
TXZSETUP.SIF

грузился с харда. Можно использовать для загрузки с драйверами SCSI и без них.

AZJIO
Ну да, вот с вариантом когда для обоих платформ грузится мульти-ядро и хал - нестабильно для одноядерных. Потому и старался с плагином выбора.

Цитата:

а образ к сожалению нет

Какой образ, в каком смысле? После моего плагина? Полностью не работает, или речь о выборе в BCDW, не совпадающем с платформой?
Т.е. при совпадении платформы+выбора работает после моего плага?
А наоборот особо и не предусмотрено, т.к. делал я просто чтоб в отличие от плагина cdob оставался выбор Uni, и с другой стороны не нужна была вторая сборка. Автоматической универсальности и не ждите.
Или с плагином cdob (всё мульти-) на Вашем одноядернике работает а с моим нет? Если да - отпишите пожалуйста, значит мне исправлять плаг.
Или Вы не о моем плагине вовсе?


Цитата:

Проблема в NTOSKRNL.EXE, в одноядерной сборке он родной, а в двухядерной - переименованный NTKRNLMP.EXE

Да, я в курсе...
Забыл написать, что плагин предназначен для сборки PE по умолчанию (когда родное NTOSKRNL.EXE), т.е. если заменяли ручками ядро на другое - на одноядреном hw будет трабла.
Что Вы здесь подразумевали? Ядро само переименовывается насколько я понимаю только при установке Windows / правильной смены типа компьютера в диспетчере устройств или т.п. Но ведь это известно
"Проблема" конечно не в этом, а в следствии этого (XP SP2) - при правильно полном в этом смысле txtsetup.sif и наличии обеих ядер все равно грузится то, что с именем NTOSKRNL.EXE. А главное, что это происходит и даже при ручном выборе типа компьютера. Т.е. тот выбор влияет только на хал, так выходит. Но собсно все это нам обоим известно Я же хотел выбор ядра(+hal) добавить. Но плагин и не собирался реализовывать это автоматикой.
Жаль конечно, что XP SP2 не умеет автоматом выбирать ядро, а так жестко привязывает
Или это все-таки глюк разработчиков? который можно исправить / изменить...

Еще, Вы раньше писали в топике на эту тему, можно вопросик?

Цитата (AZJIO, 15:17 17-08-2008, [32]):
На счёт халов в теме по "Перенос системы на другую мать" много выясняли. Хал и ntoskrnl.exe должны быть в связке, но "многопроцессорное" имеет проблемы на однопроцессорных компах, универсальнее всего "компьютер с аспи", интересно для PE будет ли сборка универсальной.

jCHex

Цитата:

система грузится, однако все этапы xpelogon.exe проходят заметно медленней чем обычно, и в конце-концов после окончания всей загрузки остается тот же пустой рабочий стол (без иконок+таскбара+фона), который висит пока работает xpelogon.exe, и сам он висит в процессах (можно запустить таск-менеджер, однако все работает намного медленней обычного). Сама сборка ессно грузится все-таки рам Диск можно вытащить и лазить с таск-менеджера - работает...

такой результат можно получить если в img файле нет свободного места, т.е. когда ramboot'ом собираешь впритык, в ramboot сборке при загрузке создаются файлы на x - .pnf в inf папке и некоторые другие - надо минимум 2 мега свободного места оставлять...

7sh3
О, спасибо огромное! Я-то думал что для абсолютно всех временных файлов используется B: Хоть в img и есть метра 3 свободных, но действительно я делал впритык. Видимо на оборудовании той машины было больше этих новых файлов, попробую увеличить.
Теперь хоть буду знать вероятную причину спасибо

jCHex
образ - я имел ввиду файл рамсборки Boot.img. NTOSKRNL.EXE грузится либо для двухядерника, либо для одноядерника (какой положил тот и грузится), поэтому рабочий только один вариант. Переименование ядра не происходит, а в плагине cdob ядро (ntkrnlmp.exe) переименовывается при создании сборки конструктором в ntoskrnl.exe, там заранее мультипроцессорное ядро. Для экспериментов в сборку естественно были добавлены:
[SourceDisksFiles]
hal.inf=20
hal.dll=2
halaacpi.dll=2
halacpi.dll=2
halapic.dll=2
halmacpi.dll=2
halmps.dll=2
ntkrnlmp.exe=2
ntkrnlpa.exe=2
ntkrpamp.exe=2
ntoskrnl.exe=2
[SourceDisksFiles.2600]
halsp.dll=2

Цитата:

на Вашем одноядернике работает а с моим нет? Если да - отпишите пожалуйста, значит мне исправлять плаг.

у меня комп двухядерник, поэтому могу проверить оба варианта, способ использования переименованных TXTSETUP.SIF и SETUPLDR.BIN работает, только я не с CD,DVD пробую, а с харда, у меня в boot.ini две строки

Цитата:

C:\i2boot.bin="RAM-Boot2 (I2BOOT.BIN) 480Mb"
C:\i3boot.bin="RAM-Boot2 (I3BOOT.BIN) 480Mb"

грузят один и тот же файл - Boot480.img, но с разными загрузчиками
i2boot.bin > i2ldr > Winnt.sif > Boot480.img > SETUPLDY.BIN > TXYSETUP.SIF
i3boot.bin > i3ldr > Winnt.sif > Boot480.img > SETUPLDZ.BIN > TXZSETUP.SIF
i2ldr и i3ldr - тоже редактировал заменой текста (SETUPLDR > SETUPLDY, TXTSETUP.SIF > TXYSETUP.SIF) и (SETUPLDR > SETUPLDZ, TXTSETUP.SIF > TXZSETUP.SIF)
Повторюсь: способ переименованных TXTSETUP.SIF и SETUPLDR.BIN работает, то есть грузится переименованный TXTSETUP.SIF но проблема не решается, так как выбора ядра ntoskrnl.exe нет... грузится ntoskrnl.exe всегда... всегда тот который в сборке, единственный вариант. Нужно придумать способ переименовать его при загрузке ntkrnlmp.exe в ntoskrnl.exe.

AZJIO
Цитата:

Переименование ядра не происходит

Цитата:

но проблема не решается, так как выбора ядра ntoskrnl.exe нет... грузится ntoskrnl.exe всегда...

Так вот жеж для этого я и заменил все ntoskrnl.exe на ntkrnlmp.exe в setupmdr.bin - который для варианта загрузки Multiprocessor. Этот момент разве не помогает? Ядро-то грузится только им, никто больше ж

Добавлено:
эх, кто хотя бы взглянул бы на плаг, и сказал бы критики... а то нужно было всем, я чуть постарался, между прочим с этими скриптами мучаився - а оказалось все всё сами умеют руками
Кстати (это для тех кто руками не умеет) его можно запускать и для готовой сборки (со стандартным ntoskrnl.exe) - достаточно в его каталоге воссоздать структуру I386\TXTSETUP.SIF и BCDW\BCDW.INI (необязательный), т.е. всего два файла, и запустить multiprocessor.cmd, затем, если сборка не для ramboot - скопировать в I386 SETUPMDR.BIN, иначе копировать из ramboot_?386 в соотв. папку с Boot.img уже после ramboot.exe

Добавлено:
Хотя на вариант с hdd плагин не рассчитан, поэтому для запуска ntkrnlmp.exe наверно понадобится та же замена имени ядра в файле ntldr (i?ldr), если он грузит ядро.

Добавлено:
7sh3
Я же правильно понимаю что в рам-сборке ядро грузит таки "внешний" SETUPLDR.BIN, т.е. тот который рядом с Boot.img, руководствуясь Winnt.sif, а не "внутренний" в Boot.img?

Не надо ничего менять - я вчера в ночь поборол проблему зависания многопроцессорных ядер на однопроцессорных системах... Оформлю плаг и выложу. Универсальность есть в пределах одной сборки и даже без BCDW!

Приветствую
Подскажите как загрузить XPE от Sherpia с помощью BsLogon (PEShell), честно искал но ненашел, в виде Shell BsLogon не интересно планируется иметь две оболочки быстрая BsLogon и полная с PnP XPE.

P.S. Фаилы реестра в папке сборки так-же не освобождаются, и удалить себя не дают. После перезагрузки винды всё удаляется. Собираю на W2K3 SP2 из его-же дистрибутива, Bart последний оригинал.

jCHex
да, "внешний", от 2k3, тот что внутри от XP в принципе не нужен...

angro

Цитата:

в виде Shell BsLogon не интересно планируется иметь две оболочки быстрая BsLogon и полная с PnP XPE

по другому не загрузишь, все равно надо xpе подымать сначала, поэтому BsLogon от оболочки BsExplorer самое то, можно еще ReatogoLogon использовать а насчет быстрая BsLogon и полная с PnP XPE - все это скорости загрузки никак не прибавит, грузится будет со скоростью стандартной xpe плюс ручной выбор шелла, кстати обычный барт с nu2menu в качестве оболочки может ничем не отличатся от xpe - PnP и все дела - хоть dvd смотри - просто собирать надо не оригинальным конструктором , и с 2k3 завязывать - ничего она не дает в плане функционала по сравнению с xpsp2, проблем даже больше...

jCHex
Я проверил замену ntoskrnl.exe на ntkrnlmp.exe во внешнем SETUPLDR.BIN (i?ldr) и внутреннем, результат тот же. Можешь и сам попробовать сделать это, просто сам файл ntoskrnl.exe переименуй на ntkrnlmp.exe, а мультипроцессорный ntkrnlmp.exe на ntoskrnl.exe, если нормально запустится, то загрузчик отработал верно, если незапустится, то значит сработал родной ntoskrnl.exe, который фактически мультипроцессорный. Ждём плагин от yurkesha.