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

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

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

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

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

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

Для большинства специфических библиотек отдельных разработчиков это не так. Если пользователь использует какую-то библиотеку, то она ориентирована на ограниченный набор доступных архитектур целевой вычислительной системы. Примерами могут служить библиотеки MFC(Microsoftfoundationclasses) фир­мыMicrosoftиVCL(visualcontrolslibrary) фирмыBorland, жёстко ориентиро­ванные на архитектуру ОС типаWindows. Тем не менее, многие фирмы-разработчики сейчас стремятся создать библиоте­ки, которые бы обеспечивали переносимость исходного кода приложений между различными архитектурами целевой вычислительной системы. Пока ещё такие библиотеки не получили широкого распространения, но есть несколько попыток их реализации – например, библиотекаCLXпроизводства фирмыBorlandори­ентирована на архитектуру ОС типаLinuxи ОС типаWindows.

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

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

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

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

unsignedchar*ptr=malloc(256);

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

LPVOID НеарАllос{

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) НеарАllос( GetProcessHeap(), 0, 256);

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

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

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