Board.KolibriOS.org

Привет! Код писал практически на коленке и использовал готовый функционал, который работает. Есть ли смысл переписывать dll.inc? ИМХО если работает, проверял и каждый день работает - не трогай. Лучше дорабатывать. Вот, что надо доделать так, во-первых это саму функцию переходника (thunk), например, проверка таблицы импорта скорее всего слабая. Особенно на минимальный размер)
no reason to kill app for import absence - skip import processing, согласен, надо исправить.
Ну и наверное приложению также не помешает указатели на таблицу экспорта + malloc/realloc/free
tell user via board or console or whatever about unsuccesed searching of import
Да, это надо дорабатывать (текущее ограничение 1), в моем видении вывод надо делать через @NOTIFY
that handling made by OS - so no needance in terminating process вот это не понял, т.к если один из импортов не разрешен приложение запускать нельзя.

про использовал готовый функционал, который работает - я практически сделал тоже самое.
У фасма код лоадера был уникальный и он работал, притом как быстрейший лоадер, обыдно если быстрейший заменить на устаревший с dll.inc`а. его я и взял. Только добавил несколько фич (lib_init) и оболочки для стдкалл экспортов.
один момент в либинит надо передавать ссылку на строку пути к самой библиотеке, так чтоб библиотека знала окружение (ну т.е. путь до себя и относительные пути до каких нибудь еще библиотек), так еще чтоб в процессе либинита не затерла ненароком эту строку.
Есть еще 1 момент использование регистров в моем примере настолько друг к другу подогнано, что дополнительный функционал может к чертям нарушить сию быстроту. И вот момент с передачей строки в либинит обескураживает, то ли поинтер передавать, то ли копировать строку куда то. Так еще это обратную совместимость нарушает (на 1 параметр больше кидать), хотя раз параметры в регистрах - заюзать еще 1.

that handling made by OS - so no needance in terminating process вот это не понял

тут все просто .denied у тебя куда код передавало? на инструкцию рет в ядро, ну а хендлер фактически выведет лог всего импорта который не загрузился и всех процедур которые не нашлись и перейдет туда же на .denied.
Хотя в либинитах в процессе попытки импорта может что-то и эдакое насоздаваться - но вылечится ли это исполнением mcall SF_TERMINATE_PROCESS или достаточно будет вернуть исполнение в ядро.

П.С. а ты в ядре хорошо разобрался? только в отношении 2х файликов debug.inc & taskmgr.inc интересует - там интересно какие ядерные структуры создаются (дерево используемых библиотек и прочее)?

ProMiNick, я пока не вижу смысла переписывать заново dll.ink. М.б. позже. И еще важно то, что dll.inc уже много времени на SVN, а твой код кто-то тестировал кроме тебя?
Мне тоже многое не нравится, например, текущий формат таблицы экспорта - таблицу можно сделать меньше по размеру. Соответственно, код загрузки и связывания должен будет это учитывать.
Зачем библиотеке передавать путь до себя и относительные пути до каких нибудь еще библиотек? Все библиотеки живут в /LIB, свое имя библиотека знает.
Инициализация в dll.obj начинается в пользовательском режиме, как стартовая точка приложения.
.denied - это защита от дурака, если кто-то вызовет стартовый код еще раз или со старой версией заголовка, в этом случае ничего не происходит (хотя нужно добавить alert на доску сообщений), ret просто возвращает управление вызвавшему код. Если этот вызов из пользовательского режима, то в ядро при этом попасть нельзя. У режимов ядра и пользователя разные контексты и стек, а инструкция ret эквивалента примерно следующему { pop eip jmp eip }. Из пользовательского режима попасть в ядро можно только через шлюз (int 0x40) и ядру управление не нужно возвращать, оно его и так получает с каждым тиком таймера.

IgorA wrote: Делать через notify наверное не вариант, потому как она сама подключает libimg для показа картинок ...

Не вижу проблем с этим. Тут 2 варианта решения:
1) поселить иконки в формате BBGGRRBBGGRR... внутри самой программы, в этом случае libimg не будет нужен. Минусы - notify потолстеет, примерно до 20 кБ (это не особо проблематично), а пользователь не сможет заменить иконки (сейчас они живут отдельно)
2) научить notify, что если libimg не загрузилась (об этом можно сообщать, скажем, в одном из регистров), то не рисовать иконки. Ну и до кучи, также можно не рисовать иконки, если не загрузился сам файл иконок - сейчас программа завершается из-за ошибки страницы.

В любом случае это актуально, т.к. ядро использует notify для вывода сообщений.

Hi again.

Rebased version of the PE patch by CleverMouse is attached.
No functional changes.

dunkaist wrote:Hi again.

Rebased version of the PE patch by CleverMouse is attached.
No functional changes.

Created a branch based in the patch. If it works it's possible to merge it with the trunk.

Boppan wrote:If it works it's possible to merge it with the trunk.

CleverMouse wrote:то, что есть, должно работать, но некоторых важных вещей нет.

viewtopic.php?f=1&t=1839&start=60#p69674

Tested it out, it works but unstable. It executes a test file several times but then starts to give segfault.

Also it requires kolibri.dll to be StrippedPE.

Also I see no reason to use undocumented StrippedPE instead of a regular PE - there's no significant difference in binary size.

Добавлена поддержка автозагрузки библиотек для компилятора tcc, начальная версия для тестирования в Windows в теме http://board.kolibrios.org/viewtopic.ph ... 413#p77413