OSDev

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

_________________
We are back with a hard even better than before [D-Block & S-Te-Fan – Evolutionz {Ran-D remix}]

Ну так пусть задача-эмулятор будет драйвером режима пользователя, а ядро пусть формирует и передает ему запросы на ввод-вывод. И вообще, зачем самому ядру понадобился BIOS?

Если речь идет о накопителях, и если действительно там работа идет в 32-битном режиме, то прыжки в RM, наверное, единственный выход (тем более там нужна обработка прерываний).
А для установки видеорежимов наверняка хватит эмулятора - перехватываем обращения к пространству ввода-вывода, а ось их обрабатывает.

Вот мне интересно, как решает эти вопросы Мелкософт в 64-битых системах?
Сдаётся мне, что они как переходят в защищённый режим, так и забивают на BIOS INT 13h. Все остальные обращения делают только при наличии соответствующего драйвера I/O железки.

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

XP решает так. В загрузчике, если не путаю в ntdetect. Работа идёт в RealMode использует int 13h для загрузки загрузочного драйвера жесткого (в 99,9% этот драйвер отсутствует). В случае его отсутствия прыгает между реальным и защищенным режимом, для загрузки ядра. Затем передает управление ядру которое загружает драйвера жесткого диска который грузится либо загрузочным драйвером либо прыжком в реальный режим.

Как видите VM86 windows не использует.
в 64 битной думаю ничего не поменялось.

В Vista, 7, 8 (BOOTMGR/winload) не зависимо от x86/x64 все абсолютно так же, для загрузки ядра и первичных драйверов используются прыжки.
После запуска ядра, стандартный видеодрайвер (он работает, если нет дров на видюху) использует эмулятор в HAL.

А экспорты эмулятора вам известны? Интересно было бы на него поглядеть.

HAL - уровень абстракции от железа. Другими словами прослойка в виде интерфейсов. Что такое интерфейс это указатель на функции и описание функции как то список передаваемых и принимаемых параметров. Архитектура виндоуса построена по принципу разработки сверху в низ. Драйверная система в виндоусе построенна следующим образом есть набор мини драйверов в которых описаны интерфейсы такие драйвера называются "MiniPort". Что касается видео драйвера то это "videoprt.sys"
По сути это и есть частичка HAL. В виндоусе есть ещё HAL.dll в котором всякая мелочевка собрана не попавшая в другие части.
Так вот универсальный видео драйвер в виндоусе называется vga.sys он вызывает функции из videoprt.sys либо заменяет на свои. В секции импорта vga.sys лежит функция VideoPortInt10 из videoprt.sys. Далее надо смотреть как там это сделано.
videoprt.sys есть импорт из HAL.dll функции Ke386CallBios (WinXP) x86BiosCall (Win7).

Насколько я думаю там все таки не эмуляция, а переход в реальный режим. Эмулятор у них под NTVDM заточен и там int реальные надо эмулировать в защищенном. Т.е в NTVDM вызов int 10 приводит к вызову VideoPortInt10.

Я разбирался с x86BiosCall и насколько я разобрался, там как раз чистый эмулятор, без прыжков.
А вот ее предшественница Ke386CallBios, по-моему прыгала.

Если исходить из теории, то прыжки действительно вызывают большую головную боль с обработкой возникших в течение работы BIOS аппаратных прерываний. Эмуляция с этой точки зрения надёжней, хотя возникает другая проблема - производительность. Ещё непонятно, до какой глубины эмулировать процессор? Ведь BIOS в принципе, может исполнять любые инструкции реального режима. А т.к. системный BIOS затачивается под конкретную систему, он совершенно не обязан ограничиваться только базовым набором инструкций 386.

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