U ovom članku želio bih govoriti o tome što su to aplikacijski programi, kao i koji se aplikacijski zadaci mogu riješiti uz njihovu pomoć (na primjer, primjer jednostavne baze podataka), te kakvu ulogu imaju za krajnjeg korisnika osobno računalo. Prije svega, želio bih napomenuti da računala mogu obraditi sve podatke koje im korisnik pošalje. No, da bi te podatke stroj ispravno prepoznao i razumio, potrebno je izraditi poseban program na jeziku koji on razumije, ili, jednostavnije rečeno, niz uzastopnih uputa za izvođenje određenih radnji.

Vrste aplikacijskih programa

Aplikacijski programi su takvi programi, čija je svrha usmjerena na rješavanje određenih problema i izravnu interakciju s korisnikom. Računalni programi su potrebni za automatizaciju svih procesa, pohranu i obradu podataka, modeliranje, dizajn itd. složeni računalni procesi. Programi se obično dijele u dvije klase: sistemski programi i aplikacijski programi. Prvi se uglavnom koriste za obradu dolaznih informacija s neke opreme: mrežne kartice, video kartice, povezane opreme, t.j. to su programi koji komuniciraju s hardverom ili vanjskim uređajima. O njima ćemo govoriti u sljedećim člancima. Ali o drugom - aplikacijskim programima, razgovarajmo detaljnije.

Aplikacijski programi dizajnirani su za interakciju s krajnjim korisnikom, t.j. korisnik, takoreći, stupa u interakciju sa samim sobom, ali samo kroz program, unosi bilo koji podatak na ulaz i dobiva određeni rezultat obrađenih podataka na izlazu. Ovo je svojevrsno rješenje primijenjen zadatak, na primjer, ovo je skeniranje slika i njihova naknadna obrada ili traženje pravih datoteka. Korištenje aplikativnih programa može se uočiti u gotovo svim područjima ljudske djelatnosti, bilo da je riječ o računovodstvu u poduzeću ili izradi grafičkih slika, crtanju itd. Također, primjena aplikacijskih programa prisutna je u tako vrlo važnim sustavima kao što su sustavi za upravljanje bazama podataka. To je vrlo važno u velikim poduzećima u kojima radi veliki broj korisnika i koji stvarno trebaju pohranjivati ​​i koristiti velike količine informacija.

Vrste i primjeri aplikacijskih programa

Aplikacijski programi su:

• Urednici teksta. Dizajniran za stvaranje i uređivanje teksta bez oblikovanja;
• Procesori teksta (MS Word). Napredniji uređivači teksta koji omogućuju uređivanje teksta s dizajnom, promjenu fontova i veličina, umetanje grafičkih datoteka, tablica itd. za prezentabilniji dizajn teksta;
• Proračunske tablice (MS Excell). Uglavnom se koriste za obradu svih podataka sadržanih u ovim tablicama. Primijenjeni zadaci najčešće se izvodi za pohranjivanje vjerodajnica s njihovom naknadnom analizom;
• Rasterski i vektorski grafički uređivači (Photoshop, Corel), "preglednici". Korištenje aplikacijskih programa ove vrste omogućuje stvaranje, uređivanje i pregled grafičkih slika;
• Audio video playeri, uređivači (WinAmp). Omogućuje vam gledanje videozapisa, slušanje glazbe, stvaranje glazbenih skladbi;
• Sustavi upravljanja bazama podataka (na primjer - MSQL). Takvi se programi koriste za rad s bazama podataka. Na primjer, program za računovodstvo kupaca je jednostavna baza podataka za pohranu podataka o kupcima, njihovim kontakt podacima itd. Možete izvršiti operacije za pretraživanje, brisanje i dodavanje zapisa u bazu podataka;
• Prevoditelji ili elektronički rječnici. Takvi aplikacijski programi omogućuju vam da bez napora prevedete tekst na različite strane jezike bez njihovog izravnog proučavanja;
• Računalne igrice. Koristi se za zabavu ili za razvoj na razigran način.

Jedan primjer aplikacijskog programa je, na primjer, program za brojanje repostova. Teško je nabrojati sve vrste aplikacijskih programa, ali pokušali smo istaknuti glavne aplikativne programe.

Korištenje okruženja aplikacijskog softvera pojednostavljuje zadatak pokretanja aplikacija napisanih za jedan OS na drugom . U osnovi, aplikacijsko okruženje treba uključivati ​​funkcije sučelja programskog zahtjeva, kao i sredstva za organiziranje nekonfliktnog suživota unutar istog OS-a nekoliko načina upravljanja računalnim resursima.

Aplikacijsko okruženje može se implementirati kao obična aplikacija, a zatim djeluje na razini korisnika.

Riža. 2.8. Aplikacijska okruženja koja prevode sistemske pozive

U drugoj implementaciji više aplikacijskih okruženja, operativni sustav ima više sučelja za programiranje aplikacija ravnopravnih. Na sl. Primjer 2.9, operativni sustav podržava aplikacije napisane za OS1, OS2 i OS3. Da bi se to postiglo, sučelja aplikacijskog programiranja svih ovih operacijskih sustava postavljaju se izravno u prostor kernela sustava: API OS1, API OS2 i API OS3.

Funkcije svakog API-ja implementira kernel, uzimajući u obzir specifičnosti odgovarajućeg OS-a, čak i ako imaju sličnu svrhu. Kako bi jezgra odabrala željenu implementaciju sistemskog poziva, svaki proces mora jezgri prenijeti skup identifikacijskih karakteristika.

Riža. 2.9. Implementacija interoperabilnosti koja se temelji na više API-ja ravnopravnih

zaključke

· Sav softver računalnog sustava dijeli se na primijenjen (za rješavanje korisničkih problema) i sistemski (za korištenje računalnog hardvera).

Najjednostavnije strukturiranje OS-a sastoji se od podjele svih komponenti OS-a na module koji obavljaju glavne funkcije OS-a (kernel) i module koji obavljaju pomoćne funkcije OS-a. Pomoćni OS moduli izrađuju se ili u obliku aplikacija (uslužni programi i programi za obradu sustava), ili u obliku knjižnica procedura. Pomoćni moduli se učitavaju u RAM samo za vrijeme trajanja svojih funkcija, odnosno prolazni su. Moduli kernela su stalno u RAM-u, odnosno rezidentni su.

· Ako postoji hardverska podrška za načine rada s različitim razinama ovlaštenja, stabilnost OS-a može se povećati izvršavanjem funkcija kernela u privilegiranom načinu rada, a pomoćnih OS modula i aplikacija u korisničkom načinu rada. To omogućuje zaštitu kodova i podataka OS-a i aplikacija od neovlaštenog pristupa. OS može djelovati kao arbitar u sporovima oko resursa.

Svaki operativni sustav u interakciji s hardverom računala rješava svoje probleme, a to su: podrška za privilegirani način rada i prevođenje adresa, sredstva za prebacivanje procesa i zaštitu memorijskih područja, sustav prekida i tajmer sustava. To čini OS stroj ovisnim, vezan za određenu hardversku platformu.

· Mikrokernel arhitektura je alternativa klasičnom načinu izgradnje operacijskog sustava, u skladu s kojim se sve glavne funkcije operacijskog sustava koje čine višeslojnu jezgru izvode u privilegiranom načinu rada. U operativnim sustavima mikrokernel, samo vrlo mali dio operacijskog sustava ostaje u privilegiranom načinu rada. , koje se nazivaju mikrokernel Sve ostale funkcije kernela visoke razine pakirane su kao aplikacije korisničkog načina rada.

· Aplikacijsko softversko okruženje – skup OS alata dizajniranih za organiziranje izvršavanja aplikacija stvorenih za jedan OS u drugom. Svaki OS stvara barem jedno aplikacijsko programsko okruženje. Problem je osigurati kompatibilnost nekoliko softverskih okruženja unutar istog OS-a.

Dok su mnoge arhitektonske značajke OS-a izravno relevantne samo za programere sustava, koncept višestrukih aplikacijskih (operativnih) objekata izravno je povezan s potrebama krajnjih korisnika – sposobnošću operacijskog sustava da pokreće aplikacije napisane za druge operacijske sustave. Ovo svojstvo operacijskog sustava naziva se kompatibilnost.

Kompatibilnost aplikacija može biti na binarnoj razini i na razini izvornog koda. Aplikacije se obično pohranjuju u OS kao izvršne datoteke koje sadrže binarne slike koda i podataka. Binarna kompatibilnost postiže se kada možete uzeti izvršni program i pokrenuti ga na drugom OS okruženju.

Kompatibilnost na razini izvora zahtijeva da odgovarajući prevodilac bude uključen u softver računala na kojem će se aplikacija pokrenuti, kao i kompatibilnost na razini knjižnica i sistemskih poziva. To zahtijeva ponovnu kompilaciju izvornog koda aplikacije u novi izvršni modul.

Kompatibilnost na razini izvora važna je uglavnom za programere aplikacija kojima su ti izvori na raspolaganju. Ali za krajnje korisnike, samo je binarna kompatibilnost od praktične važnosti, jer samo u tom slučaju mogu koristiti isti proizvod na različitim operativnim sustavima i na različitim strojevima.

Vrsta moguće kompatibilnosti ovisi o mnogim čimbenicima. Najvažnija od njih je arhitektura procesora. Ako procesor koristi isti skup instrukcija (možda s dodacima, kao u slučaju IBM PC-a: standardni set + multimedija + grafika + streaming) i isti raspon adresa, tada se binarna kompatibilnost može postići vrlo jednostavno. Za to moraju biti ispunjeni sljedeći uvjeti:

• API koji aplikacija koristi mora biti podržan od strane danog OS-a;
• interna struktura izvršne datoteke aplikacije mora odgovarati strukturi izvršnih datoteka OS-a.

Ako procesori imaju različite arhitekture, tada je, uz gore navedene uvjete, potrebno organizirati emulaciju binarnog koda. Na primjer, naširoko se koristi emulacija uputa za Intelov procesor na procesoru Motorola 680x0 Macintosha. Softverski emulator u ovom slučaju sekvencijalno odabire binarnu instrukciju Intelovog procesora i izvršava ekvivalentni potprogram napisan u uputama Motorola procesora. Budući da Motorola procesor nema potpuno iste registre, zastavice, interne ALU itd., kao u Intelovim procesorima, također mora simulirati (emulirati) sve te elemente koristeći svoje registre ili memoriju.

Ovo je jednostavna, ali vrlo spora operacija, budući da je jedna Intelova instrukcija mnogo brža od Motorola sekvence instrukcija koja je oponaša. Izlaz u takvim slučajevima je korištenje takozvanih aplikacijskih softverskih okruženja ili operativnih okruženja. Jedna od komponenti takvog okruženja je API skup funkcija koje OS izlaže svojim aplikacijama. Kako bi se smanjilo vrijeme za izvođenje tuđih programa, aplikacijska okruženja oponašaju pozive funkcijama knjižnice.

Učinkovitost ovog pristupa je zbog činjenice da većina današnjih programa radi pod GUI (grafičko korisničko sučelje) kao što su Windows, MAC ili UNIX Motif, dok aplikacije provode 60-80% vremena radeći GUI funkcije i druge pozive OS knjižnice. . Upravo ovo svojstvo aplikacija omogućuje aplikacijskim okruženjima da kompenziraju veliko vrijeme utrošeno na emulaciju programa naredbu po naredbu. Pažljivo dizajnirano okruženje softverske aplikacije sadrži biblioteke koje oponašaju GUI knjižnice, ali napisane u izvornom kodu. Time se postiže značajno ubrzanje izvođenja programa s API-jem drugog operativnog sustava. Inače se ovaj pristup naziva prijevodom – kako bi se razlikovao od sporijeg procesa oponašanja jedne po jedne instrukcije.

Na primjer, za Windows program koji radi na Macintoshu, kada tumači naredbe iz Intelovog procesora izvođenje može biti vrlo niska. Ali kada se pozove GUI funkcija, otvori prozor itd., OS modul koji implementira Windows aplikacijsko okruženje može presresti ovaj poziv i preusmjeriti ga na rutinu otvaranja prozora ponovno kompajliranu za Motorola 680x0 procesor. Kao rezultat toga, u takvim dijelovima koda, brzina programa može doseći (i, možda, nadmašiti) brzinu rada na vlastitom procesoru.

Da bi se program napisan za jedan OS mogao pokrenuti na drugom OS-u, nije dovoljno samo osigurati kompatibilnost API-ja. Koncepti koji su u osnovi različitih operacijskih sustava mogu se međusobno sukobiti. Na primjer, u jednom OS-u, aplikaciji može biti dopušteno kontrolirati I/O uređaje, u drugom su te radnje prerogativ OS-a.

Svaki OS ima svoje mehanizme zaštite resursa, vlastite algoritme za rukovanje pogreškama i iznimkama, vlastitu strukturu procesora i shemu upravljanja memorijom, vlastitu semantiku pristupa datotekama i vlastito grafičko korisničko sučelje. Kako bi se osigurala kompatibilnost, potrebno je organizirati beskonfliktan suživot unutar istog OS-a nekoliko načina upravljanja računalnim resursima.

Postoje različite mogućnosti za izgradnju više aplikacijskih okruženja, koje se razlikuju i po značajkama arhitektonskih rješenja i u funkcionalnosti koje pružaju različite stupnjeve prenosivosti aplikacije. Jedna od najočitijih opcija za implementaciju više aplikacijskih okruženja temelji se na standardnoj slojevitoj strukturi OS-a.

Drugi način za izgradnju više aplikacijskih okruženja temelji se na pristupu mikrokernela. Pritom je vrlo važno uočiti osnovnu, zajedničku za sve aplikacijske sredine, razliku između mehanizama operacijskog sustava i funkcija visoke razine specifične za svako od aplikacijskih okruženja koje rješavaju strateške probleme. U skladu s mikronuklearna arhitektura sve funkcije OS-a implementiraju mikrokernel i poslužitelji korisničkog načina rada. Važno je da je aplikacijsko okruženje dizajnirano kao zaseban poslužitelj u korisničkom načinu rada i da ne uključuje temeljne mehanizme.

Aplikacije, koristeći API, upućuju pozive sustava u odgovarajuće okruženje aplikacije putem mikrokernela. Aplikacijsko okruženje obrađuje zahtjev, izvršava ga (možda tražeći pomoć od osnovnih funkcija mikrokernela za to) i šalje rezultat natrag u aplikaciju. Tijekom izvršavanja zahtjeva, aplikacijsko okruženje, zauzvrat, mora pristupiti osnovnim OS mehanizmima implementiranim od strane mikrokernela i drugih OS poslužitelja.

Ovaj pristup dizajniranju višestrukih aplikacijskih okruženja ima sve prednosti i nedostatke arhitekture mikro jezgre, posebno:

• vrlo je jednostavno dodavati i isključivati ​​aplikacijska okruženja, što je posljedica dobre proširivosti operativnih sustava mikro-jezgre;
• ako jedno od aplikacijskih okruženja ne uspije, ostale ostaju operativne, što pridonosi pouzdanosti i stabilnosti sustava u cjelini;
• niske performanse mikrokernel operativnih sustava utječu na brzinu aplikacijskih alata, a time i na brzinu aplikacija.

Kao rezultat toga, treba napomenuti da je stvaranje unutar jednog OS-a nekoliko aplikacijskih alata za izvršavanje aplikacija različitih OS-a način koji vam omogućuje da imate jednu verziju programa i prenosite je između različitih operacijskih sustava. Više aplikacijskih okruženja osigurava binarnu kompatibilnost određenog OS-a s aplikacijama napisanim za druge operacijske sustave.

1.9. Virtualni strojevi kao suvremeni pristup implementaciji više aplikacijskih okruženja

Koncept "virtualnog monitora stroja" (VMM) nastao je kasnih 60-ih kao softver razina apstrakcije, koji je hardversku platformu podijelio na nekoliko virtualnih strojeva. Svaki od tih virtualnih strojeva (VM) bio je toliko sličan osnovnom fizičkom stroju da je postojeći softver mogao se na njemu izvesti nepromijenjen. U to vrijeme, opći računalni zadaci obavljali su se na skupim glavnim računalima (kao što je IBM /360), a korisnici su visoko cijenili sposobnost VMM-a da dodijeli oskudne resurse između nekoliko aplikacija.

U 1980-im i 1990-im, cijena računalne opreme značajno je smanjena i učinkovita multitasking OS, što je smanjilo vrijednost VMM-a u očima korisnika. Glavna računala su ustupila mjesto miniračunalima, a potom i računalima, a potreba za VMM-om je nestala. Kao rezultat toga, arhitektura računala je jednostavno nestala hardver za njihovu učinkovitu provedbu. Do kraja 80-ih, u znanosti i proizvodnji VMM-a, oni su percipirani samo kao povijesni kuriozitet.

Danas je MVM ponovno u centru pažnje. Intel, AMD, Sun Microsystems i IBM stvaraju strategije virtualizacije, a laboratoriji i sveučilišta razvijaju pristupe temeljene na virtualnim strojevima za rješavanje problema mobilnosti, sigurnosti i upravljanja. Što se dogodilo između ostavke MVM-a i njihovog oživljavanja?

U 1990-ima istraživači sa Sveučilišta Stanford počeli su istraživati ​​mogućnost korištenja virtualnih strojeva za prevladavanje ograničenja hardvera i operacijskih sustava. Problemi su nastali s računalima s masovnom paralelnom obradom (Massively Parallel Processing, MPP), koja su bila teška za programiranje i nisu mogla pokretati postojeće operacijske sustave. Istraživači su otkrili da bi virtualni strojevi mogli ovu glomaznu arhitekturu učiniti dovoljno sličnom postojećim platformama kako bi iskoristili prednosti operativnih sustava koji su dostupni na polici. Iz ovog projekta proizašli su ljudi i ideje koje su postale zlatni rudnik VMwarea (www.vmware.com), prvog dobavljača VMM-a za mainstream računala.

Začudo, razvoj modernih operativnih sustava i smanjenje troškova hardvera doveli su do problema za koje su se istraživači nadali da će ih riješiti s VMM-ovima. Jeftina opreme pridonijela je brzom širenju računala, ali su često bila nedovoljno korištena, zahtijevajući dodatni prostor i trud za održavanje. A posljedice rasta funkcionalnosti OS-a postale su njihova nestabilnost i ranjivost.

Kako bi smanjili utjecaj rušenja sustava i zaštitili se od hakova, administratori sustava ponovno su se okrenuli samo jednom zadatku računski model(s jednom aplikacijom na jednom stroju). To je rezultiralo dodatnim troškovima zbog povećanih zahtjeva za hardverom. Premještanje aplikacija s različitih fizičkih strojeva na VM-ove i konsolidacija tih VM-ova na nekoliko fizičkih platformi poboljšalo je korištenje hardvera, smanjilo troškove upravljanja i smanjilo prostor. Stoga ih je VMM-ova sposobnost multipleksiranja hardvera – ovoga puta u ime konsolidacije poslužitelja i pomoćnog računanja – vratila u život.

Trenutno, VMM nije postao toliko alat za organiziranje multitaskinga kao što je nekoć bio zamišljen, već rješenje za probleme osiguranja sigurnosti, mobilnosti i pouzdanosti. Na mnogo načina, VMM daje programerima operacijskog sustava mogućnost razvoja funkcionalnosti koja nije moguća s današnjim složenim operativnim sustavima. Funkcije kao što su migracija i zaštita mnogo su prikladnije za implementaciju na razini VMM-a, koja održava kompatibilnost unatrag prilikom implementacije inovativnih rješenja operacijskog sustava uz zadržavanje prethodnih dostignuća.

Virtualizacija je tehnologija koja se razvija. Općenito, virtualizacija vam omogućuje odvajanje softvera od temeljne hardverske infrastrukture. Zapravo, prekida vezu između određenog skupa programa i određenog računala. Virtual Machine Monitor se odvaja softver od hardvera i tvori međusloj između softvera koji pokreće virtualne strojeve i hardvera. Ova razina omogućuje VMM-u da u potpunosti kontrolira korištenje hardverskih resursa. gostujući operativni sustavi (GuestOS) koji rade na VM-u.

VMM stvara jedinstveni pogled na temeljni hardver tako da fizički strojevi različitih dobavljača s različitim I/O podsustavima izgledaju isto, a VM radi na bilo kojem dostupnom hardveru. Bez brige o pojedinačnim strojevima, s njihovim čvrstim međusobnim odnosima između hardvera i softvera, administratori mogu tretirati hardver jednostavno kao skup resursa za pružanje bilo koje usluge na zahtjev.

Zahvaljujući potpuna inkapsulacija stanja softvera na VM-u, VMM monitor može mapirati VM na sve dostupne hardverske resurse, pa čak i premjestiti ga s jednog fizičkog stroja na drugi. Zadatak balansiranja opterećenja na skupini strojeva postaje trivijalan, a postoje pouzdani načini za rješavanje kvarova hardvera i razvoj sustava. Ako trebate isključiti neispravno računalo ili vratiti novo na mrežu, VMM može u skladu s tim redistribuirati virtualne strojeve. Virtualni stroj se lako replicira, što administratorima omogućuje brzo pružanje novih usluga prema potrebi.

Enkapsulacija također znači da administrator može pauzirati ili nastaviti VM u bilo kojem trenutku, kao i spremiti trenutno stanje virtualnog stroja ili ga vratiti u prethodno stanje. Uz univerzalnu mogućnost poništavanja, rušenja i konfiguracijske pogreške mogu se lako riješiti. Enkapsulacija je osnova generaliziranog modela mobilnosti, budući da se suspendirani VM može kopirati preko mreže, pohraniti i transportirati na prijenosnim medijima.

VMM igra ulogu posrednika u svim interakcijama između VM-a i temeljnog hardvera, podržavajući izvođenje mnogih virtualnih strojeva na jednoj hardverskoj platformi i osiguravajući njihovu pouzdanu izolaciju. VMM vam omogućuje sastavljanje grupe VM-ova s ​​niskim zahtjevima za resursima na jednom računalu, smanjujući troškove hardver te potreba za proizvodnim prostorom.

Potpuna izolacija također je važna za pouzdanost i sigurnost. Aplikacije koje su se nekada izvodile na jednom računalu sada se mogu distribuirati na različite VM-ove. Ako jedan od njih izazove pad OS-a kao rezultat pogreške, druge aplikacije će biti izolirane od njega i nastaviti s radom. Ako nekoj od aplikacija prijeti vanjski napad, napad će biti lokaliziran unutar "kompromitirane" VM. Dakle, VMM je alat za restrukturiranje sustava kako bi se poboljšala njegova stabilnost i sigurnost, bez potrebe za dodatnim prostorom i administrativnim naporima, koji su nužni kada se aplikacije izvode na zasebnim fizičkim strojevima.

VMM mora povezati hardversko sučelje s VM-om, zadržavajući potpunu kontrolu nad temeljnim strojem i postupcima za interakciju s njegovim hardverom. Za postizanje ovog cilja postoje različite metode temeljene na određenim tehničkim kompromisima. Prilikom traženja takvih kompromisa uzimaju se u obzir glavni zahtjevi za VMM: kompatibilnost, izvođenje i jednostavnost. Kompatibilnost je važna jer je glavna prednost VMM-a mogućnost pokretanja naslijeđenih aplikacija. Izvođenje određuje količinu režijskih troškova za virtualizaciju - programi na VM-u moraju se izvršavati istom brzinom kao i na stvarnom stroju. Jednostavnost je neophodna jer će neuspjeh VMM-a rezultirati neuspjehom svih VM-ova koji rade na računalu. Konkretno, pouzdana izolacija zahtijeva da VMM bude bez bugova koje napadači mogu koristiti za uništavanje sustava.

Umjesto da prolazite kroz složeno prepisivanje koda gostujućeg operativnog sustava, možete napraviti neke promjene u operativnom sustavu domaćina mijenjajući neke od dijelova kernela koji najviše "ometaju". Ovaj pristup se naziva paravirtualizacija. Jasno je da u ovom slučaju samo autor može prilagoditi jezgru OS-a, a na primjer, Microsoft ne pokazuje nikakvu želju da popularnu jezgru Windows 2000 prilagodi stvarnostima konkretnih virtualnih strojeva.

U paravirtualizaciji, VMM programer redefinira sučelje virtualnog stroja, zamjenjujući podskup izvornog skupa instrukcija koji nije prikladan za virtualizaciju s prikladnijim i učinkovitijim ekvivalentima. Imajte na umu da iako se OS mora prenijeti za rad na takvim VM-ovima, najčešće aplikacije mogu raditi nepromijenjene.

Najveći nedostatak paravirtualizacije je nekompatibilnost. Bilo koji operacijski sustav, dizajniran da radi pod kontrolom paravirtualiziranog VMM monitora, mora biti portiran na ovu arhitekturu, za što je potrebno pregovarati o suradnji s dobavljačima OS-a. Osim toga, ne mogu se koristiti naslijeđeni operativni sustavi, a postojeći strojevi ne mogu se lako zamijeniti virtualnim.

Kako bi postigao visoke performanse i kompatibilnost u x86 virtualizaciji, VMware je razvio novu metodu virtualizacije koja kombinira tradicionalno izravno izvršenje s brzim prevođenjem binarnog koda u hodu. U većini modernih operacijskih sustava, procesorski načini rada tijekom izvođenja običnih aplikacijskih programa lako se virtualiziraju, te se stoga mogu virtualizirati izravnim izvršavanjem. Privilegirani načini neprikladni za virtualizaciju mogu se izvršiti pomoću prevoditelja binarnog koda, ispravljajući "nezgodne" x86 naredbe. Rezultat je visoka izvedba virtualni stroj, koji je potpuno kompatibilan s hardverom i održava potpunu softversku kompatibilnost.

Konvertirani kod vrlo je sličan rezultatima paravirtualizacije. Uobičajene instrukcije se izvršavaju nepromijenjene, dok instrukcije koje zahtijevaju posebnu obradu (kao što su POPF i instrukcije registra segmentnog koda za čitanje) prevodilac zamjenjuje sekvencama instrukcija koje su slične onima koje su potrebne za izvršenje na paravirtualiziranom virtualnom stroju. Međutim, postoji važna razlika: umjesto promjene izvornog koda operacijskog sustava ili aplikacija, binarni prevoditelj mijenja kod prvi put kada se izvrši.

Iako postoje neki dodatni troškovi koji su uključeni u prevođenje binarnog koda, oni su zanemarivi pod normalnim radnim opterećenjima. Prevoditelj obrađuje samo dio koda, a brzina izvršavanja programa postaje usporediva s brzinom izravnog izvršavanja – čim se predmemorija napuni.

Izlaz u takvim slučajevima je korištenje tzv primijenjena softverska okruženja. Jedna od komponenti koje čine okruženje za programiranje aplikacija je skup API funkcija koje operativni sustav pruža svojim aplikacijama. Kako bi se smanjilo vrijeme za izvođenje tuđih programa, aplikacijska okruženja oponašaju pozive funkcijama knjižnice.

Učinkovitost ovog pristupa je posljedica činjenice da većina današnjih programa radi pod GUI (Grafičko korisničko sučelje) poput Windowsa, Maca ili UNIX Motifa, pri čemu aplikacije provode većinu svog vremena izvodeći neke dobro predvidljive radnje. Oni kontinuirano upućuju pozive GUI knjižnicama za manipulaciju prozorima i druge aktivnosti povezane s GUI-jem. Danas se u tipičnim programima 60-80% vremena troši na izvršavanje GUI funkcija i drugih poziva OS knjižnice. Upravo ovo svojstvo aplikacija omogućuje aplikacijskim okruženjima da kompenziraju veliko vrijeme utrošeno na emulaciju programa naredbu po naredbu. Pažljivo osmišljeno okruženje softverske aplikacije uključuje biblioteke koje oponašaju interne GUI biblioteke, ali napisane u izvornom kodu, čime se postiže značajno ubrzanje izvođenja programa s API-jem drugog operativnog sustava. Ovaj se pristup ponekad naziva prijevodom kako bi se razlikovao od sporijeg procesa emulacije koda jednu po jednu instrukciju.

Na primjer, za Windows program koji radi na Macintoshu, pri tumačenju naredbi iz Intel 80x86 procesora, performanse mogu biti vrlo loše. Ali kada se pozove GUI funkcija za otvaranje prozora, OS modul koji implementira okruženje aplikacije Windows može presresti ovaj poziv i preusmjeriti ga na rutinu otvaranja prozora prekompajliranu za procesor Motorola 680x0. Kao rezultat toga, u takvim dijelovima koda, brzina programa može doseći (i eventualno premašiti) brzinu rada na njegovom "nativnom" procesoru.

Da bi se program napisan za jedan OS mogao pokrenuti na drugom OS-u, nije dovoljno samo osigurati da je API kompatibilan. Koncepti koji su u osnovi različitih operacijskih sustava mogu se međusobno sukobiti. Na primjer, u jednom operacijskom sustavu, aplikaciji može biti dopušteno da izravno kontrolira I/O uređaje, u drugom su te radnje prerogativ OS-a. Svaki operativni sustav ima svoje mehanizme zaštite resursa, vlastite algoritme za rukovanje pogreškama i iznimkama, vlastitu strukturu procesa i shemu upravljanja memorijom, vlastitu semantiku pristupa datotekama i vlastito grafičko korisničko sučelje. Kako bi se osigurala kompatibilnost, potrebno je organizirati beskonfliktan suživot unutar istog OS-a nekoliko načina upravljanja računalnim resursima.

3. 7. 3. Metode implementacije okruženja aplikacijskog softvera

Stvaranje punopravnog aplikacijskog okruženja koje je u potpunosti kompatibilno s okruženjem drugog operacijskog sustava prilično je složen zadatak, usko povezan sa strukturom operacijskog sustava. Postoje različite mogućnosti za izgradnju više aplikacijskih okruženja, koje se razlikuju i po značajkama arhitektonskih rješenja i u funkcionalnosti koje pružaju različite stupnjeve prenosivosti aplikacije.

U mnogim verzijama UNIX operativnog sustava, prevoditelj aplikacijskog okruženja implementiran je kao obična aplikacija. U operativnim sustavima izgrađenim korištenjem koncepta mikrokernela, kao što je Windows NT, okruženja aplikacija rade kao poslužitelji u korisničkom načinu rada. A u OS/2, s njegovom jednostavnijom arhitekturom, okruženja aplikacija ugrađena su duboko u operativni sustav.

Jedna od najočitijih opcija za implementaciju više aplikacijskih okruženja temelji se na standardnoj slojevitoj strukturi OS-a. Na sl. 3. 8 operativni sustav OS1 podržava, osim svojih "nativnih" aplikacija, aplikacije OS2 operativnog sustava. Za to uključuje posebnu aplikaciju - okruženje aplikacijskog softvera koje prevodi sučelje "stranog" operativnog sustava - API OS2 u sučelje svog "domaćeg" operativnog sustava - API OS1.

Riža. 3. 8. Aplikacijsko okruženje koje prevodi sistemske pozive

U drugoj implementaciji više aplikacijskih okruženja, operativni sustav ima više sučelja za programiranje aplikacija ravnopravnih. Na sl. 3. U primjeru, operativni sustav podržava aplikacije napisane za OS1, OS2 i OS3. Da bi se to postiglo, sučelja aplikacijskog programiranja svih ovih operacijskih sustava postavljaju se izravno u prostor kernela sustava: API OS1, API OS2 i API OS3.

Riža. 3. 9. Implementacija interoperabilnosti temeljene na više API-ja peer

U ovoj varijanti, funkcije API razine pozivaju funkcije osnovne razine OS-a, koje moraju podržavati sva tri općenito nekompatibilna okruženja aplikacija. Različiti operacijski sustavi različito upravljaju vremenom sustava, koriste različite formate vremena u danu, dijele CPU vrijeme na temelju vlastitih algoritama, itd. Funkcije svakog API-ja implementira kernel uzimajući u obzir specifičnosti odgovarajućeg OS-a, čak i ako imaju sličnu svrhu.

Drugi način za izgradnju više aplikacijskih okruženja temelji se na pristupu mikrokernela. Pritom je vrlo važno odvojiti osnovne, zajedničke svim aplikacijskim okruženjima, mehanizme operacijskog sustava od funkcija visoke razine specifične za svako od aplikacijskih okruženja koje rješavaju strateške probleme.

U skladu s arhitekturom mikrokernela, sve funkcije OS-a implementiraju mikrokernel i poslužitelji korisničkog načina rada. Važno je da je svako aplikacijsko okruženje dizajnirano kao zaseban poslužitelj korisničkog načina rada i da ne uključuje osnovne mehanizme (slika 3. 10). Aplikacije, koristeći API, upućuju pozive sustava u odgovarajuće okruženje aplikacije putem mikrokernela. Aplikacijsko okruženje obrađuje zahtjev, izvršava ga (možda tražeći pomoć od osnovnih funkcija mikrokernela za to) i šalje rezultat natrag u aplikaciju. Tijekom izvršavanja zahtjeva, aplikacijsko okruženje, zauzvrat, mora pristupiti osnovnim OS mehanizmima implementiranim od strane mikrokernela i drugih OS poslužitelja.

Riža. 3. 10. Mikrokernel pristup implementaciji više aplikacijskih okruženja

Ovaj pristup dizajniranju višestrukih aplikacijskih okruženja ima sve prednosti i nedostatke arhitekture mikrojezgre, posebno:

vrlo je jednostavno dodavati i isključivati ​​aplikacijska okruženja, što je posljedica dobre proširivosti mikrokernel operativnih sustava;

pouzdanost i stabilnost izraženi su u činjenici da ako jedno od aplikacijskih okruženja zakaže, sve ostale ostaju operativne;

niske performanse mikrokernel operativnih sustava utječu na brzinu aplikacijskih okruženja, a time i na brzinu izvršavanja aplikacije.

Stvaranje nekoliko aplikacijskih okruženja unutar jednog operacijskog sustava za pokretanje aplikacija različitih operacijskih sustava način je koji vam omogućuje da imate jednu verziju programa i prenosite je između operacijskih sustava. Više aplikacijskih okruženja osigurava binarnu kompatibilnost određenog OS-a s aplikacijama napisanim za druge operacijske sustave. Kao rezultat toga, korisnici imaju više slobode u odabiru operacijskih sustava i lakši pristup kvalitetnom softveru.

Pitanja za samoispitivanje

Što se podrazumijeva pod arhitekturom OS-a?

Koja su tri glavna sloja u strukturi računalnog sustava?

Koja je uloga koju OS dodjeljuje sučelju za pozive sustava?

Koji uvjeti moraju biti ispunjeni pri dizajniranju OS-a da bi OS bio lako prenosiv?

Koja je razlika između arhitekture mikrokernela i tradicionalne arhitekture OS-a?

Zašto je mikrokernel dobro prikladan za podršku distribuiranom računalstvu?

Što se podrazumijeva pod konceptom višestrukih aplikacijskih okruženja?

Koja je bit metode prevođenja knjižnice?

Kompatibilnost i više aplikacija

Koncept višestrukih aplikacijskih okruženja vezan je uz potrebe krajnjih korisnika – sposobnost operacijskog sustava da pokreće aplikacije drugih operacijskih sustava. Ova značajka operacijskog sustava se zove kompatibilnost.

Binarna i izvorna kompatibilnost

Razlikujte kompatibilnost na binarnoj razini i kompatibilnost na razini izvornog koda. Aplikacije se obično pohranjuju u OS kao izvršne datoteke koje sadrže binarne slike koda i podataka. Binarna kompatibilnost postiže se kada možete uzeti izvršni program i pokrenuti ga na drugom operativnom sustavu.

Kompatibilnost na razini izvora zahtijeva da odgovarajući prevodilac bude uključen u softver računala na kojem se aplikacija namjerava pokrenuti, kao i kompatibilnost na razini knjižnica i sistemskih poziva. To zahtijeva prevođenje dostupnog izvornog koda u izvršni modul.

Kompatibilnost na razini izvora važna je uglavnom za programere aplikacija kojima su ti izvori na raspolaganju. Za krajnje korisnike od praktične je važnosti samo binarna kompatibilnost, jer samo u tom slučaju mogu koristiti isti komercijalni proizvod u obliku binarnog izvršnog koda u različitim operativnim okruženjima.

Hoće li operativni sustavi biti binarno ili izvorno kompatibilni ovisi o mnogim čimbenicima. Glavna među njima je arhitektura procesora na kojem radi novi OS. Ako procesor koristi isti skup instrukcija (možda s nekim dodacima) i isti raspon adresa, tada se binarna kompatibilnost može postići prilično lako. Da biste to učinili, dovoljno je ispuniti sljedeće uvjete:

OS mora podržavati pozive API funkcijama koje aplikacija sadrži;

Interna struktura izvršne datoteke aplikacije mora odgovarati strukturi izvršnih datoteka OS-a.

Teže je postići binarnu kompatibilnost za operativne sustave dizajnirane za rad na procesorima različitih arhitektura. Osim poštivanja navedenih uvjeta, potrebno je organizirati emulaciju binarnog koda, što će dovesti do prilično sporog izvršavanja programa.

Stvaranje cjelovite aplikacijske okoline koja je u potpunosti kompatibilna s okruženjem drugog operacijskog sustava zadatak je usko povezan sa strukturom operacijskog sustava. Postoje različite mogućnosti za izgradnju više aplikacijskih okruženja, koje se razlikuju i po značajkama arhitektonskih rješenja i u funkcionalnosti koje pružaju različite stupnjeve prenosivosti aplikacije.

Jedna od najočitijih opcija za implementaciju višestrukih aplikacijskih okruženja temelji se na standardnoj slojevitoj strukturi OS-a i pruža prijevod sistemskih poziva.

Na slici 6. operativni sustav OS1 podržava, osim svojih aplikacija, aplikacije OS2 i OS3 operativnih sustava.

Za to sadrži posebne aplikacije – okruženja aplikacijskog softvera – koje prevode sučelja „stranih“ operativnih sustava API OS2 i API OS3 u sučelje svog operacijskog sustava – API OS1.

Slika 6 - Aplikacijska okruženja koja prevode sistemske pozive

U drugoj implementaciji više aplikacijskih okruženja, operativni sustav ima više sučelja za programiranje aplikacija ravnopravnih (slika 7). U prikazanom primjeru operativni sustav podržava aplikacije za OS1, OS2 i OS3.

Da bi se to postiglo, sučelja aplikacijskog programiranja svih ovih operacijskih sustava postavljaju se izravno u prostor kernela sustava: API OS1, API OS2 i API OS3.

Slika 7 - Implementacija kompatibilnosti temeljena na više API-ja ravnopravnih

U ovoj varijanti, funkcije API razine pozivaju funkcije osnovne razine OS-a, koje moraju podržavati sva tri općenito nekompatibilna okruženja aplikacija. Funkcije svakog API-ja implementira kernel, uzimajući u obzir specifičnosti odgovarajućeg OS-a, čak i ako imaju sličnu svrhu. Kako bi jezgra odabrala željenu implementaciju sistemskog poziva, svaki proces mora jezgri prenijeti skup identifikacijskih karakteristika.

Drugi način za izgradnju više aplikacijskih okruženja temelji se na pristupu mikrokernela. U skladu s arhitekturom mikrokernela, sve funkcije OS-a implementiraju mikrokernel i poslužitelji korisničkog načina rada. Svako aplikacijsko okruženje dizajnirano je kao zasebni poslužitelj korisničkog načina rada i ne uključuje osnovne mehanizme (slika 8). Aplikacije putem mikrokernela upućuju pozive sustava prema odgovarajućem aplikacijskom okruženju. Aplikacijsko okruženje obrađuje zahtjev, izvršava ga i šalje rezultat natrag u aplikaciju. Tijekom izvršavanja zahtjeva, aplikacijsko okruženje, zauzvrat, mora pristupiti osnovnim OS mehanizmima implementiranim od strane mikrokernela i drugih OS poslužitelja.

Ovaj pristup dizajniranju višestrukih aplikacijskih okruženja ima sve prednosti i nedostatke arhitekture mikrojezgre, posebno:

Vrlo je jednostavno dodavati i uklanjati aplikacijska okruženja, što je posljedica dobre proširivosti mikrokernel operativnih sustava;

Pouzdanost i stabilnost izraženi su u činjenici da ako jedno od aplikacijskih okruženja zakaže, sve ostale ostaju operativne;

Niska izvedba operacijskih sustava mikrokernel utječe na brzinu okruženja aplikacija, a time i na brzinu izvršavanja aplikacije.

Slika 8 - Mikrokernel pristup implementaciji više aplikacijskih okruženja

Stvaranje unutar jednog operacijskog sustava nekoliko aplikacijskih okruženja za izvršavanje aplikacija različitih operacijskih sustava način je koji vam omogućuje da imate jednu verziju programa i da je prenosite između operacijskih sustava.