Joint #01 31 января 2006

Концепции

Articles - Операционная система на Спектруме. Что это?

Операционная система на Спектруме. Что это?
by Vitamin


Здравствуйте, уважаемые читатели!

В  этой  статье  под таким интригующем названием будет затронута
тема  операционных  систем  вообще  и для Спектрума в частности.
Если  вы  ожидаете очередной рекламы новой оболочки или хваления
несуществующего  кода  в  стиле  мелкософт,  то можете дальше не
читать.  По возможности, буду стараться избежать того и другого.
Здесь  будут  рассмотрены  сугубо  технические  стороны  данного
вопроса,  посвященные  проектированию, разработке и, собственно,
работе  операционных  систем.  Я  может,  буду  даже  советовать
почитать книги по данной теме, в которых о Спектруме не будет ни
слова.  Написать  эту  статью  меня попросили с разницей в месяц
редакция газеты "Абзац" и группа "Brainwave".

Итак,  перехожу  к  сути  дела.  Курс "Операционные системы" был
прослушан  мной в университете в стандартном объеме и предо мной
стала  такая  задача - а нельзя ли это знания применить к нашему
Спектруму?  Засев  за книги, одной из которых была Н. А. Олифер,
В.  Г.  Олифер  "Сетевые  операционные системы", я получил массу
дополнительных  сведений  из  чисто  теоретической  области. При
последующем   чтении   книг   по  Юниксу  и  Виндоуз  я  получил
возможность  сравнить  эти системы и выбрать оптимальное решение
тех  или иных задач. Далее я буду рассказывать свои мысли насчет
внутренности  операционной  системы.  Не  нужно  принимать их за
догму  или  шаблон.  Скорее,  это  просто рекомендации, часть из
которых  проверена  на  практике. Некоторая часть моих изысканий
была  опубликована  в газете Zx-Time. Так что, я в чем-то и буду
повторяться.   Итак,  для  начала  определим  основные  функции,
которые будут возложены на ядро системы:

1)  Реализация  многозадачности.  Сюда  входят  функции работы с
процессами  и  распределения  процессорного  времени. Два режима
многозадачности - невытесняющая и вытесняющая, а также множество
алгоритмов  диспетчеризации  для  последней (для первой, кстати,
тоже)  открывают  небывалый  простор  для  реализации.  Вопрос о
необходимости многозадачности вообще, я считаю, стоять не должен
-  слишком  большие  выгоды  открываются при ее использовании, в
противовес сложности реализации. Желающих поспорить - прошу, мой
адрес   указан  в  конце  статьи.  Единственное  различие  между
вытесняющей   и   не   вытесняющей  многозадачностью  состоит  в
возможности системы вызывать планировщик не по желанию процесса.
При  вытесняющей  многозадачности простой цикл никогда не сможет
подвесить  систему,  как  это  может  запросто  случиться при не
вытесняющей  или  без  многозадачности  вообще. В худшем случае,
значительно снизится быстродействие. Но после снятия "зависшего"
процесса  работа  продолжится  в  обычном  режиме.  В отличие от
процессоров   класса   x86,  начиная  с  386,  z80  не  обладает
аппаратными  средствами  защиты  памяти. Другими словами, никоим
образом нельзя проконтролировать чтение или запись в ту или иную
область  памяти.  Выполнение  "запрещенного"  кода  в  некоторых
случаях  может быть отловлено. Единственным способом защиты ядра
от  вторжения  вредоносных программ является прошивка его в ПЗУ.
Но  это шаг оправдан только в случае отлаженного ядра, наилучшим
образом соответствующего возможностям машины.

2) Работа с внешними устройствами. Этими устройствами может быть
все,  что  угодно - от клавиатуры и мыши, до DMA и GeneralSound.
Необходимо  только  их  разделить  по  категориям и осуществлять
контроль   согласно  их  целевому  назначению.  Например,  через
драйвера   дисковых  устройств  может  осуществляться  доступ  к
носителям   самого  различного  типа,  начиная  от  дисковода  и
рам-диска   и  заканчивая  жестким  диском  и  CD-приводом.  Для
обеспечения  легкости  расширения  аппаратной  поддержки системы
необходимо  предусмотреть  диспетчер  устройств,  который  будет
предоставлять    программам   единый   интерфейс   обращения   к
устройствам,  зависящий от категории устройства, но не зависящий
от его типа.

3)  Оконная  оболочка.  Графический  пользовательский интерфейс,
штука  приятная,  но только не для системы. Для нее самый лучший
интерфейс  - командная строка. Минимум ресурсов, ничего лишнего,
единый интерфейс работы всех программ. Но попробуй запомнить все
команды системы! Если вам это удалось, можете себя называть про-
фессионалом   :)  Поэтому  и  придумывают  люди  так  называемые
"интуитивно  понятные  интерфейсы",  суть  которых - по минимуму
нагружать  мозги  пользователя  для  выполнения различных задач,
пусть и в ущерб производительности и скорости работы.

Но  и  тут  не  стоит  перегибать  палку.  В качестве авторитета
привожу  цитату  из  книги  А.Голуба "Веревка достаточной длины,
чтобы...  выстрелить себе в ногу" (Holub.A. Enough Rope To Shoot
At  Your  Leg"). Это книга по хитростям программирования на С++,
но, я думаю, вы согласитесь с моим решением включить эту цитату.
"...Интерфейс   пользователя   не   должен   быть   похожим   на
компьютерную программу (принцип прозрачности). Я однажды слышал,
как  кто-то  сказал,  что лучшим пользовательским интерфейсом из
когда-либо   разработанных  является  карандаш.  Его  назначение
тотчас  же  понятно, для него не нужно руководство пользователя,
он  готовится  к работе без особой суеты. Однако наиболее важным
свойством    является   прозрачность.   Когда   вы   пользуетесь
карандашом,  то  думаете  о  том,  что  вы  пишите, а не о самом
карандаше. Подобно карандашу, лучшими компьютерными интерфейсами
являются  те, которые скрывают сам факт того, что вы обращаетесь
к   компьютеру:   замечательный  пример  интерфейса  с  системой
зажигания   вашего   автомобиля.   Вы  поворачиваете  зажигание,
включаете  скорость  и жмете на газ, как если бы все эти объекты
интерфейса (ключ, рычаг скоростей, педаль) были прицеплены прямо
на двигатель. Тем не менее, это не так: они теперь обычно просто
устройства  ввода  в  компьютер, который управляет двигателем. К
сожалению,   подобный   уровень   ясности  часто  отсутствует  в
пользовательских  интерфейсах. Представьте графический интерфейс
пользователя  Windows  на  автомобиле.  Вы  трогаетесь, выбрав в
главном меню пункт "Движение автомобиля". Щелчок по нему откроет
меню  "Переключение  скорости",  которое  предложит вам выбор из
опций  "Вперед",  "Назад"  и "Нейтральная". Щелкните по одной из
них,  чтобы  передвинуть флажок на нужное вам направление. Затем
вернитесь  в  меню  "Движение  автомобиля"  и  выберите  команду
"Поехали".  Это  вызовет  появление диалогового окна "Скорость",
где вы должны использовать ползунок для ввода желаемой скорости.
Однако  установить скорость правильно трудно вследствие высокого
разрешения  ползунка (пол-миллиметра движения мыши соответствует
примерно  1 км/ч), поэтому вы скорее установите 59,7 км/ч вместо
60. Затем вы нажимаете кнопку "Поехали" в диалоговом окне, вслед
за  чем появляется сообщение "Стояночный тормоз не убран нажмите
F1  для  справки"  (динамик  издает  громкий  звук).  Вы покорно
щелкаете  по  кнопке  "ОК",  чтобы  убрать окно сообщений, затем
снова  пытаетесь открыть главное меню, но машина просто посылает
вам  звуковой  сигнал.  Наконец,  поняв,  что  дело  в  том, что
диалоговое  окно  "Скорость"  еще  отображается,  вы щелкаете по
кнопке   "Отмена",   чтобы   убрать   его.  Вы  открываете  меню
"Стояночный  тормоз" и убираете флажок "Включен". Затем вы снова
открываете  окно  "Поехали". И вновь получаете сообщение громкий
звук)  о  том,  что вы должны сначала выбрать направление в меню
"Переключение  скорости".  В  этот  момент  вы решаете, что вам,
может быть, лучше пройтись на работу пешком..."

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

4)   Файловая   система.   Она  является  логическим  надуровнем
аппаратного  уровня  носителей  информации. Физические параметры
носителей  могут  различаться, а логическая структура оставаться
постоянной,  равно  как и наоборот - одна физическая структура и
разная   логическая.  Достаточно  большое  количество  различных
файловых  систем представляет серьезную проблему совместимости и
переносимости.  Здесь  также  можно пойти по пути Unix: файловая
система  одна. Ее определяют две основные концепции: нет ничего,
кроме  файлов,  в файлах нет ничего, кроме данных. Поясню первую
концепцию.  Все  области  диска,  включая  системную  область  и
каталог,   представляются  как  файлы.  Ну  а  вторая  концепция
является  отображением первой, но уже на уровне данных в файлах.
Также  основной  особенностью этой файловой системы, в оригинале
называвшейся  s5fs,  является  абсолютная  древовидная  файловая
структура.  Вы  можете  у  меня  спросить:  а как насчет того же
MS-DOS? Там ведь тоже древовидная файловая система. Да, я с вами
согласен,  но  все  дело  в  том,  что в системах подобного типа
дерево  строится  для  каждого  логического  диска.  В  s5fs все
по-другому. Есть главное дерево, обычно находящееся на системном
разделе.  Чтобы  получить  доступ  к  другим  разделам  и другим
накопителям,  необходимо  их  файловые  системы примонтировать к
основному  дереву.  Обычно  это  делается  так: создается пустая
папка  и  с  ней  ассоциируется  раздел  диска. Файловая система
скрывает эти переходы для приложений и создается ощущение, будто
все  файлы  находятся  на  одном диске. На самом деле, они могут
даже физически находиться на разных машинах- сеть служит каналом
передачи  данных.  Тем более, данная файловая система, точнее ее
логическая  структура,  очень компактная. Помимо этого, файловая
система предоставляет единый интерфейс как для работы с файлами,
так  и  для  работы  с  потоками  и другими устройствами ввода и
вывода.  Например,  экран  может  быть представлен как файл и на
него будет выводиться вся информация в телетайпном режиме.

Вот,  в  принципе,  и  все,  что  я  хотел  рассказать по поводу
операционных  систем.  И  теперь, выполнив свой долг :), я буду,
согласно  просьбе редакции, рассказывать о своей попытке создать
операционную  систему.  Это  я  говорю  о  проекте ChAOS. Начало
работы  над  ним  как  раз  совпадает с моментом начала раздумий
насчет  ОС  на  спектруме.  Ну нельзя же только рассуждать, надо
попробовать,  как  это будет работать на деле. Вот и попробовал.
Сначала  было  реализовано ядро многозадачности. Оно работало на
основе    алгоритма   круговой   диспетчеризации,   не   слишком
эффективного,  но самого простого. Также были написаны процедуры
диспетчеризации  памяти  и  оконная  оболочка.  Задатки работы с
диском  позволяли  читать  с  диска  файлы  целиком и побайтово,
записывать файлы целиком на диск. Так что, я мог запускать ранее
созданные  и сохраненные приложения. На этом макете отлаживались
многие  алгоритмы  и  проверялись теории. Оказалось, вытесняющая
многозадачность-  дело  реальное.  Все работает, конечно, не так
быстро,  как  хотелось,  но  быстрее,  чем ожидалось. В процессе
разработки   был   проверен   новый   алгоритм  диспетчеризации,
основанный  на  приоритетах. Но заточенная под круговой алгоритм
структура  системы  не  дала  в  полной  мере  опробовать данный
алгоритм,   впрочем,   и  так  показавший  очень  даже  неплохие
результаты.  Для интереса, я послал эту работу Диме Быстрову aka
Alco.  Он-то  и рассказал о ней всему спектрумовскому населению.
Некоторое  время спустя, я начал с нуля писать другую систему, в
которой  старался собрать лучшее от старой версии и внести много
нового.   В   ядро  было  встроено  два  режима  диспетчеризации
процессорного  времени  -  круговой  и  приоритетный.  Диспетчер
памяти  остался  старый,  только расширились его возможности. Но
нехватка  времени  и  появление еще более новых и здравых идей -
модульная  структура  -  заставили  меня пока приостановить этот
проект.  Теперь все приходящие идеи записываются в текстовик для
дальнейшего  обдумывания  и  реализации.  Также совершенствуется
модульная поддержка пока на уровне компиляции.

Сейчас  собираются  идеи,  и  копится  материал  на новую версию
системы.  Работа  ведется  совместно  с  Максимом Фомкиным (MaXx
Fomkin). Рассказывать пока про этот новый проект ничего не хочу,
но   могу   сказать,  что  помимо  мира  виндоуз,  спектрумистам
получится познакомиться с увлекательным миром юникс и линукс :).

Со  всеми вопросами, пожеланиями просьба обращаться по следующим
адресам:

347924 Россия, г.Таганрог, Рост. обл., ул.С.Лазо, д.7, кв.54
Гаврилову Виталию Дмитриевичу,

e-mail: vitamin_caig@mail.ru