Библиотеки колибри 2.0
-
Вопрос в каком формате должна быть ДЛЛ ? Скомпилировать ffmpeg в COFF если и можно то очень непросто.Last edited by Serge on Fri Jun 19, 2009 11:35 am, edited 1 time in total.
Изготовление своего формата DLL, как и выполняемых файлов можно обсудить в отдельной ветке. Но я считаю, что логичнее использовать существующие форматы.
<Lrz>
Если делать свой свой формат всё затянется ещё на три года. Для PE всё готово.
Если делать свой свой формат всё затянется ещё на три года. Для PE всё готово.
Хорошо, что народ думает на счет режима AMD64/EMT64. Я неоднократно поднимал этот вопрос.
Я предлагаю отказаться от режима IA-32 и сконцентрироваться на режиме AMD64/EMT64.
1) Сейчас система с поддержкой режима AMD64/EMT64 может позволить себе почти каждый.
2) Как правило большинство ЦП поддерживают этот режим работы.
3) Перспективность (все помним как происходил переход с 16 рязрядного кода на 32 разрядный)
4) Наличее 16 доступных РОН для программирования.
Вообще лучше поставить вопрос так: Вам нужна х64 битная ОС ?
Я предлагаю отказаться от режима IA-32 и сконцентрироваться на режиме AMD64/EMT64.
1) Сейчас система с поддержкой режима AMD64/EMT64 может позволить себе почти каждый.
2) Как правило большинство ЦП поддерживают этот режим работы.
3) Перспективность (все помним как происходил переход с 16 рязрядного кода на 32 разрядный)
4) Наличее 16 доступных РОН для программирования.
Вообще лучше поставить вопрос так: Вам нужна х64 битная ОС ?
Мнэээ? Кто-то совсем недавно что-то говорил про гарантии, и мне казалось, что этот кто-то тоже подписывался ником Galkov. Ну а реальная система, которая вовсе не гарантирует всё и по любому поводу, - это и есть текущее состояние планировщика...Galkov wrote:Что бы появилась возможность создать реальную систему вовсе не надо гарантировать все и по любому поводу.
Угу.<Lrz> wrote:Насколько я понял, diamond говорит о необходимости глобальной перестройке ядра ОС, со сменой API, как следствие и GUI. Т.е. это означает, что придеться переписывать каждую программу.
Дважды два - таки четыре, и сила человеческой мысли тут ни при чём. Результат всегда следует из предпринимаемых действий, и мысль может выбрать между сценариями действий и реализовать действия, но не изменить вытекающий из предпринятых действий результат.Galkov wrote:Ну во-первых, мне кажется, что в нашей... Типа, сила человеческой мысли - безгранична.
Многопроцессорность?Galkov wrote:Во-вторых, diamond, какие глобальные изменения ты считаешь необходимыми, которые мы никогда не сможем достигнуть "локальными" изменениями
Очевидно, что ffmpeg можно скомпилировать в PE DLL, а PE уже можно автоматически перегнать в COFF.<Lrz> wrote:Только вопрос в каком формате должна быть ДЛЛ ? Скомпилировать ffmpeg в COFF если и можно то очень непросто.
Против PE у меня есть ровно одно возражение - слишком много мусора. Прямо начиная с MZ-заголовка, и продолжая PE-заголовком, в котором куча лишних полей. В ELF тоже мусора хватает - в первом же 16-байтном поле используется всего 7 байт, и то без двух можно было бы обойтись, и продолжая совершенно ненужной загрузчику section table.Serge wrote:Если делать свой свой формат всё затянется ещё на три года. Для PE всё готово.
...в котором, например, отсутствует V86 со всеми вытекающими последствиями (наличествующая там аппаратная виртуализация - вещь, конечно, интересная, но её может и не быть).<Lrz> wrote:Я предлагаю отказаться от режима IA-32 и сконцентрироваться на режиме AMD64/EMT64.
Ушёл к умным, знающим и культурным людям.
Я себе AMD64/EMT64 позволить не могу, и это главное, да и просто не хочу, птму переход на эти архитектуры сделает не возможным для меня дальнейшее сопровождение проекта в какой бы то ни было форме.
Мне не столько ненавистна х64 битная ОС, сколько отказ от IA-32 в КолибриОС сейчас.
Если проще, то мне х64 битная Колибри не нужна.
Мне не столько ненавистна х64 битная ОС, сколько отказ от IA-32 в КолибриОС сейчас.
Если проще, то мне х64 битная Колибри не нужна.
С другой стороны, не видно фич, которые нужны и которых нет в PE... Пожалуй, я за поддержку стрипнутого PE (без ненужных полей), а также при этом можно загружать (по сути тем же кодом) и обычные PE - чтобы была и возможность не мучаться с линковкой, получая готовый файл сразу после компиляции, и возможность уменьшить размер файла за счёт некоторых дополнительных махинаций (то есть линковки с минимально возможным выравниванием, опционально таблицей перемещаемых элементов и программой, убивающей ненужные поля и опционально ужимающей образ в памяти на исчезнувшие поля).
Кстати, а PE собирается под Linux без шаманства?
Кстати, а PE собирается под Linux без шаманства?
Ушёл к умным, знающим и культурным людям.
diamond
ld позволяет неплохо ужать PE если поиграть с ключами линковки и скриптом.
А он не будет раза в полтора толще ? И каким образом перегонять назад в coff ? Если это экзешник то там нет релокаций, все адреса уже пофиксены.
Я согласен и на стрипнутый PE, если сохранится формат основных структур IMAGE_SECTION_HEADER, IMAGE_BASE_RELOCATION, IMAGE_IMPORT_DESCRIPTOR и т.п.
Есть mingw32 для Linux
ld позволяет неплохо ужать PE если поиграть с ключами линковки и скриптом.
Code: Select all
Очевидно, что ffmpeg можно скомпилировать в PE DLL, а PE уже можно автоматически перегнать в COFF
Я согласен и на стрипнутый PE, если сохранится формат основных структур IMAGE_SECTION_HEADER, IMAGE_BASE_RELOCATION, IMAGE_IMPORT_DESCRIPTOR и т.п.
Есть mingw32 для Linux
Я про то, что можно независимо от этого ещё немного ужать, если отказаться от полей, не нужных для загрузки.Serge wrote:ld позволяет неплохо ужать PE если поиграть с ключами линковки и скриптом.
Релоки в PE хорошо хранятся, так что при преобразовании размер файла возрастает, хотя и не в полтора раза. Впрочем, пакуются эти таблицы неплохо.Serge wrote:А он не будет раза в полтора толще ?
Взял с потолка первые попавшиеся 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. Все структуры, размещающиеся вне заголовка, пусть остаются как есть.Я согласен и на стрипнутый PE, если сохранится формат основных структур IMAGE_SECTION_HEADER, IMAGE_BASE_RELOCATION, IMAGE_IMPORT_DESCRIPTOR и т.п.
Ушёл к умным, знающим и культурным людям.
diamond
Я бы конечно не стал заморачиваться с экономией на IMAGE_SECTION_HEADER но это не принципиально. Из IMAGE_OPTIONAL_HEADER нужны AddressOfEntryPoint, ImageBase и SizeOfImage. Полезны SizeOfStackReserve и SizeOfHeapReserve. Могут пригодиться SectionAlignment и FileAlignment для расшареных длл. Ещё надо что-то для контроля версии и подсистемы.
Я бы конечно не стал заморачиваться с экономией на IMAGE_SECTION_HEADER но это не принципиально. Из IMAGE_OPTIONAL_HEADER нужны AddressOfEntryPoint, ImageBase и SizeOfImage. Полезны SizeOfStackReserve и SizeOfHeapReserve. Могут пригодиться SectionAlignment и FileAlignment для расшареных длл. Ещё надо что-то для контроля версии и подсистемы.
Serge
Например, так (всё это обсуждаемо). Исполняемый файл начинается со структуры stripped_pe_header_{32,64}:
Потом идут NumberOfRvaAndSizes структур IMAGE_DATA_DIRECTORY (тех же, что и в PE), причём номер элемента в массиве определяет смысл элемента:
Нумерация выбрана из соображений, что если, например, приложение использует только импорт, то оно имеет право ограничиться массивом из одного элемента, положив NumberOfRvaAndSizes = 1, и более необходимые вещи идут раньше.
Потом (по смещению sizeof.stripped_pe_header + 8*NumberOfRvaAndSizes в файле) идёт таблица секций - NumberOfSections структур
Например, так (всё это обсуждаемо). Исполняемый файл начинается со структуры 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 ?
}
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
Потом (по смещению 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 ? Насчет ресурсов не знаю, а таблица исключений может пригодиться.
Думаю что 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 342 times
-
Согласен.
IMAGE_DIRECTORY_ENTRY_IAT не связана с bound import, а определяет диапазон адресов, в которые надо записывать значения при импорте и которые соответственно нужно VirtualProtect'ить на read/write. Эту же информацию можно получить и из самой таблицы импорта, и виндовый загрузчик ENTRY_IAT игнорирует.
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
Last edited by diamond on Thu Jun 18, 2009 12:22 pm, edited 1 time in total.
Ушёл к умным, знающим и культурным людям.
diamond
Такой вариант мне нравится. Осталось решить самый важный вопрос - какой должна быть сигнатура ( (с) South Park)
Такой вариант мне нравится. Осталось решить самый важный вопрос - какой должна быть сигнатура ( (с) South Park)
Who is online
Users browsing this forum: No registered users and 41 guests