Колибри PE
-
И ещё один глупый вопрос: а где взять PE ядро?
Присоединяюсь к Атауальпа, где взять бинарник и как собрать бинарник самому, если можно развернутый ответ ) а то на svn несколько лишних скриптов для компиляции которые к PE отношения не имеют.
Для сборки нужны migw gcc (я компилирую gcc 4.2.1) fasm, binutils , make и 7z если нужна упаковка в .gz. Сборка простая - открывается консоль cmd и в ней выполняется make. Или простой батник
@erase lang.inc
@echo lang fix ru >lang.inc
@make
@pause
если все нормально то получится примерно такой лог
Ядро может выводить отладочный лог в COM1. Это очень удобно если запускать в эмуляторе. Для этого надо открыть makefile и добавить -DCONFIG_DEBUG в строку "CFLAGS =" и перекомпилировать ядро. Для запуска в qemu указать ключ -serial file:путь_к_лог_файлу. Для bochs отредактировать строку в bochsrc.txt "com1: enabled=1, mode=file, dev=путь_к_лог_файлу". На реальном железе такое ядро будет грузиться очень медлено потому что вывод в СОМ занимает много времени.
P.S. Я выложу новую сборку когда доделаю загрузку PE программ. Примерно через неделю.
@erase lang.inc
@echo lang fix ru >lang.inc
@make
@pause
если все нормально то получится примерно такой лог
Code: Select all
as -o bin/export.obj core/export.asm
gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/init.obj core/init.c
gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/mm.obj core/mm.c
gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/slab.obj core/slab.c
gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/heap.obj core/heap.c
gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/dll.obj core/dll.c
gcc -c -O2 -I include/ -fomit-frame-pointer -fno-builtin -o bin/spinlock.obj core/spinlock.c
fasm.exe boot/boot.asm bin/boot/boot.obj
flat assembler version 1.67.15 (1373667 kilobytes memory)
3 passes, 7240 bytes.
fasm.exe boot/start.asm bin/boot/start.obj
flat assembler version 1.67.15 (1373667 kilobytes memory)
4 passes, 851 bytes.
ld -shared -s -Map kernel.map --image-base 0x100000 --file-alignment 32 -T ld.x -o kernel.mnt kernel.obj bin/export.obj bin/init.obj bin/mm.obj bin/slab.obj bin/heap.obj bin/dll.obj bin/spinlock.obj bin/boot/boot.obj bin/boot/start.obj
7z a -tgzip kernel.gz kernel.mnt
7-Zip 4.42 Copyright (c) 1999-2006 Igor Pavlov 2006-05-14
Scanning
Updating archive kernel.gz
Compressing kernel.mnt
Everything is Ok
P.S. Я выложу новую сборку когда доделаю загрузку PE программ. Примерно через неделю.
Жду с нетерпением.
Загрузка DLL будет реализована?
..bw
Загрузка DLL будет реализована?
..bw
Сейчас этим занимаюсь. PE программы и расшаренные DLL с автоматической линковкой при загрузке.
Какие параметры порта?Ядро может выводить отладочный лог в COM1
8 бит, остальное по дефолту. Я использовал только в эмуляторах им всё равно. На железе наверное надо ставить 115200 чтобы быстрее работало
- Attachments
-
-
console.7z (16.99 KiB)
- исходники портированной консоли
Downloaded 359 times
-
Какие есть условия для запуска PE EXE? ImageBase, например, должен быть равен нулю? Если он будет выставлен в 0x400000 то это приведет к перерасходу памяти (первые 4Mb будут зарезервированны для удовлетворения смещения секций на ImageBase)?
DLL локальны (не понял :-) ? Т.е. таблицы импорта в них игнорируются и зависимости для таких DLL разрешены не будут?
..bw
DLL локальны (не понял :-) ? Т.е. таблицы импорта в них игнорируются и зависимости для таких DLL разрешены не будут?
..bw
Last edited by bw on Wed Nov 05, 2008 12:35 pm, edited 1 time in total.
Базы программ и длл должны быть 0. Для фасма это не проблема
format PE GUI at 0
format PE GUI 4.0 DLL at 0
Перерасхода памяти не будет. Образ неправильно скомпонуется и вылетит со страничной ошибкой. Длл локальны в том смысле что находятся в пространстве процесса. Если десять программ ссылаются на одну длл она будет загружена десять раз. Таблицы импорта в длл игноруруется. Загрузчик не различает длл и приложения и может запустить длл как программу. Всё это будет исправлено, а пока так.
Путь к программе и командная строка передаются через стек. Я взял за основу System V ABI. После загрузки приложения стек выглядит так
[esp] = argc
[esp+4] = path и т.д
Стек расположен в вершине адресного пространства процесса. Пока стек жёстко ограничен одной страницей.
format PE GUI at 0
format PE GUI 4.0 DLL at 0
Перерасхода памяти не будет. Образ неправильно скомпонуется и вылетит со страничной ошибкой. Длл локальны в том смысле что находятся в пространстве процесса. Если десять программ ссылаются на одну длл она будет загружена десять раз. Таблицы импорта в длл игноруруется. Загрузчик не различает длл и приложения и может запустить длл как программу. Всё это будет исправлено, а пока так.
Путь к программе и командная строка передаются через стек. Я взял за основу System V ABI. После загрузки приложения стек выглядит так
Code: Select all
typedef struct
{
int argc; /* always 2 */
char *path; /* argv[0] program path */
char *cmdline; /* argv[1] command line. May be null */
u32_t sep1; /* separator. must be zero */
char *env; /* single environment string */
u32_t sep2; /* separator. must be zero */
auxv_t aux[1]; /* aux. AT_NULL for now */
}exec_stack_t;
[esp+4] = path и т.д
Стек расположен в вершине адресного пространства процесса. Пока стек жёстко ограничен одной страницей.
Разделил тему.
in code we trust
> Базы программ и длл должны быть 0.
Странное решение, надеюсь в скором времени ты исправишь этот момент. Хотелось бы иметь возможность загружать существующие (под винду) библиотеки без предварительного изменения в них image base и соответствующей релокации. Конечно, для выполнения зависимостей некоторых DLL придется поработать мозгом и написать частичные реализации kernel32.dll и т.п. Например, первым делом, я хочу поработать над xvid.dll. У этой библиотеки существуют, вполне реализуемые, зависимости от kernel32.dll и user32.dll.
..bw
Странное решение, надеюсь в скором времени ты исправишь этот момент. Хотелось бы иметь возможность загружать существующие (под винду) библиотеки без предварительного изменения в них image base и соответствующей релокации. Конечно, для выполнения зависимостей некоторых DLL придется поработать мозгом и написать частичные реализации kernel32.dll и т.п. Например, первым делом, я хочу поработать над xvid.dll. У этой библиотеки существуют, вполне реализуемые, зависимости от kernel32.dll и user32.dll.
..bw
Базу для длл я поправлю. Насчёт Win DLL я не столь оптимистичен. Существующий загрузчик не сможет их правильно загрузить. И правильная реализация функций из win api дело довольно нудное. Мне кажется быстрее портировать и скомпилировать их под Колибри.
> Существующий загрузчик не сможет их правильно загрузить.
А в чем может возникнуть сложность? Удручающая новость, если честно, я сильно расчитывал на это.
> И правильная реализация функций из win api дело довольно нудное.
Это конечно так. Но я не ставлю перед собой цель реализовать весь API, а только по мере необходимости.
> Мне кажется быстрее портировать и скомпилировать их под Колибри.
Собирать виндовый код из под Linux то еще приключение, особенно сишный код паскалисту :-). Мои начинания с медиаплеером потому и заглохли. Существующих реализация libc окозалось недостаточно, ни для xvid, ни тем более для ffmpeg. Писать свои заглушки для недостающих имен на си я не могу из-за недостатояного опыта разработки на этом языке, а на pascal'е это довольно проблематичная задача, хотя бы потому, что определение функций типа cdecl реализовано слабовато (нельзя работать с "..." в параметрах).
p.s. К тому же исходники не всегда доступны ;-).
..bw
А в чем может возникнуть сложность? Удручающая новость, если честно, я сильно расчитывал на это.
> И правильная реализация функций из win api дело довольно нудное.
Это конечно так. Но я не ставлю перед собой цель реализовать весь API, а только по мере необходимости.
> Мне кажется быстрее портировать и скомпилировать их под Колибри.
Собирать виндовый код из под Linux то еще приключение, особенно сишный код паскалисту :-). Мои начинания с медиаплеером потому и заглохли. Существующих реализация libc окозалось недостаточно, ни для xvid, ни тем более для ffmpeg. Писать свои заглушки для недостающих имен на си я не могу из-за недостатояного опыта разработки на этом языке, а на pascal'е это довольно проблематичная задача, хотя бы потому, что определение функций типа cdecl реализовано слабовато (нельзя работать с "..." в параметрах).
p.s. К тому же исходники не всегда доступны ;-).
..bw
Действительно, наверное благодаря улучшеным иконкам (а может и чему-то ещё)), образ грузится значительно быстрее.
Из хаоса в космос
Who is online
Users browsing this forum: No registered users and 4 guests