Alkalmazási szoftverkörnyezetek megvalósításának módszerei. Alkalmazási szoftver Alkalmazási szoftver megvalósításának módjai
Olvassa el is
Míg számos operációs rendszer architektúra jellemzője közvetlenül csak a rendszerprogramozókhoz kapcsolódik, a többalkalmazásos (működési) létesítmények koncepciója közvetlenül kapcsolódik a végfelhasználók igényeihez – a operációs rendszer más operációs rendszerekhez írt alkalmazások futtatása. Az operációs rendszernek ezt a tulajdonságát kompatibilitásnak nevezzük.
Az alkalmazások kompatibilitása lehet bináris és forrásszintű [ 13 ]. Az alkalmazások általában futtatható fájlokként tárolódnak az operációs rendszerben, amelyek kód és adat bináris képeit tartalmazzák. A bináris kompatibilitás akkor érhető el, ha egy végrehajtható programot futtathat egy másik operációs rendszer környezetben.
A forrásszintű kompatibilitás megköveteli a megfelelő fordító jelenlétét annak a számítógépnek a szoftverében, amelyen futni kívánják. ez az alkalmazás, valamint a kompatibilitás a könyvtárak és a rendszerhívások szintjén. Ez megköveteli az alkalmazás forráskódjának újrafordítását egy új végrehajtható modulba.
A forrásszintű kompatibilitás főleg azon alkalmazásfejlesztők számára fontos, akiknek rendelkezésére állnak ezek a források. De a végfelhasználók számára csak a bináris kompatibilitásnak van gyakorlati jelentősége, mivel csak ebben az esetben használhatják ugyanazt a terméket különböző operációs rendszereken és különböző gépeken.
A lehetséges kompatibilitás típusa számos tényezőtől függ. Ezek közül a legfontosabb a processzor architektúrája. Ha a processzor ugyanazt az utasításkészletet használja (talán kiegészítéssel, mint az IBM PC esetében: standard készlet + multimédia + grafika + streaming) és ugyanazt a címtartományt, akkor a bináris kompatibilitás egészen egyszerűen elérhető. Ehhez a következő feltételeknek kell teljesülniük:
Az alkalmazás által használt API-t az adott operációs rendszernek támogatnia kell;
az alkalmazás végrehajtható fájljának belső szerkezetének meg kell egyeznie az operációs rendszer végrehajtható fájljainak szerkezetével.
Ha a processzorok eltérő architektúrával rendelkeznek, akkor a fenti feltételek mellett meg kell szervezni a bináris kód emulációját. Például széles körben használják az Intel processzor utasításainak emulációját a Macintosh Motorola 680x0 processzoron. A szoftver emulátor ebben az esetben szekvenciálisan választja ki a bináris utasítást Intel processzorés végrehajtja a Motorola processzor utasításaiban írt egyenértékű szubrutint. Mivel a Motorola processzor nem rendelkezik pontosan ugyanazokkal a regiszterekkel, zászlókkal, belső ALU-val stb., mint az Intel processzoraiban, mindezeket az elemeket is szimulálnia (emulálnia) kell saját regiszterei vagy memória segítségével.
Egyszerű, de nagyon lassú munka, mivel egy Intel utasítás sokkal gyorsabban hajtódik végre, mint az azt emuláló Motorola processzor utasítássorozata. A kiút ilyen esetekben az úgynevezett alkalmazásszoftver-környezetek vagy operációs környezetek használata. Egy ilyen környezet egyik összetevője az alkalmazás interfész funkcióinak halmaza. API programozás, amelyet az operációs rendszer az alkalmazásai számára biztosít. A mások programjainak végrehajtásához szükséges idő csökkentése érdekében az alkalmazási környezetek a könyvtári funkciók hívását imitálják.
Ennek a megközelítésnek a hatékonysága annak köszönhető, hogy a legtöbb mai program GUI (grafikus felhasználói felület) vezérlése alatt fut. Windows típus, MAC vagy UNIX Motif, ahol az alkalmazások idejük 60-80%-át grafikus felhasználói felület (GUI) funkciókkal és más operációs rendszer-könyvtárhívásokkal töltik. Az alkalmazásoknak ez a tulajdonsága teszi lehetővé, hogy az alkalmazási környezetek kompenzálják a programok parancsonkénti emulációjával töltött sok időt. A gondosan megtervezett szoftveralkalmazási környezet olyan könyvtárakat tartalmaz, amelyek utánozzák a GUI-könyvtárakat, de „natív” kóddal írva. Így egy másik operációs rendszer API-jával jelentősen felgyorsul a programok végrehajtása. Egyébként ezt a megközelítést fordításnak nevezik, hogy megkülönböztessük a lassabb folyamattól, amikor egy-egy utasítást emulálunk.
Például egy Macintosh-on futó Windows-program esetében a processzorparancsok értelmezésekor Intel Performance nagyon alacsony lehet. De ha egy grafikus felhasználói felület függvényt hívunk, megnyílik egy ablak stb., az alkalmazást megvalósító operációs rendszer modul Windows környezet, el tudja fogni ezt a hívást, és átirányítja a Motorola 680x0 processzor számára újrafordított ablakra. Ennek eredményeként a kód ilyen szakaszaiban a program sebessége elérheti (és esetleg meg is haladhatja) a saját processzorán végzett munka sebességét.
Ahhoz, hogy az egyik operációs rendszerre írt program egy másik operációs rendszeren fusson, nem elég csak az API-kompatibilitás biztosítása. A különböző operációs rendszerek alapjául szolgáló fogalmak ütközhetnek egymással. Például az egyik operációs rendszerben egy alkalmazás engedélyezheti az I / O eszközök vezérlését, egy másikban ezek a műveletek az operációs rendszer előjoga.
Minden operációs rendszernek megvannak a saját erőforrás-védelmi mechanizmusai, saját hiba- és kivételkezelő algoritmusai, speciális processzorstruktúrája és memóriakezelési sémája, saját fájlelérési szemantikája és grafikája. felhasználói felület. A kompatibilitás biztosítása érdekében meg kell szervezni a konfliktusmentes együttélést ugyanazon az operációs rendszeren belül a számítógépes erőforrások kezelésének többféle módja között.
Különféle lehetőségek állnak rendelkezésre több alkalmazási környezet létrehozására, amelyek mind az építészeti megoldások jellemzőiben, mind az alkalmazások hordozhatóságát biztosító funkcionalitásban különböznek egymástól. A több alkalmazási környezet megvalósításának egyik legkézenfekvőbb lehetősége az operációs rendszer szabványos réteges szerkezetén alapul.
Tovább rizs. 1.9 Az OS1 a "natív" alkalmazásai mellett támogatja az OS2 és OS3 operációs rendszerek alkalmazásait is. Ehhez tartalmazza speciális alkalmazások, alkalmazásprogramozási környezetek, amelyek "idegen" operációs rendszerek API OS2 és API OS3 interfészeit "natív" operációs rendszerük interfészére fordítják - API OS1. Így például, ha az OS2 UNIX OS, az OS1 pedig OS/2, a fork() folyamatlétrehozó rendszerhívás végrehajtásához egy UNIX alkalmazásban, a szoftverkörnyezetnek hozzá kell férnie az OS/2 operációs rendszer kerneléhez a rendszerrel a DOS meghívásával. ExecPgm().
Rizs. 1.9. Több alkalmazási környezet szervezése
Sajnos az egyik operációs rendszer API-ját alkotó szinte összes funkció viselkedése általában jelentősen eltér egy másik operációs rendszer megfelelő funkcióinak viselkedésétől. Például annak érdekében, hogy az OS/2 Dos ExecPgm() folyamatlétrehozó függvénye teljes mértékben konzisztens legyen a fork() folyamatlétrehozó függvénysel UNIX-szerű rendszerekben, meg kell változtatni, és új funkcionalitást kell írni: támogatás a a szülőfolyamat címterének másolása a gyermekfolyamat területére [ 17 ].
A több alkalmazási környezet létrehozásának másik módja a mikrokernel megközelítésen alapul. Ugyanakkor nagyon fontos megjegyezni az alapvető, minden alkalmazási környezetre jellemző különbséget az operációs rendszer mechanizmusai és az egyes alkalmazási környezetekre jellemző, stratégiai problémákat megoldó magas szintű funkciók között. A mikrokernel architektúrának megfelelően az operációs rendszer összes funkcióját a mikrokernel és a felhasználói módú szerverek valósítják meg. Fontos, hogy az alkalmazási környezet a formában legyen kialakítva külön szerver felhasználói módban, és nem tartalmazza a mögöttes mechanizmusokat.
Az API-t használó alkalmazások rendszerhívásokat indítanak a megfelelő alkalmazási környezetbe a mikrokernelen keresztül. Az alkalmazási környezet feldolgozza a kérést, végrehajtja azt (esetleg a mikrokernel alapfunkcióitól kérve ehhez), és az eredményt visszaküldi az alkalmazásnak. A kérés végrehajtása során az alkalmazási környezetnek hozzá kell férnie a mikrokernel és más operációs rendszer szerverek által megvalósított mögöttes operációs rendszerekhez.
A többalkalmazásos környezet tervezésének ez a megközelítése a mikro-kernel architektúra összes előnyével és hátrányával rendelkezik, különösen:
alkalmazási környezetek hozzáadása és kizárása nagyon egyszerű, ami a mikro-kernel operációs rendszerek jó bővíthetőségének a következménye;
ha az egyik alkalmazási környezet meghibásodik, a többi működőképes marad, ami hozzájárul a rendszer egészének megbízhatóságához és stabilitásához;
a mikrokernel operációs rendszerek alacsony teljesítménye befolyásolja az alkalmazási eszközök sebességét, és ezáltal az alkalmazások sebességét.
Ennek eredményeként meg kell jegyezni, hogy több alkalmazási eszköz létrehozása ugyanazon az operációs rendszeren belül a különböző operációs rendszerek alkalmazásainak végrehajtásához olyan mód, amely lehetővé teszi a program egyetlen verziójának használatát, és annak átvitelét a különböző operációs rendszerek között. Több alkalmazási környezet biztosítja egy adott operációs rendszer bináris kompatibilitását más operációs rendszerekre írt alkalmazásokkal.
Elég egy komplett alkalmazáskörnyezet létrehozása, amely teljesen kompatibilis egy másik operációs rendszer környezetével kihívást jelentő feladat, amely szorosan kapcsolódik az operációs rendszer felépítéséhez. Többféle alkalmazási környezet felépítésére többféle lehetőség kínálkozik, amelyek mind az építészeti megoldások jellemzőiben, mind pedig funkcionalitás, amely különböző fokú alkalmazások hordozhatóságát biztosítja.
A UNIX operációs rendszer számos verziójában az alkalmazási környezet fordítója normál alkalmazásként van megvalósítva. A mikrokernel koncepcióval épített operációs rendszerekben, mint például a Windows NT, az alkalmazási környezetek felhasználói módú kiszolgálóként futnak. Az egyszerűbb architektúrájú OS/2-ben pedig az alkalmazási környezetek mélyen az operációs rendszerbe vannak beépítve.
A több alkalmazási környezet megvalósításának egyik legkézenfekvőbb lehetősége az operációs rendszer szabványos réteges szerkezetén alapul. ábrán. 3. 8 operációs rendszer Az OS1 a "natív" alkalmazásai mellett támogatja az OS2 operációs rendszer alkalmazásait is. Ehhez tartalmaz egy speciális alkalmazást - egy alkalmazásszoftver-környezetet, amely egy "idegen" operációs rendszer - API OS2 - interfészét a "natív" operációs rendszer - API OS1 - interfészére fordítja.
Rizs. 3. 8. Alkalmazási szoftverkörnyezet, amely sugároz
rendszerhívások
A többalkalmazásos környezet egy másik megvalósításában az operációs rendszer több társalkalmazás-programozási felülettel rendelkezik. ábrán látható. 3. A példában az operációs rendszer támogatja az OS1, OS2 és OS3 operációs rendszerre írt alkalmazásokat. Ennek érdekében az összes operációs rendszer alkalmazásprogramozási felületei közvetlenül a rendszer kernelterébe kerülnek: API OS1, API OS2 és API OS3.
Rizs. 3. 9. Kompatibilitás megvalósítása több alapján
peer API-k
Ebben a változatban az API-szintű függvények az alapul szolgáló OS-szint függvényeit hívják meg, amelyeknek támogatniuk kell mindhárom, általában nem kompatibilis alkalmazáskörnyezetet. A különböző operációs rendszerek eltérően kezelik a rendszeridőt, eltérő időformátumokat használnak, saját algoritmusaik alapján osztják fel a CPU-időt stb. Az egyes API-k funkcióit a kernel a megfelelő operációs rendszer sajátosságait figyelembe véve valósítja meg, még akkor is, ha hasonló céljuk van.
A több alkalmazási környezet létrehozásának másik módja a mikrokernel megközelítésen alapul. Ugyanakkor nagyon fontos elválasztani az operációs rendszer alapvető, minden alkalmazási környezetre jellemző mechanizmusait az egyes alkalmazási környezetekre jellemző, stratégiai problémákat megoldó magas szintű funkcióktól.
A mikrokernel architektúrának megfelelően az operációs rendszer összes funkcióját a mikrokernel és a felhasználói módú szerverek valósítják meg. Fontos, hogy minden alkalmazási környezet külön felhasználói módú szerverként legyen kialakítva, és ne tartalmazzon alapvető mechanizmusokat (3. 10. ábra). API hozzáférést használó alkalmazások rendszerhívások a megfelelő alkalmazási környezetbe a mikrokernelen keresztül. Az alkalmazási környezet feldolgozza a kérést, végrehajtja azt (esetleg a mikrokernel alapfunkcióitól kérve ehhez), és az eredményt visszaküldi az alkalmazásnak. A kérés végrehajtása során az alkalmazási környezetnek hozzá kell férnie a mikrokernel és más operációs rendszer szerverek által megvalósított mögöttes operációs rendszerekhez.
Rizs. 3. 10. Mikrokernel megközelítés a többszörös megvalósításához
alkalmazási környezetek
A többalkalmazásos környezet tervezésének ez a megközelítése rendelkezik a mikrokernel architektúra összes előnyével és hátrányával, különösen:
Alkalmazási környezetek hozzáadása és kizárása nagyon egyszerű, ami a mikrokernel operációs rendszerek jó bővíthetőségének a következménye;
A megbízhatóság és a stabilitás abban nyilvánul meg, hogy ha az egyik alkalmazási környezet meghibásodik, az összes többi működőképes marad;
· a mikrokernel operációs rendszerek alacsony teljesítménye befolyásolja az alkalmazási környezetek sebességét, és ezáltal az alkalmazások végrehajtásának sebességét.
Egy operációs rendszeren belül több alkalmazáskörnyezet létrehozása a különböző operációs rendszerek alkalmazásainak futtatásához lehetővé teszi a program egyetlen verziójának létrehozását és az operációs rendszerek közötti átvitelét. Több alkalmazási környezet biztosítja egy adott operációs rendszer bináris kompatibilitását más operációs rendszerekre írt alkalmazásokkal. Ennek eredményeként a felhasználók nagyobb szabadságot kapnak az operációs rendszerek és egyebek kiválasztásában könnyű hozzáférés minőségi szoftverre.
Kérdések önvizsgálathoz
- Mit jelent az operációs rendszer architektúrája?
- Mi a három fő réteg egy számítógépes rendszer szerkezetében?
- Milyen szerepet rendelt az operációs rendszer a rendszerhívási felülethez?
- Milyen feltételeknek kell teljesülnie az operációs rendszer tervezésekor, hogy az operációs rendszer könnyen hordozható legyen?
- Mi a különbség a mikrokernel architektúra és a hagyományos operációs rendszer architektúra között?
- Miért alkalmas a mikrokernel az elosztott számítástechnika támogatására?
- Mit jelent a többszörös alkalmazási környezet fogalma?
- Mi a könyvtári fordítási módszer lényege?
Munka vége -
Ez a téma a következőkhöz tartozik:
Operációs rendszer, folyamatok, hardver
Az operációs rendszer operációs rendszere a legnagyobb mértékben meghatározza az egész számítástechnikai rendszer egészének megjelenését, az OS két lényegében kevéssé összefüggő .. os virtuális kiterjesztett gépként a legtöbb számítógép használatát .. a felhasználó szemszögéből. , az operációs rendszer funkciója, hogy a felhasználó számára valamilyen kiterjesztett vagy virtuális ..
Ha további anyagra van szüksége ebben a témában, vagy nem találta meg, amit keresett, javasoljuk, hogy használja a munkaadatbázisunkban található keresést:
Mit csinálunk a kapott anyaggal:
Ha ez az anyag hasznosnak bizonyult az Ön számára, elmentheti az oldalára a közösségi hálózatokon:
| csipog |
Az összes téma ebben a részben:
A hardverplatformok jellemzői
Az operációs rendszer tulajdonságait közvetlenül befolyásolja az a hardver, amelyre irányul. Az operációs rendszereket a hardver típusa szerint osztályozzák. személyi számítógépek, mi
Feladatok és gyakorlatok
1. A számítógépek műszaki bázisának fejlődésében milyen események váltak mérföldkővé az operációs rendszerek történetében? 2. Mi volt az alapvető különbség az első kötegelt feldolgozó monitorok és
Operációs rendszer architektúra
Minden jól szervezett komplex rendszer világos és racionális felépítésű, azaz részekre oszlik - modulokra, amelyeknek teljesen kész funkcionális célja van.
Fő memória kezelése
A memória szavak vagy bájtok nagy tömbje, mindegyiknek saját címe van. Ez egy adattárház, amelyhez biztosított gyors hozzáférés szétosztva a processzor és
Külső memóriakezelés
Mivel a fő memória (elsődleges memória) ingatag és túl kicsi ahhoz, hogy az összes adatot és programot tartósan tárolja, a VS-nek másodlagos memóriát kell biztosítania a fő memória mentéséhez. Bol
Fájlkezelő alrendszer
A fájl a létrehozáskor meghatározott kapcsolódó információk gyűjteménye. A tényleges adatokon kívül a fájlok a programokat reprezentálják, mind forrás, mind objektum formában. Alrendszer
Hálózatépítés
Elosztott rendszer - processzorok halmaza, amelyek nem foglalnak le memóriát, vagy minden processzornak saját helyi memóriája van. A rendszer processzorai a következővel vannak összekötve számítógép hálózatés biztosítva
Kernel és kiegészítő operációs rendszer modulok
Az operációs rendszer felépítésének legáltalánosabb megközelítése az összes modul két csoportra osztása: kernel - az alapvető funkciókat ellátó operációs rendszer modulok;
Kernel és privilegizált mód
Az alkalmazások végrehajtásának megbízható vezérléséhez az operációs rendszernek bizonyos jogosultságokkal kell rendelkeznie az alkalmazásokkal szemben. Ellenkező esetben előfordulhat, hogy egy nem megfelelően működő alkalmazás
Réteges OS-struktúra
A kernel alapú operációs rendszer alatt futó számítási rendszer három hierarchikusan elrendezett rétegből álló rendszernek tekinthető: az alsó réteg alkotja a hardvert.
Magszerkezet
OS hardver támogatás. Eddig az operációs rendszerről úgy beszéltek, mint programok halmazáról, de az OS egyes funkcióit hardver is elláthatja. Költő
Hardverfüggőség és az operációs rendszer hordozhatósága
Sok operációs rendszer sikeresen fut különféle hardverplatformokon anélkül, hogy lényegesen megváltozna az összetételük. Ez nagyrészt annak köszönhető, hogy a különbségek ellenére
Az operációs rendszer hordozhatósága
Ha az operációs rendszer kódja viszonylag könnyen átvihető egyik processzortípusról egy másik processzortípusra, és egyfajta hardverplatformról egy hardverplatformra
Koncepció
A mikrokernel architektúra az operációs rendszer felépítésének klasszikus módjának alternatívája. A klasszikus építészet ebben az esetben a fent tárgyalt szerkezeti felépítést jelenti.
Bináris és forráskompatibilitás
Különbséget kell tenni a bináris szintű kompatibilitás és a forráskód szintű kompatibilitás között. Az alkalmazások általában bináris képeket tartalmazó futtatható fájlokként tárolódnak az operációs rendszerben.
Könyvtárak fordítása
A kiút ilyen esetekben az ún alkalmazási programok környezetek. Az alkalmazásszoftver-környezetet alkotó összetevők egyike egy funkciókészlet
Folyamat koncepció
A folyamat egy processzoron futó tevékenység. A legtágabb értelemben processzor a számítógép bármely olyan eszköze, amely
Erőforrás fogalma
Az operációs rendszer egyik funkciója, hogy hatékony és konfliktusmentes módot biztosítson a számítástechnikai rendszer erőforrásainak kezelésére. Az erőforrást gyakran indikátorként értelmezik
A virtualizáció fogalma
Ennek vagy annak az erőforrásnak a virtualizálása egy központosított erőforrás-elosztási rendszer keretében történik. A virtualizáció a felhasználó megtévesztésének két formáját valósítja meg:
Egyszeri megrendelésre vonatkozó szolgáltatási szakterületek
a) FIFO (First In -- First Out) - szolgáltatási fegyelem a beérkezés sorrendjében. Minden kérés a sor végére megy. Először a sor élén lévő jelentkezéseket szolgálják ki. Vázlatos
Megszakítási rendszer
Olyan helyzet, amely valamilyen független esemény hatására következik be, és egy program parancssorozatának ideiglenes leállításához vezet azzal a céllal.
Folyamat koncepció
A folyamat (feladat) olyan program, amely végrehajtási módban van. Minden folyamathoz saját címtér tartozik, amelyből olvasni és
Folyamatmodell
A többfeladatos rendszerben a valódi processzor folyamatról folyamatra vált, de a modell egyszerűsítése érdekében párhuzamosan (pszeudo-párhuzamosan) futó folyamatok halmazát veszik figyelembe. Fontolgat
Egy folyamat befejezése
(híváskilépés vagy ExitProcess): Ütemezett befejezés (végrehajtás vége) Ütemezett kilépés ismert hiba esetén (pl. hiányzó fájl)
Folyamathierarchia
A UNIX rendszerek merev folyamathierarchiával rendelkeznek. A fork rendszerhívás által létrehozott minden új folyamat az előző folyamat gyermeke. A gyermek folyamat a szülő folyamattól származik
Folyamat állapota
A folyamat három állapota a következő: Futás (a processzor elfoglalása) Kész (a folyamat ideiglenesen felfüggesztve van, hogy egy másik folyamat fusson) Várakozás (a folyamat
Az áramlás fogalma
Minden folyamathoz tartozik egy címtér és egyetlen végrehajtható utasításfolyam. Többfelhasználós rendszerekben minden egyes hívás ugyanahhoz a szolgáltatáshoz az érkezés
áramlási modell
Minden szál társítva van: Parancsvégrehajtási számláló Az aktuális változók regiszterei Verem állapot A szálak megosztják egymással az elemeket
A szálak használatának előnyei
Egyes esetekben a program egyszerűsítése közös címtér használatával. A szál létrehozásának sebessége egy folyamathoz képest körülbelül 100-szoros. Előléptetett
Szálak megvalósítása felhasználói térben, kernelben és vegyesben
A - szálak a B felhasználói térben
Windows implementációs szolgáltatások
Négy fogalom használatos: Job – folyamatok halmaza közös kvótákkal és korlátokkal Folyamat – erőforrások tárolója (memória...), legalább egy szálat tartalmaz. Poto
Kommunikáció a folyamatok között
Olyan helyzetek, amikor a folyamatoknak kölcsönhatásba kell lépniük: Információ átvitele egyik folyamatból a másikba A folyamatok tevékenységeinek ellenőrzése (például: amikor versenyeznek
Információk átadása egyik folyamatból a másikba
Az átvitel többféleképpen történhet: Osztott memória A csatornák (pipes) egy pszeudofájl, amelybe az egyik folyamat ír, a másik olvas.
Verseny állapot
A versenyhelyzet olyan helyzet, amikor több folyamat egyszerre olvas vagy ír adatokat (memóriába vagy fájlba). Vegyünk egy példát, ahol két folyamat próbálkozik
Kritikus területek
A kritikus régió egy olyan program része, amely hozzáfér a megosztott adatokhoz. A viták elkerülésének feltételei és eredményes munka folyamatok: Két folyamat nem
Változók zárolása
Bevezetésre kerül a zárváltozó fogalma, i.e. ha ennek a változónak az értéke például 1, akkor az erőforrást egy másik folyamat foglalja el, és a második folyamat készenléti üzemmódba (blokkok) lép addig, amíg
Szigorú váltakozás
Ebben a modellben a folyamatok szigorúan sorra hajthatók végre egy változó segítségével.
Folyamat interakciós primitívek
Bemutatjuk a két primitív fogalmát. Az alvás egy olyan rendszerkérelem, amely a hívási folyamatot addig blokkolja, amíg egy másik folyamat el nem indítja. wak
szemaforok
A szemaforok a jövő számára tárolt triggerjelek számlálására szolgáló változók. Két műveletet javasoltak lefelé és felfelé (az alvás és az ébrenlét analógjai
Ütemezés kötegelt feldolgozó rendszerekben
6.2.1 First In Fist Out (FIFO) A folyamatok érkezésükkor sorba kerülnek. Előnyök:
Ciklikus tervezés
A legegyszerűbb és gyakran használt ütemezési algoritmus. Minden folyamat kap egy CPU-időszeletet. Amikor a kvantum véget ér, a folyamatot az ütemező átviszi a végére
Kiemelt tervezés
Minden folyamathoz prioritás van hozzárendelve, és a vezérlés a legmagasabb prioritású folyamatra kerül át. A prioritás lehet dinamikus vagy statikus. Dinamika
Ütemezés valós idejű rendszerekben
A valós idejű rendszerek a következőkre oszthatók: merev (szigorú határidők minden feladatra) - mozgásvezérlés rugalmas (az időbeosztás megszegése nem kívánatos, de elfogadható) -
Általános valós idejű ütemezés
A modellt akkor használjuk, ha minden folyamat a saját feladatával és végrehajtási ütemtervével küzd a processzorért. A tervezőnek tudnia kell: milyen gyakorisággal az egyes
Folyamat holtpontja
A folyamatok holtpontja akkor fordulhat elő, ha több folyamat verseng ugyanazért az erőforrásért. Az erőforrások lapozhatók és lapozatlanok, hardverek és szoftverek lehetnek.
Holtpontok modellezése
Zsákutcák modellezése grafikonokkal. Egyezmények Egy ilyen modellen
Holtpont észlelése és megszüntetése
A rendszer nem próbálja megakadályozni a holtpontot, hanem megpróbálja észlelni és feloldani. Holtpont észlelése, ha minden típusból egy erőforrás van
Dinamikus holtpont elkerülése
Ily módon az operációs rendszernek tudnia kell, hogy az erőforrás-támogatás biztonságos-e vagy sem. Erőforrás-pályák Tekintsünk két folyamatból és két erőforrásból álló modellt
A holtpontokhoz szükséges négy feltétel elkerülése
Kölcsönös kizárási feltételek megelőzése Minimalizálhatja az erőforrásokért versengő folyamatok számát. Például a nyomtató spooling használata, amikor t
I/O hardver alapelvek
Az I/O vezérlőrendszer két alsó szintje hardver: maguk az eszközök, amelyek közvetlenül hajtanak végre műveleteket, és ezek vezérlői, amelyek a rendszerezést szolgálják. közös munka eszköz
Eszközvezérlők
Az I/O eszközök általában két részből állnak: mechanikus (nem szó szerint értendő) - lemez, nyomtató, monitor elektronikus - vezérlő ill.
Memória-leképezett I/O
Minden vezérlőnek több regisztere van, amelyek a központi processzorral való interakcióra szolgálnak. Ezen regiszterek segítségével az OS vezérli (olvas, ír, bekapcsol stb.) és meghatározza
Közvetlen memória hozzáférés (DMA - Közvetlen memória hozzáférés)
A közvetlen memóriaelérés egy DMA vezérlő segítségével valósul meg. A vezérlő több regisztert tartalmaz: memóriacímregiszter bájtszámláló
Megszakítja
Az I/O eszköz elindulása után a processzor más feladatokra vált át. A processzor végének jelzésére a készülék megszakítást kezdeményez,
I/O szoftverfeladatok
A főbb megoldandó feladatok szoftver I/O: Eszközfüggetlenség – például egy fájlból adatokat kiolvasó programnak nem kell azon gondolkodnia, hogy miért
Szoftver I/O
Ebben az esetben a CPU elvégzi az összes munkát. Tekintsük az ABCDEFGH karakterlánc ilyen módon történő nyomtatásának folyamatát.
Megszakítás-vezérelt I/O
Ha az előző példában a puffer nincs használatban, és a nyomtató másodpercenként 100 karaktert nyomtat, akkor minden karakter 10 ms-t vesz igénybe, ezalatt a processzor tétlen lesz, és várja, hogy a nyomtatás készen álljon.
Megszakításkezelők
A megszakításokat a lehető legmélyebben kell elrejteni az operációs rendszer mélyén, hogy az operációs rendszernek minél kevesebbet kelljen foglalkoznia velük. A legjobb, ha blokkolja azt az illesztőprogramot, amely elindította az I/O-t. Algo
Eszközmeghajtók
Eszközillesztő - minden eszközhöz szükséges. A különböző operációs rendszerek különböző illesztőprogramokat igényelnek. Az illesztőprogramoknak a kernel részének kell lenniük (monolit rendszeren), hogy hozzáférjenek a regiszterekhez.
Eszközfüggetlen I/O szoftver
Eszközfüggetlen I/O szoftver jellemzői: Egységes interfész az eszközillesztőknek, pufferelési hibaüzenetek
I/O szintek és funkciók általánosítása
Az I / O rendszer szintjei és alapvető funkciói Baz
Blokkolás, nem blokkoló és aszinkron rendszerhívások
Az I / O műveletek megvalósításához kapcsolódó összes rendszerhívás három csoportba osztható a folyamat és az I / O eszköz közötti interakció megvalósításának módja szerint. az elsőre, arra
Pufferelés és gyorsítótár
A puffer általában egy bizonyos memóriaterület az információk tárolására, amikor két eszköz, két folyamat vagy egy folyamat és egy eszköz között adatcsere történik. Csere be
Spooling és rögzítő eszközök
A spooling fogalmáról kurzusunk első előadásában beszéltünk, mint olyan mechanizmusról, amely először tette lehetővé egy feladat valós I/O műveleteinek kombinálását egy másik feladat végrehajtásával.
Megszakítás és hibakezelés
Ha egy külső eszközzel végzett munka során a számítástechnikai rendszer nem az állapot lekérdezésének módszerét használja, hanem a megszakítási mechanizmust használja, akkor megszakítás esetén, mint már
Lekérdezés tervezése
Nem blokkoló rendszerhívás használatakor kiderülhet, hogy kívánt eszközt már elfoglalt néhány művelettel. Ebben az esetben a nem blokkoló hívás azonnal előfordulhat
A UNIX I/O vezérlő alrendszer alapelvei
1. Ez az alrendszer az adatkezelési alrendszerhez (fájlrendszerhez) hasonlóan épül fel. A felhasználó egységes hozzáférést biztosít a PU-hoz és a fájlokhoz. Fájl alatt az OS-ben
OS memóriakezelés
4.1. A szervezés és irányítás fogalma fizikai memória operációs rendszerekben 4.2. A fő memória összekapcsolt kiosztásának módjai 4.2.1. Csatlakoztatott elosztott
A fizikai memória szervezésének és kezelésének megértése operációs rendszerekben
A számítógép fő (elsődleges, fizikai, valós) memóriájának megszervezése és kezelése az operációs rendszerek felépítését meghatározó egyik legfontosabb tényező. Az angol műszakiban
Csatlakoztatott memória lefoglalása egyetlen felhasználó számára
Az egy felhasználóhoz tartozó csatlakoztatott memóriafoglalást, más néven egyszeri folyamatos lefoglalást kötegelt egyprogramos üzemmódban működő számítógépekben használják a legegyszerűbb vezérléssel.
Csatlakoztatott memóriafoglalás többprogramos feldolgozásban
Többprogramos feldolgozás esetén egyszerre több feladat kerül a számítógép memóriájába. A jobok közötti memória lefoglalása ebben az esetben a következő módokon történhet:
Az információk memóriába helyezésének stratégiái
A memóriafoglalási stratégiák célja annak meghatározása, hogy a bejövő programokat és adatokat a fő memóriában hol kell elhelyezni egy nem mozgatható memóriafoglalásban.
A virtuális memória alapfogalmai
A virtuális memória kifejezést általában egy adott számítástechnikai gép elsődleges (valós, fizikai) memóriakapacitásánál jóval nagyobb memóriaterület megcímzésének képességével társítják.
A virtuális memória lapozása
A tisztán lapozó virtuális cím egy rendezett pár (p, d), ahol p a bejövő oldalszám virtuális memória, és d a p oldalon belüli eltolás. A folyamat futhat
A virtuális memória szegmensszervezése
A virtuális memória szegmentált felépítésében a virtuális cím egy n = (s, d) rendezett pár, ahol s a virtuális memória szegmens száma, d pedig a szegmensen belüli eltolás. A folyamat lehet
A virtuális memória oldalszegmenses szervezése
A személyhívó rendszereknek megvannak a virtuális memória megvalósításának mindkét módja előnyei. A szegmensek általában egész számú oldalt tartalmaznak, és nem szükséges, hogy minden oldal legyen
Virtuális memória kezelési stratégiák
A virtuális memóriakezelési stratégiák, akárcsak a fizikai memóriakezelési stratégiák, három kategóriába sorolhatók: push stratégiák, elhelyezési stratégiák és pop stratégiák.
Push stratégiák
A következő stratégiákat használják a tolás szabályozására: nyomás (pumpálás) igény szerint (igény szerint); tolás (pumpálás) ólommal (előre).
Elhelyezési stratégiák
A virtuális memória lapozásával rendelkező rendszerekben az újonnan betöltött oldalak elhelyezéséről szóló döntés meglehetősen egyszerű: új oldal bármely szabadon elhelyezhető
Push stratégiák
A többprogramozós rendszerekben általában az összes elsődleges memória foglalt. Ebben az esetben a memóriakezelőnek kell eldöntenie, hogy melyik oldalt vagy melyik szegmenst távolítsa el az elsődlegesről
Fájl elnevezése
A fájlnév hossza az operációs rendszertől függ, 8 (MS-DOS) és 255 (Windows, LINUX) karakter közötti lehet. Az operációs rendszerek megkülönböztethetik a kis- és nagybetűket. Például a WINDOWS és az MS-DOS ablakai ugyanazok, és t
Fájlszerkezet
Három alapvető fájlstruktúra: 1. Byte Sequence – Az operációs rendszer nem törődik a fájl tartalmával, csak a bájtokat látja. Egy ilyen rendszer fő előnye a rugalmasság
Fájl típusok
A fájlok fő típusai: · Normál – felhasználói információkat tartalmaznak. Windows és UNIX rendszeren használják. · Katalógusok - rendszerfájlokat gondoskodás
Fájl attribútumok
Főbb fájlattribútumok: · Biztonság – ki és hogyan férhet hozzá a fájlhoz (felhasználók, csoportok, olvasás/írás). Windows és UNIX rendszeren használják. · Jelszó - jelszó fa
Fájlok leképezve a memória címterére
Néha célszerű egy fájlt a memóriába képezni (nincs szükség I/O rendszerhívásokra a fájl kezeléséhez), és a memóriával dolgozni, majd a módosított fájlt lemezre írni. Használat során
Egyszintű címtárrendszerek
Ebben a rendszerben az összes fájl egy könyvtárban található. od
Útvonal neve
A könyvtárfa rendszerezéséhez valamilyen módon meg kell adnia egy fájlt. A fájl megadásának két fő módja a következő: abszolút elérési út – a gyökértől származó elérési utat adja meg
Címtár megvalósítása
Fájl megnyitásakor az elérési út nevével keresi meg a bejegyzést a könyvtárban. A címtárbejegyzés a lemezblokkok címére mutat. A rendszertől függően ez lehet: lemez pokol
Hosszú fájlnevek megvalósítása
A korábbi operációs rendszerek rövid fájlneveket használtak, az MS-DOS legfeljebb 8 karaktert, a UNIX 7-es verziója pedig legfeljebb 14 karaktert. Most már hosszabb fájlnevek használatosak (legfeljebb 255 karakter vagy több).
Fájlkeresés felgyorsítása
Ha a könyvtár nagyon nagy (több ezer fájl), akkor a könyvtár szekvenciális olvasása nem túl hatékony. 1 Hash tábla használata a fájlkeresés felgyorsítására.
A - megosztott fájl
Az ilyen fájlrendszert irányított aciklikus gráfnak (DAG, Directed Acyclic Graph) nevezzük. Probléma adódik, ha a lemezcímeket maguk a címtárbejegyzések tartalmazzák.
Blokkméret
Ha úgy döntünk, hogy a fájlt blokkokban tároljuk, akkor felmerül a kérdés ezeknek a blokkoknak a méretével kapcsolatban. Két véglet létezik: Nagy blokkok - például 1 MB, akkor még egy 1 bájtos fájl is egy egész blokkot vesz fel
Ingyenes blokkok elszámolása
A szabad blokkok számbavételének két fő módja van: · Lemezblokkok összekapcsolt listája, minden blokk annyi szabad blokkszámot tartalmaz, amennyi zavarja a blokkot. Gyakran a tartaléklistára
Lemezkvóták
A felhasználó korlátozására van egy kvótamechanizmus. Kétféle korlát: kemény - nem léphető át Rugalmas - túlléphető, de a felhasználó kijelentkezésekor
biztonsági mentés
Olyan esetek, amelyekben biztonsági mentés szükséges: Vészhelyzetek, amelyek a lemezen lévő adatok elvesztését eredményezik A fájlok véletlen törlése vagy szoftveres megsérülése
A fájlrendszer konzisztenciája
Ha a rendszer összeomlik a módosított blokk írása előtt, előfordulhat, hogy a fájlrendszer inkonzisztens állapotba kerül. Főleg, ha i-node blokkról van szó, könyvtárblokkról és
gyorsítótárazás
Blokkgyorsítótár (puffergyorsítótár) - a memóriában tárolt, de logikailag a lemezhez tartozó blokkok halmaza. Minden olvasási kérelmet a lemez elfog, és a jelenléte a szükséges
ISO 9660 fájlrendszer
További információ - http://en.wikipedia.org/wiki/ISO_9660 A szabványt 1988-ban fogadták el. A szabvány szerint a lemezek logikai partíciókra oszthatók, de figyelembe vesszük azokat a lemezeket, amelyek
ISO 9660 katalógus bejegyzés
Fájl helye - a kezdeti blokk száma, mert. a blokkok egymás után kerülnek elhelyezésre. L - a fájlnév hossza bájtban Fájlnév - 8 karakter, 3 karakter kiterjesztés (a kompatibilitás miatt
Rock Ridge kiterjesztések UNIX-hoz
Ez a kiterjesztés azért jött létre, hogy a UNIX fájlrendszer jelen legyen a CD-ROM-on. Ehhez a Rendszerhasználat mezőt használjuk. A kiterjesztések a következő mezőket tartalmazzák: 1. PX -
Fájlrendszer UDF (univerzális lemezformátum)
További információ - http://ru.wikipedia.org/wiki/Universal_Disk_Format Eredetileg DVD-hez készült, az 1.50-es verzió CD-RW és CD-R támogatásával. Most a legújabb verzió
MS-DOS fájlrendszer (FAT-12,16,32)
Az első verzióknak csak egy könyvtáruk volt (MS-DOS 1.0). Az MS-DOS 2.0 óta hierarchikus felépítést alkalmaznak. Könyvtárbejegyzések, rögzített 32 bájt. Fájlnevek -
A Windows 98 rendszerben engedélyezve lesznek
Az archívum attribútum szükséges a programokhoz Tartalékmásolat, ennek megfelelően határozzák meg, hogy másolják-e a fájlt vagy sem. Az időmező (16 bit) három almezőre oszlik:
Windows 98 bővítmény a FAT-32 számára
10 szabad bitet használtak a kiterjesztéshez. Forma
A FAT-32 feletti fő felépítmény, ezek hosszú fájlnevek
Minden fájlhoz két nevet kezdtek hozzárendelni: 1. Rövid 8+3 az MS-DOS-szal való kompatibilitás érdekében 2. hosszú név fájl, Unicode formátumban A fájlt bármely
Bejegyzési könyvtárak formátuma hosszú fájlnév töredékével a Windows 98 rendszerben
Az "Attribútumok" mező lehetővé teszi egy hosszú név töredékének (0x0F érték) megkülönböztetését a fájlleírótól. Régi MS-DOS programok katalógusbejegyzései 0x0 attribútummező értékkel
NTFS fájlrendszer
Fájl NTFS rendszer Windows NT-re lett kifejlesztve. Jellemzők: · 64 bites címek, pl. elméletileg 264*216 bájtot támogat (1 208 925 819 M
Fájl keresése név szerint
Fájl létrehozásakor a program meghívja a CreateFile("C:windowsreadmy.txt", ...) könyvtári eljárást. Ez a hívás az n szintű megosztott könyvtárba kerül
Fájltömörítés
Ha a fájl tömörítettként van megjelölve, a rendszer íráskor automatikusan tömöríti, olvasáskor pedig kicsomagolja. Munkaalgoritmus: 1. A fájl első 16 blokkja vizsgálatra kerül (n
Fájl titkosítás
Bármilyen információ, ha nincs titkosítva, hozzáférés útján olvasható. Ezért a legtöbb megbízható védelem jogosulatlan hozzáférésből származó információk - titkosítás. Még ha lopnak is tőled
UNIX V7 fájlrendszer
Bár régi fájlrendszerről van szó, az alapelemeket még mindig a modern UNIX rendszerek használják. Jellemzők: A fájlnevek legfeljebb 14 ASCII karakterből állhatnak, kivéve a „/&q” perjelet
i-node szerkezet
Mező Bájtok Leírás Mód Fájltípus, biztonsági bitek, setuid és setgid bitek Nlinks
Fájl létrehozása és kezelése
fd=creat("abc", mode) – Példa egy abc fájl létrehozására a módváltozóban megadott védelmi móddal (amelyhez a felhasználók hozzáférhetnek). A rendszert használják
BSD fájlrendszer
Az alap a klasszikus UNIX fájlrendszer. Jellemzők (eltérő korábbi rendszer): A fájlnév hossza 255 karakterre nőtt. Átszervezett könyvtárak
Az EXT2 fájlrendszer helye a lemezen
Egyéb jellemzők: · Blokkméret 1 KB · Minden i-node mérete 128 bájt. Az i-node 12 közvetlen és 3 indirekt címet tartalmaz, az i-csomópontban lévő cím hossza 4 bájt lett, ami kb.
EXT3 fájlrendszer
Az EXT2-vel ellentétben az EXT3 egy naplózó fájlrendszer, azaz. meghibásodások után nem kerül inkonzisztens állapotba. De teljesen kompatibilis az EXT2-vel.
XFS fájlrendszer
Az XFS a Silicon Graphics által kifejlesztett, de nyílt forráskódú naplózó fájlrendszer. Hivatalos információ: http://oss.sgi.com/project
RFS fájlrendszer
Az RFS (RaiserFS) a Namesys által kifejlesztett naplózó fájlrendszer. Hivatalos információ a RaiserFS-ről Néhány szolgáltatás: Hatékonyabb munka
JFS fájlrendszer
JFS (Journaled Fájlrendszer) egy naplózó fájlrendszer, amelyet az IBM fejlesztett ki AIX operációs rendszerhez, de most nyílt forráskódú. Hivatalos információ a Journaled File S-ről
Az NFS fájlrendszerszintek felépítése
VFS (virtuális fájlrendszer) – virtuális fájlrendszer. A megnyitott fájlok táblázatának kezeléséhez szükséges. Jelentkezések mindenkinek fájl megnyitása v-csomópontoknak nevezzük
Emulációs alternatíva - több alkalmazási környezet, amely API-funkciókat tartalmaz. Utánozzák az alkalmazási környezet könyvtári funkcióinak hívását, de valójában belső könyvtáraikat hívják. Ez az úgynevezett könyvtári fordítás. Ez tisztán szoftver.
Ahhoz, hogy az egyik operációs rendszer alatt írt program a másik alatt működjön, biztosítani kell a folyamatvezérlési módszerek konfliktusmentes interakcióját a különböző operációs rendszerekben.
Alkalmazási szoftverkörnyezetek megvalósításának módjai
Az architektúrától függően:
1. Alkalmazási szoftverkörnyezet alkalmazás formájában (a natív operációs rendszer magjának felső rétege).
Felhasználói üzemmód, a rendszerhívások (API-hívások) natív operációs rendszer hívásokká történő fordítása. Megfelel a klasszikus többrétegű operációs rendszernek (Unix, Windows).
2. Több egyformán működő alkalmazási környezet jelenléte. Mindegyik a mag külön rétegének formájában.
Kiváltságos működési mód. Az API meghívja az operációs rendszer mögöttes (privilegizált) rétegének funkcióit. A hívás felismerésének és adaptálásának feladata a rendszerre hárul. Kívánt nagyszámú erőforrások. Az azonosító jellemzők készlete átadásra kerül a kernelnek felismerés céljából.
3. Mikronukleáris elv.
Bármely alkalmazáskörnyezet külön felhasználói módú kiszolgálóként van kialakítva. Az API-t használó alkalmazások rendszerhívásokat indítanak a megfelelő alkalmazási környezetbe a mikrokernelen keresztül. Az alkalmazási környezet feldolgozza a kérést, és a mikrokernelen keresztül visszaküldi az eredményt. Használhat mikrokernel függvényeket. Többféle hozzáférés is lehetséges más erőforrásokhoz (miközben a mikrokernel fut).
OS interfészek
OS interfész egy alkalmazás programozó rendszer. Szabványok (POSIX, ISO) szabályozzák.
1. Felhasználói felület- speciális segítségével valósítják meg szoftver modulok, amely a felhasználói kéréseket egy speciális parancsnyelven az operációs rendszer felé irányuló kérésekké fordítja le.
Az ilyen modulok halmazát ún tolmács. Lexikális és elemzést hajt végre, és vagy magát a parancsot hajtja végre, vagy átadja az API-nak.
2. API- az alkalmazási programok operációs rendszer-erőforrásokkal való ellátására és egyéb funkciók megvalósítására szolgál. Az API a kernelhez és az operációs rendszer bővítményeihez tartozó függvények, eljárások készletét írja le. API használ rendszerprogramok mind az operációs rendszeren belül, mind azon kívül, alkalmazási programok használatával a programozási környezeten keresztül.
Az operációs rendszer erőforrásokkal való ellátásának középpontjában végső soron a szoftveres megszakítás áll. Megvalósításuk rendszertől függően (vektor, táblázatos). Számos lehetőség van az API megvalósítására OS szinten (leggyorsabb, legalacsonyabb), szinten rendszer programozás(elvontabb, kevésbé gyors) és egy külső eljárás- és függvénykönyvtár szintjén (kis halmaz).
Linux operációs rendszer interfészek:
szoftver (közvetítők nélkül - a rendszerhívások tényleges végrehajtása);
· parancs sor(közvetítő - a Shell interpreter shellje, amely átirányítja a hívást);
Grafikus (közvetítők - Shell + grafikus héj).
Fájlrendszer része annak az operációs rendszernek, amely a felhasználók számára készült felhasználóbarát felület fájlokkal való munkavégzés és a külső adathordozón tárolt fájlok használatának biztosítása ( HDD+ RAM) több felhasználó és folyamat által.
Az FS összetétele szerint:
a lemezen lévő összes fájl összessége az összes adathordozón,
fájlok kezelésére használt adatszerkezetek, például fájlkönyvtárak, fájlleírók, szabad és használt lemezterület-leosztási táblázatok,
rendszerszintű komplexum szoftver eszközök amelyek fájlkezelést valósítanak meg, különösen: létrehozás, megsemmisítés, olvasás, írás, elnevezés, keresés és egyéb műveletek a fájlokon.
A fájlok egyik attribútuma a fájlnevek, amelyek a fájl azonosításának módja a felhasználó számára. Azokban a rendszerekben, ahol több név is megengedett, a fájlhoz az operációs rendszer kernelje által használt inode van hozzárendelve. A nevek a különböző operációs rendszerekben eltérően vannak beállítva.
Míg az operációs rendszer felépítésének számos jellemzője közvetlenül csak a rendszerprogramozókhoz kapcsolódik, a többalkalmazásos (működési) létesítmények koncepciója közvetlenül kapcsolódik a végfelhasználók igényeihez – az operációs rendszer azon képességéhez, hogy más operációs rendszerekhez írt alkalmazásokat futtasson. Az operációs rendszernek ezt a tulajdonságát kompatibilitásnak nevezzük.
Az alkalmazások kompatibilitása lehet bináris szinten és forráskód szinten. Az alkalmazások általában futtatható fájlokként tárolódnak az operációs rendszerben, amelyek kód és adat bináris képeit tartalmazzák. A bináris kompatibilitás akkor érhető el, ha egy végrehajtható programot futtathat egy másik operációs rendszer környezetben.
A forrásszintű kompatibilitás megköveteli, hogy a megfelelő fordító szerepeljen annak a számítógépnek a szoftverében, amelyen az alkalmazást futtatni kívánjuk, valamint kompatibilitást a könyvtárak és a rendszerhívások szintjén. Ez megköveteli az alkalmazás forráskódjának újrafordítását egy új végrehajtható modulba.
A forrásszintű kompatibilitás főleg azon alkalmazásfejlesztők számára fontos, akiknek rendelkezésére állnak ezek a források. De a végfelhasználók számára csak a bináris kompatibilitásnak van gyakorlati jelentősége, mivel csak ebben az esetben használhatják ugyanazt a terméket különböző operációs rendszereken és különböző gépeken.
A lehetséges kompatibilitás típusa számos tényezőtől függ. Ezek közül a legfontosabb a processzor architektúrája. Ha a processzor ugyanazt az utasításkészletet használja (talán kiegészítéssel, mint az IBM PC esetében: standard készlet + multimédia + grafika + streaming) és ugyanazt a címtartományt, akkor a bináris kompatibilitás egészen egyszerűen elérhető. Ehhez a következő feltételeknek kell teljesülniük:
- Az alkalmazás által használt API-t az adott operációs rendszernek támogatnia kell;
- az alkalmazás végrehajtható fájljának belső szerkezetének meg kell egyeznie az operációs rendszer végrehajtható fájljainak szerkezetével.
Ha a processzorok eltérő architektúrával rendelkeznek, akkor a fenti feltételek mellett meg kell szervezni a bináris kód emulációját. Például széles körben használják az Intel processzor utasításainak emulációját a Macintosh Motorola 680x0 processzoron. A szoftver emulátor ebben az esetben szekvenciálisan választja ki az Intel processzor bináris utasítását, és végrehajtja a Motorola processzor utasításaiban leírt egyenértékű szubrutint. Mivel a Motorola processzor nem rendelkezik pontosan ugyanazokkal a regiszterekkel, zászlókkal, belső ALU-val stb., mint az Intel processzoraiban, mindezeket az elemeket is szimulálnia (emulálnia) kell saját regiszterei vagy memória segítségével.
Ez egy egyszerű, de nagyon lassú művelet, mivel egyetlen Intel utasítás sokkal gyorsabb, mint az azt emuláló Motorola utasítássorozat. A kiút ilyen esetekben az úgynevezett alkalmazásszoftver-környezetek vagy operációs környezetek használata. Egy ilyen környezet egyik összetevője az API függvénykészlet, amelyet az operációs rendszer az alkalmazásai számára tesz elérhetővé. A mások programjainak végrehajtásához szükséges idő csökkentése érdekében az alkalmazási környezetek a könyvtári funkciók hívását imitálják.
Ennek a megközelítésnek a hatékonysága annak a ténynek köszönhető, hogy a legtöbb mai program grafikus felhasználói felületen fut, mint például a Windows , a MAC vagy a UNIX Motif , míg az alkalmazások az idő 60-80%-át GUI-funkciókkal és más operációs rendszer-könyvtárhívásokkal töltik. . Az alkalmazásoknak ez a tulajdonsága teszi lehetővé, hogy az alkalmazási környezetek kompenzálják a programok parancsonkénti emulációjával töltött sok időt. A gondosan megtervezett szoftveralkalmazási környezet olyan könyvtárakat tartalmaz, amelyek utánozzák a grafikus felhasználói felület függvénytárakat, de natív kóddal vannak megírva. Így egy másik operációs rendszer API-jával jelentősen felgyorsul a programok végrehajtása. Egyébként ezt a megközelítést fordításnak nevezik, hogy megkülönböztessük a lassabb folyamattól, amikor egy-egy utasítást emulálunk.
Például egy Macintosh-on futó Windows-programhoz, amikor Intel processzorból származó parancsokat értelmez teljesítmény nagyon alacsony lehet. De ha egy grafikus felhasználói felület függvényt hívunk meg, egy ablakot stb., akkor a Windows alkalmazási környezetet megvalósító operációs rendszer modul elkaphatja ezt a hívást, és átirányíthatja a Motorola 680x0 processzorra újrafordított ablaknyitó rutinhoz. Ennek eredményeként a kód ilyen szakaszaiban a program sebessége elérheti (és esetleg meg is haladhatja) a saját processzorán végzett munka sebességét.
Ahhoz, hogy az egyik operációs rendszerre írt program egy másik operációs rendszeren fusson, nem elég csak az API-kompatibilitás biztosítása. A különböző operációs rendszerek alapjául szolgáló fogalmak ütközhetnek egymással. Például az egyik operációs rendszerben egy alkalmazás engedélyezheti az I / O eszközök vezérlését, egy másikban ezek a műveletek az operációs rendszer előjoga.
Minden operációs rendszernek megvannak a saját erőforrás-védelmi mechanizmusai, saját hiba- és kivételkezelő algoritmusai, saját processzorstruktúrája és memóriakezelési sémája, saját fájlelérési szemantikája és saját grafikus felhasználói felülete. A kompatibilitás biztosítása érdekében meg kell szervezni a konfliktusmentes együttélést ugyanazon az operációs rendszeren belül a számítógépes erőforrások kezelésének többféle módja között.
Különféle lehetőségek állnak rendelkezésre több alkalmazási környezet létrehozására, amelyek mind az építészeti megoldások jellemzőiben, mind az alkalmazások hordozhatóságát biztosító funkcionalitásban különböznek egymástól. A több alkalmazási környezet megvalósításának egyik legkézenfekvőbb lehetősége az operációs rendszer szabványos réteges szerkezetén alapul.
A több alkalmazási környezet létrehozásának másik módja a mikrokernel megközelítésen alapul. Ugyanakkor nagyon fontos megjegyezni az alapvető, minden alkalmazási környezetre jellemző különbséget az operációs rendszer mechanizmusai és az egyes alkalmazási környezetekre jellemző, stratégiai problémákat megoldó magas szintű funkciók között. Vminek megfelelően mikronukleáris architektúra az operációs rendszer összes funkcióját a mikrokernel és a felhasználói módú szerverek valósítják meg. Fontos, hogy az alkalmazáskörnyezet külön felhasználói módú kiszolgálóként legyen kialakítva, és ne tartalmazza a mögöttes mechanizmusokat.
Az API-t használó alkalmazások rendszerhívásokat indítanak a megfelelő alkalmazási környezetbe a mikrokernelen keresztül. Az alkalmazási környezet feldolgozza a kérést, végrehajtja azt (esetleg a mikrokernel alapfunkcióitól kérve ehhez), és az eredményt visszaküldi az alkalmazásnak. A kérés végrehajtása során az alkalmazási környezetnek hozzá kell férnie a mikrokernel és más operációs rendszer szerverek által megvalósított mögöttes operációs rendszerekhez.
A többalkalmazásos környezet tervezésének ez a megközelítése a mikro-kernel architektúra összes előnyével és hátrányával rendelkezik, különösen:
- alkalmazási környezetek hozzáadása és kizárása nagyon egyszerű, ami a mikro-kernel operációs rendszerek jó bővíthetőségének a következménye;
- ha az egyik alkalmazási környezet meghibásodik, a többi működőképes marad, ami hozzájárul a rendszer egészének megbízhatóságához és stabilitásához;
- a mikrokernel operációs rendszerek alacsony teljesítménye befolyásolja az alkalmazási eszközök sebességét, és ezáltal az alkalmazások sebességét.
Ennek eredményeként meg kell jegyezni, hogy egy operációs rendszeren belül több alkalmazási eszköz létrehozása a különböző operációs rendszerek alkalmazásainak végrehajtására lehetővé teszi a program egyetlen verziójának létrehozását, és annak átvitelét a különböző operációs rendszerek között. Több alkalmazási környezet biztosítja egy adott operációs rendszer bináris kompatibilitását más operációs rendszerekre írt alkalmazásokkal.
1.9. A virtuális gépek, mint modern megközelítés több alkalmazási környezet megvalósításához
A "virtuális gép-monitor" (VMM) koncepciója a 60-as évek végén jelent meg szoftverként absztrakciós szint, amely a hardverplatformot több virtuális gépre osztotta. Ezen virtuális gépek (VM-ek) mindegyike annyira hasonlított az alapul szolgáló fizikai géphez, hogy a meglévő szoftver változatlanul elvégezhető rajta. Abban az időben számítási problémák Tábornok drága nagyszámítógépeken oldották meg (mint például az IBM/360), és a felhasználók dicsérték a VMM azon képességét, hogy a szűkös erőforrásokat több alkalmazás között is el tudja osztani.
Az 1980-as és 1990-es években a költségek jelentősen csökkentek. számítógép tartozékés hatékony multitasking operációs rendszer, ami csökkentette a VMM értékét a felhasználók szemében. A nagyszámítógépek átadták helyét a miniszámítógépeknek, majd a PC-knek, és megszűnt a VMM iránti igény. Ennek eredményeként a számítógép-architektúra egyszerűen eltűnt hardver hatékony végrehajtásuk érdekében. A 80-as évek végére a tudományban és a VMM-ek gyártásában már csak történelmi érdekességként fogták fel őket.
Ma az MVM ismét a reflektorfénybe került. Az Intel, az AMD, a Sun Microsystems és az IBM virtualizációs stratégiákat hoz létre, a laboratóriumok és az egyetemek pedig virtuális gép alapú megközelítéseket fejlesztenek a mobilitási, biztonsági és felügyelhetőségi problémák megoldására. Mi történt az MVM lemondása és újjáéledése között?
Az 1990-es években a Stanford Egyetem kutatói elkezdték vizsgálni a virtuális gépek alkalmazásának lehetőségét a hardver és az operációs rendszerek korlátainak leküzdésére. Problémák merültek fel a masszívan párhuzamos feldolgozású (Massively Parallel Processing, MPP) számítógépekkel, amelyeket nehéz volt programozni, és nem tudták futtatni a meglévő operációs rendszereket. A kutatók azt találták, hogy a virtuális gépek ezt a nehézkes architektúrát eléggé hasonlóvá tehetik a meglévő platformokhoz ahhoz, hogy kihasználják a kész operációs rendszerek előnyeit. Ebből a projektből származtak azok az emberek és ötletek, amelyek a VMware (www.vmware.com) aranybányájává váltak, amely a VMM-ek első szállítója a mainstream számítógépekhez.
Furcsa módon a modern operációs rendszerek fejlődése és a csökkenő hardverköltségek olyan problémákhoz vezettek, amelyeket a kutatók a VMM-ekkel reméltek megoldani. A berendezések olcsósága hozzájárult a számítógépek gyors elterjedéséhez, de gyakran alulhasználták őket, ami további helyet és erőfeszítést igényelt a karbantartásuk. És az operációs rendszer funkcionalitásának növekedésének következményei az instabilitásuk és sebezhetőségükké váltak.
A rendszerösszeomlások hatásának csökkentése és a feltörések elleni védelem érdekében rendszergazdák visszafordult az egyfeladatos munkához számítási modell(egy alkalmazással egy gépen). Ez többletköltségeket eredményezett a megnövekedett hardverigények miatt. Az alkalmazások különböző fizikai gépekről virtuális gépekre való áthelyezése és ezeknek a virtuális gépeknek néhány fizikai platformon való egyesítése javította a hardver kihasználtságát, csökkentette a felügyeleti költségeket és csökkentette az alapterületet. Így a VMM azon képessége, hogy multiplex hardvert – ezúttal a szerverkonszolidáció és a segédprogramok számítása nevében – újra életre keltette őket.
A VMM mára már nem annyira a multitasking megszervezésének eszközévé vált, mint ahogy korábban kigondolták, hanem a biztonság, a mobilitás és a megbízhatóság biztosításának problémáira. A VMM sok szempontból lehetőséget ad az operációs rendszer fejlesztőinek olyan funkciók fejlesztésére, amelyek a mai összetett operációs rendszerekkel nem lehetségesek. Az olyan funkciókat, mint az áttelepítés és a védelem, sokkal kényelmesebb megvalósítani VMM-szinten, amely fenntartja a visszafelé kompatibilitást innovatív operációs rendszer-megoldások telepítésekor, miközben megtartja a korábbi eredményeket.
A virtualizáció egy fejlődő technológia. Általánosságban elmondható, hogy a virtualizáció lehetővé teszi a szoftver és az alapul szolgáló hardver-infrastruktúra elkülönítését. Valójában megszakítja a kapcsolatot egy bizonyos programkészlet és egy adott számítógép között. A Virtual Machine Monitor elválik szoftver a hardvertől és egy köztes szintet képez a futó szoftverek között virtuális gépekés hardver. Ez a szint lehetővé teszi a VMM számára, hogy teljes mértékben szabályozza a hardver erőforrások használatát. vendég operációs rendszerek (GuestOS) amelyek a virtuális gépen futnak.
A VMM egységes nézetet hoz létre a mögöttes hardverről, így a különböző gyártóktól származó, különböző I/O alrendszerekkel rendelkező fizikai gépek ugyanúgy néznek ki, és a virtuális gép bármely elérhető hardveren fut. Azáltal, hogy nem törődnek az egyes gépekkel a szoros hardver-szoftver kapcsolatokkal, az adminisztrátorok egyszerűen úgy tekinthetik a hardvert, mint egy erőforráskészletet, hogy bármilyen igény szerinti szolgáltatást nyújthassanak.
Köszönet teljes tokozás A virtuális gép szoftverállapotaiban a VMM-figyelő le tudja rendelni a virtuális gépet bármely rendelkezésre álló hardvererőforráshoz, és akár át is helyezheti egyik fizikai gépről a másikra. A gépcsoportok terheléselosztásának feladata triviálissá válik, és vannak megbízható módszerek a hardverhibák kezelésére és a rendszer bővítésére. Ha le kell állítania egy meghibásodott számítógépet, vagy újat kell online hoznia, a VMM ennek megfelelően újra tudja osztani a virtuális gépeket. A virtuális gép könnyen replikálható, így a rendszergazdák szükség szerint gyorsan új szolgáltatásokat nyújthatnak.
A beágyazás azt is jelenti, hogy a rendszergazda bármikor szüneteltetheti vagy folytathatja a virtuális gépet, valamint mentheti a virtuális gép aktuális állapotát, vagy visszaállíthatja az előző állapotba. Az univerzális visszavonási képességgel az összeomlások és a konfigurációs hibák könnyen kezelhetők. A beágyazás az általános mobilitási modell alapja, mivel a felfüggesztett virtuális gépek a hálózaton keresztül másolhatók, tárolhatók és cserélhető adathordozón szállíthatók.
A VMM közvetítő szerepet játszik a virtuális gép és a mögöttes hardver közötti összes interakcióban, támogatja számos virtuális gép egyetlen hardverplatformon történő végrehajtását, és biztosítja azok megbízható elkülönítését. A VMM lehetővé teszi alacsony erőforrásigényű virtuális gépek csoportjának összeállítását egyetlen számítógépen, csökkentve ezzel a költségeket hardverés a termelési terület igénye.
A teljes szigetelés a megbízhatóság és a biztonság szempontjából is fontos. Azok az alkalmazások, amelyek korábban egyetlen gépen futottak, mostantól eloszthatók különböző virtuális gépeken. Ha valamelyik hiba következtében az operációs rendszer összeomlását okozza, a többi alkalmazás le lesz izolálva tőle, és tovább működnek. Ha az egyik alkalmazást külső támadás fenyegeti, a támadás a „kompromittált” virtuális gépen belül lesz lokalizálva. Így a VMM egy eszköz a rendszer átstrukturálására a stabilitás és a biztonság javítása érdekében anélkül, hogy további hely- és adminisztrációs erőfeszítéseket igényelne, amelyekre az alkalmazások különálló fizikai gépeken történő futtatásakor van szükség.
A VMM-nek hozzá kell rendelnie egy hardveres interfészt a virtuális géphez, miközben megőrzi a teljes ellenőrzést alapgépés a hardverével való interakciós eljárások. E cél elérése érdekében különböző módszerek léteznek, amelyek bizonyos technikai kompromisszumokon alapulnak. Az ilyen kompromisszumok keresése során figyelembe veszik a VMM főbb követelményeit: kompatibilitás, teljesítményés az egyszerűség. A kompatibilitás azért fontos, mert a VMM fő előnye a régi alkalmazások futtatásának képessége. Teljesítmény határozza meg a virtualizációs többletköltséget – a virtuális gépen lévő programokat ugyanolyan sebességgel kell végrehajtani, mint a valódi gépen. Az egyszerűségre azért van szükség, mert a VMM meghibásodása a számítógépen futó összes virtuális gép meghibásodását eredményezi. A megbízható elkülönítés különösen azt követeli meg, hogy a VMM mentes legyen azoktól a hibáktól, amelyeket a támadók a rendszer megsemmisítésére használhatnak.
A vendég operációs rendszer bonyolult kód-újraírása helyett néhány változtatást hajthat végre a gazdagép operációs rendszeren a kernel leginkább "zavaró" részének megváltoztatásával. Ezt a megközelítést paravirtualizációnak nevezik. Nyilvánvaló, hogy ebben az esetben csak a szerző adaptálhatja az operációs rendszer kernelt, és például a Microsoft nem mutat semmilyen vágyat arra, hogy a népszerű Windows 2000 kernelt az adott virtuális gépek valóságához igazítsa.
A paravirtualizáció során a VMM fejlesztője újradefiniálja a virtuális gép interfészét, és az eredeti utasításkészlet egy részét, amely alkalmatlan a virtualizációra, kényelmesebb és hatékonyabb megfelelőkkel helyettesíti. Vegye figyelembe, hogy bár az operációs rendszert át kell vinni az ilyen virtuális gépeken való futtatáshoz, a legtöbb általános alkalmazás változatlanul futhat.
A paravirtualizáció legnagyobb hátránya az inkompatibilitás. Bármi operációs rendszer, amelyet egy paravirtualizált VMM-monitor vezérlése alatt való futtatásra terveztek, erre az architektúrára kell portolni, amelyhez együttműködési megállapodást kell kötni az operációs rendszer szállítóival. Ezenkívül a régi operációs rendszereket nem lehet használni, és a meglévő gépeket nem lehet egyszerűen virtuálisra cserélni.
Az x86-os virtualizáció nagy teljesítményének és kompatibilitásának elérése érdekében a VMware kifejlesztette új módszer virtualizáció, amely egyesíti a hagyományos közvetlen végrehajtást a gyors bináris fordítással menet közben. A legtöbb modern operációs rendszerben a processzorok működési módjai a hétköznapi alkalmazási programok végrehajtása során könnyen virtualizálhatók, így azok közvetlen végrehajtással is virtualizálhatók. A virtualizációra alkalmatlan privilegizált módokat bináris kódfordító hajthatja végre, kijavítva a "kényelmetlen" x86 parancsokat. Az eredmény egy nagy teljesítmény Virtuális gép, amely teljes mértékben kompatibilis a berendezéssel és a támasztékokkal teljes kompatibilitásÁLTAL .
A konvertált kód nagyon hasonlít a paravirtualizáció eredményeihez. A közönséges parancsok változatlanul hajtódnak végre, a parancsok pedig, amelyekre szükség van különleges bánásmód(mint például a POPF és a kódszegmensregiszter-utasítások olvasása), a fordító lecseréli azokat az utasítássorozatokat, amelyek hasonlóak a paravirtualizált gépen végrehajtandó utasításokhoz. Virtuális gép. Van azonban egy fontos különbség: ahelyett, hogy változtatnánk forrás operációs rendszer vagy alkalmazások esetén a bináris fordító megváltoztatja a kódot az első végrehajtáskor.
Bár a bináris kód lefordítása többletköltséggel jár, ezek normál munkaterhelés mellett elhanyagolhatóak. A fordító a kódnak csak egy részét dolgozza fel, és a programvégrehajtás sebessége a közvetlen végrehajtás sebességéhez lesz hasonlítható - amint a gyorsítótár megtelik.
Kompatibilitás és több alkalmazási környezet
A többalkalmazási környezet koncepciója a végfelhasználók igényeihez kapcsolódik – az operációs rendszer azon képességéhez, hogy más operációs rendszerek alkalmazásait futtathassa. Az operációs rendszer ezen tulajdonságát ún kompatibilitás.
Bináris és forráskompatibilitás
Tegyen különbséget a bináris szintű kompatibilitás és a forráskód szintű kompatibilitás között. Az alkalmazások általában futtatható fájlokként tárolódnak az operációs rendszerben, amelyek kód és adat bináris képeit tartalmazzák. A bináris kompatibilitás akkor érhető el, ha egy végrehajtható programot futtathat egy másik operációs rendszeren.
A forrásszintű kompatibilitás megköveteli, hogy a megfelelő fordító szerepeljen annak a számítógépnek a szoftverében, amelyen az alkalmazást futni kívánják, valamint kompatibilitást a könyvtárak és a rendszerhívások szintjén. Ehhez le kell fordítani a rendelkezésre álló forráskódot egy végrehajtható modulba.
A forrásszintű kompatibilitás főleg azon alkalmazásfejlesztők számára fontos, akiknek rendelkezésére állnak ezek a források. A végfelhasználók számára csak a bináris kompatibilitásnak van gyakorlati jelentősége, mivel csak ebben az esetben használhatják ugyanazt a kereskedelmi terméket bináris formában. futtatható kód különféle működési környezetekben.
Az, hogy az operációs rendszerek binárisan vagy forráskompatibilisek-e, számos tényezőtől függ. Ezek közül a legfontosabb annak a processzornak az architektúrája, amelyen az új operációs rendszer fut. Ha a processzor ugyanazt az utasításkészletet használja (talán néhány kiegészítéssel) és ugyanazt a címtartományt, akkor a bináris kompatibilitás meglehetősen könnyen elérhető. Ehhez elegendő a következő feltételek betartása:
Az alkalmazás által tartalmazott API-funkciók hívásait az operációs rendszernek támogatnia kell;
Az alkalmazás végrehajtható fájljának belső szerkezetének meg kell egyeznie az operációs rendszer végrehajtható fájljainak szerkezetével.
Nehezebb elérni a bináris kompatibilitást a különböző architektúrájú processzorokon való futtatásra tervezett operációs rendszereknél. A fenti feltételek betartása mellett meg kell szervezni a bináris kód emulációját, ami meglehetősen lassú programvégrehajtáshoz vezet.
Egy másik operációs rendszer környezetével teljes mértékben kompatibilis alkalmazáskörnyezet létrehozása az operációs rendszer felépítéséhez szorosan kapcsolódó feladat. Különféle lehetőségek állnak rendelkezésre több alkalmazási környezet létrehozására, amelyek mind az építészeti megoldások jellemzőiben, mind az alkalmazások hordozhatóságát biztosító funkcionalitásban különböznek egymástól.
A több alkalmazási környezet megvalósításának egyik legkézenfekvőbb lehetősége a szabványos réteges operációs rendszer struktúrán alapul, és rendszerhívás-fordítást biztosít.
A 6. ábrán az OS1 operációs rendszer az alkalmazásain kívül támogatja az OS2 és OS3 operációs rendszerek alkalmazásait is.
Ehhez speciális alkalmazásokat - alkalmazásszoftver-környezeteket - tartalmaz, amelyek "idegen" operációs rendszerek API OS2 és API OS3 interfészeit fordítják le operációs rendszerük - API OS1 - interfészére.
6. ábra – Alkalmazási környezetek, amelyek lefordítják a rendszerhívásokat
A többalkalmazásos környezet egy másik megvalósításában az operációs rendszer több társalkalmazás-programozási felülettel rendelkezik (7. ábra). A bemutatott példában az operációs rendszer támogatja az OS1, OS2 és OS3 alkalmazásokat.
Ennek érdekében az összes operációs rendszer alkalmazásprogramozási felületei közvetlenül a rendszer kernelterébe kerülnek: API OS1, API OS2 és API OS3.
7. ábra - Kompatibilitás megvalósítása több peer API-n alapul
Ebben a változatban az API-szintű függvények az alapul szolgáló OS-szint függvényeit hívják meg, amelyeknek támogatniuk kell mindhárom, általában nem kompatibilis alkalmazáskörnyezetet. Az egyes API-k funkcióit a kernel valósítja meg, figyelembe véve a megfelelő operációs rendszer sajátosságait, még akkor is, ha hasonló céljuk van. Ahhoz, hogy a kernel kiválaszthassa a rendszerhívás kívánt megvalósítását, minden folyamatnak át kell adnia egy sor azonosító jellemzőt a kernelnek.
A több alkalmazási környezet létrehozásának másik módja a mikrokernel megközelítésen alapul. A mikrokernel architektúrának megfelelően az operációs rendszer összes funkcióját a mikrokernel és a felhasználói módú szerverek valósítják meg. Minden alkalmazáskörnyezet külön felhasználói módú szervernek készült, és nem tartalmaz alapvető mechanizmusokat (8. ábra). Az alkalmazások a mikrokernelen keresztül rendszerhívásokat indítanak a megfelelő alkalmazási környezetbe. Az alkalmazáskörnyezet feldolgozza a kérést, végrehajtja azt, és az eredményt visszaküldi az alkalmazásnak. A kérés végrehajtása során az alkalmazási környezetnek hozzá kell férnie a mikrokernel és más operációs rendszer szerverek által megvalósított mögöttes operációs rendszerekhez.
A többalkalmazásos környezet tervezésének ez a megközelítése rendelkezik a mikrokernel architektúra összes előnyével és hátrányával, különösen:
Alkalmazási környezetek hozzáadása és eltávolítása nagyon egyszerű, ami a mikrokernel operációs rendszerek jó bővíthetőségének a következménye;
A megbízhatóság és a stabilitás abban nyilvánul meg, hogy ha az egyik alkalmazási környezet meghibásodik, az összes többi működőképes marad;
A mikrokernel operációs rendszerek alacsony teljesítménye befolyásolja az alkalmazási környezetek sebességét, és ezáltal az alkalmazások végrehajtásának sebességét.
8. ábra - Mikrokernel megközelítés több alkalmazási környezet megvalósításához
Egy operációs rendszeren belül több alkalmazáskörnyezet létrehozása a különböző operációs rendszerek alkalmazásainak futtatásához lehetővé teszi a program egyetlen verziójának létrehozását és az operációs rendszerek közötti átvitelét.