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

Discussing libraries simplifying applications development
  • Изготовление своего формата DLL, как и выполняемых файлов можно обсудить в отдельной ветке. Но я считаю, что логичнее использовать существующие форматы.
  • <Lrz>

    Если делать свой свой формат всё затянется ещё на три года. Для PE всё готово.
  • Хорошо, что народ думает на счет режима AMD64/EMT64. Я неоднократно поднимал этот вопрос.
    Я предлагаю отказаться от режима IA-32 и сконцентрироваться на режиме AMD64/EMT64.
    1) Сейчас система с поддержкой режима AMD64/EMT64 может позволить себе почти каждый.
    2) Как правило большинство ЦП поддерживают этот режим работы.
    3) Перспективность (все помним как происходил переход с 16 рязрядного кода на 32 разрядный)
    4) Наличее 16 доступных РОН для программирования.

    Вообще лучше поставить вопрос так: Вам нужна х64 битная ОС ?
  • 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 со всеми вытекающими последствиями (наличествующая там аппаратная виртуализация - вещь, конечно, интересная, но её может и не быть).
    Ушёл к умным, знающим и культурным людям.
  • Я себе AMD64/EMT64 позволить не могу, и это главное, да и просто не хочу, птму переход на эти архитектуры сделает не возможным для меня дальнейшее сопровождение проекта в какой бы то ни было форме.
    Мне не столько ненавистна х64 битная ОС, сколько отказ от IA-32 в КолибриОС сейчас.
    Если проще, то мне х64 битная Колибри не нужна.
  • С другой стороны, не видно фич, которые нужны и которых нет в PE... Пожалуй, я за поддержку стрипнутого PE (без ненужных полей), а также при этом можно загружать (по сути тем же кодом) и обычные PE - чтобы была и возможность не мучаться с линковкой, получая готовый файл сразу после компиляции, и возможность уменьшить размер файла за счёт некоторых дополнительных махинаций (то есть линковки с минимально возможным выравниванием, опционально таблицей перемещаемых элементов и программой, убивающей ненужные поля и опционально ужимающей образ в памяти на исчезнувшие поля).
    Кстати, а PE собирается под Linux без шаманства?
    Ушёл к умным, знающим и культурным людям.
  • diamond

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

    Code: Select all

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

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

    Есть mingw32 для Linux
  • 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. Все структуры, размещающиеся вне заголовка, пусть остаются как есть.
    Ушёл к умным, знающим и культурным людям.
  • diamond

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

    Думаю что SizeOfStackCommit и SizeOfHeapCommit не нужны. ld ставит эти поля в 4 Кб и опций в командной строке для них нет. В pe_header_64 SizeOfStackReserve и SizeOfHeapReserve должны быть по 8 байт или там страничная гранулярность ? Для BOUND_IMPORT нужен IAT ? Насчет ресурсов не знаю, а таблица исключений может пригодиться.
  • В мануале от мелкософта размер SizeOfStackReserve и SizeOfHeapReserve определен для PE32/PE32+ как 4/8.
    Attachments
    pecoff_v8.7z (101.91 KiB)
    Downloaded 341 times
  • Согласен.

    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 игнорирует.
    Last edited by diamond on Thu Jun 18, 2009 12:22 pm, edited 1 time in total.
    Ушёл к умным, знающим и культурным людям.
  • diamond

    Такой вариант мне нравится. Осталось решить самый важный вопрос - какой должна быть сигнатура ( (с) South Park) :)
  • Who is online

    Users browsing this forum: No registered users and 3 guests