Менеджер DLL в MeOS

Discussing libraries simplifying applications development
  • MenuetOS C Library: http://board.flatassembler.net/topic.php?t=2952
    Других вроде пока нет, хотя в MFAR'е я буду делать поддержку плагинов, так что и над DLL подумаю. Точнее говоря, плагины и будут DLL.
  • mike.dld
    Слушай, а ты не сможешь создать топик про плагины для MFar'а?Может кто-чем сможет помочь в реализации этой затеи.
  • Пока что помочь может только менеждер памяти :) А дальше будем думать
  • А что, если попробовать интегрировать возможность реализации DLL в ядро? Тогда к DLL обращаться через IPC будет не сложно, но проблема в передаче параметров. После реализации открываются большие перспективы для MeOS как модульной системы (а не так, что все ядро одним файлом).
  • Приблизительно так и должно быть. И в любом случае так будет. Но не сейчас. Я могу свободно представить себе, насколько возрастёт потенциал ядра с введением DLL, но делается всё не в один день.
  • Тогда к DLL обращаться через IPC будет не сложно, но проблема в передаче параметров.
    А в миос что какие то особенные длл планируются? =) Зачем к длл обращаться через IPC? %)
    Причины и следствия
  • Ну, вообще, да, IPC тут ни к чему :)
  • Привет всем! Я тоже думал на реализацией DLL.
    Хоть я и отошёл от разработки GUI (говорят что были проекты куда удачнее моего, не спорю - но что то ни одного из них в действии не видел)
    но с реализацией ДЛЛ механизма думаю всё наладится более менее, и думаю применить ООП на асме - главное это реализация полноценного обьектного механизма , в свою очередь это влечёт за собой доработку менеджера памяти, ибо надо что бы обьекты были динамические в ОЗУ а не в части кода как было у меня раньше (проблема с размером приложений отпадёт сразу)...
    вобщем что то я не в ту степь полез, а по теме

    я тоже за то что бы ДЛЛ загружались/выгружались посредством функций ядра

    Вот как я себе представляю

    Допустим определить какую то функцию работы с DLL
    например 0x100

    через 4-6 регистров впрочем можно передать все необходимые параметры

    в eax - номер подфункции, такие как загрузить, выгрузить либу
    в ebx - номер вызываемой функции (нужна таблица соответствий номеров функций либы и их имен)... не совсем удобно но для начала думаю вполне хватит
    в esi или edi - типа передаваемые параметры в определённом виде...

    сделать либы 2х видов - статические и динамические...

    необходима также таблица в которой будут храниться текущие данные о загруженных либах и приложениях которые их юзают (ну собсно это работа манагера длл)


    вот тока в каком формате делать сами либы я пока ещё не продумал...

    что то типа того

    struc DLL_HEADER
    {
    некоторая служебная инфа
    }

    {
    таблица соответствий имен и номеров функций
    }

    сами функции

    ресурсы...


    а в самой проге напрмер в начале работы

    загрузка либы
    mov eax,0x100
    mov ebx,1 ;типа загрузка либы
    mov ecx,'MyLib.DLL'
    xor edx,edx ;сюда будет возвращен handle либы или -1 к примеру если ошибка ; хендл ранее загруженой либы или загрузка если она не в памяти

    если либа загружена то теперь обращаемся (ну или загружаем таблицу соответствий имен и номеров функций)

    mov eax,0x100
    mov edx,[Handle]
    mov ebx,10 - получить таблицу соответствий
    int 0x40

    таблица вида что то типа

    # ID Name @Addr
    1 001 'Init' 0x0100
    2 002 'Proc1' 0x0120
    3 ....
    ..

    далее имея данные о доступных функциях делаем вызов, параметры передаём скорее всего через стек (либо же выделить область для пересылки параметров отдельно.. но думаю стек будет как раз в тему)

    push param1
    push param2
    call Init ; на самом деле вызывается адрес с либы

    надо правда ещё подумать как работать с хендлами либ что бы не было колизий с одинаковыми именами в 2х либах...

    но это дело времени...

    вот так я представляю процесс... если у кого каике то идеи получше буду рад их прочитать тут
  • Ты знаешь как устроены DLL в винде? Рискну напомнить, что DLL'ки в отличие от программ не всегда загружаются по тому адресу, по которому они скомпилированны. А значит им нужна таблица релокейшенов, которые определяют какие байты нужно править, чтобы DLL работала при загрузке по другому адресу. Но сделать таблицу релокейшенов в FASM'e нельзя - он может ее делать только автоматически для тех форматов исполняемых файлов, где она используется (DLL'ки в Windows например). Но ничего о Менуете FASM не знает, а потому сгенерировать эту таблицу автоматически нельзя. А с помощью макросов это сделать невозможно (кто меня переубедит :mrgreen: ). А значит с написанием DLL'ек на FASM'e будут проблемы. Нужно написать программу, которая по ассемблерному исходнику сгенерирует таблицу релокейшенов (кто это сделает? :wink: ). И это также будет ограничивать применение макросов при написании DLL.
    Остальные проблемы мне кажутся не столь существенными - подумаешь нужно будет придумать что-то типа PE формата :mrgreen: . Разбирались, знаем :wink: .
  • я в этом не сильно смыслю, но теоретически можно бы "подгружать" именно исполняемый код... то есть открывать текст программы, наприимер на +40h, загружать его на метку dll_load_area, а затем прыгать на неё... ну муть конечно, но руботать должно :)
  • сори, не текст программы, а сам исполняемый файл.. очепятался :).. только надо будет узнать сколько кода подгружать, положение начала нужного кода и тд
  • Я как имею ввиду, что так сделать нельзя - в DLL'ке наверняка используются переменные, а при таком копировании обращение пойдет не по тем адресам.
  • halyavin, а я всё думал (но не искал :) ) - зачем эти релокейшены :) спасибо что разъяснил, теперь буду знать. и, кстати, сразу всё встало на свои места ;)
    насчет макросов и релок.таблиц - сделать можно, но лишь переопределением всех инструкций, в качестве операндов которых может быть переменная в памяти :-/ следовательно возрастут требования к памяти для компиляции (причём не на 1-2 байта). лучше действительно сделать маленькую прогу, которая по исходнику или бинарнику проходит и строит таблицу.
    с другой стороны, можно самим внести в FASM поддержку менуетовских DLL'ок :)
    in code we trust
  • Я уже думал над созданием макросов для всех команд - это не поможет, потому что средствами макроязыка нельзя получить параметры переданной переменной в памяти (используется ли смещение, сложение регистров и.т.д.) - это можно сделать только с помощью программы, да и то если программисты не будут сильно запутывать код с помощью equ, fix, и.т.д. Возможно придется даже вводить псевдо-макрос, который будет указывать в каких случаях нужно (или наоборот не нужно) генерировать релокейшен. Поскольку случаи типа mov eax,[esi+1011*nextlabel-1010*nextlabel] автоматически не учтешь.
  • Who is online

    Users browsing this forum: No registered users and 1 guest