Реализация функцийApIна уровне ос

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

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

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

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

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

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

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

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

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

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

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

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

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