\chapter{Понятие операционной системы}
\section{Основные функции операционных систем}

В pаботе \cite{Kxxx} операционная система определяется так:
<<Я не знаю, что это такое, но всегда узнаю ее, если увижу>>.
Эта фраза была сказана в первой половине 70-х, когда операционные системы
действительно отличались большим разнообразием структуры и выполняемых
функций.

С тех времен положение существенно изменилось.
Современные ОС -- по крайней мере, широко распространенные системы --
во многом похожи друг на друга.
Прежде всего это определяется требованием переносимости программного
обеспечения. Именно для обеспечения этой переносимости был принят
\standname{POSIX} (Portable OS Interface based on uniX) -- стандарт,
определяющий минимальные функции по управлению файлами, межпроцессному
взаимодействию и т.д., которые {\it должна} уметь выполнять система.

Кроме того, за четыре с лишним десятилетия, прошедших с момента
разработки первых ОС, сообщество программистов достигло определенного
понимания того, что:
\begin{itemize}
\item при разработке ОС возникает много стандартных проблем и вопросов;
\item для большинства из этих проблем и вопросов существует набор
стандартных решений;
\item некоторые из этих решений намного лучше, чем все альтернативные.
\end{itemize}

\note{Многие из таких наилучших решений были реализованы в операционных
системах семейства \sysname{Unix}. Поэтому среди адептов этой ОС ходит
поговорка: <<Если вы не понимаете \sysname{UNIX}, вы должны будете
заново изобрести его>>. Опыт систем \sysname{OS/2} и \sysname{Windows~NT}
отчасти подтверждает её.
}

По современным представлениям, ОС должна уметь делать следующее:
\begin{itemize}
\item Обеспечивать загрузку пользовательских программ в оперативную память
и их исполнение.
\item Обеспечивать работу с устройствами долговременной памяти, такими как
магнитные диски, ленты, оптические диски и т.д. Как правило, ОС управляет
свободным пространством на этих носителях и структурирует пользовательские
данные.
\item Предоставлять более или менее стандартный доступ к различным
устройствам ввода/вывода, таким как терминалы, модемы, печатающие устройства.
\item Предоставлять некоторый пользовательский интерфейс. Слово {\it некоторый}
здесь сказано не случайно -- часть систем ограничивается командной строкой,
в то время как другие на 90\% состоят из средств интерфейса пользователя.
\end{itemize}

Существуют ОС, функции которых этим и исчерпываются. Одна из хорошо известных
систем такого типа -- дисковая операционная система \sysname{MS~DOS}.

Более развитые ОС предоставляют также следующие возможности:
\begin{itemize}
\item Параллельное (точнее, псевдопараллельное, если машина имеет только один
процессор) исполнение нескольких задач.
\item Распределение ресурсов компьютера между задачами.
\item Организация взаимодействия задач друг с другом.
\item Взаимодействие пользовательских программ с нестандартными внешними устройствами.
\item Организация межмашинного взаимодействия и разделения ресурсов.
\item Защита системных ресурсов, данных и программ пользователя,
исполняющихся процессов и самой себя от ошибочных и зловредных действий
пользователей и их программ.
\end{itemize}

\section{Классификация ОС}

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

\subsection*{ДОС (Дисковые Операционные Системы)}

 Это системы, берущие на себя
выполнение только первых четырех функций. Как правило, это просто некий
резидентный набор подпрограмм, не более того. Он загружает пользовательскую
программу в память и передает ей управление, после чего программа делает с
системой все, что ей заблагорассудится.
Считается желательным, чтобы после завершения программы машина оставалась
в таком состоянии, чтобы ДОС могла продолжить работу.
Если же программа приводит машину в какое-то другое состояние\ellipsis
что ж, ДОС ничем ей в этом не может помешать.
Характерный пример -- различные загрузочные мониторы для машин класса
\machname{Spectrum}.
Как правило, такие системы работают одновременно только с одной программой.

Дисковая операционная система \sysname{MS~DOS} для
\machname{IBM PC}-совместимых
машин является прямым наследником одного из таких резидентных мониторов.
Она, правда, умеет загружать несколько программ, но {\it не предоставляет }
средств для исполнения этих программ.
Более того, с точки зрения документированных функций, этим программам
{\it нельзя} работать.
Конечно, есть еще недокументированные {\it задние двери}
({\it backdoors})\ellipsis

Существование систем такого класса обусловлено их простотой и тем,
что они потребляют мало ресурсов.
Для машин класса \machname{Spectrum} это более чем критичные параметры.
Еще одна причина, по которой такие системы могут использоваться даже на
довольно мощных машинах - требование программной совместимости
с ранними моделями того же семейства компьютеров.

\subsection*{ОС}

К этому классу относятся системы, берущие на себя выполнение
всех вышеперечисленных функций.
Разделение на ОС и ДОС идет, по-видимому, от систем \sysname{IBM DOS/360}
и \sysname{OS/360} для больших компьютеров этой фирмы, клоны
которых известны у нас в стране под названием \machname{ЕС ЭВМ серии 10XX}.
(Кстати, у \entname{IBM} была еще \sysname{TOS/360},
Tape Operating System - Ленточная Операционная Система).

Здесь под ОС мы будем подразумевать системы <<общего назначения>>,
то есть рассчитанные на интерактивную работу одного или нескольких
пользователей в режиме разделения времени, при не очень жестких требованиях
на время реакции системы на внешние события.
Как правило, в таких системах уделяется большое внимание защите самой
системы, программного обеспечения и пользовательских данных от ошибочных
и злонамеренных программ и пользователей.
Обычно такие системы используют встроенные в архитектуру процессора средства
защиты и виртуализации памяти. К этому классу относятся такие широко
распространенные системы, как \sysname{VAX/VMS}, системы семейства
\sysname{Unix} и \sysname{OS/2}, хотя последняя не обеспечивает
одновременной работы нескольких пользователей и защиты пользователей
друг от друга.

\subsection*{Системы виртуальных машин}

 Такие системы стоят несколько особняком.
Это система, допускающая одновременную работу нескольких программ, но
создающая при этом для каждой программы иллюзию, что машина находится в
полном ее распоряжении, как при работе под ДОС.
Примером такой системы является \entname{IBM} \sysname{VM}, известная у нас
в стране под названием \sysname{СВМ} (Система Виртуальных Машин).
Аналогичным образом работают \sysname{DesqView} и другие
\termin{многозадачники}{multitaskers} для \sysname{MS~DOS}.

Часто такие системы являются подсистемой ОС общего назначения:
\sysname{MS~DOS} и \sysname{MS~Windows}-эмуляторы под
\sysname{UNIX} и \sysname{OS/2},
окно \sysname{DOS} в \sysname{MS~Windows}, эмулятор \sysname{RT-11} в
\sysname{VAX/VMS}.

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

\subsection*{Системы реального времени}

 Это системы, предназначенные для облегчения
разработки так называемых \term{приложений реального времени}.
Это программы, управляющие некомпьютерным по природе оборудованием, часто
с очень жесткими ограничениями по времени. Примером такого приложения
может быть программа бортового компьютера крылатой ракеты, системы
управления ускорителем элементарных частиц или промышленным оборудованием.
Такие системы обязаны поддерживать многопроцессность,
{\it гарантированное\/} время реакции на внешнее событие, простой доступ к
таймеру и внешним устройствам. Такие системы могут по другим признакам
относиться как к классу ДОС (\sysname{RT-11}), так и к ОС (\sysname{OS-9},
\sysname{QNX}).
Часто такие системы (например, \sysname{VxWorks}) рассчитаны на работу
совместно с управляющей host-машиной, исполняющей <<нормальную>> операционную
систему.

\note{
Гарантированное время реакции на внешнее событие является отличительным
признаком систем РВ. Требование гарантированного времени реакции налагает
специфические требования на архитектуру ОС; большинство современных ОС
общего назначения непригодно для задач РВ.
}

Любопытно, что новомодное течение в компьютерной
технике --  \term{multimedia} -- при качественной реализации предъявляет
к системе те же требования, что и промышленные задачи реального времени.
В multimedia основной проблемой является синхронизация изображения на экране
со звуком. Именно в таком порядке. Звук обычно генерируется
внешним аппаратным устройством с собственным таймером, и изображение
синхронизуется с ним же.
Человек способен заметить довольно малые временные неоднородности в звуковом
потоке. Напротив, пропуск кадров в визуальном потоке не так заметен,
а расхождение звука и изображения заметно уже при задержках около 30 мс.
Поэтому системы качественного multimedia должны обеспечивать синхронизацию
с такой же или более высокой точностью, что мало отличается от систем
мягкого реального времени

\subsection*{Кросс-загрузчики}

Это системы - полностью ориентированные на работу с
host-машиной. Чаще всего они используются для написания и отладки кода,
позднее прошиваемого в ПЗУ. Это системы программирования микроконтроллеров
семейства \machname{Intel 8048} и подобных им, \sysname{TDS}
(Transputer Development System) фирмы \entname{Inmos}, и многие другие.
Такие системы, как правило, включают в себя набор компиляторов и ассемблеров,
работающих на host-системе (реже -- загружаемых с host-машины в целевую
систему), библиотеки, выполняющие большую часть функций ОС при работе
программы (но не загрузку этой программы!), и средства отладки.

\subsection*{Системы промежуточных типов}

 Существуют системы, которые с первого
взгляда нельзя отнести к одному из вышеперечисленных классов. Такова,
например, система \sysname{RT-11}, которая, по сути своей, является ДОС,
но позволяет одновременное исполнение нескольких программ
с довольно богатыми средствами взаимодействия и синхронизации.
Другим примером промежуточной системы являются \sysname{MS~Windows~3.x}
и \sysname{Windows~95} которые, как ОС, используют аппаратные средства
процессора для защиты и виртуализации памяти и даже могут обеспечивать
некоторое подобие многозадачной работы, но {\it не защищают} себя и
программы от ошибок других программ.


В последнее время вошел в употребление еще один термин: \term{сетевые ОС},
или сокращенно \termin{NOS}{Networking Operating System}. На взгляд авторов,
сложившееся использование этого термина несколько неудачно. Его можно
употреблять в двух различных смыслах:
\begin{enumerate}
\item Системы, предназначенные для предоставления сетевых услуг,
аналогично тому, как ДОС предназначена для предоставления средств
работы с диском. Под такое понимание NOS подходят узкоспециализированные
системы, такие как \sysname{Novell Netware}, \sysname{K9Q} или программное
обеспечение маршрутизаторов \machname{Cisco}.

\item Системы, способные предоставлять сетевые услуги. Под такое определение
подходят практически все современные ОС общего назначения.
\end{enumerate}

Судя по тому, что большинство <<обзоров сетевых операционных систем>>
в компьютерных журналах сравнивают не маршрутизатор \machname{Cisco}
с \sysname{K9Q}, а \sysname{Windows~NT} с \sysname{SunSoft Solaris}
или \sysname{OS/2}, термин NOS в этих публикациях понимается во втором
смысле. Как уже говорилось, практически все современные ОС и некоторые
ДОС способны предоставлять сетевые сервисы, поэтому этот термин почти
эквивалентен словам <<Современная ОС общего назначения>> и, таким образом,
почти не несет полезной информации.

\section{Выбор операционной системы}

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

Например, задачи
управления промышленным или исследовательским оборудованием в режиме
жесткого реального времени вынуждают нас делать выбор между
специализированными ОС реального времени и некоторыми ОС общего назначения,
такими как \sysname{Unix System V Release 4}\footnote{
Хотя \sysname{Unix SVR4} теоретически способен обеспечивать гарантированное
время реакции, системы этого семейства имеют ряд недостатков с точки зрения
задач РВ, поэтому чаще всего предпочтительными оказываются специализированные
ОС -- \sysname{QNX}, \sysname{VxWorks}, \sysname{OS-9} и т.д..}.
Другие приложения, например серверы баз данных, просто требуют
высокой надежности и производительности,
что отсекает системы класса ДОС и \sysname{MS~Windows}.

Наконец, некоторые задачи, такие как автоматизация конторской работы,
не предъявляют больших требований к надежности, производительности
и времени реакции системы, что предоставляет широкий выбор между
различными ДОС, \sysname{MS~Windows}, \sysname{Mac OS} и многими системами
общего назначения. При этом технические параметры системы перестают играть
роль, и в игру вступают другие факторы. На заре персональной техники
таким фактором была стоимость аппаратного обеспечения, вынуждавшая
делать выбор в пользу ДОС и, позднее, \sysname{MS~Windows}.

Сейчас же стоимость аппаратуры резко упала, а требования персонального
программного обеспечения резко возросли. Последняя версия
пакета \progname{MS~Office} занимает около 120 мегабайт на диске
и требует для комфортабельной работы 8-16 мегабайт памяти и процессор
класса \machname{486/Pentium}. Машины такого типа вполне достаточно для работы
многих ОС общего назначения, таких как \sysname{OS/2}, \sysname{Linux}
и некоторых коммерческих систем семейства \sysname{Unix}. Тем не менее,
в большинстве ситуаций выбор по-прежнему делается в пользу
\sysname{MS~Windows}. Обычно при этом ссылаются на отсутствие программного
обеспечения для <<альтернативных>> систем, несмотря на то, что объективный
анализ ситуации показывает несостоятельность этого утверждения.

{%\small
Например, \sysname{OS/2} способна исполнять практически все прикладное ПО,
разработанное для \sysname{DOS} и \sysname{MS~Windows}\footnote{Если быть
точным, то ряд DOS и Windows-приложений, в первую очередь системные утилиты,
некоторые игры, вирусы и некоторые программы multimedia, все-таки
отказываются работать в эмуляции, но программы, необходимые в офисе
-- \progname{MS~Word}, \sysname{Excel} и им подобные -- работают не
хуже, чем под <<родной>> системой.};
для этой системы существует также ряд офисных приложений --
текстовые процессоры \progname{Describe}, \progname{ClearLook},
\progname{AmiPro/2}, электронные таблицы \progname{Lotus-123}  и т.д..

Для \sysname{Linux} приложений конторской направленности меньше,
и они выглядят несколько странно для пользователя, привыкшего к
\sysname{MS~Windows}, однако они существуют -- например, WYSIWYG
текстовый процессор \progname{ez} и электронные таблицы \progname{xess}.

Мы не упоминаем здесь прикладное ПО, разработанное для \sysname{Mac OS},
потому что это ПО не может исполняться на процессорах архитектуры
\machname{x86}, а машины фирмы \entname{Apple} несколько дороже клонов
\machname{IBM PC}.
}

Утверждение о том, что \sysname{MS~Windows} проще в эксплуатации,
чем доступные альтернативы, также не соответствует действительности,
особенно при работе в сети. Более убедительно звучат слова о том,
что переход под другую ОС потребует переучивания пользователей
и поиска или обучения специалистов, которые будут заниматься
установкой и поддержкой системы. Большинство же современных
специалистов по персональным компьютерам знакомы лишь с одной
ОС -- \sysname{MS~DOS/MS~Windows}...

Нужно отметить, впрочем, что \sysname{MS~Windows}, несмотря на
низкую надежность, сложность конфигурации и поддержки и ряд функциональных
недостатков, вполне адекватна большинству задач конторской автоматизации.
Проблемы возникают, когда задачи, стоящие перед организацией, выходят
за пределы распечатки прайс-листов из \progname{MS~Excel} и набора
писем в \progname{MS~Word}. Лучше всего проблемы этого рода выражены в
следующей притче:

\begin{quote}
Проблема. Организация имеет двенадцать велосипедов. Стоит задача:
перевезти рояль. Что делать? Грузовик не предлагать...
\end{quote}

Основная проблема \sysname{MS~Windows} состоит вовсе не в том, что это
не <<настоящая>> операционная система -- <<велосипед>>, в терминах
процитированной притчи, а в том, что она не обеспечивает путей плавного и
безболезненного перехода под другие платформы, даже если возникнет
необходимость такого перехода. Строго говоря, тот же недостаток
свойствен многим другим \termin{закрытым}{closed} платформам,
поставляемым одной фирмой и использующим нестандартные <<фирменные>>
интерфейсы. Пока <<закрытое>> решение соответствует вашим требованиям,
все хорошо, но когда вы выходите за пределы технологических возможностей
данного решения, вы оказываетесь в тупике.

\section{Открытые системы}

Альтернативой закрытым решениям является концепция \term{открытых систем}.
Идея открытых систем исходит из того, что для разных задач необходимы
разные системы -- как специализированные, так и системы общего назначения,
просто по-разному настроенные и сбалансированные. Сложность состоит
в том, чтобы:
\begin{itemize}
\item Обеспечить взаимодействие разнородных систем в гетерогенной сети.
\item Обеспечить обмен данными между различными приложениями на разных
платформах.
\item Обеспечить переносимость прикладного ПО с одной платформы на другую,
хотя бы путем перекомпиляции исходных текстов.
\item Обеспечить по возможности однородный пользовательский интерфейс.
\end{itemize}

Эти задачи предполагается решать при помощи открытых стандартов --
стандартных сетевых протоколов, стандартных форматов данных,
стандартизации программных интерфейсов -- \termint{API}{Application
Program Interface}{интерфейс прикладных программ} и, наконец, стандартизации
пользовательского интерфейса.

В качестве стандартного сетевого протокола предлагалась семиуровневая модель
\entname{OSI}, но прежде, чем на основе этой модели было разработано
что-то полезное, получило широкое распространение семейство протоколов
\protname{TCP/IP}. Документация по протоколам этого семейства имеет статус
\termin{public domain}{общественная собственность}; кроме того, есть
по крайней мере одна программная реализация этого протокола, также
имеющая статус \term{public domain} -- сетевое ПО системы \sysname{BSD Unix},
поэтому \protname{TCP/IP} является вполне приемлемым основанием для открытых
систем.

Обсуждение стандартных форматов данных увело бы нас далеко от основной
темы, но нужно отметить следующее: в настоящее время существует много
общепризнанных стандартов представления изображений (особенно растровых)
и звуковых данных, но некоторые типы данных так и не имеют признанной
стандартной формы. Например, есть несколько открытых форматов
представления форматированного текста: \progname{troff}, \LaTeX и другие
пакеты макросов для системы \TeX, и, наконец, стандарт \standname{SGML}
(Standard Generalized Markup Language), но ни один из этих стандартов
не пользуется популярностью среди разработчиков коммерческих текстовых
процессоров\footnote{Справедливости ради нужно отметить, что форматы
\progname{troff} и \LaTeX очень неудобны для WYSIWYG текстовых процессоров,
но \standname{SGML} разрабатывался специально для них.}.
Причины такого отношения понятны: предоставление пользователю
возможности без проблем обмениваться данными с текстовым процессором
конкурента означает дать пользователю возможность выбирать между твоим
процессором и его. Впрочем, пользователю от понимания не легче...

Для того чтобы как-то обеспечить переносимость программ между
системами различных типов, принимались различные стандарты интерфейса между
пользовательской (обычно говорят -- прикладной, но это не всегда правильно)
программой и ОС. Одним из первых таких стандартов был стандарт библиотек
\standname{ANSI C}. Он основан на системных вызовах ОС \sysname{Unix},
но функции \sysname{MS~DOS} для работы с файлами (те, которые используют
\term{file handle}) тоже достаточно близки к этому стандарту.

В  конце 80-х - начале 90-х гг. было осознано, что средства для
<<тонкого>> управления файлами и межпроцессного взаимодействия также
нуждаются в стандартизации.
Первоначально идея состояла в том, чтобы привести
различных потомков системы \sysname{UNIX} к какому-то общему знаменателю.
Для этой цели в \entname{ISO} (International Standard Organisation) был
создан ряд комитетов, принимавших стандарты для различных сфер деятельности
(сетевое взаимодействие, работа в реальном времени и т.д.).

В настоящее время приняты только два документа этого стандарта из
предполагаемых десяти.
Эти документы регламентируют операции над файлами
(стандарт \standname{POSIX.1}) и интерпретатор команд (\standname{POSIX.2}).
Тем не менее, большинство производителей ОС объявили, что их
системы, такие как \sysname{VMS~5.4} и \sysname{Windows~NT},
объявили о поддержке этого стандарта.

\note{По оценкам
пользователей \sysname{NT}, \standname{POSIX}-подсистема этой ОС
является упражнением в том, насколько бесполезной можно сделать полную
реализацию стандарта \standname{POSIX},  или, наоборот, насколько
полной может быть совершенно бесполезная реализация.

Отчасти бесполезность этой
подсистемы обусловлена неполнотой принятых в настоящее время документов
стандарта \standname{POSIX}:
например, они совершенно не охватывают сетевые интерфейсы, что позволило
фирме \entname{MicroSoft} реализовать собственный интерфейс
\progname{WinSock} вместо принятых в \sysname{Unix} механизмов.
Это делает практически невозможным перенос сетевого программного
обеспечения, и т.д..}

В качестве стандартного командного языка стандарт \standname{POSIX}
предлагает командный язык \progname{Bourne Shell}. Со стандартизацией
графического интерфейса пользователя ситуация несколько сложнее и будет
обсуждаться в разделе \ref{GUI}.
