Der Nachfolger von Windows 7
Zunächst einmal wird auf Windows 8 alles laufen, was auch auf der Vorgängerversion läuft. Es gab ja einige Befürchtungen, dies könnte nicht so sein.
Neben vielen wirklich coolen Neuerungen wie Hyper-V auf dem Client, RemoteFX oder Windows To Go, ist die neue Oberfläche im Metro Design und die ihr zugrundeliegende Windows Runtime das innovative Highlight von Windows 8. Neben dem gewohnten Windows Desktop, der auch weiterhin zur Verfügung stehen wird, gibt es die neue Metro Oberfläche, die speziell auch Touch-Geräte unterstützt und teilweise schon vom Windows Phone bekannt ist.
Grundlegend neu ist die Windows Runtime, die die Programmierschnittstelle für Metro-Apps bereitstellt und technologisch neue Wege einschlägt.
Die Windows Runtime
Die schlicht Windows Runtime (WinRT) genannte Schnittstelle zum Betriebssystem ist ein ABI (Application Binary Interface) nach dem Vorbild von COM. Die WinRT ist in nativem Code mit C++ geschrieben und darauf ausgelegt, das UI „fast and fluid“ zu machen. Um sie zu programmieren, wurde C++ mit vielen neuen Features angereichert, die man aus .NET kennt: Properties, Exceptions, Delegates, Events, Generics, Lambda-Expression, u.a. Die dazugehörige Syntax ist praktisch identisch mit C++/CLI, nur wird eben kein managed, sondern nativer Code generiert. Die WinRT stellt ihre Funktionalität in Form von Komponenten, die Interfaces implementieren, zur Verfügung. Um aus verschiedenen Programmiersprachen heraus genutzt werden zu können, legt sie bestimmte Datentypen und Konventionen fest. Das ist ganz ähnlich wie die CLR in .NET funktioniert, aber die WinRT basiert nicht auf .NET. Sie verwendet insbesondere kein Garbage-Collection, sondern das aus COM bekannte Reference-Counting. Um die Programmierung zu vereinfachen wurde dazu in C++ ein neuer new-Operator eingeführt, der den Compiler veranlasst, die Aufrufe von AddRef und Release selbst zu generieren, wenn der Pointer auf ein so erzeugtes Objekt verwendet wird.
Die in COM verwendete IDL (Interface Definition Language) zur Beschreibung von Schnittstellen wird nicht eingesetzt. Stattdessen kommt ein moderneres Metadatenformat zum Einsatz, welches eine Weiterentwicklung des aus .NET bekannten Metaformats darstellt. Aufgrund dieser Windows Metadata (WinMD) kann die WinRT von beliebigen Sprachen aus anprogrammiert werden (im Gegensatz zu .NET, was nur von beliebigen managed Sprachen aus angesprochen werden kann). Zurzeit sind C++ und JavaScript die einzigen unmanaged Sprachen und C# und VB die einzigen managed Code Sprachen, die zur Verfügung gestellt werden.
Das Binden an eine konkrete Programmiersprache wird als „Projection“ bezeichnet, wohl um auszudrücken, dass es mehr ist als simples „Binding“. Da die WinRT sich über ihre Metadaten selbst beschreibt, ist die Projection in eine konkrete Sprache automatisiert und sehr effizient möglich. Sprachen wie C# können diese Metadaten praktisch direkt nutzen und benötigen daher die in COM notwendigen Interop-Assemblies nicht mehr.
Die Projection erlaubt außerdem eine tiefe Integration in die jeweilige Programmiersprache. So sind beispielsweise ca. 10 bis 15 Prozent der WinRT Funktionen asynchron, d.h. sie starten einen länger andauernden Vorgang und liefern gleichzeitig ein Interface auf ein Operation-Objekt zurück, über das man diesen Vorgang kontrollieren und am Ende dessen Ergebnis abfragen kann. Ruft man eine solche Funktion aus C# heraus aus, kann man direkt das neuen Schlüsselwort await aus dem async/await Pattern von C# 5 verwenden. Aus dem IAsyncOperation der WinRT wird ein Task<T> in C#. In JavaScript dagegen wird die gleiche WinRT-Funktion in ein entsprechendes Promise-Konstrukt umgewandelt.
Programmiermodell
Das folgende Schaubild ist eine der Kernfolien von Microsoft.
Es zeigt deutlich, dass die Metro Apps neben dem bisherigen Windows Desktop Apps liegen, sie also um etwas Neues ergänzen und nichts ersetzen.
Die von der WinRT angebotenen Klassen und Funktionen sehen Silverlight zum Verwechseln ähnlich und jeder Silverlight- bzw. WPF-Programmierer findet sich praktisch sofort zurecht. Zwar sind die Namespaces und viele Details etwas anders, aber die aus Silverlight bekannten Controls und Konzepte wie XAML, Resources, Styles, Templates, etc. werden alle nahezu identisch unterstützt. Auch das Resource-Format .resw ist praktisch das Gleiche wie .resx.
Die Konzepte der WinRT eignen sich hervorragend für alle Arten von Schnittstellen, stehen aber zunächst mal nur unter Windows 8 und nur für Metro Apps zur Verfügung.
C++/CX
C++/CX ist der Name des für die WinRT erweiterten C++. Stark vereinfacht kann man es so ausdrücken: C++ plus die coolen Sprachfeatures von C# mit Reference Counting anstatt Garbage Collection. Da C++/CX nativen Code erzeugt, kann man nun die unschlagbare Performance von C++ mit den modernen Sprachmitteln von C# nutzen. Ein gewaltiger Schritt für C++ als Basissprache moderner Betriebssysteme. Microsoft möchte, dass C++/CX in den ANSI-Standard einfließt. Zurzeit kann man C++/CX allerdings nur unter Windows 8 und nur für WinRT Metro Apps verwenden.
JavaScript
Auch für JavaScript ist die WinRT verfügbar. Dadurch sind mit HTML5 Browser-basierte Metro-Anwendungen möglich, die alle Features des Betriebssystems nutzen können. Ich sehe zwei große Vorteile dieses Ansatzes. Zum einen findet das riesige Heer von JavaScript-Programmierern nun einen einfachen Zugang zur Programmierung von Windows Apps. Ein kluger Schachzug von Microsoft, der auch von Microsofthassern nur schwer zu kritisieren ist. Zum anderen lässt sich dynamischer Content aus dem Web leichter in eine HTML5- als in eine XAML-basierte Metro App integrieren.
Bevor nun jemand wegen HTML5 auf falsche Gedanken kommt: Alle Metro Apps basieren auf der WinRT. HTML5 Apps werden zwar vom IE 10 gehostet, laufen aber ausschließlich auf Windows 8 Geräten und sind damit genauso proprietär wie eine XAML-basierte Metro App.
C#/VB
Als .NET Sprachen stehen zurzeit C# und VB zur Verfügung. Auch wenn das obige Schaubild den Eindruck erweckt, als würde C# irgendwie ohne .NET Framework laufen, gibt es genau wie bisher eine CLR, Garbage Collection, IL Code und ein .NET Framework. Tatsächlich ist auf Windows 8 auch nur ein .NET 4.5 Framework installiert, mit dem man wahlweise WinForms, ASP.NET, WPF, etc. Anwendungen erstellen kann oder alternativ auf Basis der WinRT Metro Apps. Eine Vermischung der beiden Welten innerhalb einer Anwendung ist nicht vorgesehen.
Ansonsten hat man das Gefühl, Silverlight oder WPF zu programmieren. XAML, Controls, Events, Styles, Templates, ResourceDictionaries, VisualStateManager, usw. sind bis ins Detail sofort vertraut. Natürlich gibt es etliche Unterschiede, beispielsweise bei den Touch-Events oder bei neuen Namensräumen, aber jeder Silverlight-Entwickler findet sich schnell zurecht.
Es ist auch möglich, mit C#/VB neue WinRT-kompatible Komponenten zu erstellen, wenn man sich an bestimmte Konventionen hält. So kann man beispielsweise nützliche Hilfsroutinen, sein ViewModel oder neue Controls in C# schreiben und diese dann in einer HTML5 App über JavaScript verwenden. So muss das auch sein. Ich bin absolut überzeugt, dass .NET die dominierende Technologie für WinRT Anwendungen werden wird, weil .NET einfach die produktivste Art ist, Software zu entwickeln, die bisher erfunden wurde.
Performance zählt
Eine der wichtigsten Neuerungen der WinRT sind drastische Verbesserungen der UI-Performance gemäß dem Metro-Paradigma „fast and fluid“. Am einfachsten lässt sich das anhand eines Beispiels verdeutlichen. In Silverlight beruhen Animationen letztlich darauf, dass man über eine Timeline gesteuert eine oder mehrere Dependency-Properties über einen Zeitraum hinweg verändert. Basierend auf diesen Änderungen rendert der UI-Thread die Oberfläche mehrmals pro Sekunde neu. Auf einem Intel Desktop-Prozessor ist dies kein Problem, wenn auch ein Blick in den Taskmanager zeigt, dass damit ein Prozessorkern oft zu 100% ausgelastet ist. Auf einem mobilen Gerät mit einem ARM Prozessor führt dies jedoch zu einem unlösbaren Problem. Die Animation wirkt entweder ruckelig oder benötigt bestenfalls einfach zu viel Energie und belastet damit die Batterie unangemessen. Dies war einer der Hauptgründe, warum Microsoft vor rund 3 Jahren Silverlight nicht auf Windows Mobile sinnvoll zum Laufen bekommen hat. Andererseits erwartet ein Anwender heutzutage, das beispielsweise ein zu löschendes Element aus einer Liste nicht einfach „wegpoppt“, sondern sich langsam ausblendet, während die dahinterliegenden Elemente nachrücken und die Lücke schließen. Grundsätzlich kein Problem für ein Silverlight FluidMoveBehavior, aber leider sind diese zu performancehungrig für mobile Geräte.
Die WinRT geht daher mit fest eingebauten Animationen für Standard-Controls einen neuen Weg. Für das obige Beispiel aktiviert man einfach die sog. Theme-Transition AddDelete aus der eingebauten Animations-Library. Etwas vereinfacht ausgedrückt rendert diese Animation alle beteiligten List-Items genau einmal und bewegt sie dann GPU-beschleunigt über das Display, ohne dass der Inhalt dabei neu berechnet werden müsste. Visuell macht dies keinerlei Unterschied, sieht geschmeidig aus und braucht nur einen Bruchteil der Energie. Die vorgefertigten Animationen sind vielfältig und lassen sich auch untereinander kombinieren. Wem das dennoch nicht ausreicht, kann die jetzt als „Dependent Animation“ bezeichneten bisherigen Animationen immer noch verwenden. Allerdings muss man sie explizit einschalten, damit einem auch bewusst wird, dass man hier Leistung verbrät.
Dieses Beispiel zeigt sehr deutlich, wie sehr die WinRT auf Geschwindigkeit, flüssiges UI und Energieeffizienz getrimmt ist. Der Verzicht auf Garbage-Collection in der WinRT erfolgte übrigens nicht aufgrund von Performanceüberlegungen. Zum einen wollte man auf Betriebssystemebene die vollständige Kontrolle über die Speicherverwaltung haben und zum anderen sollte die WinRT wirklich von jeder Programmiersprache aus genutzt werden können.
Weitere Programmiersprachen
C++, JavaScript, C# und VB sind zurzeit die einzigen verfügbaren Programmiersprachen für die Windows Runtime und man kann damit auch nur Metro Apps bauen. Da jedoch alle Entwickler, mit denen ich auf der BUILD gesprochen habe, völlig begeistert sind von der WinRT, vermute ich mal, dass in naher Zukunft diverse Programmiersprachen auf die WinRT aufgesetzt werden. Einfach so, weil es eine interessante Herausforderung ist und Entwickler gerne spannende neue Dinge machen. Außerdem lassen sich viele Sprachen vermutlich sogar leichter auf die WinRT aufsetzen als auf das .NET Framework.
Silverlight
Zur strategischen Zukunft von Silverlight wurde auf der BUILD nichts gesagt. Natürlich läuft Silverlight im Browser und Out-of-Browser auf dem Windows 8 Desktop. Das war aber sowieso klar, da schon immer jede neue Windows-Version die Software der Vorgängerversion ausführen konnte. Auch das Silverlight, Flash und sonstige PlugIns nicht innerhalb einer HTML5 Metro App laufen werden ist logisch. Metro Apps laufen in einer Sandbox und werden vor dem Verkauf über den Windows Marketplace von Microsoft verifiziert. Und zu diesem Konzept passen nun mal keine Browser-PlugIns, auch nicht Silverlight.
Nun ist Metro zwar technisch gesehen eine Weiterentwicklung von Konzepten aus Silverlight, deckt aber einen größtenteils anderen bzw. neuen Markt ab. Metro steht für eine neue UX auf Windows 8 Geräten und läuft weder auf Windows XP, Vista oder 7, noch auf dem Desktop weder im Browser noch Out-of-Browser, noch auf dem Mac. Damit ist es auch mittelfristig keine Alternative für Projekte, die man heute mit Silverlight machen würde. Silverlight hat sich von der aus heutiger Sicht nicht mehr realistischen „WPF/Everywhere“ Idee hin zu einer Browser-basierten Windows Desktop Technologie entwickelt. Durch die Einführung von PInvoke kann eine Full-Trust Silverlight 5 Anwendung sowohl im Browser als auch Out-of-Browser alles machen, was mit Win32 möglich ist. Das ist eine andere Richtung als die von Metro eingeschlagene. Metro erweitert Windows für neue Gerätetypen, ersetzt aber keine der bisherigen Desktop-Technologien.
Ich vermute, dass Microsoft selbst noch nicht so genau weiß bzw. entschieden hat, was nach Silverlight 5 kommen wird. Viele Firmen haben auf Silverlight gesetzt und auch LightSwitch basiert darauf. Daher bin ich sicher, dass Silverlight auch in den nächsten Jahren eine zunehmend wichtigere Rolle spielen wird. Für reine Web-Anwendungen mit maximaler Reichweite muss man ausschließlich auf HTML und JavaScript setzen, das war aber auch schon bei Einführung von Silverlight so und Silverlight war nie als Alternative zu HTML angedacht. In Szenarien, wo man jedoch die Wahl zwischen HTML oder Silverlight hat, ist und bleibt Silverlight fast immer die bessere Alternative.
Die tägliche Arbeit
Metro und die WinRT sind sowohl von der UX Seite als auch technologisch ein großer Schritt nach vorne. Die Zukunft wird sicherlich sehr spannend werden. Bis Windows 8 auf dem Markt ist und eine nennenswerte Verbreitung hat, wird allerdings noch eine ganze Weile vergehen. Wer also nächsten Monat ein neues Projekt startet und sich heute Gedanken über die Technologie macht, für den hat sich durch die BUILD nicht viel geändert. Er sollte Silverlight oder WPF für den Desktop verwenden, genau wie bisher. Zwei sehr positive Dinge für die unmittelbare Zukunft hat die BUILD allerdings schon gebracht: Zum einen weiß jetzt jeder Silverlight-Entwickler, dass er sein Know-how zur UI-Programmierung, XAML oder RIA Services auch langfristig mit Metro weiter nutzen kann. Zum anderen sind die von Microsoft durch eine unglückliche Präsentation von Windows 8 im Juni geschürten Befürchtungen, die .NET Entwicklung würde durch JavaScript ersetzt, endlich vom Tisch.
Ich vermute, dass die WinRT langfristig das Win32 API verdrängen wird, jedoch frühestens in der übernächsten Windows-Version. Vorher werden aber bestehende Systeme wie Windows Phone 8 die WinRT als Basis erhalten. Microsoft hat jedenfalls eine sehr durchdachte und innovative Grundlage für die nächsten Jahre geschaffen.
Wenn ich mir was wünschen könnte: Silverlight 6 im Metro Look mit einer WinRT als PlugIn für weitere non-Microsoft Plattformen. Dies wird aber wohl ein Wunsch bleiben.