Board.KolibriOS.org

Official KolibriOS board
It is currently Thu Oct 29, 2020 11:17 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 216 posts ]  Go to page Previous 1 2 3 4 515 Next
Author Message
 Post subject:
PostPosted: Thu May 26, 2005 1:22 pm 
Offline

Joined: Wed May 25, 2005 8:52 am
Posts: 147
Есть еще вариант:
Грузим dll путем обычного чтения файла в адресное пространство приложения, причем в то место, куда клиент захочет. Доступ к переменным внутри библиотеки делать, как в вирусах, через дельта смещение (обычно база образа записывается в ebp). Я так хотел zip-распаковщик сделать.


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


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

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

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


Top
   
 Post subject:
PostPosted: Fri May 27, 2005 6:58 pm 
Tak libov ili dll?


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


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


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


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

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

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


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


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


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


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


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

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

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

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

вид ддл который я делал был на асме такой
Code:
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:
;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:

;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 например...


Top
   
 Post subject:
PostPosted: Tue Jul 19, 2005 1:12 pm 
Offline

Joined: Wed May 25, 2005 8:52 am
Posts: 147
Одобряю!


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

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 216 posts ]  Go to page Previous 1 2 3 4 515 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited