Seite 2: Native Code

Inhaltsverzeichnis

Flashback mit nativem Code

Ein Punkt unterscheidet die Windows Runtime fundamental von .NET und Silverlight: WinRT ist in C++ als eine COM-Komponente implementiert und liegt komplett in nativem Code vor. Das muss man sich noch mal verdeutlichen: COM ist das Softwarekomponentenmodell, das 2002 von .NET abgelöst werden sollte. Nun gibt es nach mehr als zehn Jahren Stillstand das COM-Softwarekomponentenmodell in einer neuen klassenbasierten Fassung – bisher war das Kernkonzept die Schnittstelle. Microsoft hat nun viele Konzepte aus .NET zurück nach COM portiert.

Die für C# und Visual Basic sowie JavaScript verfügbaren Klassen sind nur "Wrapper". Ein neues Typsystem sorgt dafür, dass die Typen in verschiedene Sprachen "projiziert" werden und damit dort verfügbar sind. Das darunter COM liegt, erkennt man auch an den HRESULT-Werten. Die WinRT verwendet das alte HRESULT-Konzept. Die Wrapper-Klassen bilden einige HRESULT-Werte auf Exception-Klassen ab und den Rest auf die generische COM-Exception.

WinRT-Klassen besitzen Metadaten genau wie .NET-Anwendungen. Das Metadatenformat heißt WinMD, entspricht aber dem .NET-Metadatenformat. Die Abfrage der Metadaten zur Laufzeit (Reflection) wird unterstützt. Ziel bei WinRT war ein geringer Overhead und maximale Leistung – sicherlich ein Tribut an die größere Menge C++-Entwickler, die Microsoft bisher nicht von Managed Code begeistern konnte. Auch das Rendering von XAML ist in der WinRT nun in nativem Code realisiert und hat damit das Potenzial, schneller zu sein als WPF und Silverlight.

Im Fall von in C# oder Visual Basic geschriebenen Metro Apps führt wie bisher die Common Language Runtime (CLR) den Managed Code aus. Es steht aber nur eine Teilmenge der .NET-Klassen zur Verfügung. Die Darstellung in WinRT erfolgt nicht via GDI, sondern mit DirectX. Eine Message Loop gibt es nicht mehr.

WinRT lässt sich nur aus Metro Apps heraus verwenden. WinRT kann der Entwickler also nicht von Win32-Anwendungen oder .NET-Anwendungen nutzen. Metro Apps kennen nicht das Konzept einer gemeinsamen Bibliothek (Shared Library), das heißt, jede Metro App muss ihre DLLs selbst mitliefern. Nur die WinRT-DLLs sind geteilt.

WinRT wird von Microsoft als integraler Bestandteil des Betriebssystems betrachtet, nicht als ein zusätzliches Framework. Daher wird WinRT zusammen mit jedem Build von Windows kompiliert. Und es heißt auch, dass WinRT nicht für ältere Betriebssysteme als Add-on nachgeliefert werden soll – so ist der aktuelle Stand. Unternehmen, die Client-Anwendungen entwickeln, müssen also in Zukunft zwei Codebasen pflegen, wenn sie ihre Anwendungen sowohl für den klassischen Desktop als auch Windows 8 Metro anbieten wollen.

WinRT ist verfügbar für die Prozessorarchitekturen x86, x64 und ARM. In der Keynote am ersten Tag sah man auch, dass WinRT-Anwendungen mit nur "einer geänderten Codezeile" auf Windows Phone laufen können. Was das für Silverlight auf Windows Phone bedeutet, blieb allerdings offen.

Aufbau der WinRT-Bibliothek

Die Abbildung 3 gibt einen Überblick über die wichtigsten Teile der WinRT-Bibliothek. Neben Standardfunktionen wie Threading, XML und Mehrsprachigkeit erkennt man auch Windows-8-spezifische Funktionen wie "PlayTo", mit der man die Wiedergabe von Medien auf beliebigen DLNA-Geräten (Digital Living Network Alliance) starten kann.

Ebenso wie die .NET-Klassenbibliothek ist WinRT aus Namensräumen aufgebaut, zum Beispiel Windows.ApplicationModel.Background, Windows.Data.Xml.Dom, Windows.Media.PlayTo, Windows.Storage, Windows.System.Threading und Windows.UI.Xaml.Input. Als Wurzelnamensraum verwendet Microsoft hier "Windows", statt wie bisher "System" und "Microsoft". Einige Betriebssystemfunktionen sind gut versteckt, zum Beispiel die Registry steuert man mit den Klassen im Namensraum Windows.Storage.ApplicationDataContainer. In der vorläufigen (und noch stark lückenhaften) Dokumentation findet man eine Liste, wo welche Funktionen der bisherigen Windows-API in der Windows Runtime zu finden sind. .NET-Entwickler warteten schon lange darauf, dass mehr Funktionen des Betriebssystems (z.B. Zugriff auf Hardware) in Form von .NET-Klassen bereitstehen. Mit Ausnahme der XAML-Oberflächenklassen sollen die WinRT-Klassen auch "klassischen" (d.h. nicht Metro-basierten) .NET-Anwendungen zur Verfügung stehen.

In Metro läuft typischerweise nur eine Anwendung im Vordergrund. Alle nicht vom Anwender genutzten Anwendungen im Hintergrund schlafen. Sie bleiben im RAM, der Scheduler weist dem Thread aber keine Rechenzeit zu, es wird also kein Code ausgeführt. Damit ässtl sich die Leistung steigern. Die Anwendung kann man durch sogenannte Real Time Communication Triggers (z.B. eingehende Netzwerkpakete, Zeitsteuerung) temporär reaktivieren.

XAML

Abbildung 4 zeigt die in der WinRT verfügbaren Steuerelemente; sie gibt es sowohl für HTML als auch für XAML. Auf den ersten Blick fällt auf, dass nicht alle WPF- und Silverlight-Steuerelemente vertreten sind und es zusätzliche Steuerelemente wie GridView und AppBar gibt. Copy & Paste von XAML aus WPF oder Silverlight zu WinRT (und zurück) wird also in vielen Fällen nicht funktionieren.

Eine Aussage wie "WinRT ist Standard-XAML" von John Sheehan im Vortrag "Platform for Metro style apps" verdeutlicht die Sicht, die Microsoft-Mitarbeiter auf WinRT haben. Softwareentwickler, die schon wirklich Projekte sowohl mit WPF als auch Silverlight umsetzen mussten, sagen, dass es kein "Standard"-XAML gibt, sondern die Unterschiede so groß sind, dass eine 1:1-Übernahme in der Regel nicht möglich ist. Lediglich der Grundstock der Syntax ist gleich, aber davon hat man für die konkrete Übernahme von Oberflächen herzlich wenig.