Интерфейс прикладного программирования

Прежде всего, необходимо однозначно разделить общий термин API (Application Program Interface — интерфейс прикладного программирования) на следующие направления:

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

□ API прикладных и системных программ, входящих в поставку операционной
системы;

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

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

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

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

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

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

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

Существует несколько вариантов реализации API:

□ реализация на уровне модулей операционной системы;

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

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

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

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

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

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

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

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

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

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

Что такое Win API

Win API - это набор функций, предоставляемых операционной системой каждой программе. Эти функции находятся в стандартных динамически компонуемых библиотеках (Dynamic Linked Library, DLL), таких как kernel32.dll, user32.dll, gdi32.dll. Эти файлы находятся в директории Window\System. Вообще говоря, каждая программа должна самостоятельно заботится о том, чтобы подключить эти библиотеки. DLL могут подключаться к программе статически и динамически. В первом случае программа «освобождает» DLL только при завершении, во втором освобождение может произойти в любой момент. Если после освобождения DLL оказывается, что её больше не использует ни одна программа, она выгружается из памяти. Так как стандартные библиотеки используются самой системой, они всегда находятся в памяти, и поэтому использование динамического подключения бессмысленно. Чтобы статически подключить в Delphi некоторую функцию Win API, например, функцию GetWindowDC из модуля user32.dll, надо написать конструкцию вида

function GetWindowDC(Wnd: HWnd); HDC; stdcall; external 'user32.dll' name 'GetWindowDC';

Такая запись обеспечивает одновременно и статическое подключение библиотеки user32, и декларацию функции GetWindowDC, что позволяет компилятору в дальнейшем работать с ней. Обратите внимание, что все функции Win API написаны в соответствии с моделью вызова stdcall, а в Delphi по умолчанию используется другая модель - register (модель вызова определяет, как функции передаются параметры). Поэтому при импорте функций из стандартных библиотек необходимо явно указывать эту модель. Далее указывается, из какой библиотеки импортируется функция и какое название в ней она имеет. Дело в том, что имя функции в библиотеке может не совпадать с тем, под которым она становится известна компилятору. Позже я остановлюсь на тех случаях, когда это используется. Главным недостатком DLL следует считать то, что в них сохраняется информация только об именах функций, но не об их параметрах. Поэтому, если при импорте функции указать не те параметры, какие подразумевались автором DLL, то программа будет работать неправильно (вплоть до зависания), а ни компилятор, ни операционная система не смогут указать на ошибку.

Обычно программа использует довольно большое число функций Win API. Декларировать их все довольно утомительно. К счастью, Delphi избавляет программиста от этой работы: все эти функции уже описаны в соответствующих модулях, достаточно упомянуть их имена в разделе uses. Например, большинство общеупотребительных функций описаны в модулях Windows.dcu и Messages.dcu.

Системные вызовы

Системный вызов, это требование к ОС (ядру) произвести аппаратно/системно специфическую или привилегированную операцию. В Linux-1.2 были определены 140 системных вызовов. Такие вызовы, как close() реализованы в Linux libc. Эта реализация часто включает в себя макрос, который в конце концов вызывает syscall(). Параметры, передаваемые syscall, это номер системного вызова, перед которым ставятся требуемые аргументы. Номера системных вызовов можно найти в , а обновленные вместе с новой версией libc в . Если появились новые системные вызовы, но их до сих пор нет в libc, вы можете использовать syscall(). Как пример, рассмотрим закрытие файла при помощи syscall (не советуем, однако):

#include <syscall.h>

extern int syscall(int, ...);

int my_close(int filedescriptor)

{return syscall(SYS_close, filedescriptor);}

На i386 системные вызовы ограничены 5-ю аргументами кроме номера вызова из-за аппаратного числа регистров. На другой архитектуре вы можете поискать макрос _syscall в и там посмотреть сколько аргументов поддерживается у вас или $how many developers chose to support$. Макросами _syscall можно пользоваться вместо syscall(), но это не рекомендуется, поскольку макрос может развернуться в функцию, которая уже существует в библиотеке. Поэтому только ядреные хакеры имеют право поиграться с _syscall :). Для демонстрации посмотрим на пример close(), использующий макрос _syscall.

#include <linux/unistd.h>

_syscall1(int, close, int, filedescriptor);

_syscall1 раскрывается в функцию close(), и мы получаем твикс: один close() в libc и один в нашей программе. Возвращаемое syscall() (или _syscall) значение есть -1, если вызов неудачен и 0 или больше в случае успеха. В случае неудачи ошибку можно определить по глобальной переменной errno.

Приведем системные вызовы, возможные в BSD и SYS V, но не допустимые в LINUX: audit(), audition(), fchroot(), getauid(), getdents(), getmsg(), mincore(), poll(), putmsg(), setaudit(), setauid().