Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Nov 29, 2020 2:18 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 31 posts ]  Go to page 1 2 3 Next
Author Message
PostPosted: Wed Jun 17, 2009 11:27 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Вопрос в каком формате должна быть ДЛЛ ? Скомпилировать ffmpeg в COFF если и можно то очень непросто.


Last edited by Serge on Fri Jun 19, 2009 11:35 am, edited 1 time in total.

Top
   
PostPosted: Wed Jun 17, 2009 11:34 am 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Изготовление своего формата DLL, как и выполняемых файлов можно обсудить в отдельной ветке. Но я считаю, что логичнее использовать существующие форматы.


Top
   
PostPosted: Wed Jun 17, 2009 12:02 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
<Lrz>

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


Top
   
PostPosted: Wed Jun 17, 2009 12:33 pm 
Offline
Kernel Optimizer
User avatar

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

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


Top
   
PostPosted: Wed Jun 17, 2009 2:06 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
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 со всеми вытекающими последствиями (наличествующая там аппаратная виртуализация - вещь, конечно, интересная, но её может и не быть).

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


Top
   
PostPosted: Wed Jun 17, 2009 2:07 pm 
Offline

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


Top
   
PostPosted: Wed Jun 17, 2009 2:54 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
С другой стороны, не видно фич, которые нужны и которых нет в PE... Пожалуй, я за поддержку стрипнутого PE (без ненужных полей), а также при этом можно загружать (по сути тем же кодом) и обычные PE - чтобы была и возможность не мучаться с линковкой, получая готовый файл сразу после компиляции, и возможность уменьшить размер файла за счёт некоторых дополнительных махинаций (то есть линковки с минимально возможным выравниванием, опционально таблицей перемещаемых элементов и программой, убивающей ненужные поля и опционально ужимающей образ в памяти на исчезнувшие поля).
Кстати, а PE собирается под Linux без шаманства?

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


Top
   
PostPosted: Wed Jun 17, 2009 4:56 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond

ld позволяет неплохо ужать PE если поиграть с ключами линковки и скриптом.
Code:
Очевидно, что ffmpeg можно скомпилировать в PE DLL, а PE уже можно автоматически перегнать в COFF

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

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

Есть mingw32 для Linux


Top
   
PostPosted: Wed Jun 17, 2009 7:05 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
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%).
Quote:
Если это экзешник то там нет релокаций, все адреса уже пофиксены.

Ну вообще это для библиотек предназначалось. Там таблица релокаций обычно есть. А если нет, то можно сделать (при компиляции, естественно).
Quote:
Я согласен и на стрипнутый 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. Все структуры, размещающиеся вне заголовка, пусть остаются как есть.

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


Top
   
PostPosted: Wed Jun 17, 2009 8:17 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond

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


Top
   
PostPosted: Wed Jun 17, 2009 10:39 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Serge
Например, так (всё это обсуждаемо). Исполняемый файл начинается со структуры stripped_pe_header_{32,64}:
Code:
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:
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:
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.

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


Top
   
PostPosted: Wed Jun 17, 2009 11:57 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond

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


Top
   
PostPosted: Thu Jun 18, 2009 6:14 am 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
В мануале от мелкософта размер SizeOfStackReserve и SizeOfHeapReserve определен для PE32/PE32+ как 4/8.


Attachments:
pecoff_v8.7z [101.91 KiB]
Downloaded 216 times
Top
   
PostPosted: Thu Jun 18, 2009 10:20 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Согласен.
Code:
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.

Top
   
PostPosted: Thu Jun 18, 2009 10:38 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 31 posts ]  Go to page 1 2 3 Next

All times are UTC+03:00


Who is online

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