U ovom članku želim govoriti o tome šta su aplikativni programi, kao i koji aplikativni problemi se mogu riješiti uz njihovu pomoć (na primjer, primjer jednostavne baze podataka), te kakvu ulogu imaju za krajnjeg korisnika lične kompjuter. Prije svega, želio bih napomenuti da kompjuteri mogu obraditi sve podatke koje mu korisnik pošalje. Ali da bi te podatke mašina ispravno prepoznala i razumjela, potrebno je sastaviti poseban program na jeziku koji razumije, ili, jednostavnije, niz uzastopnih instrukcija za izvođenje određenih radnji.

Vrste aplikativnih programa

Aplikacioni programi su takvi programi čija je svrha rješavanje određenih problema i direktna interakcija s korisnikom. Računalni programi su potrebni za automatizaciju svih procesa, skladištenja i obrade podataka, modeliranja, dizajna itd. složeni računarski procesi. Programi se općenito dijele u dvije klase: sistemski programi i aplikativni programi. Prvi se uglavnom koriste za obradu dolaznih informacija sa neke opreme: mrežne kartice, video kartice, povezane opreme, tj. ovo su programi koji komuniciraju sa hardverom ili eksternim uređajima. O njima ćemo govoriti u sljedećim člancima. Ali o drugom - primijenjenim programima, hajde da razgovaramo detaljnije.

Aplikacioni programi su dizajnirani za interakciju sa krajnjim korisnikom, tj. korisnik, takoreći, stupa u interakciju sa samim sobom, ali samo kroz program, unosi bilo koji podatak na ulaz i na izlazu prima određeni rezultat obrađenih podataka. Ovo je svojevrsna odluka određenom primijenjen zadatak, na primjer, to je skeniranje slika i njihova naknadna obrada ili traženje željenih datoteka. Korištenje aplikativnih programa može se uočiti u gotovo svim sferama ljudske djelatnosti, bilo da je riječ o računovodstvu u preduzeću ili kreiranju grafičkih slika, crteža itd. Takođe, upotreba aplikativnih programa prisutna je u tako važnim sistemima kao što su sistemi za upravljanje bazama podataka. Ovo je veoma važno u velikim preduzećima u kojima radi veliki broj korisnika i koji zaista moraju da skladište i koriste velike količine informacija.

Vrste i primjeri aplikativnih programa

Aplikacioni programi su:

• Urednici teksta. Dizajniran za kreiranje i uređivanje teksta bez ukrasa;
• Procesori teksta (MS Word). Napredniji uređivači teksta koji vam omogućavaju da uređujete tekst sa dizajnom, mijenjate fontove i njegove veličine, ubacujete grafičke datoteke, tabele itd. za prezentabilniji dizajn teksta;
• Elektronske tablice (MS Excell). Uglavnom se koriste za obradu svih podataka sadržanih u ovim tabelama. Primijenjeni zadaci najčešće se izvode za pohranjivanje vjerodajnica s njihovom naknadnom analizom;
• Rasterski i vektorski grafički uređivači (Photoshop, Corel), "preglednici". Upotreba aplikativnih programa ovog tipa omogućava vam da kreirate, uređujete, kao i pregledate grafičke slike;
• Audio video plejeri, uređivači (WinAmp). Omogućava vam da gledate video zapise, slušate muziku, kreirate muzičke kompozicije;
• Sistemi za upravljanje bazama podataka (na primjer - MSQL). Takvi programi se koriste za rad sa bazama podataka. Na primjer, program za računovodstvo kupaca je jednostavna baza podataka za pohranjivanje informacija o klijentima, njihovih kontakt informacija itd. Možete izvršiti operacije pretraživanja, brisanja i dodavanja zapisa u bazu podataka;
• Prevodioci ili elektronski rječnici. Takvi aplikativni programi omogućuju vam da bez napora prevodite tekst na različite strane jezike bez direktnog proučavanja;
• Kompjuterske igre. Koristi se za zabavu ili za razvoj na igriv način.

Jedan primjer aplikacije je, na primjer, program za brojanje ponovnih objava. Teško je navesti sve vrste aplikativnih programa, ali smo pokušali da istaknemo glavne aplikativne programe.

Upotreba primijenjena softverska okruženja pojednostavljuje zadatak pokretanja aplikacija napisanih za jedan OS na drugom . U osnovi, okruženje aplikacije treba da sadrži funkcije interfejsa programskog zahteva, kao i sredstva za organizovanje beskonfliktne koegzistencije u okviru jednog OS-a nekoliko načina upravljanja računarskim resursima.

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

Rice. 2.8. Aplikaciona programska okruženja koja prevode sistemske pozive

U drugoj implementaciji višestrukih aplikativnih okruženja, operativni sistem ima više sučelja za programiranje aplikacija ravnopravnih. U primjeru prikazanom na sl. Primjer operativnog sistema 2.9 podržava aplikacije napisane za OS1, OS2 i OS3. Da bi se to uradilo, interfejsi za programiranje aplikacija svih ovih operativnih sistema nalaze se direktno u prostoru kernela sistema: 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. Da bi jezgro odabralo željenu implementaciju sistemskog poziva, svaki proces mora proslediti set identifikacionih karakteristika kernelu.

Rice. 2.9. Implementacija interoperabilnosti zasnovane na više API-ja ravnopravnih

zaključci

· Sav softver računarskog sistema se deli na primenjeni (za rešavanje korisničkih problema) i sistemski (za korišćenje računarskog hardvera).

· Najjednostavnije strukturiranje OS-a sastoji se od podjele svih komponenti OS-a na module koji obavljaju glavne OS funkcije (kernel) i module koji obavljaju pomoćne OS funkcije. Podržavajući OS moduli su dizajnirani ili kao aplikacije (uslužni programi i programi za obradu sistema), ili kao biblioteke procedura. Pomoćni moduli se učitavaju u RAM samo za vrijeme trajanja svojih funkcija, odnosno prolazni su. Moduli kernela su rezidentni u RAM-u, odnosno rezidentni su.

· Ako postoji hardverska podrška za režime sa različitim nivoima ovlašćenja, stabilnost OS se može povećati izvršavanjem funkcija kernela u privilegovanom režimu, a pomoćnih modula OS-a i aplikacija u korisničkom režimu. Ovo omogućava zaštitu kodova i podataka OS-a i aplikacija od neovlaštenog pristupa. OS može djelovati kao arbitar u sporovima oko aplikacija oko resursa.

· Svaki OS radi rješavanja svojih zadataka stupa u interakciju sa računarskim hardverom, a to su: sredstva za podršku privilegovanog režima i translacije adresa, sredstva za prebacivanje procesa i zaštitu memorijskih područja, sistem prekida i sistemski tajmer. Ovo čini OS mašinu zavisnim, vezan za određenu hardversku platformu.

Mikrokernel arhitektura je alternativa klasičnom načinu izgradnje operativnog sistema, u skladu sa kojim se sve glavne funkcije operativnog sistema koje čine višeslojno jezgro izvode u privilegovanom režimu. U operativnim sistemima mikrokernel, samo mali dio operativnog sistema ostaje u privilegovanom načinu rada. , Sve ostale funkcije kernela visokog nivoa implementirane su kao aplikacije u korisničkom režimu.

· Aplikacijsko softversko okruženje – skup OS alata dizajniranih da organiziraju izvršavanje aplikacija kreiranih za jedan OS u drugom. Svaki OS kreira najmanje jedno okruženje za programiranje aplikacija. Problem leži u osiguravanju kompatibilnosti nekoliko softverskih okruženja unutar istog OS-a.

Dok se mnoge arhitektonske karakteristike OS-a direktno tiču ​​samo sistemskih programera, koncept višestrukih aplikativnih (operativnih) alata je direktno povezan sa potrebama krajnjih korisnika – sposobnošću operativnog sistema da pokreće aplikacije napisane za druge operativne sisteme. Ovo svojstvo operativnog sistema naziva se kompatibilnost.

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

Kompatibilnost izvora zahteva odgovarajući kompajler u softveru računara na kojem nameravate da pokrenete aplikaciju, kao i kompatibilnost biblioteke i sistemskog poziva. U tom slučaju potrebno je ponovo kompajlirati izvorni kod aplikacije u novi izvršni modul.

Kompatibilnost izvora je važna prvenstveno za programere aplikacija koji imaju izvorni kod na raspolaganju. Ali za krajnje korisnike, samo binarna kompatibilnost je od praktične važnosti, jer samo u tom slučaju mogu koristiti isti proizvod na različitim operativnim sistemima i na različitim mašinama.

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

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

Ako procesori imaju različite arhitekture, tada je, pored navedenih uslova, potrebno organizovati emulaciju binarnog koda. Na primjer, široko se koristi emulacija komandi Intel procesora na Motorola 680x0 procesoru Macintosh računara. Softverski emulator zatim sekvencijalno bira binarnu instrukciju Intel procesora i izvršava ekvivalentnu potprogramu napisanu u uputstvima Motorola procesora. Pošto Motorola procesor nema potpuno iste registre, zastavice, interne ALU itd., kao u Intelovim procesorima, on takođe mora simulirati (emulirati) sve ove elemente koristeći svoje registre ili memoriju.

Ovo je jednostavan, ali veoma spor posao, jer je jedna Intelova komanda znatno brža od komandne sekvence Motorola procesora koja je emulira. Izlaz u takvim slučajevima je korištenje tzv. aplikativnih softverskih okruženja ili operativnih okruženja. Jedna od komponenti takvog okruženja je skup API funkcija koje OS pruža svojim aplikacijama. Da bi se smanjilo vrijeme utrošeno na izvršavanje tuđih programa, okruženja aplikacija imitiraju pozive funkcijama biblioteke.

Efikasnost ovog pristupa je zbog činjenice da većina današnjih programa radi pod GUI (grafički korisnički interfejs) kao što su Windows, MAC ili UNIX Motif, dok aplikacije troše 60-80% vremena na izvršavanje GUI funkcija i drugih poziva OS biblioteka . Ovo je svojstvo aplikacija koje omogućava aplikacijskim okruženjima da kompenzuju veliku količinu vremena utrošenog na emuliranje programa po komandi. Pažljivo dizajnirano okruženje softverske aplikacije sadrži biblioteke koje oponašaju GUI biblioteke, ali su napisane u "nativnom" kodu. Time se postiže značajno ubrzanje izvršavanja programa sa API-jem drugog operativnog sistema. Ovaj pristup se također naziva emitiranjem kako bi se razlikovao od sporijeg procesa emulacije jednu po jednu naredbu.

Na primjer, za Windows program koji radi na Macintosh-u, kada tumači komande iz Intel procesora performanse može biti veoma nizak. 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 koja je ponovo kompajlirana za Motorola 680x0 procesor. Kao rezultat toga, u takvim dijelovima koda, brzina programa može dostići (i, eventualno, nadmašiti) brzinu rada na vlastitom procesoru.

Da bi se program napisan za jedan OS mogao izvršiti na drugom OS, nije dovoljno samo osigurati kompatibilnost API-ja. Koncepti koji stoje iza različitih operativnih sistema mogu se međusobno sukobljavati. Na primjer, u jednom OS aplikaciji može biti dozvoljeno da kontrolira I/O uređaje, u drugom - ove akcije su prerogativ OS-a.

Svaki OS ima svoje mehanizme zaštite resursa, svoje algoritme za obradu grešaka i izuzetaka, specifičnu strukturu procesora i šemu upravljanja memorijom, vlastitu semantiku pristupa datotekama i grafičko korisničko sučelje. Da bi se osigurala kompatibilnost, potrebno je organizovati beskonfliktan suživot u okviru jednog OS-a nekoliko metoda upravljanja računarskim resursima.

Postoje različite opcije za izgradnju više okruženja aplikacija, koje se razlikuju po arhitektonskim karakteristikama i funkcionalnosti koje pružaju različite stepene prenosivosti aplikacija. Jedna od najočitijih opcija za implementaciju više aplikacijskih okruženja zasniva se na standardnoj slojevitoj strukturi OS.

Drugi način da se izgradi više okruženja aplikacija baziran je na pristupu mikrojezgra. Istovremeno, veoma je važno uočiti osnovnu, zajedničku za sva okruženja aplikacija, razliku između mehanizama operativnog sistema i funkcija visokog nivoa specifične za svako od aplikativnih okruženja koje rešavaju strateške probleme. U skladu sa arhitektura mikrokernela sve funkcije OS-a implementiraju mikrokernel i serveri korisničkog načina rada. Važno je da je okruženje aplikacije dizajnirano kao poseban server u korisničkom režimu i da ne uključuje osnovne mehanizme.

Aplikacije koje koriste API upućuju sistemske pozive u odgovarajuće okruženje aplikacije preko mikrokernela. Aplikacijsko okruženje obrađuje zahtjev, izvršava ga (možda koristeći osnovne funkcije mikrokernela za pomoć) i šalje rezultat nazad u aplikaciju. U toku izvršavanja zahtjeva, okruženje aplikacije mora, zauzvrat, pristupiti osnovnim OS mehanizmima implementiranim od strane mikrokernela i drugih OS servera.

Sve prednosti i nedostaci mikronuklearne arhitekture inherentne su ovom pristupu izgradnji višestrukih aplikativnih okruženja, posebno:

• vrlo je lako dodati i isključiti okruženja aplikacija, što je posljedica dobre proširivosti mikro-jezgra OS-a;
• ako jedno od okruženja aplikacije ne uspije, ostale ostaju operativne, što doprinosi pouzdanosti i stabilnosti sistema u cjelini;
• niske performanse operativnih sistema mikrokernela utiču na brzinu aplikativnih alata, a samim tim i na brzinu aplikacija.

Kao rezultat toga, treba napomenuti da je kreiranje nekoliko aplikacijskih alata unutar jednog OS-a za izvršavanje aplikacija različitih OS-a način koji vam omogućava da imate jednu verziju programa i prenosite je između različitih operativnih sistema. Višestruka okruženja aplikacija pružaju binarnu kompatibilnost datog OS-a sa aplikacijama napisanim za druge OS-ove.

1.9. Virtuelne mašine kao moderan pristup implementaciji višestrukih aplikativnih okruženja

Koncept "monitora virtuelne mašine" (VMM) nastao je kasnih 60-ih kao softver nivo apstrakcije koji je podijelio hardversku platformu na više virtuelnih mašina. Svaka od ovih virtuelnih mašina (VM) bila je toliko slična osnovnoj fizičkoj mašini da je postojeća softvera mogao se izvršiti na njemu nepromijenjen. U to vrijeme, opći računarski zadaci su se obavljali na skupim mainframe-ovima (kao što je IBM / 360), a korisnici su cijenili sposobnost VMM-a da distribuira oskudne resurse u više aplikacija.

U 80-90-im godinama, cijena kompjuterske opreme je značajno smanjena i efektivna multitasking OS, što je smanjilo vrijednost VMM-a u očima korisnika. Glavni računari su ustupili mjesto mini-računarima, a zatim PC-ima, i nije bilo potrebe za VMM-om. Kao rezultat toga, kompjuterska arhitektura je jednostavno nestala hardver za njihovu efikasnu implementaciju. Krajem 80-ih, u nauci i proizvodnji, MVM se doživljavao kao ništa drugo do historijski kuriozitet.

Danas je MVM ponovo u centru pažnje. Intel, AMD, Sun Microsystems i IBM kreiraju strategije virtuelizacije, a pristupi bazirani na virtuelnim mašinama se razvijaju u akademskim krugovima i na univerzitetima kako bi se pozabavili pitanjima mobilnosti, sigurnosti i upravljanja. Šta se dogodilo između ostavke MVM-a i njihovog oživljavanja?

Tokom 1990-ih, istraživači na Univerzitetu Stanford počeli su da istražuju upotrebu VM-a za prevazilaženje ograničenja hardvera i operativnih sistema. Problemi su nastali sa računarima sa masovnom paralelnom obradom (MPP), koji su bili teški za programiranje i nisu mogli da pokreću postojeće operativne sisteme. Istraživači su otkrili da virtuelne mašine mogu učiniti ovu nezgodnu arhitekturu dovoljno sličnom postojećim platformama da iskoriste prednosti standardnih operativnih sistema. Iz ovog projekta proizašli su ljudi i ideje koje su postale zlatna rezerva VMware-a (www.vmware.com), prvog dobavljača VMM-a za mainstream računare.

Ironično, napredak modernih operativnih sistema i smanjenje troškova hardvera doveli su do problema za koje su se istraživači nadali da će ih rešiti uz pomoć VMM-a. Jeftina opreme doprinijela je brzom širenju računara, ali su često bili nedovoljno iskorišteni, zahtijevajući dodatni prostor i trud za održavanje. A posljedice rasta funkcionalnih mogućnosti OS-a bile su njihova nestabilnost i ranjivost.

Da bi smanjili uticaj pada sistema i zaštitili od hakova, sistemski administratori su se ponovo okrenuli samo jednom zadatku računarski model(sa jednom aplikacijom na jednoj mašini). To je rezultiralo dodatnim troškovima zbog povećanih zahtjeva za hardverom. Premještanje aplikacija s različitih fizičkih mašina na VM i konsolidacija ovih VM-a na nekoliko fizičkih platformi omogućilo je povećanje iskorištenosti opreme, smanjenje troškova upravljanja i smanjenje prostora. Dakle, sposobnost VMM-a da multipleksira hardver — ovog puta u ime konsolidacije servera i pomoćnog računarstva — ih je ponovo vratila u život.

Danas VMM nije postao toliko alat za organizaciju multitaskinga koliko je nekada bio zamišljen kao rješenje problema osiguranja sigurnosti, mobilnosti i pouzdanosti. Na mnogo načina, VMM daje kreatorima operativnih sistema mogućnost da razviju funkcionalnost koja nije moguća u današnjim složenim operativnim sistemima. Funkcije kao što su migracija i sigurnost su mnogo pogodnije za implementaciju na nivou VMM-a, koji održava kompatibilnost unatrag kada se implementiraju inovativna rješenja operativnog sistema uz zadržavanje prethodnih napretka.

Virtuelizacija je tehnologija koja se razvija. Uopšteno govoreći, virtuelizacija vam omogućava da odvojite softver od osnovne hardverske infrastrukture. Zapravo, prekida vezu između određenog skupa programa i određenog računara. Monitor virtuelne mašine se odvaja softvera od hardvera i formira međusloj između softvera koji pokreće virtuelne mašine i hardvera. Ovaj nivo omogućava VMM-u da u potpunosti kontrolira korištenje hardverskih resursa. gostujući operativni sistemi (GuestOS) koji rade na VM.

VMM stvara jedinstveni pogled na osnovni hardver tako da fizičke mašine različitih proizvođača sa različitim I/O podsistemima izgledaju isto i VM rade na bilo kom hardveru koji je dostupan. Bez brige o pojedinačnim mašinama sa njihovim čvrstim međusobnim vezama između hardvera i softvera, administratori mogu gledati na hardver kao na jednostavno skup resursa za pružanje bilo koje usluge na zahtev.

Hvala za potpuna inkapsulacija VMM monitor može mapirati VM na sve dostupne hardverske resurse, pa čak i prenijeti ga s jedne fizičke mašine na drugu. Zadatak balansiranja opterećenja na grupi mašina postaje trivijalan, a pojavljuju se pouzdani načini za rješavanje kvarova opreme i rasta sistema. Ako treba da isključite neispravan računar ili da pokrenete novi, VMM je u mogućnosti da redistribuira virtuelne mašine u skladu sa tim. Virtuelna mašina se lako replicira, omogućavajući administratorima da brzo isporuče nove usluge po potrebi.

Enkapsulacija takođe znači da administrator može suspendovati ili nastaviti VM u bilo kom trenutku, kao i da sačuva trenutno stanje virtuelne mašine ili da je vrati u prethodno stanje. Uz univerzalne mogućnosti poništavanja, lako je nositi se sa nesrećama i greškama u konfiguraciji. Enkapsulacija je u srcu generičkog modela mobilnosti jer se suspendirani VM može kopirati preko mreže, pohraniti i transportirati na prenosivim medijima.

VMM djeluje kao posrednik za sve interakcije između VM-a i osnovnog hardvera, održavajući više virtualnih mašina koje rade na jednoj hardverskoj platformi i osiguravajući pouzdanu izolaciju. VMM vam omogućava da sastavite grupu VM-ova sa malim zahtevima za resursima na zasebnom računaru, smanjujući troškove hardver i potreba za proizvodnim prostorom.

Potpuna izolacija je također važna za pouzdanost i sigurnost. Aplikacije koje su nekada radile na istoj mašini sada se mogu distribuirati na različite VM. Ako jedan od njih, kao rezultat greške, uzrokuje pad OS-a, druge aplikacije će biti izolirane od njega i nastaviti s radom. Ako nekoj od aplikacija prijeti vanjski napad, napad će biti lokaliziran unutar "kompromitovanog" VM-a. Dakle, VMM je alat za restrukturiranje sistema kako bi se povećala njegova otpornost i sigurnost, bez dodatnog prostora i administrativnih napora potrebnih kada se aplikacije izvode na odvojenim fizičkim mašinama.

VMM mora povezati hardverski interfejs sa VM-om, zadržavajući punu kontrolu nad osnovnom mašinom i procedurama za interakciju sa njenim hardverom. Postoje različite metode za postizanje ovog cilja, zasnovane na određenim tehničkim kompromisima. Kada se traže takvi kompromisi, uzimaju se u obzir glavni zahtjevi za VMM: kompatibilnost, performanse i jednostavnost. Kompatibilnost je važna jer je glavna prednost VMM-a mogućnost pokretanja naslijeđenih aplikacija. Performanse određuje količinu virtueliziranih troškova - programi na VM-u moraju raditi istom brzinom kao na stvarnoj mašini. Jednostavnost je potrebna jer će kvar VMM-a uzrokovati neuspjeh svih VM-ova koji rade na računalu. Konkretno, sigurna izolacija zahtijeva da VMM bude bez grešaka koje napadači mogu koristiti da unište sistem.

Umjesto da se petljate sa složenim prepisivanjem koda gostujućeg operativnog sistema, možete napraviti neke promjene na host operativnom sistemu promjenom nekih od "dosadnijih" dijelova kernela. Ovaj pristup se naziva paravirtualizacija. Jasno je da u ovom slučaju samo autor može prilagoditi jezgro OS-a, a, na primjer, Microsoft nije voljan da prilagodi popularni Windows 2000 kernel realnosti specifičnih virtuelnih mašina.

U paravirtualizaciji, VMM dizajner redefiniše interfejs virtuelne mašine, zamenjujući nevirtualizujući podskup originalnog skupa instrukcija pogodnijim i efikasnijim ekvivalentima. Imajte na umu da iako se OS mora prenijeti da bi radio na ovim VM-ovima, najčešće aplikacije mogu raditi nepromijenjene.

Najveći nedostatak paravirtualizacije je nekompatibilnost. Bilo koji operativni sistem dizajniran da radi pod kontrolom paravirtuelizovanog VMM monitora mora se preneti na ovu arhitekturu pregovaranjem o saradnji sa dobavljačima OS. Osim toga, stari operativni sistemi se ne mogu koristiti, a postojeće mašine se ne mogu lako zamijeniti virtuelnim mašinama.

Da bi postigao visoke performanse i kompatibilnost pri virtuelizaciji x86 arhitekture, VMware je razvio novu tehniku ​​virtuelizacije koja kombinuje tradicionalno izvršavanje uživo sa brzim binarnim prevođenjem u hodu. U većini modernih operativnih sistema, režimi rada procesora prilikom izvršavanja običnih aplikativnih programa se lako virtueliziraju, pa se stoga mogu virtuelizirati direktnim izvršavanjem. Neprikladni za virtuelizaciju privilegovani režimi mogu biti izvršeni od strane binarnog prevodioca, popravljajući "nezgodne" x86 instrukcije. Rezultat je vrlo efikasan virtuelna mašina koji u potpunosti odgovara hardveru i održava punu softversku kompatibilnost.

Konvertovani kod je vrlo sličan rezultatima paravirtualizacije. Redovne komande se izvršavaju nepromenjene, a komande koje zahtevaju posebnu obradu (kao što su POPF i komande za čitanje registara segmentnih kodova) translator zamenjuje sekvencama komandi koje su slične onima koje su potrebne za izvršenje na paravirtuelizovanoj virtuelnoj mašini. Međutim, postoji važna razlika: umjesto modifikacije izvornog koda operativnog sistema ili aplikacija, binarni prevodilac mijenja kod prvi put kada se izvrši.

Iako su potrebni dodatni troškovi za prevođenje binarnog koda, oni su zanemarljivi pod normalnim radnim opterećenjima. Prevoditelj obrađuje samo dio koda, a brzina izvršavanja programa postaje uporediva sa brzinom direktnog izvršavanja - čim se keš memorija 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 sistem pruža svojim aplikacijama. Da bi se smanjilo vrijeme utrošeno na izvršavanje tuđih programa, okruženja aplikacija imitiraju pozive funkcijama biblioteke.

Efikasnost ovog pristupa proizilazi iz činjenice da većina programa danas radi na grafičkim korisničkim interfejsima (GUI) kao što su Windows, Mac ili UNIX Motif, pri čemu aplikacije provode većinu svog vremena radeći neko dobro predvidljivo ponašanje. Oni kontinuirano pozivaju GUI biblioteke za manipulaciju prozorima i druge aktivnosti vezane za GUI. Danas se u tipičnim programima 60-80% vremena troši na izvršavanje GUI funkcija i drugih poziva OS biblioteke. Ovo je svojstvo aplikacija koje omogućava aplikacijskim okruženjima da kompenzuju veliku količinu vremena utrošenog na emulaciju programa jednu po jednu naredbu. Pažljivo dizajnirano okruženje softverske aplikacije sadrži biblioteke koje oponašaju interne GUI biblioteke, ali su napisane u "native" kodu, što značajno ubrzava izvršavanje programa sa API-jima drugog operativnog sistema. Ovaj pristup se ponekad naziva prevođenjem kako bi se razlikovao od sporijeg procesa emulacije koda jednu po jednu instrukciju.

Na primjer, za Windows program koji radi na Macintosh-u, tumačenje komandi iz Intel 80x86 procesora može biti veoma sporo. Ali kada se pozove GUI funkcija za otvaranje prozora, OS modul koji implementira okruženje Windows aplikacije može presresti ovaj poziv i preusmjeriti ga na rutinu otvaranja prozora koja je ponovo kompajlirana za Motorola 680x0 procesor. Kao rezultat toga, u takvim dijelovima koda, brzina programa može dostići (i eventualno nadmašiti) brzinu rada na njegovom "nativnom" procesoru.

Da bi se program napisan za jedan OS mogao izvršiti na drugom OS, nije dovoljno samo osigurati kompatibilnost API-ja. Koncepti koji stoje iza različitih operativnih sistema mogu se međusobno sukobljavati. Na primjer, u jednom operativnom sistemu, aplikaciji može biti dozvoljeno da direktno kontrolira I/O uređaje, u drugom su ove radnje prerogativ OS-a. Svaki operativni sistem ima svoje mehanizme zaštite resursa, svoje algoritme za obradu grešaka i izuzetaka, specifičnu strukturu procesa i šemu upravljanja memorijom, sopstvenu semantiku pristupa datotekama i grafički korisnički interfejs. Da bi se osigurala kompatibilnost, potrebno je organizovati beskonfliktan suživot u okviru jednog OS-a nekoliko metoda upravljanja računarskim resursima.

3. 7. 3. Metode implementacije primijenjenih softverskih okruženja

Kreiranje punopravnog okruženja aplikacije, potpuno kompatibilnog sa okruženjem drugog operativnog sistema, prilično je složen zadatak, usko povezan sa strukturom operativnog sistema. Postoje različite opcije za izgradnju višestrukih aplikativnih okruženja, koje se razlikuju kako po karakteristikama arhitektonskih rješenja tako i u funkcionalnosti koje pružaju različite stepene prenosivosti aplikacija.

U mnogim verzijama UNIX OS-a, prevodilac okruženja aplikacije implementiran je kao obična aplikacija. U operativnim sistemima izgrađenim korišćenjem koncepta mikrokernela, kao što je Windows NT, okruženja aplikacija rade kao serveri u korisničkom režimu. A u OS/2, sa njegovom jednostavnijom arhitekturom, alati za organizovanje okruženja aplikacija ugrađeni su duboko u operativni sistem.

Jedna od najočitijih opcija za implementaciju više aplikacijskih okruženja zasniva se na standardnoj slojevitoj strukturi OS. Na sl. 3. 8 operativni sistem OS1 podržava, pored svojih "nativnih" aplikacija, aplikacije operativnog sistema OS2. Za to sadrži posebnu aplikaciju - okruženje aplikativnog softvera koje prevodi interfejs "stranog" operativnog sistema - API OS2 u interfejs svog "domaćeg" operativnog sistema - API OS1.

Rice. 3. 8. Aplikacijsko softversko okruženje koje prevodi sistemske pozive

U drugoj implementaciji višestrukih aplikativnih okruženja, operativni sistem ima više istovrsnih API-ja. U primjeru prikazanom na sl. 3. Na primjer, operativni sistem podržava aplikacije napisane za OS1, OS2 i OS3. Da bi se to uradilo, interfejsi za programiranje aplikacija svih ovih operativnih sistema nalaze se direktno u prostoru kernela sistema: API OS1, API OS2 i API OS3.

Rice. 3. 9. Implementacija interoperabilnosti zasnovane na više peer API-ja

U ovoj varijanti, funkcije na nivou API-ja odnose se na funkcije OS nižeg nivoa koje moraju podržavati sva tri općenito nekompatibilna okruženja aplikacija. Različiti operativni sistemi različito upravljaju sistemskim vremenom, koriste drugačiji format doba dana, dijele procesorsko vrijeme na osnovu 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 da se izgradi više okruženja aplikacija baziran je na pristupu mikrojezgra. Istovremeno, veoma je važno odvojiti osnovne mehanizme operativnog sistema koji su zajednički za sva okruženja aplikacija od funkcija visokog nivoa specifične za svako od aplikativnih okruženja koje rešavaju strateške probleme.

Prema arhitekturi mikrokernela, sve funkcije OS implementiraju mikrokernel i serveri korisničkog načina rada. Važno je da svako okruženje aplikacije bude dizajnirano kao poseban server u korisničkom režimu i da ne uključuje osnovne mehanizme (slika 3. 10). Aplikacije koje koriste API upućuju sistemske pozive u odgovarajuće okruženje aplikacije preko mikrokernela. Aplikacijsko okruženje obrađuje zahtjev, izvršava ga (možda koristeći osnovne funkcije mikrokernela za pomoć) i šalje rezultat nazad u aplikaciju. U toku izvršavanja zahtjeva, okruženje aplikacije mora, zauzvrat, pristupiti osnovnim OS mehanizmima implementiranim od strane mikrokernela i drugih OS servera.

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

Ovaj pristup konstrukciji višestrukih aplikativnih okruženja ima sve prednosti i nedostatke arhitekture mikrokernela, posebno:

veoma je lako dodavati i isključivati ​​okruženja aplikacija, što je posledica dobre proširivosti operativnih sistema mikrokernela;

pouzdanost i stabilnost se izražavaju u činjenici da ako jedno od okruženja aplikacije zakaže, sva ostala ostaju operativna;

niske performanse mikrokernel operativnih sistema utiču na brzinu okruženja aplikacija, a samim tim i na brzinu izvršavanja aplikacije.

Kreiranje nekoliko aplikacijskih okruženja unutar jednog operativnog sistema za izvršavanje aplikacija različitih OS je način koji vam omogućava da imate jednu verziju programa i da je prenosite između operativnih sistema. Višestruka okruženja aplikacija pružaju binarnu kompatibilnost datog OS-a sa aplikacijama napisanim za druge OS-ove. Kao rezultat, korisnici imaju veću slobodu izbora operativnih sistema i lakši pristup kvalitetnom softveru.

Pitanja za samotestiranje

Šta se podrazumeva pod arhitekturom OS?

Koja su tri glavna sloja u strukturi računarskog sistema?

Koja je uloga OS-a na interfejsu sistemskog poziva?

Koji uslovi moraju biti ispunjeni prilikom dizajniranja operativnog sistema da bi operativni sistem bio lako prenosiv?

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

Zašto je mikrokernel dobro prilagođen za podršku distribuiranom računarstvu?

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

Koja je suština bibliotečke metode prevođenja?

Kompatibilnost i višestruka okruženja aplikacija

Koncept višestrukih aplikacijskih okruženja odnosi se na potrebe krajnjeg korisnika — sposobnost operativnog sistema da pokreće aplikacije iz drugih operativnih sistema. Ovo svojstvo operativnog sistema se zove kompatibilnost.

Binarna i izvorna kompatibilnost

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

Kompatibilnost izvora zahteva odgovarajući kompajler u softveru računara na kojem nameravate da pokrenete aplikaciju, kao i kompatibilnost biblioteke i sistemskog poziva. U ovom slučaju, potrebno je prevesti dostupne izvore u izvršni modul.

Kompatibilnost izvora je važna prvenstveno za programere aplikacija koji imaju izvorni kod na raspolaganju. Za krajnje korisnike je od praktične 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.

Da li je operativni sistem binarni ili kompatibilan sa izvorom zavisi od mnogo faktora. Glavna među njima je arhitektura procesora na kojem radi novi OS. Ako procesor koristi isti skup instrukcija (moguće sa nekim dodacima) i isti raspon adresa, onda se binarna kompatibilnost može postići vrlo jednostavno. Da biste to učinili, dovoljno je ispuniti sljedeće uslove:

Pozivi API funkcija koje aplikacija sadrži moraju biti podržani od OS;

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

Teže je postići binarnu kompatibilnost za operativne sisteme dizajnirane za rad na procesorima različitih arhitektura. Pored poštovanja navedenih uslova, potrebno je organizovati emulaciju binarnog koda, što će dovesti do prilično sporog izvršavanja programa.

Kreiranje punopravnog okruženja aplikacije, potpuno kompatibilnog sa okruženjem drugog operativnog sistema, zadatak je usko povezan sa strukturom operativnog sistema. Postoje različite opcije za izgradnju višestrukih aplikativnih okruženja, koje se razlikuju kako po karakteristikama arhitektonskih rješenja tako i u funkcionalnosti koje pružaju različite stepene prenosivosti aplikacija.

Jedna od najočitijih opcija za implementaciju višestrukih aplikativnih okruženja zasnovana je na standardnoj slojevitoj strukturi OS-a i omogućava prevođenje sistemskih poziva.

Na slici 6, operativni sistem OS1 podržava, pored svojih aplikacija, aplikacije operativnih sistema OS2 i OS3.

Za to sadrži posebne aplikacije – aplikativno softversko okruženje – koje prevode interfejse „stranih“ operativnih sistema API OS2 i API OS3 u interfejs njihovog operativnog sistema – API OS1.

Slika 6 – Aplikaciona softverska okruženja koja prevode sistemske pozive

U drugoj implementaciji višestrukih aplikativnih okruženja, operativni sistem ima više istovrsnih API-ja (slika 7). U prikazanom primjeru, operativni sistem podržava aplikacije za OS1, OS2 i OS3.

Da bi se to uradilo, interfejsi za programiranje aplikacija svih ovih operativnih sistema nalaze se direktno u prostoru kernela sistema: API OS1, API OS2 i API OS3.

Slika 7 – Implementacija interoperabilnosti zasnovane na više API-ja ravnopravnih

U ovoj varijanti, funkcije na nivou API-ja odnose se na funkcije OS nižeg nivoa 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. Da bi jezgro odabralo željenu implementaciju sistemskog poziva, svaki proces mora proslediti set identifikacionih karakteristika kernelu.

Drugi način da se izgradi više okruženja aplikacija baziran je na pristupu mikrojezgra. Prema arhitekturi mikrokernela, sve funkcije OS implementiraju mikrokernel i serveri korisničkog načina rada. Svako okruženje aplikacije je dizajnirano kao poseban server u korisničkom režimu i ne uključuje osnovne mehanizme (slika 8). Aplikacije vrše sistemske pozive u odgovarajuće okruženje aplikacije preko mikrokernela. Okruženje aplikacije obrađuje zahtjev, izvršava ga i šalje rezultat aplikaciji. U toku izvršavanja zahtjeva, okruženje aplikacije mora, zauzvrat, pristupiti osnovnim OS mehanizmima implementiranim od strane mikrokernela i drugih OS servera.

Ovaj pristup konstrukciji višestrukih aplikativnih okruženja ima sve prednosti i nedostatke arhitekture mikrokernela, posebno:

Veoma je lako dodati i isključiti okruženja aplikacija, što je posledica dobre proširivosti operativnih sistema mikrokernela;

Pouzdanost i stabilnost se izražavaju u činjenici da ako jedno od okruženja aplikacije zakaže, sva ostala ostaju operativna;

Loše performanse mikrokernel operativnih sistema utiču na brzinu okruženja aplikacija, a samim tim i na brzinu izvršavanja aplikacije.

Slika 8 – Mikrokernel pristup implementaciji više aplikacija

Kreiranje više aplikativnih okruženja u okviru jednog operativnog sistema za izvršavanje aplikacija različitih OS je način koji vam omogućava da imate jednu verziju programa i da je prenosite između OS-a.