În acest articol aș dori să vorbesc despre ce sunt programele de aplicație, precum și despre sarcinile aplicației care pot fi rezolvate cu ajutorul lor (de exemplu, un exemplu de bază de date simplă) și ce rol joacă ele pentru utilizatorul final al unei baze de date personale. calculator. În primul rând, aș dori să remarc că computerele pot prelucra orice date pe care utilizatorul i le trimite. Dar pentru ca aceste date să fie recunoscute și înțelese corect de către mașină, este necesar să se compună un program special într-un limbaj pe care îl înțelege sau, mai simplu, o serie de instrucțiuni secvențiale pentru efectuarea anumitor acțiuni.

Tipuri de programe aplicative

Programele de aplicare sunt astfel de programe, al căror scop are ca scop rezolvarea anumitor probleme și interacțiunea directă cu utilizatorul. Sunt necesare programe de calculator pentru automatizarea oricăror procese, stocare și prelucrare a datelor, modelare, proiectare etc. procese de calcul complexe. Programele sunt în general împărțite în două clase: programe de sistem și programe de aplicație. Primele sunt utilizate în principal pentru a procesa informațiile primite de la unele echipamente: o placă de rețea, o placă video, echipamente conectate, de ex. acestea sunt programe care interacționează cu hardware sau dispozitive externe. Despre ele vom vorbi în articolele următoare. Dar despre al doilea - programe aplicate, să vorbim mai detaliat.

Programele de aplicație sunt concepute pentru a interacționa cu utilizatorul final, de ex. utilizatorul, parcă, interacționează cu el însuși, dar numai prin program, introduce orice date la intrare și primește un anumit rezultat al datelor procesate la ieșire. Acesta este un fel de decizie pentru un anumit sarcina aplicata, de exemplu, este scanarea imaginilor și prelucrarea lor ulterioară sau căutarea fișierelor dorite. Utilizarea programelor de aplicație poate fi observată în aproape toate sferele activității umane, fie că este vorba de contabilitate la o întreprindere sau de creare de imagini grafice, desen etc. De asemenea, utilizarea programelor de aplicație este prezentă în sisteme atât de importante precum sistemele de gestionare a bazelor de date. Acest lucru este foarte important în întreprinderile mari în care lucrează un număr mare de utilizatori și care chiar au nevoie să stocheze și să utilizeze cantități mari de informații.

Tipuri și exemple de programe de aplicație

Programele de aplicare sunt:

• Editori de text. Proiectat pentru crearea și editarea textului fără decorațiuni;
• Procesoare de text (MS Word). Editore de text mai avansate care vă permit să editați text cu design, să schimbați fonturile și dimensiunile acestuia, să inserați fișiere grafice, tabele etc. pentru un design text mai prezentabil;
• Tabele electronice (MS Excell). Ele sunt utilizate în principal pentru a prelucra orice date conținute în aceste tabele. Sarcini aplicate cel mai adesea sunt efectuate pentru a stoca acreditările cu analiza lor ulterioară;
• Editori de grafică raster și vectorială (Photoshop, Corel), „spectatori”. Utilizarea programelor de aplicație de acest tip vă permite să creați, editați, precum și să vizualizați imagini grafice;
• Playere audio video, editori (WinAmp). Vă permite să vizualizați videoclipuri, să ascultați muzică, să creați compoziții muzicale;
• Sisteme de gestionare a bazelor de date (de exemplu - MSQL). Astfel de programe sunt folosite pentru a lucra cu baze de date. De exemplu, un program de contabilitate a clienților este o bază de date simplă pentru stocarea informațiilor despre clienți, informațiile de contact ale acestora etc. Puteți efectua operațiuni pentru a găsi, șterge și adăuga înregistrări în baza de date;
• Traducători sau dicționare electronice. Astfel de programe de aplicație vă permit să traduceți fără efort text în diferite limbi străine, fără a le studia direct;
• Jocuri pe calculator. Folosit pentru divertisment sau pentru dezvoltare într-un mod ludic.

Un exemplu de aplicație este, de exemplu, un program de numărare repost. Este dificil să enumeram toate tipurile de programe de aplicație, dar am încercat să evidențiem principalele programe de aplicație.

Utilizare medii software aplicate simplifică sarcina de a rula aplicații scrise pentru un sistem de operare pe altul . Practic, mediul aplicației ar trebui să includă funcțiile interfeței de solicitare a programului, precum și mijloacele de organizare a coexistenței fără conflicte în cadrul unui sistem de operare a mai multor moduri de gestionare a resurselor computerului.

Un mediu de aplicație poate fi implementat ca o aplicație obișnuită și apoi funcționează la nivel de utilizator.

Orez. 2.8. Medii de programare a aplicațiilor care traduc apelurile de sistem

Într-o altă implementare a mai multor medii de aplicații, sistemul de operare are mai multe interfețe de programare a aplicațiilor de la egal la egal. În exemplul prezentat în fig. Exemplul de sistem de operare 2.9 acceptă aplicații scrise pentru OS1, OS2 și OS3. Pentru a face acest lucru, interfețele de programare a aplicațiilor ale tuturor acestor sisteme de operare sunt situate direct în spațiul kernel al sistemului: API OS1, API OS2 și API OS3.

Funcțiile fiecărui API sunt implementate de kernel, ținând cont de specificul OS-ului corespunzător, chiar dacă au un scop similar. Pentru ca nucleul să aleagă implementarea dorită a apelului de sistem, fiecare proces trebuie să transmită nucleului un set de caracteristici de identificare.

Orez. 2.9. Implementarea interoperabilității bazată pe mai multe API peer

concluzii

· Toate programele software ale unui sistem informatic sunt împărțite în aplicate (pentru rezolvarea problemelor utilizatorului) și sistem (pentru utilizarea hardware-ului computerului).

· Cea mai simplă structurare a sistemului de operare constă în împărțirea tuturor componentelor sistemului de operare în module care îndeplinesc principalele funcții ale sistemului de operare (kernel) și module care îndeplinesc funcții auxiliare ale sistemului de operare. Modulele de suport OS sunt proiectate fie ca aplicații (utilități și programe de procesare a sistemului), fie ca biblioteci de proceduri. Modulele auxiliare sunt încărcate în RAM numai pe durata funcțiilor lor, adică sunt tranzitorii. Modulele kernel sunt rezidente în RAM, adică sunt rezidente.

· Dacă există suport hardware pentru moduri cu diferite niveluri de autoritate, stabilitatea sistemului de operare poate fi mărită prin executarea funcțiilor kernelului în modul privilegiat, iar modulele auxiliare ale sistemului de operare și aplicațiile în modul utilizator. Acest lucru face posibilă protejarea codurilor și datelor ale sistemului de operare și aplicațiilor împotriva accesului neautorizat. Sistemul de operare poate acționa ca un arbitru în litigiile de aplicare cu privire la resurse.

· Orice sistem de operare pentru a-și rezolva sarcinile interacționează cu hardware-ul computerului, și anume: mijloace de susținere a modului privilegiat și traducerea adresei, mijloace de comutare a proceselor și de protejare a zonelor de memorie, un sistem de întrerupere și un cronometru de sistem. Acest lucru face ca mașina OS să fie dependentă, legată de o anumită platformă hardware.

Arhitectura microkernel este o alternativă la modul clasic de construire a unui sistem de operare, în conformitate cu care toate funcțiile principale ale sistemului de operare care alcătuiesc un nucleu multistrat sunt îndeplinite într-un mod privilegiat. În sistemele de operare microkernel, doar o foarte mică parte a sistemului de operare rămâne în modul privilegiat. , numit microkernel.Toate celelalte funcții de nivel înalt ale nucleului sunt implementate ca aplicații în modul utilizator.

· Mediu software de aplicație - un set de instrumente OS concepute pentru a organiza execuția aplicațiilor create pentru un OS în altul. Fiecare sistem de operare creează cel puțin un mediu de programare a aplicațiilor. Problema constă în asigurarea compatibilității mai multor medii software în cadrul aceluiași sistem de operare.

În timp ce multe dintre caracteristicile arhitecturale ale sistemului de operare privesc în mod direct doar programatorii de sistem, conceptul de instrumente de aplicații multiple (de operare) este direct legat de nevoile utilizatorilor finali - capacitatea sistemului de operare de a rula aplicații scrise pentru alte sisteme de operare. Această proprietate a sistemului de operare se numește compatibilitate.

Compatibilitatea aplicației poate fi la nivel binar și la nivel de sursă. Aplicațiile sunt de obicei stocate în sistemul de operare ca fișiere executabile care conțin imagini binare de cod și date. Compatibilitatea binară este obținută dacă puteți lua un program executabil și îl puteți rula într-un alt mediu de operare.

Compatibilitatea surselor necesită un compilator adecvat în software-ul computerului pe care intenționați să rulați aplicația, precum și compatibilitatea cu bibliotecile și apelurile de sistem. În acest caz, este necesar să recompilați codul sursă al aplicației într-un nou modul executabil.

Compatibilitatea surselor este importantă în primul rând pentru dezvoltatorii de aplicații care au cod sursă la dispoziție. Dar pentru utilizatorii finali, doar compatibilitatea binară este de importanță practică, deoarece numai în acest caz pot folosi același produs pe sisteme de operare diferite și pe mașini diferite.

Tipul de compatibilitate posibilă depinde de mulți factori. Cea mai importantă dintre acestea este arhitectura procesorului. Dacă procesorul folosește același set de instrucțiuni (eventual cu completări, ca în cazul PC-ului IBM: set standard + multimedia + grafică + streaming) și același interval de adrese, atunci compatibilitatea binară poate fi realizată destul de simplu. Pentru a face acest lucru, trebuie îndeplinite următoarele condiții:

• API-ul utilizat de aplicație trebuie să fie suportat de sistemul de operare dat;
• structura internă a fișierului executabil al aplicației trebuie să corespundă structurii fișierelor executabile ale sistemului de operare dat.

Dacă procesoarele au arhitecturi diferite, atunci, pe lângă condițiile enumerate, este necesar să se organizeze emularea codului binar. De exemplu, emularea comenzilor procesorului Intel pe procesorul Motorola 680x0 al unui computer Macintosh este utilizată pe scară largă. Emulatorul software selectează apoi secvenţial instrucţiunea binară a procesorului Intel şi execută subrutina echivalentă scrisă în instrucţiunile procesorului Motorola. Deoarece procesorul Motorola nu are exact aceleași registre, steaguri, ALU intern etc., ca la procesoarele Intel, trebuie să simuleze (emuleze) toate aceste elemente folosind registrele sau memoria sa.

Aceasta este o muncă simplă, dar foarte lentă, deoarece o singură comandă Intel este semnificativ mai rapidă decât secvența de comandă a procesorului Motorola care o emulează. Ieșirea în astfel de cazuri este utilizarea așa-numitelor medii software de aplicație sau medii de operare. Una dintre componentele unui astfel de mediu este setul de funcții API pe care sistemul de operare le oferă aplicațiilor sale. Pentru a reduce timpul petrecut cu executarea programelor altcuiva, mediile de aplicații imită apelurile la funcțiile bibliotecii.

Eficacitatea acestei abordări se datorează faptului că majoritatea programelor de astăzi rulează sub GUI (Graphical User Interfaces) precum Windows, MAC sau UNIX Motif, în timp ce aplicațiile petrec 60-80% din timp executând funcții GUI și alte apeluri de bibliotecă OS. Această proprietate a aplicațiilor este cea care permite mediilor de aplicații să compenseze cantitatea mare de timp petrecută emulând programe pe comandă. Un mediu de aplicații software conceput cu grijă conține biblioteci care imită bibliotecile GUI, dar sunt scrise în cod „nativ”. Astfel, se realizează o accelerare semnificativă a execuției programelor cu API-ul altui sistem de operare. Această abordare se mai numește și difuzare pentru a o diferenția de procesul de emulare mai lent o comandă la un moment dat.

De exemplu, pentru un program Windows care rulează pe un Macintosh, la interpretarea comenzilor de la un procesor Intel performanţă poate fi foarte scăzută. Dar când se apelează o funcție GUI, se deschide o fereastră etc., modulul OS care implementează mediul de aplicație Windows poate intercepta acest apel și îl poate redirecționa către rutina de deschidere a ferestrei care este recompilată pentru procesorul Motorola 680x0. Drept urmare, în astfel de părți ale codului, viteza programului poate atinge (și, eventual, depăși) viteza de lucru pe propriul procesor.

Pentru ca un program scris pentru un sistem de operare să fie executat pe un alt sistem de operare, nu este suficient doar să se asigure compatibilitatea API. Conceptele din spatele diferitelor sisteme de operare pot intra în conflict între ele. De exemplu, într-un sistem de operare, unei aplicații i se poate permite să controleze dispozitivele I/O, în altul - aceste acțiuni sunt apanajul sistemului de operare.

Fiecare sistem de operare are propriile mecanisme de protecție a resurselor, propriile algoritmi de tratare a erorilor și excepțiilor, o structură specifică a procesorului și o schemă de gestionare a memoriei, propria semantică de acces la fișiere și interfață grafică cu utilizatorul. Pentru a asigura compatibilitatea, este necesar să se organizeze coexistența fără conflicte în cadrul unui sistem de operare a mai multor metode de gestionare a resurselor computerului.

Există diverse opțiuni pentru construirea de medii de aplicații multiple, care diferă atât prin caracteristici arhitecturale, cât și prin funcționalitate, care oferă grade diferite de portabilitate a aplicațiilor. Una dintre cele mai evidente opțiuni pentru implementarea mai multor medii de aplicații se bazează pe o structură standard de sistem de operare.

O altă modalitate de a construi mai multe medii de aplicație se bazează pe o abordare microkernel. În același timp, este foarte important de remarcat diferența de bază, comună pentru toate mediile de aplicație, între mecanismele sistemului de operare și funcțiile de nivel înalt specifice fiecăruia dintre mediile de aplicație care rezolvă probleme strategice. În conformitate cu arhitectura microkernel toate funcțiile OS sunt implementate de microkernel și servere în modul utilizator. Este important ca mediul aplicației să fie conceput ca un server separat în modul utilizator și să nu includă mecanisme de bază.

Aplicațiile care utilizează API-ul efectuează apeluri de sistem către mediul de aplicație adecvat prin microkernel. Mediul aplicației procesează cererea, o execută (poate folosind funcții de bază ale microkernelului pentru ajutor) și trimite rezultatul înapoi la aplicație. În cursul executării unei cereri, mediul aplicației trebuie, la rândul său, să acceseze mecanismele de bază ale sistemului de operare implementate de microkernel și alte servere de sistem de operare.

Toate avantajele și dezavantajele arhitecturii micro-nucleare sunt inerente acestei abordări a construcției de medii de aplicații multiple, în special:

• este foarte ușor să adăugați și să excludeți medii de aplicație, ceea ce este o consecință a bunei extensibilități a sistemului de operare micro-kernel;
• dacă unul dintre mediile de aplicație eșuează, restul rămân operaționale, ceea ce contribuie la fiabilitatea și stabilitatea sistemului în ansamblu;
• performanța scăzută a sistemelor de operare microkernel afectează viteza instrumentelor de aplicație și, prin urmare, viteza aplicațiilor.

În consecință, trebuie remarcat faptul că crearea mai multor instrumente de aplicație în cadrul unui sistem de operare pentru executarea aplicațiilor diferitelor sisteme de operare este o modalitate care vă permite să aveți o singură versiune a programului și să o transferați între diferite sisteme de operare. Mai multe medii de aplicații oferă compatibilitate binară a unui anumit sistem de operare cu aplicațiile scrise pentru alte sisteme de operare.

1.9. Mașinile virtuale ca abordare modernă a implementării mai multor medii de aplicații

Conceptul de „monitor al mașinii virtuale” (VMM) a apărut la sfârșitul anilor ’60 ca un software nivelul de abstractizare care a împărțit platforma hardware în mai multe mașini virtuale. Fiecare dintre aceste mașini virtuale (VM) era atât de asemănătoare cu mașina fizică subiacentă decât cea existentă software ar putea fi executat pe el neschimbat. La acea vreme, sarcinile generale de calcul erau efectuate pe mainframe scumpe (cum ar fi IBM / 360), iar utilizatorii apreciau capacitatea VMM de a distribui resurse limitate în mai multe aplicații.

În anii 80-90, costul echipamentelor informatice a scăzut semnificativ și eficient sistem de operare multitasking, care a redus valoarea VMM-ului în ochii utilizatorilor. Mainframe-urile au făcut loc mini-calculatoarelor și apoi PC-urilor și nu a fost nevoie de un VMM. Drept urmare, arhitectura computerului a dispărut pur și simplu hardware pentru implementarea lor eficientă. Până la sfârșitul anilor 80, în știință și în producție, MVM erau percepute ca nimic mai mult decât o curiozitate istorică.

Astăzi, MVM este din nou în centrul atenției. Intel, AMD, Sun Microsystems și IBM creează strategii de virtualizare, iar abordările bazate pe mașini virtuale evoluează în mediul academic și universități pentru a aborda problemele de mobilitate, securitate și gestionare. Ce s-a întâmplat între demisia MVM și renașterea lor?

În anii 1990, cercetătorii de la Universitatea Stanford au început să exploreze utilizarea VM-urilor pentru a depăși limitările hardware-ului și ale sistemelor de operare. Au apărut probleme cu computerele cu procesare masivă paralelă (MPP), care erau greu de programat și nu puteau rula sistemele de operare existente. Cercetătorii au descoperit că mașinile virtuale pot face această arhitectură incomodă suficient de asemănătoare cu platformele existente pentru a profita de sistemele de operare de pe raft. Din acest proiect au venit oamenii și ideile care au devenit rezerva de aur a VMware (www.vmware.com), primul furnizor de VMM-uri pentru computerele mainstream.

În mod ironic, avansarea sistemelor de operare moderne și reducerea costurilor hardware au dus la probleme pe care cercetătorii sperau să le rezolve cu ajutorul VMM-ului. Ieftinitatea echipamentelor a contribuit la răspândirea rapidă a computerelor, dar acestea au fost adesea subutilizate, necesitând spațiu suplimentar și efort pentru întreținere. Și consecințele creșterii capacităților funcționale ale sistemului de operare au fost instabilitatea și vulnerabilitatea lor.

Pentru a reduce impactul blocărilor de sistem și pentru a proteja împotriva hackurilor, administratorii de sistem au apelat din nou la o singură sarcină modelul de calcul(cu o aplicație pe o singură mașină). Acest lucru a dus la costuri suplimentare din cauza cerințelor hardware crescute. Mutarea aplicațiilor de la diferite mașini fizice la VM și consolidarea acestor VM pe câteva platforme fizice au permis creșterea gradului de utilizare a echipamentelor, reducerea costurilor de management și reducerea spațiului. Așadar, capacitatea VMM de a multiplexa hardware-ul – de data aceasta în numele consolidării serverelor și al calculului utilitar – le-a readus la viață.

În zilele noastre, VMM a devenit nu atât un instrument de organizare a multitasking-ului, cât a fost cândva conceput ca o soluție la problemele de asigurare a securității, mobilității și fiabilității. În multe privințe, VMM oferă creatorilor de sisteme de operare capacitatea de a dezvolta funcționalități care nu sunt posibile în sistemele de operare complexe de astăzi. Caracteristici precum migrarea și securitatea sunt mult mai convenabile de implementat la nivel de VMM, care menține compatibilitatea cu înapoi atunci când implementează soluții inovatoare de sistem de operare, păstrând în același timp progresele anterioare.

Virtualizarea este o tehnologie în evoluție. În termeni generali, virtualizarea vă permite să decuplați software-ul de infrastructura hardware de bază. De fapt, rupe legătura dintre un anumit set de programe și un anumit computer. Monitorul mașinii virtuale se separă software din hardware și formează un strat intermediar între software-ul rulat de mașinile virtuale și hardware. Acest nivel permite VMM să controleze pe deplin utilizarea resurselor hardware. sisteme de operare invitate (GuestOS) care rulează pe VM.

VMM creează o vedere unificată a hardware-ului de bază, astfel încât mașinile fizice de la diferiți furnizori cu subsisteme I/O diferite să arate la fel și mașinile virtuale să ruleze pe orice hardware disponibil. Fără a-și face griji în legătură cu mașinile individuale cu interconexiunile lor strânse între hardware și software, administratorii pot vedea hardware-ul ca un simplu grup de resurse pentru a furniza orice serviciu la cerere.

Mulțumită încapsulare completă Monitorul VMM poate mapa mașina virtuală la orice resurse hardware disponibile și chiar o poate transfera de la o mașină fizică la alta. Sarcina de a echilibra sarcina unui grup de mașini devine trivială, iar modalități fiabile de a face față defecțiunilor echipamentelor și creșterii sistemului apar. Dacă trebuie să închideți un computer eșuat sau să puneți unul nou în funcțiune, VMM-ul poate redistribui mașinile virtuale în consecință. Mașina virtuală este ușor de replicat, permițând administratorilor să furnizeze rapid noi servicii după cum este necesar.

Încapsularea înseamnă, de asemenea, că administratorul poate suspenda sau relua o VM în orice moment, precum și să salveze starea curentă a mașinii virtuale sau să o revină la o stare anterioară. Cu capabilități universale de anulare, este ușor să faceți față accidentelor și erorilor de configurare. Încapsularea se află în centrul unui model de mobilitate generic, deoarece o VM suspendată poate fi copiată în rețea, stocată și transportată pe medii amovibile.

VMM acționează ca un intermediar pentru toate interacțiunile dintre VM și hardware-ul de bază, menținând mai multe mașini virtuale care rulează pe o singură platformă hardware și oferind o izolare fiabilă. VMM vă permite să asamblați un grup de VM cu cerințe reduse de resurse pe un computer separat, reducând costul hardwareși nevoia de spațiu de producție.

Izolarea completă este, de asemenea, importantă pentru fiabilitate și siguranță. Aplicațiile care rulau pe aceeași mașină pot fi acum distribuite pe diferite VM. Dacă una dintre ele, ca urmare a unei erori, provoacă blocarea sistemului de operare, alte aplicații vor fi izolate de acesta și vor continua să funcționeze. Dacă una dintre aplicații este amenințată de un atac extern, atacul va fi localizat în VM „compromisă”. Astfel, VMM este un instrument de restructurare a sistemului pentru a-i crește rezistența și securitatea, fără a necesita spațiul suplimentar și efortul administrativ necesar la rularea aplicațiilor pe mașini fizice separate.

VMM-ul trebuie să asocieze interfața hardware cu VM-ul păstrând în același timp controlul deplin asupra mașinii de bază și a procedurilor de interacțiune cu hardware-ul său. Există diferite metode pentru a atinge acest obiectiv, bazate pe anumite compromisuri tehnice. Când se caută astfel de compromisuri, se iau în considerare principalele cerințe pentru VMM: compatibilitate, performanţă si simplitate. Compatibilitatea este importantă deoarece principalul avantaj al unui VMM este capacitatea de a rula aplicații vechi. Performanţă determină cantitatea de overhead de virtualizare - programele de pe o VM trebuie să ruleze la aceeași viteză ca pe o mașină reală. Simplitatea este necesară deoarece o defecțiune a VMM va duce la defecțiunea tuturor VM-urilor care rulează pe computer. În special, izolarea securizată necesită ca VMM-ul să nu aibă erori pe care atacatorii le pot folosi pentru a distruge sistemul.

În loc de a modifica rescrierea complexă a codului sistemului de operare invitat, puteți face unele modificări sistemului de operare gazdă, schimbând unele dintre părțile mai „enervante” ale nucleului. Această abordare se numește paravirtualizare. Este clar că în acest caz doar autorul poate adapta nucleul sistemului de operare și, de exemplu, Microsoft nu manifestă nicio dorință de a adapta popularul nucleu Windows 2000 la realitățile mașinilor virtuale specifice.

În paravirtualizare, designerul VMM redefinește interfața mașinii virtuale, înlocuind subsetul nevirtualizabil al setului de instrucțiuni original cu echivalente mai convenabile și mai eficiente. Rețineți că, deși sistemul de operare trebuie portat pentru a rula pe aceste mașini virtuale, cele mai comune aplicații pot rula neschimbate.

Cel mai mare dezavantaj al paravirtualizării este incompatibilitatea. Orice sistem de operare conceput pentru a rula sub controlul unui monitor VMM paravirtualizat, trebuie portat la această arhitectură prin negocierea cooperării cu furnizorii de sisteme de operare. În plus, sistemele de operare vechi nu pot fi utilizate, iar mașinile existente nu pot fi înlocuite cu ușurință cu mașini virtuale.

Pentru a obține performanțe ridicate și compatibilitate la virtualizarea arhitecturii x86, VMware a dezvoltat o nouă tehnică de virtualizare care combină execuția live tradițională cu traducerea binară rapidă, din mers. În majoritatea sistemelor de operare moderne, modurile de operare ale procesorului la executarea programelor de aplicație obișnuite sunt ușor virtualizate și, prin urmare, pot fi virtualizate prin execuție directă. Modurile privilegiate nepotrivite pentru virtualizare pot fi executate de traducătorul binar, reparând instrucțiuni „incomode” x86. Rezultatul este un foarte eficient mașină virtuală care se potrivește pe deplin cu hardware-ul și menține compatibilitatea completă cu software-ul.

Codul convertit este foarte asemănător cu rezultatele paravirtualizării. Comenzile obișnuite sunt executate neschimbate, iar comenzile care necesită procesare specială (cum ar fi POPF și comenzile pentru citirea registrelor de segmente de cod) sunt înlocuite de traducător cu secvențe de comenzi care sunt similare cu cele necesare pentru execuția pe o mașină virtuală paravirtualizată. Totuși, există o diferență importantă: în loc să modifice codul sursă al sistemului de operare sau al aplicațiilor, traducătorul binar modifică codul prima dată când este executat.

Deși sunt necesare unele cheltuieli suplimentare pentru a traduce codul binar, este neglijabilă în condiții normale de lucru. Traducatorul procesează doar o parte din cod, iar viteza de execuție a programului devine comparabilă cu viteza de execuție directă - de îndată ce memoria cache este plină

Calea de ieșire în astfel de cazuri este să folosiți așa-numitul medii software aplicate. Una dintre componentele care formează mediul de programare a aplicațiilor este un set de funcții API pe care sistemul de operare le oferă aplicațiilor sale. Pentru a reduce timpul petrecut cu executarea programelor altcuiva, mediile de aplicații imită apelurile la funcțiile bibliotecii.

Eficacitatea acestei abordări provine din faptul că majoritatea programelor de astăzi rulează pe interfețe grafice de utilizator (Interfețe grafice de utilizator) precum Windows, Mac sau UNIX Motif, aplicațiile petrecându-și majoritatea timpului realizând un comportament bine previzibil. Ei efectuează în mod continuu apeluri către bibliotecile GUI pentru manipularea ferestrelor și alte activități legate de GUI. Astăzi, în programele tipice, 60-80% din timp este petrecut executând funcții GUI și alte apeluri de bibliotecă OS. Această proprietate a aplicațiilor este cea care permite mediilor de aplicații să compenseze cantitatea mare de timp petrecută emulând un program o comandă la un moment dat. Un mediu de aplicație software atent conceput conține biblioteci care imită bibliotecile GUI interne, dar sunt scrise în cod „nativ”, iar acest lucru accelerează semnificativ execuția programelor cu API-uri ale altui sistem de operare. Această abordare este uneori denumită traducere pentru a o diferenția de procesul mai lent de emulare a codului câte o instrucțiune pe rând.

De exemplu, pentru un program Windows care rulează pe un Macintosh, interpretarea comenzilor de la un procesor Intel 80x86 poate fi foarte lentă. Dar atunci când este apelată o funcție GUI de deschidere a ferestrei, un modul OS care implementează mediul de aplicație Windows poate intercepta acest apel și îl poate redirecționa către rutina de deschidere a ferestrei care este recompilată pentru procesorul Motorola 680x0. Drept urmare, în astfel de părți ale codului, viteza programului poate atinge (și, eventual, depăși) viteza de lucru pe procesorul său „nativ”.

Pentru ca un program scris pentru un sistem de operare să fie executat pe un alt sistem de operare, nu este suficient doar să se asigure compatibilitatea API. Conceptele din spatele diferitelor sisteme de operare pot intra în conflict între ele. De exemplu, într-un sistem de operare, unei aplicații i se poate permite să controleze direct dispozitivele I/O, în altul, aceste acțiuni sunt apanajul sistemului de operare. Fiecare sistem de operare are propriile mecanisme de protecție a resurselor, propriile algoritmi de tratare a erorilor și excepțiilor, o structură specifică de proces și o schemă de gestionare a memoriei, propria semantică de acces la fișiere și interfață grafică cu utilizatorul. Pentru a asigura compatibilitatea, este necesar să se organizeze coexistența fără conflicte în cadrul unui sistem de operare a mai multor metode de gestionare a resurselor computerului.

3. 7. 3. Metode de implementare a mediilor software aplicate

Crearea unui mediu de aplicație cu drepturi depline, pe deplin compatibil cu mediul altui sistem de operare, este o sarcină destul de complexă, strâns legată de structura sistemului de operare. Există diverse opțiuni pentru construirea de medii de aplicații multiple, care diferă atât prin caracteristicile soluțiilor arhitecturale, cât și prin funcționalitatea care oferă grade diferite de portabilitate a aplicațiilor.

În multe versiuni ale sistemului de operare UNIX, traducătorul de mediu al aplicației este implementat ca o aplicație obișnuită. În sistemele de operare construite folosind conceptul de microkernel, cum ar fi Windows NT, mediile de aplicații rulează ca servere în modul utilizator. Și în OS / 2, cu arhitectura sa mai simplă, instrumentele pentru organizarea mediilor de aplicații sunt integrate adânc în sistemul de operare.

Una dintre cele mai evidente opțiuni pentru implementarea mai multor medii de aplicații se bazează pe o structură standard de sistem de operare. În fig. 3. 8 sistemul de operare OS1 suportă, pe lângă aplicațiile sale „native”, aplicații ale sistemului de operare OS2. Pentru aceasta, conține o aplicație specială - un mediu software de aplicație care traduce interfața sistemului de operare „străin” - API OS2 în interfața sistemului său de operare „nativ” - API OS1.

Orez. 3. 8. Mediu software de aplicație care traduce apelurile de sistem

Într-o altă implementare a mai multor medii de aplicații, sistemul de operare are mai multe API peer. În exemplul prezentat în fig. 3. De exemplu, sistemul de operare acceptă aplicații scrise pentru OS1, OS2 și OS3. Pentru a face acest lucru, interfețele de programare a aplicațiilor ale tuturor acestor sisteme de operare sunt situate direct în spațiul kernel al sistemului: API OS1, API OS2 și API OS3.

Orez. 3. 9. Implementarea interoperabilității bazată pe mai multe API peer

În această variantă, funcțiile la nivel de API se referă la funcții de sistem de operare de nivel inferior care trebuie să accepte toate cele trei medii de aplicații în general incompatibile. Sistemele de operare diferite gestionează ora sistemului în mod diferit, utilizează un format diferit de oră din zi, partajează timpul procesorului pe baza propriilor algoritmi etc. Funcțiile fiecărui API sunt implementate de kernel, ținând cont de specificul sistemului de operare corespunzător, chiar și dacă au un scop similar.

O altă modalitate de a construi mai multe medii de aplicație se bazează pe o abordare microkernel. În același timp, este foarte important să se separe mecanismele de bază ale sistemului de operare comune tuturor mediilor de aplicații de funcțiile de nivel înalt specifice fiecăruia dintre mediile de aplicații care rezolvă probleme strategice.

Conform arhitecturii microkernel-ului, toate funcțiile OS sunt implementate de microkernel și servere în modul utilizator. Este important ca fiecare mediu de aplicație să fie proiectat ca un server separat în modul utilizator și să nu includă mecanisme de bază (Fig. 3. 10). Aplicațiile care utilizează API-ul efectuează apeluri de sistem către mediul de aplicație adecvat prin microkernel. Mediul aplicației procesează cererea, o execută (poate folosind funcții de bază ale microkernelului pentru ajutor) și trimite rezultatul înapoi la aplicație. În cursul executării unei cereri, mediul aplicației trebuie, la rândul său, să acceseze mecanismele de bază ale sistemului de operare implementate de microkernel și alte servere de sistem de operare.

Orez. 3. 10. Abordarea microkernel pentru implementarea mai multor medii de aplicații

Această abordare a construcției de medii de aplicații multiple are toate avantajele și dezavantajele unei arhitecturi microkernel, în special:

este foarte ușor să adăugați și să excludeți medii de aplicații, ceea ce este o consecință a bunei extensibilități a sistemelor de operare microkernel;

fiabilitatea și stabilitatea se exprimă în faptul că, dacă unul dintre mediile de aplicație eșuează, toate celelalte rămân operaționale;

performanța scăzută a sistemelor de operare microkernel afectează viteza mediilor de aplicație și, prin urmare, viteza de execuție a aplicației.

Crearea mai multor medii de aplicații în cadrul unui sistem de operare pentru executarea aplicațiilor de diferite sisteme de operare este o modalitate care vă permite să aveți o singură versiune a programului și să o transferați între sistemele de operare. Mai multe medii de aplicații oferă compatibilitate binară a unui anumit sistem de operare cu aplicațiile scrise pentru alte sisteme de operare. Drept urmare, utilizatorii au o mai mare libertate de alegere a sistemelor de operare și un acces mai ușor la software de calitate.

Întrebări de autotest

Ce se înțelege prin arhitectură OS?

Care sunt cele trei straturi principale din structura unui sistem de calcul?

Care este rolul sistemului de operare pe interfața de apel de sistem?

Ce condiții trebuie îndeplinite la proiectarea unui sistem de operare pentru ca sistemul de operare să fie ușor de portat?

Care este diferența dintre arhitectura microkernel și arhitectura tradițională a sistemului de operare?

De ce este un microkernel bine potrivit pentru a sprijini calculul distribuit?

Ce se înțelege prin conceptul de medii de aplicații multiple?

Care este esența metodei traducerii bibliotecii?

Compatibilitate și medii de aplicații multiple

Conceptul de medii de aplicații multiple se referă la nevoile utilizatorului final - capacitatea unui sistem de operare de a rula aplicații din alte sisteme de operare. Această proprietate a sistemului de operare este numită compatibilitate.

Compatibilitate binară și sursă

Distinge între compatibilitatea binară și compatibilitatea surselor. Aplicațiile sunt de obicei stocate în sistemul de operare ca fișiere executabile care conțin imagini binare de cod și date. Compatibilitatea binară este obținută atunci când puteți lua un program executabil și îl puteți rula într-un alt mediu de operare.

Compatibilitatea surselor necesită un compilator adecvat în software-ul computerului pe care intenționați să rulați aplicația, precum și compatibilitatea cu bibliotecile și apelurile de sistem. În acest caz, este necesar să compilați sursele disponibile într-un modul executabil.

Compatibilitatea surselor este importantă în primul rând pentru dezvoltatorii de aplicații care au cod sursă la dispoziție. Pentru utilizatorii finali, doar compatibilitatea binară este de importanță practică, deoarece numai în acest caz pot folosi același produs comercial sub formă de cod binar executabil în diferite medii de operare.

Dacă un sistem de operare este binar sau compatibil cu sursa depinde de mulți factori. Principalul dintre ele este arhitectura procesorului pe care rulează noul sistem de operare. Dacă procesorul folosește același set de instrucțiuni (eventual cu unele completări) și același interval de adrese, atunci compatibilitatea binară poate fi realizată destul de simplu. Pentru a face acest lucru, este suficient să respectați următoarele condiții:

Apelurile de funcții API pe care le conține aplicația trebuie să fie acceptate de sistemul de operare;

Structura internă a fișierului executabil al aplicației trebuie să se potrivească cu structura fișierelor executabile ale sistemului de operare.

Este mai dificil să se obțină compatibilitate binară pentru sistemele de operare concepute să ruleze pe procesoare cu arhitecturi diferite. Pe lângă respectarea condițiilor de mai sus, este necesar să se organizeze emularea codului binar, ceea ce va duce la o execuție a programului destul de lentă.

Crearea unui mediu de aplicație cu drepturi depline, pe deplin compatibil cu mediul altui sistem de operare, este o sarcină strâns legată de structura sistemului de operare. Există diverse opțiuni pentru construirea de medii de aplicații multiple, care diferă atât prin caracteristicile soluțiilor arhitecturale, cât și prin funcționalitatea care oferă grade diferite de portabilitate a aplicațiilor.

Una dintre opțiunile cele mai evidente pentru implementarea mai multor medii de aplicații se bazează pe o structură standard de sistem de operare și oferă traducere a apelurilor de sistem.

În Figura 6, sistemul de operare OS1 suportă, pe lângă aplicațiile sale, aplicații ale sistemelor de operare OS2 și OS3.

Pentru aceasta, conține aplicații speciale - medii software de aplicație - care traduc interfețele sistemelor de operare „străine” API OS2 și API OS3 în interfața sistemului lor de operare - API OS1.

Figura 6 - Medii software de aplicație care traduc apelurile de sistem

Într-o altă implementare a mai multor medii de aplicații, sistemul de operare are mai multe API-uri de egalitate (Figura 7). În exemplul prezentat, sistemul de operare acceptă aplicații pentru OS1, OS2 și OS3.

Pentru a face acest lucru, interfețele de programare a aplicațiilor ale tuturor acestor sisteme de operare sunt situate direct în spațiul kernel al sistemului: API OS1, API OS2 și API OS3.

Figura 7 - Implementarea interoperabilității bazată pe mai multe API peer

În această variantă, funcțiile la nivel de API se referă la funcții de sistem de operare de nivel inferior care trebuie să accepte toate cele trei medii de aplicații în general incompatibile. Funcțiile fiecărui API sunt implementate de kernel, ținând cont de specificul OS-ului corespunzător, chiar dacă au un scop similar. Pentru ca nucleul să aleagă implementarea dorită a apelului de sistem, fiecare proces trebuie să transmită nucleului un set de caracteristici de identificare.

O altă modalitate de a construi mai multe medii de aplicație se bazează pe o abordare microkernel. Conform arhitecturii microkernel-ului, toate funcțiile OS sunt implementate de microkernel și servere în modul utilizator. Fiecare mediu de aplicație este proiectat ca un server separat în modul utilizator și nu include mecanisme de bază (Figura 8). Aplicațiile efectuează apeluri de sistem către mediul de aplicație adecvat prin microkernel. Mediul aplicației procesează cererea, o execută și trimite rezultatul către aplicație. În cursul executării unei cereri, mediul aplicației trebuie, la rândul său, să acceseze mecanismele de bază ale sistemului de operare implementate de microkernel și alte servere de sistem de operare.

Această abordare a construcției de medii de aplicații multiple are toate avantajele și dezavantajele unei arhitecturi microkernel, în special:

Este foarte ușor să adăugați și să excludeți medii de aplicații, ceea ce este o consecință a bunei extensibilități a sistemelor de operare microkernel;

Fiabilitatea și stabilitatea se exprimă prin faptul că, dacă unul dintre mediile de aplicație eșuează, toate celelalte rămân operaționale;

Performanța slabă a sistemelor de operare microkernel afectează viteza mediilor de aplicație și, prin urmare, viteza de execuție a aplicației.

Figura 8 - Abordarea Microkernel pentru implementarea mai multor medii de aplicații

Crearea mai multor medii de aplicații în cadrul unui sistem de operare pentru executarea aplicațiilor diferitelor sisteme de operare este o modalitate care vă permite să aveți o singură versiune a programului și să o transferați între sistemele de operare.