Есть еще вариант:
Грузим dll путем обычного чтения файла в адресное пространство приложения, причем в то место, куда клиент захочет. Доступ к переменным внутри библиотеки делать, как в вирусах, через дельта смещение (обычно база образа записывается в ebp). Я так хотел zip-распаковщик сделать.
Менеджер DLL в MeOS
Нечто подобное используется в Linux. Но использование дельта-смещения замедляет работу. Поэтому этот вариант пойдет лишь на первое время.
Немного не согласен с willow, ИМХО Грузим dll путем обычного чтения файла в адресное пространство приложения, причем в то место, куда клиент захочет такие вещи дожны выполняться ядром или манагером ДЛЛ а не пользователем, потому что во превых длл подразумевает собой юзанье одновременно несколькими программами а не одной, а во вторых процесс работы с либой должен быть максимально прозрачен для юзеровой программы...
релокейшны... блин что то тяжко мне представляется сие действо, скорее всего за недостаточным пониманием работы ОС ...
Но ДЛЛ порабы давно сделать!!! ИМХО будущего в МеОС без либов не будет однозначно... а в длл можно спокойно пихать ГУИ компоненты
релокейшны... блин что то тяжко мне представляется сие действо, скорее всего за недостаточным пониманием работы ОС ...
Но ДЛЛ порабы давно сделать!!! ИМХО будущего в МеОС без либов не будет однозначно... а в длл можно спокойно пихать ГУИ компоненты
Tak libov ili dll?
В данном случае длл (динамических либов а не статических...)
я разочарован подобными настроениями...с добавлением DLL это все примет вид или винды (когда екзешник - килобайт 60, а длльки - мегов 27, типа IE6.0), или линукса (когда в каждом дистрибутиве при сборке возникает проблема версий даже общеупотребительных .so)....смысл программ на Asm-е (которые и запускаются в Минуэте) - один файл - одно приложение...чтобы программисты задумывались над оптимизацией...а библиотеки - статистические (.lib)....вот так
;------------------------------------------------
Это сообщение написал kiwi_mani_snova
;------------------------------------------------
;------------------------------------------------
Это сообщение написал kiwi_mani_snova
;------------------------------------------------
Ага, ты хочешь чтоб ось так и не продвигалась вперёд?
kiwi_mani_snova
Ну интересно, а ты себе представил прогу с нормальным GUI, что бы были в нём и листбоксы и этиты и вьюверы всякие??? и впихать всё это в одну прогу - так ты думал, скока это будет всё занимать? Вот я видел на личном примере - каждая компонента весит где то 1-2 килобайта (ну те что посложнее - 5-6 кил)... (это при ОбъектоОриентированном подходе)... и вот надо сделать прогу в которой дохренища всех этих гуи компонент - она ж весить будет дохрена... и тем более есть вещи которые будут одинаково выполнаться во всех прогах (ГУИ, Дисколвые операции, работа с памятью и прочим - то что в основном щас реализовано через ядро - хотя это не совсем оптиматьный вариант)....
ну если тебе прёт каждый раз одно и тоже пихать во все свои проги (о размере подумай)... то пожалуйста, карты тебе в руки....
а я думаю что без ДЛЛ в меоси не будет будущего!!!!
Ну интересно, а ты себе представил прогу с нормальным GUI, что бы были в нём и листбоксы и этиты и вьюверы всякие??? и впихать всё это в одну прогу - так ты думал, скока это будет всё занимать? Вот я видел на личном примере - каждая компонента весит где то 1-2 килобайта (ну те что посложнее - 5-6 кил)... (это при ОбъектоОриентированном подходе)... и вот надо сделать прогу в которой дохренища всех этих гуи компонент - она ж весить будет дохрена... и тем более есть вещи которые будут одинаково выполнаться во всех прогах (ГУИ, Дисколвые операции, работа с памятью и прочим - то что в основном щас реализовано через ядро - хотя это не совсем оптиматьный вариант)....
ну если тебе прёт каждый раз одно и тоже пихать во все свои проги (о размере подумай)... то пожалуйста, карты тебе в руки....
а я думаю что без ДЛЛ в меоси не будет будущего!!!!
вот и получается 2 варианта:
1) нет страничной поддержки, соответственно виртуальной памяти, код всего приложения висит в памяти...при обращении к DLL они то грузятся в память, то освобождают ее...куча прог использует кучу библиотек, а юзер не понимает, что же у него все тормозит...
2) все прекрасно работает..при обращении к коду "экзешника" или "длл-лек" недостающие страницы грузятся на лету, все шоколадно...программисту можно не думать ни о чем..смело писать на этом гребанном "C"....в результате код на ассемблере просто исчезает, из подключаемой кучи библиотек прога использует по 2-3 функции из каждой dll-ки (а их там по 40-50 в каждой)....сами dll-ки пухнут на глазах...и мы получаем очередную винду....
Вывод - на на кой хрен тогда нам это все нужно....(((....хотя, может, я чуть пессимистичен, и все будет не так плохо...
1) нет страничной поддержки, соответственно виртуальной памяти, код всего приложения висит в памяти...при обращении к DLL они то грузятся в память, то освобождают ее...куча прог использует кучу библиотек, а юзер не понимает, что же у него все тормозит...
2) все прекрасно работает..при обращении к коду "экзешника" или "длл-лек" недостающие страницы грузятся на лету, все шоколадно...программисту можно не думать ни о чем..смело писать на этом гребанном "C"....в результате код на ассемблере просто исчезает, из подключаемой кучи библиотек прога использует по 2-3 функции из каждой dll-ки (а их там по 40-50 в каждой)....сами dll-ки пухнут на глазах...и мы получаем очередную винду....
Вывод - на на кой хрен тогда нам это все нужно....(((....хотя, может, я чуть пессимистичен, и все будет не так плохо...
Куда это код на ассемблере исчезнет? Наоборот из С все будет переводится на ассемблер. А пихать в каждую прогу код jpeg'a меня не прикалывает. В ядре ему тоже, вроде, нечего делать...
Если тебе не нравится ни ситуация в windows ни ситуация в linux придумай правильную систему dll. Этим ты сослужишь хорошую службу. А я пока буду дописывать менеджер памяти (над сносной архитектурой которого пришлось не мало подумать).
Если тебе не нравится ни ситуация в windows ни ситуация в linux придумай правильную систему dll. Этим ты сослужишь хорошую службу. А я пока буду дописывать менеджер памяти (над сносной архитектурой которого пришлось не мало подумать).
правильная система dll - это когда переменные класса - одна либа, а на каждую функцию - по каждой отдельной либе...если брать аналогию с C++))))))))))))))))))))))))))
выход - написать очень жестко заранее заданную одну коллекцию - все сетевын функции - своя dll, вся графика - другая dll, и т.д.))) и никаких новых версий...)))))))))
Вот вчера вечером ковырялся в с--, потихоньку начинаю раздуплять сие творение Свинкса, вобщем понял что пока буду писать на нем - ИМХО оптимизация сносная да и размеры скомпиленных приложений маленькие... да и удобнее для моих задач (в планее ООП)...
вот какие идеи (и наброски) у меня возникли:
щас правда пока в длл я пихал одну функцию, поэтому мои соображения по поводу нескольхих функций в длл выложу ниже...
итак, что мы имеем...
вид ддл который я делал был на асме такой
компилируем это безобразие в FASM - получаем файл размером 23 байта (или 24 я не помню уже... но это не столь важно)...
назовём его test.dll для начала... и скопируем его на /HD/1/test.dll (я так делал, хотя с загрузкой в эмуляции оходу запарка)
итак, длл пробная есть...
теперь прога которая её будет юзать, в ней как раз рассмотрен прототип механизма работы с длл (конечно он не ходится для оптимальной работы да ещё и без страничной памяти но на первое время я думаю прокатит)
в результате получаем
загружаем кусок кода и test.dll в память размером sizeof(test.dll) и по адресу #buffer, передаем управление (загоняем в IP регистр адрес следующей команды на #buffer+0 {неявно вызовом CALL EBX} ... выполнение идёт по этому адресу до коменды ret (#buffer+sizeof(test.dll)-1 т.е. на коде 0xC3) и возвращается к адресу следующему за этой процедурой...
далее осовбождаем память из под длл (если необходимо... или перед завершением работы программы)...
вот и всё... это конечно тривиальный простейший случай, к тому же параметры в функцию не передаются....
но рабочий... (проверено, тока размер файла вручную пришлось вбивать )
на счёт передачи параметров даже ещё нет понятия
насчёт нескольких функций логично сделать заголовок файла длл, в котором будут находться названия процедр и их адреса что то типа такого
всё это дело компилируем
а в проге (или ядре) загружаем так к пирмеру
DllHandle=LoadDll('/hd/1/test.dll');
SPixel=GetProcAddrByName(DllHandle,'SetPixel');
if(SPixel) $call @SPixel; где @ - адрес (для удобства предствления .. не более, не путать с метками, это я для наглядности)
WText=GetProcAddrByIndex(DLLHandle,1);
if(WText) $call @WText;
...
ваши мнения?...
ебстественно лучше что бы это реализовано было в ядре а адрес Dll передавался через IPC например...
вот какие идеи (и наброски) у меня возникли:
щас правда пока в длл я пихал одну функцию, поэтому мои соображения по поводу нескольхих функций в длл выложу ниже...
итак, что мы имеем...
вид ддл который я делал был на асме такой
Code: Select all
use32
;begin proc
;допустим всеголишь надо отрисовать точечку на экране
mov eax,1
mov ebx,100
mov ecx,100
mov edx,0
int 0x40
ret
;end proc i dll
назовём его test.dll для начала... и скопируем его на /HD/1/test.dll (я так делал, хотя с загрузкой в эмуляции оходу запарка)
итак, длл пробная есть...
теперь прога которая её будет юзать, в ней как раз рассмотрен прототип механизма работы с длл (конечно он не ходится для оптимальной работы да ещё и без страничной памяти но на первое время я думаю прокатит)
Code: Select all
;dll_test.c--
#include "mclib2.h--"
;юзаются гуи контролы от Ивана Поддубного (респект за идею, у меня что то подобного в голове кружилось но на асме я так и не допер его сделать)
CMainWindow wnd;
struct TFile
{
dword Func,Blocks,Advanced,Buffer,OsMem;
char FileName[128];
};
TFile fileinfo;
fileinfo={8,1,1,#buffer,#osmem};
byte osmem[4096];
dword buffer; //указатель на адрес, куда будет загружена длл
void main()
{
fileinfo.FileName="/HD/1/test.dll",0; //правда я не понял почему компилер выдает ошибку здесь?
wnd.CMainWindow(... параметры); отрисовываем окошко
;теперь надо загрузить файл с длл, получить его размер
;кстати как узнать размер файла я не знаю, если есть идеи дайте знать
; //допустим получили размер файла
fileinfo.Buffer=MALLOC(GetFileSize(#fileinfo));
sys_tree_access(#fileinfo); //загружаем его в память
EBX=#buffer; // в ebx загружаем адрес процедуры из ддл
if(EBX){ //если либа загружена (адрес не равен нулю)
$call EBX //то передаем управление по этому адресу
}
FREE(#buffer); //выгружаем функцию
wnd.MainLoop(); //отрисовываем окно и отлавливаем события
}
загружаем кусок кода и test.dll в память размером sizeof(test.dll) и по адресу #buffer, передаем управление (загоняем в IP регистр адрес следующей команды на #buffer+0 {неявно вызовом CALL EBX} ... выполнение идёт по этому адресу до коменды ret (#buffer+sizeof(test.dll)-1 т.е. на коде 0xC3) и возвращается к адресу следующему за этой процедурой...
далее осовбождаем память из под длл (если необходимо... или перед завершением работы программы)...
вот и всё... это конечно тривиальный простейший случай, к тому же параметры в функцию не передаются....
но рабочий... (проверено, тока размер файла вручную пришлось вбивать )
на счёт передачи параметров даже ещё нет понятия
насчёт нескольких функций логично сделать заголовок файла длл, в котором будут находться названия процедр и их адреса что то типа такого
Code: Select all
;DLL HEADER
db 'MDLL'; header
dw 0001 ; header version для будущего.. (разные типы либов будет)
dd _DLL_Proc ; адрес списка процедур
dw _DLL_Count; количество процедур в списке
; поэтому можно будет обращаться как по индексу 0 .. Count-1 так и по названию функции
struc _DLLproc
{
.ProcName db ? имя процедуры типа 'PutPixelProc',0 ASCIIZ
.ProcAddr dd ? адрес процедуры
; .Params ? <-может и список параметров процедуры??? пока без параметров... но всё будет
}
теперь определяем таблицу
чтото типа такого
создаем массив типа
_DLL_Proc: //ссылка заголовка на массив
_DLLproc
типа такого .. (а вообще надо написать макрос, который будет сам всё это делать)
_DLLproc[0].ProcName='SetPixel';
_DLLproc[0].ProcAddr=SetPixel;
_DLLproc[1].ProcName='WriteText';
_DLLproc[1].ProcAddr=WriteText;
...
и так далее, незабыв в заголовок записать размер массива!
SetPixel:
..../// some code
ret
WriteText:
...// some code
ret
а в проге (или ядре) загружаем так к пирмеру
DllHandle=LoadDll('/hd/1/test.dll');
SPixel=GetProcAddrByName(DllHandle,'SetPixel');
if(SPixel) $call @SPixel; где @ - адрес (для удобства предствления .. не более, не путать с метками, это я для наглядности)
WText=GetProcAddrByIndex(DLLHandle,1);
if(WText) $call @WText;
...
ваши мнения?...
ебстественно лучше что бы это реализовано было в ядре а адрес Dll передавался через IPC например...
Одобряю!
Теперь дело надо передать на рассмотрение ув. Халявину, я правда понимаю что у него и так напряги с менеджером памяти, но хотя бы прикинуть механизм внедрения в ядро... выделить API функцию для работы с DLL... думаю дальше юудет проще...
Дадим ответ Билли!
Дадим ответ Билли!
Who is online
Users browsing this forum: No registered users and 29 guests