Управление задачами и памятью в операционных системах

 

Реализация функций API с  помощью внешних библиотек

 

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

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

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

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

Например, библиотеки, удовлетворяющие  стандарту POSIX, доступны в большинстве  систем программирования для языка  С. И если прикладная программа использует только библиотеки этого стандарта, то ее исходный код будет переносимым. Еще одним примером является широко известная библиотека графического интерфейса XLib, поддерживающая стандарт графической среды X Window.

Для большинства специфических  библиотек отдельных разработчиков  это не так. Если пользователь использует какую-то библиотеку, то она ориентирована  на ограниченный набор доступных  архитектур целевой вычислительной системы. Примерами могут служить  библиотеки MFC (Microsoft foundation classes) фирмы Microsoft и VCL (visual controls library) фирмы Borland, жестко ориентированные на архитектуру ОС типа Windows.

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

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

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

Частным случаем попытки стандартизации API является внутренний корпоративный  стандарт компании Microsoft, известный как WinAPI. Он включает в себя следующие реализации: Win16, Win32s, Win32, WinCE. С точки зрения WinAPI (в силу ряда идеологических причин – обязательный графический «оконный» интерфейс пользователя), базовой задачей является окно. Таким образом, WinAPI изначально ориентирован на работу в графической среде. Однако базовые понятия дополнены традиционными функциями, в том числе частично поддерживается стандарт POSIX.

 

Платформенно-независимый  интерфейс POSIX

 

POSIX (Portable Operating System Interface for Computer Environments) — платформенно независимый системный интерфейс для компьютерного окружения. Это стандарт IEEE, описывающий системные интерфейсы для открытых операционных систем, в том числе оболочки, утилиты и инструментарии. Помимо этого, согласно POSIX, стандартизированными являются задачи обеспечения безопасности, задачи реального времени, процессы администрирования, сетевые функции и обработка транзакций. Стандарт базируется на UNIX-системах, но допускает реализацию и в других ОС.

POSIX возник как попытка всемирно известной организации IEEE пропагандировать переносимость приложений в UNIX-средах путем разработки абстрактного, платформенно-независимого стандарта. Однако POSIX не ограничивается только UNIX-системами; существуют различные реализации этого стандарта в системах, которые соответствуют требованиям, предъявляемым стандартом IEEE Standard 1003.1-1990 (POSIX.1). Например, известная ОС реального времени QNX соответствует спецификациям этого стандарта, что облегчает перенос приложений в эту систему, но UNIX-системой не является ни в каком виде, ибо ее архитектура использует абсолютно иные принципы.

Этот стандарт подробно описывает VMS (virtual memory system, систему виртуальной памяти), многозадачность (МРЕ, multiprocess executing) и технологию переноса операционных систем (CTOS). Таким образом, на самом деле POSIX представляет собой множество стандартов, именуемых POSIX. I — POSIX. 12.

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

как основной язык описания системных  функций API.

 

Таблица 1. Семейство стандартов POSI

 
 
 

 

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

 

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

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

Реализации POSIX API на уровне операционной системы различны. Если UNIX-системы  в своем абсолютном большинстве  изначально соответствуют спецификациям IEEE Standard 1003.1-1990, то WinAPI не является POSIX-совместимым. Однако для поддержки данного стандарта в операционной системе MS Windows NT введен специальный модуль поддержки POSIX API, работающий на уровне привилегий пользовательских процессов. Данный модуль обеспечивает конвертацию и передачу вызовов из пользовательской программы к ядру системы и обратно, работая с ядром через WinAPI. Прочие приложения, написанные с использованием WinAPI, могут передавать информацию POSIX-приложениям через стандартные механизмы потоков ввода/вывода (stdin, stdout)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

СПИСОК  ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ

 

1. Лекция операционные системы [электронный ресурс], режим доступа: http://www.lookinfo.org/2007/10/28/print:page,1,upravlenie_zadachami_i_pamjatju_v_operacionnykh_sistemakh.html
2. Учебный материалы [электронный ресурс], режим доступа: http://do.gendocs.ru/docs/index-241888.html?page=4#6094559
3. [Электронный ресурс] http://kk.docdat.com/docs/index-350865.html.