Боюсь с начальным опытом MS Visio и схемами плана USER->KEYBOARD->MONITOR никуда не уедешь....Сообщение от spectrum
Мы с ним раньше уже общались, все вопросы к нему....
PS: Кидаю ещё "картинки" для размышлений....
Хорошая ось - это очень непросто... Тот же IS-DOS огого написать...
скинуться по 100$ и заказать у майкрософт на заказ
или у Genesi или их там омижниковых морфосников...
Я уже писал, почему С. Потому что пока ты на асме отладишь все эти RST дополнительные - у тебя столько времени уйдет - что все надоест. А "нормальная работа с памятью и файловой системой" вообщето и является одними из основных функций почти любой ОС. Что значит "добавить несколько RST" ? Одного достаточно. Но дело не в RST. Дело в том, что ОС обеспечиват прежде всего работу с разнородным оборудованием, устраняя проблемы несовместимости. Грубо говоря - программа пользователя обратилась к ОС с запросом - "дай мне 2к памяти", ОС должна вернуть адрес выделенного блока в какойто форме или код ошибки, если памяти нет. А уж на какие там порты подключено переключение страниц памяти и в какие окна и как все это делается - это сугубо интимные проблемы дрпайвера памяти, установленного на данной ОС в данной машине. И они никак не должны касаться программы пользователя.
Или работа с файлами - на кой программе юзера знать - на какой физической файловой системе лежит файл с данными игрушки ? Пусть эти проблемы мучают ОС. А программа пользователя должна только уметь сказать ос "myfileid=open("/games/mysupergame.dat",O_RDONLY):read(myfileid, &buffer, size);close(myfileid); - все !!! Остальное - интимные проблемы драйверов файловой системы и драйверов устройств !
Все нормальные компы так работают....
чем вам IS-DOS не угодил? его б лучше дорулить...
Товарищ экспериментатор ! Может я несколько самонадеян, НО !!!! ОС - это не ГРАФ ИНТЕРФЕЙС. Это НЕ КНОПОЧКИ !!!! ЧТО ЗА ВИНДОВОЗНО-МИКРОСОФТНЫЙ ПОДХОД ?!Привет всем снова!
Продолжаем эксперимент. Вот привожу детальную структуру окна привидённого ранее в "Структура оконного интерфейса.jpg". В будущем выложу на обозрение текущую версию документа эксперементального проекта в котором ведётся сама разработка.
Давайте присоединяйтесь экспериментаторы !!!
ОС - это прежде всего работа с оборудованием.
Подумай вот над чем:
- Как будет реализована работа с памятью. Алгоритм выделения, освоюождения памяти. То есть менеджер памяти.
- Как будет выглядеть единый интерфейс драйверов устройств.
- Как будут отображаться устройства на виртуальную файловую систему.
- Как будут подключаться файловые системы устройств к виртуальной файловой системе.
- Как буде реализована файловая система и взаимодействие с ней.
- Как будет работать менеджер задач. (Тип многозадачности, распределение времени)
И только потом, когда ты нарисуешь и обкатаешь эти схемы - сможешь подумать "кнопочках, рюшечках и прочей байде". Событийный графинтерфейс написать - несложно.
Всем. По сути это не ОС, а только ДОС. На кой нам однозадачная ОС ? Это неправильно.
Странно, что ты свалил всё в кучу - ФС и задачи с памятью.
Надо сильно думать вот над чем
1. механизмы многозадачности.
2. память.
3. 'событийные' механизмы: сигналы, мессаги, семафоры.
Все драйвера далее могут взаимодействовать с задачами на основе этих механизмов. ФС/etc же вообще тут не причём - её можно добавить как отдельную либу, у которой уже свои механизмы работы (основывающиеся на событийных и тасковых механизмах) с драйверами ФСов и драйверами накопителей.
По крайней мере так ось сделана на амиге - всем осописателям кстати рекомендуется ознакомиться. =)
Ну да, всё это сделать-то несложно, но применительно к спеку возникают проблемы нехватки памяти, быстродействия, етц. И возможно не так уж неправы были исдосники, что сделали монолитную систему-командер.И только потом, когда ты нарисуешь и обкатаешь эти схемы - сможешь подумать "кнопочках, рюшечках и прочей байде". Событийный графинтерфейс написать - несложно.
В Unix-системах драйвера взаимодействуют с программой пользователя как файлы устройств. В этом отношении мне Юниксы нравятся своей простотой и логичностью. Возможно мы имеем ввиду разные файловые системы ? Есть файловые системы хранения файлов на физ. уровне (FAT, Ext2 и тд), а я говорил о виртуальной файловой системе, которая объединяет все файловые системы в одно дерево. В этом дереве - и фйлы данных и файлы устройств и файлы-ссылки и т.д. и т.п.
Не спорю. А так же всем осописателям рекомендуется изучить книги "Операционные системы" Т.Б.Большаков - Д.В.Иртегов и "Сетевые операционные системы" Н. А. Олифер, В. Г. Олифер... В общем и обзорно и с реальными примерами рассмотрены типы ОС, типы менеджеров памяти, файловых систем, методов взаимодействия с драйверами и т.п.
Они просто копировали Нортон и идеологию ДОС (заметь - не ОС, а ДОС!), распостраненных на тот момент. Привязывать ядро ОС к пользовательскому интерфейсу - глупость несусветная ! Причем выигрыша в быстродействии никакого не дает. Какая разница - загружена у тебя программа, выводящая на экран окошки как внешняя или вкомпилена в ядро ОС ? Для процессора - никакой. Он и то и это будет выполнять с примерно равной скоростью. А вот с памятью ситуевина как раз прямо обратная. Вкомпиленный в ядро интерфейс пользователя - это ПОПА !!! В том смысле - что он жрет память не зависимо от того нужен он реально пользователю или нет. А если он подгружаемый - то все более приятно. Есть память - можно подгружать оконно-мышинный супероконный. Нет памяти - подгрузил маленкий интерпретатор комстроки - или нечто Нортон-подобное...
принял бы участие в написании unix подобной оси/ядра для спека. опыт в языке Си - 9 лет. только давайте действительно сначала определимся с многозадачностью и системой меж процессовых комуникаций. остальное, в принципе, уже пройденный путь. естественно файл система будет модульной. но нам, для начала, микро ядро надо продумать.
может сделать отдельную ветку? с идеей автора данной темы это довольно большая разница. (я вообще против графического интерфейса в составе оси как таковой. если программе понадобится графика, пускай сама делает. в крайнем случае напишем либу какую-нибудь).
целью считаю размещение самого ядра и минимума драйверов в 16кб странице (вместо пзу).
PalmOS, например, сразу изначально базировалась на GUI, хотя на самом первом Палме памяти было как у современного Спектрума, процессор стоял слабенький (сопоставимый по мегагерцам со Спектрумовским) и однобитный экран 160х160. Я помнится даже в REAL.SPECCY кидал скриншоты с палмовских электронных таблиц в формате SCR 6912... Так что может быть не стоит вот так сразу откидывать идею с GUI? Хотя, вероятно, именно для Спектрума GUI вовсе и не нужен...
Примерно об этом я и писал вот здесь: http://zx.pk.ru/showthread.php?t=168
С уважением, Станислав.
Это как раз идеология унихов - всякие там / и все девайсы как файлы etc. В результате имеем монструозное ядро. Да и к тому же унихам ММУ нужен (ну есть конечно uClinux, но думаешь он спасёт на Z80?).
Ну да - глупость, когда например в винде таски обменивааться месагами могут только через окошки =) Я говорю, что может быть это и глупость, но таки позволила хоть куда-то уехать - мне навскидку трудно прикинуть, с какой скоростью будет работать честная многозадачная ос на спеке и сколько будет жрать ОЗУ, етц.Они просто копировали Нортон и идеологию ДОС (заметь - не ОС, а ДОС!), распостраненных на тот момент. Привязывать ядро ОС к пользовательскому интерфейсу - глупость несусветная ! Причем выигрыша в быстродействии никакого не дает.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием