Board.KolibriOS.org

8-байтная сигнатура - излишество. Достаточно 4 или даже 2.
Если добавить в заголовок версию заголовка, то в будущем можно будет добавлять в заголовок новые поля не нарушая совместимости.
Если добавить в заголовок информацию о целевой платформе, то можно будет опеспечить единый формат файла для 32/64/.. систем.
cmdline и последующие поля в заголовке не нужны. Если программе нужна командная строка и пр. - пусть вызывает ПолучитьКоманднуюСтроку().
Нет секции ресурсов.
Нет значка.

Выравнивание секций: я вообще за линейный файл без деления на секции. Единственная нужная "секция" - размер области неициализированных данных. Все остальные секции сплошняком. Если автора программы заботит скорость - он сам выровняет их размер, который посчитает нужным.

"For better flexibility" код должен быть позиционно-независимым, как следствие imagebase бесполезен.

Freeman
1.Зачем экспорт, длл в pe формате. Велосипед изобретаем только для екзешников.
2.Явно начало секции указано только для import, что необходимо. Если ecode выравнен на страницу, секция кода может быть защищена от записи, остальные соответственно от исполнения. eimport и edata похоже действительно лишние. Файл приложения это образ в памяти, никаких секций, смещённых относительно своих виртуальных адресов. Если выравнивание требует заполнение промежутков, значит там будут nop-ы.

1. Зачем два формата?
2. Необходимо кому? Процессор этого не требует, значит этого требует программист. Назови его имя.

Защита от исполнения и записи во многом бессмыслена: закроет ядро программу из-за исполнения недостимой инструкции или из-за обращения к недопустимой странице памяти - программу закроют.

Тогда изобретать собственный формат и правда глупо.

У меня написана утилита для работы с образами PE, которую можно было бы научить сохранять и в MENUET01, и в KOLIBRI, делая rebase и перетасовывая секции как нужно. Думал создать для нее тему.


Ты уж определись: или образ в памяти, или защита. Предположим, у меня есть 600 байт кода, 40 байт данных и еще 600 байт импорта. Если файл -- образ в памяти, с заголовком выходит 1288 байт. Если же при этом нужна защита, имеется три секции: код с защитой от записи, данные с защитой от исполнения и импорты с защитой от (чего?). При 4 КБ на страницу получаем файл размером 12336 байт, если он по-прежнему образ в памяти. Разве не так? Ни фига себе "Колибри"!

Добавлено: Впрочем, даже в PE выравнивание в файле и в памяти может отличаться...

Я подразумевал, что если загрузчик знает размеры секций, он их сможет растасовать их по страницам, которые и займут в памяти 12 КБ, а файл при этом останется 1288 байт, что более привычно для "Колибри".

Если код и импорты с экспортами имеют одни и те же флаги защиты, их можно объединить, тогда надо еще подумать, как это наиболее технологично сделать.

Добавлено: Неожиданно быстро удалось прикрутить сохранялку в формат KOLIBRI (концепт). Порядок секций такой же, как в описании: код, импорты, экспорты, данные. Rebase не делается, image base прописывается исходный. Вызывать:

pet my.dll -into my -kolibri -strip -trunc

В режиме -strip выравнивание не делается, иначе выравнивается на 8 байт. Ключ -trunc запрещает выравнивать последнюю секцию (данные).

Импорт с защитой от исполнения. Не нужно всем секциям страничное выравнивание, достаточно код от всего остального отделить. И не хочется делать многосекционный файл, чтобы потом каждую секцию на своё место копировать. Экономия дискового пространства копеечная, а файл традиционно будет сжат kpack.
Утилита это хорошо, но есть порт ld, генерирующий бинарник в родном формате Колибри. Обновить его под новый заголовок дело на один вечер. А для fasm пара макросов нужна. Хотя, если таким образом конвертировать PE других компиляторов, будет неплохо.

Да, я потом уже вспомнил, что раз в PE выравнивание в файле отличается от страничного, то можно как-то по-другому.


А ты пока не копируй, оставь на вторую версию. Мне кажется, что если уж принимать новый формат, в нем должен быть потенциал для роста. Не куча мусора, как в PE, но минимальная дополнительная инфа должна присутствовать. В будущем ее можно будет интерпретировать как-то по-другому.

Размеры блоков (раз уж слово "секции" не нравится) -- как раз такая инфа. Она и неизбыточна, и позволит проделывать более сложные манипуляции в дальнейшем, не трогая программы. Блок экспорта и "-1" для аналога консольного приложения -- тоже потенциал для улучшений.

Поскольку моя версия заголовка получилась размером 60 байт, наверное, ее стоит дополнить еще одним зарезервированным двойным словом в конце, чтоб уж 64 было. Сейчас 64 байта заголовок имеет только при включенном выравнивании, что мне кажется в стиле "Колибри".


Да-да, и я о том же. Нужно только формат утвердить. Видеть PE в качестве основного формата "Колибри" мне не хотелось бы. Это и к имиджу минус, и проблем с антивирусами не избежать.

MENUET01 для обратной совместимости останется? Со временем его тоже в Pet добавлю тогда.

Freeman
Обратная совместимость это святое.
Про флаг консольного приложения тоже думал. Секцию экспорта можно добавить, хотя зачем она в экзешнике ? Ещё есть желание добавить .debug секции, но тут надо с форматом разбираться.

Так я же писал. Размер секции экспорта равен 0 -- приложение, ненулевой размер -- библиотека. Подбиваю тебя на единый формат для приложений и библиотек.

Размер секции с отладочной инфой можно тоже добавить -- как раз последние 4 байта остались до 64.

Еще думал, как вместить перемещаемые символы (релоки), если понадобится для библиотек. Наверное, нужно добавить флаг (в те самые три байта), и тогда трактовать поле ImageBase как размер секции релоков, а фактический ImageBase в таком хранить уже в секции релоков, в ее заголовке.

С fasm будет облом. Придётся править исходники, чтобы таблицу релокаций в файл записать. И не уверен я в необходимости единого формата.

Я уже понял, что для библиотек PE избежать не удастся, по крайней мере, пока. Использование неродного формата будет печалить, и единый собственный формат -- надежда на будущее, цель развития. Поэтому и нужен мини-PE без мусора, чтобы хоть через утилиту в него преобразовывать.