Hoofdcategorieën
Device Settings

Microsoft haalt graphics uit Windows-kernel

Door Mick de Neeve, woensdag 14 december 2005 22:34
Bron: Techworld, views: 35.074

Techworld schrijft dat Microsoft het grafische subsysteem (bekend als WPF of 'Avalon') in Windows Vista buiten de Windows-kernel zal laten opereren. De reden daarvoor is dat veel vastlopers hun oorsprong in de grafische gebruikersinterface vinden, zegt Microsoft infrastructure architect Giovanni Marchetti. Het is een extra bescherming bovenop de eerder genomen beslissing om de meeste drivers, inclusief de grafische, in de zogeheten user mode te laten draaien, om toegang tot de kernel te voorkomen aangezien softwarefouten op dat niveau vaak tot een systeemcrash leiden. Negen van de tien crashes zouden het gevolg zijn van driverproblemen, die in user mode draaiend tot minder systeemcrashes moeten leiden. In feite gaat Windows hiermee dezelfde kant op als Unix, Linux, Mac OS en BSD, waar het grafische subsysteem zijn werk ook buiten de kernel doet.

Het opschuiven van het grafische subsyteem naar de user mode zou ook moeten helpen de gebruikersinterface minder afhankelijk van de gebruikte hardware te maken. Daarnaast moet het besturingssysteem er minder gevoelig voor kernelmalware zoals rootkits door worden. Een bijkomend voordeel zou zijn dat zware grafische applicaties makkelijker vanaf terminal servers gedraaid zouden kunnen worden omdat er beter comprimeerbare (kleinere) datapakketjes over het netwerk gestuurd zouden worden terwijl intensieve operaties zoals rotaties lokaal worden uitgevoerd. Het losweken van het grafische subsysteem draagt weliswaar performancekosten met zich mee, maar dat zou met de huidige stand van techniek nauwelijks merkbaar moeten zijn, gezien de beslissing van Microsoft om de kernel open te zetten voor de gebruikersinterface en drivers uit 1990 stamt - indertijd was daar een veel groter performancevoordeel mee te halen.

Airport Windows crash
Volgende 23:06 Microsoft geeft ontwikkelaars vooruitblik op Direct3D 10
Vorige 21:01 'Volgende generatie Centrino gemiddeld 28% zuiniger'
Advertentie

Reacties

«  1  2  3  4  »

Dit is heel goed nieuws. Hadden ze een hele tijd terug al gedaan moeten hebben...

ze hadden het nooit in de kernel moeten stoppen. In NT 3.5 zat het netjes in ring 1 en niet in ring 0 (de kernel). Nee MS moest weer eens eigenwijs zijn en het in de kernel stoppen. dit lesje hebben ze duur moeten leren met alle BSOD's door drivers.

In het stuk staat anders toch duidelijk de reden waarom men tot die keuze was gekomen: er was namelijk een duidelijke prestatie verbetering mee te bereiken en in die tijd (met processoren op 100 tot 333 MHz en 8 tot 64 MB werkgeheugen) was dat broodnodig.

Nu is de tijd gekomen dat men met CPU cycles en MB's kan smijten en is de beslissing genomen om het weer terug naar layer 1 te brengen.

Overigens zijn de default drivers die sinds Windows 2000 meegeleverd worden altijd zeer betrouwbaar geweest en DE keuze voor mensen die betrouwbaarheid boven snelheid verkiezen. En denk er aan: een slechte graphics driver zal ook in Vista voor problemen blijven zorgen: denk maar aan de oudere, brakke drivers voor ATI kaarten onder linux. Niks om over naar huis te schrijven, terwijl die toch netjes buiten de kernel gehouden worden!

Snelheidswinst is een reden om rotimplementaties in te voeren die tien jaar lang stand houden en een hoop miserie veroorzaken?

die bewuste beslissing hebben we in de les computer architectuur bekeken (universiteit) en ik moet zeggen dat de prof het eens was met MS
de snelheidswinst was toen enorm
het probleem is dat de gfx kaarten zo ingewikkeld zijn geworden dat er altijd wel bugs in de drivers zitten, waardoor het nu niet meer te verantwoorden is

alleen jammer dat MS intern niet snel beslissingen durft nemen, dit hadden ze eigenlijk al moeten doen bij NT5

Hadden misschien wel maar konden ze het op dat moment ook? Lijkt mij, als je het binnen de Windows-context bekijkt, behoorlijk revolutionair.

die bewuste beslissing hebben we in de les computer architectuur bekeken (universiteit) en ik moet zeggen dat de prof het eens was met MS
de snelheidswinst was toen enorm
Voor Windows 1, 2 en 3 had ik he nog kunnen begrijpen. Maar sinds Windows '95 was het al niet meer nodig. Ze hadden deze beslissing 10 jaar geleden al kunnen en moeten nemen.


Je ziet het.

Veel meer draagt je post niet echt bij, meer yet-another-flame naar Microsoft toe. En niet dat deze post nou zo constructief is, maar ik ben dat eeuwige gebash op of MS of Linux nu wel zat hoor.

Goed nieuws. Kunnen we zonder veel gevaren onze multithreaded GUI's uitproberen.

Multithreaded gui's, klinkt mooi, in de praktijk werkt het niet, graphics hardware is er niet voor gemaakt en je kan er nooit een snelheidswinst mee bereiken.

Meestal word dit gefaked door door alle multithreaded opgeroepen grafische calls in een queue te plaatsen en die gewoon singlethreaded uit te voeren, oa in Swing behalen ze hier in Mustang een leuke performance winst mee.

't gaat bij multithreaded Gui's ook niet alleen om rauwe snelheidswinst, maar vooral om responsiveness en "'t gevoel". Daarmee bedoel ik dat voorkomen wordt dat je hele GUI blokkeert zodra je via een knop een bijvoorbeeld een IO intensieve actie uitvoert.

Kijk maar eens naar BeOS. Daar is dat toch echt wel goed uitgeveord hoor.

Hmmm... dus als ik het goed begrijp blijft er voor de kernel zelf weinig werk over? Wel handig dat het zo waarschijnlijk makkelijker is om bij een crash een bepaald deel van Windows opnieuw op te starten zonder te rebooten. Ik vraag me wel af hoe alle communicatie tussen de kernel en de losse delen (sub kernels?) geregeld gaat worden, en of juist daar geen zwakke plekken in zullen zitten... Ik zie de kernel IO viri al verschijnen :7

en of juist daar geen zwakke plekken in zullen zitten... Ik zie de kernel IO viri al verschijnen
wat dat betreft is er weinig verschil als wat we nu hebben, een driver kan nu immers ook in principe alles doen ;)

Hmmm... dus als ik het goed begrijp blijft er voor de kernel zelf weinig werk over?
Euhm, wat dacht je van het verstrekken van instructies aan de processor? Geheugenallocatie? Harde schijf transacties?

.......procesbeheer over meerdere CPU's, security


Het idee van een microkernel is al zéér oud. Zelfs Windows NT was al opgezet als Microkernel. De keuze was indertijd echter performance of mooi ontwerp en logischerwijs koos Microsoft voor de performance. Nu de performance minder relevant wordt (dankzij krachtige GPUs) kan deze keuze weer terug gedraaid worden.

De claim dat Windows dit leent van Linux geeft enkel het beperkte niveau van sommige mensen hier op tweakers aan. Botweg gezegd: Linux is een samenraapsel van andermans ideeen (uit o.a. Unix, Minix, Windows en BSD). Ook nu nog worden de meeste zaken, zoals filesystemen, nog vanuit andere OSen geport naar Linux. Daar is niets mis mee, maar er zit verdomd weinig echt oorspronkelijks in Linux.

Ik vind het vooral opmerkelijk dat ze de overeenkomst met Linux trekken, terwijl juist Linux gaat voor een macrokernel architectuur.


Een schouderklop en een bakkie koffie.

JFK? Delta scherm? ;)

Zoals altijd bij software, via api's. Ik vind het zowiezo een goed bericht om te horen dat er weer iets uit een onderdeel is gehaald wat eigenlijk als een module geimplementeerd had moeten worden. Als je nu de grafische systemen wilt updaten hoef je alleen die module te updaten, en de infrastructuur ongemoeid te laten.

OS-sen worden altijd al modulair gemaakt zodat je elk afzonderlijk onderdeeltje kan updaten zonder dat er aan het geheel iets verandert.

Windows is wat dat betreft een uitzondering. Maar ja, Windows is wel op meer punten van OS-design een uitzondering.. ;)

Onder andere populariteit...

ja, da's nou echt een feature van os-design... |:(

populariteit heeft niets, maar dan ook werkelijk niets met het desing van het OS te maken. Da's een kwestie van marketing, reklame maken zeg maar.

onbegrijpelijk dat zo'n ondoordachte post met +3 inzichtvol wordt gemodereerd.

En toegankelijkheid, iets wat Linux tot op heden nog altijd niet geschikt maakt voor de gemiddelde thuis gebruiker... dus het heeft weldegelijk met design te maken...

Toegankelijkheid en modulariteit hebben echt NIKS met elkaar te maken. Dus je praat hier gewoon poep.


Huh wat heeft het in usermode ipv kernel mode draaien te maken met de het softwarematig emuleren van directx?

usermode/kernelmode heeft helemaal niets te maken met wat voor toegang applicaties hebben tot de videokaart.
Het zal misschien een minieme hoeveelheid performance loss met zich meenemen om redenen die ik niet kan uitleggen als niet kernel expert, maar ik speel liever mijn spellen op een fps minder dan dat ik met iedere nieuwe driver release drie keer per minuut crash (ja overdreven).

Dit maakt voor de gebruiker dus compleet geen hol uit behalve dan dat het veiliger is en stabieler. En die kaart van 400 euro is zowieso volgend jaar niet meer dan 100 meer waard :+

Terug naar NT 3.51, daar zat de GUI ook in de usermode en niet in de kernel.

of op naar vista :Y)

Ja, maar da's niet eerlijk! NT 3.51 is nog door IBM gemaakt. En die hebben de Microsoft programmeurs niet geleerd hoe je een Operating System moet schrijven. Je kunt het niet Microsoft aanrekenen dat ze naderhand een puinhoop van IBM's ontwerp hebben gemaakt. De programmeurs van Microsoft wisten niet beter, daar moet je ze voor respecteren.

:+

Je haalt een aantal zaken door elkaar. Microsoft heeft destijds Dave Cutler (ontwerper van VMS) aangetrokken om Windows NT te schrijven. Windows NT is door Microsoft ontwikkeld, niet door IBM.

Je bent waarschijnlijk in de war met OS/2. Het oorspronkelijke OS/2 systeem (tot versie 1.3) werd door Microsoft in samenwerking met IBM geschreven. IBM heeft pas vanaf OS/2 versie 2.0 de ontwikkeling in eigen beheer voortgezet.

Raul Pesch
Microsoft B.V.

Klopt. Daar was bij de introductie van NT 4.0 best wat heisa over. Ik hoor zo af en toe nog wel eens iemand over een NT 3.51 servertje dat al jáááren niet gereboot is...

hopelijk lost dit de vervelende bug op dat als je windows explorer een video of foto wil cachen en vastloopt dat niet heel je desktop crasht (maw icoontjes die verdwijnen en startbalk die verdwijnt, waardoor statbar e.d. niet meer juist docken)

Nee, dat is gewoon Explorer.exe die vastloopt. Die zou automatisch opnieuw gestart moeten worden. Je kunt dat ook handmatig proberen door Ctrl-Alt-Del te klikken en onder de TaskManager onder File..New Task (run) weer een nieuwe explorer.exe te starten.

Nee. Explorer.exe was al een user-mode process, wat voor je desktop, taakbalk, en dat venstertje waar je je fotomap in bekijkt zorgt. Als je dat venstertje dan laat crashen crasht dus je taakbalk mee.

Overigens is er in Windows XP bij de verkenner-opties een optie om elk Verkenner-venster een apart process te geven, dat lost het op.

die is er ook al bij alle versies van windows 2000, - ergens verborgen in het register. - zou verder niet weten hoe dat zit, - aangzien ik 'm toepas met nLite

Kijk eens onder Configuratiescherm bij Mapopties, tabblad Weergave, Geavanceerde instellingen, 'Mapvensters in een afzonderlijk proces openen' ;)
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

Volgende 23:06 Microsoft geeft ontwikkelaars vooruitblik op Direct3D 10
Vorige 21:01 'Volgende generatie Centrino gemiddeld 28% zuiniger'
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011