Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Jan 18, 2020 3:16 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 216 posts ]  Go to page Previous 19 10 11 12 1315 Next
Author Message
 Post subject:
PostPosted: Mon Aug 21, 2006 11:21 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
Люди, есть вопрос. Я так между делом о длл-ках размышляю... Как можно идентифицировать библиотеки? Вариантов может быть придумано уйма, но какой лучше взять я не знаю... Тут приведу несколько... Кто может, приведите свои...
1) либы в своём теле содержат своё имя, путь к которому загрузчик может вычислить. При загрузке сверяется это имя с требуемым, и если совпадает выдавать указатель на загруженную копию (минус: одноимённые длл-ки из разных папок отдыхают, чтобы поменять имя файла с либой надо менять имя внутри либы)
2) тоже что и в первом но хранить весь путь (первый минус отпадает, но зато при изменении прописки файла надо менять путь внутри либы, а так же койкакие проблемы с выделением пространства под путь)
3) пользуясь функциями менеджера памяти сохранять полный путь к либе в куче процесса (мне такое решение почему-то кажется не очень красивым)
4) считать что в теле программы имя либы где то храниться и меняться не будет, соответственно привызове функции загрузки либы брать указатель на путь и с ним работать (минус: реализация "относительных" путей ложится полностью на пользователя...)
5) пришла мысль, но уже ушла, не застав меня :/


Top
   
 Post subject:
PostPosted: Mon Aug 21, 2006 11:34 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
ещё идея пришла... Получать имя длл-ки , по нему строить полный путь, считать его crc32, и в дальнейшем оперировать с ним. Но всё же имя где то надо хранить


Top
   
 Post subject:
PostPosted: Mon Aug 21, 2006 11:51 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Я думаю надо делать так.

1) Для системных dll.

После установки системы(или её загрузки с внешнего носителя),в каком-то ini файле прописываются директории где будут храниться СИСТЕМНЫЕ dll.

2)Если dll не системная,а принадлежит какой-то программе.

dll должна находиться либо в той же директории где и программа,либо в относительной директории.Тоесть дериктория,где находиться программа считается "/" ,а дериктория библиотеки,к примеру, "/codecs/dlls/".
В этом случае ОТНОСИТЕЛЬНАЯ дериктория dll прописана в программе,но при этом программу можно располагать в лубой дериктории и на любом диске.

Думаю,что лучшего варианта не придумать.


Top
   
 Post subject:
PostPosted: Mon Aug 21, 2006 11:52 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Я думаю надо делать так.

1) Для системных dll.

После установки системы(или её загрузки с внешнего носителя),в каком-то ini файле прописываются директории где будут храниться СИСТЕМНЫЕ dll.

2)Если dll не системная,а принадлежит какой-то программе.

dll должна находиться либо в той же директории где и программа,либо в относительной директории.Тоесть дериктория,где находиться программа считается "/" ,а дериктория библиотеки,к примеру, "/codecs/dlls/".
В этом случае ОТНОСИТЕЛЬНАЯ дериктория dll прописана в программе,но при этом программу можно располагать в лубой дериктории и на любом диске.

Думаю,что лучшего варианта не придумать.


Top
   
 Post subject:
PostPosted: Tue Aug 22, 2006 12:12 am 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
1) хранить в ини файле слишком медленно (пусть и системные.. смысла в этом нет)
2) думаю лучше относильные пути брать как в *nix системах. Т.е. "./" это текущая папка, "../" родительская, "/" корень всей системы (для коос дальше должно быть что-то вроде "rd/1/..."


Top
   
 Post subject:
PostPosted: Tue Aug 22, 2006 12:41 am 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
1)Почему медленно ?Один раз загрузил драйверы и пользуйся ими сколько хочешь.Зачем их каждый раз-то грузить.Да и драйверов не так много.Звук,видео(пока нет) да и всё.А если устройства специфические так их тоже немного будет.

Ини файл можно и не создавать,если жестко прописать дериктории(к примеру rd/1/drivers/).

2) пусть будет как в nix системах.Я просто имел ввиду,что дериктория,где находиться программа,должна быть корневой для dll.


Top
   
 Post subject:
PostPosted: Tue Aug 22, 2006 1:05 am 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
я наверно даже несколько не об этом и спрашивал... если хранить в ини файле список "драйверов" для загрузки при старте системы то нормально


Top
   
 Post subject:
PostPosted: Wed Aug 23, 2006 12:01 am 
[willow quote]
Практически закончил загрузчик ELF и COFF на уровне приложения (в виде включаемого файла). Пока что умеет грузить либу в произвольное место, осуществлять релокацию и возвращать адрес функции по ее названию. Предоставляет такие функции:
[/quote]
Очень интерестно. А где можно исходники скачать?

Тут горячие дискусии по поводу того создавать свой формата динамических библиотек или использования уже используемых библиотек в часности говорилось о ELF/COFF/OMF. Я уверен что стандартизация путь к светлому будущему, не зря ведь придумали ГОСТы ;) Ну а если кто-то (не в обиду сказанно) боится что Колибри без "уникальной класной игрушки" перестанет выделяться среди других систем, то это врядли Колибри на дискете (есть и другие дискет. системы но они слабее), а все остальные на харде, Колибри на полную катушку использует ассемблер, эти черты врядли сможет заменить какая-либо другая операционная система разве что, Колибри64 :)


Top
   
 Post subject:
PostPosted: Tue Oct 10, 2006 9:30 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond
Можно встроить в ядро функцию распаковки для загрузки
сжатых COFF программ? Например stdcall unpack, input, output.
Это должна быть внутренняя функция, не для приложений.


Top
   
 Post subject:
PostPosted: Tue Oct 10, 2006 10:15 am 
Сжатые COFF программы? Это что еще за зверь? Я всегда думал, что COFF это объектный формат, и если в нем есть какое-то сжатие, то оно должно работать на принципе самораспаковки и внешней распаковке не поддаваться из-за многообразия алгоритмов распаковки.


Top
   
 Post subject:
PostPosted: Tue Oct 10, 2006 10:36 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
COFF - для ДЛЛ и линкующихся к ним программ. А сжатие для экономии места. Если в программе объявить функцию или переменную как extrn в таблице символов COFF будет её имя. Это готовая таблица импорта.


Top
   
 Post subject:
PostPosted: Tue Oct 10, 2006 12:05 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond
Можно вызывать из ядра ф. 70.0 и 70.5 ?


Top
   
 Post subject:
PostPosted: Tue Oct 10, 2006 6:14 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Serge wrote:
Можно встроить в ядро функцию распаковки для загрузки
сжатых COFF программ? Например stdcall unpack, input, output.
Это должна быть внутренняя функция, не для приложений.

Можно при условии, что мы определились с форматом сжатия. Но лучше делать самораспаковку (встраивать код распаковки - как правило, относительно небольшой - в саму программу, преимущество этого способа в том, что мы не ограничены используемым алгоритмом сжатия, а в разных случаях оптимальны разные алгоритмы).
Serge wrote:
Можно вызывать из ядра ф. 70.0 и 70.5 ?

а) Если заранее известно, на каком устройстве находится файл и известен относительный путь (например, загружается /rd/1/char.mt): вызываем функцию fs_RamdiskRead, fs_FloppyRead или fs_HdRead для 70.0, fs_RamdiskGetFileInfo, fs_FloppyGetFileInfo, fs_HdGetFileInfo соответственно; параметры указаны переж кодом функции (rd.inc, fat12.inc, fat32.inc соответственно).
б) Если требуется разбор строки в стиле 70-й функции:
Code:
pushad
push eax
mov eax, fileinfo_block - std_application_base_address
call file_system_lfn
pop eax
popad
; eax и ebx установлены в соответствии со спецификацией

Только в fileinfo_block следует из адреса тоже вычесть std_application_base_address

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Tue Oct 10, 2006 8:09 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Я могу доработать mtappack так, чтобы он сжимал не только программы, но и односекционные COFF согласованно с кодом из dll.inc (насколько я понимаю, entry point там есть как символ с именем START, так что распаковщик спокойно может внедриться куда надо). Для справки: mtappack перебирает 6 вариантов упаковки (3 для aPLib - в последних версиях только для файлов <64Kb, 3 для LZMA). Размер кода распаковки сильно варьируется в зависимости от многих условий, но по порядку величины для aPLib ~100-200 байт, для LZMA ~500-600.


Top
   
 Post subject:
PostPosted: Tue Oct 10, 2006 9:53 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Самараспаковка не нужна. Иначе не удасться одновременно грузить программу и ДЛЛ. Идея в том, чтобы загрузчик делал всё сам, а сжатие для экономии места. Библиотеки можно будет подгружать и вручную но тогда придётся получать указатели через get_proc(). Для сжатого COFF хватит заголовка и размера исходного файла.
dd 'COFF'
dd image_size
Библиотеки можно искать сначала в папке откуда грузится приложение, потом на /rd/1 или наооборот


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 216 posts ]  Go to page Previous 19 10 11 12 1315 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


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:  
cron
Powered by phpBB® Forum Software © phpBB Limited