информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеПортрет посетителяВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[NT] Похоже МС-овский ntloader согласен грузить только родные ядра 08.07.03 13:08  Число просмотров: 1550
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Как он их одупляет - другой вопрос. Потому как точка входа может быть любой (если в ms-е в проекте винды поменяют порядок объектников для линкера - она тоже поменяется).

> Валялась у меня РеактОсь, и решил я ее заюзать...
> В чистом виде она мне не нужна, только, как справочник по
> внутренним структурам мастдая, но вот, хотел я сделать вот
> что: подсунуть отдельные файлы (начиная с Ntoskrnl) в
> "родной" Мастдай и посмотреть, что получится.
> А не получилось ни XYZа!
> Не буду, говорит, за гружаться, пока Ntoskrnl missing or
> corrupt!
> Я, пока не приглядывался, но точки входа у них сильно
> различаются:
> родная по адр 40D010 а в ReactOS - C0001000, ну и далее, я
Я, кста, давно заметил, что драйвера (и ядро вот) компилятся с произвольным Base Address-ом, в память они все равно по этому адресу никогда не попадают. А реактос, я так понял, честно указывает куда собирается грузиться.

> пока не приглядывался (завтра начну).
Кроме этого в реактосовском ntoskrnl.exe нет битмапов для вывода бегущих кубиков. Если б проблема только в этом, то /noguiboot помогло бы. Так ведь и hal не заменяется. Еще вспомнилось, что структура реестра у реактоса - plain text. А работа с реестром идет именно из ядра. И даже если удастся заставить кернел загружаться, первый же дривер, который попытается считать свою конфигурацию испортит всю малину. Я так подозреваю, что это не единственные грабли, с которыми предстоит встретиться, если пытаться заменить любую часть (как это в свое время делали с юнихом). Может это временно, а может и by design. Типа упор делается на то, чтоб софта внутри НОВОЙ ОС-и чувствовала себя нормально, а не ось была ТОЧНО ТАКОЙ же как NT-я (что было задачей при переписывании юниха).

А начинать лучше сразу с ntldr-а, только вот никак не дойдут руки поставить bochs с внешним отладчиком - все в vmware-и делаю (вот чего там реально не хватает так это встроенного отладчика). А вообще неплохо бы потрейсить ntldr в том месте, где он выводит это самое missing. Это бы могло дать ответ на тот самый "другой вопрос" (что винде мешает загружать чужой кернел). Приятнее всего было бы если это какая-то явная проверка, а не нехватка чего то где-то.

> И так, вопрос:
>
> Может, кто уже пробовал что-нить подобное и добился
> каких-нить успехов, или, хотя бы имеет идеи на этот счет?
Похоже пока реактос можно ставить только полностью, совместимостью там еще не очень пахнет. И не уверен, что когда нибудь можно будет вытворять такие вещи. Вот реактосовские примеры я запускал в винде - работают. Скорее всего будут работать и виндовые проги, если они не используют unimplemented функций. Насколько видно из дизайна реактоси там будут также работать и большинство дриверов. Но самые низкоуровневые штуки типа ядра, хала и т.д. - вряд ли. Хотя время покажет...
<operating systems> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach