Колибри PE

Kernel architecture questions
  • Хорошая новость.
    Может вместо sys.dll выбрать другое имя (kos.dll, ksys.dll, kolibri32.dll и т.п.), что бы при "случайном" запуске программы в Windows было бы понятно по имени отсутствующей динамической библиотеки что за дела.

    ..bw
  • Название не принципиально и расширение может быть любым, только lib плохо подходит потому что будет путаница со статическими библиотеками и implib.
  • Вау, вот это новость! Респект!

    >Ещё можно можно сделать загруку PE программ с автоматической линковкой DLL и общесистемные DLL.
    Если я правильно понимаю, то теперь можно будет реализвать dll в которой будут обертки для системных вызовов колибри. Реализовать такую же для винды. И полноценно пускать и там и там?
  • k@sTIg@r wrote:Если я правильно понимаю, то теперь можно будет реализвать dll в которой будут обертки для системных вызовов колибри. Реализовать такую же для винды. И полноценно пускать и там и там?
    А нафига?
  • Например, чтобы программы Колибри могли использовать плагины от виндовых программ.
  • Атауальпа
    1. Возможность загрузки PE-exe и PE-dll - разные вещи. Не вижу причин, мешающих Колибри-программе загружать PE-dll при условии поддержки ядра.
    2. Для использования плагинов другой программы абсолютно необходима похожесть внутреннего строения - или потребуется очень трудоёмкие усилия по эмуляции plugin api.
    Ушёл к умным, знающим и культурным людям.
  • ИМХО, так удобней чем через эмулятор, точнее эмулятор в виде экзешки. И не надо вешать никакие обработчики, а сразу же писать это все дело в виде ф-ций. Возможно даже под WINE'ом удастся поднять.
    Но опять же, врядли согласитесь писать приложения которые будут не через syscall'ы работать а через обертки. Насколько помню vectoroc уже предлагал такую схему, но никто не поддержал.
  • Мне почему-то упорно кажется, что мы пишем свою операционную систему со своими форматами исполняемых файлов и своими системными вызовами...
  • мне тоже так казалось.....раньше
    Но после обсуждения "расширение запускаемых файлов" я увидел что большинство пользуются эмулятором и основным аргументом было "удобно запускать под эмулятором"...
    Но не о том разговор. Стоит ли создавать обертки для системных вызовов?
  • Проблема в том что никто больше наш стандарт исполняемых файлов не поддерживает. Даже портированному Фасму надо его прописывать в двоичном виде. Никакого format KOLIBRI там нет в отличие от COFF ELF и т.п. Так же и в ktcc. Собственно и никаких форматов исполняемых файлов у нас нет. Есть два варианта заголовков 'MENUET00' и 'MENUET01'. Сами заголовки очень примитивны. Там нет таблицы секций, значит нельзя защитить код от переписывания, данные от исполнения и т.д. Выбор coff.obj для драйверов был не совсем удачным решением потому что на практике кроме Фасма такой драйвер больше ни чем не скомпилировать. Не знаю, может это кого-то радует, меня нет. Что касается системных вызовов то сейчас каждый пишет для них свои обёртки. ИМХО стоит разработать общий API для программ на ЯВУ. Вообще лучшим вариантом было бы делать все обращения к ядру только через DLL, скинуть туда всю черновую работу по проверке параметров и таким образом разгрузить ядро и уменьшить код выполняющийся в привилегированном режиме, но это уже другая тема.
    Что касается загрузки pe.exe то технически нет никакой разницы. Загрузка .exe даже проще потому что там нет релокаций.
    Last edited by Serge on Wed Oct 24, 2007 5:53 pm, edited 1 time in total.
  • Serge> Название не принципиально и расширение может быть любым
    Не скажи.
    Если это именно виндовый по формату DLL, то он и должен иметь расширение DLL, что бы небыло лишней путаницы и вопросов. Другое дело, что pe dll для KOS не будут работать в винде, если они используют системные вызовы KOS или не реализованные в винде динамические библиотеки и поэтому лишний раз "светиться" расширением бестолковым в отличных от KOS системах, наверное, не стоит. Тем не менее, я вижу удобство использования существующих форматов в том, что ничего не надо придумывать, существуют сторонние инструменты для работы с ними, существуют компиляторы и линковщики выдающие код в этих форматах, т.е. отсутствует необходимость конвертирования в родной KOS формат (в частности я говорю про компиляторы, которые в KOS ничего сами не сделают).

    ..bw
  • >скинуть туда всю черновую работу по проверке параметров и таким образом разгрузить ядро
    ИМХО это не правильно, проверки в ядре должны быть, иначе будут дыры через которые можно убить систему. Либо придется ограничить программы на прямой вызов ядреных функций, что тоже не очень.
  • bw
    По формату виндовый но есть отличия. Раньше секции в файле выравнивались на 512 байт. Сейчас большинство линковщиков выравнивает секции в файле на границу страницы. Такой модуль загружается в память как memory-mapped что упрощает и ускоряет весь процесс загрузки но увеличивает размер файла, особенно если там много секций. ld c ключом --file-alignment 16 уменьшит размер файла но очень вероятно что он не загрузится в Win. Ещё базовый адрес приложений в Колибри 0x0000 а в Win 0x400000. Наконец в Колибри программа и DLL могут быть упакованы так что бинарно они совсем не будут выглядеть как MS PE.

    k@sTIg@r
    Я не говорил что все проверки, но правильность указателей, строк, путей к файлам и прочие санитарные мероприятия можно проводить и в user-mode. Разумеется в таком случае вызовы ядра должны быть защищены от прямого доступа что не так и сложно. Вообще сначала проверками параметров пренебрегают, а потом жалуются что всё плохо работает.
  • А поддержка dll формата MS COFF останется ? Меня интересует, не придётся ли переделывать libGUI под формат PE dll ?
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Who is online

    Users browsing this forum: No registered users and 1 guest