Колибри PE

Kernel architecture questions
  • andrew_programmer

    MS COFF остаётся, а вообще coff легко линкуется в PE DLL
  • 1. DLL - это аббревиатура от Dynamic Linking Library и не подразумевает никакого формата файла.
    2. Если сделать загрузку PE-файлов как бинарников Колибри, сразу же возникнет путаница Колибри-бинарников и Windows-бинарников. И посыплются куча вопросов "а чего оно не запускается" и хотелок "ну PE-екзешники вы же загружать умеете, как насчёт загрузки Windows-программ?" А уж как расстроятся линуксоиды...
    3. Сравните формат PE и "формат" MENUETxx. Посчитайте размер заголовков, количество лишних/ненужных/неиспользуемых полей/областей и только потом продолжайте предлагать подобные идеи. Напоминаю, что Колибри позиционируется как маленькая и быстрая ось.
    4. Колибри позиционируется также как система, большая часть которой написана на ассемблере. Нафига в ассемблерных программах (которых большинство и, я надеюсь, останется большинство) вообще какие-то обёртки для всех API? Банальный "int 0x40" короче и быстрее.
    5. Желающим видеть программы, валидные одновременно и в Колибри, и в Windows: все системные программы и все файловые менеджеры написаны на ассемблере и напрямую используют системные вызовы. Выкиньте их - и что останется? Портированные вещи типа doom и dosbox? Знаете ли, их Windows-версии всегда будут работать лучше Колибри-версий, запущенных под Windows. А свои программы в любом случае можно писать так, чтобы их можно было скомпилировать и как Kolibri-программу, и как Windows-программу (@rcher тому пример).
    6. tcc как раз-таки генерирует формат MENUET01.
    Ушёл к умным, знающим и культурным людям.
  • 1. Да DLL это только буквы и с форматом никак не связаны.
    Наверное поэтому разговор о DLL шёл несколько лет без всях результатов. Интересующиеся вопросом могут посмотреть тему. Своих форматов для DLL так никто и не разработал. Тем более что ещё нужны инструменты для работы с новым форматом.

    2. Хотелки будут всегда. Их количество определяется числом новичков узнавших о системе и больше связано с распространением новостей о системе чем с её возможностями и внутренним устройством.

    3,4 Да PE и ELF содержат много дополнительной и "ненужной" на первый взгляд информации. Но когда начинаешь делать загрузку по произвольному адресу и с защитой памяти эта ненужная информация становится просто необходимой. Для примера: сейчас код ядра вообще никак не защищён от затирания. Достаточно ф.70.0 считать 128Кб по адресу 0х80010000 чтобы затереть всё ядро. И сделать такую защиту практически невозможно потому что код ядра перемешан с данными - следствие "компактного и не отягощённого всякими ненужными полями" raw формата ядра. Что касается размера файлов то чем больше модуль тем меньше процент накладных расходов, а упаковка вообще сводит их к минимуму.

    Никто не предлагал делать обёртки системных вызовов для асм-программ. Речь шла о едином API для ЯВУ. Впрочем никто и не запрещает такими обёртками пользоваться. Кому как нравится.

    Похоже что в конечном счёте все упирается в вопрос о "чистоте системы". Для Вилле это был принципиально - в МеОС всё должно быть написан на асме. В Колибри если я не ошибаюсь так вопрос никогда не стоял.


    P.S. Две цитаты:

    Vlad G. Maslakov 21 май 2005 16:26
    А что, если попробовать интегрировать возможность реализации DLL в ядро? Тогда к DLL обращаться через IPC будет не сложно, но проблема в передаче параметров. После реализации открываются большие перспективы для MeOS как модульной системы (а не так, что все ядро одним файлом).
    mike.dld 21 май 2005 16:56
    Приблизительно так и должно быть. И в любом случае так будет. Но не сейчас. Я могу свободно представить себе, насколько возрастёт потенциал ядра с введением DLL, но делается всё не в один день.
  • Serge wrote:Да PE и ELF содержат много дополнительной и "ненужной" на первый взгляд информации. Но когда начинаешь делать загрузку по произвольному адресу и с защитой памяти эта ненужная информация становится просто необходимой.
    Начинаем разбирать описание формата PE.
    В начале файла идёт DOS-заголовок и DOS-заглушка. Абсолютно ненужные и неиспользуемые. Уже получаем минимум 0x40 (а обычно в пару раз больше) лишних байт.
    Далее,

    Code: Select all

    typedef struct _IMAGE_NT_HEADERS {
        DWORD Signature;
        IMAGE_FILE_HEADER FileHeader;
        IMAGE_OPTIONAL_HEADER32 OptionalHeader;
    } IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;
    
    Ну сигнатура - это понятно. А вот дальше

    Code: Select all

    typedef struct _IMAGE_FILE_HEADER {
        WORD    Machine;
        WORD    NumberOfSections;
        DWORD   TimeDateStamp;
        DWORD   PointerToSymbolTable;
        DWORD   NumberOfSymbols;
        WORD    SizeOfOptionalHeader;
        WORD    Characteristics;
    } IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
    
    Из 20 байт 12 (TimeDateStamp, PointerToSymbolTable, NumberOfSymbols) ненужны и не используются! Продолжать?
    Для примера: сейчас код ядра вообще никак не защищён от затирания. Достаточно ф.70.0 считать 128Кб по адресу 0х80010000 чтобы затереть всё ядро. И сделать такую защиту практически невозможно потому что код ядра перемешан с данными - следствие "компактного и не отягощённого всякими ненужными полями" raw формата ядра.
    Ну, допустим, кто-то выделил абсолютно все переменные в блоки iglobal/uglobal, отделил начало данных от конца кода и сделал все страницы кода доступными только на чтение. Тогда функцией 70.0 можно считать 64 Кб по адресу 0x80000000 - и всё равно можно давить Reset, потому что вместо важных системных данных появляется каша. И формат ядра тут ни при чём. Такая защита от плохих приложений делается по-другому, проверками указателей, независимо от атрибутов страниц.
    Serge wrote:Никто не предлагал делать обёртки системных вызовов для асм-программ. Речь шла о едином API для ЯВУ.
    А мне почему-то показалось, что пост
    k@sTIg@r wrote:Если я правильно понимаю, то теперь можно будет реализвать dll в которой будут обертки для системных вызовов колибри. Реализовать такую же для винды. И полноценно пускать и там и там?
    именно это и предлагает. И чистота системы тут ни при чём.
    Ушёл к умным, знающим и культурным людям.
  • diamond

    И того получается две сотни лишних байтов. И разумеется мы никак не можем себе этого позволить.

    Я не утверждал что ненужных нам полей там вообще нет. Но их процент невелик. Для примера килобайтный заголовок bochsdbg.exe 2.3.5 составляет 0,045% от всего файла. Это приемлимо или нет ?
    Для ac97snd это 1.02%. Упакованный win-екзешник весит 23 543 байта а колибри 23 478 байт. И того разница в 65 байт или 0.28% от окончательного размера бинарника.
    Такая защита от плохих приложений делается по-другому, проверками указателей, независимо от атрибутов страниц.
    Разумеется ты прав. Ничто не защитит данные ядра от затирания самим ядром. Но это врождёный недостаток ядра вообще и к сожалению не последний.
    Такие вопросы должны решаться ещё при проектировании системы в том числе и о проверках параметров. Только никто этих проверок не делает и я в том числе. Большинство вызовов записывающих данные по указателю могут записать их куда угодно.
    Но сделать эффективную защиту от пререзаписи расшаренной DLL можно а для этого нужны таблицы секций и их атрибуты то есть те самые "лишние" поля. Если у тебя или ещё у кого-нибудь есть время на разработку такого формата с релокациями, динамическим связыванием и прочими современными наворотами то у меня его нет и нет желания его разрабатывать. PE я выбрал потому что он проще и доступней. Скомпилировать расшаренную .so мне удалось только в Linux, позиционно независимый код выглядит довольно громоздким а его загрузка не самым простым процессом. Тем кто интересуется вопросом рекомендую поискать в сети книгу "Linkers and loaders". Вообще загрузчик PE побочный продукт другой работы и написан на С. Просто появилась возможность встроить его в Колибри и я решил её использовать. Весь код находится в файле peload.inc и остальным ядром пока не используется. Если большинство считает что нам PE длл и екзешники не нужны, или кто-нибудь придумает новый компактный и замечательный формат, файл можно безболезнено удалить.

    Если кому-то хочется сделать DLL с эмуляцией вызовов Колибри под Win и наоборот, то флаг в руки. В чём вообще проблема? Будет ещё один эмулятор.

    Что касается "sys.dll" то повторю ещё раз: я предлагаю сделать библиотеку с единым API системных вызовов для программ на С и Паскале (если получится) IMHO такая интерфейсная библиотека избавит от необходимости каждому изобретать свои версии draw_window, ksys_draw_window, kos_draw_window и т.п. и дополнительно проводить проверку параметров о которой забыли разработчики ядра, а так же фиксить некоторые особенности системы. Сам я на асме больше кодить не буду так что простоту вызовов int 0x40 оценить не смогу а вот длл с API представляется очень полезной.
  • diamond, я не подразумевал перевести все программы в формат PE и подсадить их на "sys.dll". Я всего лишь спрашивал, реально ли такое провернуть. Извини может я не правильно выразился.

    Я полностью поддерживаю идею с поддержкой PE. А также единой библиотеки для ЯВУ.
    1. Она ни кому не мешает
    2. Она ни кого не заставляет переходить с формата MENUETxx или COFF на PE.
    3. Никто никого не заставляет потом PE-файлы пихать в дистрибутив, так что лишнее место никто не зохавает.
    4. Упрощает разработку софта под колибри, а собственно и к-во разаработчиков.
    Единственный минус, который повлияет на ядро/дистрибутив - это увиличится размер ядра.
    Но и тут есть выход, я думаю без проблем влепить опцию которая будет компилить ядро без поддержки PE.
  • Скажем так: я за поддержку загрузки PE как таковую, я против признания PE основным форматом - именно потому, что там много лишних полей (действительно лишних! таблицу секций с атрибутами я лишней не считаю!), которые будут давать заметный вклад в маленькие программы, но действительно пренебрежимо малы в ЯВУшных монстрах.
    Serge wrote:Что касается "sys.dll" то повторю ещё раз: я предлагаю сделать библиотеку с единым API системных вызовов для программ на С и Паскале (если получится) IMHO такая интерфейсная библиотека избавит от необходимости каждому изобретать свои версии draw_window, ksys_draw_window, kos_draw_window и т.п. и дополнительно проводить проверку параметров о которой забыли разработчики ядра, а так же фиксить некоторые особенности системы.
    Тогда я обеими руками за.
    k@sTIg@r wrote:4. Упрощает разработку софта под колибри, а собственно и к-во разработчиков.
    Вот тут ты не прав. Какая разница, что использует menuetlibc - статически линкуемый код или динамическую библиотеку? На исходный текст программ это не влияет. А для привлечения разработчиков нужны всякие визуальные среды... Но при этом возникает другой вопрос: а нужно ли нам привлекать таких разработчиков?
    k@sTIg@r wrote:Единственный минус, который повлияет на ядро/дистрибутив - это увиличится размер ядра.
    Но и тут есть выход, я думаю без проблем влепить опцию которая будет компилить ядро без поддержки PE.
    Нет уж, выкидывать полезные фичи только из соображений экономии места - не наш метод.
    Ушёл к умным, знающим и культурным людям.
  • diamond wrote:я против признания PE основным форматом
    Так никто и не предлагает :)
    diamond wrote:А для привлечения разработчиков нужны всякие визуальные среды... Но при этом возникает другой вопрос: а нужно ли нам привлекать таких разработчиков?
    Ты имеешь ввиду что-то вроде Builder'a с палитрой компонентов?
    Если да, то тут ты тоже немного не прав. Для меня удобная среда это которая предлагает удобные средства для написания кода. Что-то вроде eclips'a и т.п. Аналогов под колибри нет.
    Я не спорю, я не разбирался как компилить для колибри на ЯВУ, может данный способ и не будет менне корявым чем теперешний. Так что дальше промолчу :)
    diamond wrote:Нет уж, выкидывать полезные фичи только из соображений экономии места - не наш метод.
    ну тогда вообще замечательно :)
  • Serge или кто-нибудь другой сделайте возможность подключения PE DLL в пользовательских приложениях, это ведь не очень сложно. Как я понял это еще не реализовано. Сам я пока боюсь лезть в код ядра.

    ..bw
  • Для меня удобная среда это которая предлагает удобные средства для написания кода
    ...а попутно создаёт многомегабайтные продукты и отучает использовать мозг...
  • Serge
    А загрузчик обрабатывает всякие тонкости PE-формата? Например, TLS callbacks или bound import?
  • diamond wrote:...а попутно создаёт многомегабайтные продукты и отучает использовать мозг...
    Ты не понял. Я про всякие backfill'ы. Ctrl+LMB на имени функции выкидывает меня туда где эта ф-ция обьявлена. Тоже самое про переменные. При простом наводе на функцию показывает ее обьявление (какие параметры сколько и в каком порядке) и если есть то ее шапка /** ...*/.
    И куча куча других мелких полезностей которые нифига не отключают мозг, а просто освобождают его от избыточной инфы. А также экономит время на открытие другого файла и поиска в нем необходимой тебе ф-ции/переменной или других данных. Особенно при использовании не свих хидеров. Ну и собсно кнопочки компиляции/билда/запуска и т.д. которые опять же ускоряют процедуру написания кода.
  • k@sTIg@r
    Я вполне допускаю существование программистов, которым от сред типа Visual Studio и Delphi действительно нужны только продвинутые средства редактирования кода. Но я также уверен в существовании программистов, которым нравится именно написание программ в стиле "набросал мышкой кнопочек на форму, подредактировал их свойства и выложил как готовый продукт"...
    Ушёл к умным, знающим и культурным людям.
  • diamond
    Конечно такие есть. Я тоже таким был. Точнее я с такого начинал познание ПК. Потом мне пространства начало не хватать, сильно уж ограниченое программирование. Потом забил и пошел дальше.
    Но все равно до сих пор я признаю такой вид программирования. Иногда приходится писать мелкие программки. На WinAPI дольше, куда проще пихнуть пару editbox'ов и копочек и написать их обработчики.
    Да и некоторые программы получаются хорошими, пусть тяжеловатыми. Но зато быстро и удобно.
    Посмотри на некоторые приложения колибри такие как сетап, настройка сети и т.д. Уже есть libGUI но никто не спешит переводить их под эту библиотеку. Зато на форуме присутствует много людей которые с удовольствием это сделали будь визуальная среда разработки, т.к. асма боятся как огня. Так что не стоит не дооценивать "такой способ разработки".
    Разговор переходит в оффтоп...
  • Who is online

    Users browsing this forum: No registered users and 8 guests