Совместимость операционных систем. Операционные системы различных фирм

Переносимость.

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

Существует несколько «долгоживущих» популярных операционных систем (разновидности UNIX, MS-DOS, Windows NT, OS/2), для которых наработана широкая номенклатура приложений. Некоторые из них пользуются широкой популярностью. Поэтому для пользователя, переходящего по тем или иным причинам с одной ОС на другую, очень привлекательна возможность запуска в новой операционной системе привычного приложения. Если ОС имеет средства для выполнения прикладных программ, написанных для других операционных систем, то про нее говорят, что она обладает совместимостью с этими ОС. Следует различать совместимость на уровне двоичных кодов и совместимость на уровне исходных текстов. Понятие совместимости включает также поддержку пользовательских интерфейсов других ОС.

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

-3. 7. Совместимость и множественные прикладные среды

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

-3. 7. 1. Двоичная совместимость и совместимость исходных текстов

Необходимо различать совместимость на двоичном уровне и совместимость на уровне исходных текстов. Приложения обычно хранятся в ОС в виде исполняемых файлов, содержащих двоичные образы кодов и данных. Двоичная совместимость достигается в том случае, когда можно взять исполняемую программу и запустить ее на выполнение в среде другой ОС.

Совместимость на уровне исходных текстов требует наличия соответствующего компилятора в составе программного обеспечения компьютера, на котором предполагается выполнять данное приложение, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция имеющихся исходных текстов в новый исполня-емый модуль. Совместимость на уровне исходных текстов важна в основном для разработчиков приложений, в распоряжении которых эти исходные тексты всегда имеются. Но для конечных пользователей практическое значение имеет только двоичная совместимость, так как только в этом случае они могут использовать один и тот же коммерческий продукт, поставляемый в виде двоичного исполняемого кода, в различных операционных средах и на различных машинах. Для пользователя, купившего в свое время пакет (например, Lotus 1-2-3) для MS-DOS, важно, чтобы он мог запускать этот полюбившийся ему пакет без каких-либо изменений и на своей новой машине, работающей под управлением, например, Windows NT. Обладает ли новая ОС двоичной совместимостью или совместимостью исходных текстов с существующими операционными системами, зависит от многих факторов. Самый главный из них – архитектура процессора, на котором работает новая ОС. Если процессор использует тот же набор команд (возможно, с некоторыми добавлениями) и тот же диапазон адресов, тогда двоичная совместимость может быть достигнута довольно просто.

Для этого достаточно соблюдения сле­дующих условий:

вызовы функций API, которые содержит приложение, должны поддерживать­ся данной ОС;

внутренняя структура исполняемого файла приложения должна соответство­вать структуре исполняемых файлов данной ОС.

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

Пусть, например, требуется выполнить DOS-программу для IBM PC-совместимого компьютера на компьютере Macintosh. Компьютер Macintosh построен на основе процессора Motorola 680x0, а компьютер IBM PC - на основе процессора Intel 80x86. Процессор Motorola имеет архитектуру (систему команд, состав регистров и т. п.), отличную от архитектуры процессора Intel, поэтому ему непонятен двоичный код DOS-программы, содержащей инструкции этого процессора. Для того чтобы компьютер Macintosh смог интерпретировать машинные инструкции, которые ему изначально непонятны, на нем должно быть установлено специальное программное обеспечение - эмулятор .

Эмулятор должен последовательно выбирать каждую двоичную инструкцию процессора Intel, программным способом дешифрировать ее, чтобы определить, какие действия она задает, а затем выполнять эквивалентную подпрограмму, написанную в инструкциях процессора Motorola. Так как к тому же у процессора Motorola нет в точности таких же регистров, флагов и внутреннего арифметико-логического устройства, как в Intel, он должен также имитировать (эмулировать) все эти элементы с использованием своих регистров или памяти. Состояние эмулируемых регистров и флагов после выполнения каждой команды должно быть абсолютно таким же,как и в реальном процессоре Intel. Это простая, но очень медленная работа, так как одна команда процессора Intel исполняется значительно быстрее, чем эмулирующая его последовательность ко­манд процессора Motorola.

-3. 7. 2. Трансляция библиотек

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

Эффективность этого подхода связана с тем, что большинство сегодняшних программ работают под управлением GUI (Graphic User Interface - графических интерфейсов пользователя) типа Windows, Mac или UNIX Motif, при этом приложения тратят большую часть времени, производя некоторые хорошо предсказуемые действия. Они непрерывно выполняют вызовы библиотек GUI для манипулирования окнами и для других связанных с GUI действий. Сегодня в типичных программах 60-80 % времени тратится на выполнение функций GUI и других библиотечных вызовов ОС. Именно это свойство приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программы. Тщательно спроектированная программная прикладная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но написанные на «родном» коде, и этим достигается существенное ускорение выполнения программ с API другой операционной системы. Иногда такой подход называют трансляцией для того, чтобы отличать его от более медленного процесса эмулирования кода по одной команде за раз.

Например, для Windows-программы, работающей на Macintosh, при интерпретации команд процессора Intel 80x86 производительность может быть очень низкой. Но когда производится вызов функции GUI открытия окна, модуль ОС, реализующий прикладную среду Windows, может перехватить этот вызов и перенаправить его на перекомпилированную для процессора Motorola 680x0 подпрограмму открытия окна. В результате на таких участках кода скорость работы программы может достичь (а возможно, и превзойти) скорость работы на своем «родном» процессоре.

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

-3. 7. 3. Способы реализации прикладных программных сред

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

Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде обычного приложения. В операционных системах, построенных с использовани­ем микроядерной концепции, таких, как, например, Windows NT, прикладные среды выполняются в виде серверов пользовательского режима. А в OS/2 с ее более простой архитектурой средства организации прикладных сред встроены глубоко в операционную систему.

Один из наиболее очевидных вариантов реализации множественных приклад­ных сред основывается на стандартной многоуровневой структуре ОС. На рис. 3. 8 операционная система OS1 поддерживает кроме своих «родных» приложений приложения операционной системы OS2. Для этого в ее составе имеется специальное приложение – прикладная программная среда, которая транс­лирует интерфейс «чужой» операционной системы –API OS2 в ин­терфейс своей «родной» операционной системы – API OS1.

Рис. 3. 8. Прикладная программная среда, транслирующая
системные вызовы

В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных програм-мных интерфейсов. В приведенном на рис. 3. 9примере операционная си-стема поддерживает прило­жения, написанные для OS1, OS2 и OS3. Для этого непосредственно в простран­стве ядра системы размещены прикладные программные интерфейсы всех этих ОС: API OS1, API OS2 и API OS3.

Рис. 3. 9. Реализация совместимости на основе нескольких
равноправных API

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

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

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

Рис. 3. 10. Микроядерный подход к реализации множественных
прикладных сред

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры, в частности:

· очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей расширяемости микроядерных ОС;

· надежность и стабильность выражаются в том, что при отказе одной из при­кладных сред все остальные сохраняют работоспособность;

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

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

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

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

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

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

Вид возможной совместимости зависит от многих факторов. Самый главный из них– архитектура процессора. Если процессор использует тот же набор команд (возможно с добавлениями, как в случае IBM PC – стандартный набор + мультимедиа + графика + потоковые) и тот же диапазон адресов, то двоичная совместимость может быть достигнута достаточно просто. Для этого необходимо соблюдение следующих условий:

• API, который использует приложение, должны поддерживаться данной ОС;
• внутренняя структура исполняемого фала приложения должна соответствовать структуре исполняемых фалов данной ОС.

Если процессоры имеют разную архитектуру, то, кроме перечисленных условий, необходимо организовать эмуляцию двоичного кода. Например, широко используется эмуляция команд процессора Intel на процессоре Motorola 680x0 компьютера Macintosh. Программный эмулятор в этом случаи последовательно выбирает двоичную инструкцию процессора Intel и выполняет эквивалентную подпрограмму, написанную в инструкциях процессора Motorola. Так как у процессора Motorola нет в точности таких же регистров, флагов, внутреннего АЛУ и др., как в процессорах Intel, он должен также имитировать (эмулировать) все эти элементы с использованием своих регистров или памяти.

Это простая, но очень медленная работа, поскольку одна команда Intel выполняется значительно быстрее, чем эмулирующая ее последовательность команд процессора Motorola. Выходом в таких случаях является использование так называемых прикладных программных сред, или операционных сред. Одной из составляющих такой среды является набор функций интерфейса прикладного программирования API , которая ОС предоставляет своим приложениям. Для сокращения времени на выполнение чужих программ прикладные среды имитируют обращение к библиотечным функциям.

Эффективность этого подхода связана с тем, что большинство сегодняшних программ работают под управлением GUI (графических интерфейсов пользователя) типа Windows , MAC или UNIX Motif , при этом приложения тратят 60-80% времени на выполнение функций GUI и других библиотечных вызовов ОС. Именно это свойство приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программ. Тщательно спроектированная программная прикладная среда имеет в своем составе библиотеки, имитирующие библиотеки GUI , но написанная на "родном коде". Таким образом, достигается существенное ускорение выполнения программ с API другой операционной системы. Иначе такой подход называют трансляцией – для того, чтобы отличить его от более медленного процесса эмулирования по одной команде за раз.

Например, для Windows -программы, работающей на Macintosh, при интерпретации команд процессора Intel производительность может быть очень низкой. Но когда производится вызов функции GUI , открытие окна и др., модуль ОС, реализующий прикладную среду Windows , может перехватить этот вызов и перенаправить его на перекомпилированную для процессора Motorola 680x0 подпрограмму открытия окна. В результате на таких участках кода скорость работы программы может достичь (а возможно, и превзойти) скорость работы на своем родном процессоре.

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

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

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

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

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

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры , в частности:

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

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

3.9. Виртуальные машины как современный подход к реализации множественных прикладных сред

Понятие " монитор виртуальных машин" (МВМ) возникло в конце 60-х как программный уровень абстракции , разделявший аппаратную платформу на несколько виртуальных машин. Каждая из этих виртуальных машин (ВМ) была настолько похожа на базовую физическую машину, что существующее программное обеспечение могло выполняться на ней в неизменном виде. В то время вычислительные задачи общего характера решались на дорогих мэйнфреймах (типа IBM /360), и пользователи высоко оценили способность МВМ распределять дефицитные ресурсы среди нескольких приложений.

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

Сегодня МВМ – снова в центре внимания. Корпорации Intel, AMD , Sun Microsystems и IBM создают стратегии виртуализации, в научных лабораториях и университетах для решения проблем мобильности, обеспечения безопасности и управляемости развиваются подходы, основанные на виртуальных машинах. Что же произошло между отставкой МВМ и их возрождением?

В 90-е годы исследователи из Стэндфордского университета начали изучать возможность применения ВМ для преодоления ограничений оборудования и операционных систем. Проблемы возникли у компьютеров с массовой параллельной обработкой (Massively Parallel Processing , MPP ), которые плохо поддавались программированию и не могли поддерживать имеющиеся ОС. Исследователи обнаружили, что с помощью виртуальных машин можно сделать эту неудобную архитектуру достаточно похожей на существующие платформы, чтобы использовать преимущества готовых ОС. Из этого проекта вышли люди и идеи, ставшие золотым фондом компании VMware (www.vmware.com), первого поставщика МВМ для компьютеров массового применения.

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

Чтобы уменьшить влияние системных аварий и защититься от взломов, системные администраторы вновь обратились к однозадачной вычислительной модели (с одним приложением на одной машине). Это привело к дополнительным расходам, вызванным повышенными требованиями к оборудованию. Перенос приложений с разных физических машин на ВМ и консолидация этих ВМ на немногих физических платформах позволили повысить эффективность использования оборудования, снизить затраты на управление и производственные площади. Таким образом, способность МВМ к мультиплексированию аппаратных средств – на этот раз во имя консолидации серверов и организации коммунальных вычислений – снова возродила их к жизни.

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

Виртуализация – развивающаяся технология. В общих словах, виртуализация позволяет отделить ПО от нижележащей аппаратной инфраструктуры. Фактически, она разрывает связь между определенным набором программ и конкретным компьютером. Монитор виртуальных машин отделяет программное обеспечение от оборудования и формирует промежуточный уровень между ПО , выполняемым виртуальными машинами, и аппаратными средствами. Этот уровень позволяет МВМ полностью контролировать использование аппаратных ресурсов гостевыми операционными системами (GuestOS), которые выполняются на ВМ.

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

Благодаря полной инкапсуляции состояния ПО на ВМ монитор ВМ может отобразить ВМ на любые доступные аппаратные ресурсы и даже перенести с одной физической машины на другую. Задача балансировки нагрузки в группе машин становится тривиальной и появляются надежные способы борьбы с отказами оборудования и наращивания системы. Если нужно отключить отказавший компьютер или ввести в строй новый, МВМ способен соответствующим образом перераспределить виртуальные машины. Виртуальную машину легко тиражировать, что позволяет администраторам по мере необходимости оперативно предоставлять новые услуги.

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

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

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

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

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

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

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

Чтобы добиться высокой производительности и совместимости при виртуализации архитектуры x86 , компания VMware разработала новый метод виртуализации, который объединяет традиционное прямое выполнение с быстрой трансляцией двоичного кода "на лету". В большинстве современных ОС режимы работы процессора при выполнении обычных прикладных программ легко поддаются виртуализации, а следовательно, их можно виртуализировать посредством прямого выполнения. Непригодные для виртуализации привилегированные режимы может выполнять транслятор двоичного кода, исправляя "неудобные" команды x86 . В результате получается высокопроизводительная виртуальная машина , которая полностью соответствует оборудованию и поддерживает полную совместимость ПО .

Преобразованный код очень похож на результаты паравиртуализации. Обычные команды выполняются в неизменном виде, а команды, нуждающиеся в специальной обработке (такие как POPF и команды чтения регистров сегмента кода), транслятор заменяет последовательностями команд, которые подобны требующимся для выполнения на паравиртуализованной виртуальной машине. Однако есть важное различие: вместо того, чтобы изменять исходный код операционной системы или приложений, транслятор двоичного кода изменяет код при его выполнении в первый раз.

Хотя трансляция двоичного кода требует некоторых дополнительных расходов, при нормальных рабочих нагрузках они незначительны. Транслятор обрабатывает лишь часть кода, и скорость выполнения программ становится сопоставимой со скоростью прямого выполнения – как только заполнится кэш- память трассировки.

Трансляция двоичного кода также помогает оптимизировать прямое выполнение. Например, если при прямом выполнении привилегированного кода часто происходит перехват команд, это может привести к существенным дополнительным расходам, поскольку при каждом перехвате управление передается от виртуальной машины к монитору и обратно. Трансляция кода может устранить многие из таких перехватов, что приведет к снижению накладных расходов на виртуализацию. Это особенно верно для центральных процессоров с длинными конвейерами команд, в частности, для современного семейства x86 , в котором перехват связан с высокими дополнительными расходами.

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

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

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

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

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

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

безопасность и надежность – благодаря удалению из МВМ сложного кода драйверов устройств.

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

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

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

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

Виды совместимости Чтобы достичь двоичной совм-ти достаточно соблюсти условия: вызовы функций API, которые содержат приложения должны поддерживаться данной ОС; внутренняя структура исполняемого файла приложения должна соответствовать структуре исполняемых файлов данной ОС. Самый значительный из них - архитектура процессора, на котором работает ОС.

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

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

Виды совместимости Тем не менее, существует другой, гораздо более эффективный выход из описанной ситуации – использование так называемых прикладных программных сред. Одной из составляющих, формирующих программную среду, является набор функций интерфейса прикладного программирования API, которым ОС обеспечивает свои приложения.

Виды совместимости Эффективность данного подхода определяется тем, что большинство современных программ работают под управлением графических интерфейсов пользователя (GUI) типа Windows, UNIX при этом приложения, как правило, наибольшую часть времени тратят на выполнение, некоторых хорошо предсказуемых действий

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

Виды совместимости Тщательно спроектированная программная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но написанные на "родном" коде данной ОС. Таким образом, достигается существенное ускорение выполнения программ с API другой операционной системы.

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

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

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

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

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

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

Способы реализации совмест-ти ОС1 поддерживает кроме своих "родных" приложений приложения ОС2 и ОСЗ. Для этого есть прикладные программные среды, которые транслируют интерфейсы "чужих" API OC2 и API ОСЗ в интерфейс своей "родной" API OC1.

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

Способы реализации совмест-ти В соответствии с микроядерной архитектурой функции ОС реализуются микроядром и серверами пользовательского режима. Важно: каждая прикладная среда оформляется в виде отдельного сервера пользовательского режима и не включает базовых механизмов

Способы реализации совмест-ти Приложения, используя API, обращаются с системными вызовами к соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос, выполняет его (возможно, обращаясь для этого за помощью к базовым функциям микроядра) и отсылает приложению результат

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

Способы реализации совмест-ти очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей расширяемости микроядерных ОС; надежность и стабильность: при отказе одной из прикладных сред все остальные сохраняют работоспособность; низкая производительность микро ядерных ОС сильно сказывается на скорости работы прикладных сред, а значит, и на скорости выполнения приложений.

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

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

Системные вызовы (system calls) – интерфейс между ОС и пользовательской программой. Они создают, удаляют и используют различные объекты, главные из которых – процессы и файлы. Пользова- тельская программа запрашивает сервис у ОС, осуществляя системный вызов. Имеются библиотеки процедур, которые загружают машинные регистры определенными пара- метрами и осуществляют прерывание процессора, после чего управление передается обработчику данного вызова, входящему в ядро операционной системы.

При системном вызове задача переходит в привилегированный режим или режим ядра (kernel mode). Поэтому системные вызовы иногда еще называют программными преры- ваниями, в отличие от аппаратных прерываний, которые чаще называют просто прерываниями. В большинстве ОС системный вызов осуществляется командой прог- раммного прерывания (INT).

Прерывание (hardware interrupt) – это событие, генерируемое внешним (по отношению к процессору) устройством. Посредством аппаратных прерываний аппаратура либо информирует процессор о том, что произошло какое- либо событие, требующее немедленной реакции (например, пользователь нажал клавишу), либо сообщает о завершении асинхронной операции ввода-вывода (например, закончено чтение данных с диска в основную память).

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

Исключительная ситуация (exception) – событие, возникающее в результате попытки выполнения программой команды, которая по каким-либо причинам не может быть выполнена до конца. Примерами таких команд могут быть попытки доступа к ресурсу при отсутствии достаточных привилегий или обращения к отсутствующей странице памяти.

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

Главная задача файловой системы (ФС) – скрыть особен- ности ввода-вывода и дать прог- раммисту простую абстрактную модель файлов, независимых от устройств. Для чтения, создания, удаления, записи, открытия и закрытия файлов имеется обшир- ная категория системных вызовов (создание, удаление, открытие, закрытие, чтение и т.д.).

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

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

Совместимость на уровне исходных текстов требует наличия соответствующих компиляторов в составе программного обеспечения компьютера, на котором предполагается использовать данное приложение, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция исходных текстов программ в новые исполняемые модули.

Таким образом, совместимость на уровне исходных текстов наиболее важное значение имеет для разработчиков приложений, в распоряжении которых находятся эти исходные тексты. Для конечных же пользователей практическое значение имеет только двоичная совместимость, так как только в этом случае они могут без специальных навыков и умений использовать программный продукт, поставляемый в виде двоичного исполняемого кода, в различных операционных средах и на разных компьютерах. Для пользователя, купившего в свое время пакет программ для MS-DOS, важно, чтобы он мог запускать этот привычный ему пакет без каких-либо изменений или ограничений на своей новой машине, работающей, например, под управлением Windows NT. Множественные прикладные среды как раз и обеспечивают совместимость данной ОС с приложениями, написанными для других ОС и процессоров, на двоичном уровне, а не на уровне исходных текстов.

Каким типом совместимости – двоичной или совместимостью исходных текстов обладает ОС, зависит от многих факторов. Самый значительный из них – архитектура процессора, на котором работает ОС. Только в том случае, если процессор использует тот же набор команд (возможно, даже более расширенный, но ни в коем случае не уменьшенный) и тот же диапазон адресов, двоичная совместимость может быть достигнута довольно просто. Достаточно соблюсти несколько следующих условий:

Вызовы функций API, которые содержит приложение, должны поддерживаться данной ОС;

Внутренняя структура исполняемого файла приложения должна соответствовать структуре исполняемых файлов данной ОС.

Несравнимо сложнее достигнуть двоичной совместимости операционным системам, предназначенным для выполнения на процессорах, имеющих различающиеся архитектуры. Кроме соблюдения приведенных выше условий, необходимо также организовать эмуляцию двоичного кода. Пусть, например, требуется выполнить DOS-программу для IBM PC-совместимого компьютера на компьютере Macintosh. Компьютер Macintosh построен на основе процессора Motorola 680x0, а компьютер IBM PC – на основе процессора Intel 80x86. Процессор Motorola имеет архитектуру (систему команд, состав регистров и т.п.), отличную от архитектуры Intel, поэтому ему совершенно непонятен двоичный код DOS-программы, содержащей инструкции этого процессора. Для того, чтобы компьютер Macintosh смог интерпретировать машинные инструкции, которые ему изначально непонятны, на нем должно быть установлено специальное программное обеспечение – эмулятор .

Назначение эмулятора состоит в том, чтобы последовательно выбирать каждую двоичную инструкцию процессора Intel, программным способом дешифровать ее, чтобы определить, какие действия она задает, а затем выполнять эквивалентную подпрограмму, написанную в инструкциях процессора Motorola. Поскольку вследствие архитектурных отличий процессор Motorola не имеет в точности таких же регистров, флагов и внутреннего арифметико-логического устройства, как в процессоре Intel, он должен эмулировать (имитировать) и все эти элементы с использованием своих регистров и памяти. Состояние эмулируемых регистров и флагов после выполнения каждой инструкции должно быть точно таким же, как и в реальном процессоре Intel. Эта не очень сложная с точки зрения программной реализации задача требует для своего выполнения достаточно большого количества ресурсов компьютера. Реально на компьютере Macintosh можно запускать на выполнение только небольшие DOS-приложения, не требующие активного использования ресурсов компьютера.

Тем не менее, существует несколько другой, гораздо более эффективный выход из описанной ситуации – использование так называемых прикладных программных сред. Одной из составляющих, формирующих программную среду, является набор функций интерфейса прикладного программирования API, которым ОС обеспечивает свои приложения. Для сокращения времени выполнения чужих программ прикладные среды имитируют обращения к библиотечным функциям. Эффективность данного подхода определяется тем, что большинство современных программ работают под управлением графических интерфейсов пользователя (GUI) типа Windows, Mac или UNIX Motif, при этом приложения, как правило, наибольшую часть времени тратят на выполнение некоторых хорошо предсказуемых действий. Они непрерывно осуществляют вызовы библиотек GUI для манипулирования окнами и для других, связанных с GUI, действий. Сегодня в среднестатистической программе около 60-80% времени выполнения тратится на выполнение функций GUI и остальных библиотечных вызовов ОС. Именно эта особенность приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программы. Тщательно спроектированная программная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но написанные на “родном” коде данной ОС. Таким образом достигается существенное ускорение выполнения программ с API другой операционной системы. Для того чтобы отличить такой подход от более медленного процесса эмулирования кода по одной команде за раз, его называют трансляцией .

Например, для Windows-программы, работающей на Macintosh, при интерпретации команд процессора Intel 80x86 производительность может быть очень низкой. Но когда происходит вызов функции GUI открытия окна, модуль ОС, реализующий прикладную среду Windows, перехватывает этот вызов и направляет его на перекомпилированную для процессора Motorola 680x0 подпрограмму открытия окна. В результате на подобных участках кода скорость работы программы может достичь скорости работы на своем “родном” процессоре.

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

15. Внешние устройства ПК: диалоговые, запоминающие, телекоммуникационные.

Внешние устройства (ВУ) ПК - важнейшая составная часть любого вычислительного комплекса, достаточно сказать, что по стоимости ВУ составляют до 80 - 85 % стоимости всего ПК.

ВУ ПК обеспечивают взаимодействие машины с окружающей средой: пользователями, объектами управления и другими ЭВМ.

К внешним устройствам относятся:

внешние запоминающие устройства (ВЗУ) или внешняя память ПК;

диалоговые средства пользователя;

устройства ввода информации;

устройства вывода информации;

средства связи и телекоммуникации.

Диалоговые средства пользователя включают в свой состав видеомониторы (дисплеи) и устройства речевого ввода-вывода информации.

Видеомонитор (дисплей) - устройство для отображения вводимой и выводимой из ПК информации.

Устройства речевого ввода-вывода относятся к быстро развивающимся средствам мультимедиа.

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

Устройства речевого вывода - это различные синтезаторы звука, выполняющие преобразование цифровых кодов в буквы и слова, воспроизводимые через громкоговорители (динамики) или звуковые колонки, подсоединенные к компьютеру.

К устройствам ввода информации относятся:

клавиатура - устройство для ручного ввода числовой, текстовой и управляющей информации в ПК;

графические планшеты (дигитайзеры) - для ручного ввода графической информации, изображений путем перемещения по планшету специального указателя (пера); при перемещении пера автоматически выполняется считывание координат его местоположения и ввод этих координат в ПК;

сканеры (читающие автоматы) - для автоматического считывания с бумажных носителей и ввода в ПК машинописных текстов, графиков, рисунков, чертежей;

устройства указания (графические манипуляторы) - для ввода графической информации на экран дисплея путем управления движением курсора по экрану с последующим кодированием координат курсора и вводом их в ПК (джойстик - рычаг, “мышь”, трекбол - шар в оправе, световое перо и др.);

сенсорные экраны - для ввода отдельных элементов изображения, программ или команд с полиэкрана дисплея в ПК.

К устройствам вывода информации относятся:

принтеры - печатающие устройства для регистрации информации на бумажный носитель;

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

Устройства связи и телекоммуникации используются для связи с приборами и другими средствами автоматизации (согласователи интерфейсов, адаптеры, цифро-аналоговые и аналого-цифровые преобразователи и т.п.) и для подключения ПК к каналам связи, к другим ЭВМ и вычислительным сетям (сетевые интерфейсные платы, “стыки”, мультиплексоры передачи данных, модемы).

В частности, сетевой адаптер является внешним интерфейсом ПК и служит для подключения ее к каналу связи для обмена информацией с другими ЭВМ, для работы в составе вычислительной сети. В качестве сетевого адаптера подключения к удаленной ЭВМ через телефонную линию используется модулятор-демодулятор телефонного сигнала (модем).

Многие из названных выше устройств относятся к условно выделенной группе - средствам мультимедиа.

Мультимедиа (multimedia - многосредовостъ) средства - это комплекс аппаратных и программных средств, позволяющих человеку общаться с компьютером, используя самые разные, естественные для себя среды: звук, видео, графику, тексты, анимацию и др.

К средствам мультимедиа относятся:

устройства речевого ввода и вывода информации;

микрофоны и видеокамеры;

акустические и видеовоспроизводящие системы с усилителями, звуковыми колонками, большими видеоэкранами;

звуковые и видеоплаты, платы видеозахвата, снимающие изображение с видеомагнитофона или видеокамеры и вводящие его в ПК;

сканеры (поскольку они позволяют автоматически вводить в компьютер печатные тексты и рисунки);

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

Назначение и функции операционной системы.

Назначение ОС - организация вычислительного процесса в вычислительной системе, рациональное распределение вычислительных ресурсов между отдельными решаемыми задачами; предоставление пользователям многочисленных сервисных средств, облегчающих процесс программирования и отладки задач. Операционная система исполняет роль своеобразного интерфейса (Интерфейс - совокупность аппаратуры и программных средств, необходимых для подключения периферийных устройств к ПЭВМ) между пользователем и ВС, т.е. ОС предоставляет пользователю виртуальную ВС. Это означает, что ОС в значительной степени формирует у пользователя представление о возможностях ВС, удобстве работы с ней, ее пропускной способности. Различные ОС на одних и тех же технических средствах могут предоставить пользователю различные возможности для организации вычислительного процесса или автоматизированной обработки данных.

Функции ОС:

1) Планирование заданий. Использование процессора.

2) Обеспечение программ средствами коммуникации и синхронизации.

3) Управление памятью.

4) Управление файловой системой.

5) Управление вводом выводом.

6) Обеспечение безопасности.

Виды интерфейсов пользователя операционных систем

По типу пользовательского интерфейса различают текстовые (линейные), графические и речевые операционные системы.

Пользовательским интерфейсом называется набор приемов взаимодействия пользователя с приложением. Пользовательский интерфейс включает общение пользователя с приложением и язык общения.

Текстовые ОС

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

Первые настоящие операционные системы имели текстовый интерфейс. В настоящее время он также используется на серверах и компьютерах пользователей.

Графические ОС

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

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

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

Основу графического интерфейса пользователя составляет организованная система окон и других графических объектов, при создании которой разработчики стремятся к максимальной стандартизации всех элементов и приемов работы.

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

Речевые ОС

В случае SILK-интерфейса (от англ. speech – речь, image – образ, language – язык, knowledge – знание) – на экране по речевой команде происходит перемещение от одних поисковых образов к другим.

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

Планирование заданий.

Планировщик заданий - оснастка консоли управления (MMC), которая включает в себя дополнительные разделы справки для опытных пользователей.

Планировщик задач - программа или сервис операционной системы, которая запускает другие программы в зависимости от различных критериев, как, например:

наступление определённого времени

операционная система переходит в определённое состояние (бездействие, спящий режим и т. д.)

поступил административный запрос через пользовательский интерфейс или через инструменты удалённого администрирования.

Microsoft Windows

В версиях Windows до XP включительно данный сервис предоставлялся, в основном, для нужд конечного пользователя. Начиная с Windows Vista, данный сервис активно используется самой операционной системой для обслуживания (дефрагментация разделов жёсткого диска, тестирование компонентов, индексирование файлов и т. д.).

Cron - демон-планировщик задач в UNIX-подобных операционных системах.

Организация ввода-вывода.

Когда процессору при выполнении программы встречается команда, связанная с вводом-выводом, он выполняет ее, передавая соответствующие команды контроллеру ввода-вывода. При программируемом вводе-выводе это устройство выполняет требуемое действие, а затем устанавливает соответствующие биты в регистрах состояния ввода-вывода. Контроллер ввода-вывода больше не посылает процессору никаких сигналов, в том числе и сигналов прерываний. Таким образом, ответственность за периодическую поверку состояния модуля ввода-вывода несет процессор; он должен производить проверку до тех пор, пока операция ввода-вывода не завершится.

Backoff Processor

Очень редкая опция и не совсем однозначно трактуемая. BOFF# (Back Off) - сигнал безусловного отключения процессора от шины. По этому сигналу процессор отдает управление шиной в следующем же такте с прерыванием текущего цикла. По окончании действия сигнала "BOFF#" процессор рестартует прерванный шинный цикл. Возможные значения опции:

"Disabled" (или "No"),

"Enabled" (или "Yes").

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

Опция может называться "Backoff CPU".

Base I/O Address

Опция установки базового адреса устройства. I/O-адреса - это адреса ввода/вывода, называемые также портами системных и периферийных устройств. По сути, это "почтовые ящики", через которые программы и устройства обмениваются сообщениями, данными. Каждому адресу отведен один байт системной памяти. Начиная с 386-х систем таких адресов имеется в наличии 65536, хотя большинство из них никогда не используется.

Базовый I/O-адрес - это первый адрес из того адресного пространства, что предоставлен данному устройству. Например, большинство сетевых адаптеров использует адресный диапазон в 20h, а для COM 1 резервируется диапазон с адресами от 3F8h по 3FFh, которые используются для различных задач, например, установки скорости, четности, т.п. Весь адресный диапазон ввода/вывода - 0000-FFFFh.

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

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

Рассмотренная выше опция "Extended I/O Decode" показала нам некоторые нюансы и даже сложности декодирования адресов ввода/вывода. Опция "PCI I/O Start Address", предназначенная в общем-то для PCI-устройств, тем не менее позволяет для ISA-устройств создать дополнительную область адресов и тем самым избежать "неприятных накладок".

Branch Target Buffer

Просто редчайшая функция, скорее в смысле уникальности, а не частоты появления в различных версиях BIOS. О чем идет речь? BTB (Branch Target Buffer - буфер адресов перехода) - блок центрального процессора, отвечающий за динамическое предсказание переходов. При этом принимается во внимание, какие адреса переходов были выбраны ранее. Это важнейший узел современного процессора (см. специальную литературу).

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

CPU ADS# Delay 1T or Not

Опция установки задержки для сигнала ADS#. Несколько предваряющих слов. ADS# (Address Status) - строб адреса, вводимый инициатором обмена как индикатор действительности адреса. Сигнал действует на системной шине и может быть выходным как стороны процессора, так и со стороны чипсета. Передача адреса и адресного строба происходит одновременно, поскольку для адресного строба системная шина имеет свою выделенную линию. Понятно, что ADS# - это стандартный сигнал процессоров.

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

Вынесенная в заголовок опция имеет два значения: "1T", "No Delay".

А вот опция "Cyrix M2 ADS# delay" предложила стандартные "Enabled" и "Disabled". Опция "Latency from ADS# status" предложила числовые значения в тактах системной шины: "2T" (по умолчанию), "3T".

Необходимо понимать, что устанавливая "время задержки", мы тем самым определяем временные характеристики циклов записи. И с учетом того, что использование буфера отложенной записи ведет, как правило, к формированию небольших пакетов (двойными словами или в два DW). Поэтому установив значение "3T", мы получаем 5 системных тактов для каждого двойного слова. Арифметика тут простая. 3 такта задержки, один адресный такт и один такт на считывание данных.

CPU BIST Enable

В некоторых чипсетах, начиная с 430-й серии, нашли применение специализированные BIST-регистры. Большой нагрузки они не несли. Если система (чипсет + процессор) поддерживает функцию встроенного самотестирования (Built-In Self Test), то BIST-регистр хранит в своих разрядах команды "Start BIST" или "Completion Code". Если "система" не поддерживает BIST-функции, то установка опции в "Enabled" не даст эффекта, а в соответствующих разрядах регистра будут установлены "0".

Встроенный и, что немаловажно, полноценный механизм самотестирования BIST был реализован в процессорах Pentium III. Он обеспечивал постоянный контроль над зависаниями и сбоями в микрокоде, больших программируемых логических матрицах, а также обеспечивал тестирование кэша команд (инструкций) и кэша данных, буферов TLB (Translation Lookaside Buffer - буфера страничной переадресации) и сегментов памяти ROM. В течение 10-30 мсек (время связано с внутренней частотой ядра процессора) внутренним тестированием охватывается около двух третей всех внутренних блоков процессора. Лишь только после завершения теста процессор переходит в рабочий режим, результаты же теста фиксируются в регистре EAX.

CPU Drive Strength

Данная и не совсем ясная опция определяет интенсивность (strength), а точнее длительность действия сигналов при передаче данных от чипсета к процессору. Параметр измеряется в системных тактах. Чем выше значение параметра, тем выше длительность сигналов, а применение этой опции "BIOS Setup" может оказаться полезным для процедур "разгона" процессоров. Но не для всякой системы увеличение значений опции может привести к сохранению стабильности "разогнанного" процессора. Значения опции следующие: 0, 1, 2, 3.

Осталось добавить, что данная опция требует дополнительного уточнения.

CPU Fast String

- (быстрые операции со строками). Разрешение этого параметра ("Enabled") позволяет использовать некоторые специфические особенности архитектуры семейства процессоров Pentium Pro (Pentium II, Deschutes и т.п.), в частности, возможность кэширования операций со строками. Надо только понимать, что и в самой пользовательской программе должны быть выполнены условия для включения этого механизма. Эти условия указаны в документации на любой процессор данного семейства. Параметр рекомендуется оставлять в состоянии "Разрешено".

CPU Line Read Multiple

В данной опции речь идет о чтении процессором т.н. "full cache"-линии. Когда "cache"-линия заполнена данными, то их объем составляет 32 байта (восемь двойных слов). Поскольку линия "полная", система точно знает, как долго данные на линии будут считываться. На это системе потребуется 4 такта, после чего будет выставлен новый адрес. Поэтому системе не требуется сигнал об окончании передачи данных, и система не будет находиться в ожидании такого сигнала, будучи свободной для решения других задач. Когда опция включена ("Enabled"), процессор сможет считывать данные одновременно с нескольких "full cache"-линий. По умолчанию - "Disabled".

Опция может называться "CPU Multiple Reads".

Перечисленные ниже функции не содержат свойств множественности, но их размещение в данном месте более чем оправдано. Вот их наименования: "Allow Full Line Reads", "Full Cache Line Reads", "CPU Line Read". Каждая из них через "Disabled" или "Enabled" запрещает или разрешает использование "полных" линий чтения.

Опция "CPU-to-PCI Read-Line" имеет значения "On" и "Off", но различия на этом не заканчиваются. Опция под таким наименованием была введена и оптимизирована для работы с процессорами Intel OverDrive. Поэтому повышение эффективности использования CPU может быть достигнуто только с указанными процессорами. В противном случае опция должна быть отключена.

CPU Read Multiple Prefetch

Опция включения/отключения режима множественной предвыборки. Смысл процесса предвыборки (prefetch) заключается в том, что процессор, выбирая нужную инструкцию (например, из PCI-шины или памяти), одновременно начинает читать следующую, тем самым инициируя следующий процесс. Этому "способствует" то, что чипсет может иметь четыре линии чтения. Например, первые наборы логики с поддержкой процессоров Pentium Pro (Intel 450KX/GX, оба с кодовым названием Orion) как раз имели 4 такие линии чтения. Множественная же предвыборка позволяет выполнять одновременно несколько операций выборки инструкций, что существенно повышает быстродействие системы. По умолчанию устанавливается "Disabled".

Опция может называться и "CPU Multiple Read Prefetch".

Если же речь не идет о "множественных" операциях, то опция может называться "CPU Line Read Prefetch", "CPU Read Prefetch".

I/O Space Access

Данная опция через "Enabled" разрешает доступ ко всему пространству адресов ввода/вывода. Редкий BIOS обходится без странных опций.

Processor Number Feature

Опция для установки автоматического считывания и вывода информации о встроенном серийном номере процессора Pentium III в BIOS материнских плат, поддерживающих его установку. Для реализации такой возможности, естественно, требуется значение параметра как "Enabled". Во всех остальных случаях устанавливается значение "Disabled". Оно же устанавливается по умолчанию.

Опция может носить название "Processor S/N".

В "Phoenix BIOS" встречена аналогичная опция с названием "CPU Serial Number", а в "AMI BIOS" - "Processor Serial Number".

Зачем нужна информация о серийном номере? Скажем, для внешних программ. Один из примеров - считывание информации о процессоре при работе в Интернет. Естественно, что при этом нарушаются конфиденциальность и права пользователя. В свое время эта проблема достаточно бурно обсуждалась.

Файловая система ОС.

Файловая система – это часть ОС, включающая:

1) Совокупность всех файлов на диске.

2) Наборы структур данных, используемых для управления файлами.

3) Комплекс системных программных средств, реализующих различные операции над файлами.

Функции ФС:

1) Именование файла.

2) Программный интерфейс для приложений.

3) Отображение логической модели файловой системы на физическую организацию хранения данных.

4) Устойчивость файловой системы к сбоям питания.

Типы файлов:

1) Обычные файлы – это файлы, содержащие информацию произвольного характера, которую заносит в них пользователь, или образующуюся в результате работы системных и пользовательских программ.

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

3) Специальные файлы – это файлы, ассоциированные с устройствами ввода вывода системы, которые используются для механизма доступа к отдельным файлам и внешним устройствам.

Современные ФС поддерживают другие типы файлов: символьные связи; именованные конвейеры; отображаемые в память файлы и др.

Microsoft все еще поставляет свою сетевую ОС LAN Manager. Большое количество независимых поставщиков имеют лицензии на эту ОС и поддерживают свои собственные версии LAN Manager как часть своих сетевых продуктов. В число этих компаний входят такие известные фирмы как AT&T и Hewlett-Packard. LAN Manager требует установки на файл-сервере операционной системы OS/2, рабочие станции могут работать под DOS, Windows или OS/2. OS/2 - это операционная система, реализующая истинную многозадачность, работающая в защищенном режиме микропроцессоров x86 и выше. LAN Manager использует 32-х битную версию файловой системы OS/2, называемую HPFS, которая оптимизирована для работы на файл-сервере за счет кэширования каталогов и данных. LAN Manager - это первая сетевая ОС, разработанная для поддержки среды клиент-сервер. Ключевыми компонентами LAN Manager являются редиректор и сервер. Особенно эффективно LAN Manager поддерживает архитектуру клиент-сервер для систем управления базами данных. LAN Manager разрешает рабочим станциям под OS/2 поддерживать сетевой сервис по технологии "равный-с-равным". Это означает, что рабочая станция может выполнять функции сервера баз данных, принт-сервера или коммуникационного сервера. Ограничением является то, что только один пользователь, кроме владельца этой рабочей станции, имеет доступ к такому одноранговому сервису.

Для работы в небольшой сети фирма Microsoft предлагает компактную, не требующую значительных аппаратных или программных затрат операционную систему Windows for Workgroups. Эта операционная система позволяет организовать сеть по схеме "равный-с-равным", при этом нет необходимости приобретать специальный компьютер для работы в качестве сетевого сервера. Эта операционная система особенно подходит для решения сетевых задач в коллективах, члены которого ранее широко использовали Windows 3.1. В Windows for Workgroups достигнута высокая производительность сетевой обработки за счет того, что все сетевые драйверы являются 32-х разрядными виртуальными драйверами.

Компьютеры с изображением семицветного яблочка уже давно перестали быть диковинкой. Их теперь можно встретить практически везде – в издательствах, рекламных агентствах, дизайн - студиях. Высокую популярность компьютеров Apple среди верстальщиков и дизайнеров можно объяснить множеством причин, но высокое качество, удобный интерфейс и надежность работы техники этой марки отмечают все. К новому тысячелетию компания подходит уверенно занимающей достойное место среди крупнейших производителей компьютеров. Новые разработки на базе процессоров PowerPC 750 (G3) уже завоевали заслуженную популярность, и Apple готовит к выпуску еще более мощные модели компьютеров, оснащенные надежной и удобной операционной системой MacOS. Одна из последних моделей – iMac – стала просто хитом сезона, побив все рекорды по продажам. Отличительные особенности этого компьютера – высокая вычислительная мощность, простота установки и настройки, элегантный дизайн при невысокой стоимости.

Исходная философия для разработки Unix состоит в распределении функциональности по нескольким маленьким частям, программам.

Изначально это было требованием, исходящим из аппаратуры, на которой Unix изначально работал. По какой-то странной причине, получившаяся операционная система оказалось весьма полезной на другой аппаратуре. Вы можете относительно просто достичь новой функциональности и новых возможностей, объединяя маленькие части (программы) новым способом. Если появляются новые утилиты (так и происходит), Вы можете встроить его в Ваш старый инструментарий. К сожалению, в наше время программы для Unix становятся все большими, и включают в себя все больше возможностей, но некоторая гибкость и возможность взаимодействия по-прежнему остается. К примеру, когда я писал этот документ, я активно использовал эти программы; fvwm – для управления "окнами", emacs для редактирования текста, LaTeX - для форматирования его, xdvi для просмотра отформатированного текста, dvips - для подготовки его к печати, и, наконец, lpr для печати. Если я завтра найду новую лучшую программу просмотра dvi, я смогу использовать ее вместо старой, не изменяя остальных установок.

Сетевые ОС.

Сетевая ОС – предназначенная для обработки, хранения и передачи данных в информационной сети.

Задачи:

Разделение ресурсов;

Администрирование сети.

Делятся на:

Сетевые ОС для серверов;

Сетевые ОС для пользователей.

Сетевая ОС составляет основу любой вычислительной сети.

Под сетевой ОС:

В широком смысле: понимается совокупность ОС отдельных компьютеров, взаимосвязанных с целью обмена сообщениями и разделения ресурсов по единым правилам – протоколам. Эти протоколы обеспечивают основные функции сети: адресацию объектов; функционирование служб; обеспечение безопасности данных; управление сетью.

В узком смысле: сетевая ОС – это ОС отдельного компьютера, обеспечивающая ему возможность работать в сети.

Делятся на классы:

Одноранговые (ставится одна и та же ОС);

Двухранговые (которые чаще называют сетями с выделенными серверами).

Тупиковые ситуации.

Тупик (клинч, дедлок) - ситуация, которая никогда не разрешится, т.е. процесс ждет ресурса, но он ему не будет выделен.

ОС в состоянии тупика ("зависание") - когда несколько процессов находятся в состоянии тупика.

Простая тупиковая ситуация в ОС:

Пусть имеются 2 процесса A и B, которым перед началом работы предоставлены ресурсы P1 и P2 соответственно. В какой-то момент времени процессу A понадобился P2, а процессу B - P1, но они их не получат, т.к. они удерживаются предыдущими процессами => наступила простая тупиковая ситуация в ОС.

Правила предотвращения тупиков в ОС:

Прежде чем процесс начнет свою работу, ему должны быть предоставлены все требуемые ресурсы.

В том случае, если во время работы ему понадобился дополнительный ресурс, ему необходимо возвратить все ранее выделенные ресурсы ОС и затем запросить все требуемые ресурсы с этим дополнительным ресурсом.

Бесконечное откладывание процесса.

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

В некоторых ОС данная ситуация предотвращается благодаря увеличению приоритетности ("старению" процесса) для того, чтобы ему был предоставлен требуемый ресурс, после чего приоритет понижается до прежнего уровня.

Управление ресурсами.

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

планирование ресурса - то есть определение, кому, когда, а для делимых ресурсов и в каком количестве, необходимо выделить данный ресурс;

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

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

Типы операционных систем. Понятие операционной системы.

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

Операционные системы пакетной обработки.
Операционная система пакетной обработки – это система, которая обрабатывает пакет заданий, т. е. несколько заданий, подготовленных одним или разными пользователями. Взаимодействие между пользователем и его заданием во время обработки невозможно или крайне ограничено. Под управлением операционной системы пакетной обработки ЭВМ может функционировать в однопрограммном и мультипрограммном режимах.
Операционные системы разделения времени.

Такие системы обеспечивают одновременное обслуживание многих пользователей, позволяя каждому пользователю взаимодействовать со своим заданием в режиме диалога. Эффект одновременного обслуживания достигается разделением процессорного времени и других ресурсов между несколькими вычислительными процессами, которые соответствуют отдельным заданиям пользователей. Операционная система предоставляет ЭВМ каждому вычислительному процессу в течение небольшого интервала времени; если вычислительный процесс не завершился к концу очередного интервала, он прерывается и помещается в очередь ожидания, уступая ЭВМ другому вычислительному процессу. ЭВМ в этих системах функционирует в мультипрограммном режиме.
Операционная система разделения времени может применяться не только для обслуживания пользователей, но и для управления технологическим оборудованием. В этом случае “пользователями” являются отдельные блоки управления исполнительными устройствами, входящими в состав технологического оборудования: каждый блок взаимодействует с определённым вычислительным процессом в течение интервала времени, достаточного для передачи управляющих воздействий на исполнительное устройство или приёма информации от датчиков.
Операционные системы реального времени.
Данные системы гарантируют оперативное выполнение запросов в течение заданного интервала времени. Запросы могут поступать от пользователей или от внешних по отношению к ЭВМ устройств, с которыми системы связаны каналами передачи данных. При этом скорость вычислительных процессов в ЭВМ должна быть согласована со скоростью процессов, протекающих вне ЭВМ, т. е. согласована с ходом реального времени. Эти системы организуют управление вычислительными процессами таким образом, чтобы время ответа на запрос не превышало заданных значений. Необходимое время ответа определяется свойствами объектов (пользователей, внешних устройств), обслуживаемых системой. Операционные системы реального времени используются в информационно– поисковых системах и системах управления технологическим оборудованием. ЭВМ в таких системах функционирует чаще в многозадачном режиме.
Диалоговые операционные системы.
Данные операционные системы получили широкое распространение в персональных ЭВМ. Эти системы обеспечивают удобную форму диалога с пользователем через дисплей при вводе и выполнении команд. Для выполнения часто используемых последовательностей команд, т. е. заданий, диалоговая операционная система предоставляет возможность пакетной обработки. Под управлением диалоговой ОС ЭВМ обычно функционирует в однопрограммном режиме.