Кому нужен еще один клон операционки в стиле "Пингвиндовс"? Только не нам!
Начнем с того, что связи со спецификой языка Форт, вопрос о проектировании Форт-ОС следует рассматривать на двух взаимосвязанных, но совершенно различных по целям и задачам уровнях. Это:
Уровень I. Оболочка ОС (интерфейс)
Уровень II. Форт-ядро ("API")
Уровень I. "Что снаружи?":
Оболочка обеспечивает концептуальный пользовательский интерфейс.
Задачи:
п.1 Широкий диапазон стиля работы (от пользователя до программиста):
Допускаются все варианта исполнения слов:
1) исполнение готового библиотечного кода (тип шитого кода?)
2) компиляция "на лету" из форт-исходников
3) режим консольного ввода
п.2а Отсутствие файловой системы в среде ОС:
1) СЛОВО вместо файла (аналогия не прямая!!!)
2) СЛОВАРЬ вместо директории/каталога (аналогия не прямая!!!)
Т.е. ФС отсутствует логически,- работая на физическом уровне ядра ОС (и оставаясь реально доступной, напр., при загрузке HDD из-под под другой операционки)
При этом ядро ОС предоставляет Форт-API единый "логический файл" (можно сказать - процесс, обратный работе утилит DriveSpace и Stacker)
"Попадая внутрь" Форт-ОС, каждый файл получает свой заголовок словарной статьи.
Но только это не стандартная словарная статья форта, а аналогичная (прописываемая "поверх") структура, одного из четырех типов:
1а) SWAP-блоки, подготовленные для загрузки в ОЗУ
1б) специальные словари уже откомпилированных либ
2) обычные либы со словами-исходниками (СЛОВАРИ:\СЛОВА)
3) единая БД (специальный словарь) - база текстовых данных и стороннего "не форт" кода (jpg, mp3, xls...)
п.2б Особая логическая среда для работы в системе, основанная на идеологии языка Форт:
NB Чтобы не путаться, далее обозначим эти "бывшие" файлы, "заключенные" в оболочку словарной статьи 4-го типа, как "ФАЙЛИКИ" (мнемообраз: прозрачные пакетики-файлики для бумаг)
Причем словарная статья файлика содержит два дополнительных специальных поля:
1) поле типа файлика (аналог файлового расширения, но получаемый непосредственно из заголовка самого файла)
2) поле адреса слова-обработчика файлика
Кроме того все четыре типа словарных статей-оболочек имеют единые специальные поля:
1) поле даты_время создания/модернизации слова(словаря) + его уникального числового_идентификатора
Со стороны ФС ядра это поле является:
а) дата_время == имя каталога файла
б) числовой_идентификатор == некий технический индекс данного файла (напр. его начальный адрес в FAT)
Единое именование директорий по дате_времени призвано не только стандартизовать однозначное соответствие файлика (словаря, бинарного кода или текста-исходника) его реальному имени и месту в ФС, но и позволит организовать бесконечный откат к "предыдущей рабочей конфигурации" самой ОС.
2) поле стековой нотации слова: (стек до исполнения слова --> стек после исполнения слова). В идеале данное поле могло бы вычисляться и подставляться специальной программой-отладчиком (конечно, увы, только количество)
3) поле размера сегмента ОЗУ, выделяемого слову форт-ядром ОС (?)
4) поле связи с иконкой/цветом_отображения/дополнительными_эффектами (звук,флеш...)
5) поле "иерархии свертки", определяющее режим просмотра словаря (аналогичный применению фильтров у вьювера).
Имеется в виду разные уровни просмотра словарей: так, к примеру, если в либе основное (рабочее) слово RUN будет иметь значение данного поля True, а все остальные, вспомогательные,- False, то по желанию пользователя при просмотре словаря, содержащего это слово, все остальные слова либы могут не отображаться.
6) поле профиля пользователя,- задающее уровень доступа к словам (root, guest...), а также множественные профили работы в системе (аналог виртуальных рабочих столов).
Сочетание полей 5 и 6 дает также дополнительные возможности:
В отличии от обычных операционок (с "визуализацией ФС") пользователь Форт-ОС имеет свою персональную "область видимости" системы.
Точнее даже не одну, а несколько таких областей - несколько точек зрения скрывающих не нужную пользователю информацию.
(Примерно как если вместо фотографии местности со спутника использовать специализированные карты, составленные по этой фотографии)
п.3 "Либа-фундамент" для "эксплорера" - простая "базовая" библиотека вывода на экран, задающая стиль графического Drag & Drop IDE.
Собственно, заложенные в Форт-ОС вышеперечисленные принципы уже определяют функциональность рабочего стола (т.е. эксплорера), как:
1) системного проводника
2) диспетчера базы данных, основанной на словарях уровня оболочки, и поддерживающей множественные вложения (DataBase 3D !)
3) редактора простых скриптов, автоматизирующих работу в системе (nnCron!!!) - пользовательский уровень программирования
4) форт-редактора-IDE (!) - профессиональный уровень программирования
Причем ничто не запрещает проводнику раскрывать вложенность слов вплоть до слов из ядра форт-системы ("там, аж до самого низа - одни белые слоны!")
При этом, для определяющих циклы и ветвления "низкоуровневых" слов задается графическая реализация по типу "блок-схем" (отдельный класс символики в поле связи с иконкой)
Правда сам дизайн рабочего стола лучше "по-умолчанию" оставить лаконично-функциональным - предоставив возможность сторонним программистам-скинописателям добавлять всяческие красивости.
п.4 "ФОРТочки"
Увы, от привычных окон, уже никуда не денешься. Тем не менее хотелось бы перемен. Так, для окна, используемого программистом в режиме редактора, хотелось бы видеть панельки, показывающие текущее состояние стека (стеков). Кстати, а как насчет отдельного стека строк, как в либах Якимова?
Однако заранее определять внешний вид ФОРТочек, пожалуй, преждевременно - в процессе реализации оптимальное решение само проявится...
Здесь должен быть п.5 - но пока не ясно о чем...
Уровень II. "Что внутри?":
API (форт-ядро) встраивается поверх готового моно-ядра от операционной системы ...(?)
К нему же прикручиваются и драйвера, не вошедшие в моно-ядро.
При этом само форт-ядро - модульное, с предусмотренной возможностью выбора "на ходу" конфигурации подключаемых модулей.
В задачи данного "консольного" режима, доступного на этапе загрузки входит:
1) выбор диапазона функциональности ОС (от "облегченного" до "полнофункционального")
2) выбор профиля пользователя (напр. "детский", с запретом на редактирование исходников)
3) "бесконечный" откат назад по времени на требуемую дату
Задачи форт-ядра:
п.1 "Базовый набор задач" - драйверы/железо, память, многозадачка и т.д. (опустим подробности по данным вопросам поскольку они уже получили развитие в других ветках)
п.2 Механизм "подмены" файловой системы носителя (HDD, Flash, CD) концепцией словарей форт-системы.
п.3 Стандартизация механизмов работы из среды ОС с периферией, файловой системой, локальными сетями(Ethernet,USB) и Интернет - упрощенный универсальный интерфейс ввода-вывода через подключенные "службы"(программы обработки).
К примеру вариант некоего тройного "синхронизированного" (т.е. с единым идентификатором для отправляемой/принимаемой порции данных) буфера:
1) буфер адреса_параметров (источник/приемник_команда)
2) буфер данных
3) буфер управления_состояния (флаги??)
Типа:
(1) Принтер_печатай
(2) (йцукен)
(3) {return} (ОК)
(1) Почта_ВасьяПупкин@фортхос.ру
(2) (Я уже все распечатал. Вася)
(3) {return} (письмо отправлено)
п.4 Задачи совместимости - эмуляторы Вин/Линукса/Мака, языков программирования и пр.
Однако это уже, естественно, относится не к первым релизам ОС, и само ТЗ на их разработку пока не рассматриваетcя. Просто о вопросе совместимости следует помнить...
NB1 А дальше, похоже, пошла одна НФ ...
п.5 "Псевдонейросеть"
Как бы не повышалось быстродействие процессоров, скорость доступа и объемы винчестеров, но обработка больших массивов информации по-прежнему остается сложной задачей.
Нет, речь не конкретно о базах данных, а просто "о больших объемах чего-бы-то-ни-было" (например: толстеющий реестр Windows, поиск в папках с mp3-файлами...).
А что мешает, взяв за образец работу нескольких ОС под VMWare, изначально поставить задачу МНОГОЯДЕРНОЙ ОС? Т.е. поверх единого моно-ядра операционки загружать (одновременно!) несколько форт-ядер ОС и их оболочек ?
При этом искусственное ограничение объема доступных данных в каждой из параллельно работающих операционок можно компенсировать "межъядерным взаимодействием" между получившимися "кластерами" (наподобии нейросети)...
NB2 ...и чистое фэнтези:
п.6 "Виртуальный форт-процессор"
А все-таки: нельзя ли одно из ядер современных многоядерных процессоров программно "оптимизировать" и загрузить исключительно на работу со стеками Форт-ОС?
_________________ Банзай!
|