Board.KolibriOS.org

Official KolibriOS board
http://board.kolibrios.org/

Библиотеки колибри 2.0

http://board.kolibrios.org/viewtopic.php?t=1294

Page 1 of 3

Библиотеки колибри 2.0

Posted: Wed Jun 17, 2009 11:27 am
by Serge
Вопрос в каком формате должна быть ДЛЛ ? Скомпилировать ffmpeg в COFF если и можно то очень непросто.

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 11:34 am
by <Lrz>
Изготовление своего формата DLL, как и выполняемых файлов можно обсудить в отдельной ветке. Но я считаю, что логичнее использовать существующие форматы.

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 12:02 pm
by Serge
<Lrz>

Если делать свой свой формат всё затянется ещё на три года. Для PE всё готово.

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 12:33 pm
by <Lrz>
Хорошо, что народ думает на счет режима AMD64/EMT64. Я неоднократно поднимал этот вопрос.
Я предлагаю отказаться от режима IA-32 и сконцентрироваться на режиме AMD64/EMT64.
1) Сейчас система с поддержкой режима AMD64/EMT64 может позволить себе почти каждый.
2) Как правило большинство ЦП поддерживают этот режим работы.
3) Перспективность (все помним как происходил переход с 16 рязрядного кода на 32 разрядный)
4) Наличее 16 доступных РОН для программирования.

Вообще лучше поставить вопрос так: Вам нужна х64 битная ОС ?

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 2:06 pm
by diamond
Galkov wrote:Что бы появилась возможность создать реальную систему вовсе не надо гарантировать все и по любому поводу.
Мнэээ? Кто-то совсем недавно что-то говорил про гарантии, и мне казалось, что этот кто-то тоже подписывался ником Galkov. Ну а реальная система, которая вовсе не гарантирует всё и по любому поводу, - это и есть текущее состояние планировщика...
<Lrz> wrote:Насколько я понял, diamond говорит о необходимости глобальной перестройке ядра ОС, со сменой API, как следствие и GUI. Т.е. это означает, что придеться переписывать каждую программу.
Угу.
Galkov wrote:Ну во-первых, мне кажется, что в нашей... Типа, сила человеческой мысли - безгранична.
Дважды два - таки четыре, и сила человеческой мысли тут ни при чём. Результат всегда следует из предпринимаемых действий, и мысль может выбрать между сценариями действий и реализовать действия, но не изменить вытекающий из предпринятых действий результат.
Galkov wrote:Во-вторых, diamond, какие глобальные изменения ты считаешь необходимыми, которые мы никогда не сможем достигнуть "локальными" изменениями
Многопроцессорность?
<Lrz> wrote:Только вопрос в каком формате должна быть ДЛЛ ? Скомпилировать ffmpeg в COFF если и можно то очень непросто.
Очевидно, что ffmpeg можно скомпилировать в PE DLL, а PE уже можно автоматически перегнать в COFF.
Serge wrote:Если делать свой свой формат всё затянется ещё на три года. Для PE всё готово.
Против PE у меня есть ровно одно возражение - слишком много мусора. Прямо начиная с MZ-заголовка, и продолжая PE-заголовком, в котором куча лишних полей. В ELF тоже мусора хватает - в первом же 16-байтном поле используется всего 7 байт, и то без двух можно было бы обойтись, и продолжая совершенно ненужной загрузчику section table.
<Lrz> wrote:Я предлагаю отказаться от режима IA-32 и сконцентрироваться на режиме AMD64/EMT64.
...в котором, например, отсутствует V86 со всеми вытекающими последствиями (наличествующая там аппаратная виртуализация - вещь, конечно, интересная, но её может и не быть).

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 2:07 pm
by PhoSor
Я себе AMD64/EMT64 позволить не могу, и это главное, да и просто не хочу, птму переход на эти архитектуры сделает не возможным для меня дальнейшее сопровождение проекта в какой бы то ни было форме.
Мне не столько ненавистна х64 битная ОС, сколько отказ от IA-32 в КолибриОС сейчас.
Если проще, то мне х64 битная Колибри не нужна.

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 2:54 pm
by diamond
С другой стороны, не видно фич, которые нужны и которых нет в PE... Пожалуй, я за поддержку стрипнутого PE (без ненужных полей), а также при этом можно загружать (по сути тем же кодом) и обычные PE - чтобы была и возможность не мучаться с линковкой, получая готовый файл сразу после компиляции, и возможность уменьшить размер файла за счёт некоторых дополнительных махинаций (то есть линковки с минимально возможным выравниванием, опционально таблицей перемещаемых элементов и программой, убивающей ненужные поля и опционально ужимающей образ в памяти на исчезнувшие поля).
Кстати, а PE собирается под Linux без шаманства?

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 4:56 pm
by Serge
diamond

ld позволяет неплохо ужать PE если поиграть с ключами линковки и скриптом.

Code: Select all

Очевидно, что ffmpeg можно скомпилировать в PE DLL, а PE уже можно автоматически перегнать в COFF
А он не будет раза в полтора толще ? И каким образом перегонять назад в coff ? Если это экзешник то там нет релокаций, все адреса уже пофиксены.

Я согласен и на стрипнутый PE, если сохранится формат основных структур IMAGE_SECTION_HEADER, IMAGE_BASE_RELOCATION, IMAGE_IMPORT_DESCRIPTOR и т.п.

Есть mingw32 для Linux

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 7:05 pm
by diamond
Serge wrote:ld позволяет неплохо ужать PE если поиграть с ключами линковки и скриптом.
Я про то, что можно независимо от этого ещё немного ужать, если отказаться от полей, не нужных для загрузки.
Serge wrote:А он не будет раза в полтора толще ?
Релоки в PE хорошо хранятся, так что при преобразовании размер файла возрастает, хотя и не в полтора раза. Впрочем, пакуются эти таблицы неплохо.
Взял с потолка первые попавшиеся dll из http://ffmpeg.arrozcru.org/builds/ ("SDK, Win32 shared libraries"), провёл преобразование формата у пары библиотек из bin.
avcodec-52.dll: 8627712 байт превращаются в 9449164 (возрастание примерно 10% от исходного размера), после kpack dll весит 2306421 байт, obj - 2301737 (уменьшение на 0.2%).
swscale-0.dll: 175616 байт превращаются в 218230 (возрастание на 24%), после kpack - соответственно 52946 и 51192 байт (уменьшение на 3%).
Если это экзешник то там нет релокаций, все адреса уже пофиксены.
Ну вообще это для библиотек предназначалось. Там таблица релокаций обычно есть. А если нет, то можно сделать (при компиляции, естественно).
Я согласен и на стрипнутый PE, если сохранится формат основных структур IMAGE_SECTION_HEADER, IMAGE_BASE_RELOCATION, IMAGE_IMPORT_DESCRIPTOR и т.п.
Из IMAGE_SECTION_HEADER я бы выкинул Name, PointerToRelocations, PointerToLinenumbers, NumberOfRelocations, NumberOfLinenumbers, а в Characteristics фактически используются только 4 старшие бита (shared, execute, read, write), так что его можно объединить с SizeOfRawData (оставив эти биты старшими), достигая красивого размера в 10h. Все структуры, размещающиеся вне заголовка, пусть остаются как есть.

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 8:17 pm
by Serge
diamond

Я бы конечно не стал заморачиваться с экономией на IMAGE_SECTION_HEADER но это не принципиально. Из IMAGE_OPTIONAL_HEADER нужны AddressOfEntryPoint, ImageBase и SizeOfImage. Полезны SizeOfStackReserve и SizeOfHeapReserve. Могут пригодиться SectionAlignment и FileAlignment для расшареных длл. Ещё надо что-то для контроля версии и подсистемы.

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 10:39 pm
by diamond
Serge
Например, так (всё это обсуждаемо). Исполняемый файл начинается со структуры stripped_pe_header_{32,64}:

Code: Select all

struc stripped_pe_header_32
{
	Signature		dd	?	; можно оставить 'PE', можно 'KPE' или 'SPE' или 'PES'
	Characteristics		dw	?	; IMAGE_FILE_HEADER.Characteristics, except that
						; IMAGE_FILE_32BIT_MACHINE is set
	NumberOfSections	dw	?	; IMAGE_FILE_HEADER.NumberOfSections
	ImageBase		dd	?
	AddressOfEntryPoint	dd	?
	SectionAlignment	dw	?
	FileAlignment		dw	?
	MajorOperatingSystemVersion dw	?
	MinorOperatingSystemVersion dw	?
	SizeOfImage		dd	?
	SizeOfHeaders		dd	?	; first SizeOfHeaders bytes from the file are mapped to ImageBase
	SizeOfStackReserve	dd	?
	SizeOfStackCommit	dd	?
	SizeOfHeapReserve	dd	?
	SizeOfHeapCommit	dd	?
	Subsystem		db	?
	NumberOfRvaAndSizes	db	?
	padding			dw	?
}
struc stripped_pe_header_64
{
	Signature		dd	?
	Characteristics		dw	?	; IMAGE_FILE_HEADER.Characteristics, except that
						; IMAGE_FILE_32BIT_MACHINE is cleared
	NumberOfSections	dw	?
	ImageBase		dq	?
	AddressOfEntryPoint	dd	?
	SectionAlignment	dw	?
	FileAlignment		dw	?
	MajorOperatingSystemVersion dw	?
	MinorOperatingSystemVersion dw	?
	SizeOfImage		dd	?
	SizeOfHeaders		dd	?
	SizeOfStackReserve	dd	?
	SizeOfStackCommit	dd	?
	SizeOfHeapReserve	dd	?
	SizeOfHeapCommit	dd	?
	Subsystem		db	?
	NumberOfRvaAndSizes	db	?
	padding			dw	?
}
Потом идут NumberOfRvaAndSizes структур IMAGE_DATA_DIRECTORY (тех же, что и в PE), причём номер элемента в массиве определяет смысл элемента:

Code: Select all

SPE_DIRECTORY_IMPORT = 0
SPE_DIRECTORY_EXPORT = 1
SPE_DIRECTORY_BASERELOC = 2
SPE_DIRECTORY_RESOURCE = 3 ; нужно ли это вообще?
SPE_DIRECTORY_TLS = 4
SPE_DIRECTORY_BOUND_IMPORT = 5
Нумерация выбрана из соображений, что если, например, приложение использует только импорт, то оно имеет право ограничиться массивом из одного элемента, положив NumberOfRvaAndSizes = 1, и более необходимые вещи идут раньше.
Потом (по смещению sizeof.stripped_pe_header + 8*NumberOfRvaAndSizes в файле) идёт таблица секций - NumberOfSections структур

Code: Select all

struc stripped_pe_section_header
{
	VirtualSize	dd	?
	VirtualAddress	dd	?
	SizeOfRawData_MemProtect dd	?	; lowest 28 bits are SizeOfRawData,
						; highest 4 bits give memory protection
	PointerToRawData	dd	?
}
IMAGE_SCN_MEM_SHARED	= 0x10000000	; Section is shareable.
IMAGE_SCN_MEM_EXECUTE	= 0x20000000	; Section is executable.
IMAGE_SCN_MEM_READ	= 0x40000000		; Section is readable.
IMAGE_SCN_MEM_WRITE	= 0x80000000	; Section is writeable.

Re: Колибри для встроенных систем?

Posted: Wed Jun 17, 2009 11:57 pm
by Serge
diamond

Думаю что SizeOfStackCommit и SizeOfHeapCommit не нужны. ld ставит эти поля в 4 Кб и опций в командной строке для них нет. В pe_header_64 SizeOfStackReserve и SizeOfHeapReserve должны быть по 8 байт или там страничная гранулярность ? Для BOUND_IMPORT нужен IAT ? Насчет ресурсов не знаю, а таблица исключений может пригодиться.

Re: Колибри для встроенных систем?

Posted: Thu Jun 18, 2009 6:14 am
by <Lrz>
В мануале от мелкософта размер SizeOfStackReserve и SizeOfHeapReserve определен для PE32/PE32+ как 4/8.

Re: Колибри для встроенных систем?

Posted: Thu Jun 18, 2009 10:20 am
by diamond
Согласен.

Code: Select all

struc stripped_pe_header_32
{
	Signature		dd	?	; можно оставить 'PE', можно 'KPE' или 'SPE' или 'PES'
	Characteristics		dw	?	; IMAGE_FILE_HEADER.Characteristics, except that
						; IMAGE_FILE_32BIT_MACHINE is set
	NumberOfSections	dw	?	; IMAGE_FILE_HEADER.NumberOfSections
	ImageBase		dd	?
	AddressOfEntryPoint	dd	?
	SectionAlignment	dw	?
	FileAlignment		dw	?
	MajorOperatingSystemVersion dw	?
	MinorOperatingSystemVersion dw	?
	SizeOfImage		dd	?
	SizeOfStackReserve	dd	?
	SizeOfHeapReserve	dd	?
	SizeOfHeaders		dd	?	; first SizeOfHeaders bytes from the file are mapped to ImageBase
	Subsystem		db	?
	NumberOfRvaAndSizes	db	?
	padding			dw	?
}
struc stripped_pe_header_64
{
	Signature		dd	?
	Characteristics		dw	?	; IMAGE_FILE_HEADER.Characteristics, except that
						; IMAGE_FILE_32BIT_MACHINE is cleared
	NumberOfSections	dw	?
	ImageBase		dq	?
	AddressOfEntryPoint	dd	?
	SectionAlignment	dw	?
	FileAlignment		dw	?
	MajorOperatingSystemVersion dw	?
	MinorOperatingSystemVersion dw	?
	SizeOfImage		dd	?
	SizeOfStackReserve	dq	?
	SizeOfHeapReserve	dq	?
	SizeOfHeaders		dd	?
	Subsystem		db	?
	NumberOfRvaAndSizes	db	?
	padding			dw	?
}
SPE_DIRECTORY_IMPORT = 0
SPE_DIRECTORY_EXPORT = 1
SPE_DIRECTORY_BASERELOC = 2
SPE_DIRECTORY_EXCEPTION = 3
SPE_DIRECTORY_TLS = 4
SPE_DIRECTORY_BOUND_IMPORT = 5
SPE_DIRECTORY_RESOURCE = 6
IMAGE_DIRECTORY_ENTRY_IAT не связана с bound import, а определяет диапазон адресов, в которые надо записывать значения при импорте и которые соответственно нужно VirtualProtect'ить на read/write. Эту же информацию можно получить и из самой таблицы импорта, и виндовый загрузчик ENTRY_IAT игнорирует.

Re: Колибри для встроенных систем?

Posted: Thu Jun 18, 2009 10:38 am
by Serge
diamond

Такой вариант мне нравится. Осталось решить самый важный вопрос - какой должна быть сигнатура ( (с) South Park) :)
All times are UTC+03:00
Page 1 of 3

Powered by phpBB® Forum Software © phpBB Limited