Board.KolibriOS.org

Позвольте мне опять высказать свои соображания

GUI на мой взгляд это одно из самых узких мест любой системы (причем я думаю мало кто будет возражать)

Поясню две, на мой взгляд основные причины:
Первая причина - если программист пишет простой графический интерфейс для своего приложения то не оптимально со стороны ядра держать огромное количество бесполезных функций
Вторая причина - если программист пишет сложный графический интерфейс то как не крути встроеннго в ядро GUI как правило не хватает и программист начинает втискивать свою задачу в узкие рамки существующего GUI или дополнять существующий GUI своими элементами, причем не редко алгоритм существующего GUI только мешает программисту.
И видимо по законам Мерфи, как правило программист некак не может попасть в золотую середину

Посему предлагаю вынести GUI за пределы ядра, оставив только основные функции работы с графикой, типа "создать графическое окно размерами такими и такими" и минимум графических функций по созданию примитивов, таких как нарисовать пиксел, линию, треугольник +низкоуровневыйOpenGL и т.п.
Тогда GUI можно оформить как отдельную библиотеку исходников или сделать GUI Server/Driver
А любители творить своими руками могут сами написать что им нужно не используя ни то ни другое.

P.S.
Если назвать выше изложенные причины граблями то Windows наступила на грабли описанные под номером 2. Она сначала начала неимоверно усложнила GUI на "уровне ядра", тем самым потеряв быстродействие системы, а затем начала обходить свои навароты за счет DirectX и т.п. тем самым более усложняя систему.

Ваше мнение ???

w-tools

Посему предлагаю вынести GUI за пределы ядра, оставив только основные функции работы с графикой, типа "создать графическое окно размерами такими и такими" и минимум графических функций по созданию примитивов, таких как нарисовать пиксел, линию, треугольник +низкоуровневыйOpenGL и т.п.

Вообще-то в данный момент уже так устроено. Большинство приложений реализуют элементы GUI сами, в ядре минимум, который не имеет смысла исключать.
Вопрос стоит лишь в написании полноценной стандартной библиотеки GUI подключаемой к приложению.

w-tools
Опоздал Уже предлагалось и немного обсуждалось. Есть небольшие наработки. Всё упирается в недоделанные события.

На сегодня уже реализованы разлиные GUI компоненты:
edit_box
check_box
radio_button
....
Все они используют минимум фунций ядра:
Нарисовать полосу, нарисововать линию, нарисовать точку. Все остальное они реализуют самостоятельно.
Для использования этих компонентов достаточно добавить в код своей программы вызовы этих компонентов.
Я не против, что бы сделать библиотеку с этитими функциями и предоставлять любой программе работать с этими компонентами.

Andrew_programmer тоже какие-то компоненты ваяет.

Товарисчи !!! Товарисчи !!!

Я просто "подбиваю" начать параллельно еще один но "микроядерный проект", а Колибри использовать как платформу для отладки и эксперементов не трогая ее сущности. Проблема в том что на данном этапе я еще не совсем въехал в тонкости защищенного режима i386, посему не могу организовать грамотный менеджер задач!!!
Если микроядерный проект 'пойдет' это будет ГУД !!!

Это хорошая идея, но программистов, хорошо знающих тонкости защищенного режима i386 не так много, к тому же у остальных не так много времени. Эта основная проблема. Каждый прилагает все усилия чтобы улучшить ту или иную часть кода программ, ядра и т.д. Если тебе нужно мое согласие на жизнь этого проекта, я за, но я совершенно не знаю что и как нужно делать + у меня не так много времени на это.
Скорее всего тебе придется начать этот проект самостоятельно, и если ты сам не разочаруешься, к тебе начнут присоединяться люди, которые будут улучшать и дописывать код.
Надеюсь на твое понимание, но сейчас я, как и многие помочь тебе не сможем.

w-tools
Колибри давно нуждется в хорошем планировщике задач. Сейчас все процессы организованы в простое кольцо, кажется такая схема называется round-robin. Вся работа планировщика сводится к тому чтобы не передавать управление потоку для которого нет событий (поток блокируется sys_waitforevent() )
Планировщики обсуждались в одном из форумов sysbin.com и там упоминался алгоритм адаптивных приоритетов разновидность которого есть в NT. В QNX реализовано три разных планировщика, которые может выбирать программа, ясно что не от хорошей жизни.
Если у тебя есть идеи на этот счёт то они могли бы очень пригодиться.

P.S.
Начинать новый микроядерный проект просто некому. Плотно ядром занимаются всего два человека и оба заняты. А сущность Колибри в том что она постоянно меняется и микроядерные идеи этой сущности совсем не противоречат. Многие идеи можно реализовать не вникая в защищённый режим, достаточно знания команд общего назначения.

Serge
Я планировал сделать планировщик задач следуещего типа (незнаю поможет ли он чем нибудь):

В памяти локализовано сидят приложения и драйвера причем они обсалютно равноправны. В ядре находится обработчик прерывания по таймеру который имеет свою таблицу векторов (адреса перехода) на соответствующие приложения. Любое приложение может зарегитрироваться в этой таблице (через функцию ядра конечно) обрекая себя на выполнения по таймеру в порядке очередности. Так же может поступить любой драйвер (драйвера и приложения равноправны).

В ядре также находиться регистратор аппаратных и программных прерываний. Причем регистратор только регистрирует эти прерывания. Кода в системе происходит какое либо аппаратное или программное прерывание (кроме прерывания от таймера) Регистратор смотрит в таблицу и передает управление по этой таблице. В таблице размещены вектора на зарегистрированные в ядре драйвера. Любое приложение или драйвер могут застолбить(зарегистрироваться) в этой таблице указывая переход на себя, или наоборот освободить этот вектор.

Таким образом получаем двойной механизм переключения задач
Первый механизм - переключение по таймеру
Второй механизм - переключение по прерываниям
Естественно по приоритету выполнения второй механизм будет выше, такак он будет прерывать выполнение задач по таймеру и кратковременно передавать управление на драйверы. Драйверы будут заполнять/очищать соответствующие буферы (описанные в предыдущих постах).

Таково поверхностное описание механизма переключения задач, конечно это планировалось под микроядро + куча всяких драйверов и приложений.

Из сказанного тобой не вижу разницы между приложениями и драйверами (разве что только по выполняемым функциям...).
Я думал, что планировщик занимается только планированием времени процессора.
И в общем эта модель напоминает что-то до боли знакомое...

w-tools
Первое в Колибри уже реализовано и второе тоже. Обработка проерываний от клавиатуры и AC97 идёт подобным образом. При желании можно сделать каскадный вызов обработчиков если это расшаренное PCI прерывание. Пока установливать обработчики можно только для кода в памяти ядра но в принципе можно сделать и для приложений. Сама схема заимствована из документации по QNX с неизбежной адаптацией.

ниосилил... про меос/коос (были такие времена...) были такие случаи... какой-то конкурс на котором один человек выдал себя за осеписателя, хотя там исходники были кооси/меоси, но без гуи... про вынесения вроде кто-то высказался, но... про простую функцию вывода точки или линии... ее же тоже можно ускорить! т.е. простые ф-ии будут ссылаться на "драйвер"... а так выносить можно до бесконечности...

Victor
Насчет драйверов и приложений ты абсолютно прав, они равнопрвны и между ними принципиалной разници нету. Разница в том, кто-то встает в очередь по таймеру, кто-то цепляется за аппаратные или программные прерывания. Хотя впринципе одно и тоже приложение может прицепиться обоими способами. Замечу что то приложение которое цепляется за программное прерывание может еще через него реализовать какой нибудь свой API. Но все это лиш мое личностное мнение и не более того

Serge
Сама идея выше описанного менеджера памяти/задач, планировщика (кому как удобно пусть так его иназывает) стара как MS-DOS (если не старше ). Просто на старых процессорах в то время не было там всяких шлюзов, симафоров, защиты памяти и т.п. А суть была та-же, тот-же таймер , те-же прерывания и полный творческий беспредел для программиста Так что QNX и прочие системы сдесь непричем

В Колибри нет четкого механизма (ставлю ударение на слово четкий механизм) который реализует самые необходимые функции:

1 - Выделить кусок памяти с двумя свойствами, по другому говоря создать буфер:
а - доступный для всех (+r или +rw)
б - приватный (доступный только для того кто запросил этот кусок)
2 - Обратная функция которая уничтожает выделенный кусок

3 - Пара сервисных функци которые меняют свойства выделенного куска памяти (для удобства программиста)

4 - Запустить выделенный кусок памяти на выполнение (короче создать задачу/поток/нить кому как удобно )
6 - Обратная функция, остановить выполнение куска памяти
7 - Сопутствующие сервисные функции

8 - Зарегистрировать приложение/драйвер в очереди на выполнение по таймеру(проще говоря поставить в очередь, установив вектор)
9 - Обратная функция

10 - Зарегестрировать приложение/драйвер в таблице на аппаратное прерывание (не таймер)
11 - Обратная функция
12 - Функция возврата из задачи (типа Return)

13 - Различные сервисные функции, (для удобства) типа вернуть свободное количество памяти, версю процессора, версию ядра, временно остановить/запустить/перескачить через приложение, и т.п.

Пока в OS не реализованы (и не отпалированы) описанные выше или подобные механизмы, программисты обречены 'чуть что' каждый раз переписывать драйвера и их взаимодействия. Про встроенный GUI на таком этапе вообще нечего говорить, иначе GUI начнет тормозить процесс доводки ядра. А восклицания об обратной совместимости тестовых приложений - это вообще глупо

Теперь о грустном:
Я так понял что реальных помощников для реализации микро ядра на i386 катастрофически нехватает И пока мне не удасться самому детально разобраться совсякими GDT, LDT, TSS и прочими премудростями i386, микроядерный проект обречен

Проект не обречен, он отложен, не вожможно начать что -либо не имея почвы под ногами (знаний в этой области). Если у тебя возникнут вопросы, тебе ответят на этом форуме, но в основном это свободное плавание каждого, и нас всех объединяет одна идея. Начни работу, и ты сам увидишь как начнет меняться все. Помоги себе сам! Только не подумай, что все от тебя отвернулись, я не знаю как тебе помочь!

А если такая система.
Вот у нас есть элемент кнопка, который обрабатывается ядром. А если нам выкинуть его, а точнее расширить.
Вместо элемента кнопка будет элемент компонент. Вместо одного события сделать 3: mouse_click, mouse over, mouse_out.....или клик расширить на up и down. То есть минимум событий которые обрабатываются ядром.
А все остальное (рисование компонента, расширение событий такие как фокус, потеря фокуса, нажатие клавиши и т.п) берет на себя приложение.
То есть получаем ту же кнопку но с расширеными возможностями ( а ведь тот же чекбокс, радиопедаль и подобные это те же кнопки) мы можем рисовать свое и получать дополнительные события.

А приложение само реализует переключение фокусов, рисование компонентов. Одни компоненты смогут получать фокус по клику, другие при наведении мыши...ну вообщем как фантазия программиста захочет.

Не пинать, а обьяснить почему так лучше не делать. Я конечно еще не разобрался до конца в ядре, но помоему эти 3/4 события висящих на ядре не сделают ничего страшного.