Board.KolibriOS.org

А что, если попробовать интегрировать возможность реализации DLL в ядро? Тогда к DLL обращаться через IPC будет не сложно, но проблема в передаче параметров. После реализации открываются большие перспективы для MeOS как модульной системы (а не так, что все ядро одним файлом).

Приблизительно так и должно быть. И в любом случае так будет. Но не сейчас. Я могу свободно представить себе, насколько возрастёт потенциал ядра с введением DLL, но делается всё не в один день.

Serge wrote:Да PE и ELF содержат много дополнительной и "ненужной" на первый взгляд информации. Но когда начинаешь делать загрузку по произвольному адресу и с защитой памяти эта ненужная информация становится просто необходимой.

typedef struct _IMAGE_NT_HEADERS {
    DWORD Signature;
    IMAGE_FILE_HEADER FileHeader;
    IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;

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;

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

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

k@sTIg@r wrote:Если я правильно понимаю, то теперь можно будет реализвать dll в которой будут обертки для системных вызовов колибри. Реализовать такую же для винды. И полноценно пускать и там и там?

Такая защита от плохих приложений делается по-другому, проверками указателей, независимо от атрибутов страниц.

Serge wrote:Что касается "sys.dll" то повторю ещё раз: я предлагаю сделать библиотеку с единым API системных вызовов для программ на С и Паскале (если получится) IMHO такая интерфейсная библиотека избавит от необходимости каждому изобретать свои версии draw_window, ksys_draw_window, kos_draw_window и т.п. и дополнительно проводить проверку параметров о которой забыли разработчики ядра, а так же фиксить некоторые особенности системы.

k@sTIg@r wrote:4. Упрощает разработку софта под колибри, а собственно и к-во разработчиков.

k@sTIg@r wrote:Единственный минус, который повлияет на ядро/дистрибутив - это увиличится размер ядра.
Но и тут есть выход, я думаю без проблем влепить опцию которая будет компилить ядро без поддержки PE.

diamond wrote:я против признания PE основным форматом

diamond wrote:А для привлечения разработчиков нужны всякие визуальные среды... Но при этом возникает другой вопрос: а нужно ли нам привлекать таких разработчиков?

diamond wrote:Нет уж, выкидывать полезные фичи только из соображений экономии места - не наш метод.

Для меня удобная среда это которая предлагает удобные средства для написания кода

diamond wrote:...а попутно создаёт многомегабайтные продукты и отучает использовать мозг...