Windows 8 Preview im Detail: Neuerungen unter der Haube

Metro-Style-Apps basieren auf einem ganz anderen API-Modell als klassiche Windows-Apps. Alle sichtbaren Elemente werden mit HTML, CSS und XAML definiert. Zu den Elementen wird Code in Javascript, C#, Visual Basic oder C++ hinterlegt.

Beschränkt man sich auf HTML, CSS und Javascript, dann kann eine Metro-Style-App sehr leicht portiert werden, etwa auf Mobiltelefone unter Android und iOS. Zur Not kann man sie als Browser-App auch auf jedes Desktop-Betriebssystem wie Mac OS X oder Linux portieren.

Hier geht Microsoft einen wichtigen Schritt in Richtung Interoperabilität und Unabhängigkeit der Anwendungen vom Betriebssystem. Das ist nicht ganz uneigennützig, denn man weiß, dass Microsoft hinter den Kulissen unter dem Codenamen Midori an einem Betriebssystem arbeitet, das nicht mehr auf dem NT-Kernel basiert.

Auch wenn Microsoft und Steven Sinofsky Windows 8 gegenüber seinen Vorgängern kräftig verschlanken können, ist Windows zu wenig modular aufgebaut, dass man es für alle Zwecke vom Mobiltelefon bis zum High-End-Server anpassen kann. Bei Linux und Mac OS X gibt es diese Probleme nicht. Langfristig muss Microsoft einen neuen Kernel bauen, der unabhängig voneinander funktionierende Dienste und Frameworks hostet.

Metro-Style-Apps sind allerdings nicht grundsätzlich auf jedes Betriebssystem portabel. Oft muss nativer C- oder C++-Code eingebaut werden. Die Gründe liegen nicht so sehr in der Performance, sondern darin, dass bestehender Code weiter verwendet werden muss. Man kann nicht so einfach ein Programm wie Microsoft Office von C++ auf C# bringen.

Dieser bestehende Code generiert einerseits nativen Prozessorcode, so dass er beispielsweise ohne Neukompilierung nur auf x86-Systemen läuft und nutzt andererseits Low-Level-APIs, die nur für ein Betriebssystem zur Verfügung stehen und nicht eins zu eins auf ein anderes portiert werden können.

Man muss daher das gesamte Metro-Style-Framework als einen Schritt in die richtige Richtung betrachten. Den gesamten Weg muss Microsoft später in Zusammenarbeit mit anderen Herstellern konsequent zu Ende gehen, was den Redmondern traditionell nicht leicht fällt, da dies auch eine ernsthafte Gefahr für ihr Desktop-Monopol bedeutet.

ARM und x86

Mit Windows 8 hat sich Microsoft sehr zum Ärger von Intel dafür entschieden, auch eine ARM-Version herauszubringen. Diese Entscheidung ist sicher nicht leicht gefallen, da man einerseits den langjährigen Weggefährten Intel nicht grundlos verärgern will und andererseits einen nicht unerheblichen Zusatzaufwand bei der Entwicklung hat.

Stand heute ist es aber so, dass ARM-CPUs für Smartphones und Tablets aus Gründen des Stromverbrauchs einfach die bessere Wahl sind. Bisher kann Intel ARM keine CPUs entgegensetzen, die einen vollständigen x86-Befehlssatz bieten, aber ähnlich wenig Strom verbrauchen.

Das führt zu dem Problem, dass immer, wenn ein nativer Compiler zum Einsatz kommt, eine Applikation, die für x86-Geräte kompiliert ist, nicht auf ARM-Geräten läuft. Ein x86-Emulator für ARM wäre viel zu langsam.

Ein Programm, dass ausschließlich in einer Sprache geschrieben ist, die Bytecode kompiliert und mittels eines JIT-Compilers zur Laufzeit in nativen Code umwandelt, kann hingegen auf ARM- und x86-Geräten laufen. Das gilt nicht nur für Metro-Apps, sondern auch für klassische Windows-Desktop-Apps, die beispielsweise in C# oder Visual Basic entwickelt sind.

Entwickler können heute leicht neue Apps programmieren, die unmodifiziert auf der ARM- und der x86-Version von Windows 8 laufen. Für die meisten alten x86-Anwendungen gilt aber, dass der Hersteller eine spezielle ARM-Version herausbringen muss.

Entscheidet sich ein Programmierer für das Metro-App-Framework, hat er immer noch einen gewissen Aufwand, sie auf andere Betriebssysteme zu portieren. Dieser fällt allerdings deutlich geringer aus, als bei einer klassischen Windows-App. Der Hauptaufwand liegt meist darin, den Code von C# zu einer anderen Sprache zu portieren, etwa der Dalvik-VM von Android. Dies könnte man mit Javascript in vielen Fällen umgehen, allerdings ist Javascript für größere Projekte wenig geeignet, da es den Entwickler zu unsauberer Programmierweise mit vielen Memory-Leaks verleitet.

Fazit

Mit der Developer-Preview von Windows 8 zeigt Microsoft gleich eine Reihe von Überraschungen. Allerdings fallen diese fast ausschließlich positiv aus. So scheint es Microsoft durchaus gelungen zu sein, den Ressourcenverbrauch von Windows 8 gegenüber der Vorgängerversion deutlich zu senken.

Während man die Metro-Style-Oberfläche schon in geleakten Videos und Screenshots bewundern konnte, überzeugt auch das dahinterliegende Framework. Die User-Interface-Elemente basieren auf HTML und CSS, Technologien, die heute so weit ausgereift sind, dass sie klassischen GUI-Elementen sogar teilweise überlegen sind. Das gilt zum Beispiel für HTML5-Canvas. Ferner haben Entwickler den Vorteil, ihre Userinterfaces leicht auf andere Betriebssysteme portieren zu können. Es bleibt aber die proprietäre Beschreibungssprache XAML.

Bei den Sprachen haben Programmierer die freie Auswahl zwischen C, C++, C#, Visual Basic, Javascript und anderen. Verzichten Entwickler auf native Compiler und generieren ausschließlich Bytecode, laufen Anwendungen sogar ohne Modifikation auf ARM- und x86-Geräten. Die meisten bestehenden Anwendungen müssen aber für ARM-Geräte mindestens neu kompiliert werden.

Weniger überzeugend klingt zunächst die Senkung der Bootzeit. Hier hat Microsoft geschummelt: Beim Herunterfahren wird in Wirklichkeit der Ruhezustand aktiviert. Den kann man auch bei Windows 7 manuell aufrufen. Spätestens, wenn bei einem Update wichtige Systemdateien ausgetauscht werden, was nicht nicht selten vorkommt, muss ein echter Reboot stattfinden. Hier muss sich noch zeigen, wie lange dieser Vorgang wirklich dauert.

Alles in allem hat Microsoft aber bisher einen guten Job bei der Weiterentwicklung von Windows gemacht, jedenfalls bis jetzt. Bis zum Release im nächsten Jahr ist es noch ein weiter Weg.