Mr.McD. писал(а):
Yoda, вот система Станислава - отличный пример восходящего проектирования. Ещё не решён вопрос ни динамической загрузки программ, ни разделения и планирования ресурсов, ни механизмов защиты и IPC.. Но зато есть отлаженный механизм загрузки с флешки монолитного образа системы, и отличная векторная графика. Система - открытка. Времени, надо думать, немало ушло на написание.. Как в Менуете: для того, чтобы поменять иконку на рабочем столе - нужно ядро перекомпилить. Станислав, нужно бы с общим функционалом определиться сначала, а потом можно и иконки для устройств рисовать.
Перво-наперво, определись с тем, как будут подгружаться новые программы. Т.е. твоя ось сперва должна научиться шарить ФС. Потом, каждой программе нужно выделить свой отрезок памяти. Потом система должна зарегистрировать новую программу в очереди на исполнение. Раздели все программы по функционалу: одна ФС шарит, другая памятью заведует, третья иконки рисует и т.д. А ядро пусть сообщения/события между ними крутит. Вот тебе практически микроядерная ОС получилась. По-первой можно и без страниц и подкачки обойтись: пусть все программы в одной линейной области памяти находятся. Но если захочешь динамически программы запускать, их код должен быть позиционно-независимым. Опять же, придётся делать модуль, управляющий кучей памяти. Определись с тем, что должен содержать дескриптор загруженной программы, например: Имя программы, Идентификатор, Занимаемая область памяти, Состояние и т.п. Дальше, если система у тебя кооперативная, а приоритетов программ не ожидается, то для всех программ можно сделать одну общую очередь сообщений. Т.е. все запросы будут обрабатываться в порядке поступления. Выглядит это так: Сообщение имеет идентификатор отправителя, идентификатор получателя и указатель на область памяти в которой лежат данные (ключ от квартиры, где деньги лежат). Когда программа работает, она кидает в конец общей очереди сообщения. Потом передаёт управление диспетчеру (ядру). Диспетчер берёт из общей очереди первое сообщение, читает идентификатор получателя, ищет получателя в таблице процессов, и передаёт ему управление. А сообщение можно оставлять в стеке. Т.к. у тебя кооперативка, то все процессы могут использовать один общий стек.
Зачем это вы мне систему усложняете? Всё, что вы мне предлагаете сделать у меня уже есть. Те же иконки или из проводника можно запустить любую прогу с таблицей релокации для пересчёта адресов, чтобы код мог находиться в любом месте оперативки и переноситься от туда опять в другое место с перепросчётом очередным адресов. Стек событий уже есть, т.к. проги могут поставить свои обработчики на постоянную обработку в массив, но самое главное это обработка событий простым нажатием мыши на объект
без перебора объектов, и очередь там не нужна. Для каждого диска свой заголовок файловой системы и файл имеет ссылку на неё, а там есть номер этого диска для функции чтения файлов и их загрузки, которая указана в том же файле. Так же в нём данные о его первом кластере. Всё, что делает например винда моя система будет прекрасно делать, даже с плюсом.
Как например вы решите проблему, для своей оси, переключения окошек, посылания им сообщений о нажатии мыши на них, после реализации файловой системы и памяти и драйверов(у вас получится командная строка в текстовом режиме)? А вы будете переписывать всё это заново и от этой системы вашей прежнего кода останется мало, или получится приспособничество с большим числом глюков. А я могу сейчас дописать всё что угодно к системе.
Если проектируеш систему не до конца, то добавление к ней чегото будет мучительным, а иногда и невозможным. Поэтому я сразу задумался о конечном этоге, как шрифты рисоваться будут с окошками и иконками.
Вход
Регистрация
FAQ
Поиск
