Гордеев А.В. Операционные системы (2-е изд., 2004) (1186250), страница 78
Текст из файла (страница 78)
Система программирования ответственна только за то, чтобы организовать интерфейс для вызоваэтого кода.В таком варианте результирующая программа обращается непосредственно к операционной системе. Поэтому достигается наибольшая эффективность выполнения функций API по сравнению со всеми другими вариантами реализации API.Недостатком организации API по такой схеме является практически полное отсутствие переносимости не только кода результирующей программы, но и кодаисходной программы. Программа, созданная для одной архитектуры вычислительной системы, не сможет исполняться на вычислительной системе другой архитектуры даже после того, как ее объектный код полностью перестроен.
Чаще всегосистема программирования просто не сможет выполнить перестроение исходногокода для новой архитектуры вычислительной системы, поскольку многие функции API, ориентированные на определенную операционную систему, в новой архитектуре могут просто отсутствовать.Таким образом, в данной схеме для переноса прикладной программы с одной целевой вычислительной системы на другую потребуется изменение исходного кодапрограммы.Переносимости можно было бы добиться, если унифицировать функции API в различных операционных системах.
С учетом корпоративных интересов производителей операционных систем и иного системного программного обеспечения такоенаправление их развития представляется практически невозможным. В лучшемслучае при приложении определенных организационных усилий удается добиться стандартизации смыслового (семантического) наполнения основных функцийAPI, но не их программного интерфейса.Хорошо известным примером API такого рода может служить набор функций,предоставляемых пользователю со стороны операционных систем типа MicrosoftWindows — WinAPI (Windows API).
Надо сказать, что даже внутри этого корпоративного интерфейса API существует определенная несогласованность, котораянесколько ограничивает переносимость программ между различными операционными системами типа Windows. Еще одним примером такого интерфейса APIможно считать набор сервисных функций простейших однопрограммных операционных систем типа MS DOS, реализованный в виде набора подпрограмм обслуживания программных прерываний.Реализация функций API на уровнесистемы программированияПри реализации функций API на уровне системы программирования эти функции предоставляются пользователю в виде библиотеки функций соответствующего языка программирования.
Обычно речь идет о библиотеке времени выполнения (RTL). Система программирования предоставляет пользователю библиотекуИнтерфейс прикладного программирования301функций и обеспечивает подключение к результирующей программе объектногокода, ответственного за выполнение этих функций.Очевидно, что эффективность вызова функций API в таком варианте будет несколько ниже, чем при непосредственном обращении к функциям операционнойсистемы. Так происходит, поскольку для выполнения многих функций API библиотека RTL языка программирования должна все равно выполнять обращенияк функциям операционной системы. Наличие всех необходимых вызовов и обращений к функциям операционной системы в объектном коде RTL обеспечиваетсистема программирования.Однако переносимость исходного кода программы в таком варианте оказываетсясамой высокой, поскольку синтаксис и семантика всех функций строго регламентированы в стандарте соответствующего языка программирования.
Они зависятот языка и не зависят от архитектуры целевой вычислительной системы. Поэтомудля выполнения прикладной программы на новой архитектуре вычислительнойсистемы достаточно заново построить код результирующей программы с помощьюсоответствующей системы программирования.Единообразное выполнение функций языка обеспечивается системой программирования. При ориентации на различные архитектуры целевой вычислительнойсистемы в системе программирования могут потребоваться различные комбинации вызовов функций операционной системы для выполнения одних и тех жефункций исходного языка.
Это должно быть учтено в коде RTL. В общем случаедля каждой архитектуры целевой вычислительной системы потребуется свой кодRTL языка программирования. Выбор того или иного объектного кода RTL дляподключения к результирующей программе система программирования обеспечивает автоматически.Например, рассмотрим функции динамического выделения памяти в языках Си Паскаль. В С это функции malloc, realLoc и free (функции new и delete в C++),в Паскале — функции new и dispose. Если использовать эти функции в исходномтексте программы, то с точки зрения исходной программы они будут действоватьодинаковым образом в зависимости только от семантики исходного кода программы. При этом для разработчика исходной программы не имеет значения, на какуюархитектуру ориентирована его программа.
Это имеет значение для системы программирования, которая для каждой из этих функций должна подключить к результирующей программе объектный код библиотеки. Этот код будет выполнятьобращение к соответствующим функциям операционной системы. Не исключенодаже, что для однотипных по смыслу функций в разных языках (например, mallocв С и new в Паскале выполняют схожие по смыслу действия) этот код будет выполнять схожие обращения к операционной системе. Однако для различных вариантов операционной системы этот код будет различен даже при использованииодного и того же исходного языка.Проблема главным образом заключается в том, что большинство языков программирования предоставляют пользователю не очень широкий набор стандартизованных функций.
Поэтому разработчик исходного кода существенно ограниченввыборе доступных функций API. Как правило, набора стандартных функций ока-302Глава 9. Архитектура операционных системзывается недостаточно для создания полноценной прикладной программы. Тогдаразработчик может обратиться к функциям других библиотек, имеющихся в составе системы программирования. В этом случае нет гарантии, что функции, включенные в состав данной системы программирования, но не входящие в стандартязыка программирования, будут доступны в другой системе программирования,особенно если та ориентирована на другую архитектуру целевой вычислительнойсистемы. Такая ситуация уже ближе к третьему варианту реализации API.Например, те же функции malloc, realLoc и free в языке С фактически не входятв стандарт языка.
Они входят в состав стандартной библиотеки, которая «де-факто» входит во все системы программирования, построенные на основе языка С.Общепринятые стандарты существуют для многих часто используемых функцийязыка. Если же взять более специфические функции, такие как функции порождения новых процессов, то для них ни в С, ни в Паскале не окажется общепринятогостандарта.Реализация функций API с помощьювнешних библиотекПри реализации функций API с помощью внешних библиотек эти функции предоставляются пользователю в виде библиотеки процедур и функций, созданнойсторонним разработчиком.Система программирования ответственна только за то, чтобы подключить объектный код библиотеки к результирующей программе. Причем внешняя библиотекаможет быть и динамически загружаемой (загружаемой во время выполнения программы).С точки зрения эффективности выполнения этот метод реализации API имеет самые низкие результаты, поскольку внешняя библиотека обращается как к функциям операционной системы, так и к функциям RTL языка программирования.Только при очень высоком качестве внешней библиотеки ее эффективность сравнима с эффективностью библиотеки RTL.Если говорить о переносимости исходного кода, то здесь требование только одно —используемая внешняя библиотека должна быть доступна в любой из архитектурвычислительных систем, на которые ориентирована прикладная программа.
Тогда удается достигнуть переносимости. Это возможно, если внешняя библиотекаудовлетворяет какому-то принятому стандарту, а система программирования поддерживает этот стандарт.Например, библиотеки, удовлетворяющие стандарту POSIX (см. следующий раздел), доступны в большинстве систем программирования для языка С. И если прикладная программа использует только библиотеки этого стандарта, то ее исходный код будет переносимым. Еще одним примером является широко известнаябиблиотека графического интерфейса XLib, поддерживающая стандарт графической среды X-Window.Для большинства специфических библиотек отдельных разработчиков это не так.Если пользователь использует какую-то библиотеку, то она ориентирована на ог-Интерфейс прикладного программирования303раниченный набор доступных архитектур целевой вычислительной системы.
Примерами могут служить библиотеки MFC (Microsoft Foundation Classes) от Microsoftи VCL (Visual Controls Library) от Borland, жестко ориентированные на архитектуру операционных систем семейства Windows.Тем не менее многие фирмы-разработчики сейчас стремятся создавать библиотеки, которые бы обеспечивали переносимость исходного кода приложений междуразличными архитектурами целевой вычислительной системы.
Пока еще такиебиблиотеки не получили широкого распространения, но имеется несколько попыток их реализации, например библиотека CLX от Borland ориентирована на архитектуру операционных систем семейств Linux и Windows.В целом развитие функций API идет в направлении попытки создать библиотекиAPI, обеспечивающие широкую переносимость исходного кода. Однако с учетомкорпоративных интересов различных производителей и сложившейся ситуациина рынке в ближайшее время вряд ли удастся достичь значительных успехов в этомнаправлении. Разработка широко применимого стандарта API пока еще остаетсяделом будущего.Поэтому разработчики системных программ вынуждены оставаться в довольноузких рамках ограничений стандартных библиотек языков программирования.Что касается прикладных программ, то гораздо большую перспективу для них предоставляют технологии, связанные с разработками в рамках архитектуры клиентсервер или трехзвенной архитектуры создания приложений.
В этом направленииведущие производители операционных систем, СУБД и систем программирования скорее достигнут соглашений, чем в направлении стандартизации API.Итак, нами были рассмотрены основные принципы, цели и подходы к реализациисистемных интерфейсов API. Отметим еще один очень важный момент: желательно, чтобы интерфейс прикладного программирования не зависел от системы программирования. Конечно, были одно время персональные компьютеры, у которыхбазовой системой программирования выступал интерпретатор с языка Basic, ноэто скорее исключение.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
