переделать оконную систему...

Kernel-side graphics support
  • Я ничего не говорил о том где должен быть код, я говорил о том что оконная система должна быть полноценной иначе она будет не намного полезнее текущей. Взаимоотношения оконных объектов многих приложений эффективнее разрешать в одном программном модуле-сервисе. Сейчас, буквально, требуется создать (пусть минимальный) такой сейрвис заставить ядро (для поддержания обратной совместимости) "коннектиться" к этому сервису и его помошью эмулировать работу старых (текущих) оконных функций. (Что бы было понятно, я не говорю что вы должны делать, а рассказываю о том как я бы начал решать проблему, если бы у меня было достаточно знаний по ядру.)
    Такого понятия как сервис в KOS нет. Может попробовать его сделать :-) ? Это, наверное, всего лишь скрытое однажды загруженное пользовательское приложение предоставляющее услуги другим приложениям (и ядру) по средствам IPC. Или этого недостаточно?

    ..bw
  • bw

    А что ты называешь полноценной оконной системой и оконными объектами ? Если это окна MS WIN где каждый объект от "STATIC" до главного окна приложения создаётся ядром и является его объектом то ИМХО это неудачное решение. Для примера сравни с libGUI который реализует те же самые элементы управления на уровне приложения.
  • bw
    Это, наверное, всего лишь скрытое однажды загруженное пользовательское приложение предоставляющее услуги другим приложениям (и ядру) по средствам IPC. Или этого недостаточно?
    Все как то к идеям микроядра подталкиваешь?
    IPC - реализовано не самым удачным образом и будет медленно работать.
  • Вот только думаю проблем не будет??? Просто я пускал колибри в bochs, впринципе все ок, вот только приложения которые с таймером работали(pipes и еще какие-то), работали не правильно, таймер быстро тикал....возможно его обновить нужно, у тя проблем с таймером нет???
    С самого начала отлаживаю в Bochs - никаких проблем нет. Хотя таймер там действительно спешит, но это не проблема. Кстати, можно в Bochsdbg использовать информацию о символах: load-symbols "symbols.dbg", где symbols.dbg генерируется http://diamondz.land.ru/fasmdbg.exe
  • Mario79, все говорят, что надо выносить код из ядра, так что ничего особенного не предлагаю. Предлагать делать систему на микроядре (на своем) я не буду, работа для коллектива слишком сложная. А предусмотреть некоторые сервисы/сервера в системе и понемногу начинать выносить код из ядра вполне можно начать уже сейчас. Сейчас оптимизировали системные вызовы, завтра, смотри, за IPC кто-нибудь из кодеров возьмется.

    ..bw
  • А что если программа(сервер окон) вызывает(один раз) некую системную функцию, которая делает так что бы ядро перенаправляло все события клавиатуры и мыши этому приложению и только ему. Это приложение создает и перемещает окна(или регионы), а так же их перерисовывает через селектор gs. Обычное приложение через IPC создает обьекты этого сервера и получает события от мыши и клавиатуры также через IPC.
    Получается, что не надо менять оконную подсистему - "старые" приложения будут корректно работать до запуска этого сервера.
    Как такой вариант? Нормальный или туфта?
  • Maxis
    С существующим ядром это будет работать медленно.
  • Да и вообще такое будет работать медленно - вон в NT-линейке изначально за графику отвечал user-mode процесс, а потом Microsoft таки встроила графику в ядро.
  • Не знаю как у Майкрософта, а у Вилле скроллы рисуются ядром. Кстати, красиво рисуются...
  • diamond, Mario79
    И на сколько медленно оно будет работать есть соображения? На 500-ом будет тормозить.
    В роде в minixe такой же принцип и ничего - работает.
  • Атауальпа
    Это уже обсуждалось. Нельзя все пихать в ядро - это тупиковый путь.

    Maxis
    Minix - изначально микроядерная ОС, оно под такое заточено.
    Колибри - система с монолитным, в лучшем случае с гибридным строением ядра (на будущее).
  • А в Линуксе и Хайку как оконная подсистема устроена?
  • Maxis
    Насчет Хайку ничего не скажу, так как я не знаю.
    А насчет Линукс - лучше я ничего не скажу, потому что иначе начнется "холи вар"...
    Слишком много желающих и у Колибри выдрать GUI из ядра.
    Тело без башки говорят, бегает лучше, особенно заметно на курицах, если их отпустить после обезглавливания.
  • diamond
    Ну NT посложнее Колибри будет да и к тому же на C написана.

    Я так понимаю что главным тормозом в таком варианте как я предложил будет работа IPC и переключение RING3->RING0->RING3 ну и запись в видеопамять через GS(или в ядре с такой же скоростью запись происходит?). На счет переключений, то у Колибри большая фора по сравнению с Линуксом и Хайку(если я правильно понимаю этот тест http://haiku-os.org/blog/engima/2007-03 ... d_syscalls и данные fastcall тестов на этом форуме(на моём разогнанном до 2088МHz он показывает 96нс)).

    Mario79
    Слишком много желающих и у Колибри выдрать GUI из ядра.
    Я не предлагаю его выдирать, в том случае, что я предложил он не помешает. У текущего GUI я вижу только один недостаток - когда приложение входит в цикл и не может ответить на сообщение о перерисовке окна(когда требуются все ресурсы процессора, например, при архивации файла), то это окно при попытке его перетащить перестает перерисовываться и может пропасть совсем, я так понимаю, чтобы решить эту проблему нужно пихать GUI-обьекты в ядро.
    Кстати k@sTIg@r, а в твоем варианте будет эта проблема решена?
    А насчет Линукс - лучше я ничего не скажу, потому что иначе начнется "холи вар"...
    Может быть в личку скинешь?
  • Who is online

    Users browsing this forum: No registered users and 5 guests