Менеджер DLL в MeOS

Mon Aug 21, 2006 11:21 pm

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

Mon Aug 21, 2006 11:34 pm

ещё идея пришла... Получать имя длл-ки , по нему строить полный путь, считать его crc32, и в дальнейшем оперировать с ним. Но всё же имя где то надо хранить

Mon Aug 21, 2006 11:51 pm

Я думаю надо делать так.

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

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

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

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

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

Mon Aug 21, 2006 11:52 pm

Я думаю надо делать так.

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

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

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

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

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

Tue Aug 22, 2006 12:12 am

1) хранить в ини файле слишком медленно (пусть и системные.. смысла в этом нет)
2) думаю лучше относильные пути брать как в *nix системах. Т.е. "./" это текущая папка, "../" родительская, "/" корень всей системы (для коос дальше должно быть что-то вроде "rd/1/..."

Tue Aug 22, 2006 12:41 am

1)Почему медленно ?Один раз загрузил драйверы и пользуйся ими сколько хочешь.Зачем их каждый раз-то грузить.Да и драйверов не так много.Звук,видео(пока нет) да и всё.А если устройства специфические так их тоже немного будет.

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

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

Tue Aug 22, 2006 1:05 am

я наверно даже несколько не об этом и спрашивал... если хранить в ини файле список "драйверов" для загрузки при старте системы то нормально

Wed Aug 23, 2006 12:01 am

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

Тут горячие дискусии по поводу того создавать свой формата динамических библиотек или использования уже используемых библиотек в часности говорилось о ELF/COFF/OMF. Я уверен что стандартизация путь к светлому будущему, не зря ведь придумали ГОСТы

Ну а если кто-то (не в обиду сказанно) боится что Колибри без "уникальной класной игрушки" перестанет выделяться среди других систем, то это врядли Колибри на дискете (есть и другие дискет. системы но они слабее), а все остальные на харде, Колибри на полную катушку использует ассемблер, эти черты врядли сможет заменить какая-либо другая операционная система разве что, Колибри64

Tue Oct 10, 2006 9:30 am

diamond
Можно встроить в ядро функцию распаковки для загрузки
сжатых COFF программ? Например stdcall unpack, input, output.
Это должна быть внутренняя функция, не для приложений.

Tue Oct 10, 2006 10:15 am

Сжатые COFF программы? Это что еще за зверь? Я всегда думал, что COFF это объектный формат, и если в нем есть какое-то сжатие, то оно должно работать на принципе самораспаковки и внешней распаковке не поддаваться из-за многообразия алгоритмов распаковки.

Tue Oct 10, 2006 10:36 am

COFF - для ДЛЛ и линкующихся к ним программ. А сжатие для экономии места. Если в программе объявить функцию или переменную как extrn в таблице символов COFF будет её имя. Это готовая таблица импорта.

Tue Oct 10, 2006 12:05 pm

diamond
Можно вызывать из ядра ф. 70.0 и 70.5 ?

Tue Oct 10, 2006 6:14 pm

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: Select all

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

Tue Oct 10, 2006 8:09 pm

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

Tue Oct 10, 2006 9:53 pm

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

Менеджер DLL в MeOS

Who is online