OSDev

Да, виртуалки легко делают пустой диск, а как ткда записать бинарник то?

Сам по себе компилятор бесполезен, а если есть система, то программируя в ней на асме хочется некоторые моменты систематизировать.
Например тот же стек (кстати узнал недавно, что процы АРМа его не требуют, а bl (аналог call) помещает адрес возврата не в стек, а в регистр LR, было бы интересно про них почитать, у них ещё говорят прерывания используют отдельные наборы регистров), в кривой IA-32 в стеке адреса вызовов, переменные, параметры, история сна, ... . При изучении АРМов вообще, всё что делалось для IA-32 кажется бредом, а особенно подход к загрузчикам(труд Yodы окажется бесполезным) система не должна зависеть от архитектуры так сильно. А на АРМах скоро все будем, IA-32 скоро умрёт(формально уже).

Параметры компиляторы не позволяют смотреть прошлой функции, а я на асме могу спокойно через [esp+] смотреть параметры позапрошлой функции, про использование ebp для выделения параметров это вообще такой бред. Реч о том, что компилятор может спокойно отслеживать изменения в стеке и адресоваться на переменные в стеке прошлых функций.
В трансляторе мне только не хватает голой инструкции для формирования таблицы релокации если org не известен, а то, что эти таблицы создаются для существующих форматов, это мне не нужно, как и сами форматы.
В создании системы на данный момент считаю самым главным организовать работу с объектами имеющими стек, его переключение в системе и хранение там задач и всего остального, соответственно самое интересное.

Знакомо до боли, хотя больше переписываю, но изучать дольше.

Не интересно. У меня MBR читает BR. BR грузит из корня KLOADER.EXE (Формат MZ-EXE).
BR у меня для FAT (FAT12,16,32).
KLOADER.EXE грузит ядро с FAT. Да и ещё много всего грузит( настройки, ядро, драйвера, отладочную информацию, и тд.).

Для отладки ядра надо что-то придумать. Если KLOADER я писал прямо на виртуалки и на ней компилировал и с неё запускал и отлаживал проблем не было. А вот ядро пока не могу собирать на виртуалке. Приходиться копировать на диск ручками.
Утилиты в планах

Ну Ё. Для этого есть cat или copy /b. На крайняк, если нужно подравнять конец образа, забиваете байтами под нужную границу. В Варе такое не нужно, а нужно просто правильно выставить тип соответствующей области вирт. диска и ее размер. Я об этом писал в самом начале: складываешь образ из "нулевой дорожки" и образа ядра, физически не объединяя файлы.

Собирай образ сменного носителя для автоинсталляции обновленных файлов на образ харда и выключения (или, чтобы дважды не запускать эмуль, рестарта, если в процессе загрузки можно легко отказаться от повторной загрузки с этого сменного носителя в пользу харда, типа: "Press any key to boot from CD..." или в стартовом меню "Boot from first hard disk").

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


В свете твоего пристрастия писать всё на АСМе и грядущей кончины x86/AMD64 (АМД, похоже, уже идёт с молотка), твой труд тоже будет бесполезен.


А я и не говорю, что это офигенно интересная тема. Тем более, у тебя уже есть какие-то загрузчики. Но в качестве быстрого и удобного стартапа для начала ОСДева для тех, у кого ещё нет ничего, вполне сгодится. Да я и сам до сих пор им (с вариациями) пользуюсь.


Неее, они не удобны. Ими нельзя что-то вбить внутрь файла. См. чуть выше.

_________________
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" предполагает хранение в бутсекторе (или еще где-либо) стартового номера сектора и размера загружаемого модуля, это можно сделать заранее в образе "нулевой дорожки" (пусть даже размер будет с запасом, если он может подрасти) или собирать "нулевую дорожку" на основе актуального размера модуля перед их объединением (или даже в процессе объединения).

Ну, например, размер ядра. А в более сложном случае инжектировать ядро внутрь образа со сложной файловой системой.

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

Ээ, чукча не дурак, чукча умный однако(как говорится). Я разрабатываю систему, и стараюсь не привязываться к архитектуре, а на АРМах она может даже и удачнее будет выглядеть (подозрение есть такое).
А по поводу кончины x86, так тока на руку всем будет, архитектура АРМ более открытая, менее навязчивая, без хлама, даже свои модели процов можно будет у корейцев заказать (о чём мы все так мечтаем, но по карману бьёт(причём нереально, а для государства вполне) и не допустимо в интел).
Если пойдут разговоры о АРМ, то глядиш и SII c grindars вернутся к обсуждениям, которые x86 обсуждать уже вообще смысла не видят, хотя знают в идеале.


Так надо знать с какой позиции начинается первый сектор в файловом образе диска

Про это я уже написал.

Это практически нереально. Где гарантия отсутствия фрагментации у исходного файла? Что если размер модуля изменяется (в большую или в меньшую сторону), т.е. как ты будешь вносить изменения в структуру ФС? Лучше уж тогда сразу делать полноценную утилиту добавления файлов в образ, чем при каждой записи задумываться о том, не нарушил ли ты структуру ФС.