A Windows 98 felépítése A Windows 98 fő jellegzetességeit a Windows 95 rendszertől örökölte. Ha megvizsgáljuk a rendszer felépítését (1. ábra), akkor azt találjuk, hogy a hardverhez legközelebbi szoftverösszetevők az eszközillesztő programok, amelyek megteremtik a kapcsolatot a szoftver- és a hardverelemek között. Kezelőfelületi eszközök
Alkalmazások 32-bites réteg (shell) Registry
a Windows 98 magja VMM
Telepíthető fájlrendszervezérlő
Konfigurációvezérlő
WDM illesztők vezérlője
Eszközillesztő programok
.1. ábra A Windows 98 felépítése
Az eszközillesztő programokra épülő modulok képezik az operációs rendszer és a futtatott alkalmazások szoftverhátterét. Az illesztőprogramok hierarchiáját, amely kapcsolatot teremt a hardver és a felhasználói programok között, Win32 Driver Modelnek nevezzük. Az előző fejezetben láttuk, hogy telepíthető fájlrendszer a perifériakezelés milyen lehetőségeit nyújtja. A Windows 98 virtuális számítógépeket használ a különböző alkalmazások és rendszerprogramok futtatására. Ez azt jelenti, hogy az alkalmazások úgy futnak, mintha egyedül birtokolnák a rendszer erőforrásait. A virtuális számítógépek kezelését a VMM-modul (Virtual Machine Manager) végzi. Fontos része a Windows 98 rendszernek a konfiguráció-vezérlő modul. A felhasználónak nem kell képzett szakembernek lennie ahhoz, hogy új hardverelemeket építsen a számítógépébe. Az operációs rendszer automatikusan felismeri az új hardverelemeket és telepíti a kezelésükhöz szükséges illesztőprogramokat. Több konfiguráció (gépki-
1
alakítás) is tárolható a rendszer adatai között, amelyek közül egyszerűen kiválasztva az aktuálisat, lehetővé válik, hogy számítógépünket különböző kiépítéssel használjuk. A Windows 98 rendszer magjának főbb részei: a grafikus megjelenítést biztosító és a felhasználóval kapcsolatot tartó programrészek, illetve az alapvető rendszerprogramok. A kezelői felület és az alkalmazások a fenti programok elemeit hívják a különböző műveletek végzése során. Alapvető része a rendszernek egy hierarchikus adatbázis (registry), amelyben a rendszermodulok és az alkalmazói programok tárolják adataikat. 1. Plug and Play - „magától működő” +A Plug and Play (PnP) elnevezéssel az olyan tervezési eljárást, illetve a személyi számítógép felépítésére vonatkozó előírásokat (specifikációkat) jelölik, amelyek lehetővé teszik a számítógép, a hozzá csatolt hardvereszközök, illesztőprogramok és az operációs rendszer automatikus együttműködését, felhasználói beavatkozás nélkül. Az ilyen rendszert felépítő hardverelemeket is Plug and Play komponenseknek nevezzük. A Plug and Play kifejezés szó szerinti fordítása a „helyezd be és használd”. A kifejezés által takart fogalom lényegét tekintve azonban inkább a „magától működő” elnevezés honosodott meg.
A Plug and Play rendszer a következő komponensekből épül fel: −
Plug and Play operációs rendszer,
−
Plug and Play BIOS (Basic Input/Output System,
−
Plug and Play hardvereszközök, illesztőprogramjukkal együtt.
A Windows 98 – a Windows 95-höz hasonlóan – Plug and Play operációs rendszer. Napjainkban a korszerű számítógép-alkatrészeket – kevés kivétellel – a Plug and Play előírásainak megfelelően tervezik. Az ilyen PnP hardvereszközök számítógépes rendszerbe való integrálása a felhasználótól mindössze az eszköz külső – azaz a számítógép dobozának szétszerelése nélküli – csatlakoztatását igényli. A telepítés többi részét, beleértve az erőforrások (a memóriacímek, a megszakítások – IRQ, és a közvetlen memóriacsatornák – DMA) elosztását a hardverelemek között, az operációs rendszer automatikusan végzi. A Plug and Play eszköz fizikai csatlakoztatása és a rendszer által automatikusan végzett eszközfelismerés után a rendszer megkeresi az eszközhöz tartozó illesztőprogramot (illetve annak frissítését), és üzembe helyezi az eszközt. Ha azonban a Windows 98 rendszer nem talál megfelelő illesztőprogramot, felajánlja a felhasználónak annak telepítését, a hardvereszközhöz kapott telepítőlemezről vagy CD-ROM-ról.
2
A Plug and Play kidolgozása során fontos szempont volt a már meglévő nem PnP technológiájú perifériákkal való kompatibilitás A Windows 98 természetesen ilyen számítógépre is telepíthető, azonban a telepítés során felmerülő hardverproblémák megoldásáról hagyományos módon, magunknak kell gondoskodni az eszközök átkonfigurálásával. A nem Plug and Play hardverelemek nem teszik lehetővé, hogy az operációs rendszer automatikus elvégezze konfigurálásukat, mivel a paramétereiket gyakran csak kézzel lehet megváltoztatni (a kártyán levő átkötéseket és mikrokapcsolók felhasználásával). Hagyományos módon egy új hardvereszköz telepítése az alábbi lépésekből áll:
– az eszköz jellemzőinek (I/O címek, IRQ, DMA-port) beállítása kapcsolók és átkötések segítségével, amihez ismerni kell mind a vezérlőkártya lehetséges beállításait, mind pedig a számítógépünk aktuális konfigurációját (a szabad erőforrásokat a Windows Eszközkezelőjében ellenőrizhetjük). A kártyán beállított jellemzőket érdemes megjegyezni és a BIOS-ban kizárni ezeket a Plug and Play eszközöknek szánt erőforrások köréből (a BIOS-ban a "Plug and Play Settings", "PnP features" stb. név alatt kell átállítanunk az eszköz IRQ és DMA beállításokhoz tartozó bejegyzéseket pl. "Legacy card-ra"). Erre azért van szükség, hogy a Windows 98 ne ossza ki ezeket az erőforrásokat más eszközöknek.
– a beállított eszköz behelyezése a számítógépbe (a számítógép kikapcsolása és áramtalanítása után), az eszközt vezérlő szoftver (illesztőprogram) telepítése (a "Start/Beállítások/ Vezérlőpult/Új hardver hozzáadása" alkalmazás segítségével), melynek során – ha a rendszernek nem sikerül felismerni az eszközt – ki kell választani a felajánlott listából a gyártót és a típust, a rendszer újraindítása.
–
–
Ezzel szemben a Plug and Play technológia olyan előírások gyűjteménye, amely a hardvereszközök automatikus konfigurációját célozza. Elegendő behelyezni a számítógépbe az új hardvert, és az elkezd működni. Jelenleg az alábbi következő Plug and Play eszközök ismertek: −
USB (Universal Serial Bus) eszközök: forrón (azaz a számítógép kikapcsolása nélkül) csatlakoztatók olyan külső hardvereszközök, mint a billentyűzetek, az egerek, a hangszórók és a videokamerák. A Windows 98 támogatja a USB busz- szabványt, és digitális kamera számára tartalmaz eszközmeghajtót (a többi eszköz számára az illesztőprogram az eszközzel együtt kell beszerezni).
−
IEEE 1394 eszközök: forrón csatlakoztatható, nagy sávszélességű eszközök, mint például a digitális filmfelvevők, kamerák és a videolemez-lejátszók. Az eszközök illesztőprogramjai a Win32 Driver Model (WDM) előírásai szerint
3
készülnek. Windows 98 a digitális kamera számára tartalmaz eszközillesztő programot. −
SCSI (small computer system interface) eszközök, mint például a merevlemez- és CD-ROM-meghajtók.
−
A PC Card (PCMCIA, Personal Computer Memory Card International Association) és a CardBus (32 bites PC Card) eszközök.
−
A VL (Video Electronic Standards Association = VESA Local) busz-szabványnak megfelelő eszközök alkalmasak gyors kapcsolatteremtés megvalósítására, azonban nem teljesen felelnek meg a Plug and Play előírásainak. Működésük hasonló az ISA eszközök működéséhez.
−
PCI (periferial component interconnect) eszközök: ez a lokális busz gyakorlatilag ipari szabvány lett, miután a legtöbb Pentium és Apple Power Macintosh számítógépben is alkalmazzák. A busz megfelel a Plug and Play elvárásainak, mivel a busz és a PCI eszközök egyaránt rendelkeznek azonosítási mechanizmussal, valamint az erőforrás-beállítások is lekérdezhetők a rendszer BIOS-án keresztül.
−
ISA (Industry Standard Architecture) eszközök: Az ISA buszrendszer képezi az IBM PC/AT architektúra alapját. A Plug and Play ISA eszközöket a busz megváltoztatása nélkül csatlakoztathatjuk az ilyen típusú számítógépekhez.
−
EISA (Extended Industry Standard Architecture) eszközök: Az EISA az x86alapú számítógépek busza. Az EISA eszközök szoftveres módon teszik lehetővé azonosításukat és konfigurálásukat. A Windows 98 olyan busz-enumerátorral rendelkezik, amely ezen eszközök konfigurációs információit az operációs rendszer számára elfogatható formátumúvá alakítja.
−
más eszköztípusok: IDE (integrated device electronics) vezérlők, ESP-k (Extended Capability Port), kommunikációs portok.
1.1. A Plug and Play komponensek Ahogy már a fejezet elején említettünk, a Plug and Play teljes alkalmazásához olyan számítógéppel kell rendelkeznünk, amelyik a PnP előírásainak megfelelően kidolgozott BIOS (Basic I/O system) rendszert tartalmaz, amely elegendő rugalmasságot biztosít ahhoz, hogy emberi beavatkozás nélkül is megoldhatók legyenek a különböző hardverelemek között fellépő konfliktusok. Ugyancsak fontos kritériuma a Plug and Play alkalmazásának, hogy a számítógépünkön olyan operációs rendszer működjön, amely rendelkezik a PnP képességekkel. Ilyen operációs rendszer a Windows 98 is, amely telepítéskor egy adatstruktúrában 4
(hardverfa) tárolja a számítógépben található eszközöket és az általuk használt erőforrásokat. A fentieken kívül a bővítő eszközöknek és az eszközök illesztőprogramjának szintén eleget kell tenni a Plug and Play előírásainak. Az ilyen eszközt az operációs rendszer automatikusan azonosítja, és szükség esetén újrakonfigurálja (dinamikus konfiguráció). A változások érzékelése és a rendszer dinamikus konfigurációja azt is lehetővé teszi, hogy bizonyos perifériális eszközöket a számítógép kikapcsolása nélkül, azaz forrón csatlakoztathatunk, illetve leválaszthatunk. A következőkben bemutatjuk a Plug and Play technológia elemeit, amelyekkel a Windows 98 telepítése, illetve új hardverelem beillesztése során találkozhatunk. hardverfa A rendszer aktuális konfigurációját tartalmazó adatbázis. A hardverfát a rendszer konfigurációs menedzsere építi fel és tárolja a számítógép memóriájában. A fa minden eleme (device node) egy eszköz leírását tartalmazza. Gyökér
"Régi" hang BIOS
PCI Plug and Play SCSI
ISA busz Képernyőcsatoló
CD-ROM Merevlemez
DMA Párhuzamos PCMCIA busz
Hálózat
Soros Billentyűzet-vezérlő I/O
2. ábra Példa hardverfára
.INF állományok Az .INF állományok az eszközök adott csoportjáról tartalmaznak információkat (például SCSI.INF). Egy új Plug and Play eszköz telepítése során a megfelelő .INF fájl tartalmát használja a rendszer a konfiguráció elvégzéséhez. 5
Regisztrációs adatbázis (Registry) A regisztrációs adatbázis a Windows 98 hardver- és szoftver konfigurációjának leírását tartalmazza. Események (events) A számítógép működése során keletkező jelzések (üzenetek), amelyek az aktuális konfiguráció megváltozását jelzik az operációs rendszer felé. Konfiguráció-vezérlő (configuration manager) A PnP azon komponense, amely felépíti a számítógép konfigurációját leíró adatbázist és tárolja az egyes eszközökhöz tartozó erőforrásokat. A konfiguráció-menedzser központi eleme a működő PnP rendszernek. Számbavevő (enumerator) Az eszközszoftver azon új része, amely együttműködik az eszközvezérlővel és a konfigurációs menedzserrel. A hardverfán minden busz eszközhöz tartozik egy számbavevő. A konfigurációs menedzser szintén tartalmaz egy speciális, ún. gyökér (root) számbavevőt, amely segíti a nem Plug and Play eszközök rendszerbe állítását. Erőforrás döntőbíró (resource arbitrator) Az a funkció, amely irányítja a speciális erőforrások foglalását és segít a fellépő konfliktusok megoldásában. Plug and Play BIOS Az új rendszer BIOS, amely támogatja a Plug and Play műveleteket. De magának a hardvereszköznek is lehet olyan BIOS-a, amely megfelel a Plug and Play előírásoknak. Plug and Play eszközvezérlő Az adott hardver vezérlését végző védett módú program (PnP alrendszer). Felhasználói felület Szabványos párbeszédablakok gyűjteménye, melynek elemeit a Plug and Play rendszer akkor jeleníti meg, amikor információkat vár a felhasználótól. A felhasználó is használhatja ezeket az ablakokat információnyerés céljából. Alkalmazások Olyan alkalmazás, amely képes fogadni a PnP eseményeket és azokra megfelelő módon tud válaszolni. Memória
6
Az eszköz által felhasznált fizikai memóriaterület (pufferterület). I/O Az eszköz által használt input/ouput portok (kapuk). Az eszköz-konfigurációs információ magában foglalja az eszköz által használható alternatív portkészletek leírását is. DMA Az eszköz által használt, a közvetlen memóriaelérést (Direct Memory Access) biztosító csatornák. IRQ Az eszköz (hardveres) megszakítási kérelmei. A Win32 Driver Model (WDM) és a buszok Windows 98-ban a Win32 Driver Model (WDM) egy olyan új vezérlőmodell, amely szerint az illesztőprogramok hierarchiája – a hardverszinttől egészen az alkalmazás szintjéig – felépül. Az eszköz és az alkalmazás közötti adatáramlás ún. buszokon (adatsíneken) keresztül folyik, amelyekből a WDM az USB és az IEEE 1394 technológiájút támogatja. (A Windows 98 a fentieken kívül a régebbi PCI és PCI Card szabványnak megfelelő buszokat is támogatja.) Az USB (Universal Serial Bus), illetve az IEEE 1394 (más néven FireWire) technológia két olyan hardverosztályt határoz meg, amelyek megkönnyítik a soros eszközök csatlakoztatását a számítógéphez: e két buszrendszer segítségével a perifériákat kívülről, több szintű elágazásokban kapcsolhatjuk a számítógéphez. A Windows 98 a buszra kapcsolt eszközöket a Plug and Play technológia szerint kezeli: elvégzi az automatikus felismerésüket, és illesztőprogramokat telepíti hozzájuk, ráadásul „forrón”, vagyis nyomban az eszköz fizikai csatlakoztatása után, a gép újraindítása és a telepítő parancssorozatok futtatása nélkül. (A busz az adatok és a vezérlőinformációk áramlását biztosítja a számítógép memóriája, a processzor és a perifériák között.) A két buszt különböző eszközök csatlakoztatására használják. A gyorsabb adatátviteli sebességű IEEE 1394 buszt a nagy tömegű információt küldő/fogadó eszközökhöz fejlesztették: digitális képfelvevők, digitális videolemez-lejátszók, memória, nyomtatók és lapolvasók (scanner). A lassúbb USB buszra „hagyományos” perifériákat csatlakoztatnak: billentyűzet, mutatóeszközök, botkormányok és kézi lapolvasók. Az USB ezen kívül megfelel a számítógépes játékok, hang és (MPEG-1 tömörítésű) videó igényeinek is.
7
Ahogy már említettük, mind az USB, mind pedig az IEEE 1394 támogatását a WDM (Win32 Driver Model) specifikáció tartalmazza, így a Windows későbbi verziói is (beleértve Windows NT-t) támogatni fogják a jelenlegi illesztőprogramokat. Az USB és az IEEE 1394 eszköz telepítéséhez az eszköz csatlakozókábelét a számítógép USB, illetve IEEE 1394 portjához kell csatlakoztatni. Ami az adatátviteli sebességet (bus transfer rates) illeti, a USB esetében ez 1,5 és 12 Mbit/másodperc, az IEEE 1394 esetében pedig 98,304, 196,608 és 393,216 Mbit/másodperc lehet.
A fent említett WDM – Windows eszközvezérlő modell – egy általános I/O (bemeneti/kimeneti) szolgáltatás-gyűjtemény, amely binárisan kompatíbilis illesztőprogramokat biztosít a jelenlegi és a jövőbeni Windows-alapú operációs rendszerek számára. A kompatibilitás jelenleg azt jelenti, hogy a WDM specifikáció alapján megírt eszközillesztő programok mind a Windows 98, mind pedig a Windows NT (5.0-ás) alatt is működnek – szemben a „WDM-korszak előtti” illesztőprogramokkal, amelyekből az eszközök többsége esetén két, egymással össze nem cserélhető változat készült. Erre azért van szükség, mivel a Windows NT-ben az eszközillesztők kezelése a kernelszervizek felé irányuló hívásokkal történik, ami különbözik a Windows 98-ban alkalmazott kezelési módtól. A Windows 98-ban az NT-kompatibilis szervizhívások értelmezését a WDM típusú eszközillesztők számára az NTKERN.VXD komponens végzi, miáltal az eszközillesztő program a környezetét Windows NT-nek érzékeli. Az NTKERN.VXD a meglévő eszközillesztő modellben egy újabb szintet definiál, azaz az eszköz felé irányuló kérések szokásos értelmezési (USER.EXE) és továbbítási (KERNEL32.DLL, KRNL386.EXE) sorába – az új WDM alapú eszközillesztő esetében – még az NTKERN.VDX is beékelődik. A WDM hatékonysága elsősorban abban rejlik, hogy az adatfolyamok feldolgozása (ún. szűrése, például a képinformációk dekódolása), illetve létrehozása és fogadása a korábbi modellektől eltérően végig a kernel szintjén (0. gyűrű) folyik, a felhasználói szintre (3. gyűrű) való többszörös visszaküldések nélkül, ami végső soron csökkenti a processzor terhelését.
A WDM szerepe a hardver esetében tulajdonképpen megfelel annak a szerepnek, amelyet az alkalmazások fejlesztésében és futtatásában a Win32 API (Application Programming Interface) tölt be. (Az egységes -Win32 API – programozási felületre készült alkalmazások változtatás nélkül futtathatók a Windows 95/98-as és a Windows NT-s platformon, vagyis a két operációs rendszer alá nem kell külön alkalmazást fejleszteni.) Az új közös WDM illesztőprogram modell azonban csak az új típusú buszrendszerekre és eszközökre vonatkozik, vagyis a már említett USB, IEEE 1394 buszokra és olyan eszközökre, mint a DVD-ROM, a digitális videokamerák stb. A WDM az
8
Advanced Configuration and Power Interface (ACPI, Továbbfejlesztett beállítási- és energiaforrás-felület) egyik alapeleme. DirectX Windows 98-ban hang- és videólejátszást egy DirectX névre keresztelt összetevő is támogatja. A DirectX segítségével jobb minőségben játszhatók le a különféle multimédiás anyagok, és jobban kezelhető a háromdimenziós grafika. A DirectX fogalommal azokat a programozási felületeket (API) illetik, amelyek lehetővé teszik az alkalmazások számára a rendszer multimédiás hardvereszközeihez való közvetlen hozzáférést, azaz az alkalmazások az eszközt az operációs rendszer megkerülésével érik el. A DirectX-hívásokkal elérhető kártyákhoz a gyártók olyan szoftveres vezérlőket, ún. HAL-okat (Hardware Abstraction Layer) készítenek, amelyek leírják a kártya képességeit a felette működő DirectX komponensek számára. Ha az alkalmazás készítője a DirectX komponensek függvényeit használja a multimédiás eszközök működtetésére (például gyors animáció érdekében), akkor a hívást követően a megfelelő DirectX komponens – az eszköz HAL-információi alapján – megvizsgálja, hogy hívás közvetlenül teljesíthető-e. Ha igen, a DirectX komponens (DLL) továbbítja a hívást a hardvernek, ha pedig nem, a Windows szoftveres emulációt végez, és a szokásos GDI-hívásokkal oldja meg a feladatot. A Windows 98 rendszerben megtalálható DirectX komponensek: DirectDraw DirectSound Direct3D DirectPlay DirectInput DireckAnimation DirectShow
2D grafika és animáció Hangkezelés, 3D grafika, Hálózati játékok támogatása, Botkormány, játékpad, billentyűzet, egér, HÍD (Human Interface Device) és erővisszacsatoló (force feedback) eszközök, Különböző médiatípusok együttes alkalmazása (a Web-lapokon is), (Korábban ActiveMovie), a DVD, az áramló audio- és videóadatok szűrése, keverése stb.
9
Media Control Interface (MCI) A hardvereszközök egységes kezeléséhez (vezérléséhez) Windows 98 hardverfüggetlen felületet (MCI-t) biztosít a médiaeszközöket használó alkalmazások számára. A felület MCI illesztőprogramokkal (driver) dolgozik, értelmezve és futtatva az olyan általános MCI parancsokat, mint a pause, play és stop. Az általános (ún. mag-) parancsokon és tulajdonságokon kívül az MCI felületen keresztül elérhető különböző eszköztípusok olyan tulajdonságokkal és parancsokkal is rendelkezhetnek, amelyek csak az eszközre jellemzőek. A jelenleg definiált MCI eszköztípusok a következők: animation, cdaudio, dat, digitalvideo, other (definiálatlan MCI-eszköz), overlay, scanner, sequencer, vcr, videodisk, waveaudio. 2. Alkalmazások futtatása a Windows 98 rendszerben Az operációs rendszerek sok tekintetben különbözhetnek egymástól. Az operációs rendszert minősítő jellemzők közül az egyik legfontosabb a számítógép memóriájának (operatív tárának) kezelési módja. A számítógép memóriája a különböző felhasználói programok (alkalmazások) működésének színtere. Ezért a Windows alatti programfuttatás módozatainak megértéséhez elengedhetetlenül szükséges a memóriakezelés lehetőségeinek tisztázása. A hagyományos besorolás szerint a Windows ún. egyfelhasználós operációs rendszer, ami azt jelenti, hogy egyidejűleg csak egy felhasználó (user) programjai futnak alatta. Már a Windows 3.1 is biztosította annak lehetőségét, hogy a felhasználó akár több programot is elindítson és a futó alkalmazások közül válassza ki a számára szükségeset. A több feladat (task) párhuzamos (konkurens) végrehajtását támogató rendszereket többfeladatos (multitasking) operációs rendszereknek nevezzük.
A Windows 98 rendszer lehetőséget biztosít a kimondottan a Windows 95, illetve Windows 98 rendszerre írt Win32-alapú alkalmazások mellett az MS-DOS és a Windows előző verzióihoz fejlesztett programok futtására is. A 16-bites MS-DOS és Windows 3.1 rendszerekre készített alkalmazásokat MS-DOSalapú, illetve Win16-alapú alkalmazásoknak nevezzük. A Windows NT és a Windows 95/98 (32-bites operációs rendszerek) számára írt alkalmazások Win32-alapú programok. A Win16 és a Win32 az alkalmazás-programozási felület (API - Application Programming Interface) 16-, illetve 32-bites változatai, amelyek a Windows rendszerfüggvényeit tartalmazzák. Minden Windows alkalmazás az API felhasználásával készül. (A Win32 API-nak több változata is létezik: Windows NT egyszerű és objektum-orientált API-ja, a Windows 98 API-ja, és a Windows 3.1-ben is használható 32-bites API-bővítés.)
10
Windows 98-ban az alkalmazások általában megbízhatóbban és zökkenőmentesebben futnak, mint a Windows előző verzióiban. Ennek oka egyrészt az, hogy a Windows 98 több rendszererőforrást bocsát az alkalmazások rendelkezésére, másrészt pedig jóval hatékonyabb a rendszer memóriakezelése. Ezen kívül a Windows 98 egyaránt támogatja a hagyományos és az újabb OLE-technológia alkalmazását (beleértve az OLE (ActiveX)-vezérlők használatát és az OLE-automatizmus lehetőséget). Ebben a fejezetben – az általános tudnivalókon túlmenően – megismerkedünk a Windows azon képességével, amely lehetővé teszi, hogy több alkalmazást futtassunk egyidejűleg (párhuzamosan). Ezt követően megnézzük, hogyan futnak a Windows 98 alatt a 32-bites és a 16-bites Windows alkalmazások, illetve az MS-DOS-alapú programok. (Az MS-DOS programok Windows 98 alatti futtatásával a 8. fejezetben foglalkozunk részletesen.) 2.1. Az alkalmazások indítása és befejezése A Windows 98-ban az alkalmazásokat sokféleképpen indíthatjuk el. Nézzünk néhány gyakran használt megoldást:
– A futtatni kívánt alkalmazást kiválaszthatjuk a Start/Programok menüből (amennyiben az ott megtalálható).
– Az alkalmazást megkereshetjük a Windows Intézőben vagy a Sajátgép mappában, esetleg a "Start/Keresés/Fájlok vagy mappák…" segítségével. Az alkalmazás indításához kétszer kell kattintanunk annak ikonján, vagy az ikon kiválasztása után a Fájl menü Megnyitás parancsát kell aktivizálnunk.
3. ábra Fájlok vagy mappák keresése
11
– Ugyancsak használhatjuk a Start menü Futtatás... menüpontját, ahol a megjelenő párbeszédablakban meg kell adnunk az alkalmazás nevét és elérési útját (a Tallózás nyomógombon kattintva megkereshetjük a futtatni kívánt alkalmazást).
– A gyakran használt alkalmazásokat parancsikon formájában elhelyezhetjük a munkaasztalon, így ezek indításához csak kétszer (illetve egyszer az Active Desktop felületen) kell kattintani az ikonon. Az alkalmazások szabályos befejezési lehetőségein (például a rendszer- vagy a Fájl gomb lenyomása) túlmenően menü Bezárás menüpontjának kiválasztása vagy a használhatjuk a
billentyűkombinációt is. Ez a módszer elsősorban a lefagyott alkalmazások „helyes” befejezésére biztosít megoldást. A lefagyott alkalmazás olyan futó program, amely nem reagál a felhasználói beavatkozásokra (egér, billentyűzet), ezért csak kívülről zárható le. A billentyűkombináció hatására megjelenik "Program bezárása" párbeszédablak (4. ábra), melynek segítségével bezárhatjuk a kijelölt, vagy a lefagyott alkalmazásokat. (A ismételt megnyomásával pedig újraindíthatjuk a számítógépünket.)
4. ábra Program bezárása párbeszédablak
2.2. A többfeladatos működés (multitasking) modelljei Az MS-DOS-tól eltérően, ahol egyszerre csak egy program futtatható (egyfeladatos operációs rendszer), a többfeladatos (multitasking) Windows operációs rendszer több alkalmazás egyidejű futtatását is támogatja. Az operációs rendszer többfeladatos működése azonban nem jelenti azt, hogy az alkalmazások valóban egyszerre futnak, ehhez a számítógépnek legalább annyi processzorral kellene rendelkeznie, ahány alkalmazás fut a gépen egy tetszőlegesen választott időpillanatban (a következő pillanatban ez a szám persze változhat). A többfeladatos működés egyszerűen azt jelenti, hogy az operációs rendszer képes megosztani a CPU-t (central processing unit 12
processzor) a futó programok – folyamatok (process) – között. Így a processzor egy kis ideig csak az egyik program utasításait hajtja végre, aztán átvált egy másikra. Mivel ezek az időintervallumok nagyon rövidek, a felhasználó úgy érzékeli, mintha az alkalmazások valóban egyszerre (párhuzamosan) futnának.
Több feladat problémamentes és megbízható futtatása azonban erősen függ az operációs rendszer által megvalósított többfeladatos működés modelljétől. A Windows 3.1 az ún. együttműködő többfeladatos (cooperative multitasking) működési modellt valósítja meg, ahol egyedül csak magától az alkalmazástól függ, mikor adja vissza a vezérlést (a processzort) az operációs rendszernek (ez a program szintjén az üzenetsor rendszeres figyelésével történik). Ezután az operációs rendszer ütemező komponense (scheduler) eldönti, hogy a várakozó folyamatok közül melyik kapja meg a vezérlést. Ez a modell egészen addig jól működik, amíg egyetlen folyamat sem használja túl sokáig a processzort. Ha azonban a felhasználó elindít egy hosszabb időt igénylő folyamatot (például nyomtatási fájl elkészítése), akkor a többi program kénytelen várakozni. Így a felhasználó nem kap választ a billentyűk és az egérgombok nyomogatására egészen addig, amíg a folyamat be nem fejezi a működését, és el nem engedi a processzort. A Windows 98 is használja az együttműködő többfeladatos modellt, de csak a 16-bites (Win16-alapú) alkalmazások futtatására. Ehhez a Windows 3.1-hez hasonló környezetet biztosít a rendszer, amelyben a Win16-alapú alkalmazások nem csak a memóriát osztják meg egymással, hanem az input- és üzenetsoruk is közös. A 32-bites (Win32-alapú) alkalmazások futtatatása az ún. kizárólagos, vagy rendszerközpontú (preemptive) többfeladatos modell megvalósításával megy végbe a Windows 98-ban. (Ezt a modellt használja a Windows NT is, ahol a folyamatokat több processzoron is meg lehet osztani. A Windows NT alatt azonban a 16-bites alkalmazások futtatása is így történik.) A Win32 alkalmazások saját, teljesen védett címterületen futnak, és külön üzenetsorokkal rendelkeznek – következésképpen a működésüket nem befolyásolja az, hogyan éri el a többi alkalmazás saját üzenetsorát. A kizárólagos többfeladatos működési modellben szintén az operációs rendszer ütemezője – ún. folyamatütemező (Process Scheduler) – dönt arról, hogy melyik folyamat kapja meg a vezérlést. A leglényegesebb eltérés az együttműködő többfeladatos modelltől az, hogy nem az alkalmazás üzenetsorához való fordulás rendszerességétől függ, meddig birtokolja a CPU-t a folyamat, hanem a processzoridő kiosztásáért felelő folyamatütemezőtől. Az ütemező minden folyamathoz különböző szintű elsőbbséget (0 és 31 közé eső prioritási szintet) rendel, amit szükség esetén futás közben meg is változtathat (például 13
eggyel növeli a prioritási szintet, ha a program előtérbe kerül, azaz megkapja a fókuszt, és eggyel csökkenti, ha a program újra háttérbe kerül). A processzoridő mindig a legnagyobb prioritási szinttel rendelkező folyamatok között kerül megosztásra. Kisebb prioritású folyamatok csak akkor jutnak processzoridőhöz, ha egyetlen magasabb prioritású folyamat sincs futtatható állapotban, például felfüggesztett állapotban van, azaz várakozik a további működéséhez szükséges műveletek – például háttértárról való olvasás – befejezésére. Minden folyamat (illetve ún. szál, lásd a következő alfejezetet) csak az előre definiált időszelet (time slice) határain belül (kb. 20 µs) használhatja a processzort, melynek elteltével a vezérlés visszakerül a rendszerhez. Ha ez idő alatt nagyobb elsőbbséggel bíró esemény keletkezett, akkor az ütemező a következő időszeletet a nagyobb prioritású eseményt feldolgozó folyamatnak adja. A vezérlés akkor is visszakerül a rendszerhez, ha az időszelet ugyan még nem telt le, de a folyamat elért egy olyan pontot, amikor magától adja vissza a vezérlést (például várakozik a felhasználói adatbevitelre). A kizárólagos többfeladatos modell sokkal megbízhatóbban működik, mint az együttműködő modell. A felhasználói beavatkozásra minden késlekedés nélkül megjön a megfelelő válasz, még akkor is, ha az egérmutató – a processzor foglaltságát jelezve – éppen homokóra alakú. Egy folyamat itt nem akadályozza más folyamatok futását. Így a felhasználónak, miután például elindította a fájlok másolását hálózaton keresztül, nem kell várnia a folyamat végére, hanem nyugodtan dolgozhat más alkalmazásokkal, például játszhat vagy szöveget szerkeszthet. Persze a problémamentes működésnek itt is ára van. Mivel nem az alkalmazás dönti el, hogy mikor veszíti el a vezérlést, ez leggyakrabban a működése közepén megy végbe, amikor a program erősen használja a számítógép erőforrásait. Az alkalmazás sikeres továbbfutása érdekében a rendszernek ekkor el kell mentenie a futó program aktuális állapotát – a regiszterek, a változók stb. tartalmát – az erre a célra fenntartott adatstruktúrákba. A vezérlés visszaadásakor pedig vissza kell állítania a megszakított program állapotát. A programozótól is kíván többletmunkát az a tény, hogy bizonyos esetekben nem engedhető meg a program futásának felfüggesztése. Ilyen szituáció például valamilyen közös erőforrás használata. A hibák elkerülése érdekében egy másik program csak akkor sajátíthatja ki a közös erőforrást, ha az előző alkalmazás már teljesen befejezte az erőforrás használatát (például fájlok kiküldése a nyomtatóra, pontosabban a nyomtatásra váró állományok átmeneti tárolójába). Ha egy ilyen fontos művelet nem fejeződik be azelőtt, mielőtt egy másik program is megpróbálja használni az erőforrást, akkor ez akár a rendszer összeomlásához is vezethet. (Az együttműködő többfeladatos
14
rendszerekben ilyen helyzet sosem fordulhat elő, mivel a futó programok csak akkor adják vissza a vezérlést, amikor befejezték a szükséges utasítások végrehajtását.) A kizárólagos többfeladatos rendszerek számára írt alkalmazásokban különböző programozási módszereket használnak az ilyen helyzetek kiküszöbölésére (kritikus szekciók kialakítása, szinkronizációs objektumok használata stb.), ami persze kissé megnehezíti a programozó munkáját. 2.3. A kizárólagos, többszálú, többfeladatos működés (preemptive multithreaded multitasking) A Windows 98 – a Windows NT-hez hasonlóan – nem csak az alkalmazások között osztja meg a processzor idejét, hanem azt a szemléletet támogatja, hogy egy alkalmazáson belül is elindíthatók egymástól teljesen függetlenül futó folyamatszálak, amelyek ugyanúgy ütemezhetők, mint az igazi (egyszálú) folyamatok. Például egy szövegszerkesztőben a helyesírás ellenőrzése és a táblázat formázása két egymástól független folyamatnak tekinthető. Ha a helyesírás-ellenőrző külön folyamatként fut, akkor párhuzamosan tovább lehet szerkeszteni a szöveget. Az előzőekben bemutatott megoldás a kizárólagos, többszálú, többfeladatos működés (preemptive multithreaded multitasking) nevet viseli. A folyamat (process) – a memóriába töltött és a futtatáshoz előkészített alkalmazás – fogalma mellett megjelenik a szál (thread) fogalma is. A többszálú működés, amely különleges programozási megoldásokat igényel, tovább javítja és finomítja a rendszer többfeladatos működését. A 32-bites alkalmazások készítéséhez kialakított programozási felület (Win32 API) támogatja a címben szereplő működési módot. Az operációs rendszer szóhasználatában az éppen futó Win32-alapú alkalmazás egy folyamat. Minden folyamat legalább egy szálból áll. A folyamat futtatása mindig egy szál elindításával kezdődik. A szál az alkalmazás kódjának olyan része, amely ugyanúgy kaphat időszeleteket az operációs rendszertől a független futásához, mint más kódrészek. Egy Win32-alapú alkalmazás több szálat is elindíthat. A folyamat szálai közösen használják a folyamat memóriaterületét, globális változóit és a folyamat erőforrásait. A Windows 98-ban minden 32-bites folyamat egy vagy több szálat indíthat el, azonban a 16-bites és az MS-DOS folyamatok mindig csak egy szálból állnak.
15
2.4. A Windows 98 virtuális gépei A különböző alapú alkalmazások Windows 98-ban külön virtuális gépeken (virtual machine, VM) futnak. Virtuális gépnek egy olyan különleges módon vezérelt memóriatartományt szokás nevezni, amit az alkalmazás különálló gépként érzékel. A virtuális gép tartalmazza mindazokat a valóságos (fizikai) gépen is elérhető erőforrásokat, amelyek szükségesek az adott alkalmazás futásához. A virtuális gépek kialakításából származó előnyök közül kiemelést érdemel a rendszer nagyobb biztonsága. A látszólag külön gépeken futó folyamatok nem zavarhatják meg egymás működését. Windows 98-ban alaphelyzetben egyetlen virtuális gép – az ún. rendszer virtuális gép (System VM) – van jelen. Ezen a gépen a rendszerfolyamatokon kívül fut az öszszes Win32- és Win16-alapú alkalmazás. Minden egyes Win32-alapú alkalmazás saját címtartományon, míg az összes Win16-alapú alkalmazás egy közös címtartományon belül helyezkedik el. Ha Windows 98 alatt elindítunk egy MS-DOS programot, akkor ez az alkalmazás egy külön virtuális gépen fut. Minden egyes MS-DOS virtuális gép környezete egymástól függetlenül beállítható, a rajta futó alkalmazás szükségleteinek megfelelően. Például, hasznos lehetőség, hogy minden egyes MS-DOS virtuális gépen saját AUTOEXEC.BAT fájlt futtathatunk le az alkalmazás elindítása előtt. (Az alkalmazás adatlapjain elvégezhető beállítási lehetőségek ismertetésére a 8.1. fejezetben kerül sor.) Windows 98 rendszer architektúrájában a virtuális gépek vezérlője (Virtual Machine Manager, VMM) nevű alkotóelem felel a virtuális gépek létrehozásáért és vezérléséért (a Windows 3.1-ben ezeket a funkciókat a WIN386.EXE komponens látta el). A virtuális gépek vezérlőjének legfontosabb feladatai a következőkben foglalhatók össze:
– a folyamatok ütemezése (process scheduling), – a memória lapozása (memory paging), – az MS-DOS mód támogatása olyan MS-DOS alkalmazások esetén, amelyek kizárólagos hozzáférést igényelnek a rendszer erőforrásaihoz. Mivel folyamatok ütemezéséről az előző két alfejezetben már esett szó, az MS-DOS móddal pedig 2.8. alfejezetben foglalkozunk részletesen, most csak a memórialapozás mechanizmusával ismerkedünk meg.
16
Rendszer virtuális gép
Win32 Kezelőfelületi eszközök
Win16
DOS virtuális gép
Alkalmazások 32-bites réteg
Registry
Windows 98 magja Telepíthető fájlrendszer vezérlő Virtuális gépek vezérlője
VMM
Konfiguráció vezérlő
WDM illesztők vezérlője
Eszközillesztő programok Memórialapozó Folyamatütemező
Védett módú MS-DOS felület (interface)
5. ábra A Windows 98 rendszer felépítése és virtuális gépei
2.5. Memóriakezelés A Windows 98-ban (és a Windows NT-ben is) a virtuális memória kezelése a 32-bites Intel processzorok (80386-ostól) azon lehetőségére épül, amely során a fizikai címtartomány helyett – a memórialapozást használva – logikai (virtuális) címtartományokat lehet összeállítani. Azt a legkisebb memóriablokkot, amit a lapozás során egyetlen egységként kezel a rendszer, memórialapnak nevezzük. A memórialapozás mechanizmusát használva a Windows 98 alatt futó 32-bites programok (a memóriát 32 bites címekkel elérő folyamatok) mindegyike 4 gigabájt (GB) memóriát címezhet. Ez a 4 GB az alkalmazás virtuális címterülete, amely egyenlő részekre – lapokra – van felosztva (az Intel processzorok esetében ez 4 kilobájt). Az alsó 2 gigabájt az alkalmazás saját területe, míg a felső 2 GB a rendszer által használt közös (osztott) memória. Az alkalmazás csak virtuális, 0-tól 4 GB-ig terjedő logikai címekkel jelölt folytonos memóriával dolgozik, és nem vesz tudomást arról, hogy az általa használt címterüle17
tek valójában hol kerülnek lefoglalásra a fizikai memóriában (a címkonverziót a processzor belső címképző egysége hajtja végre). A virtuális memória fizikailag egy háttértárolón elhelyezkedő területet jelöl, ami általában egy merevlemezen elhelyezkedő fájl (ún. swapfile). A processzor azonban csak azokkal az adatokkal tud közvetlenül dolgozni, amelyek az operatív (fizikai) tárban találhatók. Az adatok memóriába kerülése a virtuális és a fizikai memória közötti adatmozgás (másolás) során valósul meg, amely folyamat szintén teljesen láthatatlan a program számára. A virtuális memóriában értelmezett logikai címek két részből állnak: egy ún. báziscím kiválasztására szolgáló szelektor és egy offszet részből. A báziscím az adott memóriaszegmens helyét határozza meg a virtuális memóriában. A szelektor pedig egy indexérték, amely egy ún. szegmensleíró táblázatban egy szegmensleírót jelöl, amely a báziscímet tartalmazza. A logikai, ún. lineáris cím a báziscím és az offszet értékből adódik össze (mind a három cím 32-bites érték). Szelektor
Offszet Virtuális memória 4GB Veremszegmens
Leírótábla
Adatszegmens Báziscím
Lineáris cím +
Kódszegmens
0
6. ábra Az Intel processzorcsalád (386-ostól) szegmentált címképzése
A Windows 98 (és a Microsft cég más 32-bites operációs rendszerei, illetve a Unix rendszerek többsége) által használt úgynevezett Flat (lineáris) memóriacímezési modellben nem létezik külön kód-, adat és veremszegmens: mind a három szegmens a teljes címtartományra (azaz 0-tól 4 gigabájtig) van állítva. Ebből adódik a megcímezhető virtuális tár 4 gigabájtos mérete. A Win16-alapú alkalmazások futtatásához Windows 98 a Win16 alrendszer emulációját végzi. 16-bites operációs környezet (Windows 3.1, MS-DOS) támogatására az Intel processzor architektúrája az ún. szegmentálási mechanizmust használ, amelynek lényege, hogy a memória nagyobb blokkonként, ún. szegmensenként érhető el 16-bites címekkel, és a legfeljebb 64 KB nagyságú szegmensen belüli címzés 16-bites offszet értékekkel valósul meg. Ha szükség van az aktuális szegmensen kívüli területek elérésére is, akkor a szükséges címátszámítás mind az alkalmazások, mind pedig az operációs rendszer teljesítményének romlásához vezethet. 18
Ahogy már említettünk, az alkalmazás kódja és adatai számára a memóriaterület mindig laponként kerül lefoglalásra. Ha kevés fizikai memória (RAM) áll a futó alkalmazások rendelkezésére, akkor az éppen nem használt lapok kikerülnek a számítógép fizikai memóriájából a merevlemezre (egy ideiglenes lapozási fájlba). Ha az alkalmazásnak újra szüksége lesz a lemezen tárolt lapok tartalmára (adatokra vagy kódra), akkor az információ visszakerül a fizikai memóriába. Ez a memóriakezelés igény szerinti lapozás (Demand Paging) néven ismert. Fizikai memória szabad lap
1. folyamat virtuális címterülete 4 GB 2 GB 0
Rendszer, 3. lap 1. folyamat, 5. lap
Rendszer által címezhető memória (rendszerterület)
2. folyamat, 1. lap 1. folyamat, 2. lap
Alkalmazás által címezhető memória (felhasználói terület)
Rendszer, 2. lap 2. folyamat, 4. lap virtuális-fizikai címleképezés
2. folyamat, 3. lap szabad lap Rendszer, 4. lap 1. folyamat, 1. lap
2. folyamat virtuális címterülete
2. folyamat, 2. lap 4 GB 2 GB 0
Rendszer által címezhető memória (rendszerterület)
szabad lap 1. folyamat, 4. lap
Alkalmazás által címezhető memória (felhasználói terület)
Rendszer, 1. lap szabad lap 1. folyamat, 3. lap
7. ábra Memórialapozás
A virtuális címek és a számítógép fizikai memóriájának összerendelését a virtuális memória kezelője, a memórialapozó (Memory Pager) valósítja meg. Azáltal, hogy a valódi fizikai címek rejtve maradnak az alkalmazások elől, egyrészt egyszerűbbé válik a címzés, másrészt pedig nő a rendszer biztonsága, mivel az egyik futó alkalmazás nem érheti el a többi alkalmazás által lefoglalt memóriaterületeket. A Win32 folyamatok valójában nem a 0-tól, hanem a saját címtartományuk 0x00400000 címétől töltődnek be, amely terület nem osztható meg más folyamatokkal. Ez alól kivételt képeznek a Win16-alapú alkalmazások, mivel ezek továbbra is egyetlen közös címtartományon belül futnak (a 0x00001000-0x003FFFFF virtuális címtartományon, összesen 4 megabájton). A címtartomány alsó 4096 bájtja (4 KB, 0x00000000-0x00000FFF) nem használható: ez a terület a programhibákból adódó nulla értékű mutatók (pointer) felismerésére van fenntartva. 19
A fentiekben leírt lineáris címzési modell használatával Windows 98 lehetővé teszi az operációs rendszer összes 32-bites komponensének és minden Win32-alapú alkalmazásnak a címezhető memóriaterület teljes 4 gigabájtjának kihasználását, és megszünteti a szegmentált memória jellegzetességeiből fakadó esetleges kellemetlenségeket. Sajnálatos módon azonban a Windows 98-ban – a Windows NT-vel ellentétben – a rendszerrutinok és az eszközvezérlők minden folyamat által elérhető, megosztható címtartományban helyezkednek el (helytakarékossági okokból). Amennyiben ezek a területek programhiba következtében felülíródnak, a Windows rendszer összeomolhat. Az alkalmazások szempontjából az operációs rendszer rutinjait a virtuális címtartomány felső 2 gigabájtos része tartalmazza, amelyek a folyamatok által címezhető alsó 2 GB virtuális címterülettel szemben (fizikailag elkülönülő területek) csak egyetlen példányban léteznek a fizikai memóriában. Vagyis minden egyes folyamat 0x80000000-0xBFFFFFFF virtuális címtartományában található adatok az összes folyamat által írhatók és olvashatók, mivel egy és ugyanazon fizikai tárterületen helyezkednek el. Ezen terület első 1 gigabájtnyi részén a rendszer dinamikus könyvtárai (a KERNEL32.DLL, a USER32.DLL, a GDI32.DLL és a ADVAPI32.DLL), a többi részben pedig a virtuális eszközvezérlők, a memóriakezelő és a fájlrendszer számára fenntartott területek találhatók. A címtartomány megosztásából eredően azonban ezek a területek semmiféle védelmet nem élveznek a felülírásukat indítványozó folyamatokkal szemben.
2.6. A 32-bites alkalmazások futtatása A Win32-alapú alkalmazások kihasználhatják a Windows 98 által biztosított teljesítménynövelő lehetőségeket. A 32-bites alkalmazások kizárólagos többfeladatos üzemmódban futnak a rendszer virtuális gépén, a többi alkalmazástól elkülönített címtartományban. A Win32 folyamatok egy vagy egynél több szálból épülnek feljavítva ezzel a rendszer többfeladatos működésének hatékonyságát és a felhasználóval való kommunikációt. A Windows 98 sokkal ellenállóbb az eltévedt és függőben maradt folyamatokkal szemben, mint a Windows 3.1, ahol az alkalmazások közös memóriaterületet és üzenetsort használnak. Windows 3.1-ben egy hibás folyamat az egész rendszer „elszállásához” vezethet. A Windows 98 ilyen esetekben azonnal megszünteti az eltévedt 32-bites folyamat futását, nem érintve ezzel más alkalmazások további végrehajtását. Ezen kívül minden 32-bites alkalmazásnak saját üzenetsora van, aminek következtében szintén javul a rendszer stabilitása. Az üzenetsor a rendszer által használt memóriaterület, ahol a program számára értelmezhető formátumú üzenetek tárolódnak, és ahonnan az alkalmazások kiolvassák az üzeneteket. Az üzeneteket külső (például egérgomb lenyomása) vagy belső (például ütemező jelzése) események váltják ki. A Windows üzenetvezérelt környezetében az alkalmazás futása lényegében a számára érkezett üzenetek kiolvasásából és az üzenetek megfelelő feldolgozásából áll. 20
Az együttműködő többfeladatos Windows 3.1 akkor adja át a vezérlést egy másik folyamatnak, amikor az éppen futó alkalmazás ellenőrzi az üzenetsort. Ha valamely alkalmazás túl sokáig nem ellenőrzi az üzenetsort, vagy egyszerűen „lefagy”, a rendszer mindaddig felfüggesztett állapotban tartja a többi folyamatot, amíg a hibás folyamat be nem fejeződik. A Windows 98-ban ezzel szemben a futó Win32-alapú folyamatok tudomást sem szereznek arról, hogy miként használja a többi folyamat saját üzenetsorát. Ha Windows 98-ban „lefagy” egy 16-bites, vagy „elszáll” egy 32-bites alkalmazás, a többi 32-bites folyamat tovább folytatja futását és tovább kapják az üzeneteket a saját üzenetsorukból. A Windows 98-ban a 32-bites alkalmazások futtatása abban is különbözik a Windows 3.x és az MS-DOS rendszerekben megszokott 16-bites alkalmazások futtatásától, hogy ezek az alkalmazások nem kényszerülnek a szegmentált memóriaszerkezet használatára, hanem lineáris (sík - flat) címekkel címzik a memóriát. A lineáris memóriamodellt használva a 32-bites címekkel – minden ügyeskedés nélkül – akár mind a 4 Gbájt címezhető fizikai memóriát elérhetjük. Végül megjegyezzük, hogy azok a 32-bites alkalmazások, amelyeket a Windows NT számára fejlesztettek ki, és amelyek készítésekor a Win32 API-nak csak a Windows 98 és a Windows NT-ben egyaránt megtalálható közös részét használták, minden további átdolgozás nélkül futtathatók a Windows 98 alatt is. A külön megvásárolható Win32s bővítésnek és a megfelelő fejlesztői környezetnek köszönhetően, már az egyébként 16-bites Windows 3.1-ben is lehetőség volt 32-bites alkalmazások készítésére és futtatására. Az ilyen alkalmazások Windows 98 alatti futtatásához azonban az esetek többségében szükséges egy kis átdolgozás.
2.7. A 16-bites Windows alkalmazások futtatása Windows 3.1 rendszerhez fejlesztett Win16-alapú (16-bites) alkalmazások (szövegszerkesztők, táblázatkezelők, játékok stb.) minden változtatás nélkül futnak a Windows 98 alatt is. Azonban ezek az alkalmazások nem használják ki azokat az előnyöket, amelyeket a Windows 98 a Win32-alapú alkalmazások számára biztosít. A 16-bites alkalmazások a Windows 98-ban ugyanúgy együtt futnak egy közös memóriatartományon belül, az együttműködő többfeladatos modell szerint, mint ahogy azt a Windows 3.1-ben tették. (Azon Win16-alapú alkalmazásokhoz, amelyek futtatásához különleges paramétereket igényelnek, a Windows 98 egy APPS.INF állományban tárolja a szükséges beállításokat.) A 16-bites alkalmazások futtatása Windows 98 alatt azonban megbízhatóbb, mint Windows 3.1 alatt. Egy rosszul „viselkedő” Win16-alapú alkalmazás nem tudja tönk21
retenni az egész rendszert, mivel a 16-bites alkalmazások nem érhetik el a 32-bites és a DOS-alapú alkalmazások memóriaterületét. Egy hibásan működő 16-bites alkalmazás legfeljebb csak a többi 16-bites alkalmazás futását zavarhatja meg. A 16-bites alkalmazások futása során jelentkezhet az ún. általános védelmi hiba (General Protection Fault), amely az alkalmazás megszakítását eredményezi. Ekkor a Windows 3.1-ben a hibás alkalmazás által lefoglalt erőforrások lefoglalva maradnak, ami nagyon gyorsan a rendszer „elhalásához” vezet. A Windows 98 azonban nyomon követi a futó folyamatok által lefoglalt erőforrásokat, és ezt az információt arra használja, hogy „kitakarítsa” a rendszert, miután valamelyik alkalmazás nem szabályos módon fejezi be a futását. Ennek köszönhetően még tovább nőtt a Windows 98 megbízhatósága és védelme. Bár a 16-bites alkalmazások futtathatók a Windows 98 alatt is, azonban a rendszer lehetőségeit csak a 32-bites alkalmazások használhatják ki. Ezért mindenképpen érdemes áttérni az alkalmazások 32-bites változataira. (Számolni kell azonban azzal, hogy a programok 32-bites változatainak mérete jóval nagyobb, mint a 16-biteseké.) 2.8. MS-DOS alkalmazások futtatása Az MS-DOS-alapú alkalmazások még ma is jelentős részét képezik a személyi számítógépeken futó alkalmazásoknak. Bár a DOS napja leáldozott, a DOS-os alkalmazások egy része valószínűleg még egy ideig használatban marad. Úgy, ahogy a Windows 3.1 386-os módjában, minden MS-DOS alkalmazás saját virtuális gépen fut. A virtuális gépek használatának köszönhetően lehetővé válik az egyfeladatos rendszerre írt alkalmazások futtatása többfeladatos operációs rendszer alatt. Windows 98-ban ezek az alkalmazások is a kizárólagos többfeladatos modell alapján működnek. Windows 98-ban a DOS-alapú alkalmazások futtatására sokkal több memória áll rendelkezésre, mint Windows 3.1-ben, így a memóriaszűke miatt a Windows 3.1-ben nem futtatható alkalmazások is szépen futnak. Ez annak köszönhető, hogy a Windows 95-ben és Windows 98-ban sok korábban 16-bites, valós módú rendszerelemet (elsősorban az eszközvezérlőket - például az egérvezérlőt) 32-bites védett módúra írtak át. A DOS-alapú alkalmazások a hagyományos memóriát használják (a memória alsó 640 kilobájtja) ugyanúgy, mint a Windows 3.1 valós módú rendszerelemei. Így az MS-DOS-ra épülő Windows 3.1-ben előfordulhatott, hogy miután minden rendszerés DOS-alapú komponens (eszközvezérlők, tárrezidens programok, hálózati komponensek) betöltődött a memóriába, bizonyos memóriaigényes MS-DOS programok nem indultak el. A Windows 98-ban azonban a 32-bites rendszerelemek nem használnak hagyományos memóriát, így a DOS alkalmazások futtatására sokkal több hely marad. 22
Az MS-DOS-alapú alkalmazásoknak egy csoportja egyáltalán nem képes a Windows 3.1 alatt működni. Ezek az alkalmazások (elsősorban játékok) általában közvetlenül használják a hardverelemeket – például közvetlenül a videómemóriába írnak, átírják a megszakításokat és majdnem teljesen kisajátítják a processzor idejét és más erőforrásokat – vagyis felrúgják a többfeladatos rendszer használatának minden szabályát. A Windows 98 azonban, a rendszerszinten megvalósult újításoknak köszönhetően, lehetővé teszi az ilyen programok közül a „szelídebbek” futtatását (akár ablakban is). Azon alkalmazások számára pedig, amelyek csakis az MS-DOS alatt futnak és a hardverhez 100 százalékos hozzáférést igényelnek, a Windows 98 biztosít egy különleges mechanizmust, az ún. MS-DOS módot, amely tiszta MS-DOS környezetet biztosít az ilyen alkalmazások futtatásához. A Windows 98 az MS-DOS módban egyszerűen félreáll, vagyis kimásolja magát a memóriából (egy kis tönk – stub – kivételével, melynek segítségével újraindulhat az egész rendszer), ezáltal a számítógép összes erőforrása elérhető az MS-DOS-alapú alkalmazásból. Amikor a felhasználó MS-DOS módban elindít egy DOS-alapú alkalmazást, a Windows 98 megkérdezi tőle, hogy befejezheti-e a rendszeren éppen futó folyamatokat. Igenlő válasz esetén a Windows befejezi a folyamatokat, újraindítja a számítógépet és betölti a valós módú MS-DOS operációs rendszert (igény esetén feldolgozza a felhasználó által beállított CONFIG.SYS és AUTOEXEC.BAT állományokat) és elindítja az alkalmazást. Amikor a felhasználó kilép az alkalmazásból, a Windows 98 újraindítja a számítógépet és visszaállítja a saját felhasználói felületét. Ez a megoldás sokkal elegánsabb, mintha a felhasználónak kellene a fenti lépésekről gondoskodnia. Windows 98-ban viszonylag kevés MS-DOS-alapú alkalmazás igényli az MS-DOS módot a futtatásához, és a legtöbb program Windows környezetben is jól érzi magát. Az MS-DOS mód használata nem jelent szükségképpen teljesítménynövekedést is. Csak azok az alkalmazások esetében ajánlatos használni ezt a módot, amelyek máskülönben nem indulnak el a Windows alatt. A Windowsban alapértelmezés szerint minden alkalmazás ablakban fut (most nem beszélünk az MS-DOS módot igénylő alkalmazásokról). MS-DOS programok esetén lehetőség van a teljes képernyő használatára is. Erre elsősorban akkor van szükség, ha VGA grafikus módot használó alkalmazást futtatunk. Az MS-DOS-alapú alkalmazások ablaka tartalmaz egy eszköztárat, melynek segítségével a felhasználó kivághatja és a vágólapra másolhatja az MS-DOS ablak szöveges tartalmának bármelyik részét, amit Windows-alapú alkalmazásban is felhasználha-
23
tunk. Egyszerűen megy az átkapcsolás az ablakos és teljes képernyős módok között (billentyűzetről az átkapcsolás az billentyűkombinációval is elvégezhető). Ugyancsak megválasztható, hogy milyen betűtípussal jelenjen meg az MS-DOS ablak szöveges tartalma (8. ábra).
2.8. ábra A futó MS-DOS-alapú alkalmazás ablaka
A Windows 98 abban is különbözik a Windows 3.1-től, hogy minden virtuális DOS gépen az alkalmazás futtatása előtt lefuttatható egy saját parancsfájl (.BAT), ami lokálisan beállítja az adott virtuális gép környezetét, nem érintve a többiét. A fent ismertetett beállítások (az MS-DOS mód használatának előírása, parancsfájl, betűtípus stb.) Windows 98-ban nagyon egyszerűen megadhatók. Windows 3.1-ben a PIF Editorral segítségével definiáltuk az MS-DOS-alapú alkalmazás sikeres futtatásához szükséges beállításokat. A program a beállításokat PIF (Program Information File) állományban tárolta. Windows 98-ban nincs szükség a PIF Editorra, – minden szükséges beállítás elvégezhető az alkalmazás adatlapjainak felhasználásával. Az alkalmazás tulajdonságlapjainak megjelenítéséhez egyszerűen rá kell kattintani a jobb oldali egérgombbal az alkalmazás ikonjára (akár a munkaasztalon, akár a Windows Intézőben), és a felbukkanó menüből ki kell választani a Tulajdonságok menüpontot. A megjelenő párbeszédablakban elvégezhető műveletekkel a 8.1. fejezetben részletesen foglalkozunk. Végül megjegyezzük, hogy a Start menüből indítható "MS-DOS parancssor" alkalmazás tulajdonképpen a COMMAND.COM programot aktivizálja. A Windows 98-beli DOS parancsok átdolgozásra kerültek, egyrészről kibővültek a hosszú állománynevek támogatásával, másrészről pedig megszűnt a munkaterületek 64 kilobájtos korlátja (edit, sort, xcopy32 stb.). Továbbá néhány új utasítás is megjelent, hozzáférést biztosítva a Windows 98 új lehetőségeihez.
24
3. A rendszeradatok tárolása és beállítása A Windows 98 a rendszeradatokat és az alkalmazások adatait egységes, hierarchikus, rendszerleíró adatbázisban, a Registry-ben tárolja. A Windows 3.1-ben a rendszer működtetéséhez szükséges adatokat és beállításokat az AUTOEXEC.BAT, a CONFIG.SYS és az .INI szöveges állományok tartalmazták. A rendszerleíró adatbázis használata feleslegessé teszi a fenti szöveges állományok használatát, azonban kompatibilitási okokból a Windows 98 rendszerben is megtaláljuk azokat. 3.1. A rendszerleíró adatbázis A Windows rendszer működési adatait a WINDOWS könyvtárában található adatállományok tartalmazzák. A rendszeradatokat a SYSTEM.DAT, a felhasználókhoz kapcsolódó adatokat pedig a USER.DAT állomány tartalmazza. Ha több felhasználó használja a gépet, akkor a WINDOWS\PROFILES könyvtárban a felhasználó nevének megfelelő alkönyvtárban található a felhasználó testre szabott adatait tartalmazó USER.DAT fájl. Minden sikeres rendszerindításkor az utoljára érvényes adatok mentésre kerülnek a SYSTEM.DA0 és a USER.DA0 állományokba, így ezek a rendszerbeállítások biztonsági mentéseként használhatók. Belső szerkezetét tekintve a rendszerleíró adatbázis hierarchikus szerkezetű. Ez azt jelenti, hogy az információ objektumokban található, mely objektumok gyűjtő objektumokban és ezek további gyűjtő objektumokban lehetnek pontosan úgy, mint a lemezen az állományok és az állományokat tároló mappák. Az információkat tároló objektumokat kulcsoknak nevezzük, arra utalóan, hogy az információhoz való hozzáférést teszik lehetővé. A rendszer által használt információk változókba kerülnek, amely változókat a nevük alapján azonosítjuk. A változók típusukat tekintve lehetnek karakterláncok, illetve bináris számadatok. A bináris számadatok hossza is lehet rögzített hosszúságú (32-bites), vagy nem rögzített hosszúságú. Az is elmondható, hogy a könyvtárszerkezetnek megfelelően a regisztrációs adatbázis is fastruktúrájú, azaz minden objektum pontosan egy gyűjtőobjektumban található. Az egyes csomópontok – az előző verziókkal való kompatibilitás miatt is – speciális nevet viselnek és úgy kezelhetők, mintha a regisztrációs adatstruktúra gyökerében helyezkednének el. A regisztrációs adatbázis valójában két gyűjtőobjektumot tartalmaz. Az egyik objektum neve a Hkey_Local_Machine – a SYSTEM.DAT állománynak megfelelően a számítógéppel kapcsolatos információkat tartalmazza: hardveradatok, a telepített programok adatai és beállításai stb.. A Hkey_Local_Machine objektum további gyűjtőket tartalmaz: − A Config különböző, sorszámozott gépkonfigurációs adatokat tartalmaz. A Windows 98 lehetőséget teremt arra, hogy több hardverkialakítást definiáljunk, és ezek közül mindig az egyiket használjuk. A Hkey_Current_Config kulcs úgy jele25
−
− − − − −
nik meg, mintha gyökérobjektum lenne, valójában azonban a Config csomópont aktuális konfigurációjára mutat. A Software csomópont tartalmazza a különböző telepített szoftverrendszerek adatait. Ide írja be például a Microsoft is a saját rendszereinek adatait a Microsoft gyűjtőbe. A Software gyűjtőben megtaláljuk a CLASSES gyűjtőobjektumot is, amely a társítási információkat tárolja. A Hkey_Classes_Root kulcsszó gyökérobjektumként azonosítja a Hkey_Local_Machine / Software / CLASSES gyűjtőobjektumot. A Windows 98 indításkor végigpásztázza az eszközöket és amelyeket azonosítani tud, azokat egy feljegyzi. Az Enum ág tartalmazza a felderített eszközöket. A Hardware ág egyéb eszközadatokat – például kommunikációs port tartalmaz. A Network gyűjtőobjektum a pillanatnyi hálózati adatokat tárolja. A System ág CurrentControlSet objektuma tárolja a rendszerbeállításokat. A Hkey_Dyn_Data objektum is gyökérként jelenik meg a regisztrációs adatbázisban, valójában a Hkey_Local_Machine dinamikusan változó adatait gyűjti csokorba.
A Hkey_Users objektum a felhasználói adatok tárolóhelye. Ezen adatok is két csoportba sorolhatók. Az egyik csoport az általános információk csoportja, amely felhasználók közös adatait tárolja, míg a másik csoport a felhasználók egyedi adatai tartalmazza. − A .DEFAULT objektum az alapértelmezett felhasználói beállításokat tartalmazza, azonban egyéb felhasználói adatokat tartalmazhat. A Hkey_Current_User is gyökérobjektumként jelenik meg, valójában azonban az aktuális felhasználó adatait tárolja.
2.9. ábra A rendszerleíró adatbázis szerkezete
26
3.2. A rendszerleíró adatbázis kezelése A rendszerleíró adatbázis kezelésére a REGEDIT.EXE kezelőprogram szolgál, melyet a WINDOWS\SYSTEM könyvtárban találunk. A rendszerleíró adatbázis kezelése, módosítása nagy szakértelmet kíván, és így nem tekinthető mindennapos felhasználói feladatnak. A programot parancssorból indítva arra használhatjuk, hogy .REG kiterjesztésű állományokba mentsük az adatbázis tartalmát, illetve visszaolvassuk az adatokat az alábbi szintaktikával. Regedit [/L:system] [/R:user] fájl1.reg, fájl1a.reg… Regedit [/L:system] [/R:user] /e fájl1.reg [regkulcs] Regedit [/L:system] [/R:user] /c fájl2.reg
A paraméterek és kapcsolók magyarázata az alábbiakban foglalható össze: /L:system /R:user fájl1.reg, fájl1a.reg… /e fájl3.reg regkulcs /c fájl2.reg
A SYSTEM.DAT állomány helye. A USER.DAT állomány helye. A beépítendő .REG állományok. Az állomány. ahova exportáljuk az adatbázis tartalmát. A kulcstól kezdve exportálunk, ha elmarad, akkor az egész tartalom exportra kerül. Az adatbázis tartalmát az állományban tároltakkal írjuk felül.
A Windows 98 külön segédprogramot tartalmaz az regisztrációs adatbázis mentésére, visszaállítására és javítására. A Scanreg programot az alábbi formában használjuk: Scanreg [/kapcsoló]
A kapcsoló lehetséges értékeit az alábbi táblázatban foglaltuk össze: Biztonsági másolat készítése a rendszerleíró adatbázisról, ill. a rendszerkonfigurációs fájlokról, RESTORE Abiztonsági másolat visszaállítása, FIX A rendszerleíró adatbázis javítása (MS-DOS módban), COMMENT="megjegyzés" A megadott megjegyzés hozzáfűzése a CAB fájlhoz a biztonsági másolat készítése során. BACKUP
Ha a Scanreg programot paraméter nélkül indítjuk, akkor megvizsgálja a rendszerleíró adatbázist, és ha hibátlannak találja, biztonsági másolat készítésére tesz javaslatot. Megjegyezzük, hogy az alkalmazás paraméter nélkül a Start/ Programok/ Kellékek/ Rendszereszközök/ Rendszerinformáció alkalmazás Eszközök menüjének "Rendszerleíró adatbázis ellenőrző" parancsával is elindítható.
27
3.3. A rendszerleíró adatbázis interaktív kezelése (Regedit) Ha a Regedit programot paraméterek nélkül futtatjuk, akkor a rendszerleíró adatbázis interaktív kezelőprogramját használhatjuk (10. ábra). Az ablak bal oldalán a kulcsok – a gyűjtőobjektumok – faszerkezete látható, míg a jobb oldalon az adott kulcs változói és a változók értékei jelennek meg. Az alkalmazás menüjének parancsai segítik a program használatát.
2.10. ábra A Regedit használata
A rendszerleíró adatbázis A menüpontokat az adatbázis exportálására, importálására, nyomtatásra és a program futásának megszakítására használhatjuk. Szerkesztés Új kulcsot és változót hozhatunk létre, illetve a meglévő kulcsokat, változókat törölhetjük, másolhatjuk, illetve átnevezhetjük. Az adatbázisban való eligazodást segíti a keresés funkció. A Szerkesztés menü menüpontjait az ablak felbukkanó menüjében is megtaláljuk.
2.11. ábra Keresés a rendszerleíró adatbázisban 28
Nézet A menüponttal intézkedhetünk az állapotsor megjelenítéséről, az osztóvonal helyzetéről és arról, hogy a Regedit program által megjelenített értékek és a rendszerbeállítások szinkronba kerüljenek (Frissítés)
2.12. ábra Rendszerbeállítás szerkesztő
3.4. A rendszerbeállító állományok kezelése (Sysedit) A rendszeradatok egy részé (kompatibilitás miatt) szöveges állományokban is tárolja a Windows 98. Ezen adatok a gyökérkönyvtárban a CONFIG.SYS, AUTOEXEC.BAT állományokban, illetve a WINDOWS könyvtár WIN.INI, SYSTEM.INI és PROTOCOL.INI fájljaiban találhatók. A WINDOWS\SYSTEM könyvtárban található Sysedit program egy MDI (Multiple Document Interface) felületű szövegszerkesztő program a hagyományos menüelemekkel (Fájl a mentésre és a nyomtatásra Szerkesztés a vágóasztal használatára, Keresés tartalom keresésére Ablak az ablakok elrendezésére). 4. Parancsfájlok (szkriptek) és a Windows Scripting Host (WSH) A számítógépet már eléggé régóta használó Olvasó bizonyára emlékszik a DOS kötegelt (batch, .BAT) állományaira, amelyek több DOS-parancsból épültek fel. Ha például a számítógép bekapcsolása után gyakran kellett végrehajtanunk egy bizonyos pa29
rancssorozatot, erre a parancsfájl biztosított kényelmes megoldást, mert egyetlen parancs kiadásával az állományban tárolt összes utasítás sorban feldolgozásra került. Windows 98 a parancsfájlokra emlékeztető megoldást kínál a gyakran végrehajtott, ismétlődő feladatok automatikussá tételére. Az utasítások sorozatát tartalmazó parancsfájlokat szkripteknek (script) nevezzük, a végrehajtásukért felelő programot pedig Windows alapú szkriptgazdának (Windows Scripting Host, WSH). A Windows Scripting Host segítségével a különböző feladatokat végző parancsfájlok Windows alól és a DOS parancsértelmezőben egyaránt lefuttathatók. A WHS alapmoduljai kétféle ún. szkriptleíró nyelven írt parancsfájl feldolgozására képesek: – az Internet Explorer által használt VBScript (Visual Basic Scripting Edition) és a JavaScript (a Microsoft által JScript-nek nevezett). (Mindkét nyelvvel a Web-oldalak készítésekor találkozhatott az Olvasó.) A WHS lehetőséget biztosít a szkriptek Windows Asztalról történő futtatására, anélkül, hogy HTML-kódba ágyaztuk volna azokat. Könyvünkben nem térünk ki a parancsfájlok létrehozásával kapcsolatos kérdésekre. A szkriptek írása a VBScript , illetve a JavaScript nyelvekről szóló irodalomak tárgya.
A Windows Scripting Host kiválóan alkalmas a nem-interaktív parancssorozatok futtatására, mint például hálózatba való bejelentkezés és adminisztrációs feladatokat végző utasítássorok. A WSH segítségével a parancsfájlokból közvetlenül elérhetjük és kezelhetjük a Windows objektumait: a nyomtatókat, az Excel-táblázatokat, a Registrykulcsokat stb. A Windows Scripting Host a fentiektől eltérő nyelven írt szkriptek futtatását is elvégezi, ha a nyelv létrehozói olyan programot (értelmezőmodult) biztosítanak, amely lehetővé teszi a WSH számára ezen parancsállományok utasításainak értelmezését. A WSH a parancsfájlt soronként olvassa és a sorokat egyenként átadja a szkriptértelmezőnek. A Windows Scripting Host két programból áll: a Wscript (C:\Windows mappa) Windows alkalmazásból, és a (DOS számára írt) Cscript (C:\Windows\Command mappa) konzolprogramból. A Wscript végzi a VBScript és a JScript nyelveken írt parancsfájlok futtatását. A C:\Windows\Samples\WSH mappában néhány VBscript (.vbs, kék színű ikon), illetve JavaScript (.js, sárga színű ikon) nyelvű parancsállomány található. A parancsfájlokat dupla (vagy egyszeri) kattintással, illetve a Start/Futtatás menüpont segítségével futtathatjuk (ekkor a Wcsript alkalmazás értelmezi a parancsfájl sorait). A parancsfájlok tartalmát bármilyen egyszerű szövegszerkesztőben megnézhetjük, illetve megváltoztathatjuk (Jegyzettömb, WordPad). 30
2.13. ábra A Windows Script Host tulajdonságai
A Wscript alkalmazás két beállítható, illetve változtatható tulajdonsággal rendelkezik. Ezek megtekintéséhez parancsfájl nélkül kell elindítani az alkalmazást (a C:\Windows mappából vagy beírva a Wscript sort a Start/Futtatás ablakban). Az indítás után a 13. ábrán látható "Windows Scripting Host" ablak jelenik meg. Az első tulajdonság a másodpercekben megadott időhatár. Erre a beállításra azért van szükség, hogy megakadályozzuk a parancsfájlok végtelen futását. A második tulajdonság bejelölésével azt kérjük, hogy a szkriptek MS-DOS ablakban történő futtatásakor jelenjenek meg a Windows Script Host-ra vonatkozó verzióinformációk. A fenti beállításokat nem csak a Wscript alkalmazás számára adhatjuk meg általánosan, hanem arra is van lehetőség, hogy a gyakran futtatott parancsfájlokhoz a beállításokat egy – szöveges formátumú- konfigurációs állományban (.wsh, ikon) tároljuk. A parancsfájlt ebben az esetben a .WSH állomány kiválasztásával indítjuk (például kattintva a konfigurációs fájl ikonján). A .WSH állományt a scriptfájl tulajdonságlapjainak Parancsfájl oldalán megadott beállításokkal hozhatjuk létre. A Parancsfájl párbeszédablak felépítése megegyezik a 13. ábrán látható tulajdonságlapéval. Az Alkalmaz gombon kattintva a parancsfájlt tartalmazó mappában létrejön a parancsfájllal azonos nevű konfigurációs állomány. A 14. ábra különböző típusú parancsállományokat és WSH beállításfájlokat tartalmaz.
31
14. ábra A Windows\Samples\WHS mappa tartalma
Ha a Jegyzettömbben megnyitjuk WSH konfigurációs állomány, az alábbiakhoz hasonló sorokat látunk: [ScriptFile] Path=C:\WINDOWS\SAMPLES\WSH\SHORTCUT.VBS [Options] Timeout=6 DisplayLogo=1 BatchMode=0
A konfigurációs állomány mindössze két szekciót tartalmaz. A [ScriptFile] szekció egyetlen paramétere (Path) a parancsfájl útvonalát tárolja. Az [Options] szekció Timeout paramétere a parancsfájl futásának időhatárát tárolja másodpercekben (ha ez az érték 0, nincs időhatár megadva). A WSH-verzióinformációk megjelenítését szabályozó DisplayLogo paraméter értéke 1 (megjelenítés) vagy 0 lehet (nincs megjelenítés). Az utolsó, BatchMode paraméter nem érhető el a parancsfájl tulajdonságlapján, így csak a .WSH állomány szerkesztésével lehet megváltoztatni. A paraméter 1-re való állításával azt írjuk elő, hogy a parancsfájl futtatása kötegelt állományként történjen, mellőzve minden felhasználói adatbevitelt, és a hibaüzenetek megjelenítését. 0 érték esetében a parancsfájl interaktív módon hajtódik végre. A Windows Scripting Host másik alkalmazása, a Cscript. segítségével a DOS parancsértelmezőből is kezdeményezhetjük a parancsfájlok futtatását. Ehhez a parancsértelmező elindítása után (Start/Programok/MS-DOS parancssor) a parancssorban elő32
ször meg kell adnunk a Cscript szót, majd pedig a futtatni kívánt parancsfájl teljes elérési útvonalát. Például a már említett C:\Windows\Samples\WSH mappában található példaszkriptek egyikét következőképpen indíthatjuk el a DOS parancsértelmezőben: Cscript C:\Windows\Samples\WSH\Shortcut.vbs
A Cscript alkalmazás hívása során paramétereket is használhatunk, amelyeket // jel, vagy / jel után egyaránt megadhatunk. Az első megadási mód a Wcsript alkalmazással együtt használt WSH tulajdonságok beállítására szolgál, míg a másik a parancsfájlnak küldött paramétert vezeti be. A parancssorból az alábbi opciók adhatók meg: //? //B, //I //H:programnév //logo, //nologo //S //T:nn
A Cscript utasítással kapcsolatos információ megjelenítése, a parancsfájl batch, illetve interaktív módban való futtatásának előírása, az adott típusú parancsfájlok futtatásáért felelős program beállítása, a verzióinformációk megjelenítésének engedélyezése, illetve tiltása, az aktuális parancssor-opciók elmentése alapértelmezés szerinti opciókként, a parancsfájl futtatására vonatkozó időhatár megadása.
33
