Page 2 of 15

Posted: Thu May 26, 2005 1:22 pm
by willow
Есть еще вариант:
Грузим dll путем обычного чтения файла в адресное пространство приложения, причем в то место, куда клиент захочет. Доступ к переменным внутри библиотеки делать, как в вирусах, через дельта смещение (обычно база образа записывается в ebp). Я так хотел zip-распаковщик сделать.

Posted: Thu May 26, 2005 1:38 pm
by halyavin
Нечто подобное используется в Linux. Но использование дельта-смещения замедляет работу. Поэтому этот вариант пойдет лишь на первое время.

Posted: Fri May 27, 2005 12:59 pm
by Anton
Немного не согласен с willow, ИМХО Грузим dll путем обычного чтения файла в адресное пространство приложения, причем в то место, куда клиент захочет такие вещи дожны выполняться ядром или манагером ДЛЛ а не пользователем, потому что во превых длл подразумевает собой юзанье одновременно несколькими программами а не одной, а во вторых процесс работы с либой должен быть максимально прозрачен для юзеровой программы...

релокейшны... блин что то тяжко мне представляется сие действо, скорее всего за недостаточным пониманием работы ОС :)...

Но ДЛЛ порабы давно сделать!!! ИМХО будущего в МеОС без либов не будет однозначно... а в длл можно спокойно пихать ГУИ компоненты

Posted: Fri May 27, 2005 6:58 pm
by Chugumoto
Tak libov ili dll?

Posted: Sat May 28, 2005 9:02 pm
by Anton
В данном случае длл (динамических либов а не статических...)

Posted: Tue Jun 07, 2005 6:26 pm
by Guest
я разочарован подобными настроениями...с добавлением DLL это все примет вид или винды (когда екзешник - килобайт 60, а длльки - мегов 27, типа IE6.0), или линукса (когда в каждом дистрибутиве при сборке возникает проблема версий даже общеупотребительных .so)....смысл программ на Asm-е (которые и запускаются в Минуэте) - один файл - одно приложение...чтобы программисты задумывались над оптимизацией...а библиотеки - статистические (.lib)....вот так
;------------------------------------------------
Это сообщение написал kiwi_mani_snova
;------------------------------------------------

Posted: Tue Jun 07, 2005 10:24 pm
by ipr
Ага, ты хочешь чтоб ось так и не продвигалась вперёд?

Posted: Wed Jun 08, 2005 1:40 pm
by FreGL
kiwi_mani_snova
Ну интересно, а ты себе представил прогу с нормальным GUI, что бы были в нём и листбоксы и этиты и вьюверы всякие??? и впихать всё это в одну прогу - так ты думал, скока это будет всё занимать? Вот я видел на личном примере - каждая компонента весит где то 1-2 килобайта (ну те что посложнее - 5-6 кил)... (это при ОбъектоОриентированном подходе)... и вот надо сделать прогу в которой дохренища всех этих гуи компонент - она ж весить будет дохрена... и тем более есть вещи которые будут одинаково выполнаться во всех прогах (ГУИ, Дисколвые операции, работа с памятью и прочим - то что в основном щас реализовано через ядро - хотя это не совсем оптиматьный вариант)....

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

а я думаю что без ДЛЛ в меоси не будет будущего!!!!

Posted: Wed Jun 08, 2005 5:38 pm
by kiwi_mani_snova
вот и получается 2 варианта:
1) нет страничной поддержки, соответственно виртуальной памяти, код всего приложения висит в памяти...при обращении к DLL они то грузятся в память, то освобождают ее...куча прог использует кучу библиотек, а юзер не понимает, что же у него все тормозит...
2) все прекрасно работает..при обращении к коду "экзешника" или "длл-лек" недостающие страницы грузятся на лету, все шоколадно...программисту можно не думать ни о чем..смело писать на этом гребанном "C"....в результате код на ассемблере просто исчезает, из подключаемой кучи библиотек прога использует по 2-3 функции из каждой dll-ки (а их там по 40-50 в каждой)....сами dll-ки пухнут на глазах...и мы получаем очередную винду....
Вывод - на на кой хрен тогда нам это все нужно....(((....хотя, может, я чуть пессимистичен, и все будет не так плохо...

Posted: Wed Jun 08, 2005 7:14 pm
by halyavin
Куда это код на ассемблере исчезнет? Наоборот из С все будет переводится на ассемблер. А пихать в каждую прогу код jpeg'a меня не прикалывает. В ядре ему тоже, вроде, нечего делать...
Если тебе не нравится ни ситуация в windows ни ситуация в linux придумай правильную систему dll. Этим ты сослужишь хорошую службу. А я пока буду дописывать менеджер памяти (над сносной архитектурой которого пришлось не мало подумать). :wink:

Posted: Wed Jun 08, 2005 8:14 pm
by kiwi_mani_snova
правильная система dll - это когда переменные класса - одна либа, а на каждую функцию - по каждой отдельной либе...если брать аналогию с C++))))))))))))))))))))))))))

Posted: Wed Jun 08, 2005 8:18 pm
by kiwi_mani_snova
выход - написать очень жестко заранее заданную одну коллекцию - все сетевын функции - своя dll, вся графика - другая dll, и т.д.))) и никаких новых версий...)))))))))

Posted: Tue Jul 19, 2005 11:37 am
by FreGL
Вот вчера вечером ковырялся в с--, потихоньку начинаю раздуплять сие творение Свинкса, вобщем понял что пока буду писать на нем - ИМХО оптимизация сносная да и размеры скомпиленных приложений маленькие... да и удобнее для моих задач (в планее ООП)...

вот какие идеи (и наброски) у меня возникли:

щас правда пока в длл я пихал одну функцию, поэтому мои соображения по поводу нескольхих функций в длл выложу ниже...

итак, что мы имеем...

вид ддл который я делал был на асме такой

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
компилируем это безобразие в FASM - получаем файл размером 23 байта (или 24 я не помню уже... но это не столь важно)...
назовём его 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 например...

Posted: Tue Jul 19, 2005 1:12 pm
by willow
Одобряю!

Posted: Wed Jul 20, 2005 10:23 am
by FreGL
Теперь дело надо передать на рассмотрение ув. Халявину, я правда понимаю что у него и так напряги с менеджером памяти, но хотя бы прикинуть механизм внедрения в ядро... выделить API функцию для работы с DLL... думаю дальше юудет проще...

Дадим ответ Билли!