Emlékszik még arra az izgalomra, ami a Windows 95 megjelenését övezte? 1995. augusztus 24. – egy dátum, amely sokak számára a személyi számítógépek fejlődésének mérföldkövét jelentette. Végre itt volt egy operációs rendszer, amely grafikus felhasználói felületével, a Start menüvel, a Tálcával és a plug-and-play képességekkel forradalmasította a mindennapi számítógép-használatot. Az egyik legfontosabb ígéret pedig a valódi többfeladatos működés (multitasking) volt. Elméletben egyszerre futtathattunk több alkalmazást, zenét hallgathattunk böngészés közben, vagy épp letöltéseket indíthattunk dokumentumszerkesztés mellett. A valóság azonban ennél jóval összetettebb, sőt, néha kifejezetten frusztráló volt. A Windows 95, bár kétségkívül óriási előrelépést jelentett, hibrid felépítése miatt komoly korlátokkal rendelkezett a multitasking terén, amelyek gyakori összeomlásokhoz és „Kék Halálokhoz” vezettek.
Ahhoz, hogy megértsük a Windows 95 korlátait, érdemes visszatekinteni egy pillanatra az előzményre, a Windows 3.x sorozatra. Ezek a rendszerek még az úgynevezett kooperatív multitasking (cooperative multitasking) elvén működtek. Ez azt jelentette, hogy az alkalmazásoknak maguknak kellett „udvariasan” átadniuk az irányítást a CPU-nak, hogy az más programokat is futtathasson. Ha egy program lefagyott, vagy egyszerűen csak nem volt hajlandó átadni a vezérlést, az egész rendszer megállt. Senki sem kapta meg a CPU idejét, és a gép befagyott. Ez az elavult modell volt az egyik fő oka a korábbi Windows verziók instabilitásának.
A Windows 95 nagy ígérete a preemptív multitasking (preemptive multitasking) bevezetése volt, amely sokkal stabilabb és hatékonyabb többfeladatos működést tesz lehetővé. A preemptív multitasking lényege, hogy az operációs rendszer maga dönti el, melyik alkalmazás mikor és mennyi ideig kapja meg a CPU erőforrásait. Ha egy program túl sokat akarna futni, vagy lefagyna, az OS egyszerűen „elveszi” tőle a vezérlést, és átadja egy másiknak. Így egyetlen rosszul megírt vagy lefagyott program sem húzza magával az egész rendszert. Vagy legalábbis ez volt az elmélet.
A probléma gyökere abban rejlett, hogy a Windows 95 egy hibrid operációs rendszer volt. Nem egy teljesen tiszta 32-bites OS, mint a jóval robusztusabb (és akkoriban jóval drágább és erőforrásigényesebb) Windows NT. A Microsoftnak a DOS-ról és a 16-bites Windows 3.x-ről való zökkenőmentes átmenet biztosítása volt a célja, hogy a felhasználók és a szoftverfejlesztők ne legyenek kénytelenek azonnal lecserélni minden régi programjukat. Ez azt jelentette, hogy a Windows 95-nek képesnek kellett lennie a régi 16-bites programok futtatására is, és itt kezdődtek a komplikációk.
A Windows 95 a 16-bites alkalmazásokat egyetlen megosztott „Virtuális DOS Gép” (Virtual DOS Machine, VDMs) vagy „Virtuális Gép” (VM) alatt futtatta. Ezekben a virtuális gépekben a 16-bites alkalmazások továbbra is a régi, kooperatív multitasking modell szerint futottak. Ha egy 16-bites alkalmazás befagyott, az nem feltétlenül vitte magával az egész rendszert (mint Windows 3.x alatt), de az adott virtuális gépen belül futó *összes* többi 16-bites alkalmazás azonnal leállt, vagy instabillá vált. Ráadásul ezek a 16-bites alkalmazások hozzáférhettek a rendszer alacsony szintű erőforrásaihoz, ami szintén veszélyeztette a stabilitást.
Még nagyobb fejtörést okozott a rendszer két kritikus, megosztott erőforrása: a GDI (Graphics Device Interface) és a USER halmok (heaps). Ezek olyan memóriaterületek voltak, amelyeket az összes futó alkalmazás (legyen az 16-bites vagy 32-bites) használt a grafikus elemek (ablakok, gombok, menük, betűtípusok) és a felhasználói felület interakcióinak kezelésére. A Windows 95 örökölte a 16-bites elődeitől ezeket a mindössze 64 KB-os, rendkívül szűkös, megosztott memóriaterületeket. Bár a Windows 95 maga is 32-bites volt, ezek a kritikus alrendszerek maradtak 16-bitesek a visszafelé kompatibilitás miatt.
Ez azt jelentette, hogy ha túl sok programot nyitottunk meg, vagy ha egy alkalmazás memóriaszivárgással (memory leak) szenvedett, ami folyamatosan elfoglalta a GDI vagy USER erőforrásokat, a rendszer hamarosan kifogyott ezekből a kritikus halmokból. Amikor ez megtörtént, a grafikus felület elemei eltűntek, a programok lefagytak, és elkerülhetetlenné vált a rettegett „Kék Halál” (Blue Screen of Death, BSoD). Még a 32-bites alkalmazások is, amelyek egyébként preemptíven működtek volna, összeomolhattak a megosztott 16-bites GDI/USER erőforrások kimerülése miatt. Ez a korlát volt talán a leggyakoribb oka a Windows 95 hírhedt instabilitásának.
A memóriakezelés is kihívást jelentett. Bár a Windows 95 támogatta a virtuális memóriát és a memória swap-et (page file), ami lehetővé tette, hogy a fizikai memóriánál nagyobb alkalmazásokat futtassunk, ez gyakran vezetett súlyos lassulásokhoz. A merevlemez folyamatos „tekerése” (thrashing) jelezte, hogy a rendszer a memóriatartalom és a merevlemez közötti folyamatos csereberével próbálja kezelni az erőforráshiányt. Ez különösen igaz volt, ha kevés fizikai RAM állt rendelkezésre, ami akkoriban nem volt ritkaság. Sok felhasználó csak 8-16 MB RAM-mal rendelkezett, ami a mai sztenderdekhez képest nevetségesen kevés a többfeladatos működéshez.
További problémaforrást jelentettek az eszközillesztők (driverek). Bár a Windows 95 bevezette a 32-bites, védett módú drivereket (VxD-ket), sok gyártó még mindig a régi, 16-bites driverekkel dolgozott, vagy hibásan írta meg az újakat. Egy rosszul megírt driver könnyedén felülírhatott védett memóriaterületeket, vagy végtelen ciklusba kerülhetett, ami azonnali rendszerösszeomláshoz vezetett, függetlenül attól, hogy melyik alkalmazás futott éppen. Mivel a kernel még mindig nem volt teljesen elszigetelt a felhasználói módú alkalmazásoktól (ellentétben a Windows NT-vel), a driverhibák sokkal súlyosabb következményekkel jártak.
A mindennapi felhasználói élmény tehát gyakran a frusztráció és a türelem próbája volt. Egy átlagos munkanapon nem volt ritka, hogy több alkalmazás futtatása mellett a gép egyszer csak „befagyott”, a kurzor mozgott, de semmire sem reagált, vagy épp a „Kék Halál” köszönt be váratlanul. A megszokott rutin része volt a gyakori mentés, és a „háromujjas üdvözlet” (Ctrl+Alt+Del) elsajátítása, amivel megpróbálhattuk lelőni a fagyott alkalmazást, vagy végső esetben újraindíthattuk a rendszert. A Windows 95 alatt a többfeladatos működés inkább egy folyamatos egyensúlyozás volt a stabilitás és a kényelem között.
Mindezek ellenére, vagy éppen ezért, a Windows 95 egy hihetetlenül fontos átmeneti rendszer volt. Megtanította a felhasználókat és a fejlesztőket a 32-bites, preemptív világ előnyeire, miközben továbbra is biztosította a kompatibilitást a régi szoftverekkel és hardverekkel. A korlátok és a frusztrációk ellenére ez volt az az operációs rendszer, amely széles körben elterjesztette a grafikus felületet, és megalapozta a későbbi Windows verziók sikerét. A Microsoft tanult ezekből a kihívásokból: a Windows 98 még javított valamennyit a helyzeten (pl. a GDI/USER heap-ek optimalizálásával), de az igazi áttörést a Windows 2000 (amely már a robusztus NT kernelre épült) és a későbbi Windows XP hozta el, amelyek végre megszabadultak a 16-bites örökség terhétől, és valóban stabil, preemptív többfeladatos működést kínáltak.
Összefoglalva, a Windows 95 egy bátor, de kompromisszumokkal teli próbálkozás volt a modern többfeladatos működés bevezetésére a tömegek számára. Hibrid architektúrája, a 16-bites örökség, a szűkös GDI és USER halmok, valamint a driverproblémák mind hozzájárultak ahhoz, hogy a rendszer instabilabb volt, mint ahogyan azt sokan remélték. Ennek ellenére a Windows 95 nélkül nem tartanánk ott, ahol ma a számítástechnikában tartunk. Ez a rendszer képezte azt a hidat, amely elvezetett minket a mai stabil, több feladat egyidejű, zökkenőmentes futtatására képes operációs rendszerekhez.
Leave a Reply