*.ELF. Как преобразовать?
Если достал вопросами - не обижайтесь! Я хочу знать и уметь...
Так вот, есть очень интересный формат - *.elf
Откуда взял: есть любопытная мини-ОС, написанная на С++ (!) с добавлением сами знаете чего - ассемблера! Эта ось компилируется с помощью g++ и nasm! И то, и другое у меня есть и работает! Результатом этой компиляции является *.elf файл!
А из этого файла (непонятно как, и ни слова нигде об этом) сделали *.img, который прекрасно пишется на дискету, или подключается к виртуальной машине!
Вопрос состоит в том, чтобы вычленить из него машинный код?:confused: Т.е. этот файлик содержит хеадеры, какие-то сегменты данных и т.д. А мне нужен машинный код, который будет ядром ОС.:D
Если есть необходимость, могу выложить built.sh файл! Но там ничего интересного - самое последнее, что там есть, это проверка, создался ли *.elf файл, т.е. прошла ли компиляция успешно!
Я понимаю это так: загрузчик в первом секторе (загрузочном) носителя загружает второй загрузчик, который "знает" файловую систему новоиспеченной Оси, и, руководствуясь этим "знанием", загружает непосредственно ядро, которое представлено в том формате (например *.elf), в котором я "захочу"!
Но хотелось бы услышать от того, кто - :cool: (знает)!
Если ты думаешь что EXE(win),MZ либо ELF отличаются только хедерами то ты очень сильно заблуждаешься. Там не совсем чистый машинный код.
У каждой ОС есть свое АПИ (набор функций). Они специально сделаны для того чтобы можно было писать приложения без ущерба для самой ОС. Большинство АПИ функций выполняются в ring3. Т.е. прямой доступ например к жесткому диску винда не даст, всякое обращение к нему (либо к любому другому устройству) напрямую автоматически заменяется апи функциями.
Так вот, в чем же отличие исполн. файлов...
В таких файлах есть команды обращения к функциям самой ос (АПИ ф-циям), которых процессор не знает, а знает только сама ОС в которой он выполняеися. И конечно же, если ты запустишь код, который ты ведерешь из исполн. файла виндовс и его запустишь без ОС, то ничего не выйдет. Процессор не будет знать таких команд.
Ну как-то криво объяснил, но смысл ясен.
P.S. А если так уж хочется, возьми да и дизассемблируй например IDA Pro, только какой толк?..
Или ты просто хочешь использовать уже готовое ядро?
Так вот, в чем же отличие исполн. файлов...
В таких файлах есть команды обращения к функциям самой ос (АПИ ф-циям), которых процессор не знает, а знает только сама ОС в которой он выполняеися. И конечно же, если ты запустишь код, который ты ведерешь из исполн. файла виндовс и его запустишь без ОС, то ничего не выйдет. Процессор не будет знать таких команд
Молодой человек,у вас каша в голове
А вот что хочет asmforce,мне тоже непонятно.Насчёт *.img–так там наверняка приписывался загрузчик в начало и много-много чего полезного.Можешь поискать программы для работы с образами дискет,WinImage,например
Где именно? Я довольно долго программировал на ЯВУ, так что вот так сказать что у меня "каша" и потом куда-то испарится Вам неудастся. Потрудитесь объяснить.
уже и объяснять нечего
P.S.А я никуда и не испарюсь:) Я тут довольно часто
Что за 2й формат файла такой?Ну а коли Вы хотели написать просто про .exe(хотели,конечно же),то заголовок MZ и иже с ними туда входит.Такие дела
Там абсолютно чистый машинный код,я гарантирую это!Ну разве что это какое-нибудь .NET-приложение,или какой-нибудь программист данные вместе с кодом разместил
Спорный момент.В глубоком вызове функции и до ядра доходит,не зря же есть даже такие параметры user-mode time и kernel-mode time(немного из другой оперы,но всё же)
Вот чёрт!А мне давала…Стоило только написать CreateFile('\\.\<имя диска>:',…),и всё заработало.Может,у меня Windows такая распутная?:eek:
Вот блин,а я вручную вызовы функций писал…Наверное,у меня IDE неправильная.Или копилятор…Ой,да это же одно и то же!
Не думаю,что процессор о чём-то знает.Что ему дадут,то и выполнит.Вот вызовы функций есть,а где эта самая функция расположена–процессору покласть
Процессор знает все команды(конечно,если вы ему какую-нибудь требуху не укажете),так что не надо
Вот,пожалуйста.Расчёт окончен
MZ (иcполняемый файл DOS) и EXE(Win) - разные файлы, и структура у них разная и заголовок.
В екзе файле есть вызовы функций dll (о которых я говорил). Они как раз в выходном файле интерпритируются не совсем в машинный код. Напишите простейшее приложение для Win, уберите в заголовке заглушку 'This program cannot be run ...' и запустите под ДОС. Что ? Исполнятся будет, но неправильно, ввиду отсутствия функций.
Если по определенному адресу функция отсутствует то что будет выполнять процессор? Львиную долю машинного кода предоставляют функции вызванные из длл. Ввиду их отсутствия как это приложение будет выполнятся? Вот я что имел ввиду под выражением "не совсем машинный код", другими словами не полный машинный код. А в NET приложениях и в java и подавно.
Насколько глубоком? :D И что значит "доходит"? xD . Если приложение выполняется в ring3 то до ring0 оно никак не "дойдет" xD ))
Ф-ции ГАПИ - Direct3D или OpenGL никак не могут выполнятся в режиме ядра.Другое дело - можно настроить приложение так, чтобы действительно можно было напрямую записать данные в порт - это да. Но извращатся обычному приложению над винтом на низком уровне - это уж извините.Насколько я знаю, так могут делать только драйвера.
Я так понял Вы не видите различий между прямым доступом (читай низкоуровневым) и АПИ функциями? Функция CreateFile это как раз АПИ ф-ция, которая находится в библиотеке kernel32.dll, вот Ваше приложение как раз и вызывает ее оттуда. Все программирование в винде как раз через АПИ, за исключением написания драйверов, и то не во всех случаях.
А вот не надо ерничать. Вручную это как? Функциями типа CreateFile ? Снова - АПИ. Почитайте MSDN.
А я говорил, что приложениям в ring3 запрещено использовать низкоуровневый доступ. Никто не даст вам из ring3 низкоуровневый доступ к устройствам или портам. Я думаю это и доказывать не надо, почитайте книги.
Не надо путать исполняемый файл и то как он выполняется. И так понятно что в итоге все выполняется процессором. Я говорил о самом исполняемом файле, и его структуре, а не о связке библиотек и исп. файла.
Как раз для процессора это и будет "требуха" всякие там
push 0h
call ds:ExitProcess
Нет, безусловно это и есть код который может выполнятся на процессоре, только в данном случае будет прыжок непонятно куда, и в отсутствии ОС это приведет к ошибке
А вообще, пока Вы пишите что винда давала низкоуровневый доступ посредством ф-ции CreateFile, с выражениями типа "в Вашей голове каша" я бы повременил.
В екзе файле есть вызовы функций dll (о которых я говорил). Они как раз в выходном файле интерпритируются далеко не в машинный код.
Интерпретируются? Кем?
Вызовы функций dll - это обычный инструкция процессора CALL (http://en.wikipedia.org/wiki/X86_instruction_listings).
Если по определенному адресу функция отсутствует то что будет выполнять процессор?
Для процессора нет понятия "функция". Выполнять он будет то, что лежит по адресу, куда перевели управление. Ему вообще пофиг чего выполнять.
Львиную долю машинного кода предоставляют функции вызванные из длл. Ввиду их отсутствия как это приложение будет выполнятся?
А при чем тут отсутствие DLL и машинный код?
Если я удалю из системы user32.dll, машинный код перестанет быть машинным? :D
Напишите простейшее приложение для Win, уберите в заголовке заглушку 'This program cannot be run ...' и запустите под ДОС. Что ? Исполнятся не будет? Так вы ведь твердили что там чистый машинный код который может исполнятся прямо на процессоре!
Для того, чтоб исполняемый код запустился, его нужно расположить в памяти. Это делает загрузчик. Заголовки исполняемого файла нужны именно загрузчику, чтобы расположить код в памяти. Далее этот код выполняет процессор.
Насколько глубоком? :D И что значит "доходит"? xD . Если приложение выполняется в ring3 то до ring0 оно никак не "дойдет" xD )) порадовал !)))
Приложение - нет, вызовы Win API - "дойдет".
Внутри вызовов некоторый ф-ций Win API происходит переключение уровня.
Я так понял Вы не ловите различий между прямым доступом и АПИ функциями? Функция CreateFile это как раз АПИ ф-ция, которая находится в библиотеке kernel32.dll, вот Ваше приложение как раз и вызывает ее оттуда. Замедте,в исп. файле - не машинный код. (именно в этот момент, а таких моментов большинство. Все программирование в винде как раз через АПИ).
А я так вижу, что ты не видишь разницы между выполнением кода и вызовом ф-ции.
В исполняемом файле (в секции кода) - машинный код. В котором в т.ч. могут быть инструкции call, некоторые из которых могут вызывать код других исполняемых модулей (dll), некоторые из модулей могут относиться (реализовывать) к Win API и др. API.
Не надо путать исполняемый файл и то как он выполняется. И так понятно что в итоге все рассчеты выполняет процессор, - графику - видеокарта, ввод - клава и т.д. И все это после долгих скитаний в процессе выполнения превращается в машинный код - который непосредственно может выполнятся на процессоре. Я говорил о самом исполняемом файле, и его структуре.
Ну бред говорил... и продолжаешь... (не в обиду)
P.S. Следует конкретизировать, что мы говорим о native, а не managed приложениях.
Что бы дальше много не флудить скажу в нескольких словах:
Я не говорил что для процессора есть понятие функции, и вообще тут много чего накрутили посредством цепляния к моим словам. Понятно что ф-ция это определенный набор команд.Просто куда он прыгнет после call - это загадка, и что он выполнет если функция(ой, извиняюсь мистер), определенный набор команд по адресу такому-то будет отсутствовать? Изначально господин хотел выдрать код из какого-то непонятного приложения, непонятной ОСи, - я сказал что работать не будет (КОРРЕКТНО!!!)
Внутри этой функции, а потом снова переключается в ring3.
Насчет NanoOS... запустил, посмотрел... Честно сказать GlukOS куда лучше, он то хоть приложения умеет запускать, да и вообще он интереснее, и исходники на этом форуме, и подробное описание. Только написан он на TASMе насколько я помню, а не на С
Ты решил, что раз из ельфа сделали .имГ, то там все по-умному.
ничо подобного, все просто и тупо: как первый загрущик, так и второй winhex'ом или HxD записываются в первые сектора
а второй загрущик умнее, бо места больше у него и кода естествено
старый добрый diskedit.exe о дяди Нортона прекрасно пишет сектора в файлы и обратно . )
зы:для mbr-а не забудьте только партишены скопировать .
Что касается темы топика, не совсем понятно, чего хочет автор. Возмущает, почему ядро находится в обычном исполняемом файле? Все очень просто - используется вторичный загрузчик (например, Grub), который понимает ELF. Кстати ядро Windows тоже находится в обычном исполняемом файле формата PE. Естественно, там либо вообще не используется импорт, либо импортируются функции из модулей, также загружаемых вторичным загрузчиком, или даже из самого загрузчика. Первичные загрузчики не всегда могут загрузить файлы со "сложным" форматом лишь по одной причине - они слишком малы, чтобы реализовать эти действия. Лично я использую файл ядра с простой структурой, чтобы хоть некоторые первичные загрузчики могли его загрузить напрямую.