bw
Все GUI элементы управления программа может делать сама в своём коде или при помощи библиотек. Делать их на уровне ядра не надо. Чем больше код тем больше ошибок. Если баг в ДЛЛ то упадёт только одна программа если в ядре то упадёт всё. Отлаживать ядро и искать там ошибки намного сложнее.
переделать оконную систему...
Я ничего не говорил о том где должен быть код, я говорил о том что оконная система должна быть полноценной иначе она будет не намного полезнее текущей. Взаимоотношения оконных объектов многих приложений эффективнее разрешать в одном программном модуле-сервисе. Сейчас, буквально, требуется создать (пусть минимальный) такой сейрвис заставить ядро (для поддержания обратной совместимости) "коннектиться" к этому сервису и его помошью эмулировать работу старых (текущих) оконных функций. (Что бы было понятно, я не говорю что вы должны делать, а рассказываю о том как я бы начал решать проблему, если бы у меня было достаточно знаний по ядру.)
Такого понятия как сервис в KOS нет. Может попробовать его сделать ? Это, наверное, всего лишь скрытое однажды загруженное пользовательское приложение предоставляющее услуги другим приложениям (и ядру) по средствам IPC. Или этого недостаточно?
..bw
Такого понятия как сервис в KOS нет. Может попробовать его сделать ? Это, наверное, всего лишь скрытое однажды загруженное пользовательское приложение предоставляющее услуги другим приложениям (и ядру) по средствам IPC. Или этого недостаточно?
..bw
bw
А что ты называешь полноценной оконной системой и оконными объектами ? Если это окна MS WIN где каждый объект от "STATIC" до главного окна приложения создаётся ядром и является его объектом то ИМХО это неудачное решение. Для примера сравни с libGUI который реализует те же самые элементы управления на уровне приложения.
А что ты называешь полноценной оконной системой и оконными объектами ? Если это окна MS WIN где каждый объект от "STATIC" до главного окна приложения создаётся ядром и является его объектом то ИМХО это неудачное решение. Для примера сравни с libGUI который реализует те же самые элементы управления на уровне приложения.
bw
IPC - реализовано не самым удачным образом и будет медленно работать.
Все как то к идеям микроядра подталкиваешь?Это, наверное, всего лишь скрытое однажды загруженное пользовательское приложение предоставляющее услуги другим приложениям (и ядру) по средствам IPC. Или этого недостаточно?
IPC - реализовано не самым удачным образом и будет медленно работать.
С самого начала отлаживаю в Bochs - никаких проблем нет. Хотя таймер там действительно спешит, но это не проблема. Кстати, можно в Bochsdbg использовать информацию о символах: load-symbols "symbols.dbg", где symbols.dbg генерируется http://diamondz.land.ru/fasmdbg.exeВот только думаю проблем не будет??? Просто я пускал колибри в bochs, впринципе все ок, вот только приложения которые с таймером работали(pipes и еще какие-то), работали не правильно, таймер быстро тикал....возможно его обновить нужно, у тя проблем с таймером нет???
Mario79, все говорят, что надо выносить код из ядра, так что ничего особенного не предлагаю. Предлагать делать систему на микроядре (на своем) я не буду, работа для коллектива слишком сложная. А предусмотреть некоторые сервисы/сервера в системе и понемногу начинать выносить код из ядра вполне можно начать уже сейчас. Сейчас оптимизировали системные вызовы, завтра, смотри, за IPC кто-нибудь из кодеров возьмется.
..bw
..bw
А что если программа(сервер окон) вызывает(один раз) некую системную функцию, которая делает так что бы ядро перенаправляло все события клавиатуры и мыши этому приложению и только ему. Это приложение создает и перемещает окна(или регионы), а так же их перерисовывает через селектор gs. Обычное приложение через IPC создает обьекты этого сервера и получает события от мыши и клавиатуры также через IPC.
Получается, что не надо менять оконную подсистему - "старые" приложения будут корректно работать до запуска этого сервера.
Как такой вариант? Нормальный или туфта?
Получается, что не надо менять оконную подсистему - "старые" приложения будут корректно работать до запуска этого сервера.
Как такой вариант? Нормальный или туфта?
Maxis
С существующим ядром это будет работать медленно.
С существующим ядром это будет работать медленно.
Да и вообще такое будет работать медленно - вон в NT-линейке изначально за графику отвечал user-mode процесс, а потом Microsoft таки встроила графику в ядро.
Не знаю как у Майкрософта, а у Вилле скроллы рисуются ядром. Кстати, красиво рисуются...
diamond, Mario79
И на сколько медленно оно будет работать есть соображения? На 500-ом будет тормозить.
В роде в minixe такой же принцип и ничего - работает.
И на сколько медленно оно будет работать есть соображения? На 500-ом будет тормозить.
В роде в minixe такой же принцип и ничего - работает.
Атауальпа
Это уже обсуждалось. Нельзя все пихать в ядро - это тупиковый путь.
Maxis
Minix - изначально микроядерная ОС, оно под такое заточено.
Колибри - система с монолитным, в лучшем случае с гибридным строением ядра (на будущее).
Это уже обсуждалось. Нельзя все пихать в ядро - это тупиковый путь.
Maxis
Minix - изначально микроядерная ОС, оно под такое заточено.
Колибри - система с монолитным, в лучшем случае с гибридным строением ядра (на будущее).
А в Линуксе и Хайку как оконная подсистема устроена?
Maxis
Насчет Хайку ничего не скажу, так как я не знаю.
А насчет Линукс - лучше я ничего не скажу, потому что иначе начнется "холи вар"...
Слишком много желающих и у Колибри выдрать GUI из ядра.
Тело без башки говорят, бегает лучше, особенно заметно на курицах, если их отпустить после обезглавливания.
Насчет Хайку ничего не скажу, так как я не знаю.
А насчет Линукс - лучше я ничего не скажу, потому что иначе начнется "холи вар"...
Слишком много желающих и у Колибри выдрать GUI из ядра.
Тело без башки говорят, бегает лучше, особенно заметно на курицах, если их отпустить после обезглавливания.
diamond
Ну NT посложнее Колибри будет да и к тому же на C написана.
Я так понимаю что главным тормозом в таком варианте как я предложил будет работа IPC и переключение RING3->RING0->RING3 ну и запись в видеопамять через GS(или в ядре с такой же скоростью запись происходит?). На счет переключений, то у Колибри большая фора по сравнению с Линуксом и Хайку(если я правильно понимаю этот тест http://haiku-os.org/blog/engima/2007-03 ... d_syscalls и данные fastcall тестов на этом форуме(на моём разогнанном до 2088МHz он показывает 96нс)).
Mario79
Кстати k@sTIg@r, а в твоем варианте будет эта проблема решена?
Ну 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 4 guests