Менеджер DLL в MeOS

Discussing libraries simplifying applications development
  • Нечто подобное используется в Linux. Но использование дельта-смещения замедляет работу. Поэтому этот вариант пойдет лишь на первое время.
  • Немного не согласен с willow, ИМХО Грузим dll путем обычного чтения файла в адресное пространство приложения, причем в то место, куда клиент захочет такие вещи дожны выполняться ядром или манагером ДЛЛ а не пользователем, потому что во превых длл подразумевает собой юзанье одновременно несколькими программами а не одной, а во вторых процесс работы с либой должен быть максимально прозрачен для юзеровой программы...

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

    Но ДЛЛ порабы давно сделать!!! ИМХО будущего в МеОС без либов не будет однозначно... а в длл можно спокойно пихать ГУИ компоненты
  • Tak libov ili dll?
  • В данном случае длл (динамических либов а не статических...)
  • я разочарован подобными настроениями...с добавлением DLL это все примет вид или винды (когда екзешник - килобайт 60, а длльки - мегов 27, типа IE6.0), или линукса (когда в каждом дистрибутиве при сборке возникает проблема версий даже общеупотребительных .so)....смысл программ на Asm-е (которые и запускаются в Минуэте) - один файл - одно приложение...чтобы программисты задумывались над оптимизацией...а библиотеки - статистические (.lib)....вот так
    ;------------------------------------------------
    Это сообщение написал kiwi_mani_snova
    ;------------------------------------------------
  • Ага, ты хочешь чтоб ось так и не продвигалась вперёд?
  • kiwi_mani_snova
    Ну интересно, а ты себе представил прогу с нормальным GUI, что бы были в нём и листбоксы и этиты и вьюверы всякие??? и впихать всё это в одну прогу - так ты думал, скока это будет всё занимать? Вот я видел на личном примере - каждая компонента весит где то 1-2 килобайта (ну те что посложнее - 5-6 кил)... (это при ОбъектоОриентированном подходе)... и вот надо сделать прогу в которой дохренища всех этих гуи компонент - она ж весить будет дохрена... и тем более есть вещи которые будут одинаково выполнаться во всех прогах (ГУИ, Дисколвые операции, работа с памятью и прочим - то что в основном щас реализовано через ядро - хотя это не совсем оптиматьный вариант)....

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

    а я думаю что без ДЛЛ в меоси не будет будущего!!!!
  • вот и получается 2 варианта:
    1) нет страничной поддержки, соответственно виртуальной памяти, код всего приложения висит в памяти...при обращении к DLL они то грузятся в память, то освобождают ее...куча прог использует кучу библиотек, а юзер не понимает, что же у него все тормозит...
    2) все прекрасно работает..при обращении к коду "экзешника" или "длл-лек" недостающие страницы грузятся на лету, все шоколадно...программисту можно не думать ни о чем..смело писать на этом гребанном "C"....в результате код на ассемблере просто исчезает, из подключаемой кучи библиотек прога использует по 2-3 функции из каждой dll-ки (а их там по 40-50 в каждой)....сами dll-ки пухнут на глазах...и мы получаем очередную винду....
    Вывод - на на кой хрен тогда нам это все нужно....(((....хотя, может, я чуть пессимистичен, и все будет не так плохо...
  • Куда это код на ассемблере исчезнет? Наоборот из С все будет переводится на ассемблер. А пихать в каждую прогу код jpeg'a меня не прикалывает. В ядре ему тоже, вроде, нечего делать...
    Если тебе не нравится ни ситуация в windows ни ситуация в linux придумай правильную систему dll. Этим ты сослужишь хорошую службу. А я пока буду дописывать менеджер памяти (над сносной архитектурой которого пришлось не мало подумать). :wink:
  • правильная система dll - это когда переменные класса - одна либа, а на каждую функцию - по каждой отдельной либе...если брать аналогию с C++))))))))))))))))))))))))))
  • выход - написать очень жестко заранее заданную одну коллекцию - все сетевын функции - своя dll, вся графика - другая dll, и т.д.))) и никаких новых версий...)))))))))
  • Вот вчера вечером ковырялся в с--, потихоньку начинаю раздуплять сие творение Свинкса, вобщем понял что пока буду писать на нем - ИМХО оптимизация сносная да и размеры скомпиленных приложений маленькие... да и удобнее для моих задач (в планее ООП)...

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

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

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

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

    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 например...
  • Одобряю!
  • Теперь дело надо передать на рассмотрение ув. Халявину, я правда понимаю что у него и так напряги с менеджером памяти, но хотя бы прикинуть механизм внедрения в ядро... выделить API функцию для работы с DLL... думаю дальше юудет проще...

    Дадим ответ Билли!
  • Who is online

    Users browsing this forum: No registered users and 29 guests