Asmxygen
Websvn
Builds
Bugs
FTP
Wiki
Telegram
Discord
Reddit
Предлагаю KMPE или KMP (Kolibri Modified PE) или
KSF(P) (Kolibry System Format PE)
Не имею ничего против из предложенных ранее.
Библиотеки колибри 2.0
diamond
Можно и KSPE(Kolibri Specific PE) для точности. А сами исполняемые *.SEx ))
Можно и KSPE(Kolibri Specific PE) для точности. А сами исполняемые *.SEx ))
Меня устроит любая сигнатура, главное чтобы она случайно не совпала с другой. И ещё надо добавить поле типа в заголовок упакованных файлов чтобы система не пыталась запустить всё что загружается.
Предлагаю Сигнатуру сделать следующиего формата:
'???K' - ??? - основная сигнатура (может быть любая, как вариант, ранее предложенные,), где K - обозначает упакованный Kpack. Если файл не упакован,то вместо K содерижится ' ' или 0x20 или 0х0.
'???K' - ??? - основная сигнатура (может быть любая, как вариант, ранее предложенные,), где K - обозначает упакованный Kpack. Если файл не упакован,то вместо K содерижится ' ' или 0x20 или 0х0.
Last edited by <Lrz> on Thu Jun 18, 2009 2:45 pm, edited 1 time in total.
diamond
Ещё нужен TimeDateStamp для bound import
Ещё нужен TimeDateStamp для bound import
TimeDateStamp есть в структуре экспорта.
Пожалуй, поле SizeOfHeaders нужно переместить ближе к концу, чтобы в структурах было натуральное выравнивание. Листинг в предыдущем посте сейчас отредактирую.
Пожалуй, поле 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. (Это всё обсуждаемо, естественно.)
Для типа в упакованных файлах можно задействовать байт по смещению +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 будет указывать на начало структуры.
Надо определиться с ABI для новых екзешников и с передачей командной строки и переменных окружения.
Предлагаю сделать по примеру System V ABI, но без разделения строк на отдельные аргументы. тогда в стеке будет формироваться такая структура:
Code: Select all
struct {
int argc; //число аргументов - 1 или 2
char *path_ptr; //указатель на полный путь. Передаётся всегда
char *cmdline_ptr; //указатель на командную строку или NULL
char *env_ptr; //указатель на переменные окружения или NULL
char path[]; //Полный путь к приложению. Передаётся всегда.
char cmdline[]; //Командная строка. Передаётся если argc=2
char environment[]; //Переменные окружения. Передаются если env_ptr != NULL
}app_stack;После передачи управления приложению esp будет указывать на начало структуры.
Думаю что ком. строка как и окружение, т.е. текущее их представление устарели.
При запуске приложения A, приложением B, очень было бы недурно, что бы последнее могло передавать аргументы в произвольном (двоичном) виде, а не как это принято сейчас. Например, такими данными могут быть, как, действительно, ком. строка, которую ручками наколотил пользователь, так и номер своего PID (или другие данные), используя которые, у приложения A появятся представления о том, куда направить стандартный вывод (а также ошибки, как получить ввод и пр.). Я говорю про случай, когда B, скажем, является командной оболочкой и в состоянии передавать запущенному процессу поток (с клавиатуры, например), а так же получать от него вывод.
cmdline, env и т.д. можно объединить в один массив элементов. Элементом такого массива является примерно следующая структура:
Набор передаваемых данных может быть любым. Главное что бы приложение A (запускаемое), знало, что имеется ввиду под "inout" или "env" и корректно использовало эти значения. Некоторые сигнатуры и соотв. форматы данных можно согласовать уже сейчас.
Пример с PID очень просто, хотя и актуальный. Такими данными ведь может быть и некоторый упакованный графический ресурс, т.е. не ссылка на сам файл (так как файла может и не быть, скажем, если ресурс получен по сети, то его, не сохраняя на диск, можно отобразить по средством стороннего приложения, избегая различных IPC), а именно двоичные данные.
..bw
При запуске приложения A, приложением B, очень было бы недурно, что бы последнее могло передавать аргументы в произвольном (двоичном) виде, а не как это принято сейчас. Например, такими данными могут быть, как, действительно, ком. строка, которую ручками наколотил пользователь, так и номер своего PID (или другие данные), используя которые, у приложения A появятся представления о том, куда направить стандартный вывод (а также ошибки, как получить ввод и пр.). Я говорю про случай, когда B, скажем, является командной оболочкой и в состоянии передавать запущенному процессу поток (с клавиатуры, например), а так же получать от него вывод.
cmdline, env и т.д. можно объединить в один массив элементов. Элементом такого массива является примерно следующая структура:
Code: Select all
int signature; // сигнатура, по которой можно определить формат данных (cmdline, env, inout и т.д.)
int size; // размер данных
char data[]; // сами данные
Пример с PID очень просто, хотя и актуальный. Такими данными ведь может быть и некоторый упакованный графический ресурс, т.е. не ссылка на сам файл (так как файла может и не быть, скажем, если ресурс получен по сети, то его, не сохраняя на диск, можно отобразить по средством стороннего приложения, избегая различных IPC), а именно двоичные данные.
..bw
bw
Для передачи дополнительной информации есть массив векторов auxv_t но не думаю что надо его использовать для передачи raw данных. Стек не безразмерный.
Для передачи дополнительной информации есть массив векторов auxv_t но не думаю что надо его использовать для передачи raw данных. Стек не безразмерный.
Не понятны две вещи:
1. Где этот auxv_t?
2. Причем здесь стек?
Хотя нет, три:
3. app_stack, где это используется?
3a. Эта структура передается системной функции и необходима для запуска нового приложения?
3b. Эту структуру получает уже запущенное новое приложение?
Наверное уже не в тему, но всё же хотелось бы побольше узнать об auxv_t, его можно использовать в описанной мной задаче, для решения такой локальной проблемы как указание консольной оболочкой новому приложению где его потоки ввода/вывода (например передать pid оболочки, скорее всего, на практике, этого будет достаточно).
..bw
1. Где этот auxv_t?
2. Причем здесь стек?
Хотя нет, три:
3. app_stack, где это используется?
3a. Эта структура передается системной функции и необходима для запуска нового приложения?
3b. Эту структуру получает уже запущенное новое приложение?
Наверное уже не в тему, но всё же хотелось бы побольше узнать об auxv_t, его можно использовать в описанной мной задаче, для решения такой локальной проблемы как указание консольной оболочкой новому приложению где его потоки ввода/вывода (например передать pid оболочки, скорее всего, на практике, этого будет достаточно).
..bw
Who is online
Users browsing this forum: No registered users and 0 guests