Ugrás a tartalomhoz

Operációs rendszerek mérnöki megközelítésben

Benyó Balázs, Fék Márk, Kiss István, Kóczy Annamária, Kondorosi Károly, Mészáros Tamás, Román Gyula, Szeberényi Imre, Sziray József

Panem Kiadó

6.2. A Windows NT felépítése

6.2. A Windows NT felépítése

A Windows NT felépítését a 6.3. ábrán mutatjuk be. A téglalapok az egyes komponenseket szemléltetik, a köztük lévő kapcsolatot a nyilak mutatják. Jól láthatók az egymásra épülő rétegek, illetve az őket összekötő interfészek.

6.3. ábra. ábra - A Windows NT felépítése

A Windows NT felépítése


A következő részekben részletesen bemutatjuk az NT komponenseit, ismertetve azok funkcióit.

6.2.1. HAL

A HAL (Hardware Abstraction Layer) az aktuálisan használt hardvert teljesen elfedő, legalacsonyabb szoftverréteg. Az operációs rendszer HAL fölötti rétegei (vagyis a device driverek, illetve a kernel) csak ezen keresztül érheti el a hardvert. Minden processzorhoz, amelyen az NT-t implementálták, készül külön HAL-réteg, vagyis a HAL a használt processzor típusától függ. Egy adott rendszerben az aktuálisan használt HAL-réteget a rendszer telepítésekor választja ki.

A HAL igyekszik az általa rejtett processzortól független szolgáltatásokat nyújtani a többi réteg számára. Azonos architektúrájú processzorok esetén ez teljesül is, vagyis például az x86 típusú processzorokon futó NT-rendszerek között csak a HAL-ban van különbség. Úgy is tekinthetjük, hogy a HAL az aktuális hardverre támaszkodva egy virtuális gépet valósít meg, amelynek funkcionalitása minden rendszerben azonos.

6.2.2. Kernel

A kernel a rendszer állandóan memóriában levő kernel (védett) módban futó része. A kernel a HAL-on kívül az egyetlen hardverfüggő része az NT-nek. Azonban míg a HAL a processzor típusától függ, addig a kernel csak a processzor architektúrájától. Ez azt jelenti, hogy azonos felépítésű processzorok esetén a kernel is azonos, csak eltérő felépítésű processzorok esetén lehet különbség. Például két x86-os processzoralapú rendszerben a kernelréteg is azonos attól függetlenül, hogy konkrétan milyen processzort használunk. Egy RISC-alapú rendszerben azonban a kernelréteg is különbözni fog. Az adott konfigurációban használt HAL-t az NT installálásakor választja ki. Az installáló CD-n így számos HAL-t találhatunk. Érdemes megnézni az NT CD \i386-os alkönyvtárát.

Fontos látni, hogy a kernel és a rá épülő további komponensek csatlakozási felülete már hardverfüggetlen. Ebből következik, hogy a rendszer további komponensei is hardverfüggetlenek, vagyis hordozhatók.

Az NT hordozhatósága tehát úgy valósul meg, hogy a hardvert minden processzoron hasonló interfésszel elérhető szoftverrétegek fedik el. Ez a két hardverréteg a HAL és a kernel. A kernelben kerültek megvalósításra a processzorok architektúrájától függő funkciók (például szálak környezetváltása), míg a HAL az azonos architektúrájú processzorok adott típusától függő funkcióit tartalmazza.

A hordozhatóságról szólva meg kell említeni a hordozhatóság másik eszközét, nevezetesen azt, hogy az NT – a UNIX-rendszerekhez hasonlóan – hordozható programnyelven íródott. A kód túlnyomó része C-ben készült. A grafikus alrendszernek és a felhasználói interfésznek egy kisebb részét C++-ban fejlesztették. Assembly nyelven csak a hardver közvetlen kezelését végző (például IT-kezelés), vagy a rendszer teljesítményét nagymértékben befolyásoló (például környezetváltás) részek íródtak.

A kernel feladata, a rendszer további részeinek a hardvertől történő teljes elhatárolásán túl, hogy az operációs rendszer többi komponense számára egyszerű, jól definiált működésű alapmodulokat (ún. primitíveket) biztosítson.

A primitívek a következő funkciókat valósítják meg:

  • thread (szál) ütemezés,

  • trap-kezelés és kivételkezelés,

  • IT-kezelés,

  • multiprocesszor-ütemezés,

  • kernel objektumok kezelése.

A kernel objektumok egyszerűbbek, mint a többi réteg objektumai, mert a gyors kezelés érdekében a kernel nem végez ellenőrzést az egyes objektumok elérésekor, megbízik abban, hogy a rendszer tagjai helyesen használják az objektumokat.

6.2.3. Készülékkezelők (device driverek)

A device driverek a B/K-alrendszer és a hardver között teremtenek kapcsolatot. Mint már említettük, nem közvetlenül érik el a hardvert, hanem a HAL- ré­tegen keresztül. Ez például lehetővé teszi, hogy a device driverek forráskódban hordozhatók különböző hardverarchitektúrák között, és akár binárisan is hordozhatók azonos architektúrájú, de különböző típusú processzorok esetén.

A device driverek négy típusát különböztetjük meg:

  • Hardver driverek, melyek a hardver egységek elérését biztosítják, az eszközök közvetlen be- és kimeneteit kezelik.

  • Fájlrendszer driverek, melyek a fájlrendszerek elérését biztosító kéréseket fogadnak el és B/K-kérésekké transzformálják azokat.

  • Szűrő típusú device driverek, melyek az ún. réteg szerkezetű device driver struktúra lehetőségeit kihasználva speciális többletfunkciókat valósítanak meg. A szűrő típusú device driverek általában a magas szintű (például fájlrendszer driverek) és a B/K-kéréseket kezelő alacsony szintű driverek közé ékelődnek.

  • Hálózat elérését biztosító device driverek, melyek a hálózati kéréseket szolgálják ki, illetve továbbítják azokat.

Az NT ún. rétegszerkezetű device driver struktúrát használ, ami lehetővé teszi a funkciók szétválasztását, illetve rugalmas driverszerkezet kialakítását. A réteg szerkezetű struktúrának köszönhetően lehetőség van a hagyományosakon túl olyan driverek használatára is, amelyek lehetőséget adnak többletfunkciók megvalósítására, mint például a redundáns adattárolás me­rev­lemezek tükrözésével vagy több lemezen tárolt fájlrendszer kezelése. Ezekről a lehetőségekről a későbbiekben részletesen is lesz szó.

6.2.4. Executive

Az executive réteg az operációs rendszerek magas szintű szolgáltatásait nyújtó alrendszereket megvalósító rétege az NT-nek. Önálló részei a következők:

  • folyamat- és szálkezelő,

  • virtuálismemória-kezelő,

  • biztonsági alrendszer (monitor),

  • cache kezelő,

  • B/K-rendszer kezelő.

Az executive réteg tartalmazza az NTDLL.DLL által definiált függvények hívásainak megvalósítását, valamint biztosítja az operációs rendszer belső objektumai közötti kommunikáció lehetőségét.

Az executive réteg legfontosabb szolgáltató funkciója az LPC (Local Procedure Call, lokális eljáráshívás) szolgáltatás megvalósítása. Az LPC az NT IPC (Inter Process Communication, folyamatok közötti kommunikáció) eszköze. Ennek segítségével egy felhasználói objektum egy másik felhasználói objektum függvényét hívhatja meg. Így érhetik el például az egyes alkalmazások a hozzájuk tartozó alrendszer szolgáltatásait. Ezen felül az executive réteg tartalmaz run-time library függvényeket és különböző támogató funkciókat megvalósító függvényeket a rendszerfolyamatok és szolgáltatások számára.

6.2.5. Rendszerfolyamatok

Rendszerfolyamatok közé az operációs rendszer azon funkcióit megvalósító önálló folyamatok tartoznak, amelyek független felhasználói folyamatként kerültek megvalósításra. Fontos kiemelni, hogy bár user módban futó folyamatokról van szó, a rendszerfolyamatok alapvető részei az operációs rendszernek, futásuk nélkül az NT nem képes működni.

Fontos rendszerfolyamatok:

  • SMSS (Session Manager). A rendszer indításakor létrehozott folyamat, ami az alkalmazások elindításáért felelős. Az SMSS indítja el az egyes alrendszereket, ha futásukra szükség van, és még nem futnak; biztosítja a kapcsolatot a debugger és az általa futtatott applikáció között; valamint biztosítja a környezeti változók definiálásának és elérésének lehetőségét.

  • Logon. A felhasználók ki- és beléptetését intéző folyamat. Minden ún. SAS (Secure Attention Sequence) billentyűkombináció (alapesetben: CTRL-ALT-DEL) aktivizálja. Beléptetéskor a felhasználói azonosító (user­name) és jelszó (password) kombinációt az önálló folyamatként futó Local Security Authentication Serverhez (LSASS) továbbítva ellenőrzi. Ha az azonosítás sikeres, elindítja a USERINIT.EXE programot, ami beállítja a felhasználó által definiált környezetet, és elindítja az általa kért shellt (alapesetben: EXPLORER.EXE).

  • Service Controller. A szolgáltatások indításáért és leállításáért felelős folyamat.

6.2.6. Szolgáltatások

Az NT-ben szolgáltatásnak hívják azokat a kliens-szerver modellben szerverként működő szolgáltató folyamatokat, amelyek a kliens programok (felhasználói vagy akár rendszer programok) számára az operációs rendszer lehetőségeire építve többletszolgáltatásokat nyújtanak. Létezik például RPC (Re­mote Procedure Call) szolgáltató, különböző protokollokat megvalósító hálózati kapcsolatot biztosító szolgáltatók, vagy az NT-specifikus eseménynaplózó (event logger) szolgáltató. (Megjegyzendő, hogy egy-egy szolgáltatást gyakran nem egyetlen folyamat valósít meg.)

A szolgáltatások a rendszerfolyamatokhoz hasonlóan felhasználói módban futó folyamatok. Lényeges különbség azonban, hogy míg a rendszerfolyamatok szükséges részei a rendszernek, addig a szolgáltatásokat megvalósító folyamatok futása nélkül is képes működni az NT. A szolgáltatások a Service Manager segítségével elindíthatók és leállíthatók a rendszer működése közben.

A szolgáltatásokat megvalósító programok egyszerű Win32-es alkalmazások, azzal a különbséggel, hogy együttműködnek a Service Conroller (SER­VICES.EXE) folyamattal. Az regisztrálja őket, és annak segítségével lehet őket elindítani, leállítani, szüneteltetni stb. A rendszerben elérhető szolgáltatásokat és azok aktuális státusát a felhasználói felületről is megnézhetjük és változtathatjuk a Control Panelen a Services ikonra kattintva. (Egy szolgáltatásnak így három elnevezése is lehetséges: az első az a név, ahogy a szolgáltatás a Control Panel/Services alpontján keresztül elérhető, a másik az a név, amin az a Registry-ben szerepel, a harmadik pedig az a név, amely a szolgáltatást megvalósító futtatható program neve.)

6.2.7. NTDLL.DLL

Az NTDLL.DLL az a dinamikusan kapcsolódó könyvtár (Dinamically Linked Library – DLL), amin keresztül a felhasználói módú folyamatok elérhetik az NT-t. Mivel az egyes objektumok közötti kapcsolattartás az LPC mechanizmuson keresztül történik, így minden felhasználói objektum az NTDLL.DLL-en keresztül éri el a környezetét.

Az NTDLL által megvalósított működés egyszerű. Ha egy hívás érkezik, ellenőrzi a hívás paramétereit, és megvalósítja a user–kernel módváltást, majd meghívja az NT kért funkciót megvalósító függvényét.

6.2.8. Alrendszerek

Mint már említettük, az NT alkalmas különböző típusú applikációk futtatására. Ezt az alrendszerek segítségével valósítja meg. Három alrendszere van: Win32, POSIX, és az OS/2. A Win32 alrendszer kitüntetett abban a tekintetben, hogy a Win32 alrendszer nélkül az NT nem tud futni. A másik két alrendszer opcionális, csak abban az esetben kezdenek futni, amikor az adott alrendszerhez tartozó alkalmazást akar egy felhasználó elindítani.

Az alrendszerek elsődleges feladata, hogy a hozzájuk tartozó alkalmazások futásához szükséges szolgáltatásokat nyújtsák. Minden alrendszer a hozzá tartozó alkalmazásokat kontrollálja.

Minden alrendszerhez tartozik egy ún. alrendszer DLL, amin keresztül az alrendszerhez tartozó alkalmazás az NT szolgáltatásait elérheti. Ez tehát a programozói interfész (API: Application Programming Interface), ami az egyes alrendszerekhez tartozó applikációk számára elérhető. Ezt azért fontos kiemelni, mert ez az a publikált, jól definiált felület, amit minden program használhat. Az összes többi interfész (például NTDLL.DLL) nem publikus interfész.

Az egyes alrendszerekhez tartozó API-k lényegesen különböznek egymástól. A legszélesebb lehetőségeket a Win32 API biztosítja (például ablakozás, szálak kezelése stb.). Fontos tudni, hogy egy applikáció csak egy alrendszerhez tartozhat, nem keveredhetnek egymással egy applikáción belül különböző alrendszerhez tartozó hívások.

6.2.8.1. POSIX alrendszer

A POSIX alrendszer szigorúan a POSIX 1003.1-es szabványban rögzített tulajdonságokat valósítja meg. Így van lehetőség új folyamatok létrehozására (fork), fájlok több néven történő elérésére (hard linkek definiálására), folyamatok közötti kommunikációra (IPC), folyamatok kezelésére, valamint karakteres B/K kezelésére. Ezzel szemben nincs lehetőség szálak (thread) létrehozására, ablakkezelésre, távoli eljáráshívásra (RPC elérésére), socketek használatára. (A UNIX-alkalmazások hordozása érdekében készítettek már a szabványos POSIX-alrendszernél szélesebb lehetőségeket megvalósító POSIX-alrendszereket, illetve POSIX API-t, valamint vannak olyan programkönyvtárak, amelyek lehetővé teszik, hogy egy POSIX- (UNIX-) alkalmazást Win32-es futtatható állománnyá fordítsunk.)

6.2.8.2. Win32 alrendszer

A Win32 alrendszer futtatja nemcsak a 32 bites alkalmazásokat (vagyis azokat, amelyek Win32 API-t használnak), hanem a 16 bites és DOS-alkalmazásokat is.

A Win32 alrendszer nem csak abban különbözik a többitől, hogy nélküle nem futhat az NT, hanem abban is, hogy az alrendszer egy része kernel mód­ban fut. (WIN32K.SYS) Ez a rész valósítja meg a grafikus képernyő-kezelési funkciókat. (A USER32.DLL, GDI.DLL, KERNEL32.DLL, ADVAPI.DLL könyvtárakban definiált funkciókat.) Ez a rendszer hatékonysága miatt került ide, mert így módváltás nélkül lehetséges az executive, illetve kernel szolgáltatások (függvények) elérése.

A Win32 API-hívások háromfélék lehetnek a megvalósításuk helye szerint:

  • Az alrendszer DLL-ben van megvalósítva. Ezek egyszerű funkcionalitású függvények, a végrehajtásukhoz nincs szükség a rendszer más részeinek elérésére.

Az alrendszerben vannak megvalósítva. A hívást ebben az esetben az alrendszer DLL továbbítja az NTDLL.DLL felé, ami az executive réteg LPC szolgáltatását igénybe véve, eljut a Win32 alrendszerhez, ami a kérést teljesíti.

Az NT más, kernel módban futó rétege valósítja meg a hívást. A hívás ebben az esetben is az executive réteghez kerül, ami továbbítja a megfelelő kernel réteg felé.

A WIN32 API-ban számos grafikus funkció van definiálva. A grafikus eszközök és a nyomtató szabványos felületen történő kezelését a GDI (Graphical Device Interface), illetve a hozzá tartozó GDI32.DLL (WIN32 API része) teszi lehetővé. Az ebben definiált funkciók a WIN32 alrendszer kernel módú részében (WIN32K.SYS) vannak megvalósítva. Ezek a rutinok intézik az eszközökhöz tartozó device driverek meghívását. Egy-egy GDI32.DLL-ben definiált grafikus funkcióhoz az adott eszköztől függően akár több device driver is tartozhat.