OSDev

для всех
Текущее время: 10 май 2024, 19:09

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




Начать новую тему Ответить на тему  [ Сообщений: 353 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8, 9 ... 36  След.
Автор Сообщение
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 15 фев 2012, 13:00 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1206
Yoda писал(а):
Никак не распознаю. Не дело это MBR-загрузчиков, распознавать, что именно они загрузили. Идеальный МБР должен грузить любую, в т.ч. будущую систему и не закладываться, что именно он может встретить в загрузочном секторе. А то именно от избыточного интеллекта и возникают некоторые проблемы.
Т.к. у меня MBR-загрузчик и EBR-загрузчик являются относительно независимыми модулями, у меня была задача как-то определять обнуленный код EBR (проверять обнуленность явным способом сложнее, к тому же есть и вторая задача). Т.к. сейчас основным методом передачи номера загрузочного дополнительного раздела (в случае альтернативной загрузки) из MBR в EBR является пропатчивание в памяти, нужно иметь какой-то (пусть и не сильно надежный) способ обнаружения "родного" EBR, чтобы не повредить сторонний. Я рассматривал и другой способ передачи этого параметра (без пропатчивания), но пока он не реализован (на то есть свои причины).

Цитата:
Это почему? Я нигде не нашёл явного запрета на использование расширенного раздела в качестве загрузочного. Более того, встречаются упоминания того, что потенциально он может быть загрузочным. Другое дело, что утилиты общего назначения не хотят делать его загрузочным, но это ведь не запрет.
Так дело как раз в том, чтобы существующие утилиты проглатывали наши нововведения, не ругаясь и не впадая в ступор. Кстати, я не встречал утилит, которым бы не нравилось присутствие кода EBR, более того, многие утилиты сохраняют код EBR даже в случае корректировки таблицы в самой первой по уровню вложенности EBR.

Цитата:
Как ты поступаешь с количеством скрытых секторов в загрузочном секторе расширенного раздела?
Далее, видимо, понял, но все-таки скажу - я корректирую это поле и не только его!

Цитата:
В принципе, пока нет категорической привязки к EAX. Я подумаю.
ОК, чтобы лучше думалось, немного об используемых у меня параметрах (в принципе я ссылку уже давал, где все это обсуждалось, но все же):
  • DS:SI - указатель на дескриптор загрузочного раздела.
  • DL - номер загрузочного диска.
  • DH - номер загрузочного раздела или ноль.
  • AX - значение, отличное от "!G".
  • Дескриптор загрузочного раздела.
  • Байт по адресу 7DFFh - расширенная загрузочная сигнатура 88h.
Тоже самое должен передавать EBR-загрузчик первичному загрузчику дополнительного раздела (только обязательно DH=5-255, плюс для дополнительного раздела внутри расширенного раздела типа 5 нужно корректировать поле StartLBA в дескрипторе и еще для определенных типов разделов поле HiddenSectors в BR), но т.к. мы говорили только о взаимозаменяемости MBR/EBR, то ты можешь использовать свои выходные параметры EBR.

Цитата:
Ну это совершеннейший атавизм. Т.е. предполагается, что кто-то до сих пор использует музейную XT или AT/286 и ты разрабатываешь новую ОС, которая будет работать на этом пугале прогресса? :))) Это несерьёзно.
Мои загрузчики можно использовать для любого самозагружаемого софта, в том числе работающего исключительно в RM и на древних процах (я гарантирую, что в коде загрузчиков используются инструкции только из набора i8086).

Цитата:
Пусть так. А Int 18 в данном случае чем мешает?
Не хочу пугать пользователя угрожающим сообщением BIOS (обычно выводимым после прохождения всех устройств в загрузочной цепочке).

Цитата:
Вооот, видишь - пошли искусственные ограничения :). Ещё одно не упомянутое ограничение - не загрузишься со скрытого раздела. В моей архитектуре этих ограничений нет.
Я не говорю, что твой подход плохой. Просто хочу отметить, что в каждом случае есть свои достоинства и недостатки и мой подход вполне имеет право на жизнь.
Всем бы такие искусственные ограничения, жить бы стало проще :) Скрытые разделы 1x обрабатываются, хотя винды все равно будут ругаться при загрузке с таких разделов. Не обрабатываются только разделы восстановления. Кстати мой EBR-загрузчик будет нормально обрабатывать даже некорректные значения поля HiddenSectors (испорченные левыми утилитами типа boot.exe :) ), т.к. я выполняю корректировку на основе реального местоположения раздела на диске.

Цитата:
phantom-84 писал(а):
Может, ты имел в виду, что вписываешь копию EBR-загрузчика в каждый вложенный расширенный раздел?

Да.
В цикле обрабатывать вложенные разделы не намного сложнее, а преимуществ от использования только одного экземпляра EBR-загрузчика на весь расширенный раздел много.

pavia писал(а):
Так стандартов нет, есть специфичные вещи.
OK, как раз поэтому и приходится подстраиваться под то, как себя ведут существующие системы, дисковые утилиты и т.п.

Цитата:
Если win 98 поддерживал разделы 5h 0fh, то winxp и win Vista не факт. WinXP хранит настройки на первом логическом диске. В Win Vista как раз для загрузки отвели первый раздел в несколько сот мегабайт.
pavia, или ты неправильно выразился, или владеешь недостоверной информацией. В Win2K/XP и в Windows Vista/Seven используются разные загрузчики, но они могут размещаться на любых разделах (не только первичных, но и дополнительных). А то, о чем ты говоришь, сильно смахивает на кривую разметку с "СИСТЕМНЫМ РАЗДЕЛОМ" в 100 мег, которую пытаются навязать установщики Vista/Seven и которую легко обходят вменяемые сисадмины прямо в установщике. Я обычно устанавливаю отдельный экземпляр "родного" для системы вторичного загрузчика для каждого экземпляра системы, причем на одном разделе (это относится и к линуху). А выбор запуска цепочки "первичный загрузчик - вторичный загрузчик - соответствующая система" выполняю прямо в MBR. Линуксовые загрузчики сейчас выношу из MBR в начало какого-либо раздела (если не использую их, как основные), но готовится MBR-загрузчик Alter-3, который позволит запускать их из произвольного сектора диска (пока только при альтернативной загрузке, а потом посмотрим).

Yoda писал(а):
phantom-84 писал(а):
Как раз в случае отсутствия активного раздела нужно вызывать int 18h без вывода каких-либо сообщений и ожидания.

Не согласен с отсутствием сообщений и ожидания. Предпринята попытка загрузиться с незагружаемого носителя, - пользователь должен быть уведомлён, что он не загружаем.
Т.е. нам опять наплевать на реальное положение вещей и здравый смысл! Когда нет ни одного активного раздела на текущем диске, это означает, что в соответствии с принципами BIOS (в отличии от физического диска будет трудновато убрать из загрузочной цепочки или попросту выдернуть отдельный раздел диска, поэтому в этом случае снимают его флаг активности) нужно МОЛЧА обращаться к следующему диску в загрузочной цепочке с целью поиска загрузочного раздела на нем. Я вношу коррективы в эти правила, не нарушая основных принципов:
- перехват при альтернативной загрузке, если альтернативный загрузочный раздел для данного диска определен;
- при использовании Jumbo (и в перспективе Alter-3) при отсутствии активного первичного раздела на диске выполняется поиск "активного" дополнительного раздела и только в том случае, если не найдено ни того, ни другого, управление возвращается BIOS.

Yoda писал(а):
Вообще, конечно, свинство, что изначально не предусмотрена стандартизованная передача от MBR начала раздела.
Она существует, но, как pavia верно заметил, о реальной стандартизации речи не идет, поэтому и гарантий очень мало. Моя расширенная загрузочная сигнатура гарантирует в том числе и корректность тех параметров, которые раньше было использовать слишком рискованно (поэтому их практически никто и не использовал).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 15 фев 2012, 16:41 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 970
Откуда: Дагоба
phantom-84 писал(а):
Так дело как раз в том, чтобы существующие утилиты проглатывали наши нововведения, не ругаясь и не впадая в ступор.

Так они и не ругаются. Я говорю, в данном случае нет формальных нарушений. Как пример - все версии от старых ДОСов вплоть до Win ME, консольной утилитой fdisk не сделать два основных раздела, хотя ничего противозаконного в этом нет. Точно также нет ничего противозаконного в маркировании расширенного раздела в качестве активного.

phantom-84 писал(а):
Кстати, я не встречал утилит, которым бы не нравилось присутствие кода EBR, более того, многие утилиты сохраняют код EBR даже в случае корректировки таблицы в самой первой по уровню вложенности EBR.

Вот и отличненько ). Они делают то, что разумно от них ожидать.

phantom-84 писал(а):
Далее, видимо, понял, но все-таки скажу - я корректирую это поле и не только его!

Вот! Именно это мне и не нравится. Потом, когда загрузчики начинают патчить то, что вообще говоря, не должны, тут и начинается головная боль.

phantom-84 писал(а):
Тоже самое должен передавать EBR-загрузчик первичному загрузчику дополнительного раздела (только обязательно DH=5-255

Интересно, какой номер будет в DH, если на диске два расширенных раздела и грузимся со второго?

phantom-84 писал(а):
плюс для дополнительного раздела внутри расширенного раздела типа 5 нужно корректировать поле StartLBA в дескрипторе и еще для определенных типов разделов поле HiddenSectors в BR), но т.к. мы говорили только о взаимозаменяемости MBR/EBR...

Т.е. MBR "подправит" мне пару лишних байт?... тут ни о какой взаимозаменяемости и речи быть не может )))

phantom-84 писал(а):
Мои загрузчики можно использовать для любого самозагружаемого софта, в том числе работающего исключительно в RM и на древних процах (я гарантирую, что в коде загрузчиков используются инструкции только из набора i8086).

Да конечно, пожалуйста! Я только не могу понять причины такой крайней степени аскетизма. Даже 25 МГц трёха с 8 мегабайтами симов EDO RAM - динозавр, которого в музеях не найдёшь (специально берегу одного такого!), уж не говоря про XT/AT286. Подобные действия должны иметь какую-то разумную основу, так ведь? Или просто дело принципа? Использование 32-битных инструкций даёт огромную свободу и экономию. Даже параметров можно передать в два раза больше! )

phantom-84 писал(а):
Цитата:
Пусть так. А Int 18 в данном случае чем мешает?
Не хочу пугать пользователя угрожающим сообщением BIOS (обычно выводимым после прохождения всех устройств в загрузочной цепочке).

Нууу, это не серьёзный аргумент, с таким не попрёшь против трёх корпораций )
Кстати, даже не помню, как это сообщение выглядит, до него как-то давно дело не доходило...

phantom-84 писал(а):
Кстати мой EBR-загрузчик будет нормально обрабатывать даже некорректные значения поля HiddenSectors (испорченные левыми утилитами типа boot.exe :) ), т.к. я выполняю корректировку на основе реального местоположения раздела на диске.

Не, ну хватит уже наезжать-то )
Я же говорю, HiddenSectors содержит ошибочные данные в расширенных разделах, отформатированных старыми осями, именно потому, что никто не озабочивался загрузкой с них, а ни для чего, кроме загрузки, это поле не требуется. Наступив на эти грабли, мне тоже пришлось повозиться. Более современные или правильные ОСи пишут туда корректное значение. Если утилита boot.exe по настоятельной просьбе пользователя исправляет промашку и пишет туда правильное значение на основе реального местоположения раздела на диске, то ничего плохого в этом нет.

phantom-84 писал(а):
В цикле обрабатывать вложенные разделы не намного сложнее, а преимуществ от использования только одного экземпляра EBR-загрузчика на весь расширенный раздел много.

Пока не вижу таковых.

phantom-84 писал(а):
Т.е. нам опять наплевать на реальное положение вещей и здравый смысл! Когда нет ни одного активного раздела на текущем диске, это означает, что в соответствии с принципами BIOS (в отличии от физического диска будет трудновато убрать из загрузочной цепочки или попросту выдернуть отдельный раздел диска, поэтому в этом случае снимают его флаг активности) нужно МОЛЧА обращаться к следующему диску в загрузочной цепочке с целью поиска загрузочного раздела на нем.

Выходит, загрузчики от МС тоже лишены здравого смысла...
Не знаю, кто там снимает флаг активности и почему это проще, чем перестановка очереди.
И, кстати, более одного активного раздела - нарушение спецификации. Загрузчики от МС ругаются матом, если встречают такое. Хотя лично мне кажется, что это неразумное ограничение.

Размышляю над гарантированной передачей параметров. Прихожу к следующим выводам.
Передача в памяти за пределами области сектора - плохо. Там могут быть незатёртые остатки от предыдущей неудачной загрузки, например, был запущен MBR с одного носителя, а управление передалось на другой по Int 18.
Остаются варианты: патчить загруженный код (очень не хочется) и передавать в регистрах. Склоняюсь к передаче в регистрах. Примерно так: EAX - сигнатура, EBX/ECX - данные.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 15 фев 2012, 18:48 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1206
Yoda писал(а):
Точно также нет ничего противозаконного в маркировании расширенного раздела в качестве активного.
А ты проверял реакцию различных менеджеров дисков на такую разметку?

Цитата:
Вот! Именно это мне и не нравится. Потом, когда загрузчики начинают патчить то, что вообще говоря, не должны, тут и начинается головная боль.
Я все пропатчиваю уже в памяти непосредственно перед передачей управления, а вот то что ты это делаешь на диске, как раз и будет у многих вызывать головную боль.

Цитата:
Интересно, какой номер будет в DH, если на диске два расширенных раздела и грузимся со второго?
Я тебе уже говорил, что сейчас в загрузчике обрабатывается только один расширенный раздел. Вообще в системе используется сквозная нумерация дополнительных разделов внутри расширенных - сначала нумеруются все дополнительные разделы внутри первого расширенного (5...N), потом второго (N+1...) и т.п. Кроме того, для удобства пользователя менеджер разделов также поддерживает вспомогательную независимую нумерацию дополнительных разделов для каждого расширенного раздела (5...) - эти номера как раз и предназначены для начальных загрузчиков, а чтобы их можно было использовать при загрузке, нужно менять местами дескрипторы расширенных разделов или маскировать отдельные расширенные разделы.

Цитата:
Т.е. MBR "подправит" мне пару лишних байт?... тут ни о какой взаимозаменяемости и речи быть не может )))
Во-первых, если ты целенаправленно разместишь на месте моей EBR-сигнатуры что-нибудь другое, то не подправит (правда, и управление не передаст :) ). Во-вторых, байт только один и располагается он в самом конце кода (смещение 445). В-третьих, корректировка выполняется только при альтернативной загрузке (при дефолтной загрузке в этом байте изначально хранится номер загрузочного дополнительного раздела). В-четвертых, для Alter-3 я рассматриваю и другой способ передачи этого параметра, о чем уже говорил в соответствующей теме, но никакой реакции не увидел. В-пятых, что тебя сильно напрягает уменьшение размера твоего EBR-загрузчика на один байт?

Цитата:
Да конечно, пожалуйста! Я только не могу понять причины такой крайней степени аскетизма. Даже 25 МГц трёха с 8 мегабайтами симов EDO RAM - динозавр, которого в музеях не найдёшь (специально берегу одного такого!), уж не говоря про XT/AT286. Подобные действия должны иметь какую-то разумную основу, так ведь? Или просто дело принципа? Использование 32-битных инструкций даёт огромную свободу и экономию. Даже параметров можно передать в два раза больше! )
Это традиция ))) Тебя никто не заставляет отказываться от использования 32-разрядных инструкций и т.п. в загрузчике, а насчет передачи параметров я подумаю (просто мне пока 16-разрядных регистров и памяти хватало).

Цитата:
Нууу, это не серьёзный аргумент, с таким не попрёшь против трёх корпораций )
Кстати, даже не помню, как это сообщение выглядит, до него как-то давно дело не доходило...
Так я как раз против корпораций и не пру. Это вы мне предъявляете документ 15-летней давности, на который софтверные корпорации никогда особого внимания не обращали.

Цитата:
Я же говорю, HiddenSectors содержит ошибочные данные в расширенных разделах, отформатированных старыми осями, именно потому, что никто не озабочивался загрузкой с них, а ни для чего, кроме загрузки, это поле не требуется. Наступив на эти грабли, мне тоже пришлось повозиться. Более современные или правильные ОСи пишут туда корректное значение. Если утилита boot.exe по настоятельной просьбе пользователя исправляет промашку и пишет туда правильное значение на основе реального местоположения раздела на диске, то ничего плохого в этом нет.
А тебе не приходило в голову, что эта ошибка уже успела стать более легитимной, чем результат ее самовольного исправления? Разделы типа 5 исторически имеют эту "особенность", разделы типа 0Fh не должны иметь. Соответственно, и корректировка должна выполняться только в первом случае, но не так, как это делаешь ты.

Цитата:
И, кстати, более одного активного раздела - нарушение спецификации. Загрузчики от МС ругаются матом, если встречают такое. Хотя лично мне кажется, что это неразумное ограничение.
+1. Кстати, и у M$ эта проверка была не всегда - видимо, просто место оставалось, а фантазии на что-то большее не хватило. Я считаю наличие более одного активного раздела некритичной ошибкой. Просто считаю активным первый из активных разделов. Применительно к загрузчикам тоже самое можно сказать и о расширенных разделах. У меня номер альтернативного загрузочного раздела сохраняется в байте перед таблицей разделов. Флаг активности выставляется только у активного раздела.

Цитата:
Остаются варианты: патчить загруженный код (очень не хочется) и передавать в регистрах. Склоняюсь к передаче в регистрах. Примерно так: EAX - сигнатура, EBX/ECX - данные.
Кто тебе мешает использовать схожий с моим способ (я его не патентовал, хотя "рожали" мы его долго :) ) - патчить стандартную загрузочную сигнатуру в образе загрузчика в памяти и тем самым гарантировать корректность других параметров, передаваемых через регистры и память. Только просьба не использовать для старшего байта значение 88h, если не готов предоставлять описанные мной выше параметры.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 15 фев 2012, 22:09 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 970
Откуда: Дагоба
phantom-84 писал(а):
Yoda писал(а):
Точно также нет ничего противозаконного в маркировании расширенного раздела в качестве активного.
А ты проверял реакцию различных менеджеров дисков на такую разметку?

Пока не особенно много внимания уделил экстенсивной проверке. Времени не хватает. Но я почему-то уверен, что всем будет наплевать. И потом, повторюсь, формально никакого нарушения в этом нет. Нигде не прописан запрет на активность расширенного раздела.

phantom-84 писал(а):
Я все пропатчиваю уже в памяти непосредственно перед передачей управления

Вот из-за таких патчей у меня на рабочей машине и не грузится флешка с FAT32 с флоппи-разметкой (без разделов). Потому что на будущее невозможно предвидеть, как что разовьётся, а полноценную проверку на тип файловой системы в простенький загрузчик не впихнёшь.

phantom-84 писал(а):
а вот то что ты это делаешь на диске, как раз и будет у многих вызывать головную боль.

Ничего подобного! Это даже не патч. Это всего лишь корректировка параметров ФС, абсолютно легитимная, причём в условиях, когда я могу гарантировать, что определил тип ФС правильно. Ни одна утилита не ругается и не вправляет значение HiddenSectors обратно. С таким же успехом можно ругать изменение сигнатуры "MSDOS5.0", например. Кстати, даже эта сигнатура более критична к изменению. Утверждается, что некоторые устройства могут не переварить ФС с чем-то другим вместо неё.

phantom-84 писал(а):
Так я как раз против корпораций и не пру. Это вы мне предъявляете документ 15-летней давности, на который софтверные корпорации никогда особого внимания не обращали.

Этот документ никто не отменял и не обновлял. Значит он действующий и вполне себе актуальный. Кроме того, ещё раз отмечу: Int 19 не позволяет грузиться ни с одного устройства дальше по цепочке, только лезть в BIOS и править цепочку. А Int 18 никаких недостатков не имеет, если не принимать в расчёт сообщение BIOS в конце цепочки. Два соображения (регламентирующий документ и возможность продолжения загрузки) пересиливают одно (потенциальное сообщение).

phantom-84 писал(а):
А тебе не приходило в голову, что эта ошибка уже успела стать более легитимной, чем результат ее самовольного исправления?

О легитимизации ошибки можно говорить только в том случае, если на неё что-то опирается. Иными словами, если после её устранения что-то перестанет работать. Так вот, не перестанет. Совсем даже наоборот. Ты же всё равно патчишь поле в памяти, поэтому что там было до того, никого, в том числе и твой загрузчик, не волнует.
Прежде, чем принять решения исправить её, я почитал всё, что нашёл в инете, касаемо скрытых секторов, проверил реакцию утилит, ОС и разных мобильных устройств. Так вот, абсолютно никого не волнует, что именно там написано. Это поле влияет [положительно] только на начальную загрузку, для которой и предназначено.

phantom-84 писал(а):
Кто тебе мешает использовать схожий с моим способ (я его не патентовал, хотя "рожали" мы его долго :) ) - патчить стандартную загрузочную сигнатуру в образе загрузчика в памяти

Не, от патчей я пока воздержусь. Но вариант интересный.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 15 фев 2012, 22:56 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1126
По поводу проверки 80h чтобы отмечено был 1 раздел. Лично планирую сделать так kloader читает MBR(читает из памяти) и смотрит с какого раздела его загрузили. И если там будет 2 активных раздела он не сможет определить на каком разделе он находится.

Конечно можно пойти и другим путём, но первый вариант мне больше нравится.

Цитата:
В Win2K/XP и в Windows Vista/Seven используются разные загрузчики, но они могут размещаться на любых разделах (не только первичных, но и дополнительных).
Это касается первичного загрузчика, а вторичный загрузчик ищет boot.ini на первичном. Что вызывает казус. Так что корректно только если он на первичном.

По поводу win-7 пробовал отказываться от 100мб, но ему что-то не понравилось не помню что но решено было его оставить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 16 фев 2012, 10:58 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 970
Откуда: Дагоба
pavia писал(а):
По поводу проверки 80h чтобы отмечено был 1 раздел. Лично планирую сделать так kloader читает MBR(читает из памяти) и смотрит с какого раздела его загрузили. И если там будет 2 активных раздела он не сможет определить на каком разделе он находится.

Неудачный вариант. При наличии любого менеджера загрузки не сможешь определить, с какого раздела загрузился.
В моём начальном загрузчике ядру передаётся VolID, это гораздо более надёжный метод.

2 phantom-84,
Кстати, твой географический метод (DH) ведь тоже не будет работать при подменённом MBR/EBR или при использовании сторонних менеджеров загрузки?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 16 фев 2012, 14:38 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1206
Yoda писал(а):
pavia писал(а):
По поводу проверки 80h чтобы отмечено был 1 раздел. Лично планирую сделать так kloader читает MBR(читает из памяти) и смотрит с какого раздела его загрузили. И если там будет 2 активных раздела он не сможет определить на каком разделе он находится.

Неудачный вариант. При наличии любого менеджера загрузки не сможешь определить, с какого раздела загрузился.
В моём начальном загрузчике ядру передаётся VolID, это гораздо более надёжный метод.
Да, вариант не слишком удачный. К тому же я не понял, куда делось промежуточное звено между MBR-загрузчиком и kloader, а именно первичный загрузчик, т.е. откуда kloader узнает, куда был загружен MBR-загрузчик (он же обычно перемещает себя).

Цитата:
Кстати, твой геометрический метод (DH) ведь тоже не будет работать при подменённом MBR или при использовании сторонних менеджеров загрузки?
Метод "геометрический" сейчас. В будущем смысл номеров может быть изменен. Да, при использовании стандартного MBR-загрузчика загрузочным должен быть активный раздел или нужно патчить первичный загрузчик на диске. У меня во всех первичных загрузчиках, которые могут устанавливаться в разделы, присутствует такой код:
Код:
  cmp byte [7DFFh],88h
  je short @f
  mov dh,0
@@:
Вместо нуля можно вписать актуальный номер раздела. Если ядру в dh будет передан 0 для разбитого на разделы загрузочного диска, то ядро будет считать загрузочным активный раздел.

pavia писал(а):
Это касается первичного загрузчика, а вторичный загрузчик ищет boot.ini на первичном. Что вызывает казус. Так что корректно только если он на первичном.
Я тебе говорю, что ntldr может нормально работать на дополнительном разделе. Попробуй пропатчить HiddenSectors прямо на диске.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 17 фев 2012, 10:00 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1206
Кстати, рассказываю прикол. Решил сам проверить работоспособность ntldr на доп. разделе. Форматирую свой раздел из-под win xp sp3 (на харде свою ось я обычно размещаю в виде позиционно независимого миниобраза след. формата: EBR [zzz] BR ...), копирую ntldr и все сопутствующее добро в отформатированный доп. раздел, пропатчиваю HiddenSectors, перезагружаюсь. После перезагрузки первичный загрузчик FAT12 (/FAT16?) выдает обычное сообщение об ошибке:
Код:
Remove disks or other media.
Press any key to restart

Начинаю разбираться в причинах такой неадекватной реакции. Нахожу в загрузчике такой код:
Код:
  ...
  mov ax,201h
  cmp byte [bp+2],0Eh
  jne short @f
  mov ah,42h
  mov si,sp
@@:
  mov dl,[bp+24h]
  int 13h
  ...

Это у них такая проверка возможности использовать сервис EDD :) Видимо, они так место экономят. Заменил в третьем байте BR nop на 0Eh и все нормально заработало.

Насчет boot.ini pavia оказался частично прав, перед чтением своего конфигурационного файла ntldr перечитывает BR (т.е. найти раздел он может!!! - мой EBR-загрузчик здесь помогает) и начинает использовать вновь прочитанное значение HiddenSectors (идиотизм!!!). Нужно тоже самое проверить для bootmgr'а.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 17 фев 2012, 10:21 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 970
Откуда: Дагоба
phantom-84 писал(а):
Я тебе говорю, что ntldr может нормально работать на дополнительном разделе. Попробуй пропатчить HiddenSectors прямо на диске.

phantom-84 писал(а):
ntldr перечитывает BR ... и начинает использовать вновь прочитанное значение HiddenSectors (идиотизм!!!).

:)))))

phantom-84 писал(а):
Заменил в третьем байте BR nop на 0Eh и все нормально заработало.

Это, кстати, стопроцентное нарушение спецификации FAT. Многие устройства и ОСи не распознают такой FAT, да и утилиты ругаются. Лучше пропатчить проверочный код.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 17 фев 2012, 10:48 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1206
Yoda писал(а):
:)))))
Полнейший идиотизм... Читать BR, имея информацию о ее местоположении, и потом из прочитанного брать информацию о ее местоположении (и раздела в целом).

Цитата:
phantom-84 писал(а):
Заменил в третьем байте BR nop на 0Eh и все нормально заработало.

Это, кстати, стопроцентное нарушение спецификации FAT. Многие устройства и ОСи не распознают такой FAT, да и утилиты ругаются. Лучше пропатчить проверочный код.
+1. Я об этом же подумал. Сначала не поверил тому, что вижу, и стал искать перезапись этого байта в коде самого загрузчика - не нашел! Потом подумал, что может не только я патчу первичные загрузчики динамически в памяти, и стал искать перезапись этого байта в коде экспишного MBR-загрузчика - не нашел! Вообще не понятно, для какого софта предназначен этот трюк, явно же не для шаловливых ручек рядового пользователя винды!


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 353 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8, 9 ... 36  След.

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


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 99


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

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB