Внедряване на API функции с външни библиотеки
При внедряване на функции на API с помощта на външни библиотеки, тези функции се предоставят на потребителя под формата на библиотека от процедури и функции, създадени от разработчик на трета страна.
Програмната система е отговорна само за свързването на обектния код на библиотеката към получената програма. Освен това външна библиотека може да се зарежда динамично (зарежда се по време на изпълнение на програмата).
По отношение на ефективността на изпълнение, този метод за внедряване на API се представя най-лошо, тъй като външната библиотека има достъп както до функциите на операционната система, така и до функциите на езика за програмиране RTL. Само когато качеството на външната библиотека е много високо, нейната ефективност е сравнима с тази на RTL библиотеката.
Ако говорим за преносимостта на изходния код, то тук има само едно изискване - използваната външна библиотека трябва да е налична във всяка от архитектурите на компютърната система, към която е ориентирана приложната програма. Тогава може да се постигне преносимост. Това е възможно, ако външната библиотека отговаря на някои приети стандарти и системата за програмиране поддържа този стандарт.
Например, библиотеки, които отговарят на стандарта POSIX (вижте следващия раздел), са налични в повечето системи за програмиране на C. И ако една приложна програма използва само библиотеките на този стандарт, тогава нейният изходен код ще бъде преносим. Друг пример е добре познатата библиотека XLib GUI, която поддържа стандарта за графична среда X-Window.
За повечето библиотеки, специфични за разработчици, това не е така. Ако потребителят използва някаква библиотека, тогава се фокусира върху нея
Интерфейс на приложениетопрограмиране_______________________________ 303
ограничен набор от налични архитектури на целевата изчислителна система. Примери за това са библиотеките MFC (Microsoft Foundation Classes) от Microsoft и VCL (Visual Controls Library) от Borland, които са твърдо ориентирани към архитектурата на операционните системи от семейството Windows.
Въпреки това много разработчици сега се стремят да създадат библиотеки, които биха осигурили преносимост на изходния код на приложението между различни архитектури на целевата компютърна система. Досега такива библиотеки не са били широко използвани, но има няколко опита за тяхното внедряване, например библиотеката CLX от Borland е ориентирана към архитектурата на операционните системи от семействата Linux и Windows.
Като цяло, развитието на API функциите се движи в посока на опити за създаване на API библиотеки, които осигуряват широка преносимост на изходния код. Въпреки това, като се вземат предвид корпоративните интереси на различни производители и текущата пазарна ситуация, е малко вероятно в близко бъдеще да бъде постигнат значителен напредък в тази посока. Разработването на широко приложим API стандарт все още е въпрос на бъдещето.
Следователно разработчиците на системни програми са принудени да останат в доста тесните граници на ограниченията на стандартните библиотеки на езиците за програмиране.
Що се отнася до приложните програми, технологиите, свързани с разработката в рамките на архитектурата клиент-сървър или тристепенната архитектура на създаване на приложения, предоставят много по-голяма перспектива за тях. В тази посока водещите производители на операционни системи, СУБД и системи за програмиране са по-склонни да постигнат споразумения, отколкото в посока стандартизация на API.
И така, разгледахме основните принципи, цели и подходи към внедряването на систематаAPI. Нека отбележим още един много важен момент: желателно е програмният интерфейс на приложението да не зависи от програмната система. Разбира се, едно време имаше персонални компютри, в които основната система за програмиране беше интерпретатор от езика Basic, но това е по-скоро изключение. Обикновено API е независим от система за програмиране и може да бъде извикан от всяка система за програмиране, макар и с помощта на подходящите правила за последователност на извиквания. В същото време в някои случаи самата система за програмиране може да генерира извиквания към API. Например, можем да напишем извикване на функция в програмата при поискване от 256 байта памет:
unsigned char * ptr = malloc(256);
Системата за програмиране C ще генерира цяла последователност от повиквания. От кода на потребителската програма ще бъде извикана функцията на библиотеката malloc, чийто код се намира в RTL на езика C. Библиотеката по време на изпълнение в този случай изпълнява извикването на malloc вече като извикване на системната функция на HeapAlloc API:
РАБОТА С hHeap. // манипулатор към блока за частна купчина - указател към блок DWORD dwFlags, // флагове за контрол на разпределението на купчина - свойства на блока
304__________________________ Глава 9 Архитектура на операционната система
DWORD dwBytes // брой байтове за разпределяне - размер на блока):
Параметрите на разпределения блок памет в този случай се задават от системата за програмиране и потребителят не може да ги задава директно. От друга страна, ако е необходимо, функциите на API могат да бъдат извикани директно в текста на програмата:
unsigned char * ptr - (LPVOID) HeapAllocC GetProcessHeapO, 0, 256); В този случай програмирането на разговора е малко по-сложно, но крайният резултат ще бъде,като правило, по-кратък и, най-важното, ще работи по-ефективно. Трябва да се отбележи, че не всички функции на API са достъпни чрез извиквания към функциите на системата за програмиране. Директният достъп до API позволява на потребителя да осъществява достъп до системните ресурси по по-ефективен начин. Това обаче изисква познаване на API функциите, които често наброяват стотици.
Обикновено API функциите не са стандартизирани. Във всеки случай наборът от API извиквания се определя основно от архитектурата на операционната система и нейното предназначение. В същото време се правят опити да се стандартизира някакъв основен набор от функции, тъй като това значително би улеснило пренасянето на приложения от една операционна система към друга. Много известният и може би един от най-разпространените стандарти POSIX може да служи като такъв пример. Този стандарт изброява голям набор от функции, техните параметри и връщани стойности. Стандартизирани, според POSIX, са не само извикванията към API, но и файловата система, организацията на достъпа до външни устройства, набор от системни команди. Използването на този стандарт в приложенията улеснява по-късното прехвърляне на такива програми от една операционна система в друга чрез просто повторно компилиране на изходния код.
Специален случай на опит за стандартизиране на API е вътрешният корпоративен стандарт на Microsoft, известен като WinAPI. Той включва следните реализации: Win 16, Win32s, Win32, WinCE. От гледна точка на WinAPI (поради редица идеологически причини е необходим графичен, т.е. „прозоречен“ потребителски интерфейс), основната задача е прозорец. По този начин стандартът WinAPI първоначално е фокусиран върху работата в графична среда. Основните понятия обаче се допълваттрадиционни функции, включително частична поддръжка на стандарта POSIX.
Интерфейс POSIX
POSIX (Интерфейс на преносима операционна система за компютърни среди - независим от платформата системен интерфейс за компютърна среда) е стандарт на IEEE (Институт на инженерите по електротехника и електроника), който описва системните интерфейси.
В този контекст системните команди трябва да се разбират като набор от програми, които ви позволяват да контролирате изчислителните процеси, например pstat, kill, dir и т.н.
Интерфейс POSIX_________________________________________________ 305
лица за отворени операционни системи, включително черупки, помощни програми и комплекти инструменти. В допълнение, според POSIX, задачите за сигурност, задачите в реално време, административните процеси, мрежовите функции и обработката на транзакции са стандартизирани. Стандартът е базиран на UNIX системи, но може да бъде внедрен и на други операционни системи.
Интерфейсът POSIX започна като опит на IEEE да насърчи преносимостта на приложенията в UNIX среди чрез разработване на абстрактен, независим от платформата стандарт. POSIX обаче не се ограничава до UNIX системи; има различни реализации на този стандарт в системи, които отговарят на изискванията на стандарта IEEE 1003.1-1990 (POSIX.1). Например, добре познатата операционна система в реално време QNX отговаря на спецификациите на този стандарт, което улеснява пренасянето на приложения към тази система, но не е UNIX система под никаква форма, тъй като нейната архитектура използва напълно различни принципи.
Този стандарт описва подробно системата за виртуална памет (Virtual Memory System, VMS),мултитаскинг (Multiprocess Executing, MPE) и технология за трансфер на операционни системи (CTOS). Така че POSIX всъщност е набор от POSIX стандарти. 1-POSIX. 12. В табл. 9.1 изброява основните области, описани от тези стандарти. Трябва също да се отбележи, че в POSIX. 1 се приема, че основният език за описание на системните функции на API е C.
Таблица 9.1. Семейство стандарти POSIX
Стандартен ISO стандарт Кратко описание
POSIX.0 Няма Въведение в стандарта за отворени системи. Този документ
не е стандарт в чист вид, а е препоръка и кратък преглед на технологиите
POSIX.1 Да System API (C език)
POSIX.2 N/A Обвивки и помощни програми (одобрени от IEEE)
POSIX.3 Без тестване и проверка
POSIX.4 Без задачи и нишки за изпълнение в реално време
POSIX.5 Да Използване на езика ADA, ако е приложимо
към стандарта POSIX. 1
POSIX.6 Няма сигурност на системата
POSIX.7 Няма системна администрация
POSIX.8 Без мрежа, "прозрачен" достъп до файлове, абстрактно
мрежови интерфейси, независими от физическите протоколи, RPC повиквания, системна комуникация със зависими от протокола приложения
POSIX.9 Да Използване на езика Fortran, ако е приложимо
към стандарта POSIX. 1
POSIX. 10 Профил без суперкомпютърна среда на приложения (AEP)
POSIX. 11 Няма обработка на AEP транзакция
POSIX. 12 Няма графичен потребителски интерфейс (GUI)
306__________________________ Глава 9 Архитектура на операционната система
По този начин програмите, написани съгласно тези стандарти, ще работят по един и същи начин на всички POSIX-съвместими системи. Стандартите обачеНякои от тях имат само консултативен характер. Някои от стандартите са описани много стриктно, докато друга част само повърхностно разкрива основните изисквания. Не е необичайно за софтуерните системи да се твърди, че са съвместими с POSIX, когато не са. Причините се крият във формалния подход за внедряване на POSIX интерфейса на различни операционни системи. На фиг. Фигура 9.1 показва типична реализация на стриктно съвместимо с POSIX приложение.
Ориз. 9.1. Схема за внедряване на строго POSIX-съвместимо приложение
Фигурата показва, че програмата използва само POSIX библиотеки за взаимодействие с операционната система. 1 и стандартната C RTL библиотека, която позволява да се използват само 110 различни функции, също описани от стандарта POSIX. 1.
За съжаление, доста често, за да се увеличи производителността на определена подсистема или да се въведат патентовани технологии, които ограничават обхвата на приложението до съответната операционна среда, програмирането използва други функции, които не отговарят на стандарта POSIX.
Реализациите на стандарта POSIX на ниво операционна система са различни. Ако по-голямата част от UNIX системите първоначално отговарят на спецификациите на IEEE Standard 1003.1-1990, тогава WinAPI не е съвместим с POSIX. Въпреки това, за да го поддържа в операционната система Windows NT, е въведен специален API модул за поддръжка на стандарта POSIX, който работи на ниво привилегии на потребителските процеси. Този модул осигурява трансформация и прехвърляне на повиквания от потребителската програма към системното ядро и обратно, работейки с ядрото чрез WinAPI. Други приложения, написани с помощта на WinAPI, могат да предават POSIX информация на приложения чрезстандартни I/O поточни механизми stdin и stdout [57].
Примери за програмиране за различни API__________________ 307