zurück zum Artikel

Für die Programmierung von Windows Apps in der neuen Metro-Oberfläche in Windows 8 liefert Microsoft eine eigene, auf nativem Code und überarbeitetem COM basierende Klassenbibliothek mit Namen Windows Runtime. Als Programmiersprachen lassen sich damit C, C++, C#, Visual Basic und JavaScript einsetzen.

Auf der BUILD [1] 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 [2] und Redhawk [3].

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 [4] im Vortrag “Platform for Metro style apps”, BPS-1005 [5]).

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 … [6]" und "Silverlight ist tot [7]", 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 [8]. 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.

Native Code

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 [9], 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 [10] im Vortrag "Platform for Metro style apps [11]" 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.

HTML & JavaScript

Neue first-class citizens: HTML und JavaScript

Microsoft hat angekündigt, XAML und HTML5 als gleichwertige Oberflächenbeschreibungssprachen für Metro zu etablieren. Es ist aber bezeichnend, dass die Mehrzahl der Vorträge der BUILD-Konferenz zur Windows-8-Programmierung das mit HTML und JavaScript vornehmen. Auch anhand der von Microsoft zur Preview bereitgestellten Sammlung von Beispielcode für Windows-8-Anwendungen sieht man klar, wo Microsoft die Präferenz sieht: 145 Beispiele in HTML/JavaScript, 74 in XAML/C#, 80 in XAML/C++ und ein einsames Beispiel in XAML/Visual Basic.

Mit HTML geschriebene Windows App (alias "WinWebApp") bestehen im Gegensatz zu klassischen Webanwendungen und ähnlich wie einige Web-2.0-Anwendungen nur aus einer einzigen Webseite, in die Inhalte dynamisch geladen werden. Dadurch ist der wesentliche Bestandteil einer WinWebApp JavaScript. Die HTML- und JavaScript-Engine für das Rendering ist die gleiche wie im Internet Explorer 10 ("Chakra [12]"). Für WinRT wird aber nicht der vollständige Browser geladen.

Alle APIs des Browsers (z.B. Index DB, Application Cache, WebSockets, File API, CSS3- Transformationen und -Animationen) stehen zur Verfügung. Darüber hinaus gibt es für WinWebApps mit "WinJS" eine zusätzliche JavaScript-Bibliothek, die die Metro-Steuerelemente bereitstellt und den Zugang zu ausgewählten Funktionen des Betriebssystems ermöglicht. "WinJS" wird automatisch in jedes WinWebApp-Projekt eingebunden. Typischerweise sieht man in einem HTML-Tag Custom Attributes wie data-win-control="WinJS.UI.AppBar".

Mit WinJS und den zugehörigen HTML-Erweiterungen kann man aber von der Nutzung offener Standards nicht mehr sprechen. WinWebApps laufen erst mal nur auf Windows 8 – nicht in einem beliebigen HTML5-Browser und nicht auf anderen Betriebssystemen.

Werkzeuge & App Execution Engine

Als Entwicklungsumgebung für Windows Apps in XAML und HTML steht bisher eine frühe Vorabversion von Visual Studio 11 Express for Windows Developer zur Verfügung. Diese basiert eher auf Visual Studio 2010 und enthält noch nicht alle neuen Funktionen von Visual Studio "11" (voraussichtlich Visual Studio 2012). Enthalten sind hier nur Projektvorlagen für XAML-basierte Windows Apps (.csproj oder .vbproj) und HTML-basierte Windows Web Apps (.wwaproj), siehe Abbildung 5. Während es für XAML einen Designer gibt, bleibt für HTML derzeit nur die Bearbeitung in der Quellcodeansicht. Für die Gestaltung der Oberflächen lässt sich alternativ eine Preview von Expression Blend 5 verwenden. Expression Blend erzeugte bisher immer XAML-Code; ab Version 5 entsteht alternativ HTML5-Code. Ein Werkzeuge für beide Seitenbeschreibungssprachen zu haben, ist eine gute Idee.

Metro-Anwendungen laufen innerhalb der direkt im Kernel des Betriebssystems implementierten App Execution Engine (Abb. 6).

Jede Anwendung läuft in einem konkreten App Container. Die meisten Aufrufe gehen direkt in das Betriebssystem. Einige potenziell sicherheitsrelevante Aufrufe hingegen durch einen sogenannten "Broker", der den Aufruf unterbinden kann. Der Entwickler muss die Intentionen einer Anwendung in einem XML-Anwendungsmanifest (Package.appxmanifest) zur Entwicklungszeit deklarieren (Abb. 7). Die deklarierten Intentionen sieht der Benutzer bei der Installation und stimmt diesen zu. Alle nicht von der Anwendung deklarierten Funktionen werden von dem Broker unterbunden.

Verbreiten und Installation

Für WinRT hat Microsoft ein eigenes Paketierformat mit Namen AppX entwickelt, das ähnlich wie das XAP-Format in Silverlight funktioniert. Eine AppX-Datei ist eine ZIP-Datei, die alle zur Ausführung der Windows App benötigten Dateien enthält. Neben der .appx-Datei findet man im Ausgabeverzeichnis die gewählte Zertifikatsdatei und eine .bat-Datei, die mit der in Windows 8 enthaltenen Windows PowerShell 3 das Zertifikat integriert und das PowerShell-3-AppX-Modul nutzt, um mit dem Commandlet Add-AppxPackage die Windows App zu installieren.

Windows Apps werden primär über den neuen (aktuell noch nicht eröffneten) Windows App Store verbreitet werden, der genauso funktioniert, wie man es von den Smartphone-App-Stores kennt. Eine Zertifizierung durch Microsoft ist erforderlich, und das Unternehmen verdient an dem Verkaufserlös mit, wobei die Höhe der Provision noch nicht genannt wurde. Über den Windows App Store verbreitete Anwendungen können auch nach Nutzung abrechnen. Die Verbreitung über den Online-Shop kann man über das neue Store-Menü direkt aus Visual Studio heraus starten. Unklar ist, ob man über dafür lizenzierte Entwicklerrechner hinaus in der Lage sein wird, Apps von außerhalb des Windows App Stores zu installieren. Grundsätzlich erstellt man eigenständige Pakete über den Eintrag "Create App Package" im Store-Menü.

Bewertung

Bewertung

Vieles in der Windows Runtime erinnert an Silverlight: die Auswahl der Klassen, der eingeschränkte Ressourcenzugriff und die Verbreitung. Aber anders als bisher basiert XAML hier nicht auf Managed Code, sondern auf Native Code und hat damit das Potenzial, viel schneller als Silverlight und WPF zu sein. Außerdem wird HTML als Alternative zu XAML und JavaScript sowie C/C++ als Alternative zu C# und Visual Basic unterstützt. Das alles ist positiv zu verbuchen.

Allerdings lässt sich die neue Windows-Runtime-Bibliothek auch durchaus kritisch sehen. Microsoft ändert einmal mehr bereits etablierte Programmierschnittstellen und schafft eine dritte, nicht ganz kompatible Variante von XAML. Der Konzern hat leider völlig offen gelassen, warum es diese Änderungen in der Programmierschnittstelle gibt und warum überhaupt eine neue Bibliothek geschaffen wurde. Dass man nun alles im Untergrund in nativen Code implementiert, ist keine Begründung für eine Änderung der Schnittstelle nach oben. Allenfalls die Fälle der Einführung asynchroner Methoden könnten eine API-Änderung rechtfertigen.

Das ist schon die dritte Kehrtwende bei Windows-Anwendungen in den letzten zehn Jahren. 2002 wurde Windows Forms eingeführt, 2006 die Windows Presentation Foundation, jetzt die WinRT. Dabei haben gerade viele Unternehmen erst begonnen, ihre Windows-Anwendungen auf .NET umzustellen. Andere kürzlich von Windows Forms auf WPF oder Silverlight. Selbst wenn der Umstellungsaufwand von WPF/Silverlight zu WinRT weitaus geringer ist als von Windows Forms zu WPF, wird dennoch wieder ein Umstellungsaufwand für den bestehenden Programmcode und Schulungsaufwand für die Entwickler entstehen. Das wird viele Entscheider und Entwickler stark verärgern. Die Neuausrichtung bestärkt Zweifler an Microsoft darin, dass die Redmonder ständig die Richtung ändern – zu Lasten der Unternehmen, die Microsofts Techniken in der Softwareentwicklung einsetzen.

Es gilt aber auch, sich zu erinnern, dass Microsoft 2004 bei der Erstvorstellung von Longhorn (später Windows Vista und Windows Server 2008) schon einmal eine neue Bibliothek vorstellte, die eine neue universelle Programmierschnittstelle für Windows als Ablösung für die veraltete Windows-32-API darstellte: Windows Framework (WinFX [13]). Mit WinFX und einer .NET-Windows-Oberfläche ist Microsoft damals gescheitert. In Windows Vista war mit Ausnahme des Media-Centers kein einziger Teil in .NET geschrieben. Auch in Windows 7 gibt es darüber hinaus nur kleinere .NET-Werkzeuge wie die PowerShell.

Neben der Frage, ob sich die Softwareentwickler für WinRT begeistern können, steht und fällt der Erfolg von WinRT natürlich damit, ob Konsumenten überhaupt die neue Metro-Oberfläche annehmen werden. Man kann sich sicherlich vorstellen, dass in Zukunft Tablets mit Windows-Betriebssystem besser über die Theke gehen als bisher. Aber werden auch viele Konsumenten sich ein neues Betriebssystem für ihren PC kaufen, nachdem doch jetzt alle gerade mit Windows 7 zufrieden sind?

Auch ist zweifelhaft, ob sich typische Geschäftsanwendungen komplett in Metro abbilden lassen. Auf den ersten Blick wird man eher vermuten, dass Geschäftsanwendungen weiterhin auf dem klassischen Desktop laufen (und daher in .NET oder C++ erstellt werden) und nur eine kleine zusätzliche Windows App für wenige ausgewählten Informationen und Funktionen im Metro-Stil als Zusatz angeboten wird.

Es gibt also durchaus berechtigte Zweifel daran, dass die neue Windows Runtime in der derzeitigen Form ein Erfolg werden wird. Microsoft hat in der Vergangenheit schon mehrfach gezeigt, dass man das Feedback der Entwicklergemeinde ernst nimmt und nach einer Erstvorstellung noch deutliche Strategieänderungen vornimmt. Neben WinFX erinnert man sich der Autor dieses Beitrags da gut an ObjectSpaces [14], WinFS [15] und vor allem MyServices alias Hailstorm [16].

Dr. Holger Schwichtenberg
leitet das Expertennetzwerk www.IT-Visions.de, das Beratung, Schulungen und Softwareentwicklung im .NET-Umfeld anbietet. Er hält Vorträge auf Fachkonferenzen und ist Autor zahlreicher Fachbücher. (ane [17])

URL dieses Artikels:
https://www.heise.de/-1344071

Links in diesem Artikel:
[1] https://www.heise.de/news/Build-Erste-Details-zu-Windows-8-1341839.html
[2] http://www.zdnet.com/blog/microsoft/more-on-microsoft-jupiter-and-what-it-means-for-windows-8/8373
[3] http://www.zdnet.com/blog/microsoft/microsoft-codename-redhawk-lives-in-windows-8/9233
[4] http://channel9.msdn.com/Events/Speakers/ale%2Bholeek
[5] http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005
[6] http://www.david-tielke.de/post/2011/09/14/Ist-der-NET-Entwickler-der-neue-VB6-Entwickler.aspx
[7] http://www.neowin.net/news/former-microsoft-pm-silverlight-is-dead
[8] http://msdn.microsoft.com/en-us/library/windows/apps/br230302%28v%3DVS.85%29.aspx#UI
[9] http://msdn.microsoft.com/en-us/library/windows/apps/hh464945%28v=VS.85%29.aspx
[10] http://channel9.msdn.com/Events/Speakers/john%2Bsheehan
[11] http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005
[12] http://blogs.msdn.com/b/ie/archive/2010/03/18/the-new-javascript-engine-in-internet-explorer-9.aspx
[13] http://www.it-visions.de/Lex/673.aspx
[14] http://www.it-visions.de/Lex/643.aspx
[15] http://www.it-visions.de/Lex/674.aspx
[16] http://www.it-visions.de/lex/433.aspx
[17] mailto:ane@heise.de

Copyright © 2011 Heise Medien