Board.KolibriOS.org

bw

Все GUI элементы управления программа может делать сама в своём коде или при помощи библиотек. Делать их на уровне ядра не надо. Чем больше код тем больше ошибок. Если баг в ДЛЛ то упадёт только одна программа если в ядре то упадёт всё. Отлаживать ядро и искать там ошибки намного сложнее.

Я ничего не говорил о том где должен быть код, я говорил о том что оконная система должна быть полноценной иначе она будет не намного полезнее текущей. Взаимоотношения оконных объектов многих приложений эффективнее разрешать в одном программном модуле-сервисе. Сейчас, буквально, требуется создать (пусть минимальный) такой сейрвис заставить ядро (для поддержания обратной совместимости) "коннектиться" к этому сервису и его помошью эмулировать работу старых (текущих) оконных функций. (Что бы было понятно, я не говорю что вы должны делать, а рассказываю о том как я бы начал решать проблему, если бы у меня было достаточно знаний по ядру.)
Такого понятия как сервис в 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, а в твоем варианте будет эта проблема решена?

А насчет Линукс - лучше я ничего не скажу, потому что иначе начнется "холи вар"...

Может быть в личку скинешь?