Назад в раздел
Операционная система OS/2.
ОПЕРАЦИОННАЯ СИСТЕМА/2
М.С.КОГАН, Ф.Л.РОУСОН
Аннотация.
Создание операционной системы/2 (OS/2) является результатом по-
пытки согласовать требования фирмы IBM и ее клиентов к новой
операционной системе для различных моделей PS 2 с учетом совмес-
тимости с огромным количеством существующих ДОС-приложений. Раз-
работка OS/2 представляла собой серьезную проблему удовлетворе-
ния этих требований и эффективного использования аппаратных
средств. В этой статье обсуждаются характеристики системы.
Операционная система/2 (OS/2) является новой операционной
системой фирмы IBM для созданного ею семейства персональных
компьютеров PS/2 на базе микропроцессоров Intel 80286 и 80386
Ввиду того, что новые операционные системы являются дорогостоя-
щими как в разработке, так и при установке и адаптации , в пос-
леднее время утвердилась тенденция совершенствования существую-
щих систем вместо создания новых. OS/2 представляет собой по-
пытку реализации новой системы, которая удовлетворяла бы нужды
растущего рынка и одновременно сократила затраты на разработку
как для IBM, так и для ее клиентов.
Основной целью разработки OS/2 является создание преемника
для одного из наиболее удачных программных продуктов для персо-
нальных компьютеров, дисковой операционной системой (DOS), ко-
торая полностью поддерживает аппаратные ресурсы процессора
80286, без отказа от совместимости с ДОС.
OS/2 устраняет множество ограничений, присущих ДОС, но
позволяет использовать большинство пркладных программ, работаю-
щих в ДОС. В таблице 1 проводится сравнение основных характе-
ристик для ДОС и OS/2.
Состав OS/2
OS/2 работает на моделях 50,60 и 80 Персональной системы/2
фирмы IBM. Она также работает на персональных компьютерах АТ и
ХТ модели 286. Поскольку IBM аннонсировала две версии стандартной
редакции для OS/2, в этой статье обсуждаются общие характерис-
тики для обеих версий OS/2.
Характеристики системы
OS/2 должна обеспечивать множество системных функций (см.
таблицу 2). Ряд свойств является характерным для существующих
операционных систем и, где это возможно, OS/2 реализует их стан-
дартным образом, используя технику, описанную для более ранних
систем. Тем не менее, два аспекта побудили разработчиков OS/2
использовать новые методы во многих областях для удовлетворения
запросов, предьявляемых к системе. Первая группа требований свя-
зана по своей природе с архитектурой:
-OS/2 должна обеспечивать возможность использования огром-
ного множества существующих приложений ДОС;
-OS/2, также как и ДОС, является однопользовательской сис-
темой, которая создана для PS. Она ориентирована на обеспечение
интерактивного режима, и не занимает слишком много места в памя-
ти или на диске. Эти требования совместно с архитектурными осо-
бенностями процессора 80286 привели к разработке структуры сис-
темы, характерной для OS/2;
-OS/2 также должна эффективно использовать большой обьем
физической памяти, доступной для процессоров 80286 и 80386.
Ввиду архитектурных особенностей процессора 80286 (описан-
ных ниже), эти требования находятся в противоречии друг с
другом. Разрешение этого противоречия в работающей системе явля-
ется значительным достижением системы OS/2. Другим набором тре-
бований являются требования, часто встречающиеся при созданиии
малых систем:
-OS/2 должна обеспечивать полный набор свойств операционной
системы, которые присущи большим микро- и миникомпьютерным сис-
темам.
-OS/2 также должна работать, не расходуя слишком много ре-
сурсов для того чтобы ее можно было устанавливать на РС. Как и
всегда при таких требованиях, результатом является компромисc
между сложностью, трудоемкостью реализации свойств и простотой
при меньшей стоимости их обеспечения.
Требования к архитектуре при создании OS/2
Для того чтобы понять конфликт между двумя группами требо-
ваний к архитектуре OS/2, важно понимать архитектуру аппаратной
части семейства процессоров фирмы Интел и окружения, которое ис-
пользуется для ДОС-приложений.
Архитектура процессора 80286
Использование большого обьема памяти процессоров Интел
80286 и 80386 делают необходимым применение их более развитых и
несовместимых особенностей. Ввиду того, что OS/2 является опера-
ционной системой для 80286, которая рассматривает процессор
80386 также, как если бы он был 80286 процессором, будет исполь-
зоваться понятие 80286 для ссылки на общие характеристики обоих
типов процессоров. Для получения дальнейшей информации о процес-
соре Интел 80286 см.ссылки 1 и 2.
Процессор 80286 расширяет адресное пространство процессора
8086/8088, который используется во многих персональных компьюте-
рах, путем добавления нового режима работы, который называется
защитным режимом. 80286 может работать также в режиме 8086/8088,
который называется для 80286 реальным режимом. 80286 может пе-
реключаться между реальным и защитным режимами под управлением
программы. Переключение с реального на защитный режим относи-
тельно просто и может осуществляться крайне быстро. Несмотря на
то, что точный механизм изменяется при переходе от одной машины
к другой, переход от защитного режима к реальному режиму на
80286 (но не на 80386) всегда требует сброса процессора. Эта
операция относительно медленная и осуществляется аппаратно на
устройстве, внешнем по отношению к процессору.
Подобно процессору 8086/8088, процессор 80286 делит память
на группы адресов, которые называются сегментами. Сегменты огра-
ничены по длине величиной 64 К (кроме 80386), так как процессор
может работать со смещениями 16 бит. Хотя 80386 работает с
32-разрядными смещениями, OS/2 не использует это свойство. В
дальнейшем 32-разрядный режим для 80386 обсуждаться не будет.
В защитном режиме сегменты описываются структурами данных,
которые называются дескрипторами. Дескриптор сегмента задает на-
чальный адрес сегмента в физической памяти, его длину, режим ис-
пользования и атрибуты защиты. Дескрипторы, которые может под-
держивать и обрабатывать операционная система и которые необхо-
димы для реализации ее стратегии управления памятью, собраны в
таблицы. Существует единая глобальная таблица дескрипторов - ГТД
(Global Descriptor Table-GDT), а также множество локальных таб-
лиц дескрипторов (Local Descriptor Table-LDT). Эти таблицы дос-
тупны в любой момент времени: GDTR и LDTR являются аппаратными
регистрами, которые указывают на GDT и текущую LDT соответствен-
но. Адрессация производится косвенно через GDT или текущую LDT.
16-разрядные значения в сегментных регистрах не являются более
адресами, которыми они были в реальном режиме, а становятся ин-
дексами, которые называются селекторами. Селекторы осуществляют
индексацию дескрипторов в GDT и LDT. Процессор вычисляет адрес
ячейки, к которой осуществляется доступ, путем суммирования ба-
зового адреса сегмента и значения смещения. Результат получается
24-битовым, что позволяет адресовать до 16 Мб.
На рисунке 1 показан процесс генерации адреса процессором
80286 в реальном и защитном режиме.
Процессоры 80286 и 80386 обеспечивают четыре уровня защиты,
называемые Protection Rings . Уровни пронумерованы, причем наи-
больший приоритет имеет уровень 0, а наименьший - уровень 3.
Приоритет связан с сегментами, и уровень приоритета сегмента
хранится в его дескрипторе. Текущий уровень приоритета машины
является уровнем приоритета текущего выполняемого програмного
сегмента.
Некоторые команды, относящиеся к состоянию процессора, оп-
ределяются как приоритетные и могут выполнятся только на уровне
0. Другие команды, относящиеся к операциям ввода/вывода, класси-
фицируются как доверительные и требуют приоритетного доступа,
который называется IOPL. Для того чтобы использовать эти коман-
ды, текущий уровень приоритета должен быть по крайней мере таким
же, как минимальный приоритет, глобально установленный для этих
доверительных команд. См. страницу 10-5 [1] для получения списка
этих команд.
Процессор обеспечивает строгое правило перехода с одного
уровня приоритета на уровень с большим приоритетом, связываемое
с селектором. Когда программа вызывает селектор, используя ко-
манду FAR CALL, и селектор указывает на более приоритетный прог-
раммный сегмент, процессор автоматически переключает уровень
приоритета. При переключении уровня приоритета процессор автома-
тически копирует параметры, специфицированные при вызове, в
стек, используемый на новом уровне приоритета.
Существует аппаратно реализованная модель задач, встроенная
в 80286 и использующая Task State Segment - TSS (cегмент состоя-
ния задачи), для описания состояния задачи и стеков, которые она
использует. Для того чтобы приоритетный переход в защитном режи-
ме происходил корректно, необходим TSS. Аппаратный регистр, на-
зываемый TR, хранит адрес текущего TSS.
Interrupt Descriptor Table - IDT (таблица описателей преры-
ваний) используется для векторизации обработчиков этих прерыва-
ний. Эта таблица размещается не так, как таблица векторов преры-
ваний в реальном режиме, расположенная в младших адресах памяти,
и содержит дескрипторы для специальных типов селекторов. Выбор
этой таблицы осуществляется специальным регистром IDTR, который
позволяет ей располагаться в произвольном месте физической памя-
ти снимая ограничение на расположение только в младших адресах,
как это имело место в таблице векторов прерывания в реальном ре-
жиме.
Программное окружение ДОС
Среда ДОС очень тесно связано с деталями аппаратного обес-
печения, имеющегося в оригинальной IBM PC на основе процессора
8088. Она полностью открыта, и прикладной программист всегда
имеет полную свободу управления машиной. Несмотря на то, что это
значительное преимущество во многих случаях, трудно бывает осу-
ществить переход к более развитой архитектуре и реализовать сов-
местное выполнение нескольких прикладных программ на одной и той
же системе.
Наиболее важные архитектурные особенности программной среды
ДОС собраны в таблице 3.
Таблица 3. Программная среда ДОС
Выполнение в реальном режиме на 8088/8086/80286/80386.
Модификация значений регистров сегментации.
Адресное пространство ограничено величиной 1 Мб.
Использует интерфейс прерывания как ДОС, так и BIOS.
Прикладные программы выполняются с самым высоким приорите-
том, используя все возможности машины.
Многие прикладные программы снабжены специальными свойствами, такими как
прерывание и фиксация в памяти.
Прикладные программы могут заменять друг друга или ДОС.
Реализация этой открытой среды в системе, которая имеет
традиционную систему управления ресурсами, является значительной
технической проблемой.
ДОС и программы ДОС работают только в реальном режиме. Нес-
мотря на то, что существует прерывание BIOS, которое переводит
машину в защитный режим, его использование очень ограничено и
имеет специализированный характер: например, нет системного обс-
луживания ДОС, доступного в защитном режиме. BIOS сам по себе
текже подразумевает операции реального режима.
Программы ДОС, написанные на языке ассемблера, в общем слу-
чае используют сегментные регистры для базирования и выполняют
вычисления над значениями, содержащимися в них. Аналогичные дей-
ствия в защитном режиме обычно приводят к нарушению защиты. Сег-
ментные регистры не могут использоваться в качестве базовых ре-
гистров в программах защитного режима, поскольку их значения яв-
ляются индексами, а не адресами.
Программная среда ДОС выделяет для адресации программы об-
ласть максимум 640 Кб. Несмотря на то, что процессор в реальном
режиме может адресовать до 1 Мб, значения адресов от 640 К до 1
М зарезервированы для ПЗУ BIOS и видеобуферов. Многие из интер-
фейсов, которые в основном используются ДОС-программами, поддер-
живаются не в ДОС, а в BIOS. ДОС-программы написаны для комбина-
ции интерфесов ДОС и BIOS.
Программное окружение ДОС предоставляет программисту полный
доступ к возможностям аппаратуры. Программа может выполнять инс-
трукции В/В низкого уровня, запрещать и разрешать прерывания, и
выполнять собственную обработку прерываний. Буфер памяти, отве-
денный для экрана дисплея, непосредственно доступен, и программы
могут сохранять экран путем запоминания информации в соответст-
вующем месте памяти.
Векторы прерывания, установленные ДОС или BIOS, могут изме-
няться прикладными программами. Этот метод обычно называется об-
ход (hooking) прерываний. Изменение обычно производится простым
запоминанием указателя на программу, к которой прикладная прог-
рамма хочет передать управление в соответствующем месте таблицы
векторов прерывания в нижней области памяти.
В программах, работающих под управлением ДОС, которая пред-
полагает, что в данный момент времени выполняется одна програм-
ма, нет защиты. Несмотря на то, что существует множество схем
для фактического совместного выполнения нескольких программ, та-
ких как прерывание и фиксация в памяти, отсутствует механизм,
реализованный в системе или аппаратном обеспечении, который
обеспечивал бы какой-либо вид защиты для программ при выполнении
их в реальном режиме. Не существует также системного механизма
для управления одновременным выполнением нескольких программ.
Хотя это и может быть преимуществом при структурировании группы
программ, которые тесно взаимосвязаны и взаимодействуют, отсутс-
твие подобного механизма является существенным недостатком, ког-
да программы из различных источников объединяются вместе.
В прошлом было предложено и реализовано множество альтерна-
тив для режима защиты. Эти альтернативы, конечно, увеличивали
адаптивность ДОС, но все эти решения были ограничены двумя важ-
ными факторами. Во-первых, они являются внешними решениями, от-
личными от архитектуры процессора и обычной тенденции разработки
для систем, основывающихся на семействе процессоров фирмы Интел.
Они требуют специальной аппаратуры, обычно располагаемой на шине
или плате памяти, которая увеличивает общую стоимость машины.
Во-вторых, все они являются схемами отображения. Несмотря на
увеличение объема физической памяти, которая может присоединять-
ся к машине, они не увеличивают фактически адресуемую память,
которую имеет программа. Программист должен разделять команды и
данные на секции, которые не должны адресоваться вместе и затем
должен правильно управлять аппаратурой для обеспечения коррект-
ного отображения каждой секции в любой момент времени. Эта про-
цедура является сложной, в особенности при использовании языков
высокого уровня. По этим соображениям OS/2 использует защитный
режим для расширения адресуемого пространства прикладных прог-
рамм
Структура системы
Ввиду того, что OS/2 выполняет прикладные программы реаль-
ного режима в реальном режиме, а прикладные программы защитного
режима в защитном режиме, а также поскольку в защитном режиме
архитектура процессора 80286 требует использования нескольких
уровней защиты для осуществления ограничения по приоритетам,
структура системы OS/2 организована таким образом, чтобы поддер-
живать эти свойства.
Использование режимов
Многие части системы OS/2 разработаны для выполнения как
в реальном, так и в защитном режиме; сюда относятся:
- управление устройствами
- управление прерываниями
- переключение режимов
- переключение контекста.
Программа, которая может выполняться в обоих режимах, назы-
вается двухрежимной. Драйверы устройств, поставляемые совместно
с OS/2, также являются двухрежимными. Ядро же системы OS/2,
включая управление виртуальной памятью и файловую систему, реа-
лизовано в виде только защитных кодов. Системное обслуживание
низкого уровня позволяет определить текущий режим машины и убе-
дится в том, что она работает в нужном режиме.
В OS/2 сделана попытка минимизировать количество переключе-
ний режимов, которая реализована на критических путях, таких как
обслуживание устройств и прерываний, ввиду того, что переключе-
ние режимов происходит относительно медленно, в особенности при
переходе от защитного режима к реальному.
Это привело к решению использовать двухрежимный код для
драйверов устройств. Проводя сравнение, можно отметить, что обс-
луживание, такое как распределение сегментов, которое использу-
ется только в защитном режиме, написано как программа только за-
щитного режима. Хотя оно и используется в программах реального
режима, файловая система реализована как программа только защит-
ного режима для сокращения объема памяти до величины менее 640
Кб, (одно из требований системы OS/2). Когда файловая система
используется программами реального режима, имеется два переклю-
чателя режимов, один от реального режима к защитному при его вы-
зове и один - из защитного режима к реальному режиму при возвра-
те.
Слой уровня защиты
OS/2 использует три из четырех уровней защиты процессора
80286. На рис.2 показано использование уровней защиты в системе.
Программыа операционной системы уровня 0 состоят из двух
категорий. Основные обсуживающие программы системы собраны вмес-
те для образования программы, которая называется ядро (kernel).
Программы, которые используются для обслуживания устройств, яв-
ляются индивидуально загружаемыми и называются драйверами уст-
ройств. Как ядро, так и драйверы устройств выполняются на уровне
0, так как они требуют максимального уровня системного приорите-
та для обработки прерывания.
Подсистемы представляют собой обслуживающие и дополнитель-
ные программы, которые не требуют аппаратного приоритета. Как
прикладные программы, так и подсистемы выполняются на уровне 3.
Сегменты уровня 2 используются подсистемами и прикладными прог-
раммами для кодов, которые выполняют команды, приоритетного вво-
да/вывода. Это позволяет программам выполнять операции В/В, ко-
торые не требуют обслуживания прерываний.
Ядро реализовано как единый монитор с одним входом и одним
выходом. Ядро системы OS/2 не реализует приоритетного прерывания
обслуживания; если программа выполняется в ядре, то она не будет
прервана для выполнения другой программы. Тем не менее, програм-
ма может быть прервана, находясь в ядре, с тем чтобы программа
прерывания могла выполниться и осуществить функцию, которую не-
обходимо выполнить за относительно малый промежуток времени, та-
кую как очистка буфера В/В. Такая структура ядра обеспечивает
простоту реализации и приемлемые характеристики для однопользо-
вательских интерактивных систем типа OS/2, которые, однако, не
являются системами реального времени. При подобном подходе су-
щественным является то, что длительность интервала времени, за-
нимаемого при каждом системном вызове в ядре, поддерживается на
минимальном уровне.
Реализация большой памяти
В защитном режиме OS/2 может использовать полное адресное
пространство процессора 80286. Память является ключевым систем-
ным ресурсом которая загружается и управляется системой очень
тщательно. На рис.3 показано распределение памяти для OS/2.
Рис.3.
Вершина
Программы OS/2
1 Мб Старшие сегменты OS/2
ПЗУ и видеобуферы
640 К Оболочка ДОС
Младшие системные сегменты
0 б
Программы в OS/2 выполняются как процессы. В частности,
каждый процесс имеет свою адресную оболочку. Разные аспекты про-
цесса рассмотрены в разделе мультипрограммирования и многозадач-
ности. Ядро состоит из одного программного сегмента и одного
сегмента данных в младших адресах памяти ниже 640 Кб и несколь-
ких програмных сегментов и сегментов данных в старших адресах
памяти выше 1 Мб. Сегменты в нижней части памяти образуют ком-
пакт. Это значит , что эти сегманты могут адресоваться одним и
тем же значением в сегментном регистре в реальном и защитном ре-
жиме. Компакт (tiling) осуществляется путем преобразования вир-
туального адреса сегмента, расположенного в нижней части адрес-
ного пространства в физический адрес и занесения этого значения
в поле базового адреса дескриптора, селектор которого соответст-
вует значению сегмента исходного виртуального адреса реального
режима. Компакт позволяет двухрежимным программам корректно ра-
ботать независимо от текущего режима машины. Рис.4 иллюстрирует
понятие компакта. Драйверы устройств и часть ядра, расположенная
в нижней области памяти, входят в компакт.
Программы реального режима выполняются в области ниже 640
Кб, так что они имеют ту же адресную оболочку, что и в ДОС. Раз-
деление ядра на сегменты в старшей и в младшей области памяти
сделано для максимального увеличения памяти, доступной ДОС-прог-
рамммам, выполняющимся в реальном режиме.
Рис.4.
Х16 Индекс
----------------- Сегментный регистр-----------------
l Реальный режим Защитный режим l
l _______________________ _______l_____
l l l l Дескриптор l
l l l l____________l
l l l l
l_____________l l______________l
l_______________________l
Управление виртуальной памятью
Несмотря на то, что каждый отдельный сегмент остается огра-
ниченным по размеру величиной 64 Кб, программы защитного режима
могут использовать несколько сегментов; таким образом, они могут
иметь адресное пространство, которое намного больше 640 К. Кроме
того, OS/2 располагает способами комплексирования групп сегмен-
тов в единые блоки, что удобно для хранения больших структур
данных.
Поскольку в многозадачных системах ресурсы памяти индивиду-
альных процессов должны быть защищены от вмешательства со сторо-
ны других процессов и так как системные ресурсы сами по себе
должны быть защищены от вмешательства со стороны программ поль-
зователя, таблицы дескрипторов доступны только для приоритета
уровня 0. Только ядро должно управлять сегментами, определяя их
базовый адрес в физической памяти и их длину. Эта функция реали-
зуется с помощью Virtual Memory Manager (супервизора виртуальной
памяти), который использует средства Physical Memory Manager
(супервизора физической памяти) для распределения и освобождения
физической памяти при необходимости и для гарантии, что память
может быть восстановлена супервизором виртуальной памяти.
Несмотря на то, что сегменты занимаются и освобождаются
процессами, управление виртуальной памятью обслуживает единую
системную таблицу, которая называется операционной таблицей. Эта
таблица описывает все объекты в памяти, находящиеся в текущий
момент в системе. Объекты отображаются на сегменты и селекторы с
помощью операционной таблицы.
Ввиду того, что минимальным объектом памяти, управляемым
ядром, является сегмент, OS/2 располагает подсистемой для управ-
ления памятью внутри сегмента.
Распределение памяти
OS/2 поддерживает распределение памяти на сегменты програм-
мы и сегменты данных. Система позволяет работать как с именован-
ными, так и неименованными сегментами. Имена разделяемых сегмен-
тов данных имеют ту же форму, что и имена файлов. Процессы полу-
чают доступ к именованным разделяемым сегментам, используя их
имена в специальных системных вызовах. OS/2 допускает разделение
программныхх сегментов приложений и подсистем, а также глобаль-
ных сегментов данных подсистем. Вообще, вся концепция подсистемы
OS/2 построена на понятии разделения памяти: процессы почти
всегда разделяют сегменты с другими процессами. В этом состоит
отличие от систем типа UNIX, которые обычно разделяют только ре-
ентерабельные программы между процессами. Описание модели про-
цесса в UNIX и последние дополнения, выполненные в ней для под-
держки распределения памяти между процессами, содержатся в рабо-
те Бэтча [4].
В GDT (глобальной таблице дескрипторов) сегменты, конечно,
автоматически разделяются всеми процессами , благодаря архитек-
туре процессора 80286. Однако за исключением ядра, большинство
дескрипторов сегментов программы и данных расположены в LDT
(таблице локальных дескрипторов). Для поддержки разделения сег-
ментов и для корректной передачи адресов между процессами при
разделении программ и данных, супервизор виртуальной памяти
обеспечивает то, что если слот выделен разделяемому сегменту в
LDT в одном процессе, то этот слот резервируется в любой другой
LDT системы. В результате слот будет доступен, если любой другой
процесс будет запрашивать доступ к этому сегменту. Каждый селек-
тор в LDT классифицируется либо как общий, либо как личный. Об-
щие селекторы управляются как разделенные ресурсы внутри таблиц
LDT всех процессов. Разделяемые объекты программы и данные под-
системы, отображаются в общие селекторы. Личные селекторы ис-
пользуются для сегментов, выделенных процессом, владеющим LDT.
Счетчик входов и владельцы отслеживаются супервизором виртуаль-
ной памяти в операционной таблице.
Несмотря на то, что такая организация требует дополнитель-
ных затрат ввиду необходимости сканирования всех таблиц LDT при
каждом выделении и очистке разделенных сегментов, и на увеличе-
ние размера LDT в системе, она обеспечивает правильное распреде-
ление адресов между процессами. До тех пор, пока размер LDT и
количество процессов является небольшим, затраты оправданы.
Управление таблицами дескрипторов в OS/2
GDT размещается статически при образовании ядра OS/2. Она
содержит дескрипторы глобальных системных сегментов, в соответс-
твии с показанным на рис.3 распределением памяти. Сегменты прог-
рамм и данных резидентных и инсталируемых драйверов устройств
также отображаются в GDT. Кроме того, селекторы вызовов для вы-
зываемых интерфейсов, раелизуемых ядром, также располагаются в
GDT.
Псевдоимена структур данных, специфичных для процессора,
также находятся в GDT. Для самой GDT имеется псевдоимя, содержа-
щее один дескриптор текущей LDT. Там также имеется псевдоимя LDT
для того, чтобы к ней можно было ссылаться как к данным. Другие
псевдоимена включают псевдоимя LDT, дескриптор для текущей об-
ласти данных задачи (PTDA), дескриптор TSS для системного TSS,
дескриптор для селектора компакта области данных ПЗУ, начиная с
40:0 и дескриптор для стека прерываний. PDTA, которая является
управляющим блоком, используемым в OS/2 для описания процесса,
подробнее будет описана в следующем разделе.
Другие входы GDT могут динамически распределяться ядром и
драйверами устройств.
Для каждого процесса в системе строится своя LDT. Тот факт,
что в GDT существует только один дескриптор LDT и один дескрип-
тор PTDA, предполагает, что эти дескрипторы вновь отображаются
на переключатель контекста OS/2. Области PDTA и таблицы LDT наз-
начаются при запуске программы, и таблица LDT может динамически
увеличиваться.
Управление физической памятью
OS/2 управляет памятью таким образом, что доступным мо-
жет быть больший объем памяти, чем фактически имеет машина.
Это свойство, известное как превышение памяти, дает пользова-
телю большую свободу, поскольку система может выполнять прог-
раммы, которые больше по объему, чем размер физической памя-
ти, имеющийся в машине. Сегменты, которые активно не исполь-
зуются, могут перекачиваться на жесткий диск. Система восста-
навливает их, когда в этом возникает необходимость. Так как
все области памяти, используемые сегментом, должны быть неп-
рерывными, OS/2 перемещает в основной памяти сегменты таким
образом, чтобы максимизировать объем свободной физической па-
мяти. Это размещение называется компрессия или перемещение
сегментов. Программные сегменты не перекачиваются, поскольку
они могут перезагружаться с исходных дисков. OS/2 использует
подкачку сегментов вместо разбивки на страницы, так как про-
цессор 80286 не имеет аппаратуры для страничного механизма,
но имеет аппаратные средства, необходимые для осуществления
сегментации.
Области в младших адресах физической памяти, которые ис-
пользуются для запуска ДОС-программ и самой OS/2, не участвуют в
перемещении или подкачке. Кроме этого, система или прикладная
программа могут временно фиксировать сегмент в памяти с тем,
чтобы гарантировать наличие буфера В/В в физической памяти до
тех пор, пока операция В/В не завершится.
Если для удовлетворения запроса нет достаточного количества
непрерывной физической памяти, супервизор физической памяти пы-
тается сжать память для создания достаточного пространства. Если
в результате сжатия не удается создать необходимое свободное
пространство, то супервизор выполняет операции фонового плана
для перекачки достаточного количества сегментов из физической
памяти, чтобы дать возможность завершиться исходному запросу.
Механизм перекачки использует файловую систему для перекачки
данных из физической памяти и в нее.
Ввиду того, что перекачка и сжатие влияют на производитель-
ность системы в целом, пользователь может сконфигурировать сис-
тему так, чтобы эти функции не выполнялись.
Супервизор физической памяти отслеживает использование фи-
зической памяти. Каждый блок физической памяти, который называ-
ется ареной, имеет свой заголовок . Все заголовки арен связаны
вместе в двухсвязный список. Супервизор обслуживает два дополни-
тельных списка, один для свободных арен и один для занятых. Сре-
да ДОС имеет одну арену, которая не входит в список супервизора.
Управление памятью в ДОС осуществляется сервисными программами
ДОС, которые выполняются в этой арене.
Мультипрограммирование и многозадачность
Система мультипрограммирования позволяет организовать од-
новременное выполнение нескольких прикладных программ. Многоза-
дачная система распределяет время процессора между несколькими
программами, давая каждой из них малый период времени процессо-
ра. OS/2 реализует оба аспекта - мультипрограммирование и много-
задачность.
Сеансы. OS/2 реализует мультипрограммирование путем поддер-
жки до 16 одновременно выполняемых сеансов. Ввиду того, что сис-
тема использует четыре из этих сеансов для (а) среды ДОС, (b) для
пользовательских оболочек, (с) скрытых сеансов открепленных про-
цессов и (d) для обработчика тяжелых сбоев, пользователь может
запускать до 12 одновременно выполняемых сеансов.
OS/2 обслуживает видеобуфер таким образом, что дисплей мо-
жет использоваться несколькими прикладными программами в парал-
лельном режиме. Каждая сеанс имеет один логический дисплей, кла-
виатуру и мышь.
Процессы и цепочки малых программных модулей (нити)
Слово "задача" всегда относится к аппаратно заданному сос-
тоянию задачи. Несмотря на то, что OS/2 выполняет несколько па-
раллельных задач, она не использует понятие задачи так, как это
определено в архитектуре процессора 80286. Вместо этого, OS/2
оперирует процессами и нитями.
Процесс является обладателем ресурсов: нитей, номеров фай-
лов, семафоров, очередей и карты памяти, которая описывается его
собственной LDT. Система OS/2 обслуживает область данных задачи
(PDTA) для каждого процесса в системе. PDTA каждого процесса по-
мещается в отдельный сегмент, который адресуется через GDT.
Когда процесс создается, то одна нить всегда выделяется для
выполнения программы, специфицированной в системном вызове соз-
дания процесса. Следовательно, процесс всегда имеет по крайней
мере одну нить. Нить является единицей диспетчеризации в систе-
ме. Концептуально она представляет собой стек и набор регистров,
в которых размещается программа. Процесс может иметь множество
нитей, разделяющих его ресурсы. Система обслуживает блок управ-
ления нитью (TCB) для каждой нити в системе. TBC содержит группу
регистров, стек ядра нити и информацию для управления ресурсами
нити и действий по В/В. На рис.5 показан вид сегмента PDTA для
процесса с несколькими нитями.
Когда процесс создается, система назначает сегмент для
PDTA, включая пространство для различных TCB. Если последующие
запросы на создание нитей исчерпывают размер сегмента, то его
размер переопределяется для добавления большего числа TСВ.
Механизм диспетчеризации
Этот механизм в OS/2 является программным в отличие от ап-
паратного механизма, определенного в архитектуре процессора
80286. Поскольку единицей диспетчеризации является нить, система
переключает PDTA, когда она переходит на нить, которая не нахо-
дится в текущем процессе. Необходимо также изменить содержимое
полей стека TSS для отображения корректных стеков каждой нити
системы. При операциях переключения процессов физический адрес
поля в дескрипторе LDT в GDT изменяется для указания новой теку-
щей LDT, а регистр LDTR перезагружается для переключения LDT.
Операция переключения процесса в основном завершается, когда ап-
паратный указатель стека (SS:SP) перезагружается новым значением
для стека ядра и PDTA. Переключение нитей представляет собой то-
же самое, что и переключение процессов, за исключение того, что
PDTA и LDT остаются неизменными, в то время как стековые поля в
TSS корректируются.
Решение использовать программный механизм диспетчеризации
основано на двух основных предпосылках. Во-первых, так как сис-
тема иногда работает в реальном режиме, то аппаратный механизм
диспетчеризации не всегда доступен. Даже когда идет работа в ре-
альном режиме, система должна отслеживать текущую выполняемую
программу. Во-вторых, механизм диспетчеризации является очень
тонким. Он сохраняет в памяти и восстанавливает только те объек-
ты, которые абсолютно необходимы для правильного выделения и ос-
вобождения ресурсов. В результате на выполнение программного пе-
реключения контекста в OS/2 тратится меньшее число машинных цик-
лов по сравнению с тем количеством, которое потребовалось бы для
переключения TSS в процессоре 80286.
В OS/2 реализован режим квантования времени. Нить вы-
полняется за относительно короткий промежуток времени перед тем,
как супервизор получит управление. Он может выяснить, что сущес-
твуют другая нить, которая должна выполняться. В этом случае вы-
полнение текущей нити приостанавливается, ее состояние сохраня-
ется и происходит диспетчеризация другой нити. Планировщик OS/2
реализует многоуровневую схему приоритета с динамическим измене-
нием приоритета и круговой параллельной диспетчеризацией внутри
одного уровня приоритета. Динамическое изменение приоритета ме-
няет приоритет нитей на основе их текущей активности. Это сдела-
но прежде всего для повышения совершенства системы и для обеспе-
чения незамедлительных ответов системы на интерактивные действия
пользователя. Параллельная круговая диспетчеризация внутри уров-
ня приоритета обеспечивает то, что если существует более одной
нити на одном и том же уровне приоритета, то все нити этого
уровня имеют равные шансы на выполнение.
OS/2 реализует сложное обслуживание. Эта реализация позво-
ляет управлять взаимодействием программ, выполняемых в системе,
с тем, чтобы сделать всю систему максимально интерактивной. Зна-
чения по умолчанию, встроенные в систему, позволяют ей хорошо
выполнять стандартные наборы прикладных программ, а встроенный
програмный интерфейс позволяет прикладным программистам управ-
лять поведением своих прикладных программ. Этот механизм служит
для поддержки диалогов с пользователями.
Синхронизация процессов и коммуникация
Ввиду того, что OS/2 содержит множество процессов и нитей,
в ней текже существует метод координации их действий и внутрен-
ней коммуникацийи; таким образом, пользователь может реализовы-
вать прикладные программы, используя более чем одну нить или
процесс.
Семафоры
Так как прикладные программы, работающие в OS/2, могут
иметь несколько нитей, важно, чтобы они защищали свои ресурсы.
Общие области данных, разделенные несколькими нитями в процессе,
должны быть последовательно доступны. OS/2 позволяет прикладной
программе сделать это путем использования семафоров. Семафор -
это структура данных, которая относится к одной нити в данный
момент времени. Если две различных нити программы нуждаются в
доступе к структуре данных, то каждая из них должна вначале зап-
росить семафор. OS/2 предоставляет доступ к семафору одной из
нитей и блокирует другие до тех пор, пока он не освободится.
OS/2 имеет два типа семафоров: системные семафоры и семафо-
ры прямого доступа в память. Предоставление системных семафоров
отслеживается системой, и системные семафоры могут использовать-
ся для определения последовательности выполнения нитей в разных
процессах. Семафоры оперативной памяти являются очень простой и
очень действенной формой семафоров, которая может использоваться
для переключения между различными нитями одного процесса. Когда
нить, получившая доступ к системному семафору, прерывается, сис-
тема фиксирует все текущие запросы семафоров. Тем не менее, на
прикладную программу, использующую семафоры оперативной памяти,
возлагается задача проконтролировать, что среди запрашивающих
доступ нитей нет самоблокировки.
Сигналы
Сигналы используются для того, чтобы сообщить процессам
OS/2 о некотором внешнем событии. Процесс может определить прог-
раммы обработчиков сигналов, которые вызываются в тех случаях,
когда процесс принимает различные сигналы. Среди сигналов, опре-
деленных для процессов в OS/2, имеются такие, которые фиксируют
нажатие клавиш, соответствующим функции CTRL-Break и что процесс
должен прерваться. Если нет обработчика некоторого сигнала, то в
случае его фиксации система осуществляет текущую операцию, обыч-
но игнорируя сигнал или прерывая процесс. Если есть обработчик
сигнала, определенный до его поступлания, то он вызывается под
управлением начальной нити процесса. Система располагает функци-
ей, которая позволяет процессу блокировать и разрешать прием
сигналов.
Конвейеры
OS/2 располагает как конвейерами, так и очередями для ком-
муникации между процессами. Конвейер позволяет двум процессам
общаться, используя системные вызовы В/В файлов. Первый процесс
записывает данные в конвейер, а второй считывает данные из конве-
йера. Тем не менее, информация фактически никогда не записывает-
ся во внешний файл, а сохраняется в сегменте в основной памяти.
Очереди
Системные вызовы обслуживания очередей реализуются подсис-
темой уровня 3, которая использует разделенную память, подрасп-
ределение и семафоры для задания порядка обслуживания. Эти вызо-
вы реализуют модель почтового ящика, в которой считывать имеет
право только один владелец, но каждая нить может осуществлять
запись в него. Владелец может просматривать элементы в очереди,
удалять элементы из нее, очищать очередь и удалять ее.
Динамическое присоединение обслуживающих программ
Программы OS/2 используют команды удаленного вызова для ге-
нерации обслуживающих программ из системы. Ссылки, генерируемые
этими вызовами, определяются в момент загрузки самой программы
либо ее сегментов. Это отсроченное определение ссылок называется
динамическим присоединением. Загрузочный формат модуля OS/2
представляет собой расширение формата загрузочного модуля ДОС.
Он был расширен для поддержки необходимого окружения для свопин-
га сегментов с динамическим присоединением. Динамическое присое-
динение уменьшает объем памяти для программ в OS/2, одновременно
делая возможным перемещения подсистем и обслуживающих программ
без необходимости повторного редактирования адресных ссылок к
прикладным программам.
Механизм динамического присоединения
В защитном режиме не важно, используется ли селектор сег-
мента кода или селектор логики вызова. Если запрос относится к
системному обслуживанию, которое требует привелегированного пе-
рехода, используется логика вызова. Если присоединение происхо-
дит с обслуживающей программой, имеющейся в подсистеме, которая
выполняется на личном уровне, то вызов направляется непосредст-
венно к селектору сегмента программы.
Структура прикладной программы
EXE-модуль в OS/2 содержит записи EXPORT и IMPORT. Когда
программа импортирует ссылки дальних вызовов, линкер не пытается
разрешить дальний вызов для функции, которая должна быть импор-
тирована, и вместо этого создает запись IMPORT в EXE-заголовке .
EXPORT обычно можно найти в подсистемах; если подсистема экспор-
тировала общую программу с дальним вызовом (public far routine)
линкер создает запись EXPORT в EXE-заголовке для указания того,
что этот EXE-модуль содержит кандидатов для назначенного динами-
ческого линкования.
Структура подсистемы
Подсистемы также называются динамическими пакетами, либо
динамически подсоединяемыми библиотеками и располагаются в
EXE-файле с расширением .DLL. Подсистемы загружаются в память,
когда на них ссылается прикладная программа в период загрузки
или выполнения. Подсистема не имеет стекового сегмента, но может
содержать программные сегменты уровней 3 и 2. Модули подсистемы
также могут содержать сегменты данных, которые классифицируются
как местные данные или разделенные глобальные данные. Сегмент
местных данных назначается один на запрашивающий объект или на
пакет, тогда как сегмент разделенных данных обеспечивает назна-
чение сегмента данных один раз, когда пекет загружается. Ввиду
того, что подсистемы отображаются в общие селекторы в LDT, эти
слоты резервируются во всех LDT, так что подсистема появляется в
том же самом месте в адресном пространстве процесса, без учета
того, какой процесс ее использует. Глобальные данные для подсис-
темы организуются загрузчиком путем назначения общих селекторов
в LDT для сегментов и последующего отображения этих селекторов в
отдельную копию сегмента данных, которая предоставляется модулем
подсистемы. Этот разделенный сегмент появляется в одном и том же
месте во всех LDT. Местные данные, наоборот, предоставляются
загрузчиком, назначая один сегмент на LDT для процесса, который
ссылается на подсистему, и отображая тот же общий селектор в
каждую LDT в отдельную копию сегмента данных подсистемы, когда к
подсистеме происходит первое обращение со стороны его нити.
Когда происходит загрузка подсистемы, дополнительная прог-
рамма инициализации, встроенная в пакет, будет выполнятся таким
образом, что подсистема готова взаимодействовать с пользователя-
ми. Программа инициализации может быть локальной или глобальной,
в зависимости от того, нужно ли записывающему устройству подсис-
темы вызывать программу инициализации один раз (глобально), либо
на основе ссылок для каждого процесса( локально).
Динамическое присоединение во время загрузки
OS/2 реализует динамическое присоединение, используя таб-
личную структуру данных модуля, которая состоит из входов в таб-
лицу модуля (MTE's). Обращение к каждому МТЕ осуществляется че-
рез обработчик модуля, который является указателем на МТЕ. Все
МТЕ в системе содержатся в списке присоединения модуля. Каждый
МТЕ содержит резидентную информацию EXE-заголовка, выделяемую из
загрузочного модуля, включая экспортируемые точки входа. Таблицы
модуля назначаются как перемещаемые сегменты.
Когда загрузчик OS/2 производит попытку загрузить EXE-файл,
он создает для модуля МТЕ, если таковой уже не существует. Обра-
ботчик МТЕ сохраняется в PDTA запрашивающего процесса. Затем
производится сканирование МТЕ для выявления IMPORT-записей. Каж-
дая запись IMPORT сообщает загрузчику, какой модуль содержит
код, на который осуществляется ссылка. IMPORT могут осуществ-
ляться по имени либо по порядковому номеру.
Поименованные IMPORT ссылаются на код подсистемы. Если это
кодовый сегмент уровня 3, загрузчик фиксирует программу для вы-
зова селектора сегмента кода уровня 3. Если это сегмент кода
уровня 2, то загрузчик фиксирует программу для вызова логическо-
го блока вызовов уровня 3, который указывает на сегмент кода
уровня 2. Если необходимо, загрузчик загружает любую подсистему,
на которую ссылается программа. Загрузка подсистем аналогична
загрузке прикладных программ.
Для IMPORT по порядковому номеру используются ссылки к яд-
ру, и ссылка дальнего вызова фиксируется в логическом блоке
уровня 3, который содержит селектор сегмента кода уровня 0 и
смещение для объекта назначения. Порядковые номера позволяют
осуществить более быстрое динамическое линкование вызовов ядра,
ввиду того, что поиск MTE для ядра не требуется. Когда система
осуществляет динамическое линкование из уровня 3 на уровень 2,
она назначает стек уровня 2. Если имеются переходы с уровня 3 на
уровень 0 через вызов ДОС, стек уровня 0 уже настроен на запра-
шивающую ветвь в ее TCB в ядре. TSS указывает на это в виде сте-
ка уровня 0.
Динамическое присоединние времени выполнения
Прикладные программы OS/2 могут явно загружать подсистемы с
помощью специального системного вызова. В этом случае прикладная
программа использует вызов DosGetProcAddr для получения значений
селектора и смещения данной программы в подсистеме. Зто позволя-
ет трассировщику переадресовать запросы к другим подсистемам во
время выполнения. Программный загрузчик добавляет явно загружен-
ные модули к таблице модулей системы, и фиксирует их посредством
структуры записей, содержащейся в PDTA запрашивающего объекта, в
обработчике МТЕ для модулей динамического линкования времени вы-
полнения и в подсчете ссылок.
Загрузка по запросу
Когда загрузчик сканирует МТЕ и находит сегменты с установ-
ленным в OFF атрибутом PRELOAD, то они являются сегментами, заг-
ружаемыми по вызову (LOADONCALL). Загрузчик осуществляет отсроч-
ку фактической загрузки сегментов LOADONCALL; для них назначают-
ся селекторы LDT, но дескрипторы маркируются как отсутствующие.
В случае ссылки к отсутствующему сегменту происходит ошибка
из-за отсутствия, и сегмент загружается по требованию. При этом
может понадобиться динамическое присоединение как результат об-
работки ошибки отсутствия сегмента.
Приоритетные переходы при системных вызовах
Когда прикладная программа выполняет системный вызов к яд-
ру, система осуществляет приоритетный переход к уровню 0 за счет
выполнения дальнего вызова логического блока вызова уровня 3.
Так как результитующим программным сегментом в селекторе вызова
является уровень 0, процессор переключается со стека уровня 3,
который назначался прикладной программой во время ассемблирова-
ния либо во время разрешения ссылок , на сегмент уровня 0, ука-
занный в TSS. Все параметры копируются из стека уровня 3 в стек
уровня 0 процессором 80286, и выполнение продолжается в стеке
ядра той нити, которая назначена в TCB. Механизм диспетчеризации
обеспечивает то, что когда производится переключение ветвей, по-
ля стека уровня 0 в TSS изменяются таким образом, что система
всегда использует корректный стек ядра для ветви, производящей
запрос.
При возврате, система возвращется к вызывающему объекту,
осуществляя обратный переход на уровень 3. Нахождение в режиме
ядра не эквивалентно выполнению на уровне 0. Если системный вы-
зов прошел через селектор вызовов, нить выполняется на уровне 0,
но не находится в режиме ядра. Каждое обращение к обработчику
системного вызова вызывает интерпретатор системных вызовов, или
SCI, который соединяет точку входа уровня 0 с соответствующей
рабочей программой. Рабочая программа (worker routine) является
внутренней программой, которая выполняет системные вызовы. Она
делает доступными параметры, находящиеся в стеке, которые пере-
даются в ядро и передает их в регистры для использования рабочи-
ми программами. SCI также обеспечивает правильную последователь-
ность выполнения для программ в ядре. При возврате из рабочей
программы она устанавливает статус возврата с помощью логическо-
го блока вызовов по отношению к исходному запрашивавшему объек-
ту.
Интерфейс прикладных программ
OS/2 использует комннду call в качестве интерфейса с прик-
ладными программами(API), вместо программных прерываний (INT's),
используемых ДОС и BIOS. Механизм программных прерываний для вы-
зова системных обслуживающих программ имеет множество недостат-
ков, как например,
-количество прерываний весьма ограничено, что затрудняет
развитие механизма,
-нельзя таким образом добавлять новые параметры к существу-
ющим INT, что усложняет расширение интерфейса,
- интерфейсы легко программировать на ассемблере, но их
трудно транслировать на языки высокого уровня. В отличие от ис-
пользования программных прерываний, API системы OS/2 базируется
на механизме динамического присоединения, описанном выше.
Возможности расширения
АРI OS/2 легко может быть расширен путем добавления новых
имен функций в системную библиотеку. Подсистемы могут также до-
бавляться за счет введения новой библиотеки динамического присо-
единения. Разработчику прикладных программ предоставляется прос-
той четкий механизм доступа к основным системным функциям и рас-
ширениям. Механизм динамического присоединения позволяет системе
изменять API в последующих версиях, поддерживая совместимость
для существующих вызовов.
Семейство API
Существует набор API системы OS/2, называемый семейством
API, которое поддерживается как OS/2, так и ДОС 3.3. Программы,
написанные на API, могут редактироваться и стыковаться с сущест-
вующими EXE-файлами, которые могут выполняться в OS/2 в защитном
режиме, в OS/2 в ДОС-окружении или в ДОС. При выполнении в OS/2
в защитном режиме, вызовы семейства API обрабатываются системой
обычным образом, тогда как при выполнении в ДОС или в ДОС-окру-
жении в прикладную программу встраивается специальный программ-
ный блок, который используется для трансляции вызовов семейства
API в программные прерывания или для эмуляции системных вызовов
OS/2 в реальном режиме. Этот блок также загружает программу и
передает ей управление так, будто она выполняется в среде OS/2.
Файловая система и В/В
Несмотря на то, что существует множество нюансов в деталях
реализации, функции и прежде всего структура фрагментов OS/2,
связанных с В/В, очень похожи на те, которые поддерживают ДОС и
BIOS.
Файловая система
OS/2 использует тот же формат файлов, что и ДОС 3.3, так
что объекты, написанные в одной системе, могут читаться в дру-
гой. Так же как и ДОС 3.3, OS/2 позволяет организовывать файлы
на диске или дискете в древовидные каталоги. Соглашения относи-
тельно имен файлов и имен дисководов в OS/2 те же что и в ДОС
3.3. Файловая система OS/2 предоставляет те же свойства разделе-
ния файлов, что и ДОС 3.3, так что файл может распределяться
между процессами, которые выполняются параллельно. Последова-
тельность доступа к файлам может перераспределяться нитями одно-
го и того же процесса с использованием семафоров.
В отличие от ДОС, OS/2 реализует и асинхронные файловые
операции В/В. Это означает, что программа может начать чтение
или запись и затем продолжать другую обработку, в то время как
операции В/В выполняются системой. Когда программе потребуется
считанная информация или буферы, содержащие записываемые данные,
она может дожидаться семафора, который устанавливается, когда
система завершит операцию В/В. Кроме того, так как файловая сис-
тема работает под управлением нити вызвавшего объекта либо, в
случае операций асинхронного В/В, под управлением нити, создан-
ной для выполнения запроса, операции файловой системы выполняют-
ся несколькими нитями. Это означает, что OS/2 не дожидается за-
вершения дисковых операций В/В. Вместо этого, она может передать
управление другой нити и выполнить другую работу, в то время по-
ка диск выдает запрашиваемую информацию.
Для устройств с объемом памяти более 32 Мб OS/2 предостав-
ляет метод разбиения диска на логические дисководы, каждый из
который имеет свой идентификатор. Эта схема разбиения идентична
ДОС 3.3, что обеспечивает совместимость двух системам.
OS/2 предоставляет простую файловую систему для всех прог-
рамм защитного режима и окружения ДОС, и реализует протокол раз-
деления файлов между прикладными программами, работающими в ре-
альном и защитном режимах.
Видеоадаптер, клавиатура и мышь
Несмотря на то, что они обычно считаются устройствами, OS/2
реализует большинство программ поддержки для видео, клавиатуры и
мыши, используя специальные подсистемы. Для каждого из этих уст-
ройств имеются драйверы, но они содержат лишь небольшие фрагмен-
ты программ, необходимых для их работы. Такая организация позво-
ляет заменять предоставляемую OS/2 поддержку устройств на обыч-
ную поддержку, основанную на понятии сеансов. Система обслужива-
ет сеансы таким образом, что когда сеанс находится на переднем
плане, процесс, выполняя видеовывод, посылает его прямо в аппа-
ратный видеобуфер. Когда сеанс переводится в режим заднего пла-
на, аппаратный видеобуфер запоминается в логическом видеобуфере
сеанса. Пока сеанс находится на заднем плане, процесс посылает
ей видеовывод в этот логический видеобуфер. Когда пользователь
возвращает сеанс на передний план, система копирует свой логи-
ческий видеобуфер в аппаратный видеобуфер. Нажатия клавиш и ввод
с мыши направляются к одному из процессов сеанса переднего пла-
на. Существуют программные интерфейсы для контроля за тем, какой
из процессов принял их.
Драйверы устройств
Подобно ДОС, OS/2 имеет два типа драйверов - драйверы по-
символьных устройств и драйверы блочных устройств. Также как в
ДОС, драйверы устройств могут встраиваться в программы стратегии
и прерываний. Тем не менее, ввиду того, что драйверы устройств в
OS/2 должны работать в многозадачном режиме, они должны быть на-
писаны так, чтобы передавать управление, когда они вынуждены
ожидать завершения операций В/В. Драйверы устройств являются
двухрежимными компактными программами уровня 0. С учетом того,
что они являются двухрежимными, асинхронная операция В/В может
начаться, когда драйвер устройства находится в одном режиме, но
он может принять прерывание от нее, находясь в другом режиме.
Так как структура адресации различна в реальном и защитном режи-
ме, драйверы устройств транслируют виртуальные адреса в физичес-
кие и запоминают физические адреса для использования во время
прерываний. Физическиме адреса постоянны, независимо от режима
процессора.
Для оказания помощи в реализации подобных драйверов устрой-
ств OS/2 имеет общий супервизор прерываний, который обрабатывает
все аппаратные прерывания и направляет их к нужным драйверам.
Кроме того, система предоставляет множество сервисных программ,
называемых divice driver helper (вспомогательное средство драй-
веров устройств), или DevHlp, программы, которые может вызывать
драйвер. Эти вызовы DevHlp предоставляют доступ к обслуживающим
программам ядра, включая такие, которые специально присоеденены
для помощи в реализации драйверов устройств. Среди предоставляе-
мых функций имеется:
-преобразование виртуальных адресов в физические
-преобразование физических адресов в виртуальные
-фиксация сегментов
-обработка семафоров
-обслуживание очередей запросов.
В ядре имеется трассировщик DevHlp, который преобразует вы-
зовы DevHlp в интерфейс к исполнительным (рабочим) программам
ядра, которые аналогичны тем, которые вырабатываются в случае
интерпретатора системных вызовов (SCI) для динамического присое-
динения. Более подробную информацию по драйверам устройств сис-
темы OS/2 можно найти в работе Mizell'а [5].
Совместимость с ДОС
OS/2 выполняет программы реального режима по одной в данный
момент времени в нижней области памяти. Программы реального ре-
жима выполняются только тогда, когда среда ДОС выбрана в виде
сеанса переднего плана. Прикладные программы защитного режима
могут продолжать выполняться на заднем плане. Когда программа
реального режима переводится на задний план пользователем, она
замораживается и не выполняется вновь до тех пор, пока пользова-
тель не вернет ее на передний план. Это означает что функции об-
мена данными реального режима не могут надежно поддерживаться в
среде ДОС, когда пользователь производит переключение прикладной
программы OS/2 в защитный режим.
Программные прерывания, вызываемые программами реального
режима, обслуживаются OS/2. Охватываются как вызовы функций
программного прерывания ДОС, так и программные прерывания BIOS.
Такая организация позволяет прикладным программам реального ре-
жима и защитного режима распределять общие ресурсы и обслужива-
ние, такие, как файловая система, под управлением операционной
системы.
Часть функций BIOS, которые трудно эмулировать, перенесена
в BIOS ПЗУ . В этом случае двухрежимные драйверы устройств ис-
пользуют системное обслуживание для задания последовательности
использования BIOS ПЗУ, с тем, чтобы BIOS работал корректно.
Ввиду того, что OS/2 требуется доступ к области памяти ниже
640 Кб, для прикладных программ остается меньше памяти в среде
ДОС, по сравнению с системами, работающимим в ДОС 3.3.
Программы ДОС могут вылавливать вектор прерывания. Когда
задается среда ДОС, устанавливается таблица векторов прерываний
для получения соответствия с таблицей, которая необходима
ДОС-программе. Когда OS/2 снова получеат управление, она сравни-
вает таблицу векторов прерываний с ее первоначальным образом и,
если необходимо, изменяет IDT защитного режима. Если система об-
наруживает, что программа ДОС восприняла прерывание для того
чтобы использовать аппаратные ресурсы, она определяет, что это
использование не приводит к конфликту с использованием, которое
реализуется драйвером устройства защитного режима или програм-
мой. Это свойство называется сокрытием таблицы прерываний.
Несмотря на то, что OS/2 является двухрежимной, окружение
ДОС не получает подготовленные к работе нити, так как не может
выполнять процесс на заднем плане. Существуют ДОС-PDTA в нижней,
фиксированной области памяти.
Команды и утилиты
Командный процессор для OS/2 является расширением процессо-
ра команд Command.com в ДОС. За небольшими исключениями, поддер-
живается известный набор команд ДОС, синтаксис команд, а также
значение параметров команд являются тами же.
Существует несколько новых команд, специфичных для OS/2. В
частности, OS/2 располагает командой START, которая позволяет
запускать программу в другой сессии и дает ей возможность выпол-
няться асинхронно по отношению к командному процессору.
OS/2 поддерживает совместимое расширение языка пакетных
файлов ДОС. Это расширение позволяет переносить пакетные файлы
из ДОС и использовать их в OS/2. В отличие от ДОС, команды OS/2
программно устанавливают уровень ошибки, так что можно легко оп-
ределить, успешно ли завершилась команда.
Командный файл STARTUP.CMD, если он имеется, выполняется во
время запуска системы и может использоваться для хранения команд
инициализации. Дополнительно может существовать файл
OS2INIT.CMD, который выполняется вначале каждого CMD.EXE сеанса.
Этот файл является функциональным эквивалентом традиционного
файла ДОС AUTOEXEC.BAT. Если AUTOEXEC.BAT присутствует, он вы-
полняется при запуске среды ДОС.
Утилиты реализованы с использованием семейства API и одни и
те же программы могут использоваться как программы реального ре-
жима в среде ДОС или как программы защитного режима. Однако так
как программы могут определять режим, в котором они выполняются,
некоторые из низ располагают функциями, специфичными для того
или другого режима. Семейство API было использовано для того,
чтобы реализовать программы-утилиты с целью экономии дискового
пространства, так как на утилиту требуется только один программ-
ный файл, а не два, как было необходимо, если бы существовало
две версии утилит: для реального и для защитного режимов.
Среда ДОС использует командный процессор COMMAND.COM ДОС
для обработки команд, введенных с клавиатуры.
Заключение
Настоящая статья посвящена разработке стандартной редакции
системы OS/2 версии 1.0, с упором на архитектурные аспекты реа-
лизации системы , требования к ее размеру и функциональной пол-
ноте. OS/2 является логическим расширением системы ДОС 3.3 фирмы
IBM, которая позволяет реализовать
- больший объем памяти, превышающий 640 Кб
- мультипрограммирование
- многозадачность.
В настоящее время OS/2 имеет возможность выполнять большин-
ство прикладных программ ДОС. Так, она может обеспечить мост
между "наследием" однозадачных персональных систем с ограничен-
ной памятью и более сложными, но более мощными многозадачными
системами будущего.
|
|
 |
|
