Виды совместимости

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

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

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

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

Совместимость

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

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

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

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

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

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

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

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

Соответствие стандартам POSIX также является средством обеспечения совместимости программных и пользовательских интерфейсов. Во второй половине 80-х правительственные агентства США начали разрабатывать POSIX как стандарты на поставляемое оборудование при заключении правительственных контрактов в компьютерной области. POSIX - это "интерфейс переносимой ОС, базирующейся на UNIX". POSIX - собрание международных стандартов интерфейсов ОС в стиле UNIX. Использование стандарта POSIX (IEEE стандарт 1003.1 - 1988) позволяет создавать программы стиле UNIX, которые могут легко переноситься из одной системы в другую.

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

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

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

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

Вид возможной совместимости зависит от многих факторов. Самый главный из них– архитектура процессора. Если процессор использует тот же набор команд (возможно с добавлениями, как в случае 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) "лучше знает", какие страницы следует выгружать. Например, она способна определить, что создавший страницу процесс завершил работу и страница больше не нужна. МВМ, который работает на аппаратном уровне, "не знает" об этом и может продолжать подкачку страницы, расточительно расходуя ресурсы.

Типы операционных систем

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

Для IBM-совместимых персональных компьютеров разработано несколько различных семейств операционных систем: MS DOS, Windows, OS/2, Unix и некоторые другие. Наиболее простой операционной системой считается однопользовательская и однопрограммная операционная система MS DOS. Системы Windows, OS/2 и Unix более сложны из-за их многопрограммности, а также включенных в них сетевых возможностей. Первая версия операционной системы MS DOS была разработана в 1981-1982-х годах. Как было отмечено ранее, за годы существования MS DOS разработано большое число версий и модификаций этой системы. Ее последней версией была версия MS DOS 6.22. Затем была разработана значительно более мощная и удобная в использовании операционная система Windows, для которой к моменту написания пособия были выпущены версии Windows 95, Windows 98 и Windows ME. Для указанных версий операционных систем часто используют одно общее обозначение Windows 9.x . Название Windows имеют и сетевые операционные системы Windows NT и Windows 2000, Windows XP. Заметим, что MS DOS оказалась как бы «поглощенной», включенной в состав операционных систем Windows 9.x.

Интерфейс пользователя

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

ВНИМАНИЕ

Совокупность стандартных соглашений, средств, методов и правил взаимодействия пользователя с той или иной программной системой называется пользовательским интерфейсом (или интерфейсом пользователя) системы.

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

07-04-02 С:\>

показано, что текущая дата - это 7 апреля 2002 года, а текущим дисковым устройством является устройство С:. Для запроса на выполнение какой-либо функции операционной системы пользователь должен ввести с клавиатуры справа от символа > указание, команду операционной системе. Команда операционной системы представляет собой записанный по специальным правилам текст, обработав который операционная система «поймет», что именно требует от нее пользователь, и выполнит запрошенное пользователем действие.

ВНИМАНИЕ

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

Например, узнать версию установленной на компьютере операционной системы можно с помощью следующей команды:

07-04-02 C:\>ver

Напоминаем, что команда находится справа от знака приглашения >. В данном случае - это слово «ver» (от version - версия). Если на машине установлена операционная система MS DOS версии 6.22, то выполнение этой команды приведет к выводу на экран дисплея ответа

MS DOS Version 6.22

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

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

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

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

ВНИМАНИЕ

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

Еще раз подчеркнем, что оболочки не являются независимыми программами, они могут функционировать только совместно с операционной системой, для которой они разработаны. Для MS DOS было разработано несколько различных оболочек - Qdos, Dos Shell, Norton Commander, Volkov Commander, Windows 3.x, среди которых наибольшей популярностью пользовались оболочки Norton Commander (сокращенно - NC), Volkov Commander (VC) и Windows 3.x. Различные оболочки используют разный интерфейс пользователя. Так, оболочки Norton Commander и Volkov Commander используют табличный интерфейс, отличительной особенностью которого является указание или выбор команды или ее элементов в готовой таблице, а не ввод текста команды. Подробнее особенности табличного интерфейса пользователя рассматриваются в седьмой главе данного пособия, которая посвящена изучению оболочки Norton Commander. Оболочки семейства Windows 3.x, в которое, входят Windows 3.0, Windows 3.10, Windows 3.11, отличаются графическим интерфейсом. Особенностью этого интерфейса является широкое использование условных, легко запоминающихся значков, закрепленных за теми или иными действиями, программами, устройствами и т. д. Пользователю достаточно определенным образом указать на нужный значок, и операционная система выполнит связанное с ним действие. Графический интерфейс оказался настолько удачным, что стал основным для операционных систем семейства Windows 9.x, которые пришли на смену операционной системе MS DOS и ее оболочкам Windows 3.x.

ВНИМАНИЕ

Windows 3.x - семейство оболочек для операционной системы MS DOS, a Windows 9.x - семейство самостоятельных операционных систем. Подробнее графический интерфейс пользователя рассматривается в главе пособия, которая посвящена изучению интерфейса операционной системы Windows.

Файл

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

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

ВНИМАНИЕ

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

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

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

ВНИМАНИЕ

Итак, файл - это либо документ, либо программа в электронном виде, хранящиеся на одном из внешних устройств - магнитном или оптическом диске, магнитной ленте и т. д.

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

Действия с файлами

Над файлами могут быть выполнены следующие основные операции: создание, открытие, закрытие, изменение (редактирование), копирование, перемещение, переименование и уничтожение.

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

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

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

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

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

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

§ Переименование файла означает закрепление за файлом нового названия, при этом старое его название безвозвратно теряется.

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

Атрибуты файла

Каждый файл обладает рядом характерных свойств - атрибутов. Важнейшими атрибутами файла являются: название, расширение, длина, время и дата создания.

Название файла. Название, или имя файла, точно так же как и имя человека, название документа, книги, служит для того, чтобы иметь возможность отличить один файл от другого, указать на нужный файл. В различных операционных системах названия файлов формируются по разным правилам. Например, в операционной системе MS DOS название файла представляет из себя последовательность букв латинского алфавита, цифр и некоторых специальных знаков (~, _, -, $, &, @, %, ^ ,!, (.), {. },#,","). Название может содержать от одного до восьми символов и выбирается произвольным образом. Однако желательно подбирать названия файлам так, чтобы пользователь мог легко вспомнить, что именно хранится в этом файле. Например, файл, содержащий отчет за 4-й квартал, можно назвать otchet4, файл с ведомостью на зарплату - vedzarpl, а файл с каким-либо рисунком целесообразно назвать picture. Обратите внимание! В операционной системе MS DOS название файла не может содержать пробелов, букв русского алфавита и точек. Кроме того, оно не может содержать более восьми символов. Вообще говоря, это достаточно существенные ограничения. Например, файл, содержащий отчет предприятия за 4-й квартал, который мы назвали otchet4, желательно было бы назвать «Отчет за 4-й квартал», в крайнем случае «Otchet za 4 kvartal», применив так называемую транслитерацию , когда слова одного языка записываются буквами другого. В операционных системах Unix и Windows 9.x сняты ограничения на длину названия, использование пробелов и точек в названии. А в операционной системе Windows 9.x, кроме того, в названии можно использовать русские буквы. Таким образом, файл в Unix может иметь название «Otchet za 4 kvartal», а в Windows 9.x допускается и название «Отчет за 4-й квартал».

Расширение файла. Кроме названия каждый файл может иметь или не иметь расширение. Расширение используется для того, чтобы определенным образом охарактеризовать содержимое файла. Например, расширения doc и txt указывают на то, что файл содержит какой-либо документ или текст, а расширение bmp имеет файл, содержащий изображение в формате битовой карты. Расширение, если оно есть, отделяется от названия файла точкой. В операционной системе MS DOS расширение может содержать от одного до трех символов, например, otchet4.doc, vedzarpl.txt, picture.bmp, а в системах Unix и Windows 9.x допускается более трех символов. Если расширения нет, то точка в названии файла не ставится. Название вместе с расширением называютполным именем файла.

Если файл создается с помощью какой-либо программной системы, то, как правило, он автоматически получает стандартное для данной системы расширение, и пользователю достаточно выбрать или указать только название. Впоследствии по стандартным расширениям программная система опознает «свои» файлы. В операционных системах предусмотрен целый ряд стандартных расширений. В таблице 6.1 приведены некоторые часто встречающиеся расширения MS DOS и Windows 9.x.

Таблица 6. 1. Некоторые расширения MS DOS и Windows 9.x

Файлы с расширением.соm (common - общий) и . ехе (execute - выполнение) содержат программы на машинном языке. Эти файлы часто называют программными файлами. Различия между .com- файлами и . ехе -файлами касаются их внутренней организации. На способах обращения с файлами эти различия никак не сказываются. Файлы срасширением.bat (batch - пачка) содержат произвольные последовательности команд операционной системы. Такие файлы принято называть командными файлами. Использованный в табл. 6.1 термин «выполняемый файл» объединяет понятия «программный файл» и «командный файл». Другими словами, «выполняемый файл» означает, что файл содержит либо программу на машинном языке, которая может быть непосредственно выполнена процессором компьютера (файлы с расширениями.ехе и.com), либо последовательность команд операционной системы (файл с расширением.bat), которые тоже выполняются, но только путем обращения к соответствующим программам и средствам операционной системы.

При внесении в файл каких-либо изменений целесообразно сохранить предыдущий вариант файла с тем, чтобы при необходимости отменить сделанные изменения и вернуться к первоначальному варианту. Поэтому многие программные системы после внесения в файл изменений автоматически формируют резервный файл, в котором находится первоначальный вариант содержимого файла. Резервный файл имеет то же самое имя, что и исходный файл, но любое его расширение заменяется стандартным для резервных файлов расширением.bak (back - назад, обратно). Например, если изменения были внесены в файл otchet4.doc, то самый последний вариант файла будет иметь то же самое название otchet4.doc, и при этом автоматически будет создан резервный файл otchet4.bak, в котором сохранится старый вариант содержимого файла. Попутно заметим, что если изменения вносятся в большое число файлов, то на диске постепенно скапливается много резервных файлов, поэтому время от времени приходится выполнять «уборку» на диске - уничтожать ставшие уже ненужными или устаревшие резервные файлы.

В целом ряде случаев программная документация поставляется покупателю не на бумаге, а в виде текстовых файлов на дисковых носителях. Обычно таким файлам приписывают расширение.doc (documet - документ). Кроме того, некоторые текстовые редакторы автоматически дают «своим» файлам (то есть файлам, подготовленным с их помощью) это же расширение.doc. Расширение.txt (text - текст) - еще один распространенный вариант расширений, закрепляемых за файлами, которые содержат разнообразные тексты. А файлам с числовыми данными удобно давать расширение.dat (data - данные).

Ранее упоминалось о том, что достаточно часто в программах предусматривается встроенная справочная система, обращаться к которой можно во время выполнения программы. Такая система, как правило, содержит всю необходимую справочную информацию в файлах «помощи» с расширением.hip (help - помощь).

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

Иногда программным системам приходится сохранять промежуточную, рабочую информацию на дисковых устройствах. Для этого формируются специальные файлы, которые достаточно часто получают расширение.tmp (temporary - временный). Как правило, временные файлы после окончания работы программы автоматически уничтожаются. Но бывают ситуации, когда такие файлы все-таки остаются на диске, и тогда по указанному расширению их легко опознать и при необходимости уничтожить.

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

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

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

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

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

Атрибут системный обычно включен только у основных файлов операционной системы. У всех остальных файлов атрибут системный, как правило, выключен.

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

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

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

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

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

Групповое имя образуется с помощью символов * и?. Символ *, встретившийся в групповом имени, трактуется операционной системой как «любая последовательность любых символов названия». То есть этому символу соответствует любое количество любых символов названия. Так, групповому имени а* соответствуют любые названия, начинающиеся с буквы «а»: а1, azbuka, a2z4. Символ? воспринимается ОС как любой одиночный символ, то есть ему соответствует ровно один произвольный символ имени. Например, шаблону otchet7.doc соответствуют любые имена с расширением.doc, в названии которых за отрезком названия otchet следует ровно один символ, например otchet1.doc, otchet4.doc, otchet%.doc, otchet*.doc и т. д. Рассмотрим еще несколько примеров:

§ ??.txt - файлы с любыми двухбуквенными именами и расширением.txt;

§ *.bak - файлы с любыми именами и расширением.bak;

§ progl .* - файлы с названием progl и любым расширением;

§ *.* - файлы с любыми названиями и любыми расширениями.

Каталог

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

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

ВНИМАНИЕ

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

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

Таблица 6.2. Фрагмент каталога

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

Вообще говоря, выше изложена несколько упрощенная схема работы файловой системы при поиске и считывании файла с дискового устройства. На самом деле аналогия между каталогом и оглавлением в книге только частичная из-за того, что кластеры выделяются файлу на диске не сплошным массивом, а вразброс, в то время как в книге все страницы главы размещаются подряд. Представьте себе, что одна из глав книги занимает страницы 5,15,16, 17, 31, 123,124 вместо того, чтобы занимать страницы 5,6,7,8,9,10,11 подряд. Такое несплошное выделение кластеров файлам организовано для того, чтобы оптимизировать использование свободного пространства диска при многочисленных уничтожениях и записях файлов.

Для того чтобы все-таки знать, какие именно кластеры и в каком порядке выделены для хранения файла, в файловой системе предусмотрена другая таблица, имеющаяся на любом дисковом устройстве. Эта таблица называется FAT (File Allocation Table - таблица размещения файла). Каталог содержит только номер начального кластера файла. А таблица FAT - номера всех остальных занятых файлом кластеров. В подавляющем большинстве случаев пользователю не приходится работать с таблицей FAT, так как она заполняется при записи файла и анализируется при его считывании автоматически. Каталог и одна или две таблицы FAT (для обеспечения большей надежности таблица FAT, как правило, дублируется) автоматически создаются в процессе форматирования на любом дисковом носителе. Созданный автоматически каталог принято называть корневым. Корневой каталог вместе с таблицами FAT и начальным (нулевым, стартовым) сектором диска образуют его системную область.

Рассмотренная выше простая структура каталога, в котором все файлы образуют один общий список, может обеспечить удовлетворительную работу операционной системы только в случае небольших объемов диска и ограничивает общее число файлов, которые могут быть записаны на диск. Так, на гибких дисках объемом 1,44 Мбайт корневой каталог может содержать сведения не более чем о 224 файлах. А когда объем диска становится достаточно большим и, следовательно, на диске могут быть записаны сотни и тысячи файлов, простая структура каталога приводит к существенному замедлению процесса поиска файла на диске или переполнению каталога. Представьте себе список хранящихся в шкафу документов из нескольких тысяч названий. Совершенно очевидно, что работать с таким списком очень неудобно. В реальной жизни документы в шкафах сгруппированы по каким-либо признакам в папки. При этом в описи содержимого шкафа указываются не отдельные документы, а папки. Аналогичным образом каталог в операционных системах имеет более сложную структуру. Произвольные группы файлов каталога могут объединяться и образовывать подкаталоги . В некоторых операционных системах подкаталоги называются папками . Фактически подкаталоги, как и корневой каталог, являются таблицами, размещаемыми на диске и содержащими информацию об отнесенных к подкаталогу файлах. В отличие от корневого каталога, положение подкаталогов на диске не привязано к системной области. Поэтому размеры подкаталогов могут быть достаточно произвольными, что позволяет снять ограничение на количество указываемых в подкаталоге файлов.

Подкаталоги создаются пользователями по своему усмотрению. Каждый подкаталог имеет собственное имя (обычно без расширения), которое подбирается по тем же правилам, что и имя файла. Группировка и включение файлов в подкаталог могут производиться по любым критериям. Например, в отдельный подкаталог с названием WINDOWS целесообразно собрать все файлы, имеющие отношение к операционной системе. Точно так же целесообразно сгруппировать в отдельный подкаталог все файлы, необходимые для работы какого-либо текстового редактора или игровой программы. Если на машине по очереди работают несколько пользователей, то имеет смысл организовать отдельные подкаталоги для каждого пользователя, скажем, user1, user2, user3,... (user - пользователь), сгруппировав в подкаталоге userl файлы первого пользователя, в подкаталоге user2 - второго и т. д. Кроме снятия количественных ограничений, связанных с использованием одного каталога, это создает определенную упорядоченность при хранении информации на дисках.

Все подкаталоги, находящиеся в корневом каталоге, относят к первому уровню. На рисунке 6.2 подкаталогами первого уровня являются подкаталоги Windows, userl, Program files. Корневой каталог по отношению к включенным в него подкаталогам первого уровня называют родительским , а подкаталоги по отношению к корневому считаютсядочерними или вложенным и. Каждый подкаталог первого уровня в свою очередь устроен точно так же, как и корневой. То есть в файлах, отнесенных к подкаталогу, можно выделить какие-либо подгруппы, образовав из них новые подкаталоги. Таким образом, кроме обычных файлов любой подкаталог может содержать и файлы, сгруппированные в подкаталоги. Эти подкаталоги относятся к следующему уровню. Например, владелец подкаталога userl может сгруппировать внутри этого подкаталога все подготовленные им отчеты в отдельный подкаталог с названием otcheti, а, скажем, файлы, содержащие информацию о деловых контактах, собрать в подкаталоге kontakti (рис. 6.2). Подкаталоги первого уровня по отношению к включенным в них подкаталогам второго уровня считаются родительскими. Подкаталоги второго уровня выступают в роли дочерних по отношению к подкаталогам первого уровня. Отсюда следует, что понятия «родительский» и «дочерний» подкаталог являются относительными. Подкаталоги первого уровня, с одной стороны, считаются дочерними для корневого каталога, а с другой - родительскими для подкаталогов второго уровня. Подкаталоги второго уровня могут иметь сформированные внутри них подкаталоги третьего уровня, а те в свою очередь - четвертого уровня и т. д. Глубина вложения подкаталогов не ограничена. Такую структуру каталога можно представлять себе как оглавление книги, в котором введена определенная структуризация - выделены части, в частях выделены главы, главы разбиты на параграфы, параграфы - на разделы и т. д. Каждую из этих структурных единиц можно рассматривать как подкаталог.

Глядя на рис. 6.2, можно заметить, что каталог по своей структуре напоминает дерево. Корневой каталог можно сопоставить со стволом дерева, подкаталоги играют роль ветвей, а файлы являются листьями этого «дерева». Такая структура каталога называется древовидной или иерархической. Собственно говоря, названия «корневой» и «древовидная» происходят от указанной аналогии. А название «иерархическая» произошло от понятия «иерархия». Иерархией называется расположение частей или элементов целого в порядке от высшего к низшему. Иерархические структуры имеют очень широкое распространение.

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

Рис. 6.2. Древовидная структура каталога

ПРИМЕЧАНИЕ

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

Путь к файлу

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

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

Цепочка названий подкаталогов, по которым нужно пройти, начиная от корневого каталога и заканчивая подкаталогом, содержащим файл, называется путем или маршрутом к файлу.

ПРИМЕЧАНИЕ

В операционных системах MS DOS и Windows корневой каталог в пути указывается символом \. Этим же символом отделяются друг от друга названия подкаталогов в цепочке, а также имя файла от названия подкаталога, в котором он находится.

Таким образом, для файлов, находящихся в корневом каталоге (рис. 6.2), путем является только обозначение корневого каталога \, и файлы указываются следующим образом:

\ command.com , \config.sys , \autoexec.bat

Файл из подкаталога userl имеет путь \user1:

\user1\picture.bmp

А путь к файлам из подкаталога kontakti должен включать названия обоих подкаталогов - \user1\kontakti:

\user1\kontakti\ivanov.doc, \user1\kontakti\postavki.txt

Пути могут указываться не только к файлам, но и подкаталогам. Так, для подкаталога kontakti путем является \user1.

Спецификация файла

В состав компьютера, как правило, входит несколько различных дисковых устройств, поэтому для однозначного определения файла необходимо указать, на каком именно устройстве он находится. Это можно сделать, задавая название дискового устройства, содержащего файл. Название устройства принято размещать перед путем к файлу. Указание файла, содержащее: 1) название устройства, 2) путь к файлу, 3) полное имя файла, называется полной спецификацией файла . Заметим, что в общем случае спецификацией называется перечисление всех отличительных особенностей. Если, например, каталог, структура которого приведена на рис. 6.2, находится на винчестерском диске С:, то полная спецификация файла postavki.txt имеет вид:

C:\user1\kontakti\postavki.txt

а если этот каталог находится на гибком диске, то есть на дисковом устройстве А:, то спецификация запишется следующим образом:

A:\user1\kontakti\postavki.txt

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

Контрольные вопросы

1. Что называется операционной системой?

2. Перечислите основные функции операционных систем.

3. Какой диск называется системным? Какие диски могут быть системными?

4. Опишите порядок включения и выключения персонального компьютера.

5. Что такое начальная загрузка операционной системы? Как она происходит?

6. Укажите возможную причину прекращения выполнения загрузки.

7. Что такое зависание? Что нужно делать при зависании?

8. Опишите возможные способы выполнения перезагрузки.

9. Какие бывают операционные системы?

10. Что называется интерфейсом пользователя?

11. Опишите основные особенности текстового, табличного и графического интерфейсов.

12. Какую роль играет приглашение к вводу?

13. Что такое команда операционной системы?

14. Что такое утилита?

15. Что называется оболочкой? Какие оболочки вам известны?

16. Что такое файл?

17. Что может находиться в файле?

18. Какие операции могут выполняться над файлами?

19. Что такое атрибут файла? Какие атрибуты являются основными?

20. Как задается название файла?

21. Какую роль играет расширение и как оно задается?

22. Дайте определение понятиям «программный файл», «командный файл», «выполняемый файл», «резервный файл», «файл помощи», «драйвер». Укажите их расширения.

23. Для чего нужно и как образуется групповое имя?

24. Что такое кластер?

25. Что такое каталог и какую информацию он содержит?

26. Как осуществляется поиск файла на дисковом носителе?

27. Какую структуру имеет каталог?

28. Дайте определение понятиям «корневой каталог», «подкаталог», «подкаталог первого уровня», «подкаталог второго уровня», «родительский каталог», «дочерний подкаталог».

29. Что такое путь к файлу и почему его нужно указывать?

30. Что такое спецификация файла?

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

Виды совместимости Существует 2 принципиально отличающихся вида совместимости, которые не следует путать Совместимость на двоичном на уровне исходных текстов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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