Компиляция MBR загрузчика в Visual Studio

Собственно для реализации сабжа нужно иметь возможность линковать обжи сгенерированые VC в бинарный файл без всякого формата, а не в PE.
Кто знает какой можно испльзовать линкер, либо может быть подобное поддерживается стандартным линкером студии?

 

нет. студия не держит. я юзаю unilink.

 

Юзаю mingw. Хотя творение Харона мне тоже понравилось

 

Проблема решена путем загрузки PE файла через простенький ассемблерный код.

 

ntldr всмысле?

 

rain
Чего уж непонятного, загрузчик на асме подгружает основной стаб, скомпиленный как pe exe.

 

жестоко как-то =)) хотя если нарочно сделать одну секцию всего и все туда запихать, то загрузка будет тривиальной

 

Так и сделал. И виртуальный адрес секции равен физическому, так что все что нужно - это получить адрес точки входа.

 

помоему обычного com-файла хватило бы. без извратов.

 

Обычные .com файлы не создаются ни одним современным компилятором.

 

я думаю что и по сей день не проблема найти тасм версии 5 к примеру, или bc++ для дос.

 

k3internal
Интересно почему авторы grub и даже авторы windows в загрузчике ntldr используют именно этот подход, а не компилят свой код в bc++ для дос? Может быть потому что нужно юзать современные компиляторы знающие что такое оптимизация? Или потому что программировать в pmode гораздо проще и удобней? Или потому что 32х битный код быстрее и компактней?
В общем если хочешь - возись с старыми компиляторами и прочим дерьмом, а я считаю этот подход наиболее оптимальным для написания программ с достаточно сложной логикой.

 

Когда-то делал подобное на старых компилерах BC++ - достаточно было подменить cs.obj (или cm.obj, cl.obj ...) на свой - в котором смещение кода было выровнено на 7C00h. - после такой махинации надо было просто выкусить код ехе начиная с точки входа и смело писать в MBR/Бут-сектор (можно было и дальше, - если канеш расчитывать на то, что код бут-сектора также линейно восстановит ехе в памяти). И все это работало безо всяких дополнительных ассемблерных вставок и хаков... + не надо было патчить ни релоки, ни плейсхолдеры для сегментов (т.к. код какраз генерировался по сегментной базе 0). Кстати, этот подход работал как в малой, так и в большой модели памяти.
Если VC++ сумеет сгенерить код реального режима (как-то даж ненаю, есть ли такая возможность) - то, думаю, можно повторить .

P.S. канеш, я не сторонник такого метода, но раз народ еще пишет свои ОС, почему б не дзенствовать поглубже?

 

Я в первых версиях своей проги тоже компилил часть кода в BC++, но отказался от этого из за ужаснейшей оптимизации результата, общей убогости компилятора и геморроев связаных с сборкой в DOS приложении. Ну и наконец 16 битный реалмод код не рулит.
Сейчас же сделав парочку ассемблерных функций переходников я могу спокойно пользоваться всеми преимуществами современных компиляторов.

 

ntldr
Для бут-сектора как раз таки рулит 16-битный реалмод код, ибо код этот займёт несколько меньше места, чем аналогичный 32хбитный с префиксами. Да и вообще не курю темы, накой Х извращацца с написанием бут-сектора на современных компиляторах. Не прощще ли на асме накатать код и скомпилить, и извращацца с оптимизацией можешь как удобно.

 

k3internal

Во-первых нет никаких лишних префиксов, так как 32х битный код работает в 32х битном pmode.
Во-вторых реализуйте в чистом 16 битном коде алгоритм навроде AES, и удивитесь. Он получиться минимум в 2 раза больше аналогичной реализации в 32х битном коде.
В третьих мои прошлые версии бута были написаны на ассемблере, но проект развивается, и сложность кода очень быстро растет. Поэтому я не считаю ассемблер оптимальным выбором для этой задачи.
Моя задача - получить рабочий и не глючный конечный продукт при условии достаточно сложного функционала, и иметь возможность легко поддерживать в будующем этот код.

 

я может чего-то не понимаю?... MBR/boot-сектора вроде как грузятся в рил-моде (или это уже не так??)... Если все же в рил-моде - то, сомневаюсь, что у кого-то хватит инжинерной мысли поместить в 512 байт переход в протмод (а если по стандартам делать с BPB и проч. хренью - то и того меньше), эмуляцию v86 для выполнения BIOS (ведь на данной стадии, это по затратам меньше, чем реализовывать свой дисковый ввод/вывод верно? - ведь надо ж както загрузать еще и сам лоадер...). Думаю, никуда не деться от 16-ти разрядности в бут-секторе и частично в лоадере.

 

Поместить сам переход в pmode легко, но код всего загрузчика туда в любом случае не влезет, как ни извращайся и на чем не пиши. Поэтому в самом MBR стоит маленький код догружающий тело загрузчика которое весит около 20кб. Для вызова BIOS прерываний используется не v86, а временный переход обратно в realmode.
16 разрядный код конечно есть, но его там очень мало.

 

ntldr

[...]

 

[]