KX - новый формат исполнимых файлов

Applications development, KoOS API questions
  • Пример простой программы, использующей неинициализированные переменные:

    Code: Select all

            use32
            org     0
            
            db      "KX", 0, 0x80
            
            call    proc0
            call    proc1
            ...
            mov     [x], 5
            mov     eax, [x]
            mov     [y], eax
            ...
            xor     eax, eax
            dec     eax
            int     0x40
            
    x       dd      ?
    y       dd      ?
    
    
  • Структура чанка с 8-битным заголовком:

    Code: Select all

            db      chunk_type
            db      chunk_data_size
            db      chunk_data_size dup ? ;chunk_data
    
    с 16-битным заголовком:

    Code: Select all

            dw      chunk_type
            dw      chunk_data_size
            db      chunk_data_size dup ? ;chunk_data
    
    с 32-битным заголовком:

    Code: Select all

            dd      chunk_type
            dd      chunk_data_size
            db      chunk_data_size dup ? ;chunk_data
    
  • Забыл написать про то, что runkx - это консольная программа, поэтому её нужно запускать в shell-е так:
    runkx kxapp kxparams
    или
    runkx "kx app" "kx params"
    Например, для того, чтобы запустить calc.test в шелле введите:
    runkx calc.test

    Для работы программы требуется наличие /tmp0/1 раздела и свободного места на нём.
  • Hi Kenshin,

    I appreciate your work and value your experience. There are, however, two things I don't get:
    1. What is the problem you are solving with another custom format?
    2. What is your position on PE-related activities in this thread? I particularly mean arguments for PE and against custom formats like the current one.
  • dunkaist wrote:What is the problem you are solving with another custom format?
    1. Заголовок короче, чем M0x или PE/ELF.
    2. Меньше кода, загрузчик подготавливает всё для работы программы (стэк, память, загружает библиотеки (пока не реализовано)), выделяет необходимое кол-во памяти под строку с именем файла и строку с параметрами (т.е. не важно сколько они занимают, выделяется ровно столько места, сколько необходимо).
    3. Так как под стэк выделяется отдельный блок памяти, при переполнении произойдёт исключение General Fault, в существующих же программах при переполнении будут затираться лежащие перед стэком данные.
    4. Чтобы узнать такие важные параметры, например, как PID, теперь не нужно выделять килобайтный буфер и ждать пока его заполнит функция 9.
    5. Даже если программа в формате KX запакована, любая программа может быстро понять (т.е. не распаковывая весь файл), что это именно KX-файл, т.к. заголовок не упаковывается. Чтобы прочитать описание/иконки (будут в будущих версиях)/таблицы импорта, опять же не нужно распаковывать весь файл, достаточно разжать только данные подзаголовка.
    6. Различные фичи, которых нет в формате M0x, например краткое описание программы или аттрибуты файла (тип файла, тип используемого интерфейса (GUI/TUI и т.д.), минимальная SVN-ревизия ядра для запуска), в будущих версиях будут новые и (надеюсь) полезные фичи.
    7. Название формата, которое отражает то, что программа для KolibriOS, а не MenuetOS.
  • Против PE/ELF я ничего не имею, но идея заключалась в том, чтобы сделать формат в духе Колибри.
  • runkx теперь поддерживает чанк "General Executable File Attributes", который позволяет указать вид исполняемого файла, тип используемого интерфейса (GUI/TUI или неопределённый UI для служб, демонов и т.д.), флаги исполняемого файла, а также номер минимальной ревизии ядра, которая поддерживает данный KX-файл (например, если ваша программа использует фьютексы, вам нужно указать здесь ревизию 6926, т.к. их поддержка в ядре появилась в этой ревизии, и в таком случае runkx запустит такой файл только на ядре рев. 6926+).
    runkx_0.0.1b.7z (8.1 KiB)
    Downloaded 203 times
  • Пример программы в формате KX с использованием подзаголовка:

    Code: Select all

            use32
            org     0x0
    
            db      "KX", 0, 0x81           ;the KX header
    
            db      0, 4                    ;default entry point chunk
            dd      entry_point
    
            db      0x20, 12                ;general executable file attributes chunk
            dw      0                       ;a regular 32-bit KolibriOS application/program
            dw      1                       ;uses GUI
            dd      0                       ;executable file flags
            dd      0                       ;any version of kernel
            
            db      0xA0, 23                ;short description chunk
            db      "myapp - my application", 0
    
            db      -1
            
    entry_point:
            call    proc1
            call    proc2
            
            xor     eax, eax
            dec     eax
            int     0x40
            
    proc1:
            ...
            ret
            
    proc2:
            ...
            ret
    
    Флаги KX, установленные в 0x81, обозначают, что данная программа использует подзаголовок и что во время загрузки будут выделены 4 КБ памяти под неинициализированные данные. Если нужно больше 4 КБ, то можно использовать чанк "Initial Process Memory Size", указав в нём начальный размер общей памяти процесса. Если программа не использует неинициализированные данные, нужно сбросить старший бит флагов (т.е. должно быть 0x01).
  • думаю, когда формат уже устаканится, можно попробовать внедрить поддержку данного формата в ядро.
    The best way to predict the future is to create it.
  • На каких языках программирования можно писать программы с использованием формата kx?
    If there were no God, he would have to be invented.
    Voltaire

    Code: Select all

    program God
    begin
    
  • На любом ведь
    Главное чтобы компилер смог в этот формат
  • maxcodehack wrote:На любом ведь
    Главное чтобы компилер смог в этот формат
    1. Вот в том и проблема. Ассемблеры. Вроде всё. Потому и первоначальный заголовок Menuet не очень. С-- научили, местные С компилеры тоже. Из pascal и C (msvc или gcc) делали ухищрения в линкерах. Для паскаля вроде прога специальная была из виндового PE делать.
    2. Динамические библиотеки, линковка, как дела с этим? Этот формат для библиотек годится?
    3. Ресурсы предполагаются? Или хотя бы можно ли будет хранить иконку приложения в стандартном для всей Кос месте?
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • GerdtR wrote:
    maxcodehack wrote:На любом ведь
    Главное чтобы компилер смог в этот формат
    1. Вот в том и проблема. Ассемблеры. Вроде всё. Потому и первоначальный заголовок Menuet не очень. С-- научили, местные С компилеры тоже. Из pascal и C (msvc или gcc) делали ухищрения в линкерах. Для паскаля вроде прога специальная была из виндового PE делать.
    2. Динамические библиотеки, линковка, как дела с этим? Этот формат для библиотек годится?
    3. Ресурсы предполагаются? Или хотя бы можно ли будет хранить иконку приложения в стандартном для всей Кос месте?
    1. Привязки к какому-то определённому языку нет, хотя да, формат лучше всего подходит для fasm'а, который может создавать практически любые файлы с самой разной структурой.
    2. а) Текущая версия формата поддерживает таблицы импорта для неограниченного кол-ва библиотек, а runkx скоро научится их автоматически подключать (при этом разработчику не обязательно знать, где хранятся системные библиотеки, он может указать либо имя библиотеки полное,т.е. с путём, либо базовое - например, "libini.obg"). Сейчас для каждой библиотеки своя отдельная таблица импорта, а в версии 0.1 появится общая или универсальная таблица, описывающая импорт сразу нескольких библиотек.
    б) Изначально KX разработан именно для обычных программ и приложений, т.к. есть MS COFF, но расширяемость формата позволяет в будущем использовать его для библиотек/драйверов/чего-либо ещё, если такая надобность возникнет, разумеется.
    3. Да, поддержка ресурсов была запланирована с самого начала. В версии 0.1 появятся как минимум иконки, а насчёт других ништяков надо думать, ибо стандартов ресурсов (например, форм) в Kolibri практически нет. Также появятся возможность расширенного описания программы (версия, автор, дата сборки, описание и т.д.). Возможно ещё что-то будет, хотя лишних вещей в формате тоже не хочется.
  • Kenshin, а разве код лоадера не самая информативная часть после непосредственно описания спецификации?
    правильно ли я понимаю, что какой то формат тестируется вначале лоадером, и лишь потом помещается в ядро. управление памятью в пространстве адресов процесса вещь интересная. Она может быть реализована в юзермод лоадером?
    А еще как загрузка библиотек стыкуется с загрузкой их системой.
    Имею в виду что система загружает библиотеку в память однажды, НО...
    НО если код библиотеки не адресонезависимый то в процесс загружается свой экземпляр библиотеки...
    это то делает система, понятно.
    Но данные и код в библиотеке адресуются процессами по разному: данные в реальной памяти полностью разделяемы по разным адресам виртуальной памяти каждого процесса, а код наоборот: для каждого виртуального адреса создается свой экземпляр в реальной памяти релоцированный на этот адрес, в пределах одного виртуального адреса разных процессов в реальной памяти создается только 1 его экземпляр.
    Т.е. список подгруженных библиотек можно также на уровне лоадера хранить, а не на уровне ядра? И так вот с памятью тоже лоадер может играться?
  • Who is online

    Users browsing this forum: No registered users and 11 guests