Цитата Сообщение от spectrum
Я предлагал вроде втроить их, но это не значит, что их надо использовать. По идее программе полная свобода. А выбор типа интерфейса и используемых программ производить самому на этапе сборки или подготовки к использованию.

И вообще, мне как-то ОС видиться больше в статическом исполнении (типа держишь в ОС, что тебе надо). Там я ещё писал, из-за переключения контекста надо делать выгрузку области программ. Поскольку держать уровни ОС там накладно (размеры) и невозможно (выгрузка области), то есть пока только идея расположить ОС в области ПЗУ или теневом ОЗУ (чтоб не занимать память в "области программ" вынести необходимые уровни ОС в другое место). Хотя можно конечно в виде программ в страницах использовать, но вот как эта программа будет обрабатывать данные из других страниц?

На критику "по делу" не обижаюсь - это неоценимаю помощь.
Если писать нормальную ОСЬ - однозначно надо пихать ее в ПЗУ (или теневое ОЗУ с 0). Для работы с другими страницами создается некий стандарт (хотябы по принципу, предложенному мной) и приведенную тут http://zx.pk.ru/showthread.php?t=507&page=7&pp=10 или то что привел Griv там же.
При этом все программы под ОСЬ, должны будут придерживаться этого стандарта.

Насчет статичнского-динамического исполнения. Тут надо сделать возможность указать при сборке что в статике компилировать, а что в виде подгружаемых модулей.
Скажем драйвер стандартного экрана - сразу к ядру присобачивается, драйвеа мыши, клавиатуры. А вот драйвер какого-нибудь экрана 320х200х256 - он может либо быть встроен в ядро, либо вообще исключен (если у юзера нет такого режима), либо откомпилирован в виде отдельного модуля, подгружаемого по мере надобности.

Еще по поводу RST-JUMP и системных вызовов. Однозначно в ОСЬ должна быть ОДНА точка входа. Причем для вызова ОС использовать надо call.

call #SYSTEM
db num_func
db param1
db param2
...

Тогда во-первых приятно писать, а во-вторых можно использовать call необходимо, чтобы можно было саму ОС запихать в любую часть памяти