Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Dec 08, 2019 10:33 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 216 posts ]  Go to page Previous 110 11 12 13 14 15 Next
Author Message
 Post subject:
PostPosted: Tue Oct 10, 2006 10:24 pm 
Offline
Kernel Developer

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


Top
   
 Post subject:
PostPosted: Wed Oct 11, 2006 4:42 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Quote:
Самораспаковка не нужна. Иначе не удастся одновременно грузить программу и ДЛЛ.

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

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


Top
   
 Post subject:
PostPosted: Wed Oct 11, 2006 4:54 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Cхема с самораспаковкой по-моёму будет слишком сложна в отладке и не ясно как она будет работать если надо прилинковать несколько библиотек и программы будут из нескольких секций.
Для упаковщика наверное лучше выбрать один алгоритм сжатия и сделать его стандартным. Входные данные просто файл. На выходе сжатый файл с небольшим заголовком. В нём обязательно должен быть размер исходного файла. Если делать разные алгоритмы упаковки то должно быть поле с типом упаковки. В таком случае хватит 12 байт. Сигнатура "COFF", исходный размер файла, тип упаковщика.


Top
   
 Post subject:
PostPosted: Wed Oct 11, 2006 5:02 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
С отладкой, конечно, будут некоторые проблемы, но они вполне решаемы. Между прочим, большинство упаковщиков под Windows поддерживают DLL-ки без всякой помощи со стороны ядра. Но вроде бы мы договорились производить распаковку в ядре, а тогда задача сильно упрощается.
Про тип упаковки: ну вообще-то там байта хватит...


Top
   
 Post subject:
PostPosted: Wed Oct 11, 2006 8:15 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Сложно будет отладить загрузчик. И непонятно как автоматически связать самораспаковывающийся файл. С PE проще, там файл - образ программы в памяти. У COFF нарушено выравнивание секций, его приходится грузить в промежуточный буфер и там проводить настройку релоков.


Top
   
 Post subject:
PostPosted: Thu Oct 12, 2006 11:39 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Готов абстрактный упаковщик/распаковщик
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 - исходники


Top
   
 Post subject:
PostPosted: Thu Oct 12, 2006 1:45 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Вообще-то он может быть полезным не только для упаковки DLL/драйверов, но и для скинов (default.skn сжимается с ~7.5K до 949 байт!) и для упаковки 32-битной части самого ядра (по предварительным подсчётам, получаем сжатие примерно в 2 раза).


Top
   
 Post subject:
PostPosted: Thu Oct 12, 2006 5:32 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
По-моему жать ядро не стоит. Иногда загрузку приходится проходить пошагово в Боше. Сжатие будет только мешать. А вот сжимать всякую графику очень хорошо


Top
   
 Post subject:
PostPosted: Thu Oct 12, 2006 5:45 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
Для отладки можно и не сжимать. А для дистрибутивов само то, на дискете лишних 50 кб не бывает :)


Top
   
 Post subject:
PostPosted: Mon Oct 16, 2006 3:32 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Полуэкспериментальный упаковщик ядра: требуется ядро ревизии как минимум 183:
http://diamondz.land.ru/kerpack
http://diamondz.land.ru/kerpack_src.7z
Упакованное ядро ревизии 183 можно взять с http://diamondz.land.ru/kernel.mnt . Вроде работает.
По поводу пошаговой отладки в Bochs: 16-битный код не изменился, его можно отлаживать как и раньше, а для пошаговой трассировки 32-битного кода при использовании отладочных символов достаточно сказать
Code:
> lb "B32"
> c
<думает>
Breakpoint 1

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

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


Top
   
 Post subject:
PostPosted: Fri Oct 27, 2006 7:00 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Добро пожаловать в 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


Top
   
 Post subject:
PostPosted: Sat Oct 28, 2006 7:20 pm 
Offline

Joined: Mon Apr 10, 2006 7:22 am
Posts: 76
и какое же ядро поддерживает 68.19?


Top
   
 Post subject:
PostPosted: Sat Oct 28, 2006 7:38 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
SVN.198+


Top
   
 Post subject:
PostPosted: Mon Nov 20, 2006 8:44 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
почему описани функций всё ещё нет на svn в docs?


Top
   
 Post subject:
PostPosted: Tue Nov 21, 2006 1:23 am 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
http://infinity-sound.narod.ru/console.7z - пример DLL не работает в эмуляторе. Если заменить файл console.obj на тот что идёт в дистри 0630 то всё работает


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 216 posts ]  Go to page Previous 110 11 12 13 14 15 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 4 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:  
cron
Powered by phpBB® Forum Software © phpBB Limited