WinRT, das API für die Zukunft von Windows

Gestatten WinRT
Kommentare

Windows 8 bringt eine ganze Reihe an Neuerungen: Metro Style, Touch, neue Hardware, Unterstützung für ARM und vieles mehr. Für Softwareentwickler auf der Windows-Plattform wird dabei vor allem die Windows Runtime (WinRT) den gewaltigen Umfang an Neuerungen spürbar machen. Wenn Sie in den nächsten Jahren Programme für Windows entwickeln, kommen Sie an WinRT nicht vorbei. In diesem Artikel untersuchen wir, was hinter WinRT steckt. Sie erfahren, warum sie von Microsoft entwickelt wurde und welche konkreten Auswirkungen das auf Ihre Arbeit als Entwickler von Anwendungen für Windows haben wird.

Wenn Sie sich schon gefragt haben, ob WinRT das Ende der .NET-Klassenbibliothek bedeutet, dann ist dieser Artikel genau richtig für Sie. Als .NET-Entwickler vergessen wir manchmal, welches Fundament dafür sorgt, dass unser managed Code funktioniert. Es ist das Windows API, das früher unter dem Namen Win32 bekannt war [1]. Die Klassenbibliothek des .NET Frameworks enthält zwar Komponenten, die von Grund auf in managed Code entwickelt sind (z. B. MEF, Linq to XML etc.), bei großen Teilen handelt es sich aber um relativ dünne Hüllen (Wrapper) rund um Betriebssystemfunktionen aus dem Windows API (z. B. Sockets). Schmerzlich bewusst wird das spätestens dann, wenn man im Programm Betriebssystemfunktionen braucht, die das .NET Framework nicht enthält. In solchen Fällen bleibt nichts anderes übrig, als die entsprechenden DLLs mithilfe des Platform Invocation Service (P/Invoke) oder COM Interop direkt aus der jeweiligen .NET-Sprache aufzurufen [2]. Auch wenn P/Invoke und COM Interop in den neuesten Versionen von .NET um vieles einfacher geworden sind, merkt man immer noch den radikalen Bruch zwischen der Welt des managed Code und des nativen API von Windows. Noch schlechter geht es da Technologien, die ihren Ursprung im Web haben. Webentwickler bauen mithilfe von HTML und JavaScript beeindruckende Software. Microsoft will die Welt von Windows 8 und insbesondere den kommenden Store von Windows für JavaScript-Programmierer nutzbar machen. Heute gibt es aus JavaScript praktisch keinen tauglichen Weg, direkt auf Betriebssystemfunktionen zuzugreifen. Wie kann man das Windows API in Zukunft so anbieten, dass es sowohl von unmanaged (C++) als auch von managed Code (z. B. C#, VB) und JavaScript bequem, natürlich und ohne manuelle Entwicklung von Wrapper-Code erreichbar ist? Das ist die erste Frage, auf die WinRT eine Antwort gibt.

In meinem letzten Artikel über Windows 8 und WinRT [3] habe ich die zweite Frage bereits erwähnt: .NET ist seit seiner Vorstellung vor etwa zehn Jahren erwachsen geworden. Die .NET-Plattform wurde speziell im Bereich der Benutzerschnittstelle um Technologien ergänzt, die weit über das vom Betriebssystem selbst gebotene Niveau hinausgehen (z. B. XAML, WPF). Obwohl .NET sich großer Popularität erfreut, kann man bei Weitem nicht davon sprechen, dass alle Entwickler, die Software für Windows erstellen, darauf setzen. Es gibt eine ganze Reihe von Szenarien, in denen die von C++ gebotenen Möglichkeiten zur Optimierung von Programmen von großem Wert sind. Das gilt mittlerweile mehr denn je, da sich die Sprache in den letzten Jahren enorm weiterentwickelt hat. Im Zusammenhang mit C++ ist die Entwicklerproduktivität gestiegen und die Fehleranfälligkeit gesunken. Entwickler, die unter Windows auf unmanaged Code mit C++ setzen, können mächtige Technologien aus .NET, zum Beispiel XAML oder WPF, jedoch momentan nicht nutzen. Wird also WPF oder zumindest das bewährte Subset von Silverlight beziehungsweise Windows Phone komplett ins Windows-Betriebssystem übernommen? Nicht ganz. WinRT hat Premiere in Windows 8, und aus diesem Grund hat sich Microsoft entschlossen, ihre inhaltlichen Aufgaben auf die optimale Unterstützung der Entwicklung von Metro Style Apps zu beschränken. Die Klassenbibliothek der WinRT enthält in Windows 8 genau die Komponenten, die für diese Apps notwendig und hilfreich sind. Die zweite Frage, die WinRT aufwirft, könnte man also wie folgt formulieren: Was braucht ein Entwickler an vorgefertigten Komponenten und Bibliotheken, um möglichst effizient Metro Style Apps zu entwickeln?

Das dritte Thema ist ebenfalls eng mit den Metro Style Apps verknüpft: Das Konzept der App wird durch WinRT tief im Kern von Windows verankert. Wie der Name schon sagt, enthält die Windows Runtime eine Laufzeitumgebung, die beispielsweise Dinge wie das Verteilen (Windows Store), das Starten (Tiles), das Verwalten (z. B. Mechanismus zum Schutz des Benutzers vor unerlaubtem Zugriff auf die WebCam) und den Austausch von Daten zwischen Apps (z. B. Contracts) steuert. Der dritte große Themenbereich von WinRT zusammengefasst: Welche grundlegenden Fähigkeiten muss die Programmierschnittstelle von Windows in Zukunft anbieten, damit Apps nicht nur ein Aufsatz, sondern ein integraler Bestandteil der Plattform sein werden? Lassen Sie uns damit beginnen, diesen Aspekt von WinRT genauer zu betrachten.

Laufzeitumgebung für Apps

Windows enthält bereits seit langer Zeit eine Technologie, die es ermöglicht, monolithische Anwendungen in Komponenten zu zerteilen. Diese Komponenten können einzeln verteilt und versioniert werden und erlauben auch Zusammenarbeit über Anwendungsgrenzen hinweg. Die Technologie, die hier gemeint ist, ist das Component Object Model (COM) [4] sowie darauf aufbauende Standards wie ActiveX Controls [5] oder Automation (IDispatch Interface [6]). Als .NET-Entwickler kommen wir nur selten direkt mit COM in Berührung. Konkret passiert das immer dann, wenn wir beispielsweise eine COM-Komponente direkt ansprechen müssen, da es für sie keine managed Wrapper Assemblies gibt. Der Umgang mit COM wurde in .NET 4 vereinfacht, von natürlichem Umgang mit COM aus .NET heraus kann aber immer noch keine Rede sein. Die WinRT baut auf vielen Grundelementen von COM auf, entwickelt sie jedoch mit Rücksicht auf das kommende App-zentrierte Modell von Windows weiter. Im Folgenden werden exemplarisch einige Gemeinsamkeiten vorgestellt:

  • Auf unterster Ebene ist die WinRT ein auf Interfaces basierendes System (COM-erfahrene Leser freuen sich vielleicht zu erfahren, dass der gute, alte Bekannte IUnknown auch in WinRT die unterste Basis der Vererbungshierarchie von Objekten ist). Interfacebasierend bedeutet, dass man keinen direkten Zugriff auf das erstellte Objekt erhält, sondern immer nur Pointer auf ein von ihm implementiertes Interface. Jedes Objekt muss IUnknown implementieren. Diese Schnittstelle kann man durch Pointer auf alle weiteren, vom Objekt implementierten Interfaces abfragen (IUnknown::QueryInterface). vNext einer Klasse kann die im Vergleich zur Vorgängerversion angebotenen Methoden erweitern, indem ein neues Interface hinzugefügt wird. Durch diesen Mechanismus können WinRT-Objekte versioniert werden, ohne bestehenden Code zu brechen; er muss nicht einmal neu kompiliert werden.
  • Auf der tiefsten Ebene arbeitet WinRT genau wie COM mit numerischen Fehlercodes in Form von HRESULT und nicht mit Exceptions.
  • WinRT-Komponenten werden in der Windows Registry registriert, das Betriebssystem verwendet die Registry, um WinRT-Komponenten aufzufinden. Abbildung 1 zeigt als Beispiel die Registrierung einer Metro Style App in der Windows Registry. Achten Sie darauf, dass in diesem Fall im ExePath auf wwahost.exe verwiesen wird. Der Grund dafür ist, dass diese App mit JavaScript geschrieben wurde und sie aus diesem Grund mithilfe dieses Systemprogramms ausgeführt wird.
  • Viele der aus COM bekannten DLLs und Prozesse wurden für WinRT weiterentwickelt, sind aber auch in der neuen Plattform vorhanden (Lesern, die mit COM vertraut sind und Details zu diesem Thema wissen möchten, empfehle ich das Channel9-Video von Matt Merry [7]).
Abb. 1: Registrierung einer C# und einer JavaScript Metro Style App in der Windows Registry
Abb. 1: Registrierung einer C# und einer JavaScript Metro Style App in der Windows Registry

Es gibt jedoch auch eine ganze Reihe von Unterschieden, die zeigen, dass WinRT viel mehr ist, als das klassische COM. Im Folgenden sehen Sie eine kleine Zusammenstellung exemplarischer Beispiele dafür:

  • Metadaten spielen in WinRT eine große Rolle. Alle WinRT-Komponenten (auch die von Windows, die man unter Windows 8 im Ordner C:WindowsSystem32WinMetadata findet) müssen Metadaten über die von ihnen angebotenen Klassen, Interfaces, Methoden etc. veröffentlichen. Microsoft hat dafür das existierende Metadatenformat von .NET [8] übernommen und minimal erweitert. Metadaten von WinRT-Objekten werden als .winmd-Dateien gespeichert. Selbst zur Laufzeit kann auf die Metadaten von WinRT-Objekten mithilfe der von jedem WinRT-Objekt zu implementierenden Schnittstelle IInspectable (Erweiterung von IUnknown, für Details siehe [9]) zugegriffen werden. Dieser Fokus auf Metadaten spielt einerseits bei den Language Projections von WinRT (Details dazu siehe unten) und andererseits in Visual Studio zur Entwicklungszeit (z. B. für IntelliSense) eine entscheidende Rolle. Abbildung 2 zeigt links IntelliSense in JavaScript. Die Grundlage dafür sind die WinRT-Metadaten für das rechts dargestellte WinRT-Objekt, das in diesem Fall in C# entwickelt wurde.
  • WinRT definiert ein standardisiertes Set an Basisdatentypen, das weit über den klassischen COM-Standard hinausgeht (es enthält z. B. Interfaces für Collections) und teilweise auch davon abweicht (z. B. HSTRING statt den alten BSTR). Durch diesen Standard bei den Datentypen können unterschiedlichste Programmierplattformen wie C++, .NET und JavaScript problemlos Daten austauschen.
  • In-process-Aktivierung von WinRT-Objekten über App-Grenzen hinweg wird nicht mehr unterstützt. Wollen zwei Apps Daten austauschen, muss der Datenaustausch über vom Betriebssystem definierte Contracts (z. B. Share, Search etc. technisch als Interfaces implementiert) erfolgen. Diese Festlegung soll zu einem stabileren Windows führen und Apps vor Programmfehlern anderer Apps schützen.
  • Die gerade erwähnten Contracts sind nicht nur ein Mittel zum Datenaustausch. Selbst der Start einer App erfolgt über einen Contract (Launch-Contract). Contracts werden von Windows auch verwendet, um mit einer App zu kommunizieren, die gerade nicht ausgeführt wird (z. B. wenn eine andere App den Share Contract verwendet, um Daten an sie zu senden).
  • Auf gewisse Funktionen des Betriebssystems haben Sie nie direkten Zugriff. Ihre App erhält nur ein Proxy-Objekt, der eigentliche Code wird jedoch in einem eigenen Prozess (RuntimeBroker) ausgeführt. Er überprüft, ob ihre App überhaupt die Erlaubnis hat, die angeforderte Operation durchzuführen. Das geschieht oft dadurch, dass der Anwender z. B. um Erlaubnis gefragt wird (z. B. bei Zugriff auf die WebCam).
Abb. 2: IntelliSense in JavaScript für eine WinRT-Komponente, geschrieben in C#
Abb. 2: IntelliSense in JavaScript für eine WinRT-Komponente, geschrieben in C#

Zusammenfassend kann man sagen, dass die Laufzeitumgebung von WinRT eine deutliche Weiterentwicklung des bekannten COM-Standards ist. Oft hört man die Aussage, dass WinRT eigentlich nichts anderes als COM sei. Das ist falsch. Eine Laufzeitumgebung für Apps zu bilden ist nur eine Aufgabe der WinRT. Der zweite Teil sind die Language Projections.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -