Здесь находится список служб, которые, вероятно, должны быть в поставке системы. NB! Это не значит, что все они гарантированно присутствуют в каждой инсталляции ОС. Например, встроенный контроллер станка не очень нуждается в оконном интерфейсе и графическом шелле.

Здесь вообще никакой конкретики, это - наименее для меня интересная и наиболее тривиальная часть дизайна, посему ей внимание вообще не уделено. Разработка может в существенной степени делегироваться профессионалам в соответствующей области без потери целостности проекта.

Графический интерфейс

Очевидно. А, нет, один комментарий. Ноль координат - слева внизу, а не там, где начало адресного пространства видеоадаптера. Плевал я на видеоадаптер и его адреса вместе с ним.

Текстовый (coommand-line) интерфейс

Эту штуку реализовать куда сложнее, чем графический, вообще-то. :-)

Графический shell

Десктоп, фолдеры для объектов, интерфейс к "фабрикам" объектов (как создать word-документ или midi-композицию), полезняшки...

Графический шелл - это та компонента, которую не надо ставить, чтобы превратить настольную систему в подстольную или встроенную. :-)

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

Наиболее очевидный ход - создать в системе регистр, в который все "пользовательские" классы будут вписываться при инсталляции. Другой вариант - ввести тип system.userlevel, и наследовать "пользовательские" классы от него. Это более правильно, но косвенным образом требует введения множественного наследования или java-образного его суррогата. Впрочем, есть у меня уверенность, что от множественного не уйти, при всей его проблемности. Так что в баню регистр.

Многопользовательская подсистема

В традиционных ОС "выносная" реализация security вызывает смех. В Фантоме понятия "выносной" нету, тут всё "выносное", и модуль security, реализованный самостоятельно ничем не хуже "встроенного".

В функции входит поддержание списка пользователей, login, взаимодействие со средой на предмет поддержки глобальной карты пользователей (типа домена NT или nis+). Эта подсистема, конечно, довольно тесно завязана на концепцию ОС в целом, но завязка, по сути, ограничивается двумя моментами.

1. Подсистема должна уметь ответить, кому принадлежить данный объект или данная нить. Реализуется, по всей видимости, тривиально. Путём помещения в дескрипторы объектов и нитей указателей на объект, представляющий владельца.

2. Поскольку ОС в целом не позволяет никому добраться до сущности, не располагая указателем на неё, от подсистемы security требуется лишь выдавать указатели на запрошенные объекты тем, кто имеет на это право. По всей видимости, путём фильтрации доступа к службе имён - единственному способу добраться как до фабрик объектов, так и до уже существующих объектов "общесистемного значения".

Иллюстрация. В NT я "говорю" файлу, кто может до него добраться, а кто - нет. В фантоме - никто не может добраться до моего объекта. Чтобы кто-то смог, я должен дать ему указатель на этот объект. Подсистема security должна предоставлять мне для этого способ. Например, нечто типа почтового ящика пользователя, в который я могу кинуть ссылку на объект. Или на каталог объектов. Ящик может быть и глобально доступным. А могут быть и другие варианты - с паролем, с прикладыванием пальца, и т.п.

Между прочим, предвижу вопрос - а как забрать доступ. Только одним способом. Скопировать объект и удалить оригинал. При этом он останется "висеть" на указателе извне, точно так же, как открытый файл в unix существует физически, даже если удалён из каталога. Но изменения в копии вас уже не коснутся. То есть доступа на запись в свой объект вы окружающих лишили. Доступа же на чтение лишить нельзя в принципе, если вы его дали хоть на сколько-то. Ведь все, кто имел доступ могли сделать копию.

Есть ещё одна проблема. Например, вы создали некий список и раздали доступ к нему на запись многим людям. Теперь вы хотите лишить доступа лишь одного из них. Это сделать нельзя никак. Увы. Если бы вы были предусмотрительны, и дали каждому из людей опосредованный прокси-объектом доступ, то тогда отнять его было бы возможно. Это - один из минусов системы security Фантома.

Ещё момент. Поскольку система никогда не завершает работу, а лишь засыпает, login в ней лишь "подключает" пользователя к его среде - к десктопу, фактически.

Однопользовательская подсистема

"Затычка", вставляемая вместо security, если последняя не нужна.

Сеть, транспортный механизм

Требуется какой-то разумный набор спецификаций классов для работы с сетью вообще и, как минимум, одна инкарнация для поддержки протокола TCP/IP как такового. Вероятно, верхний уровень - потоки a-la TCP.

Сеть, объектный уровень.

(Правильный ответ на вопрос "как это сделать" - "не знаю". :-) Ниже даны некоторые соображения, накиданные за пять минут.)

Это, напомним, не только сеть, это и механизм для работы со сменными носителями. См. раздел про память.

Нужен механизм дистанционного доступа к объектам из другого адресного пространства. То есть, собственно, Remote Method Call. Отмечу, что поскольку public у нас только методы, но не поля, то задача несколько упрощается.

Imp. note: При разрыве связи с удаленным объектом все вызовы к нему вызывают exception "разрыв связи".

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

То есть, видимо, правильный способ - это оставлять ссылки тянущимися через сеть. Что, впрочем, не мешает открыть какой-нибудь инспектор внешних связей, посмотреть там, какие внешние объекты наша система использует и заказать себе копии тех, которые представляются нужными. Отметим, что автоматизировать этот фокус в общем случае нельзя.