Board.KolibriOS.org

Есть ли в природе какие-то проекты, которые реализуют динамические библиотеки в MeOS? Хотелось бы посмотреть, оценить.

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 не знает, а потому сгенерировать эту таблицу автоматически нельзя. А с помощью макросов это сделать невозможно (кто меня переубедит ). А значит с написанием DLL'ек на FASM'e будут проблемы. Нужно написать программу, которая по ассемблерному исходнику сгенерирует таблицу релокейшенов (кто это сделает? ). И это также будет ограничивать применение макросов при написании DLL.
Остальные проблемы мне кажутся не столь существенными - подумаешь нужно будет придумать что-то типа PE формата . Разбирались, знаем .

я в этом не сильно смыслю, но теоретически можно бы "подгружать" именно исполняемый код... то есть открывать текст программы, наприимер на +40h, загружать его на метку dll_load_area, а затем прыгать на неё... ну муть конечно, но руботать должно

сори, не текст программы, а сам исполняемый файл.. очепятался .. только надо будет узнать сколько кода подгружать, положение начала нужного кода и тд

Я как имею ввиду, что так сделать нельзя - в DLL'ке наверняка используются переменные, а при таком копировании обращение пойдет не по тем адресам.

halyavin, а я всё думал (но не искал ) - зачем эти релокейшены спасибо что разъяснил, теперь буду знать. и, кстати, сразу всё встало на свои места
насчет макросов и релок.таблиц - сделать можно, но лишь переопределением всех инструкций, в качестве операндов которых может быть переменная в памяти :-/ следовательно возрастут требования к памяти для компиляции (причём не на 1-2 байта). лучше действительно сделать маленькую прогу, которая по исходнику или бинарнику проходит и строит таблицу.
с другой стороны, можно самим внести в FASM поддержку менуетовских DLL'ок

Я уже думал над созданием макросов для всех команд - это не поможет, потому что средствами макроязыка нельзя получить параметры переданной переменной в памяти (используется ли смещение, сложение регистров и.т.д.) - это можно сделать только с помощью программы, да и то если программисты не будут сильно запутывать код с помощью equ, fix, и.т.д. Возможно придется даже вводить псевдо-макрос, который будет указывать в каких случаях нужно (или наоборот не нужно) генерировать релокейшен. Поскольку случаи типа mov eax,[esi+1011*nextlabel-1010*nextlabel] автоматически не учтешь.