Загрузка библиотек

Internal structure and you change requests/suggestions
  • про использовал готовый функционал, который работает - я практически сделал тоже самое.
    У фасма код лоадера был уникальный и он работал, притом как быстрейший лоадер, обыдно если быстрейший заменить на устаревший с 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) и ядру управление не нужно возвращать, оно его и так получает с каждым тиком таймера.
    Last edited by Coldy on Sat Apr 24, 2021 4:05 pm, edited 3 times in total.
  • 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.
    Attachments
    pe4.patch (146.37 KiB)
    Downloaded 144 times
  • 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
  • Who is online

    Users browsing this forum: No registered users and 1 guest