Red Flag

Emlékszik még valaki arra a kínai törekvésre, hogy Red Flag néven saját linux disztribúciót hozzanak létre? Nos ez meg is történt akkoriban, ami nem volt túl jó hír a Microsoft-nak. No, de mára megváltozott a helyzet mivel a Red Flag parkolópályára került, a Windows és az MS-Office pedig beelőzött, de jócskán. 

 

Hu Jintao kínai elnök a következőket mondta Bill Gates-nak, amikor nemrég nála járt: "Ön a kínai nép barátja és ezért én a Microsoft barátja vagyok. Minden reggel, amikor bemegyek a hivatalomba az Ön szoftvereit fogom használni"

 

Ugye nem kell hat diploma ahhoz, hogy ebből kikövetkeztessük a történet végét. Mennyi számítógép is lehet a kínai államigazgatásban? Hmm… hmm. Mekkora bevételt (és nem utolsó sorban stratégiai győzelmet) jelent ez a Gates-birodalomnak? Sokat. Nagyon sokat. Még akkor is, ha Kínának olyant 7-10 dollárért adja majd a Windows-t meg az Office-t (tanulóknak pedig mindössze 3 dollárba fog kóstálni).

 

Részletek (angolul) itt.

 

Nem szeretjük Kínát, mert zsarnok, kommunista állam, de valahogy mégis az összes cég kezét-lábát töri azért, hogy oda bekerüljön. Ejj, ez a csúnya kapitalizmus – emberi jogok ide vagy oda. Tegnap hallottam egy üzletembertől, hogy "figyeljük meg, 20 év múlva Kína lesz a világ vezető gazdasági és technológiai nagyhatalma". Miért is nem csodálkozom ezen?

Cool-túra

A "Linux Today" nevű internetes újságban olvastam egy véleményt, mely tartalmát tekintve kissé már unalmas (újfent a linux mitől nem vált még az asztali operációs rendszerek királyává…, blablabla). Az írást követő érvek és ellenérvek között megint rábukkantam egy amolyan igazi ocsmányságra. Ennek ellenére mégis érdemes elolvasni, mert a maga keresetlen modorával jól példázza, hogyan NEM volna szabad beszélni, véleményt nyilvánítani másról, másokról, főleg nem akkor, ha az eredeti hozzászóló udvariasan és jó szándékkal írta azt, amit írt.

 

A hitelesség kedvéért idézem a teljes szöveget (tehát íme egy válasz az eredeti véleményezőnek címezve):

 

"scubadir said…
You are a dumb ass. To say linux is not viable as a desktop tells us all your a typical dumbass. You should sit in the office with the rest of the yuppie dumbass’s wondering why your not paid more and why things arn’t for you. Sure I wouldn’t give linux as a desktop solution to the ladies in hr or reception but for IT guys to get there job done. Get of your lazy ass and learn something. The most basic shell skills make anything in windows look like childs play. So take your bullshit and shovel it to a microsoft site you faggit.."

 

Gyomorforgató és elszomorító. Mint egy durcás óvodás, akinek épp elvették a kedvenc linux-os játékát. "Bebibibűűűű, az enyém jobbb… Nem iiiis, mert az enyém…" – meg ilyesmi. Szóval én egyáltalán nem azt állítom, hogy közülük mindegyik ilyen, de sajnos egyre több hasonlóval találkozom. Igazi Cool-túra.

 

Részletek (angolul) itt.

Lokalizáció újratöltve

Ritkán ugyan, de időről-időre visszatérek egy-egy témára azért, hogy az újabb olvasók is (ha van ilyen egyáltalán) megismerhessék a véleményemet valamiről. Persze megtehetnék, hogy az elejétől kezdve visszaolvassák a korábbi bejegyzéseket, de nem mindenki cselekszik így. Nos, úgy rémlik valamikor már írtam a lokalizációról, de most talán kicsit részletesebben, más szempontok és érvek mentén is szeretném kifejteni ugyanezt. Aki már unja az nyugodtan lapozzon, nem fogok megsértődni (sőt, ígérem nem is fogom megtudni).

 

Ha valaki már részt vett olyan szoftverrendszer kifejlesztésében, amely nemzetközi (vagy vegyes nyelvű) környezetben is kellett működtetni, az tudja mekkora probléma az adott nyelvre való felkészítés, vagy ahogy szaknyelven mondják: lokalizáció. 

 

A problémák sora ott kezdődik, hogy ha olyan régebbi rendszerünk van, amely még nem lett felkészítve a lokalizációs igényekre. Mi is így voltunk ezzel, hiszen a 90-es évek elején, a technológiai alapok letételekor ki a fene gondolta volna, hogy 6-10 év múlva már nemzetközi környezetben is meg kellene felelni (örültünk, ha itthon boldogultunk). Meg különben is ne felejtsük el, hogy több lehetőség nagyobb költség! Ez pedig nem mindig járható út. Na mindegy. Lényeg, hogy meg kell oldani a régebben fejlesztett modulok lokalizációját lehetőleg úgy, hogy a forráskódhoz NE kelljen hozzányúlni. Vagyis magát a szoftvert a lehető legkisebb programozói erőforrás igénybevétele és minimális költség mellett lehessen felkészíteni a lokalizációra. Természetesen új fejlesztéseknél manapság már alapkövetelmény, hogy a tervezéskor eleve gondoljunk a többnyelvűségre is, de régebben ez nem így volt. Nincs rá általános módszer, mivel a feladat végrehajtása erősen függ a technológiától és az alkalmazott fejlesztői környezettől.

 

Következő probléma az eredeti és lefordított szöveg tárolási helye és elérési módja. Itt már számos lehetőség áll a rendelkezésünkre. A legrosszabb, ha annyi forrásverzió van, ahány nyelven működik a szoftver (bár kis programoknál talán mégis elfogadható). A nyelvi elemek lehetnek még dinamikus könyvtárak erőforrásaiban (pl.: Windows alatt fizikailag DLL-ekben), önálló erőforrás-fájlokban (RES, TXT, XML/XSL vagy bármely más formátumban), lehet még adatbázisban (önálló adatbázis-fájl vagy relációs adatbázis), stb. Mi ez utóbbit választottuk, tehát az eredeti szöveg és annak fordításai relációs adatbázisból jönnek (sebességi okokból több szintű átmeneti tárolókba helyezve).

 

Itt kell megjegyeznem, hogy van aki a forráskódban a megjelenítendő szövegeket konstansként tárolja, esetleg csak azonosítókkal hivatkozik rá. Ez azért jó, mert egyszerű és gyors a kezelése, rossz viszont, mert az eredeti szöveg nem látszók a kódban, ami félreértésekhez és bonyodalomhoz vezethet (a képernyőtervezési problémákról nem is beszélve). A mi esetünkben az eredeti, úgynevezett referenciaszöveg van a forráskódban (ami tulajdonképpen a magyar nyelvű szöveg maga), a fordítás pedig a referencia alapján adatbázisból jön. A tárolási helyet és annak kezelési módját az alkalmazott technológia dönti el (más lehet webes, más többrétegű és megint más kliens/szerver alapú vagy monolitikus alkalmazások esetén).

 

Az egyik legnagyobb gond azonban nem az eddigiekben, hanem a képernyők kialakításábaj rejlik. A képernyők, főleg az űrlapos és párbeszéd ablakos felhasználói felületek adott távolságokkal, sor és térközökkel rendelkeznek (pl.: egy szöveges címke és a hozzátartozó adatmező közötti tér). Nézzünk rá egy példát. Egy valaminek az árát feltűntető mező előtt valószínűleg az "Ár:" szövegcímke található. Ugyanez németül már "Preis:" lenne, ami testvérek között is kétszer olyan hosszú (6 karakter). Ha a programozó nem hagy elég távolságot a címke és a mező között, akkor német nyelven bizony problémáink lehetnek. Vagy csonkolódik a szöveg pl.: "Pre"-re vagy rácsúszik a mezőre  és átlapolja azt. Most mondhatnánk azt, hogy: "Jó nagy legyen a távolság, hogy minden nyelvi fordtásnak legyen helye". Aha, még mit nem! Ez meg azzal járna, hogy a képernyő szétesik, nem lehet az egyes mezőket megfelelő módon egymáshoz igazítani. Közérthetőbben fogalmazva úgy fog kinézni minden, mint az ökörh…gyozás. Ezt pedig nem szeretnénk, mert a kinézet, a látvány legalább olyan fontos (néha fontosabb), mint a belső tartalom. Ilyenkor utólag már csak egy valamit lehet tenni, mégpedig azt, hogy fordításkor figyelni az eredeti, referenciaszöveg és az idegen nyelvű szöveg hosszát (ami  lehet angol, német, francia, orosz, stb). Amennyiben a fordított hosszabb lenne az eredetinél akkor, ha nincs elég hely bizony valamilyen módon rövidíteni kell (már, ha lehet).

 

Technikailag már csak azt kell megoldani, hogy a rendszerbe való bejelentkezéskor (vagy amikor szükséges) ki lehessen választani a megfelelő nyelvet. Ja, meg azt is természetesen, hogy a dátum és számformátumok az adott nyelvi szabályokhoz igazodjanak (yyyy.mm.dd vagy dd.mm.yyyy, valamint a tizedes és ezres határolójelek). No meg ügyelni kell arra is, hogy a riportok (melyek nem mindig fordíthatók röptében, futás közben csak statikusan "beégetve") állandóan karban legyenek tartva.

 

Tulajdonképp most már elgedetten hátradőlhetnénk kényelmes fotelünkben legalább úgy, mint Magyarország miniszterelnöke a sokszáz, meg nem valósított, néphülyítő propagandakiadványokban létező úgymond "reformja" után, igaz? Egy frászt! A java még csak ez után jön.

 

Ugyanis ki kell gyűjteni az összes referenciaszöveget (pl. magyar szöveget) minden forráskódból és riportból, majd meg kell szervezni azok fordítását. Most megsúgom a frankót: a tükörfordítás szinte lehetetlen. Ez egyben azt is jelenti, hogy – kigyűjteni és odaadni egy fordítóirodának vagy olyasvalakinek, aki nem tudja mit csinál az adott szoftver ott azon a helyen, ahonnan a fordítandó szöveg jött – enyhén szólva könnyelműség lenne, vagy legalábbis nem oldana meg mindent. Ehhez a munkához olyan fordító kell, aki ott ül a szoftver előtt és nagyjából tudja, hogy az mit csinál. Többé-kevésbé látja a képernyőn lévő helyeket, észleli milyen hosszú lehet a fordítandó szöveg, felismeri, hogy egy adott szó finom eltéréseit az aktuális környezet viszonyában, stb. Mert például a "bizonylatszám" teljesen mást jelenthet egy adott nyelven akkor, ha az egy készlet vagy pénztár bizonylat, és megint mást ha számlaszám (mert amúgy az is lehet bizonylatszám csak kicsit más értelemben) – és ehhez hasonlók. Először mi is fordítóirodának adtuk a referenciaszöveget, de ez arra volt jó, hogy kapjunk egy nagy tömegben elvégzett nyers fordítást, aminek csak egy része használható. Utána minden képernyőn és riporton szinte egyenként végig kellett menni és korrigálni a tükörfordítás hibáit, vagyis a nyelvi eltérések finomságait az adott környezethez igazodva.

 

Érdekességképp mondom, hogy a forráskódból és riportokból kinyert információk alapján nálunk a lefordított szavak, mondatok vagy kifejezések száma 30000 – 50000 között van attól függően, hány modult teszünk bele a kalapba.

 

Még mindig nem pihenhetünk, hiszen hátra van a felhasználói és rendszergazdai dokumentációk fordítása. Ezesetben az eredeti, mondjuk magyar nyelvű dokumentációt már bátran át lehet adni egy külső fordítónak (itt ne 20-30 oldalra tessék gondolni, hanem több ezer oldalnyi vaskos anyagokra). Ne felejtsük el azt se, hogy a dokumentációkhoz mellékelni kell az adott nyelven megjelenő képernyőképeket (az azért mégsem járja, hogy egy angol nyelvű doksiban magyar nyelvű képernyőkivágások legyenek). A fordító elvégzi a dolgát, majd azt egy szakmai zsűri korrektúrázza (ismét csak a szoftver ismeretében).

 

Most akkor végre befejeztük már? … Sajnos még nem. Gondoskodni kell arról a technológiáról és munkafolyamatról is, amely biztosítja az időközben megváltozott és majd a későbbiekben módosuló szoftver nyelvi újdonságainak a rendszeren történő átvezetését (naná, hogy a lehető legkisebb erőforrásigény és költség szem előtt tartásával). A lokalizáció megkezése és befejezése között ugyanis egy adott szoftverállapottal volt dolgunk, de az élet közben tovahaladt, amit viszont nem árt pótolni. Ez így lesz később is, mikor már látszólag befejeződött a lokalizációs folyamat (ami valójában sose ér véget).

 

Nem említettem még (mert nem minden szoftvert érint) az ügyviteli lokalizációt, azaz a szoftver funkcionális módosítását. Erre azért lehet szükség, hogy az megfeleljen az adott ország törvényi és működésbeli elvárásainak. Egy olyan ERP-rendszernél, mint amilyent mi is fejlesztünk ez elvárás, de egy operációs rendszernél, szövegszerkesztőnél vagy egy képet és hangot lejátszó szoftvernél nem annyira.

 

A fentiekhez hozzáadódhat úgy 20%-nyi többletmunka és probléma akkor, ha mondjuk egy "egzotikus" ország nyelvére kell felkészíteni a rendszert (pl.: arab, héber, vietnámi, maláj, esetleg kínai).

 

Végül említést kell tennem a költségekről is. Egy nagyobb szoftverrendszer lokalizációja akár a több milliós nagyságrendet is elérheti. A mi esetünkben az első idegen nyelv lokalizációja kb. 100 – 150 millió forintba került, utána minden további nyelv nagyjából 50 – 80 millió forintot fog kivenni a kasszából. Ebből látszik, hogy nem olcsó mulatság, vagyis jól meg kell gondolni, hogy a költség és a cserébe elvárt eredmény végén vajon haszon jön-e ki.

 

A fentiekből bizonyára kitűnik, hogy a lokalizáció nem úri móka és csupa kacagás, hanem rengeteg erőfeszítés, még több probléma és főleg rengeteg költség. Persze jó lenne, ha önkéntesek ezrei, hosszú tömött sorokban várakoznának a cégünk ajtaja előtt mondván, hogy ők a szabadidejükben fordítani szeretnének. Azt hiszem erre várhatnánk az idők végezetéig. Egyrészt, mert nem "csak" fordításról lenne szó, másrészt többségüknek valószínűleg gőze sincs az ügyviteli fogalmakról, harmadrészt pedig nem hiszem, hogy épeszű ember önként és ingyen elválallna mondjuk egy izgalmasnak távolról se mondható hitelelbírálási rendszer képernyőinek a fordítását. Hát…, így jártunk mi.

Silverlight monopólium?

Amikor ezt olvastam, alig hittem a szememnek.  A Mozilla egyik vezetője azt nyilatkozta, hogy a Silverlight lesz a Microsoft legújabb monopóliuma. Ezen véleményét nagyjából arra alapozza, hogy a Silverlight megjelenésével a fejlesztők elvesztik a választási lehetőségeiket, mivel kénytelenek lesznek majd használni. Érdekes okfejtés, ami tulajdonképpen bármi újra igaz lehet.

 

A Silverlight kétségtelenül többé-kevésbé egyedüli lesz, de a kényszert azért én nem teljesen látom. Mégis, ki a csuda kényszerítené a fejlesztőket arra, hogy használják? Meg különben is, miért nem karolta fel a témát valaki más? Mondjuk a Sun vagy az IBM, esetleg egy nyílt forráskódú csoportosulás? Hoppá! Most látom, hogy az Adobe-nak már eszébe jutott. Apollo kódnéven ő is fejleszt egyet, aminek a végeredménye Adobe Integrated Runtime (AIR) néven fog megjelenni valamikor ezév második felében. Na, de akkor mi a baj a választás lehetőségével? Vagy mi a baj mivel?

 

A Mozilla vezetője azt mondja mindkettő szálka lesz a webfejlesztői közösség szemében. Véleménye szerint nem az a jó megoldás, hogy eldobunk mindent és nekiugrunk egy új technológiának (Apollo vagy Silverlight), hanem a meglévőket kellene tökéletesíteni és fejleszteni. Na persze, mi mást is mondhatana egy böngészőt fejlesztő csapat vezető embere. Mondjuk azt, hogy a Silverlight vagy Apollo fejlesztők elvesztik a rugalmasságukat, bebetonozódnak e két módszer valamelyikébe és utána már nincs onnan visszaút. Lám-lám, mondja is.

 

Részletek (angolul) itt.

 

Nos, szerintem minden új technológia – bárkitől is származik – csakis ad, nem pedig elvesz. Az idő, meg a lehetőségek majd együtt eldöntik melyik lesz tartós. Az biztos, hogy valami kell, ugyanis a web technológia (főleg a ami a felhasználói felület teljesítményét illeti – AJAX ide vagy oda) jelenleg nem megfelelő. Akár azt is mondhatnám, hogy szegényes és nem tudja kielégíteni az üzleti, ügyviteli alkalmazások által támasztott szigorú követelményeket. Reméljük a Silverlight végre megfelelő lesz, de lehet hogy nem. Meglátjuk…

Windows kernel-tervező

Néhány szakértői levelezőlistáin vagy fórumon szoktam időnként olvasni azt az ítéletet, melyszerint a Windows alapvetően és architektúrálisan egy "nagyon rossz" rendszer.

 

Folyton-folyvást a megbízhatóság vagy pl. a vírusok általi biztonság/bizonytalansággal hozakodnak elő, melyek mint tudjuk egyrészt  a harmadik gyártótól származó kernel módú meghjatószoftverek, másrészt pedig az elterjedtség és népszerűség miatt olyan, amilyen. Néha meg mindenféle mondvacsinált műszaki indokkal is előhozakodnak, hogy pl. azért rossz a Windows, mert a grafikus felület az operációs rendszer része, vagy mert lyukas, mint az ementáli, holott szerintem meg épp a "másik" az, amelyik annyi ismert hibát tartalmaz, hogy a Balaton vízhiánya simán pótolható lenne velük. Bagoly mondja…

 

Rengetegszer hivatkoztam már arra (jó lenne ha minél többen megjegyeznék), hogy a Windows tervezését nem félcédulások végzik és gondolom az se véletlen az, hogy annakidején, amikor az NT családot megalkották, sok esetben a Unix-tól vagy épp a VMS-től teljesen eltérő módszereket, megoldásokat választottak (itt meg kell jegyeznem, hogy a Windows9x termékcsaládot csak hobbiszinten tekintem operációs rendszernek, valójában műszakilag értéktelenek a szememben).

 

Az is igaz, hogy mindkét platform, tehát a Unix és Windows is (amikor Unix-ról beszélek akkor ez alatt minden Unix-szerű rendszert értek) sokat tanult egymástól az idők során. Így pl. a Unix (linux, BSD, Mac) fejlesztők is rájöttek arra, hogy ha felhasználókat akarnak szerezni, akkor bizony sok tekintetben "másolniuk" kell a Windows tulajdonságait, illetve a Microsoft is rájött arra, hogy a Unix-szerű rendszereknek is vannak számos jó tulajdonságaik, melyeket egyszer érdemes lenne a Windows-ban is megvalósítani.

 

Ezek az én szememben természetes módon működő folyamatok, melyek nagyon hasonlítanak az évmilliók során végbement törzsfejlődéshez (csak most kevesebb idő állt a rendelkezésre). Mindkét platformnak más volt a célja, melynek eléréséhez más eszközöket használt fel. A Unix-nak (vagy a belőle származó rendszereknek) volt 20 év előnyük a Windows-hoz képest. Ezt a hátrányt a Windows (legalábbis az NT-család) hamar ledolgozta, sőt van amiben jócskán túl is lépett rajtuk. Most egymást figyelik, egymást késztetik arra, hogy egyre jobb és hatékonyabbá váljanak, aminek a megítélése persze lehet akár szubjektív is.

 

Tudom, illő lenne a címben leírt témára rákanyarodni, úgyhogy rögvest így is teszek. Van egy ember, aki a Windows kernel-tervező és fejlesztő csapatban dolgozik: Dave Probert, most róla ejtenék pár szót.

 

Probert titulusa hivatalosan "Architect in the Windows Core Kernel & Architecture team". Többek között ő az az ember, aki sokat dolgozott az NT-kernel tökéletesítésén, vagyis a Windows 2000,  Windows XP,  Windows Server 2003,  Windows Vista és majd a Windows Server 2008 rendszereken. Ezen kívül részt vett számos egyetemi és kutatási projektben is (pl.: Project OZ, Project SPACE UC Santa Barbara). A Ph.D. fokozatát "Electrical & Computer Engineering" témában szerezte meg, és egy rövid kurzus erejéig prof. Kei Hiraki mellett dolgozott  a tokiói egyetemen, Japánban, ahol a "Windows Internals" volt a közös témájuk. Korábban (értsd: mielőtt a Microsoft-hoz ment volna dolgozni), Unix kernel fejlesztéseket végzett, majd néhány évig a "Culler Scientific Systems" vállalat szoftvertervezéssel foglalkozó részlegének az alelnöke volt, ahol természetesen számítógép tervezés volt az egyik feladata (mikrokódok készítése a B1900 rendszerhez). Jelenleg különféle egyetemeken tart előadásokat, főként Windows belső működés témákból.

 

Rajta kívül még jónéhány, hasonló kaliberű embert tudnék felsorolni (pl.: Rob Short "Vice President in Charge of the Team Vista", Darryl Havens "Architect", Richard B. Ward "Architect", Rich Neves "Architect" vagy  Neal Christiansen "Core File System Architect"). Egyik se ma kezdte a szakmát, és amennyire én tudom egyik se idióta vagy félkegyelmű, még ha a túloldalt ezt is szeretnék láttatni (egyébiránt ezt már korábban is jeleztem vala).

 

Ezzel az egész írással csak azt szerettem volna nyomatékosítani, hogy előbb nézzünk körül, aztán óbégassunk. A Windows fejlesztésnél mindennek megvan az oka még ha az esetleg néha üzleti célú is. Azt kijelenteni azonban, hogy nincs meg a kellő szakértelem, hát… hogy is mondjam, enyhén szólva tudatlanság és korlátoltság akár tetszik, akár nem.

 

Egyéb érdekességek:

• Inside the Windows Vista Kernel: I., II. és III. részek.
• Windows Kernel Internals Overview
• Highlights Changes to the Windows Kernel
• Windows Kernel Internals Thread Scheduling
• Windows Server 2003 Kernel Scaling Improvements

Rendszerhívások vagy nem

Vajon meglepődik-e bárki is azon, amikor azt mondom, hogy a Unix (illetve az olyan Unix-szerű rendszerek, mint a Linux, BSD, Minix, stb) és a Windows programozási modellje alapvetően eltér egymástól? Ugye nem. Nos, ezt mindjárt gondoltam.

 

A Unix-os programok bizonyos operációs rendszer szintű "szolgáltatásokat" úgynevezett rendszerhívások (system calls) formájában veszik igénybe. Ezzel ellentétben a Windows-os programok rendes körülmények között inkább eseményvezéreltek, ha szabad itt most ezt a kifejezést használnom. A főprogram (mondjuk így) várakozik egy esemény bekövetkeztére, majd amikor az megtörtént, akkor egy eljárás vagy függvény meghívásával lekezeli azt (azaz végrehajt valamilyen műveletet). Tipikus események lehetnek pl.: billentyűlenyomás, egérmozgatás, egérgomb megnyomása vagy elengedése, floppy lemez vagy pendrive behelyezése, stb. Ezek hatására végrehajtódnak az eseménykezelő műveletek, így pl.: módosul a képernyő tartalma vagy megváltozik a programok belső állapota, meg effélék. Mindezekből az következhet, hogy számos dologra gyökeresen eltérően kell reagálni a Unix-os és a Windows-os rendszereken belül.

 

Nos, nem igaz az, hogy a Windows-ban ne lennének rendszerhívások, természetesen ott is vannak. A Unix-oknál azonban a rendszerhívások (pl.: read) és az úgynevezett könyvtári eljárások közötti kapcsolat (pl.: read – library procedure) majdnem 1:1-ben megfeleltethető egymással, mivel a könyvtári eljáráshívások végén sok esetben rendszerhívások buzgólkodnak. Itt érdemes megjegyezni, hogy a Unix esetén (is) egy rendszerhívás igazándiból kernel szintű művelet, míg a könyvtári eljáráshívás meg alapvetően nem. Másképp mondva minden egyes rendszerhíváshoz hozzávetőlegesen egy könyvtári eljárás passzol. Érdekességképp meg kell említeni, hogy a POSIX szabványban (melyet az összes Unix-szerű rendszer és a Windows is megvalósít) nagyjából 100 eljáráshívás létezik. Csak magyarázatképp mondom, hogy amikor egy könyvtári eljáráson belül rendszerhívás következik be, akkor a hívás idejére felhasználói módból kernel módba kapcsol át a rendszer.

 

Most térjünk vissza a Windows-ra egy picit. Nála a helyzet radikálisan eltérő, legalábbis a Unix-hoz képest, ugyanis a rendszerhívások és a könyvtári eljáráshívások elég erősen szétválnak egymástól. A Microsoft meghatározott egy programozói felületet Win API néven (pl.: Win32 API – Application Program Interface), hogy a programok ezen keresztül vehessék igénybe az operációs rendszer "szolgáltatásait". A Win32 API részlegesen támogatja az összes korábbi Windows verziót is (a Windows 95-től kezdődően). A Microsoft ígérete szerint a rendszerhívások verzióról verzióra történő belső módosulása nem fogja érvénytelenné tenni az újabb programok hívásait (hogy tényleg így van-e, azt mindenki döntse el maga). Természetesen az újabb Windows verziókkal újabb eljárások kerülhetnek be a rendszerbe, de ezek normális esetben nincsenek hatással régebbi programok működésére.

 

A Win API eljárásainak száma különösen nagy, elérheti az ezres nagyságrendet is. Közülük jónéhány rendszerhívásba torkollik, azaz kernel módú (kernel spaces) rendszerhívás lesz belőle, mások pedig teljesen megmaradnak a felhasználói módban (user spaces). Ezek következtében szinte lehetetlen tudni, hogy mely eljáráshívások rendszerhívások és melyek nem. Lehet, hogy ami az egyik verziónál kernel szintű rendszerhívás volt, az a másiknál egyszerű felhasználói módú eljáráshívás lesz vagy fordítva. Ettől függetlenül a Microsoft garantálja, hogy ezek minden alkalommal stabilan fognak működni.

 

Azonban a Unix-szerű rendszerek esetén  is van bonyodalom bőven, vegyük például a GUI – azaz grafikus környezeteket (X Window, Motif, stb). Ezek teljes mértékben felhasználói módban működnek (kliens/szerver architektúra szerint), és rendszerhívások (pl.: write) szükségesek ahhoz, hogy megváltoztassák a képernyő tartalmát, vagy végrehajtsanak más fontosabb műveleteket. Természetesen pl. az X Window is nagyszámú könyvtári eljáráshívással rendelkezik, de ezek bizonyos értelemben nem tekinthetők rendszerhívásoknak.

 

Ezzel ellentétben a Windows Win API (ennél a pontnál azok kedvéért, akik már elbóbiskoltak gyorsan leírom, hogy a Windows és az X Window nem ugyanaz a dolog) nagy számú ablakkezelő eljárást tartalmaz, így pl.: geometriai alakzatok rajzolásához, szöveg megjelenítéshez, betűtípusok kezeléséhez, gördítősávok és párbeszéd ablakok megjelenítéséhez, menükhöz vagy más grafikus műveletekhez. Bizonyos mértékig a grafikus alrendszerek kernel módban működnek (ami igaz néhány Windows verzióra, de nem mindegyikre), tehát számos hozzátartozó eljárás rendszerhívásokra alapul, más része viszont egyszerű, felhasználó módú könyvtári eljáráhívás.

 

Érdekességképp nézzünk meg néhány egymáshoz párosított rendszerhívást a Unix és Windows lehetőségei közül:

 

Unix      Windows              Leírás                                           

fork      CreateProcess        Új folyamat létrehozása

waitpid   WaitForSingleObject  Várakozás a folyamat befejezésére

execve    –                    Program indítás (CreateProcess = fork + execve)

exit      ExitProcess          Folyamat futásának befejezése

open      CreateFile           Fájl létrehozás és/vagy megnyitás

close     CloseHandle          Fájl lezárás

read      ReadFile             Fájlból történő adat olvasás

write     WriteFile            Fájlba történő adat írás

lseek     SetFilePointer       Fájlmutató mozgatása

stat      GetFileAttributesEx  Fájl tulajdonságok kinyerése

mkdir     CreateDirectory      Új alkönyvtár létrehozása

rmdir     RemoveDirectory      Üres alkönyvtár megszűntetése

link      –                    Fájlmutató létrehozása (csak a Windos-NT vonal tudja korlátozottan)

unlink    DeleteFile           Létező fájl törlése

mount     –                    Kötet felcsatolása (csak a Windos-NT vonal tudja korlátozottan)

umount    –                    Kötet leválasztása

chdir     SetCurrentDirectory  Munkakönyvtár-váltás

chmod     –                    Könyvtár és fájl jogok (csak a Windos-NT vonal tudja)

kill      –                    Folyamat megszűntetése jelek küldésével (a Windows nem így működik)

time      GetLocalTime         Aktuális rendszeridő lekérdezése

 

Egy kis magyarázat a fentiekhez, de csak röviden: A CerateProcess létrehoz egy új folyamatot, valójában tehát kombinálja a Unix-ban lévő fork és execve rendszerhívásokat. Számos paramétere van, melyek a létrejövő új folyamat jellemzőit befolyásolhatják (egyébként korábban ezt már jól kibeszéltük azt hiszem). A Windows-ban nincs szigorúan vett folyamat hierarchia, a Unix-ban igen (mivel léteznek szülő és gyermek folyamatok). A WaitForSingleObject egy folyamathoz kapcsolható esemény bekövetkeztére várakozik, mely többféle is lehet. A paraméterében meg lehet adni egy folyamat azonosítót, amelyikre a hívó várakozni szeretne. A munka végeztével egy folyamat befejezéséhez az ExitProcess rendszerhívást kell végrehajtani. Az utána következő rendszerhívások funkcionálisan hasonlítanak a Unix-ban lévő társaikhoz, habár a paraméterezésben azért lehet eltérés közöttük. Mégis, a fájlok megnyitása, lezárása, írása és olvasása egészen sok egyezést mutat. A SetFilePointer és a GetFileAttributesEx rendszerhívások a fájlmutatót állítják be és fájl jellemző tulajdonságokat (attribútumokat) kérdeznek le. Az eljárások, függvények végére biggyesztett "Ex"  az "extended" (kiterjesztés) rövidítése, vagyis egy meglévő eljárás kibővítése új néven. Windows alkönyvtárak létrehozására a CreateDirectory, megszűntetésére pedig a RemoveDirectory szolgál. Az aktuális munkakönyvtár beállítását a SetCurrentDirectory hívással lehet véghezvinni, a számítógépen beállított rendszeridő pedig a GetLocalTime hívással kérdezhető le.

 

A régebbi Win API-ban még nem voltak meg a lehetőségek fájlmutatók (link-ek) létrehozására, fájlrendszerek, kötetek felcsatolására (mount-olására) vagy legalábbis nem olyan egyértelműen (a Windows-NT ágon a POSIX vagy Vista használatakor, illetve új partíció létrehozásakor van lehetőség erre, de azért nem teljesen egyenértékű a Unix-nál megszokottakkal). Ezen túlmenően a Windows nem kezeli a Unix-okban megszokott jelzéseket (signal-okat), mivel ez ismeretlen a számára, valamint nem lehet biztonsági "rwx" fájl vagy könyvtár tulajdonságokat sem állítani benne. Ugyanakkor a Windows eseményorientált és az NT-ág már az elejétől fogva beépítve kezeli az ACL (Access Control List) biztonsági tulajdonságokat. Sőt, a Win API-ban nagyszámú egyéb eljáráshívás van, ami a Unix-okban nem létezik (különösen igaz ez a grafikus alrendszer kezelésére) és ugyanez fordítva is igaz.

 

Azért az kimondható, hogy a Win API nem olyan rettenetesen egységes és következetes interfész. Ennek oka elsősorban az, hogy meg kellett őriznie a visszafelé való kompatibilitását az előző rendszerek felé (bizonyos esetben még akár a régi, 16-bites Windows 3.x rendszerek felé is). Nyilvánvaló, hogy ennek a fránya visszafelé való kompatibilitásnak valamilyen szintű megtartása sose lehet tökéletes, és az is biztos, hogy egy idő után az egész rendszerre nézve igen nagy hátránnyal jár.

 

Így a végefelé újfent meg kell említenem, hogy a Windows (legalábbis az NT-vonal) alkotói olyan emberek voltak, akik tudták, hogyan épül fel és miként működik a Unix, mégsem egy annak megfelelő rendszert építettek. Ezt azért jó lesz észben tartani. Egy újabb Unix-szerű rendszer ugyanis nem vitte volna előre a világot – bármilyen furcsának is tűnik most ezt így kimondani.

 

Mint már annyiszor, ismét el kell mondanom, hogy ezen gondolatok egy része nem az én kútfejemből patant ki, viszont kellő szakirodalom (pl. a már régebben is említetttt "Modern Operating Systems") áttanulmányozása után az ember képes lesz tényeket leírni és következtetéseket levonni. Most is pontosan ugyanígy történt… remélem nem hiába.

Microsoft Office Communicator 2007

Ez az Office ugye már nem az az Office…

 

"Kiadásra kész állapotba került és még ezen a héten megkezdődik a Microsoft internettelefon szoftverének és szerverének sokszorosítása. Az Office Communications Server (OCS) 2007 szerver és az Office Communicator 2007 kliensprogram várhatóan 6-8 héten belül kerülhet az üzletekbe." 

 

Részletek itt.

Visual Studio 2008 és .Net Framework 3.5 második béta

Bárcsak több időm lenne, akkor legalább ezzel is tudnék foglalkozni.

 

"A Microsoft kiadta az év végére ígért Visual Studio 2008 fejlesztői környezet második bétaváltozatát, amelyben már Silverlight alkalmazások fejlesztéséhez szükséges eszközök is helyet kaptak. A vállalat szóvivője szerint a Visual Studio 2008, kódnevén az Orcas már 99 százalékos készültségi szintet ért el. A VS2008 Beta 2-vel egyszerre megérkezett a .Net Framework 3.5 második bétája is." 

 

Részletek itt.

Versenyezzetek és győzzetek!

Az imént olvastam egy felettébb érdekes beszámolót. Ha valakinek eddig nem volt világos, hogy mi a siker kulcsa, akkor ebből kiderítheti.

 

"Ballmer abban látja a különbséget például az IBM és a Microsoft között, hogy az IBM kivonul azokról a piacokról, amelyeken "megverték" (értsd: eltervezett időn belül nem eléggé nyereséges.) A Microsoft viszont nem adja fel. Alapos volt az előkészítés, oka volt a belépésnek – a döntés tehát hosszú távú. Az Xbox nyereséges lesz, ahogy a Zune és a többiek is. Lehet, hogy nem ma, az is lehet, hogy nem holnap, de "jövünk és jövünk és jövünk és jövünk" – hogy őt idézzem. Steve szerint minden korábbi és jelenlegi versenytársunktól az különbözteti meg a Microsoftot, hogy az MS nem fél megváltozni és nem fél belépni olyan arénába, ahol még nincs tapasztalata. Továbbá: a Microsoftnak van türelme és kitartása győzni.

[…]

…volt Ballmer előadásának még egy fontos vonatkozása: a lelkesítés. Magyarországról nézve ez visszatetszőnek tűnik, pedig teljesen érhető. Egy hadvezér is lelkesítő szónoklatot tart a csata előtt, mi mást tenne egy üzleti vezető. Itt és most találkozik az embereivel. Ezért megköszöni a munkájukat, kezet fog velük, átöleli őket (berohan a tömegbe, mint Ballmer), bíztatja a csapatot: versenyezzetek és győzzetek!"

 

Részletek itt.

Európa rászáll az Intelre

Rászállnak ezek mindenkire, aki egy picit is erősebb a többinél (pedig az Intel is saját erőből vált ilyenné). Most az AMD miatt áll a bál.

 

"Az Európai Bizottság (EB) hivatalos vizsgálatot indít az Intel ellen – jelentette a Reuters. Brüsszel gyanúja szerint a világ legnagyobb processzorgyártója törvénytelen módon korlátozta a versenyt a piacon." 

 

Részletek itt.

Megválna a Thunderbird-től a Mozilla

Kíváncsi leszek hányan szeretnének majd "ráugrani" a projekre…

 

" A Mozilla munkatársai levennék óvó szárnyaikat a Thunderbird-ről, és másokra bíznák annak fejlesztését, hogy az a továbbiakban ne hátráltassa őket munkájukban." 

 

Részletek itt.

SQL Teljesítményfokozás-VI.

Nemrég beszélgettünk a WHERE feltételben rejlő lehetőségekről. Most haladjunk tovább a rendezettséget szabályozó ORDER BY művelet irányába, hátha akad ott is pár hasznos tudnivaló.

 

Jobb, ha időben tisztázzuk azt, hogy a rendezés nem fogja felgyorsítani a lekérdező műveleteinket sőt…, épp ezért csak akkor használjuk, amikor ez indokolt és már végképp elkerülhetetlen.

 

Általában kétféle (de lehet, hogy több) algoritmus működik a rendezés során. Az egyik az úgynevezett "címkerendezés", amelyben az adatbázis-kezelő csak a kiválasztott részeket hasonlítja össze (főként nagy sorméret és kis oszlopméret esetén). Ezesetben a rendezés a memóriába való betöltéssel kezdődik, minek következtében nem kerül sor a teljes fizikai sor újbóli beolvasására (dinamikus és nagy memóriafoglalási megterhelést jelent). Létezik ennél egy jobb módszer is, amit "kieséses rendezésnek" hívnak. Azonban ez utóbbi megoldás se mutat fel értékelhető teljesítménynövekedést akkor, ha az adatok már valamennyire rendezett állapotban vannak. Ugyanis a rendezés végrehajtásához szükséges idő csak igen kismértékben múlik a bemenő adatokon, mivel nagyrészt más tényezők döntik el.

 

Na, de ha más tényezők döntenek, akkor melyek is azok? Íme lássuk hát a legfontosabbakat:

• a rendezésben résztvevő sorok száma,
• az ORDER BY utasításban szereplő oszlopok száma,
• valamint az ORDER BY utasításban szereplő oszlopok hossza (méreteinek összege).

Nagyjából így néz ki tehát a helyzet. Vagyis ménél több sort érint a rendezés, vagy minél több oszlop szerepel a rendezettségi listában, esetleg az egyes oszlopok méretének összesenje is túl nagy lesz, akkor bizony a rendezés ideje nem várt módon növekedhet. Nincs más dolgunk, mint figyelni arra, hogy a fentebb leírtak káros hatásait a lehető legjobban csökkentsük. A továbbiakban nézzünk meg néhány érdekes példát, illetve optimlizálási lehetőséget.

 

Bármilyen furcsa, de a rendezendő oszlopokban található részleges egyezés, vagyis amikor a rendezendő oszlopoknál több sorban is közel ugyanazok az értékek szerepelnek (mondjuk egy karakterlánc elején), akkor az bizony lassítja a rendezést. Ha az egyes soroknál a rendezendő oszlopok tartalma eltérő, akkor attól lényegesen felgyorsulhat a rendezés (ELŐNY: 5/8, azaz nyolc rendszerből 5 gyorsabban dolgozna emiatt).

 

Ha az előző példa nem is, de az viszont már elég egyértelmű lehet, hogy egy valamilyen szintű előzetes rendezettség nagymértékben gyorsíthatja a rendezést (ezesetben az ELŐNY: 4/8, ami nem olyan rossz).

 

Amikor arról beszéltünk, hogy a rendezés sebességét az egyes rendezendő oszlopok hossza is befolyásolhatja (azaz minél hosszabb, annál lassabb), akkor ne felejtsük el, hogy itt a deklarált és nem a tényleges hosszról van szó. Tehát, ha van egy VARCHAR(30) hosszúra deklarált oszlopunk, amiben csak mondjuk az "ABC" (azaz 3 karakter hosszú) adat van, akkor nem a tényleges 3, hanem a deklarált 30 az, ami számít! Na, mindenesetre jó lesz ezt észben tartani adatbázis-tervezés közben, nem igaz? Nézzük mi van még…

 

Általánosan kimondható, hogy egy INTEGER típusú oszlop rendezése gyorsabb, mintha annak a típusa SMALLINT lenne. Azért, mert az INTEGER típus tárolása ma még 32-biten történik, míg a SMALLINT csak 16-bitet igényel. A számítógép architetúrák elrendezése miatt (32-bites rendszereken) a számok úgynevezett "szóhossza" 32-bites, vagyis az INTEGER jobban illeszkedik erre (ELŐNY: 5/8).

 

Az előző gondolatmenetet folytatva kimondhatjuk azt is, hogy az INTEGER típusú oszlopok rendezése gyorsabb, mint a CHAR típussal rendelkezőké.

 

Halmazok esetén pedig nem árt tudni, hogy az egyszerű halmaz jobb, mint az olyan többszörös halmaz, amiben előfordulhatnak azonos (tehát ismétlődő) elemek. Ez utóbbi esetben sajnos a rendezés sebessége sokkal-sokkal lassabb is lehet, mint azt mi szeretnénk.

 

Feltétlenül érdemes utána nézni annak is, hogy egy adott rendszeren belül a NULL érték hogyan viselkedik. Van olyan adatbázis, ahol a NULL "magas" értéknek felel meg, máshol "alacsonynak" (növekvő, csökkenő rendezéskor), de az is lehet, hogy a rendezés irányától függetlenül mindig a lista "végére" kerül. Ha NULL érték esetén állandó helyezést szeretnénk, akkor az adott oszlopnál (amelyik NULL-t is tartalmazhat) az adatbázis-kezelő rendszerbe beépített NULL-érték függvényekkel ez a helyzet szabályozható. Mielőbb érdemes azt is megnézni, hogy az aktuális adatbázis-kezelőnél milyen egyéb korlátozások vagy szabályok vonatkoznak a rendezésekre.

 

Újfent kijelentem, hogy ezek a tanácsok nem fogják meghozni a világbékét, sőt még a szegénységet se lesznek képesek feszámolni, hovatovább a pénztárcánkat se tudják felhízlalni (legalábbis közvetlenül semmiképp). Ugyanakkor néha, egy bizonyos döntési helyzetben talán mégis segítenek az arra érdemesnek. Ettől függetlenül körültekintően és megfontolva kell alkalmazni őket, hiszen közülük egyik se csodaszer.

 

Folytatjuk…

Kliens oprendszer-piac

Kimondhatjuk, hogy az utóbbi években a kliens oldali operációs rendszerek eloszlása érdemben semmit se változott. Legfeljebb a Windows erővonalak rendeződnek át, illetve a Mac OS X harcolt ki magának némi pozíciót. Hozzáteszem ez a Net Application felmérése az interneten fellelhető gépekre vonatkozott, de azt hiszem ezek az értékek nyugodtan kivetíthetők az összes többire is.

 

 

Vajon a linux melyik sávban osztozkodik másokkal együtt a dicsőségen? (elárulom: 2.33% – Other)

 

Részletek itt.

Égő arcok a Mozillánál

Semmi meglepő sincs ebben. Majd mindegyiknek ilyen böszme nagy arca van… 

 

"A hiba napvilágra kerülése óta mindkét oldal a másikat okolta a biztonsági résért, majd a Mozilla lépett elsőként, és módosított a Firefox böngészőn. Az Internet Explorer URL-kezelési hibája azonban ettől függetlenül továbbra is fennáll. A Mozilla eddig úgy vélte, hogy ez a hiba csak az Internet Explorert érinti, de most felfedezték, hogy a Firefox sem viselkedik másként bizonyos esetekben. A javított Firefox megjelenési időpontja egyelőre ismeretlen."

 

Részletek itt.

Folyamatos különbség

Elgondolkodott már valaki azon, hogy milyen különbségek vannak a Unix/Linux/Minix/BSD/Mac OS X, stb és a Windows rendszerekben meglévő folyamatok (processes) között? Mert én igen. Magukról a folyamatok értelméről nem fogok szót ejteni, hiszen azt már millió könyv és cikk megtette helyettem. Most inkább csak a különbségekre és a hasolóságokra szeretném felhívni a figyelmet.

 

Mint tudjuk egy Unix-szerű rendszeren belül (mondjuk egy C vagy C++ program sorai között) a fork() rendszerhívás hajtja végre az új folyamat (process) létrehozását. Nomen est omen, azaz a név kötelez. A "fork" tehát a nevének megfelelően egy új folyamatot (vagyis elágazást) hoz létre. Ebben a közegben a létrehozó folyamatot szülőnek (parent process), a létrehozottat pedig naná, hogy gyermeknek (child process) nevezzük. Ez a rendszerhívás gyakorlatilag leklónozza a szülőfolyamatot, annak minden hasznos részével együtt (memória tartalom, nyitott fájlok, regiszter tartalmak, környezeti változók, stb), de elkülönített memóriaületen. Ez utóbbinál mi sem természetsebb, hiszen a két folyamat a futás ideje alatt nem zavarhatja egymást. Ezt követően az újonnan létrehozott gyermekfolyamat végrehajt egy execve() rendszerhívást vagy valami hasonlót, hogy megváltoztassa a saját memóriaterületét vagy elindítson egy új programot.

 

Például, amikor a felhasználó begépel egy sort parancsot, akkor a parancsértelmező (shell) folyamat létrehoz egy új gyermekfolyamatot (azaz "fork"-ol), majd ezt követően már ez az új gyermekfolyamat fogja elindítani a sort programot (ami viszont végrehajtja a rendezést). Ennek a kétlépéses módszernek az az oka, hogy a rendszer időben lehetővé tegye a gyermekfolyamat számára a szülőtől örökölt fájl leíró mutatók módosítását, még az execve() rendszerhívás és annak a standard input, standard output és standard error átállítása előtt.

 

Ezzel ellentétben a Windows-ban egy egyszerű Win32-es (Win64-es) CreateProcess() függvényhívás kezeli mindegyik folyamat létrehozást, illetve a megfelelő program betöltését az újonnan létrehozott folyamatba. Ennek a függvényhívásnak nagyjából 10 paramétere van (a fork-nak egy sincs), melyek között szerepel a végrehajtandó program neve, a parancssori paraméterek, biztonsági paraméterek, nyitott fájlok öröklésére vonatkozó bitek, prioritási információk, ablaklétrehozási adatok (már, ha ez szükséges), és egy mutató arra a struktúrára, amely segítségével az új folyamat információkat adhat át a hívónak. Ezen kívül a Windows API tartalmaz még legalább 100 egyéb függvényt is a folyamatok kezelésére, szinkronizálására és egyéb kapcsolódó témakörökre.

 

Mindkét, tehát a Unix és Windows esetben egyaránt a folyamat létrehozása után a szülőnek és gyermeknek saját memóriaterülete van. Ha valamelyik folyamat megváltoztatja azt, a másik nem láthatja a módosulást. A Unix-nál a gyermekfolyamat kezdeti memóriaterülete szülőével megegyező, de attól eltérő címen helyezkedik el. Nincs közös, megosztott memóriaterületük (bár néhány Unix változatban a két folyamat programódjának lehet közös része, de azt egyik se módosíthaja). A Windows-ban a szülő és gyermekfolyamatok memóriaterülete már a kezdetekben is eltér egymástól.

 

A Unix-ban egy folyamat és annak összes gyermeke, illetve további leszámazottai együtt egy folyamatcsoportot (process group) alkotnak. Amikor például egy felhasználó egy jelet (signal) küld mondjuk a billentyűzet leütésének hatására, az a jel megérkezik a folyamatcsoport összes olyan tagjához, akik társítva vannak a billentyűzet eseményekhez. A jelet bármely folyamat elkaphatja, figyelmen kívül hagyhatja vagy valamilyen alapértelmezett tevékenységet is végezhet a hatására. Ez a folyamathierarchia egyik jellemzője. A Unix-ban létezik egy különleges, init folyamat, ami rendszerbetöltéskor jön létre. Rögtön ezután például megnézi, hogy hány terminál kapcsolódhat a rendszerhez, majd ezek számának megfelelően annyi gyermekfolymatot hoz létre ("fork"-ol), ahány terminál létezhet. A későbbiekben például ezek a gyermekfolyamatok fogják majd figyelni és kiszolgálni az egyes felhasználók bejelentkezési kéréseit. Amikor egy felhasználó sikeresen bejelentkezett, a hozzá társított "login"-folyamat végrehajt egy parancsértelmezőre vonatkozó utasítást. Ezek az utasítások vagy parancsok újabb folyamatokat indíthatnak és így tovább. Ennélfogva tehát az összes így létrejött folymat a teljes rendszeren belül egy faszerkezetet alkot, melynek tulajdonképpen a legelső, init folyamat a gyökere (őse).

 

Ezzel ellentétben a Windows-nál nem létezik ilyen szigorúan vett folyamathierarchia. Nála minden folyamat egyenlő (fő a demokrácia). Talán csak egy hely van, ahol némi hierarchia azért mégiscsak felfedezhető, ez pedig az, amikor egy új folyamat létrejön. Ezesetben a szülőnek lesz egy különleges kezeelője (ezt hívjták handle-nek), mellyel felügyelheti a gyermekfolyamatát. Ez a kezelő azonban szabadon átadható más folyamatnak is, ami viszont ettől kezdve érvényteleníti a jó kis folyamathierarchiát. A Unix-ban a folyamtok alá-fölérendeltsége utólag nem változtatható meg.

 

Ugye milyen érdekes? Sok a hasonlóság, de még több a különbözőség. Végül is a Microsoft is csinálhatta volna annakidején pontosan ugyanúgy, ahogy a Unix (a Windows POSIX interfészében tán létezik is), és mégse tette. Talán a VMS és Dave Cutler hatása…