Vlákno názorů k článku
Programujeme OS: jak na GDT a IDT

Podle mého tohle není programování. Snad kódování, ale ještě spíš jakási bastlírna udělátek.

Ke skutečnému programování OS – a vlastně čehokoli jiného – vůbec není zapotřebí počítač, přinejmenším ne v první fázi. Především je třeba si ujasnit cíle, oč se vlastně snažíme a proč, pak zvolit rámcově, bez velkých technických detailů realizační cesty, a pak až snad někde úplně v závěru to nějaký dobrák může převést do kódu – to už je to nejmenší.

Ten váš kód možná bude nakonec operační, systém to ale nebude docela určitě a to co provozujete bych programováním určitě nenazval. Ne v roce 2009.

Mohu se zeptat, kolik funkčních OS za sebou máte? Autor seriálu má minimálně 1 cvičný, který sice není určitě ve finální verzi, ale dovedu si představit, že i tak by se již dal k něčemu použít. Stačí se obtěžovat a zkusit. Je volně k dispozici. Je pravděpodobné, že jste typický žvanil teoretik, který umí sice básnit o tom jak by to mělo vypadat, ale ve skutečnosti má problémy do hloubky chápat jak vůbec funguje třeba procesor. Znám takové, učí někdy i na vysokých školách. Autorovi článku musím ale také vyčinit. Tento díl je opravdu zmatený – chtělo by to před zveřejněním dát článek někomu přečíst. Chápu úmysl napřed objasnit jak některé věci vespod fungují(čtenář má pak prostředí, kde může experimentovat s procesorem a hw než začne opravdu dělat OS), ale ůvodní nastínění cíle – třeba co vše má náš OS umět a jak toho dosáhnout – by určitě neškodilo.

Co se týče opravy gramatických chyb, apod., tak každý článek procházi přez korekturu, kde se změní některá slova, opraví příp. hrubky, popř. formátování – toto už ale na starosti nemám. Tento článek byl hotov už před více jak týdnem, ale z nějakého důvodu se spozdil, kdybych s tímto textem mohl mezitím manipulovat i po vložení do redakčního systému, určitě by to nepřišlo na škodu.

Když to bude navrhovat člověk, co to neprogramuje, tak to dopadne tak, že do návrhu dá věci, co jdou obtížně naprogramovat, věci, co nejsou potřeba, věci, co jsou vedou k bugovitosti nebo pomalosti apod.

Rozdělením práce na návrh, analýzu a kódování uděláš firemní informační systém, ale nic složitějšího ne.

Samozřejmě rozdělení projektu OS na návrh, analýzu a kódování má velmi dobrý důvod. Když se to neudělá, tak vznikne bastard typu prvních verzí Linuxu. Návrhy obecně bez ohledu na konkrétní projekt musí dělat někdo, kdo věci rozumí. V případě OS by to měl být senior developer se zkušeností v oboru. Příkladem budiž David Neil Cutler, designer zřejmě nejúspěšnějšího systému na světě (Windows NT). Jeho zkušenosti z RSX-11M, VMS a VAXELN byly dobře využity.

:-D

Tomu jako fakt sám věříte, nebo jste jen chtěl vyprovokovat flame?

Věřím čemu? Že by se měl u OS provádět design s tužkou v ruce, a ne s editorem zdrojáku? Tomu samozřejmě věřím. Že David Cutler je příkladem člověka, který je schopen OS dobře navrhnout? Ano, tomu také věřím. Že Windows NT je zřejmě nejúspěšnější systém na světě? Můžeme o tom diskutovat, ale podle mě to tak je. Vezměte si množství instalací Windows desktopů a serverů. Jestli se s tím může měřit někdo jiný, rád se dozvím podrobnosti.
Možná narážíte na ty první verze Linuxu. Ty ale byly opravdu hrozné. Linus psal terminálový emulátor, a u toho občas přepsal nějaké API starých UNIXů podle jejich dokumentace. Nakonec spatlal monolitický kernel s podporou až 64 procesů a s hromadou kódu v ASM, nad jehož designem by slabší jedinci mohli zvracet. Teprve léta šlechtění (Linuse i Linuxu) vedly k zavedení portability, kernelových modulů, částečné preempce kernelu (PREEMPT_VOLUNTARY je tuším až v kernelu 2.6, PREEMPT je dodnes v produkci nepoužívaný a nepoužitelný), multithreadingu atd. Přitom stačilo na začátku navrhovat a plánovat, a nebylo by pak nutné řadu věcí přepisovat. Implementace preempce kernelu nebo multithreadingu je logicky daleko složitější, když se pro ní rozhodnete až po pár letech. I dnes by řada věcí na kernelu zasloužila přepsat, ale čím déle se to odkládá, tím víc to pak bolí.
Nevěříte? Méně věřte legendám, a více faktům. Přečtěte si třeba zde: Linus představuje Linux, srovnání Linuxu a FreeBSD tady na rootu. Podívejte se na historii preempce kernelu (PREEMPT_VOLUNTARY byla pěkná řezničina), nebo na multithreading (vycházel původně z volání clone()). Srovnání architektury Linuxu se Solarisem nebo NT vyznívá pro Linux dost mizerně. Ale vyprávějte to lidem, pro které je operační systém náboženstvím.

To, že se kód zahazuje a přepisuje, dělají všichni vývojáři, i Microsoft. Ještě před 10 lety dodával na desktopy Windows 98 a ME, které neměly ochranu paměti (a daly se shodit dvojicí instrukcí CLI;HLT). A ještě před 20 lety byl běžný DOS. A současné Windows DOSové a Win16 programy stále pouští, ale kód byl zcela přepsán.

A třeba první Apple uměl pustit jen jeden program, pak to začalo uživatelům vadit, tak udělali možnost pustit víc programů, stále jim vadilo, že si ty programy mohou lézt do paměti, tak přešli na OS X.

Ty nedostatky starých systémů nejsou dány blbostí návrhářů, ale tím, že tehdy byly na systémy jiné požadavky. Apple měl požadavek, že musí běžet ve 128kB RAM, tak víc programů ani ochranu neimplementovali. To, že se od té doby paměť stala levná a uživatelé začali chtít víc programů, za to původní návrháři nemohou a nejde jim to dávat za vinu. Stejně tak v době Windows nebyl potřeba preemptivní multitasking nebo ochrana aplikací, tak tam nebyl implementován. Stejně tak Linus v roce 91 řekl, že víc než 64 procesů, každý s 64MB, není potřeba, tak víc neimplementoval. Bylo by možno na tehdy dodávaných Windows 3.1 pustit 64 procesů a mohl tam proces alokovat 64MB? … ale ono to je jedno, protože tehdy to žádný uživatel nechtěl

Windows NT nejsou „zahozením a přepisem“ DOSu, ale prostě jiný koncept. A nedostatky původního Linuxu jsou zjevně dané právě tím, že žádný návrh neproběhl. Bohužel jako se DOS těžko dá inkrementálně přepsat na NT, podobně je těžké z Linuxu udělat lepší OS. A proto je třeba na začátku navrhovat kvalitně.
V roce 91 byly ve vývoji Windows NT (stejně jako Linux), a na rozdíl od Linuxu byly od začátku navržené daleko lépe.

V roce 91 byly ve vývoji Windows NT (stejně jako Linux), a na rozdíl od Linuxu byly od začátku navržené daleko lépe.

To je jasne, ze windows NT jsou lip udelane… to, ze jdou provozovat jenom na domacich pocitacich a servrech vypadajicich jako lepsi domaci pocitace byl zamer hlavniho architekta…

O nadrazenosti NT architektury vypovida i jeji masivni nasazeni v mobilnich telefonech i na pocitacich z top500!

… a na rozdíl od Linuxu na většině tehdejších počítačů nemohly běžet. Já jsem měl 486 s 4 a později 8MB RAM (až v roce 98 jsem koupil Pentium s 32MB). Na střední školy byly 386–486 s 1–4MB (pouze server měl 16MB a běžel na něm Novell). NT měly víc featur než tehdejší Linux, ale ty featury jsou člověku na nic, když NT mu na počítači neběží a Linux ano.

NT coby produkt měly GUI, což je proti kernelu Linuxu s přibaleným shellem poměrně náročná záležitost. O stavbě vlastního kernelu ale HW náročnost celého OS moc nevypovídá.

Windows 3.x měly úplně stejně vypadající GUI jako NT 3.x a potřebovaly 1MB na provoz. Takže GUI samotné za to nemůže.

Jen příklad, vezměme si ovladač, který nedělá nic jiného než pípne při příchodu požadavku: http://doxygen.reactos.org/…beep_8c.html – má 400 řádků, 9 funkcí a 1 bugu (schválně, kdo ji najde?) V DOSu by se taková věc dala napsat na 2 funkce, v Linux možná tak na 4 funkce. Je to příklad sice primitivní, ale je třeba si uvědomit, že když se navrhne příliš složité rozhraní, tak všechen jaderný kód takhle nabobtnává.

To byste také mohl z GUI udělat screenshot, a tvrdit, že GUI zabírá jen paměť toho screenshotu. Windows NT 3.x byly 32-bitové, a i ta grafika měla daleko víc služeb (Unicode, TrueType, GDI 32 s podporou Bézierových křivek atd).

BTW. minimální požadavky na systémy pro provoz textového režimu bez GUI:

DOS – 512kB Linux-0.X – 2MB Linux-2.0.X – 4MB Linux-2.6.X – 12MB

– takže můžeme říkat, jak staré verze Linuxu jsou špatně udělané … jenomže v devadesátých letech měl málokdo v počítači 12MB.

Co se týče GUI jsou ty rozdíly ještě horší: Apple – 128kB Windows 3 – 1MB Windows 95 – 4–8MB Linux 2.0 + XFree 3.6 – 8MB Windows NT 3 a 4 – 12MB Windows XP – 64MB Windows Vista – 512MB Nějaké moderní Linuxové GUI – asi podobně jako Vista, podle množství grafických serepatiček.

– takže na otázku, co by bylo, kdyby návrháři před 20 lety vyvinuli moderní operační systém, je odpověď: Neběželo by to!

–

Na zvracení je mi někdy naopak ze současného kódu Linuxu, např. na probuzení procesu se volá 8 vnořených funkcí, z nichž 7 nedělá nic jiného než předává argumenty další funkci, až ta poslední ten proces slavnostně přidá do fronty. Holt v tom kódu někdo strašně obsesivně hledal společné kusy a refaktoroval ho — až hloubka volání najednou byla 8 (na Sparc64 každá funkce sežere minimálně 192 bytů na zásobníku, takže to přispělo k pádu přetečením zásobníku … navíc to zpomaluje, protože to zcela vyprázdní všechna registrová okna). Takovéhle věci ve starém Linuxu (2.0 a nižší) nebyly.

Ty rozdíly v HW náročnosti jsou o ničem. HW náročnost nemá s vlastním kernelem moc společného. A celý OS se pak typicky staví tak náročný, aby slušně běžel na v té době prodávaném HW.

„HW náročnost nemá s vlastním kernelem moc společného.“

Má, pokud programátor má možnost udělat optimalizaci, která urychlí běh, ale sežere třeba 1MB RAM, tak dnes ji beze studu udělá, zatímco před 15 lety by to neudělal.

Třeba kernel Linuxu 2.6 sežere asi 8MB neswapovatelné paměti. Před 12 lety to bylo celkové množství paměti, co jsem v počítači měl. Takže na tom počítači by Linux 2.6 běžet nemohl.

„A celý OS se pak typicky staví tak náročný, aby slušně běžel na v té době prodávaném HW.“

Ano. Proto byl Linux 0.x a 1.x udělán tak jak byl.

Řeknu to jinak. HW náročnost OS není daná (jen) kernelem.
Samozřejmě dnes mají počítače GB paměti, a minimálně stovky GB diskového prostoru. Nemá smysl dnes psát SW pro HW, který tu byl před 12 lety.
Myslíte, že by například preemptivní kernel spotřeboval výrazně více zdrojů? Nebo že by lepší architektura driverů či lepší obsluha přerušení vyžadovala více zdrojů? Podle mě ne. Linux 0.x a 1.x vpyadal jak vypadal díky absenci designu a amatérismu Linuse.

No ano, je tak úspěšný že běží na necelém jednom procentu všech počítačů na planetě :-D Na těchhle naštěstí ne. Na RSX-11M tu mám asi padesát kilo manuálů, moc zajímavé čtení, myslím že si to měli v MS také trochu nastudovat.

Nevím jestli běží na jednom procentu všech počítačů. Zato vím, že jde o systém určený pro desktopy a servery, kde má lví podíl. RSX-11 měl trochu jiné určení.

Obchodní úspěch není známka kvality, a naopak – viz třeba Tucker.
Ano, RSX-11 měl jiné určení, takže z něj jeho tvůrce v NT asi moc nepoužil, ne? Nebo naopak MS chce desktopový NT cpát i tam, kam není určeno? Třeba řízení železáren… Ale možná že v první verzi Škody Felicie také byla nějaká embedded verze NT, ty totiž občas bez jakéhokoliv důvodu za jízdy chcíply, muselo se vypnout zapalování a po chvíli znovu nastartovat.
Mimochodem, VMS, ač o spoustu let mladší, bezpečnosti tehdejšího Unixu zdaleka nedosahovalo, tam se teda Cutler čím chubit nemá ;-)

Úspěch u zákazníků je známka toho, že produkt plní jejich potřeby. Naúspěch produktu (natož produktu dostupného zdarma) naopak svědčí o neplnění potřeb zákazníků. BTW jaký Tucker?
U designu nového OS se počítá praxe s jakýmkoliv návrhem OS, stejně jako zkušenosti s jeho psaním.
Windows Embedded ve Felicii nikdy nebyly. Naopak řídí spousty technologických procesů, energetické sítě, najdete je v bankomatech, pokladnách, tiskárnách atd. Na rozdíl od domácích počítačů nemají embedded Windows problémy s přetaktováním, neznačkovým HW, zmršenými drivery, a nejsou na nich nainstalované hromady crippleware a kradeného SW. Proto s nimi nejsou větší problémy.

Úspěch u zákazníků je známka toho, že produkt plní jejich potřeby. Naúspěch produktu (natož produktu dostupného zdarma) naopak svědčí o neplnění potřeb zákazníků. 

uspech softwaru u zakaznika odpovida jeho kvalite, zhruba stejne jako vypovida prodejnost desek o kvalite hudby britney spears… je to hnus, ale lidi to chteji, protoze nic lepsiho neznaji…

Britney Spears plní potřeby zákazníků, takže je prostě dobrá. Češi zase chtějí Lunetik, Karla Gotta a duo Eva a Vašek. Takovou kulturu totiž lidé chtějí. A kdyby chtěli, tak si místo toho koupí (mnohdy levnější) klasickou hudbu, jazz, klasický rock, nebo cokoliv jiného. Ale většina jich prostě nechce. Takže jaká hudba je kvalitní? Ta, kterou lidé (typiky) nechtějí poslouchat? To asi těžko.

Vaše měřítka hodnot a způsoby hodnocení jsou opravdu podivné. Takže tedy vězte, že kvalitní je to, co odolává času, módě, čehož hodnota je trvalá nebo někdy i s časem rostoucí, zkrátka co nevyhasíná. Po jakémsi lunetiku (už v současnosti ani nevím, co to bylo) za 10 let ani pes neštěkne, Bach nebo Deep Purple se ale bude hrát pořád. Krabice supermarketů za 20 let (snad) budou postupně bourány, chrám sv. Barbory budou tisíce lidí obdivovat pořád. Vůbec není důležité, co je momentálně nakrátko na výsluní, aby to posléze zapadlo v prachu. Pro to máme jiný výraz – populární. Ale populární a kvalitní jsou dvě naprosto rozdílné věci.

Vy chodíte nakupovat do chrámu sv. Barbory? Asi ne. Jaký má tedy smysl srovnávat novodobé tržiště se středověkým chrámem?
Zkusím to vysvětlit znovu. Kvalita je schopností statku plnit potřeby. V tržním systému lidé vybírají statky podle toho, jak plní jejich potřeby. Pokud lidé něco kupují, tak to zjevně plní jejich potřeby. Cokoliv jiného je čistě subjektivním hodnocením, a tedy naprosto od věci.

Aha, takže podle vás – byt představuje kvalitnější bydlení než dům se zahradou, protože po něm sáhla většina obyvatel u nás; jídelna představuje kvalitnější způsob stravování, protože ji v poledne upřednostní většina občanů před restaurací; kalkulačka, co umí jen sčítat, odčítat, násobit a dělit je podle vás kvalitnější, protože si ji koupí více lidí, než tu vědeckou; Eva a Vašek jsou kvalitnější, než Kožená, protože prodají víc cédéček; náboženské představy o Vesmíru jsou kvalitnější, než ty fyzikální, protože jim věří více lidí…?

Jak by asi řekl profesor Hrbolek – „vaše představy o tom, co je kvalitní, zdají se býti poněkud svérázné.“

Takze vychazime-li ze stejne premisy… nejlepsi restaurace, kde prodavaji nejkvalitnejsi jidlo, se jmenuje McDonald's.

Špatná formulace. McDonald's prostě velmi dobře plní potřeby zákazníků. V tom je jeho kvalita. Není mi ale jasné, proč by McD měl být nejlepší, nebo mít nejkvalitnější jídlo. Možná znáte nějaká čísla, která já neznám.

Shitney neplní potřeby zákazníků ale vydavatelů, ta vaše zdánlivá potřeba je jen iluze vytvořená reklamou. Lidé chtějí to, co mají ostatní, to je princip módy a komerce! Jako v tomhle pravidelně aktualizovaném vtipu:
Představte si, že společnost Cray se rozhodne vyrábět osobní počítače. Má šestnáct stodvacetiosmi­bitových procesorů s frekvencí 9 GHz, 256 GB operační paměti, 50 TB kapacity disku, rozlišení obrazovky 8192×8192, dá se kompletně ovládat hlasem, vejde se vám do kapsy a stojí 300 dolarů. Co bude první otázka, na kterou se počítačová veřejnost zeptá?
„Jaký je v tom Windows?“

To mi není úplně jasné. Zákazníci si mohou svobodně vybrat, jakou hudbu si koupí. Nekupují si Bacha ani Deep Purple, ale Britney, Karla Gotta a Evu s Vaškem. Ti zákazníci znají svoje potřeby, a proto si vybírají právě to, co kupují. Cokoliv jiného je jen subjektivní soud, do kterého promítáte vlastní kulturní preference (které se u mě také neshodují s mainstreamovými).

Tenhle Tucker.

Diskuse neni o tom, zda by se mel delat navrh ci ne, ale o tom, zda by ten navrhar mel umet programovat a pripadne zda by se mel pozdeji primo na tom projektu podilet jako programator. A ja si myslim, ze odpoved na obe otazky je ano.

V tom případě se asi shodneme, že u Linuxu se to s tím návrhem nějak nepovedlo.
Odpověď na první otázku je ano, na druhou asi ano. To „asi“ proto, že pokud OS píše třeba stovka vývojářů, tak je šéfarchitekt osobou, která by je měla spíš koordinovat (a kód určitě uvidí). Pokud se vůbec dostane k vlastnímu psaní kódu, tak bude jeho příspěvek velmi malý. Nakonec když někdo navrhne výškovou budovu nebo loď, tak také nemusí osobně pokládat základy nebo svařovat profily.

Ani ty Windows NT nevznikly s tužkou v ruce. API se taky od doby Windows NT 3.1 několikrát měnilo a rozšiřovalo. To nejde dělat vývoj systému způsobem „teď si sednu, vymyslím jakou architekturu má operační systém mít, vymyslím rozhraní pro aplikace, napíšu to na papír, pak to dám programátorům napsat a budu mít skvělý operační systém“. Když takhle budeme postupovat, tak získáme něco jako Windows 1.0, Windows NT 3.1 nebo Linux 0.01.

Smozřejmě, že v těchto systémech byla spousta věcí zbytečných, neefektivních nebo úplně špatně, což je důsledek toho odděleného návrhu, o čemž jsem psal původně.

API Windows NT se nějak výrazně měnilo? O tom bych se rád dozvěděl více.
Samozřejmě návrh OS musí vycházet z nějakého obchodního zadání (někdo to zpravidla platí). Například je účelem napsat RTOS, mezi předpokládané aplikace patří to a ono. Na základě toho uděláte design, který počítá s možností rozšiřování konceptu do budoucna. Na základě toho designu napíšete první verzi toho RTOS, při troše smůly budete muset občas zpátky k „rýsovacímu prknu“. A je tu první verze. Další verze provádějí korekce a rozšíření designu, případně se produkt cílí na širší cílové skupiny, nebo se naopak specializuje. Pokud jste se nestrefil, můžete vždy něco předělat. Čím jste lepší profík, tím více se zřejmě přiblížíte cíli. MS se zprvidla velmi dobře strefí do potřeb zákazníků už na třetí iteraci (viz Windows, Windows NT, SQL Server, Outlook a další), což není špatné. Ovšem ve spoustě případů i tak velká firma tvrdě selhala. Viz třeba dlouholeté neúspěšné snahy o embedded verzi Windows 3.x, které vedly až k napsání (konečně úspěšných) Windows CE.

Nějvětší změna bylo předávání všech syscallů procesu spravujícímu Win32 subsystém, který je teprv provedl pomocí interního NT API. Tohle bylo neúnostné, protože s každým novým procesorem je syscall a context-switch pomalejší (relativně k rychlosti procesoru). Tak to v NT 4 částečně převedli do kernelu. Bohužel ne úplně, tak je tam ten proces CSRSS a local procedure call rozhraní pořád, ale většinu syscallů jde rovnou do kernelového ovladače WIN32K.SYS.

Toto je třeba úkaz, že s tužkou a papírem člověk nic pořádně nenavrhne, protože se do toho návrhu dostanou nesmyslné věci typu proces spravující Win32 syscally.

Velké procento funkcí Win32 API je řešeno tak, že zavoláte knihovnu kernel32.dll, která poté provede syscall. Není mi jasné, proč by to mělo být pomalejší při zvýšení počtu procesorů. Pro SMP škálování Windows NT je naopak zásadní fakt, že je kernel preemptivní a reentrantní (na rozdíl od Linuxu).
V NT4 došlo k přesunu GDI a window manageru do kernelu. V NT4 bylo oboje součástí CSRSS.EXE, tedy v user mode. Jenže takový design v principu vede k velkému množství syscallů. Pokud přesunete GDI do kernelu, tak provedete jeden syscall, a dál už vše běží na straně kernelu. Poměrně pěkně to popisuje linkovaný článek. A když jsme u toho, tak ke změně API u celé akce NEDOŠLO. Aplikace totiž linkují proti user mode knihovnám. Jestli je ta či ona věc interně implementovaná v user mode nebo kernel mode, to aplikace nepozná.
http://technet.microsoft.com/…c750820.aspx

Nemám na mysli SMP, mám na mysli, že Pentium 1 syscall udělalo asi na 120 tiků, Pentium 2 na 250 (INT) / 150 (SYSENTER), Pentium 4 na 900 (INT) / 450 (SYSENTER). V těch procesorech je čím dál víc mikrokódu a provádějí syscally čím dál pomelaji.

Umístění toho Win32 subsystému do procesu je na nic. Vede to ke zpomalování (víc syscallů a navíc context switche) a nepřináší to žádnou hodnotu navíc: nezvýší to stabilitu (zkuste si ten proces CSRSS odstřelit – vytuhnou stejně celá Windows) a nezvýší to bezpečnost (když jeden uživatel vnutí CSRSS, aby vykonal jeho vlastní kód, tak má kontrolu nad celým systémem).

Mít speciální proces na Win32 subsystém by mělo smysl jen kdyby ten proces běžel na každého uživatele zvlášť. Pak by to sice bylo stále pomalé, ale přinášelo by to výhody: spadnutí Win32 procesu shodilo jen procesy daného uživatele a nechalo ostatní uživetele netknuté a kompromitování bezpečnosti Win32 procesu by opět vedlo jen k možnosti útočit na procesy toho samého uživatele, čili by to bezpečnost nijak neohrozilo.

Ale tak, jak to tam je, že máme jeden CSRSS proces pro všechny, to nemá smysl, to je jen výplod někoho, kdo na papír kreslil obdélníčky a šipečky. Což si vývojáři NT taky uvědomili a proto většinu funkcí toho procesu přesunuli do kernelu.

Jenže frekvence CPU se od dob Pentia (max 233MHz) výrazně zvýšily, takže jsou syscally daleko rychlejší. Samotné zvýšení počtu taktů na instrukci souvisí jednak s mikrokódem, ale také se zvýšením délky pipeline CPU (5 stages u Pentia, 10–16 u pozdějších CPU). Rozdělení pipeline CPU na více stages je výhodné pro částečnou paralelizaci provádění instrukcí, i když zvyšuje počet taktů na instrukci.

CSRSS obsahuje pouze user-space komponenty Win32 subsystému (třeba user-mode podporu textové konzole). Velká spousta funkcí Win32 se provádí v user space knihovnách (kernel32.dll, gdi32.dll, user32.dll, shell32.dll), které poté přímo provádějí syscally. Před NT 4.0 byly v CSRSS další funkce, o kterých se soudilo, že nejsou výkonově kritické. Ono dát například technologicky poměrně složité GDI32 do kernelu vyžaduje dost odladěný kód, aby kernel nebyl z hlediska bezpečnosti děravý jako řešeto. U NT 4.0 bylo GDI už dobře vyladěné, takže mohlo být přesunuto do kernelu. Stabilita a bezpečnost přesunutého kódu se ukázala jako dobrá, nakonec NT 4.0 najdete v některých firmách ještě dodnes.

A co „extreme programming“? Taky je to cesta.

Jenže tak nenapíšete OS. V lepším případě tak ve třecjh lidech upatláte webové stránky, ale už firemní IS v deseti lidech budete dělat velmi těžko. Natož když potřebuje zákazník vědět, co celá ta výsledná věc vlastně dělá :)

Doporucuji si k tomu neco nastudovat. Spouste staromilcu se XP nelibi, ale (nejen) podle mne potencial ma. Zacit muzete treba zde: www.extremeprogramming.org

Já si k tomu nastudoval více, než si myslíte. Extreme programming má dlouhou řadu problémů, a některé z nich jsem zmínil. Jestli tak chcete psát OS, tak jen do toho. Jen doufám, že nebudete stejně „extrémně“ stavět mosty nebo budovy.