Bei allen Nachteilen der Windows-Architektur darf man nicht vergessen, dass auch Android und iOS vom Ballast eines typischen Desktop-Linux beziehungsweise Mac OS X befreit werden mussten, was natürlich auch dort die Ausführung von bestehenden Desktop-Apps verhindert.
Ein wesentlicher Punkt, um Ballast loszuwerden, ist es, die Unterstützung von (S)VGA-Karten ohne 3D-Hardwarebeschleunigung aufzugeben. Eine moderne Grafikkarte hat nämlich die Verwaltung von Fenstern und Z-Ebenen bereits hardwareseitig eingebaut. Moderne APIs wie Skia (Android), Direct2D (Windows) und Quartz Extreme (Mac OS) senden nur noch Befehle an die Grafikhardware, die diese selbstständig ausführt.
Falls VGA-Kompatibilität eingebaut ist, muss das Betriebssystem die Verwaltung von Fenstern inklusive der unsichtbarer Inhalte beherrschen, die beispielsweise von anderen Fenstern verdeckt sind oder erst durch Scrolling sichtbar werden.
Zudem besitzen Desktop-Betriebssysteme meist noch ein veraltetes Interface wie Carbon (Mac OS) oder GDI (Windows), das auf Mechanismen nach der Art von WM_PAINT-Messages und InvalidateRect basiert. Mit moderner 3D-Grafikhardware lässt sich ein ganzes Fenster, etwa eine komplette Website, immer direkt in die GPU rendern, egal ob Teile davon unsichtbar sind. Da heute sogar Smartphones über 3D-GPUs verfügen, kann man eigentlich auf VGA-Unterstützung verzichten.
Rückwärtskompatibilität verliert an Bedeutung
Will man ein Betriebssystem wie Windows von historischem Ballast befreien und trotzdem rückwärtskompatibel bleiben, steht man vor einer praktisch unlösbaren Aufgabe. Rückwärtskompatibilität ist aber eine Sache, die für Clients immer mehr an Bedeutung verliert. So kann beispielsweise das unixbasierende Mac OS X keine Anwendungen von Mac OS 9 oder früher ausführen. Zwar wurde die Carbon-Schnittstelle geschaffen, die eine Portierung von alten Anwendungen erleichtert, aber ohne Modifikation laufen diese nicht. Trotzdem wurde Mac OS X ein Erfolg.
Heutzutage ist es für Client-Betriebssysteme wichtig, dass eine Mindestfunktionalität, beispielsweise Browser, PDF-Reader und E-Mail-Software, zur Verfügung stehen. Dass noch alte Anwendungen laufen, wird immer mehr zur Nebensache. Das gilt natürlich im Consumer-Umfeld stärker als im Business-Umfeld.
Dort muss etwa gewährleistet sein, dass Office-Dokumente, die zum Teil 20 Jahre alt sind, nach wie vor zumindest geöffnet und angesehen werden können. Unternehmen, die Arbeitsprozesse auf Lotus Notes abgebildet haben, sind darauf angewiesen, dass alle Mitarbeiter Zugang zum System haben.
Zwei Kernel erlauben neues OS unter Beibehaltung der Kompatibilität
Alle diese Probleme könnten mit einem Zwei-Kernel-Betriebssystem gelöst werden. Dabei darf man nicht davon ausgehen, dass die beiden Betriebssysteme so stark voneinander getrennt werden, wie man das von Vollvirtualisierung gewohnt ist, etwa wenn man Windows unter Mac OS virtualisiert.
Man kann auf jeden Fall von Paravirtualisierung mit dynamischer Speicherverteilung für beide Kernel ausgehen. Das beherrscht Windows Server 2008 R8 ab SP1. Ferner dürfte sich das Nebeneinander der beiden Kernel für den Benutzer transparent auf einem einzigen Desktop abspielen.
Die Skizzen in der Patentschrift zeigen ferner mehrere Möglichkeiten auf, wer die Eigentümerschaft über die Hardware bekommt. In Skizze 7 bootet der Hypervisor einen weiteren Kernel, der nur für Hardware-I/O zuständig ist. In Skizze 8 werden die Aufgaben des Hypervisors erweitert, so dass er die Geräte selbst betreibt. Microsoft hält sich hier explizit alle Möglichkeiten offen. Daher kann man über technische Details bisher nur spekulieren.
Neueste Kommentare
6 Kommentare zu Windows 8: Kommt Microsofts neues OS mit zwei Kerneln?
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
dotNet
hmm…wenn man es einfach betrachtet, brauchen sie einen kernel, der dotNet unterstützt, der desktop selber wird in wpf oder silverlight umgesetzt…office wird komplett in dotNet gemacht, visual studio 2010 ist bereits in dotNet, … fehlt noch etwas, das wirklich hexenwerk ist? Also um den consumer glücklich zu machen…business ist natürlich noch was anderes.
AW: dotNet
sorry, hatte deinen kommentar irgendwie überlesen (siehe mein kommentar unten). bin genau deiner meinung. frage des kernels zukünftig komplett irrelevant… ms hat eigentlich heute schon die technologie für programme die auch unter windows 8 (egal auf welchem prozessor/kernel das laufen soll). man braucht jetzt nur noch die entsprechenden (gui-)apis und fertig…
—
Es reicht halt nicht aus, einen dünnen technischen Artikel anzuschneiden und über bestimmte Implementierungen zu urteilen.
Der Windows Kernel ist schon seit eh und je vom HAL und den Subsystemen so entkoppelt, dass unterschiedliche Versionen vom Kernel verwendet werden können (SMP, PAE…).
GUI, Filesystem usw. sind alles vom Kernel entkoppelte Subsysteme. Wenn es dort Abhängigkeiten gibt, muss das nicht zwangsweise schlecht sein. Dass zum Drucken bisher GDI verwendet wurde ist ja logisch und auch nicht schlecht, da man mit GDI eben das Ausgabegerät (Drucker oder Monitor) von der API Funktionalität entkoppeln wollte.
Die Windows Architektur ist gut und alles andere als schlecht. Ich würde mir aber mal Gedanken machen wohin die Reise geht, wenn Android Handys/Tablets immer leistungsfähiger werden. Die Reise geht nämlich von den Funktionen nach oben, da wo Windows schon steht. Android und iOS wurden so zerpflückt, dass ihre eingeschränkten Funktionen im Vergl. zum Desktop OS auf minimalistischer HW laufen. Aber ist das jetzt auch für Windows ratsam, da die technische Entwicklung erwartungsgemäßg nach oben geht?
managed code
kurze rückfrage an den verfasser des artikels (oder wer auch immer darauf antworten mag):
warum spielt der kernel des betriebssystems in zeiten von managed code (silverlight/.net) überhaupt noch eine rolle?! wenn (windows-)programme zukünftig nur noch in managed code geschrieben werden würden, dann ist doch die frage, welcher kernel dahinter liegt, vollkommen irrelevant, oder irre ich da mich? warum muss dann z.b. office überhaupt noch für eine architektur angepasst werden? als .net/silverlight applikation müsste das paket doch auf jedem gerät mit entsprechender runtime laufen?
danke für eure antworten :)
AW: managed code
Also unter Microsoft .Net wird ja diverses durch Wrapper genutzt, welche die Win32-Api zur Verfügung stellen. Von daher müsste man natürlich neben einem komplett neuen Kernel auch diese Win32 Api Funktionen neu implementieren bzw. zur .Net Laufzeitumgebung hinzufügen.Beispiel: WPF selbst steuert ja nicht die Grafikkarte an. Dazwischen steht der Treiber und AFAIK DirectX.
OS von Microsoft für Tablets
Ich meine, mein Windows XP läuft mit 256MB RAM hervorragend.
Könnte es Microsoft nicht genauso machen? Ein Tablet-OS mit WinXP als Basis?
Eventuell nur noch die Funktionen wie Win7.