Board.KolibriOS.org

И ещё один глупый вопрос: а где взять 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
если все нормально то получится примерно такой лог

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

Ядро может выводить отладочный лог в COM1. Это очень удобно если запускать в эмуляторе. Для этого надо открыть makefile и добавить -DCONFIG_DEBUG в строку "CFLAGS =" и перекомпилировать ядро. Для запуска в qemu указать ключ -serial file:путь_к_лог_файлу. Для bochs отредактировать строку в bochsrc.txt "com1: enabled=1, mode=file, dev=путь_к_лог_файлу". На реальном железе такое ядро будет грузиться очень медлено потому что вывод в СОМ занимает много времени.

P.S. Я выложу новую сборку когда доделаю загрузку PE программ. Примерно через неделю.

Жду с нетерпением.
Загрузка DLL будет реализована?

..bw

Сейчас этим занимаюсь. PE программы и расшаренные DLL с автоматической линковкой при загрузке.

Какие параметры порта?

8 бит, остальное по дефолту. Я использовал только в эмуляторах им всё равно. На железе наверное надо ставить 115200 чтобы быстрее работало

Сделал загрузку ДЛЛ.

Пока все длл-ки локальны и не могут импортировать сами, но это пока.
Здесь свежая превьюшка.
/rd/1/testcon2.kpe портированный пример работы с консолью. Здесь отладочное ядро (нет оно не зависло. Просто долго, долго, очень долго и старательно пишет всё в сом1).

Какие есть условия для запуска PE EXE? ImageBase, например, должен быть равен нулю? Если он будет выставлен в 0x400000 то это приведет к перерасходу памяти (первые 4Mb будут зарезервированны для удовлетворения смещения секций на ImageBase)?
DLL локальны (не понял :-) ? Т.е. таблицы импорта в них игнорируются и зависимости для таких DLL разрешены не будут?

..bw

Базы программ и длл должны быть 0. Для фасма это не проблема
format PE GUI at 0
format PE GUI 4.0 DLL at 0
Перерасхода памяти не будет. Образ неправильно скомпонуется и вылетит со страничной ошибкой. Длл локальны в том смысле что находятся в пространстве процесса. Если десять программ ссылаются на одну длл она будет загружена десять раз. Таблицы импорта в длл игноруруется. Загрузчик не различает длл и приложения и может запустить длл как программу. Всё это будет исправлено, а пока так.

Путь к программе и командная строка передаются через стек. Я взял за основу System V ABI. После загрузки приложения стек выглядит так

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] = argc
[esp+4] = path и т.д

Стек расположен в вершине адресного пространства процесса. Пока стек жёстко ограничен одной страницей.

Разделил тему.

_________________
in code we trust

> Базы программ и длл должны быть 0.
Странное решение, надеюсь в скором времени ты исправишь этот момент. Хотелось бы иметь возможность загружать существующие (под винду) библиотеки без предварительного изменения в них 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

Действительно, наверное благодаря улучшеным иконкам (а может и чему-то ещё)), образ грузится значительно быстрее.

_________________
Через тернии к звездам