Windows 8 Apps benötigen neue Windows Runtime

Inhaltsverzeichnis

Auf der BUILD hat Microsoft die Katze aus dem Sack gelassen: Für die Programmierung von Windows Apps in der neuen Metro-Oberfläche in Windows 8 liefert das Unternehmen eine eigene, auf nativem Code und einem überarbeiteten Component Object Model (COM) basierende Klassenbibliothek mit Namen Windows Runtime (WinRT). Als Programmiersprachen lassen sich damit C, C++, C#, Visual Basic und JavaScript einsetzen. Das Managed Code verwendende .NET Framework könnte dadurch an Bedeutung einbüßen. Der Erfolg von WinRT ist aber keineswegs gewiss.

In den letzten Monaten herrschte eine große Verunsicherung unter den Entwicklern von Windows-Anwendungen, nachdem durchgesickert war, dass die neue, auf Apps basierende Windows-Oberfläche "Metro" (siehe Abb. 1) mit HTML, CSS und JavaScript implementiert wird. Es sah so aus, als ob HTML, CSS und JavaScript die einzige Programmierplattform für die Entwicklung der neuen Windows Apps sein würden. Parallel dazu gab es aber auch Gerüchte über neue Laufzeitumgebungen und Bibliotheken wie Jupiter und Redhawk.

Klassische versus moderne Anwendungen

Das wichtigste Bild zeigte Steven Sinofski zum Glück schon zu Anfang seiner Keynote auf der BUILD-Konferenz. Links in der Abbildung 2 stehen die "Metro-style Apps" (von Microsoft auch als "modern application" bezeichnet), die Anwendungen für die neue Windows-8-Oberfläche. Die Oberflächen (Views) erstellt man mit HTML/CSS oder XAML. Die Programmierung erfolgt mit C/C++/C# und Visual Basic für XAML oder JavaScript für HTML/CSS. In beiden Fällen ist die neue Windows Runtime Library der Unterbau. Eine dritte, im Bild nicht genannte Möglichkeit für Metro-Oberflächen ist die Verwendung von DirectX 11.

Rechts im Bild sieht man die klassischen "Desktop Apps" für den Windows-Desktop, den es ja auch in Windows 8 noch gibt. Diese Anwendung erstellt man wie bisher mit der Win32-Bibliothek beziehungsweise MFC (Microsoft Foundation Class) oder mit Windows Forms beziehungsweise WPF (Windows Presentation Foundation) aus der .NET-Klassenbibliothek. Microsoft betont: "All your investments in Win32, .NET and Silverlight will be preserved. You will be able to run those apps on Windows 8" (Aleš Holeček im Vortrag “Platform for Metro style apps”, BPS-1005).

Auf den ersten Blick sieht man allerdings .NET in dem Schaubild nur noch klein unten rechts in der Ecke und Silverlight gar nicht mehr. Das ließ sofort bei vielen Betrachtern die Befürchtung aufkommen, dass .NET und Silverlight nun nur noch eine Randerscheinung in der neuen Windows-Welt sind. In Twitter und Blogs liest man seit den Keynote-Aussagen wie "Ich befürchte, die .NET Entwickler werden die neuen VB6-Entwickler …" und "Silverlight ist tot", Letzteres auch aus dem Munde von Scott Barnes, der früher Produktmanager für Silverlight bei Microsoft war.

Wie viel .NET ist drin?

Bei genauerer Betrachtung ist aber .NET auch auf der linken Seite in Abbildung 2 mehrfach vertreten:

• Die Programmiersprachen C# und Visual Basic sind auch für WinRT wichtige Sprachen
• XAML entspricht der aus WPF und Silverlight bekannten Oberflächenbeschreibungssprache – zumindest hinsichtlich der grundsätzlichen Syntax. Es gibt aber Abweichungen bei den Steuerelementen.
• Die Klassen der Windows Runtime Library (Sinfosky bezifferte diese mit circa 1800) sind in weiten Teilen eine Untermenge der .NET-Klassen aus der .NET-Klassenbibliothek 4.0 beziehungsweise Silverlight 5.

Die neue Windows-Runtime-Bibliothek erinnert schon beim Betrachten der Namensräume stark an Silverlight. So fehlen zum Beispiel alle Klassen für den direkten Zugriff auf Datenbanken (System.Data.*). Daten kann eine Windows App nur über Webservices oder aus Dateien abrufen. Der Zugang zum lokalen Dateisystem und anderen Systemressourcen ist aber stark eingeschränkt – das aus Silverlight bekannte Sandbox-Konzept.

Im Detail besitzen die Windows-Runtime-Bibliothek und die .NET-Klassenbibliothek nicht wenige lästige Unterschiede. So wird aus der Klasse System.Type nun System.Reflection.TypeInfo, für den HTTP-Download muss man System.Net.Http.HttpClient statt System.Net.WebClient verwenden. Alle Klassen für die Benutzerschnittstelle liegen in Windows.UI.Xaml statt wie bisher in System.Windows. Ein StreamWriter besitzt keine Close()-Methode mehr, sondern nur noch Dispose(). Das sind viele kleine Beispiele aus dem Kapitel "Converting your existing .NET Framework Code" in der WinRT-Dokumentation. Systematischer sind wohl die Änderungen bei Methoden, die "länger" laufen. "Alles, was über 50 Millisekunden dauern könnte, hat nun nur noch asynchrone Methoden", sagt Holeček. Microsoft will die Entwickler erziehen, die aus Vereinfachungsgründen bisher den weit leichteren, aber den Thread blockierenden synchronen Weg gewählt haben.

In Summe der fehlenden und geänderten Klassen kommt man zu der Erkenntnis, dass bestehende .NET- und Silverlight-Anwendungen nur mit einem nennenswerten Umstellungsaufwand als Metro App werden laufen können.

Nach Silverlight ist damit die Windows Runtime die dritte Variante der .NET-Klassenbibliothek, die nicht voll kompatibel ist. Der Entwicklergemeinde stellt sich die Frage, warum Microsoft eine neue Bibliothek einführt, statt .NET oder Silverlight in Hinblick auf Metro Apps zu erweitern.