Реализация функций API на уровне ОС

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

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

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

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

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

Хорошо известным примером API такого рода может служить набор функций, предоставляемых пользователю со стороны ОС типа Microsoft Windows – WinAPI (Windows API). Надо сказать, что даже внутри этого корпоративного API суще­ствует определенная несогласованность, которая несколько ограничивает пере­носимость программ между различными ОС типа Windows. Еще одним приме­ром такого API можно считать набор сервисных функций ОС типа MS-DOS, реализованный в виде набора подпрограмм обслуживания программных преры­ваний.

4.3. Реализация функций API на уровне
системы программирования

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

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

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

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

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

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

Например, те же функции mallос, realloc и free в языке С фактически не входят в стандарт языка. Они входят в состав стандартной библиотеки, которая «де-факто» входит во все системы программирования, построенные на основе язы­ка С. Общепринятые стандарты существуют для многих часто используемых функций языка. Если же взять более специфические функции, такие как функ­ции порождения новых процессов, то для них ни в С, ни в языке Pascal не ока­жется общепринятого стандарта.