Гордеев А.В. Операционные системы (2-е изд., 2004) (1186250), страница 79
Текст из файла (страница 79)
Обычно интерфейс API не зависит от системы программирования и может вызываться из любой системы программирования, хотя и с использованием соответствующих правил построения вызывающих последовательностей. В то же время, в ряде случаев система программирования может самагенерировать обращения к API. Например, мы можем написать в программе вызовФункции по запросу 256 байт памяти:unsigned char * ptr = malloc (256);Система программирования с языка С сгенерирует целую последовательность обращений.
Из кода пользовательской программы будет осуществлен вызов библиотечной функции malloc, код которой расположен в RTL языка С. Библиотека времени выполнения, в данном случае, реализует вызов malloc уже как вызов системнойФункции HeapAlloc API:LPV0ID НеарАПос(HANDLE hHeap. // handle to the private heap block - указатель на блокDWORD dwFlags.
// heap allocation control flags - свойства блока304Глава 9. Архитектура операционных системDWORD dwBytes // number of bytes to allocate - размер блока);Параметры выделяемого блока памяти в таком случае задаются системой программирования, и пользователь лишен возможности задавать их напрямую. С другойстороны, если это необходимо, функции API можно вызывать прямо в тексте программы:unsigned char * ptr = (LPVOID) HeapAlloc( GetProcessHeapO, 0. 256);В этом случае программирование вызова немного усложняется, но получаемыйконечный результат будет, как правило, короче и, что самое важное, работать будет эффективнее. Следует отметить, что далеко не все возможности API доступнычерез обращения к функциям системы программирования.
Непосредственное обращение к API позволяет пользователю обращаться к системным ресурсам болееэффективным способом. Однако это требует знания функций API, количество которых нередко достигает нескольких сотен.Как правило, функции API не стандартизированы.
В каждом конкретном случаенабор вызовов API определяется, прежде всего, архитектурой операционной системы и ее назначением. В то же время, принимаются попытки стандартизироватьнекоторый базовый набор функций, поскольку это существенно облегчило бы перенос приложений с одной операционной системы на другую. Таким примеромможет служить очень известный и, пожалуй, один из самых распространенных стандарт POSIX. В этом стандарте перечислен большой набор функций, их параметров и возвращаемых значений.
Стандартизированными, согласно POSIX, являются не только обращения к API, но и файловая система, организация доступа квнешним устройствам, набор системных команд1. Использование в приложенияхэтого стандарта позволяет в дальнейшем легко переносить такие программы с одной операционной системы в другую путем простейшей перекомпиляции исходного текста.Частным случаем попытки стандартизации API является внутренний корпоративный стандарт компании Microsoft, известный как WinAPI. Он включает в себя следующие реализации: Winl6, Win32s, Win32, WinCE. С точки зрения WinAPI(в силу ряда идеологических причин графический, то есть «оконный», интерфейспользователя обязателен) базовой задачей является окно.
Таким образом, стандарт WinAPI изначально ориентирован на работу в графической среде. Однакобазовые понятия дополнены традиционными функциями, в том числе частичноподдерживается стандарт POSIX.Интерфейс POSIXPOSIX (Portable Operating System Interface for Computer Environments - независимый от платформы системный интерфейс для компьютерного окружения) — этостандарт IEEE (Institute of Electrical and Electronics Engineers - институт инженеров по электротехнике и радиоэлектронике), описывающий системные интер1В данном контексте под системными командами следует понимать некий набор программ, позволяющих управлять вычислительными процессами, например pstat, kill, dir и др.305Интерфейс POSIXфейсы для открытых операционных систем, в том числе оболочки, утилиты и инструментарии.
Помимо этого, согласно POSIX, стандартизированными являютсязадачи обеспечения безопасности, задачи реального времени, процессы администрирования, сетевые функции и обработка транзакций. Стандарт базируется наUNIX-системах, но допускает реализацию и в других операционных системах.Интерфейс POSIX начинался как попытка пропаганды институтом IEEE идейпереносимости приложений в UNIX-средах путем разработки абстрактного независимого от платформы стандарта.
Однако POSIX не ограничивается только UNIXсистемами; существуют различные реализации этого стандарта в системах, которыесоответствуют требованиям, предъявляемым стандартом IEEE Standard 1003.11990 (POSIX.1). Например, известная ОС реального времени QNX соответствуетспецификациям этого стандарта, что облегчает перенос приложений в эту систему, но UNIX-системой не является ни в каком виде, ибо ее архитектура использует абсолютно иные принципы.Этот стандарт подробно описывает систему виртуальной памяти (Virtual MemorySystem, VMS), многозадачность (Multiprocess Executing, МРЕ) и технологию переноса операционных систем (CTOS).
Таким образом, на самом деле POSIX представляет собой множество стандартов POSIX. 1-POSIX. 12. В табл. 9.1 перечислены основные направления, описываемые данными стандартами. Следует такжеособо отметить, что в POSIX.1 основным языком описания системных функцийAPI предполагается язык С.Таблица 9 . 1 . Семейство стандартов POSIXСтандартСтандарт ISOКраткое описаниеPOSIX.0НетВведение в стандарт открытых систем. Данный документне является стандартом в чистом виде, а представляетсобой рекомендации и краткий обзор технологийPOSIX.1ДаСистемный интерфейс API (язык С)POSIX.2НетОболочки и утилиты (одобренные IEEE)POSIX.3НетТестирование и верификацияPOSIX.4НетЗадачи реального времени и потоки выполненияPOSIX.5ДаИспользование языка ADA применительнок стандарту POSIX.
1POSIX.6НетСистемная безопасностьPOSIX.7НетАдминистрирование системыPOSIX.8НетСети, «прозрачный» доступ к файлам, абстрактныесетевые интерфейсы, не зависящие от физическихпротоколов, вызовы RPC, связь системыс приложениями, зависящими от протоколаPOSIX.9ДаИспользование языка Fortran, применительноPOS1X.10НетSuper-computing Application Environment Profile (AEP)pOSIX. 11НетОбработка транзакций АЕРPOSIX.12НетГрафический интерфейс пользователя (GUI)к стандарту POSIX. 1306Глава 9 . Архитектура операционных системТаким образом, программы, написанные с соблюдением данных стандартов, будут одинаково выполняться на всех POSIX-совместимых системах. Однако стандарты отчасти носят всего лишь рекомендательный характер.
Часть стандартовописана очень строго, тогда как другая часть только поверхностно раскрываетосновные требования. Нередко программные системы заявляются как POSIXсовместимые, хотя таковыми их назвать нельзя. Причины кроются в формальномподходе к реализации интерфейса POSIX в различных операционных системах.На рис. 9.1 изображена типовая схема реализации строго соответствующегоPOSIX приложения.Строго соответствущее стандартуPOSIX приложение1к>ГVБиблиотекиPOSIX.1Стандартные библиотекиязыка С (110 функций)i к,11V1Операционная системаРис. 9 . 1 . Схема реализации приложения, строго соответствующего стандарту POSIXИз рисунка видно, что для взаимодействия с операционной системой программаиспользует только библиотеки POSIX.1 и стандартную библиотеку RTL языка С,в которой возможно использование только 110 различных функций, также описанных стандартом POSIX.1.К сожалению, достаточно часто с целью увеличения производительности той илииной подсистемы либо для введения фирменных технологий, которые ограничивают область применения приложения соответствующей операционной средой, при программировании используются другие функции, не отвечающие стандарту POSIX.Реализации стандарта POSIX на уровне операционной системы различны.
ЕслиUNIX-системы в своем абсолютном большинстве изначально соответствуютспецификациям IEEE Standard 1003.1-1990, то WinAPI не является POSIXсовместимым. Однако для его поддержки в операционной системе Windows N1введен специальный модуль API для поддержки стандарта POSIX, работающий на уровне привилегий пользовательских процессов. Данный модуль обеспечивает преобразование и передачу вызовов из пользовательской программык ядру системы и обратно, работая с ядром через WinAPI.
Прочие приложения,написанные с использованием WinAPI, могут передавать информацию POSIXприложениям через стандартные механизмы потоков ввода-вывода stdin иstdout [57].Примеры программированиядля разных интерфейсов APIДля наглядной демонстрации принципиальных различий интерфейсов API наиболее популярных современных операционных систем для персональных компьютеров рассмотрим простейший пример, в котором необходимо подсчитатьколичество пробелов в текстовых файлах, имена которых должны указываться в командной строке.
Рассмотрим два варианта программы: для Windows (с использованием WinAPI) и для Linux (POSIX API).Поскольку нас интересует работа с параллельными задачами, пусть при выполнении программы для каждого из перечисленных в командной строке файлов создается свой процесс или поток выполнения (задача), который параллельно с другими процессами (потоками) производит работу по подсчету пробелов в «своем»файле. Результатом работы программы будет являться список файлов с подсчитанным количеством пробелов для каждого.Следует обратить особое внимание на то, что приведенные ниже реализации программ решения данной задачи не являются единственно возможными.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
