Интерфейсы операционных систем

ОС всегда выступает как интерфейс^[7] между аппаратурой компьютера и пользователем с его задачами.

По соответствующим запросам от задач ОС осуществляет управление процессами, памятью и вводом/выводом.

Управление процессами включает следующий набор основных функций:

– запуск, приостанов и снятие задачи с выполнения;

– задание или изменение приоритета задачи;

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

– вызовудаленныхпроцедур (Remote Procedure Call, RFC).

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

– запрос на выделение блока памяти;

– освобождение памяти;

– изменение параметров блока памяти (например, память может быть заблокирована процессом либо предоставлена в общий доступ);

– отображение файлов на память (имеется не во всех системах).

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

– запрос на управление виртуальными устройствами;

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

Интерфейс пользователя с ОС реализуется с помощью специальных программных модулей, которые принимают его команды на соответствующем языке и транслируют их в обычные вызовы в соответствии с основным интерфейсом системы. Такие модули называют интерпретатором команд. Например, функции такого интерпретатора в MSDOSвыполняет модуль COMMAND.COM. Получив от пользователя команду, такой модуль после лексического и синтаксического анализа или сам выполняет действие, или (что чаще происходит) обращается к другим модулям операционной системы, используя механизм API. В последнее время большую популярность получили графические интерфейсы (GraphicalUserInterface, GUI), в которых задействованы манипуляторы типа " мышь" или " track-ball", или " touchpad" ^[8]. Такая интерфейсная подсистема транслирует " команды" пользователя в обращения к ОС. УправлениеGUI является частным случаем задачи управления вводом/выводом и не относится к функциям ядра ОС.

Есть два основных подхода к управлению задачами:

– порождаемая задача наследует все ресурсы задачи-родителя;

– равноправные отношения, то есть при порождении нового процесса ресурсы для него запрашиваются у операционной системы.

Обращения к ОС в соответствии с имеющимся интерфейсом API могут осуществляться как посредством вызова подпрограммы с передачей ей необходимых параметров, так и через механизм программных прерываний. Выбор метода реализации вызовов функций API должен определяться архитектурой платформы. Например, в ОС MSDOS, которая разрабатывалась для однозадачного режима (поскольку процессор I80x86 не поддерживал мультипрограммирование), использовался механизм программных прерываний. При этом основной набор функцийAPI был доступен через точку входа обработчика int 21h. В более сложных системах имеется не одна точка входа, а множество – по количеству функций API. В большинстве ОС используется метод вызова подпрограмм. В этом случае вызов сначала передается в модуль API (например, в библиотеку времени выполнения^[9]), который перенаправляет его соответствующим обработчикам программных прерываний, входящим в состав ОС.

Общий термин API^[10] можно разделить на следующие направления:

– API как интерфейс высокого уровня, принадлежащий к библиотекам RTL;

– API прикладных и системных программ, входящих в поставку ОС;

– прочие интерфейсы API.

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

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

API – это набор функций, предоставляемых системой программирования разработчику прикладной программы и ориентированных на организацию взаимодействия результирующей программы^[11] с целевой вычислительной системой^[12].

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

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

Существует несколько вариантов реализации API (с точки зрения разработчика прикладной программы):

– реализация на уровне модулей ОС;

– реализация на уровне системы программирования;

– реализация на уровне внешней библиотеки процедур и функций.

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

Возможности API можно оценивать со следующих позиций:

– эффективности выполнения функций API, которая включает в себя скорость выполнения функций и объем вычислительных ресурсов, необходимых для их выполнения;

– широты предоставляемых возможностей;

– зависимости прикладной программы от архитектуры целевой вычислительной системы.

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

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

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

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

Например, функции динамического выделения памяти в языках С и Pascal. В С это функции malloc, realloc и free (в C++ – функции new и delete), в Pascal – функции new и dispose. Для разработчика исходной программы не имеет значения, на какую архитектуру ориентирована программа, это имеет значение для системы программирования, которая для каждой из этих функций должна подключить к результирующей программе объектный код библиотеки. Этот код будет выполнять обращение к соответствующим функциям ОС. Возможно, что для однотипных по смыслу функций в разных языках (например, malloc в С и new в Pascal) этот код будет выполнять схожие обращения к ОС. Но для различных вариантов ОС этот код будет различен даже при использовании одного и того же исходного языка.

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

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

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

С точки зрения переносимости исходного кода, здесь только одно требование: используемая внешняя библиотека должна быть доступна в любой из архитектур вычислительных систем, на которые ориентирована прикладная программа. Это возможно, если внешняя библиотека удовлетворяет какому-то принятому стандарту, а система программирования поддерживает этот стандарт. Например, библиотеки, удовлетворяющие стандарту POSIX, доступны в большинстве систем программирования для языка С. И если прикладная программа использует только библиотеки этого стандарта, то ее исходный код будет переносимым. Библиотека CLX от Borland ориентирована на архитектуру ОС семейств Linux и Windows, а библиотеки VCL (VisualControlsLibrary) от Borland и MFC(MicrosoftFoundationClasses) от Microsoft, напротив, жестко ориентированы на архитектуру ОС семейства Windows.

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

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

Например, можно написать в программе вызов функции по запросу 256 байт памяти:

unsigned char * ptr = malloc (256);

Система программирования языка С сгенерирует целую последовательность обращений. Из кода пользовательской программы будет осуществлен вызов библиотечной функции malloc, код которой расположен в RTL языка С. Библиотека времени выполнения, в данном случае, реализует вызов malloc как вызов системной функцииHeapAllocAPI:

LPVOID HeapAlloc(

HANDLE hHeap, // handle to the private heap block – указательнаблок

DWORD dwFlags. // heap allocation control flags – свойстваблока

DWORD dwBytes // number of bytes to allocate – размерблока

);

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

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

unsigned char * ptr = (LPVOID) HeapAlloc (GetProcessHeap(), 0, 256);

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

Непосредственное обращение к API позволяет пользователю обращаться к системным ресурсам более эффективным способом.

Как правило, функции API не стандартизированы. В каждом конкретном случае набор вызовов API определяется, прежде всего, архитектурой ОС и ее назначением. Но предпринимаются попытки стандартизировать некоторый базовый набор функций, так как это существенно облегчило бы перенос приложений с одной ОС на другую. Например, в стандарте POSIX перечислен большой набор функций, их параметров и возвращаемых значений. Согласно POSIX, стандартизированными являются не только обращения к API, но и файловая система, организация доступа к внешним устройствам, набор системных команд^[13]. Использование в приложениях этого стандарта позволяет легко переносить такие программы с одной ОС в другую путем перекомпиляции исходного текста. Частным случаем попытки стандартизации API является внутренний корпоративный стандарт компании MicrosoftWinAPI. Он включает в себя следующие реализации: Win16, Win32s, Win32, WinCE. С точки зрения WinAPI базовой задачей является окно (в силу идеологических причин графический, то есть " оконный", интерфейс пользователя обязателен) – стандарт WinAPIизначально ориентирован на работу в графической среде. Но базовые понятия дополнены традиционными функциями, в том числе частично поддерживается стандарт POSIX.

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

^[2] Супервизор – центральный (главный) управляющий модуль ОС. Может состоять из нескольких модулей, например, супервизора ввода-вывода, супервизора прерываний, супервизора программ и т.д.

^[3] ОС MS-DOS. всегда работает в так называемом реальном режиме, в котором эмулируется процессор 8086/88. Реальный режим был реализован только для совместимости поздних моделей процессоров с ранней моделью 8086/88 и альтернативой ему является защищенный режим работы процессора, в котором становятся доступными все особенности процессоров поздних моделей, в том числе и работа на одном из четырех уровней привилегий.

^[4]Не следует путать таймер с тактовым генератором, который вырабатывает сигналы, синхронизирующие все операции в компьютере, или с системными часами – работающей на батареях электронной схеме, – которые ведут независимый отсчет времени и календарной даты.

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

^[6] Хост (host) – главный компьютер. В настоящее время этим термином обозначают любой компьютер, имеющий Internet-адрес.

^[7] В данном случае интерфейсы ОС – это специальные интерфейсы системного и прикладного программирования (API).

^[8] Touchpad – устройство, чувствительное к касанию. С помощью такого устройства пользователь управляет указателем мыши, перемещая палец по специальной поверхности

^[9] Библиотека времени выполнения (RunTimeLibrary, RTL) – включает в себя стандартные подпрограммы, которые система программирования подставляет на этапе компиляции. В общем случае это не только модули системы программирования, но и модули самой ОС.

^[10] ApplicationProgramInterface () – интерфейс прикладного программирования

^[11] Результирующая программа порождается системой программирования на основании созданного разработчиком кода исходной программы, а также объектных модулей и библиотек, входящих в состав системы программирования.

^[12] Целевая вычислительная система – это совокупность программных и аппаратных средств, в окружении которых выполняется прикладная программа.

^[13]В данном случае под системными командами понимается набор программ, позволяющих управлять вычислительными процессами, например pstat, kill, dir и т.д.