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

Applications development, KoOS API questions
  • ProMiNick wrote:управление памятью в пространстве адресов процесса вещь интересная. Она может быть реализована в юзермод лоадером?
    Даже с помощью функций 64.1 и 68.12/68.13/68.20 и т.д. уже можно управлять памятью нового процесса. Например, первый вариант (скорее всего, можно ещё проще и изящнее сделать), который приходит на ум:
    1. загрузчик устанавливает с помощью 64.1 размер своей памяти в размер_образа_исполняемого_файла + размер_неинициализированных_данных + размер_стэка
    2. затем инициирует кучу (кстати, как известно, с этого момента 64.1 нельзя уже использовать) и выделяет блок памяти для кода, который будет записывать/загружать образ
    3. копирует этот код в динамически выделенный блок (желательно, чтобы код был позиционно-независимым, иначе придётся пересчитывать адреса)
    4. загружает образ в память, выделенную с помощью функции 64.1
    5. устанавливает новую вершину стэка
    6. обнуляет регистры, настраивает окружение процесса
    7. каким-то образом очищает память, выделенную для кода загрузки (вот это непросто будет сделать)
    8. делает переход на точку входа (которая, например, указана в полях заголовка)
    Если код должен загружаться не по нулевому адресу, то ничего толкового не выйдет - нужно будет либо драйвер писать, либо ядро ковырять. Главный и единственный минус такой схемы - это то, что нельзя переименовать процесс (он так и останется "х-loader"). Поэтому для runkx этот вариант не подошёл.
  • Ну лоадер - решение временное, как я понимаю. Потому библиотеки достаточно грузить просто, каждому процессу по экземпляру. Конечно, когда и если это будет переносится в ядро, загрузчик будет уже библиотеки грузить как положено. Данные каждому, код всем общий.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • GerdtR wrote:Ну лоадер - решение временное, как я понимаю. Потому библиотеки достаточно грузить просто, каждому процессу по экземпляру. Конечно, когда и если это будет переносится в ядро, загрузчик будет уже библиотеки грузить как положено. Данные каждому, код всем общий.
    А никаких проблем с этим и нет уже, подсистема памяти уже всё делает сама, а значит библиотечный код разделяется, данные неизменяемые (константы) тоже, насколько я понимаю, разделяются, а изменяемые (локальные) у каждого процесса свои.
  • Привет!
    Тоже задумывался над новым форматом, но немного с другими, более системными идеями. К названию в итоге пришел к такому же, т.е. KX (ты не поверишь), поэтому оно мне нравится.
    Новый формат необходим, во-первых для того, чтобы реализовать полноценную поддержку автозагрузки библиотек, а во-вторых сделать единый формат для приложений (*.kxa), библиотек (*.kxl) и драйверов (*.kxd) и т.п.. Сейчас с этим творится какой-то хаос: приложения используют формат MENUET01 (также есть версия MENUET02 и еще самый древний MENUET00), библиотеки - COFF и даже PE, драйверы только PE. И соответственно в ядре живет код для всего этого зоопарка форматов, почему нельзя сделать единый формат для всего?
    Не понимаю, что тут делает PE - он не вписывается в философию Kolibri, его особенность в использовании с дисковой памятью (полноценная идея PE в том, что он состоит из секций и мапится в память нужными участками, а когда нужно, если секция не менялась в памяти, можно без проблем ее выгрузить без задействования файла подкачки и в нужное время загрузить заново), которой в Kolibri нет.
    Например, у PE часть секций для выравнивания заполнена нулями - зачем ее хранить на диске если она все равно в Kolibri никогда там не будет использована? Загрузчику ничего не стоит дополнить неиспользуемые части страницы нулями.

    Ну и как дополнение не будет лишним реализовать следующее (эти дополнительные идеи также используются в моей концепции):

    1. Защита страниц кода и константных данных. Сейчас вся пользовательская память доступна для чтения и записи. Т.е. по ошибке можно затереть код и/или данные и получить сюрпризы (я с таким уже столкнулся в Kolibri - искать такие баги крайне сложно). Потери памяти от этой полезной функции небольшие, как минимум тратится лишняя страница в 4 кБ.
    2. не хранить на диске и не загружать в память лишнюю информацию. Например, не хранить в образе указатели импорта, а только ссылаться на нужные участки, которые будут доступны только при загрузке в память. Не загружать заголовок и таблицы, которые нужны нужны только загрузчику (зачем это в памяти?), т.е. загружать только код и данные
    3 . TLS (локальная память потока) - зачатки этого в ядре уже имеются
    ...

    Считаю, надо прийти к общей системной идее по новому формату, который затем еще нужно обкатывать. Либо дорабатывать какой-то имеющийся хорошо известный и давно используемый формат, скажем COFF (он больше подходит под философию Kolibri с учетом описанных выше идей, к тому же поддерживается многими компиляторами и поддерживается ядром и давно используется), т.е. делать надстройку над существующим форматом.

    По предложенной спецификации увидел несколько интересных идей, но есть и недостатки, ну и спецификация не охватывает много нужных особенностей.

    Недостатки:
    1. зачем UTF-8? Для символов и имени библиотеки достаточно ASCII, это общепринятый стандарт.
    2. очевидно, что самый компактный вариант чанка - 8 бит, как я понял он задается один раз и остальными вариантами уже не воспользуешься.
    3. зачем столько флагов по сжатию, почему нельзя просто сжать все кроме заголовка? Не понял, как распаковщик узнает какой размер будет после распаковки (какой надо выделить буфер)?
    4. как загрузчик узнает где конец образа для загрузки (какой ему надо выделить выделить буфер)?
    5. Таблица импорта состоит из массива указателей и строк. Как загрузчик узнает размер массива указателей? зачем нужны указатели (это увеличивает размер таблицы) если строки следуют друг за другом? Строки достаточно разделить между собой. А указатель на таблицу строк зачем? Очевидно же, что он идет после массива указателей, к тому же все указатели от начала файла.
    6. Не понял, где указатели импорта, которые заполняет загрузчик?
    7. Почему нет таблицы экспорта?
    8. Если это библиотека (драйвер), то адрес загрузки может измениться. Как загрузчик поймет какие участки образа надо править в этом случае?
    9. Как узнать командную строку?
    ...
  • Когда будет дальнейшая работа по развитию формата КХ? Подвижки хоть какие то есть?
  • Оно живое..?
    If there were no God, he would have to be invented.
    Voltaire

    Code: Select all

    program God
    begin
    
  • Who is online

    Users browsing this forum: No registered users and 11 guests