OSDev

Очень просто. Утилита nmake сначала создаёт натуральный файл образа ядра. Далее на NASM написан следующий код:
- Первые 512 байт - примитивный загрузочный сектор, который грузит 620 килобайт, начиная со второго сектора и далее, в соответствии с моими загрузочными спецификациями.
- Далее инструкция препроцессора nasm, включающая файл ядра в образ диска:

- И весь образ добивается нулями до ближайшей круглой геометрии 2 дорожки, 10 головок, 63 сектора на дорожку:

Соответственно в зависимостях makefile прописана перекомпиляция этого ассемблерного файла в бинарник при более свежем ядре. Результат компиляции - загружаемый образ диска минимального размера.
Тут есть нюанс. Образ диска не имеет файловой системы. Если мне нужно работать с файловой системой, то есть две альтернативы:
- Загрузочный код при передаче управления ядру указывает не настоящий номер загрузочного диска, а другой, который содержит файловую систему.
- Столь же автоматически (по зависимостям makefile) утилитой mkisofs генерируется ISO-образ, который подхватываеся боксом с указанием грузиться с виртуального компакт-диска.

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

Зачем такие сложности? В Варе можно складывать образ из нескольких файлов. Например: образ нулевой дорожки, образ раздела, образ "остатка" диска. Ты можешь тоже самое сделать со своим бинарником. А вообще я предпочитаю делать образы с файловой системой (или даже несколькими разделами с разными файловыми системами), хотя у меня есть загрузчик для "raw fs". Можно пренебречь спеками по FAT32 и сделать образ диска с небольшим FAT32-разделом и нулевой дорожкой. Можно делать образы с FAT12/FAT16-разделами. Я обычно делаю небольшой образ позиционно независимого раздела (расширенного раздела, в котором находится FAT12- или FAT16-раздел), который прикрепляю к образу начала диска для запуска в эмуле или записываю его в конец реального диска в участок, который описан в таблице разделов, как расширенный раздел. Короче вариантов масса! А в Варе есть еще и "вкусности" в этом плане.

Образы удобно собирать fasm'ом - много интересных макрокоманд и директив, позволяющих проделывать весьма необычные трюки, только не нужно пытаться собирать многогектарные образы. Насчет формата vmdk загляни в соответствующую спеку.

Мои пять копеек.
Работаю под самописанным фреймворком, который преобразует команду собрать в вижле в готовый flat-VMDK диск согласно подсунутой XML-спецификации. При этом собирается MBR (по-требованию), первичный загрузчик, вторичный, загрузчик, драйвера, тестовые задачи. Все это конфигурируется и прописывается на диск. После чего нужно нажать только кнопку Boot и посмотреть на результат. Делалось так, чтобы было максимально гибко и удобно. В вижле есть две конфигурации, которые отличаются вышеутомянутой XML-кой. Первая - для установки на виртуальный диск для быстрого теста, вторая - для установки на реальную дискету для последующего контрольного теста на физическом сервере. За сет фичи быстрого билда поддерживаемого вижлой я могу править любой код в проекте и получать на выходе модифицированный тестовый образ за счет одной кнопки (исходники, которые не изменились с момента последнего билда не перестраиваются.).

Если можете, то заскриншотте пошаговую сборку и запуск бинарника, а то в первый раз не догоняеш, а увидиш и сразу всё понятно становится.

Станислав, если не секрет, то к кому конкретно вы обращаетесь с этой просьбой?

Ко всем, кто сможет это сделать(подготовить бинарник к запуску в виртуалках и его требования).

Мне будет проблематично заскриншотить. У меня все проходит в три этапа:
1) [MSVS] Делаем изменения (без разницы в каком компоненте).
2) [MSVS] Нажимаем кнопку "построить решение" (F7).
3) [VmWare] Жмем "PowerOn this virtual machine".

Вот лог сборки из вижлы:
1>------ Построение начато: проект: Kernel, Конфигурация: Release Win32 ------
1>Компиляция...
2>------ Построение начато: проект: BootBlockLoader, Конфигурация: Release Win32 ------
2>Осуществление действий, прописанных в проекте Makefile
2>╤ыєцхсэр  яЁюуЁрььр юсёыєцштрэш  яЁюуЁрьь Microsoft (R), тхЁёш  9.00.30729.01
2>(C) ╩юЁяюЁрЎш  ╠рщъЁюёюЇЄ (Microsoft Corporation). ┬ёх яЁртр чр∙ш∙хэ√.
2>"Makefile" эх эєцфрхЄё  т юсэютыхэшш
2>Журнал построения был сохранен в "file://x:\os\BootBlockLoader\Release\BuildLog.htm"
2>BootBlockLoader - ошибок 0, предупреждений 0
1>LowLayer.cpp
3>------ Построение начато: проект: MasterBootRecord, Конфигурация: Release Win32 ------
3>Осуществление действий, прописанных в проекте Makefile
3>╤ыєцхсэр  яЁюуЁрььр юсёыєцштрэш  яЁюуЁрьь Microsoft (R), тхЁёш  9.00.30729.01
3>(C) ╩юЁяюЁрЎш  ╠рщъЁюёюЇЄ (Microsoft Corporation). ┬ёх яЁртр чр∙ш∙хэ√.
3>"Makefile" эх эєцфрхЄё  т юсэютыхэшш
3>Журнал построения был сохранен в "file://x:\os\MasterBootRecord\Release\BuildLog.htm"
3>MasterBootRecord - ошибок 0, предупреждений 0
1>.\LowLayer.cpp(134) : warning C4100: TRG_VALUE: неиспользованный формальный параметр
1>.\LowLayer.cpp(134) : warning C4100: trgMemoryCell: неиспользованный формальный параметр
1>.\LowLayer.cpp(161) : warning C4409: недопустимый размер инструкции
1>.\LowLayer.cpp(157) : warning C4100: BIT_NUMBER: неиспользованный формальный параметр
1>.\LowLayer.cpp(157) : warning C4100: destination: неиспользованный формальный параметр
1>.\LowLayer.cpp(328) : warning C4100: xxx: неиспользованный формальный параметр
1>.\LowLayer.cpp(455) : warning C4409: недопустимый размер инструкции
1>Компоновка...
1> Создается библиотека Release\Kernel.lib и объект Release\Kernel.exp
1>Создание кода
1>Создание кода завершено
1>Выполнение анализа кода...
1>Журнал построения был сохранен в "file://x:\os\Kernel\Release\BuildLog.htm"
1>Kernel - ошибок 0, предупреждений 7
4>------ Построение начато: проект: Loader, Конфигурация: Release Win32 ------
4>Компоновка...
4>Создание кода
4>Создание кода завершено
4>Выполнение анализа кода...
4>Журнал построения был сохранен в "file://x:\os\Loader\Release\BuildLog.htm"
4>Loader - ошибок 0, предупреждений 0
5>------ Построение начато: проект: PostBuildEvents, Конфигурация: FDD Win32 ------
5>Осуществление действий, прописанных в проекте Makefile
5>ZP OS Installer. Written by Evgeny Klimenkov. All rights reserved.
5>Журнал построения был сохранен в "file://x:\os\PostBuildEvents\FDD\BuildLog.htm"
5>PostBuildEvents - ошибок 0, предупреждений 0
========== Построение: успешно: 5, с ошибками: 0, без изменений: 16, пропущено: 0 ==========
Все тулы работают из консоли поэтому скриншотить нечего. Проект PostBuildEvents - фэйковый. Он зависит от всех других проектов и единственная его функция - запустить инсталлер с соответствующими параметрами.

А это пример конфигурационной XML для флопика:
<?xml version="1.0" encoding="UTF-8"?>
<InstallConfig>
<BootBlockLoader string = "..\BootBlockLoader\BootBlockLoader"/>
<BootDevice value = "0x00"/>
<CylindersCount value = "0x00000050"/>
<HeadsCount value = "0x00000002"/>
<MasterBootRecord string = "..\MasterBootRecord\MasterBootRecord"/>
<SectorsCount value = "0x00000012"/>
<TargetAddress value = "0x7E00"/>
<TargetDisk string = "\\.\a:"/>

<CpuEntry>
<Kernel string="..\Kernel\Release\Kernel.dll"/>
<Loader string="..\Loader\Release\Loader.exe"/>
<FirstTask string="..\FirstTask\Release\FirstTask1.exe"/>
<Config>
<Parameter value="0x1"/>
</Config>
<Config>
<Parameter value="0x2"/>
</Config>
<Config>
<Parameter value="0x3"/>
</Config>
<Config>
<Parameter value="0x4"/>
</Config>
</CpuEntry>

<CpuEntry>
<Kernel string="..\Kernel\Release\Kernel.dll"/>
<Loader string="..\Loader\Release\Loader.exe"/>
<FirstTask string="..\FirstTask\Release\FirstTask2.exe"/>
<Config>
<Parameter value="0x5"/>
</Config>
<Config>
<Parameter value="0x6"/>
</Config>
<Config>
<Parameter value="0x7"/>
</Config>
<Config>
<Parameter value="0x8"/>
</Config>
</CpuEntry>
</InstallConfig>

Loader.exe - это вторичный загрузчик, который производит полную инициализацию ядра. После инициализации и пуска - он перестает работать и игнорируется. Занимаемая им память считается свободной. Само ядро не имеет никакого кода связанного с инициализацией.

Все бинарники собираются в вижле как exe или dll с тонкой натройкой. Kernel.dll - с фиксированным начальным адресом кода. Инсталлер парсит PE-заголовок бинарника, вырезает из него секцию кода и записывает в нужное место на диске. Загрузчики вычитывают и записывают секции кода по нужным адресам в памяти. Все адреса как на диске, так и в памяти автоматически высчитываются в режиме runtime.

P.S.: Извиняюсь за варнинги в коде. Они являются следствием активного насыщения кода отладочными записями, чтобы вылечить хромающий планировщик.

Можешь выложить в инет загружаемый образ диска для проверки этой ошибки? Хоть у меня и тоже восьмёрка, но полагаю что этот эффект может зависеть от номера сборки и типа хоста. У меня 8.0.0 build-471780, Windows 7 Ultimate, 64-bit 6.1.7601, Service Pack 1.