Board.KolibriOS.org

Есть какие-нибудь схемы, которые показывают организацию, план, структуру связей разных компонентов и функций в КолибриОС? Например, компоненты как графическая система, ядро, мыша. А то я уже долго копаюсь в исходниках и ни как не пойму, как всё связанно, что использует что, что вызывает что. Как будто всё слито в один флакон и трудно разобраться что к чему. Но я, правда, не специалист в ассемблере, но немного разбираюсь. Схемы или какой-нибудь интерфейс с функциями компонент помогли бы. Я думаю когда планировались компоненты, ядро и их связи, наверно делались какие-то схемки? Например, мне интересны окна и графическая система (но другое тоже интересно), т.е. окна, рисование в них, мыша, кнопки, как это всё взаимосвязано.

http://wiki.kolibrios.org/wiki/Kernel/ru

никаких схем нет.

никакого планирования отродясь не было (щас меня Mario подловит на каламбуре ).

конкретные детали см. в исходниках - там все достаточно понятно, нужно только желание и терпение.

Планирование было, но осталось только в голове авторов кода, ибо мама-анархия.
А вообще есть тема Ядро - концепция работы, и есть Wiki, все остальное только в исходниках.

Благодарю за ссылки. Но, если не было планирования или если планирования остались только в головах авторов кода, то как тогда происходит разработка КолибриОС? Если я правильно понимаю, то над КолибриОС одновременно работают больше чем один человек. Для совместной работы нужно как-то договариваться, как именно что-то будет сделано, иначе если каждый просто будет дописывать в код то, что лично у него в голове, то получатся нестыковки. Такая договорённость, я думаю, это и есть некий общий план, общая линия разработки, и эта договорённость должна где-то быть зафиксировано. Я просто думал может быть есть схема блоков разных компонент, ну что-то типа «интерфейс», где не нужно знать как компонент работает внутри, т.е. не надо смотреть весь код в ассемблере и искать компоненты, а можно было бы компоненты просто использовать зная только их входные и выходные данные.
Например, если я хочу рисовать что-то в окне, я не хочу думать, как там 16бит, 24бит цвета внутри перерабатываются или что-то такое, просто передаю самые лёгкие 32бит цвета (с альфа), рисую линии, кружки, текст и не хочу думать, как там сделать, чтобы за рамки окна не выходило или искать где там находится начало координат окна. Ну я мог бы попробовать сам переделать код так как я считаю нужным, но тут возвращаемся опять к общему планированию. Напишу, а потом новая версия КолибриОС выйдет (с переделанными компонентами) и мне опять всё переписывать. Я думаю надо сосредоточится на планировании, чтобы разработка КолибриОС стала легче и не умерла. Пойду пока почитаю ссылки.

броман, нет никого плана развития. Самодеятельность же. Just for fun.

_________________
Нуб обыкновенный

Вот так и все остальные...

Ну тут можно понимать по разному. Например, так же можно понять, что с этим ответом ты показал, что ты тоже входишь в эти "все остальные". Не принимай это оскорбительно. Я имел в виду, что для пользователя не обязательно знать, как работает компонент, который он использует, внутри. Для разработчиков компонента это конечно важно. Вот нашел интерфейс между программами и ядром: http://wiki.kolibrios.org/wiki/Category:SysCalls. Я думаю, так как новичкам трудно разобраться в самом ядре, им интересно сосредоточится на написании программ. И тут уже каждый хочет иметь определённое поведение системы. Например, я хочу, чтобы окно само отрезало всё, что выходит за рамки окна при рисовании, и чтобы при рисовании координата {0, 0} указывало на само окно, а не на экран. Или хочу, например, подключить две USB-мыши или две USB-клавиатуры, и при получении события «мыши» или «клавиатуры» от ядра, чтобы получить индекс 0 или 1, какая мыша вызвала событие. И вот у каждого есть свой список таких «целей», который он хотел бы видеть реализованным, чтобы потом писать программы. Но опять же проблема с планированием. Я перепишу ядро так, как мне хочется, а другому это не подойдет. Поэтому, мне кажется, что писать пока программы не стоит, потому что функции ядра нужно сделать такими, чтобы они были самыми подходящими для программ, а для этого нужно работать над ядром, что для новичков без плана трудно. Я думаю, неплохо было бы, если каждый для определённого раздела (например, мыша, система окон) написал его список целей, потом из этого общего списка можно выявить, куда нужно двигаться с разработкой. Поэтому, да, самодеятельность же, just for fun, но люди пишут ядро, чтобы другие его использовали, только для себя никакого fun нет. Теперь ещё один вопрос. Я тут смотрю исходники версии 0.7.7.0, но эта версия, как я понимаю, лежит уже давно для скачивания. Какие-нибудь серьёзные изменения с того времени произошли?

1) К дистрибутиву приложена справка с системными функциями, в самом дистрибутиве есть Справка, включающая то же самое. Кроме того, есть hello world'ы для большинства компиляторов, с помощью которых можно создавать программы для Колибри. Есть несколько примеров программ на ассемблере - я начинал с них.

2) Именно так всё и происходит. Приложение рисует только в пределах своего окна, если не обращаться напрямую к видеопамяти

3) А это пока что из области фантастики. Не у всех, увы, даже USB-мышки работают. Возможно, в будущем этим будет заниматься драйвер, но ядро тут явно не при чем.

4) Добро пожаловать в тему "Хотелки".

5) Проект свободный, никто не запрещает форки бранчи. На сегодняшний день, насколько я знаю, бранчей три (кроме основного дистрибутива): Kolibri PE, Kolibri-A и Kolibri Network.

6) На wiki есть ссылка на самые свежие ночные сборки системы (последняя - от 5 марта). Исходники доступны на SVN.

upd. Ах да. Возможно, заинтересует информация о библиотеках и драйверах?

броман
Я лишь констатировал факт, так что с чего бы мне сильно отличаться от 99,9% остальных людей.
На самом деле многое, о чем ты написал есть - нужно просто почитать все доступные доки и не торопиться.

Sorcerer
Есть мнение что Kolibri Network станет транком со временем, так что это не форк.

Да, пожалуйста. Особенно интересно как драйвер связан с прикладными программами.
Согласен, хотя всё читать тоже не всегда ведёт к успеху, типа второй закон диалектики, количество против качества и всякое такое . Я тут читаю системные функции типа http://wiki.kolibrios.org/wiki/SysFn01/ru и думаю, что нужно бы добавить в каждую такую страницу в wiki название файла, т.е. где эта функция сидит в исходниках ядра. Очень помогло бы.

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

Возьмёшься ?

Угу, а кто потом будет обновлять Wiki, после очередного переписывания? Программистам лень даже комментарий в коде писать, а уж доки раскиданные править тем более

Да, я тут смотрю функции и ищу их в исходниках. Что найду, выложу потом. А можно где-то скачать новейшие исходники без SVN? Так я мог бы "искать текст или фразу в документах".

броман
http://redmine.kolibrios.org/projects/k ... epository/

хотя удобнее скачать срез репозитория и уже потом ковыряться в своей рабочей копии.

Вроде нашел, где находятся системные функции. Теперь получил некую первую вспомогательную «схему» в текстовом виде для меня. Если я что-то не правильно понял, то поправляйте меня. Таблица с названиями находится в core/syscall.inc, отсюда всё вызывается. Составленный документ прикреплен ниже. Я ещё приписал, в какой строчке функция начинается. Понятно, что строчки будут меняться, поэтому это я просто для себя написал. Первый вопрос, который возник у меня, это почему одни функции начинаются с «sys», другие с «syscall», а третьи ещё по-другому. Там, где разница, там информация, там возникают вопросы. Есть какой-то продуманный, для новичков не ясный, смысл за этим? Другой вопрос тоже, почему некоторые функции вызываются через cross_order?