Board.KolibriOS.org

Posted: **Tue Oct 10, 2006 10:24 pm**

Идея такая. Программы будут похожи на существующие драйверы но всё
импортируемые функции будут объявлятся как extrn. Метка IMPORTS
станет массивом указателей на имена загружаемых библиотек, имя будет
добавляться к пути программы или к /rd/1/ и оттуда загружаться
библиотека. Строки с именами импортируемых функций и указатели на функции
и данные больше не нужны. В ДЛЛ останется метка EXPORTS и массивы как в
core/exports. Тогда можно будет получить адрес функции по имени через
get_proc. При загрузке библиотеки вручную система будет возвращать
адрес таблицы эспортируемых функций, так что код get_proc может быть в
виде inc файла. При автоматической загрузке адрес таблицы экспорта
будет записываться в данные программы как сейчас заносятся указатели
на функции, тогда можно будет вызывать get_proc для загруженных
библиотек. В окончательном виде программы и библиотеки будут состоять
из двух секций - одна код и инициализированные данные, вторая
неинициализированные данные.

Posted: **Wed Oct 11, 2006 4:42 pm**

Самораспаковка не нужна. Иначе не удастся одновременно грузить программу и ДЛЛ.

Прекрасно удастся. Схема загрузки неупакованной DLL: загрузчик читает файл DLL, производит некоторые действия по настройке, вызывает точку входа, выполняет оставшиеся действия по настройке и берёт адреса экспортируемых функций, подсовывая их программе, а уже потом программа эти функции вызывает. Схема загрузки упакованной DLL: с точки зрения загрузчика ничего не меняется; но вместо OEP (original entry point) точка входа указывает на распаковщик, который производит собственно распаковку кода/данных и передаёт управление на OEP. Таким образом, к моменту начала программы все функции из DLL уже распакованы и настроены. Ну а потом уже программа может быть упакованной и распаковываться как обычно (ну разве что коду распаковщика придётся дополнительно обрабатывать импорт).

Идея в том, чтобы загрузчик делал всё сам, а сжатие для экономии места

Я за - мне же меньше работы по написанию/отладке кода нового распаковщика

. Только в заголовке нужно ещё указывать метод сжатия и параметры сжатия, но их формально можно отнести к упакованным данным.
Только нужна, видимо, не только процедура распаковки, но и программа упаковки. С интерфейсом распаковки понятно - на входе абстрактные данные, на выходе абстрактные данные. А вот программе упаковки придётся паковать вполне конкретный файл - его паковать как просто файл с данными или имеющий некоторую структуру? И на выходе давать просто файл с данными или файл с некоторой структурой?

Posted: **Wed Oct 11, 2006 4:54 pm**

Cхема с самораспаковкой по-моёму будет слишком сложна в отладке и не ясно как она будет работать если надо прилинковать несколько библиотек и программы будут из нескольких секций.
Для упаковщика наверное лучше выбрать один алгоритм сжатия и сделать его стандартным. Входные данные просто файл. На выходе сжатый файл с небольшим заголовком. В нём обязательно должен быть размер исходного файла. Если делать разные алгоритмы упаковки то должно быть поле с типом упаковки. В таком случае хватит 12 байт. Сигнатура "COFF", исходный размер файла, тип упаковщика.

Posted: **Wed Oct 11, 2006 5:02 pm**

С отладкой, конечно, будут некоторые проблемы, но они вполне решаемы. Между прочим, большинство упаковщиков под Windows поддерживают DLL-ки без всякой помощи со стороны ядра. Но вроде бы мы договорились производить распаковку в ядре, а тогда задача сильно упрощается.
Про тип упаковки: ну вообще-то там байта хватит...

Posted: **Wed Oct 11, 2006 8:15 pm**

Сложно будет отладить загрузчик. И непонятно как автоматически связать самораспаковывающийся файл. С PE проще, там файл - образ программы в памяти. У COFF нарушено выравнивание секций, его приходится грузить в промежуточный буфер и там проводить настройку релоков.

Posted: **Thu Oct 12, 2006 11:39 am**

Готов абстрактный упаковщик/распаковщик
http://diamondz.land.ru/unpacker.inc - включаемый файл распаковщика, требует kglobals.inc
http://diamondz.land.ru/kunpack.exe - распаковщик-программа для Windows
http://diamondz.land.ru/kpack.exe - Windows-упаковщик
http://diamondz.land.ru/kpack - Kolibri-упаковщик
http://diamondz.land.ru/kpack_src.7z http://diamondz.land.ru/kpack_kolibri_src.7z - исходники

Posted: **Thu Oct 12, 2006 1:45 pm**

Вообще-то он может быть полезным не только для упаковки DLL/драйверов, но и для скинов (default.skn сжимается с ~7.5K до 949 байт!) и для упаковки 32-битной части самого ядра (по предварительным подсчётам, получаем сжатие примерно в 2 раза).

Posted: **Thu Oct 12, 2006 5:32 pm**

По-моему жать ядро не стоит. Иногда загрузку приходится проходить пошагово в Боше. Сжатие будет только мешать. А вот сжимать всякую графику очень хорошо

Posted: **Thu Oct 12, 2006 5:45 pm**

Для отладки можно и не сжимать. А для дистрибутивов само то, на дискете лишних 50 кб не бывает

Posted: **Mon Oct 16, 2006 3:32 pm**

Полуэкспериментальный упаковщик ядра: требуется ядро ревизии как минимум 183:
http://diamondz.land.ru/kerpack
http://diamondz.land.ru/kerpack_src.7z
Упакованное ядро ревизии 183 можно взять с http://diamondz.land.ru/kernel.mnt . Вроде работает.
По поводу пошаговой отладки в Bochs: 16-битный код не изменился, его можно отлаживать как и раньше, а для пошаговой трассировки 32-битного кода при использовании отладочных символов достаточно сказать

Code: Select all

> lb "B32"
> c
<думает>
Breakpoint 1

и дальше - как и раньше.

Posted: **Fri Oct 27, 2006 7:00 pm**

Добро пожаловать в DLL hell!

Фунция 68.19 - загрузить DLL. ecx - указатель на путь к библиотеке.
Возвращаемое значение - логический номер DLL в случае успеха или 0.

http://infinity-sound.narod.ru/console.7z - пример DLL
консоли.

ДЛЛ может состоять из нескольких COFF секций. Кождая DLL должна иметь таблицу экспортируемых функций. Метка EXPORTS должна быть объявлена public. Обязательная функция stdcall START должна вызываться с параметром state=1 после загрузки DLL и state=-1 перед выгрузкой. Функция должна вернуть ненулевое значение в случае успхе или ноль в случае неудачи. Каждая DLL должна содержать номер версии (экспоруемое имя 'version'). Младшее слово версии - текущая версия DLL, старшее слово - минимальная совместимая версия. Программа может работать с DLL если требуемая версия не больше текущей и не меньше совместимой. Таблица EXPORTS состоит из пар двойных слов. Первое - указатель на строку с именем переменной, второе значение. Экспортироваться могут не только адреса функций но и непосредственные данные как в случае с 'version'. В файл testcon2 добавлены две вспомогательные функции для работы с DLL. get_proc возвращает адрес экспортируемой переменной sz_name. link связывает библиотеку и программу. Для этого необходима таблица импортируемых функций (в примере imports). link заменяет адреса строк с именами функций на значения полученные после вызовов get_proc

Posted: **Sat Oct 28, 2006 7:20 pm**

и какое же ядро поддерживает 68.19?

Posted: **Sat Oct 28, 2006 7:38 pm**

SVN.198+

Posted: **Mon Nov 20, 2006 8:44 pm**

почему описани функций всё ещё нет на svn в docs?

Posted: **Tue Nov 21, 2006 1:23 am**

http://infinity-sound.narod.ru/console.7z - пример DLL не работает в эмуляторе. Если заменить файл console.obj на тот что идёт в дистри 0630 то всё работает

Board.KolibriOS.org

Менеджер DLL в MeOS