Board.KolibriOS.org

Вопрос в каком формате должна быть ДЛЛ ? Скомпилировать ffmpeg в COFF если и можно то очень непросто.

Изготовление своего формата DLL, как и выполняемых файлов можно обсудить в отдельной ветке. Но я считаю, что логичнее использовать существующие форматы.

<Lrz>

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

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

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

Мнэээ? Кто-то совсем недавно что-то говорил про гарантии, и мне казалось, что этот кто-то тоже подписывался ником Galkov. Ну а реальная система, которая вовсе не гарантирует всё и по любому поводу, - это и есть текущее состояние планировщика...

Угу.

Дважды два - таки четыре, и сила человеческой мысли тут ни при чём. Результат всегда следует из предпринимаемых действий, и мысль может выбрать между сценариями действий и реализовать действия, но не изменить вытекающий из предпринятых действий результат.

Многопроцессорность?

Очевидно, что ffmpeg можно скомпилировать в PE DLL, а PE уже можно автоматически перегнать в COFF.

Против PE у меня есть ровно одно возражение - слишком много мусора. Прямо начиная с MZ-заголовка, и продолжая PE-заголовком, в котором куча лишних полей. В ELF тоже мусора хватает - в первом же 16-байтном поле используется всего 7 байт, и то без двух можно было бы обойтись, и продолжая совершенно ненужной загрузчику section table.

...в котором, например, отсутствует V86 со всеми вытекающими последствиями (наличествующая там аппаратная виртуализация - вещь, конечно, интересная, но её может и не быть).

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

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

С другой стороны, не видно фич, которые нужны и которых нет в PE... Пожалуй, я за поддержку стрипнутого PE (без ненужных полей), а также при этом можно загружать (по сути тем же кодом) и обычные PE - чтобы была и возможность не мучаться с линковкой, получая готовый файл сразу после компиляции, и возможность уменьшить размер файла за счёт некоторых дополнительных махинаций (то есть линковки с минимально возможным выравниванием, опционально таблицей перемещаемых элементов и программой, убивающей ненужные поля и опционально ужимающей образ в памяти на исчезнувшие поля).
Кстати, а PE собирается под Linux без шаманства?

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

diamond

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

Очевидно, что ffmpeg можно скомпилировать в PE DLL, а PE уже можно автоматически перегнать в COFF

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

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

Есть mingw32 для Linux

Я про то, что можно независимо от этого ещё немного ужать, если отказаться от полей, не нужных для загрузки.

Релоки в 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%).

Ну вообще это для библиотек предназначалось. Там таблица релокаций обычно есть. А если нет, то можно сделать (при компиляции, естественно).

Из 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}:

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), причём номер элемента в массиве определяет смысл элемента:

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 структур

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.

Согласен.

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 игнорирует.

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

diamond

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