Текст лекции. Лекция № 1. Типы операционных систем

Ключевые вопросы

Лекция № 1. Типы операционных систем. Часть 2

Продолжительность: 2 часа (90 мин.)

· Цель и задачи курса.

· Информация и данные.

· Основные понятия и определения: дисковые операционные системы (ДОС); ОС общего назначения; системы промежуточных типов, системы виртуальных машин; системы реального времени; системы кросс-разработки; системы промежуточных типов.

· Преемственность между разными ОС.

· История развития систем.

· Семейства операционных систем

· Открытые системы.

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

Рисунок 3.1 – Классификация операционных систем

3.2.1 ДОС (Дисковые Операционные Системы) — до 15 мин.

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

Характерный пример — различные загрузочные мониторы для машин клас­са Spectrum. Как правило, такие системы работают одновременно только с одной программой.

Дисковая операционная система MS DOS для IBM PC-совместимых машин является прямым наследником одного из таких резидентных мониторов.

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

3.2.2 ОС общего назначения — до 15 мин.

К этому классу относятся системы, берущие на себя выполнение всех вы­шеперечисленных функций. Разделение на ОС и ДОС идет, по-видимому, от систем IBM DOS/360 и OS/360 для больших компьютеров этой фирмы, клоны которых известны у нас в стране под названием ЕС ЭВМ серии 10ХХ.

Здесь под ОС мы будем подразумевать системы "общего назначения", т. е. системы, рассчитанные на интерактивную работу одного или нескольких пользовате­лей в режиме разделения времени, при не очень жестких требованиях ко времени реакции системы на внешние события. Как правило, в таких сис­темах уделяется большое внимание защите самой системы, программного обеспечения и пользовательских данных от ошибочных и злонамеренных программ и пользователей. Обычно подобные системы используют встроен­ные в архитектуру процессора средства защиты и виртуализации памяти. К этому классу относятся такие широко распространенные системы, как Windows 2000, системы семейства Unix.

3.2.3 Системы виртуальных машин — до 15 мин.

Такие системы стоят несколько особняком. Система виртуальных машин — это ОС, допускающая одновременную работу нескольких программ, но соз­дающая при этом для каждой программы иллюзию того, что машина нахо­дится в полном ее распоряжении, как при работе под управлением ДОС. Зачастую, "программой" оказывается полноценная операционная система – примерами таких систем являются VMWare для машин с архитектурой х86 или VM для System/370 и ее потомков.

Виртуальные машины являются ценным средством при разработке и тести­ровании кросс-платформенных приложений. Реже они используются для отладки модулей ядра или самой операционной системы.

Такие системы отличаются высокими накладными расходами и сравнитель­но низкой надежностью, поэтому относительно редко находят промышлен­ное применение.

Часто СВМ являются подсистемой ОС общего назначения: MS DOS и MS Windows-эмуляторы для UNIX и OS/2, подсистема WoW в Windows NT/2000/XP, сессия DOS в Windows З.х/95/98/МЕ, эмулятор RT-11 в VAX/VMS.

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

3.2.4 Системы реального времени — до 15 мин.

Это системы, предназначенные для облегчения разработки приложений реального времени — программ, управляющих некомпьютерным оборудованием с жесткими ограничениями по времени. Примером такого приложения может быть программа бортового компьютера fly-by-wire (дословно — "летящий по проволоке", т. е. использующий систе­му управления, в которой органы управления не имеют механической и гидравлической связи с рулевыми плоскостями) самолета, системы управ­ления атомной электростанцией или промышленным оборудовани­ем. Подобные системы должны поддерживать многопоточность, гарантиро­ванное время реакции на внешнее событие, простой доступ к таймеру и внешним устройствам.

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

По другим признакам эти системы могут относиться как к классу ДОС (RT-11), так и к ОС (OS-9, QNX).

Качественная реализация современных мультимедиа приложений предъявляет к системе те же требования, что и промышленные задачи реального времени. В мультимедиа основной проблемой является синхронизация изображения на экране со звуком. Именно в таком порядке. Звук обычно генерируется внешним аппаратным устройством с собственным таймером, и изображение синхро­низируется с ним. Человек способен заметить довольно малые временные неоднородности в звуковом потоке, а пропуск кадров в визуальном потоке не так заметен. Расхождение же звука и изображения фиксируется челове­ком уже при задержках около 30 мс. Поэтому системы высококачественного мультимедиа должны обеспечивать синхронизацию с такой же или более вы­сокой точностью, что мало отличается от реального времени.

Так называемое "мягкое реальное время" (soft real time), предоставляемое со­временными Win32 платформами, не является реальным временем вообще, это что-то вроде "осетрины второй свежести". Система "мягкого РВ" обеспе­чивает не гарантированное, а всего лишь среднее время реакции. Для муль­тимедийных приложений и игр различие между "средним" и "гаранти­рованным" не очень критично — ну дернется картинка, или поплывет звук. Но для промышленных приложений, где необходимо настоящее реальное время, это обычно неприемлемо.

3.2.5 Системы кросс-разработки — до 15 мин.

Это системы, предназначенные для разработки программ в двухмашинной конфигурации, когда редактирование, компиляция, а зачастую и отладка кода производятся на инструментальной машине (в англоязычной литерату­ре ее часто называют host — дословно, "хозяин"), а потом скомпилирован­ный код загружается в целевую систему. Чаще всего они используются для написания и отладки программ, позднее прошиваемых в ПЗУ. Примерами таких ОС являются системы программирования микроконтроллеров Intel, Atmel, PIC и др., системы Windows СЕ, Palm OS и т. д. Такие системы, как правило, включают в себя:

- набор компиляторов и ассемблеров, работающих на инструментальной машине с "нормальной" ОС;

- библиотеки, выполняющие большую часть функций ОС при работе про­граммы (но не загрузку этой программы!);

- средства отладки.

Иногда встречаются кросс-системы, в которых компилятор работает не на инструментальной машине, а в целевой системе — так, например, устроена среда разработки для семейства микропроцессоров Transputer компании Inmos..

3.2.6 Системы промежуточных типов — до 15 мин.

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

Некоторые системы реального времени, например QNX, могут использо­ваться как в качестве самостоятельной ОС, загружаемой с жесткого диска в оперативную память, так и, будучи прошиты в ПЗУ. Эти системы могут быть отнесены одновременно и к ОС общего назначения, и к системам кросс-разработки.

Таких примеров "гибридизации" можно привести множество.

3.2.7 Семейства операционных систем — до 15 мин.

Часто можно проследить преемственность между различными ОС, необяза­тельно разработанными одной компанией. Отчасти такая преемственность обусловлена требованиями совместимости или хотя бы переносимости при­кладного программного обеспечения, отчасти – заимствованием отдельных удачных концепций.

На основании такой преемственности можно выстроить "генеалогические деревья" операционных систем и — с той или иной обоснованностью — объединять их в семейства. Впрочем, в отличие от древа происхождения биологических видов, граф родства ОС не является деревом и нередко со­держит циклы, поэтому стройную многоуровневую классификацию построить не всегда удается.

Тем не менее, можно выделить ми­нимум три семейства ныне эксплуатирующихся ОС и еще несколько — вы­мерших или близких к тому. Три ныне процветающих семейства:

- ОС компьютеров фирмы IBM – OS/390, z/OS и IBM VM,

- Обширное, бурно развивающееся и имеющее трудно определимые гра­ницы семейство Unix:

• Unix System V Release 4.x: SunSoft Solaris, SCO UnixWare;

• Berkeley Software Distribution Unix: BSDI, FreeBSD;

• Linux,

- Семейство прямых и косвенных потомков Control Program/Monitor (СР/М) фирмы Digital Research.

Еще одно практически вымершее к настоящему моменту, но оставившее в наследство ряд важных и интересных концепций семейство – это операци­онные системы для мини- и микрокомпьютеров фирмы DEC: RT-11, RSX-11 и VAX/VMS.

Нужно отметить, впрочем, что современные версии Windows, несмотря на низкую надежность, сложность конфигурации и поддержки и ряд функ­циональных недостатков, вполне адекватны большинству задач конторской автоматизации. Проблемы возникают, когда задачи, стоящие перед органи­зацией, выходят за пределы распечатки прайс-листов из MS Excel и набора писем в MS Word.

Основная проблема MS Windows состоит вовсе не в том, что это не "насто­ящая" операционная система, а в том, что она не обеспечивает путей плавного и безболезненного перехода к другим платформам, даже если возникнет необходимость такого перехода. Строго говоря, тот же недостаток свойственен многим другим за­крытым (closed) платформам, поставляемым одной фирмой и использую­щим нестандартные "фирменные" интерфейсы. Пока "закрытое" решение соответствует вашим требованиям, все хорошо, но когда вы выходите за пределы технологических возможностей данного решения, вы оказывае­тесь в тупике.

3.2.8 Открытые системы — до 15 мин.

Альтернативой закрытым решениям является концепция открытых систем. Идея открытых систем исходит из того, что для разных задач необходимы разные системы — как специализированные, так и системы общего назна­чения, просто по-разному настроенные и сбалансированные. Сложность состоит в том, чтобы обеспечить:

- взаимодействие разнородных систем в гетерогенной сети,

- обмен данными между различными приложениями на разных платформах,

- переносимость прикладного ПО с одной платформы на другую, хотя бы путем перекомпиляции исходных текстов,

- по возможности однородный пользовательский интерфейс.

Эти задачи решаются при помощи открытых стандартов – стандартных сетевых протоколов, стандартных форматов данных, стандарти­зации программных интерфейсов – API (Application Program Interface, интер­фейс прикладных программ) и, наконец, стандартизации пользовательского интерфейса.

Для того чтобы как-то обеспечить переносимость программ между система­ми различных типов, принимались различные стандарты интерфейса между пользовательской (обычно говорят — прикладной, но это не всегда пра­вильно) программой и ОС. Одним из первых таких стандартов был стандарт библиотек ANSI С. Он основан на системных вызовах ОС Unix, но функции MS DOS для работы с файлами (использующие file handle) тоже достаточно близки к этому стандарту.

Позднее делалось еще несколько попыток стандартизировать интерфейс системных вызовов. Одной из относительно удачных попыток такого рода был POSIX (Portable Operating System Interface [based on] uniX – переноси­мый интерфейс операционной системы, основанный на Unix), который в той или иной форме поддерживается всеми системами семейства Unix и некоторыми ОС, не входящими в это семейство, например Windows NT. Наибольший же успех имела деятельность консорциума Х/Open, который в 1998 году сертифицировал операционную систему OS/390 фирмы IBM как соответствующую спецификациям Unix/95.