Привет! Код писал практически на коленке и использовал готовый функционал, который работает. Есть ли смысл переписывать 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.
Хотя в либинитах в процессе попытки импорта может что-то и эдакое насоздаваться - но вылечится ли это исполнением mcall SF_TERMINATE_PROCESS или достаточно будет вернуть исполнение в ядро.
П.С. а ты в ядре хорошо разобрался? только в отношении 2х файликов debug.inc & taskmgr.inc интересует - там интересно какие ядерные структуры создаются (дерево используемых библиотек и прочее)?
У фасма код лоадера был уникальный и он работал, притом как быстрейший лоадер, обыдно если быстрейший заменить на устаревший с dll.inc`а. его я и взял. Только добавил несколько фич (lib_init) и оболочки для стдкалл экспортов.
один момент в либинит надо передавать ссылку на строку пути к самой библиотеке, так чтоб библиотека знала окружение (ну т.е. путь до себя и относительные пути до каких нибудь еще библиотек), так еще чтоб в процессе либинита не затерла ненароком эту строку.
Есть еще 1 момент использование регистров в моем примере настолько друг к другу подогнано, что дополнительный функционал может к чертям нарушить сию быстроту. И вот момент с передачей строки в либинит обескураживает, то ли поинтер передавать, то ли копировать строку куда то. Так еще это обратную совместимость нарушает (на 1 параметр больше кидать), хотя раз параметры в регистрах - заюзать еще 1.
тут все просто .denied у тебя куда код передавало? на инструкцию рет в ядро, ну а хендлер фактически выведет лог всего импорта который не загрузился и всех процедур которые не нашлись и перейдет туда же на .denied.that handling made by OS - so no needance in terminating process вот это не понял
Хотя в либинитах в процессе попытки импорта может что-то и эдакое насоздаваться - но вылечится ли это исполнением 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) и ядру управление не нужно возвращать, оно его и так получает с каждым тиком таймера.
Мне тоже многое не нравится, например, текущий формат таблицы экспорта - таблицу можно сделать меньше по размеру. Соответственно, код загрузки и связывания должен будет это учитывать.
Зачем библиотеке передавать путь до себя и относительные пути до каких нибудь еще библиотек? Все библиотеки живут в /LIB, свое имя библиотека знает.
Инициализация в dll.obj начинается в пользовательском режиме, как стартовая точка приложения.
.denied - это защита от дурака, если кто-то вызовет стартовый код еще раз или со старой версией заголовка, в этом случае ничего не происходит (хотя нужно добавить alert на доску сообщений), ret просто возвращает управление вызвавшему код. Если этот вызов из пользовательского режима, то в ядро при этом попасть нельзя. У режимов ядра и пользователя разные контексты и стек, а инструкция ret эквивалента примерно следующему { pop eip jmp eip }. Из пользовательского режима попасть в ядро можно только через шлюз (int 0x40) и ядру управление не нужно возвращать, оно его и так получает с каждым тиком таймера.
Last edited by Coldy on Sat Apr 24, 2021 4:05 pm, edited 3 times in total.
Не вижу проблем с этим. Тут 2 варианта решения:IgorA wrote: Делать через notify наверное не вариант, потому как она сама подключает libimg для показа картинок ...
1) поселить иконки в формате BBGGRRBBGGRR... внутри самой программы, в этом случае libimg не будет нужен. Минусы - notify потолстеет, примерно до 20 кБ (это не особо проблематично), а пользователь не сможет заменить иконки (сейчас они живут отдельно)
2) научить notify, что если libimg не загрузилась (об этом можно сообщать, скажем, в одном из регистров), то не рисовать иконки. Ну и до кучи, также можно не рисовать иконки, если не загрузился сам файл иконок - сейчас программа завершается из-за ошибки страницы.
В любом случае это актуально, т.к. ядро использует notify для вывода сообщений.
Hi again.
Rebased version of the PE patch by CleverMouse is attached.
No functional changes.
Rebased version of the PE patch by CleverMouse is attached.
No functional changes.
- Attachments
-
-
pe4.patch (146.37 KiB)Downloaded 149 times
-
Created a branch based in the patch. If it works it's possible to merge it with the trunk.dunkaist wrote:Hi again.
Rebased version of the PE patch by CleverMouse is attached.
No functional changes.
Boppan wrote:If it works it's possible to merge it with the trunk.
viewtopic.php?f=1&t=1839&start=60#p69674CleverMouse wrote:то, что есть, должно работать, но некоторых важных вещей нет.
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.
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
Who is online
Users browsing this forum: No registered users and 2 guests