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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим реализацию API в Windows NT. Для этой ОС характерно:

• Несколько программных интерфейсов.

• Изоляция базовой операционной системы от изменений или расширений в поддерживаемых API.

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

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

• Возможность операционной системе расширяться в будущем за счет новых API.

Windows NT поддерживает пять прикладных сред операционных систем: MS-DOS, 16-разрядный Windows, OS/2 1.x, POSIX и 32-разрядный Windows (Win32) (рис. 4.1). Каждая работает в собственном защищенном пользовательском пространстве. Подсистема Win32 обеспечивает поддержку дисплея, клавиатуры и мыши для четырех оставшихся подсистем.

16-битовые приложения DOS и Windows работают на VDM (virtual DOS machines – виртуальные машины DOS), каждая из которых эмулирует полный 80x86 процессор с MS-DOS.

Подсистемы OS/2 и POSIX построены по-другому. В качестве полноценных подсистем Windows NT они могут взаимодействовать с подсистемой Win32 для получения доступа к вводу и выводу, но также могут обращаться непосредственно к исполнительной системе Windows NT за другими средствами операционной системы. Подсистема OS/2 может выполнять многие имеющиеся приложения OS/2, включая OS/2 SQL Server.

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