Эксперимент

[SfS]

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

Согласен - простейший вариант реализации - повешать на NMI таймер, который будет слать прерывания скажем каждую миллисекунду. Пришло прерывание - опросил все устройства (через их драйвера) - есть ли что читать-писать, выполнил нужное. Разумеется это не оптимально. По идее каждое устройство должно уметь само послать прерывание, чтобы драйвер его обработал. Но зато вариант с таймером на NMI - самый простой.

2) прошивка ядра ОС вместо ПЗУ (как вариант- кеш), потому что основной памяти и так мало

Однозначно - кэш. Тогда ОС можно апгрейдить и изменять без перепрошивки ПЗУ. Огромный плюс.

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

Ядро и драйвера к нему должно поставляться либо в исходных текстах (для крутых кульхацкеров) либо просто под конкретную конфигурацию, которая в общем определяется набором встроенных- и подгружаемых драйверов. Скажем будет версия "SuperpuperOS v,Pentagon-1024" или версия "SuperpuperOS v,АТМ-7.10". Пользователь ее скачивает, устанавливает и работает - без гребли с компиляцией.

4) графический пользовательский интерфейс (не путать с Hacker User Interface ) возможен, но далеко не обязателен, а в силу ограниченных возможностей и нежелателен. отсюда вытекает невозможность привязки событий и проч. к оконной структуры (как в винде). имхо, следует обратить свой взор к *nix системам (что было сделано в предыдущих постах)

Привязка событий к окошкам - это извратик. Есть понятие "процесс". Есть понятие "сигнал". Несколько "процессов" могут обмениваться "сигналами" межу собой. А рисует процесс окошко или передает данные по модему - не принципиально.

5) если углубляться дальше, то нужно затронуть тему диспетчеризации процессов. с целью уточнения, проконсультировался с преподом у себя в универе. согласно выдвинутым требованиям, он предложил схему с двумя классами процессов- реального времени и разделения времени. процессы реального времени выполняются каждый квант диспетчеризации по цепочке. это могут быть процессы времени, обслуживания ау и проч. остальные процессы распределяются согласно своим приоритетам в оставшееся свободное время.

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

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

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

Распределение памяти мне видется примерно таким:
------------------------- #FFFF
Пользовательские процессы.
------------------------- #C000
Область разделяемых данных
------------------------- #8000
Системные таблицы+подгружаемые драйвера
------------------------- #4000
Ядро+встроенные драйвера.
------------------------- #0000

Такая схема будет работать минимум на 128к, если есть возможность повешать на NMI таймер (хотя можно и через INT - но повиснуть может). Главное, чтобы имелся порт для включения теневого ОЗУ с адреса #0000.