Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Ср июн 20, 2018 10:37 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 216 сообщений ]  На страницу 1 2 3 4 515 След.
Автор Сообщение
 Заголовок сообщения: Менеджер DLL в MeOS
СообщениеДобавлено: Чт май 19, 2005 8:14 pm 
Есть ли в природе какие-то проекты, которые реализуют динамические библиотеки в MeOS? Хотелось бы посмотреть, оценить.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Чт май 19, 2005 9:24 pm 
Не в сети
Site Founder
Аватара пользователя

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 689
MenuetOS C Library: http://board.flatassembler.net/topic.php?t=2952
Других вроде пока нет, хотя в MFAR'е я буду делать поддержку плагинов, так что и над DLL подумаю. Точнее говоря, плагины и будут DLL.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пт май 20, 2005 12:28 pm 
mike.dld
Слушай, а ты не сможешь создать топик про плагины для MFar'а?Может кто-чем сможет помочь в реализации этой затеи.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Пт май 20, 2005 2:17 pm 
Не в сети
Site Founder
Аватара пользователя

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 689
Пока что помочь может только менеждер памяти :) А дальше будем думать


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб май 21, 2005 6:26 pm 
А что, если попробовать интегрировать возможность реализации DLL в ядро? Тогда к DLL обращаться через IPC будет не сложно, но проблема в передаче параметров. После реализации открываются большие перспективы для MeOS как модульной системы (а не так, что все ядро одним файлом).


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Сб май 21, 2005 6:56 pm 
Не в сети
Site Founder
Аватара пользователя

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 689
Приблизительно так и должно быть. И в любом случае так будет. Но не сейчас. Я могу свободно представить себе, насколько возрастёт потенциал ядра с введением DLL, но делается всё не в один день.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб май 21, 2005 8:50 pm 
Не в сети

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 92
Цитата:
Тогда к DLL обращаться через IPC будет не сложно, но проблема в передаче параметров.

А в миос что какие то особенные длл планируются? =) Зачем к длл обращаться через IPC? %)

_________________
Причины и следствия


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вс май 22, 2005 7:21 pm 
Ну, вообще, да, IPC тут ни к чему :)


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Ср май 25, 2005 4:29 pm 
Привет всем! Я тоже думал на реализацией 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х либах...

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

вот так я представляю процесс... если у кого каике то идеи получше буду рад их прочитать тут


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Ср май 25, 2005 6:17 pm 
Ты знаешь как устроены DLL в винде? Рискну напомнить, что DLL'ки в отличие от программ не всегда загружаются по тому адресу, по которому они скомпилированны. А значит им нужна таблица релокейшенов, которые определяют какие байты нужно править, чтобы DLL работала при загрузке по другому адресу. Но сделать таблицу релокейшенов в FASM'e нельзя - он может ее делать только автоматически для тех форматов исполняемых файлов, где она используется (DLL'ки в Windows например). Но ничего о Менуете FASM не знает, а потому сгенерировать эту таблицу автоматически нельзя. А с помощью макросов это сделать невозможно (кто меня переубедит :mrgreen: ). А значит с написанием DLL'ек на FASM'e будут проблемы. Нужно написать программу, которая по ассемблерному исходнику сгенерирует таблицу релокейшенов (кто это сделает? :wink: ). И это также будет ограничивать применение макросов при написании DLL.
Остальные проблемы мне кажутся не столь существенными - подумаешь нужно будет придумать что-то типа PE формата :mrgreen: . Разбирались, знаем :wink: .


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Ср май 25, 2005 8:14 pm 
я в этом не сильно смыслю, но теоретически можно бы "подгружать" именно исполняемый код... то есть открывать текст программы, наприимер на +40h, загружать его на метку dll_load_area, а затем прыгать на неё... ну муть конечно, но руботать должно :)


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Ср май 25, 2005 8:26 pm 
сори, не текст программы, а сам исполняемый файл.. очепятался :).. только надо будет узнать сколько кода подгружать, положение начала нужного кода и тд


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Ср май 25, 2005 8:40 pm 
Я как имею ввиду, что так сделать нельзя - в DLL'ке наверняка используются переменные, а при таком копировании обращение пойдет не по тем адресам.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Ср май 25, 2005 11:36 pm 
Не в сети
Site Founder
Аватара пользователя

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

_________________
in code we trust


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


Вернуться к началу
   
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 216 сообщений ]  На страницу 1 2 3 4 515 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB