Board.KolibriOS.org

Предлагаю KMPE или KMP (Kolibri Modified PE) или
KSF(P) (Kolibry System Format PE)
Не имею ничего против из предложенных ранее.

diamond
Можно и KSPE(Kolibri Specific PE) для точности. А сами исполняемые *.SEx ))

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

Предлагаю Сигнатуру сделать следующиего формата:
'???K' - ??? - основная сигнатура (может быть любая, как вариант, ранее предложенные,), где K - обозначает упакованный Kpack. Если файл не упакован,то вместо K содерижится ' ' или 0x20 или 0х0.

diamond

Ещё нужен TimeDateStamp для bound import

TimeDateStamp есть в структуре экспорта.
Пожалуй, поле SizeOfHeaders нужно переместить ближе к концу, чтобы в структурах было натуральное выравнивание. Листинг в предыдущем посте сейчас отредактирую.

Сигнатура так важна?! чем вам PE не подходит?!

Какой-то флейм на пустом месте... Мне, в общем, пофиг на сигнатуру, но флейм надо прекращать. Для определённости пусть сигнатура будет 'KEx' от Kolibri Executable, ни с чем известным мне не конфликтует (беглый поиск в Сети тоже ничего не выявил).
Для типа в упакованных файлах можно задействовать байт по смещению +11 (+0xB) - изначально я погорячился и отвёл на поле для алгоритма сжатия целый dword (+8), в котором реально используется только младший байт (хотя проверяется весь dword). Скажем, 0 может означать generic file, 1 - KEx 32-bit EXE, 2 - KEx 32-bit DLL, 3 - KEx 32-bit driver, 4 - KEx 64-bit EXE, 5 - KEx 64-bit DLL, 6 - KEx 64-bit driver. (Это всё обсуждаемо, естественно.)

diamond

Остаётся решить что делать с уже запакованными файлами. Если их не конвертировать то поле типа не имеет смысла. Загрузчику всё равно придётся распаковывать и проверять каждый файл.

Уже упакованные файлы можно просто распаковать и упаковать заново новой версией упаковщика (распаковывать можно как старой версией, так и новой).

diamond

Надо определиться с ABI для новых екзешников и с передачей командной строки и переменных окружения.
Предлагаю сделать по примеру System V ABI, но без разделения строк на отдельные аргументы. тогда в стеке будет формироваться такая структура: Дополнительно можно передавать длины строк для упрощения программированиия.

После передачи управления приложению esp будет указывать на начало структуры.

Думаю что ком. строка как и окружение, т.е. текущее их представление устарели.
При запуске приложения A, приложением B, очень было бы недурно, что бы последнее могло передавать аргументы в произвольном (двоичном) виде, а не как это принято сейчас. Например, такими данными могут быть, как, действительно, ком. строка, которую ручками наколотил пользователь, так и номер своего PID (или другие данные), используя которые, у приложения A появятся представления о том, куда направить стандартный вывод (а также ошибки, как получить ввод и пр.). Я говорю про случай, когда B, скажем, является командной оболочкой и в состоянии передавать запущенному процессу поток (с клавиатуры, например), а так же получать от него вывод.

cmdline, env и т.д. можно объединить в один массив элементов. Элементом такого массива является примерно следующая структура: Набор передаваемых данных может быть любым. Главное что бы приложение A (запускаемое), знало, что имеется ввиду под "inout" или "env" и корректно использовало эти значения. Некоторые сигнатуры и соотв. форматы данных можно согласовать уже сейчас.
Пример с PID очень просто, хотя и актуальный. Такими данными ведь может быть и некоторый упакованный графический ресурс, т.е. не ссылка на сам файл (так как файла может и не быть, скажем, если ресурс получен по сети, то его, не сохраняя на диск, можно отобразить по средством стороннего приложения, избегая различных IPC), а именно двоичные данные.

..bw

bw

Для передачи дополнительной информации есть массив векторов auxv_t но не думаю что надо его использовать для передачи raw данных. Стек не безразмерный.

Не понятны две вещи:
1. Где этот auxv_t?
2. Причем здесь стек?

Хотя нет, три:
3. app_stack, где это используется?
3a. Эта структура передается системной функции и необходима для запуска нового приложения?
3b. Эту структуру получает уже запущенное новое приложение?

Наверное уже не в тему, но всё же хотелось бы побольше узнать об auxv_t, его можно использовать в описанной мной задаче, для решения такой локальной проблемы как указание консольной оболочкой новому приложению где его потоки ввода/вывода (например передать pid оболочки, скорее всего, на практике, этого будет достаточно).

..bw

bw

System V ABI Process Stack and Registers - здесь всё подробно расписано.