Microsoft Build 2020: Microsoft will Windows APIs wiedervereinen
(Bild: g0d4ather/Shutterstock.com)
Microsoft will Windows Runtime und Windows 32, die seit Windows 8 getrennten Windows-Programmierschnittstellen, wieder zusammenführen.
"Project Reunion" nennt Microsoft den ehrgeizigen, jetzt auf der Build-Konferenz vorgestellten Plan zur Wiedervereinigung von Windows Runtime (WinRT) und Windows 32 (Win32), den seit Windows 8 getrennten Programmierschnittstellen des Windows-Betriebssystems.
Bei der Ankündigung von Windows 8 im Jahr 2011 war die Überraschung in der Entwicklergemeinde groß [12], als Microsoft mit der Windows Runtime API (WinRT) einen Nachfolger für die Windows 32 API (Win32) ankündigte, der nicht auf .NET, sondern auf dem angestaubten Component Object Model (COM) basierte. Seitdem ist Windows bei den Programmierschnittstellen und den Anwendungsmodellen zweigeteilt in die klassischen Windows-Anwendungen auf dem Windows-Desktop und die modernen Windows-Apps. Letztere hießen ursprünglich "Metro Apps", dann "Modern Apps" und seit Windows 10 schließlich "Universal Windows Platform" (UWP) Apps.
Bemühungen seit einigen Jahren
Microsoft hat die ursprünglich stark getrennten Welten bereits in den letzten Jahren zusammengeführt. Die WinRT-Apps laufen schon lange nicht mehr ausschließlich im Vollbildmodus, sondern wirken wie normale Windows-Fenster. UWP-Apps können seit Windows 10, Version 1709, auch als 2-Tier-Anwendungen direkt auf Datenbanken zugreifen. Zuvor war nur eine 3-Tier-Architektur mit dem Umweg über Webservices möglich. Seit Version 1903 können Entwickler über sogenannte "XAML Islands", angekündigt auf der Build 2018 [13], UWP-Steuerelemente in klassische Windows-Anwendungen einbetten, die mit Microsoft Foundation Classes (MFC), Windows Forms oder Windows Presentation Foundation (WPF) erstellt wurden.
Trotz aller Vereinheitlichungen gibt es immer noch gravierende Unterschiede: UWP-Apps laufen in einer Sandbox mit beschränktem Zugang zu APIs, Netzwerk und Ressourcen. Während die Win32-Welt auf die Programmierschnittstellen von WinRT zugreifen kann, ist das umgekehrt nur eingeschränkt möglich [14] beziehungsweise über extra zu programmierende Bridge-Komponenten möglich.
Großspurige Ankündigungen
Das nun angekündigte Project Reunion besteht zunächst aus einer GitHub-Seite mit großspurigen Ankündigungen [15] ("make it easier to build great apps that work across all the Windows 10 versions" und "unify access to existing Win32 and UWP APIs"). Microsoft will die bestehenden APIs vom Betriebssystemversionen entkoppeln (d. h. rückwärtskompatibel machen), aus dem Windows Platform SDK auslagern (in NuGet-Pakete) und dabei auch neue APIs erschaffen, die dann nicht nur in der .NET-Welt in Windows Forms, WPF und UWP-Apps, sondern auch in C++ und anderen Frameworks wie React Native nutzbar sein sollen. Die Rückwärtskompatibilität bezieht sich aber ausdrücklich auf die Versionen von Windows 10, nicht auf ältere Betriebssysteme wie Windows 8.x.
Zentraler Baustein des Project Reunion ist die "Windows UI Library 3" (WinUI 3), eine neue Benutzeroberflächenbibliothek, die eine Weiterentwicklung der UWP-Steuerelemente darstellt. Nach zwei Alpha-Versionen im September 2019 und Februar 2020 ist nun eine erste Preview-Version erschienen, die erst mal nicht nur auf WinRT läuft, sondern auch auf Win32.
Während UWP allein auf der WinRT-API aufsetzt und daher nicht alle Funktionen des Betriebssystems und alle lokalen Ressourcen verwenden kann, kann eine WinUI-3-basierte Anwendung wahlweise WinRT und/oder Win32 nutzen. Damit stehen ihr alle Möglichkeiten des Windows-Betriebssystems zur Verfügung. Im Fall von WinRT läuft WinUI 3 auf Basis von .NET Native, im Fall von Win32 setzt WinUI 3 auf der Vorschauversion von .NET 5.0 auf. Die Entwicklung von WinUI-3-Oberflächen ist derzeit mit C++ und C# möglich; die Unterstützung für Rust ist in Arbeit [16]. Eine Installation von WinUI 3 erfolgt derzeit über Visual-Studio-Erweiterungen [17], die Visual Studio 2019 in der Version 16.7 Preview erfordert; ein XAML-Designer ist allerdings bisher nicht für WinUI 3 verfügbar, da alle Klassen den neuen Namensraum Microsoft.UI anstelle von Windows.UI verwenden.
Während in UWP die Weiterentwicklung der Steuerelemente mit neuen Betriebssystemversionen erfolgte, sind die komplett in C++ als Open Source auf GitHub [18] geschriebenen WinUI-3-Steuerelemente vom Betriebssystem entkoppelt; eine WinUI-3-Anwendung läuft daher auf allen Windows 10-Versionen ab dem Creators Update aus dem Frühjahr 2017. Andere Frameworks wie .NET MAUI [19], React Native for Windows [20] und Uno [21] sollen auf WinUI 3 aufsetzen.
WebView 2
WinUI 3 soll die aus WPF bekannte Eingabevalidierung mit der Schnittstelle INotifyDataErrorInfo bieten. Die bereits seit 2019 in UWP verfügbare Einbettung von Steuerelementen in ältere GUI-Frameworks wie Microsoft Foundation Classes (MFC), Windows Forms und Windows Presentation Foundation (WPF) gibt es auch in WinUI 3. Zukünftig wird Microsoft dreimal jährlich neue Funktionen für WinUI 3 veröffentlichen. Es gibt ein GitHub-Repository zu WinUI, es umfasst aber noch den Vorgänger WinUI 2, der nur auf WinRT läuft.
Als neues Steuerelement wird Microsoft ein Browsersteuerelement (WebView 2) [22] zur Einbettung von Browser-Inhalten in Windows-Anwendungen liefert (z. B. für hybride Anwendungen, die HTML zum Rendering von Desktop-Anwendungen verwenden). WebView 2 basiert auf Microsoft Edge Chromium und soll auch außerhalb von WinUI 3 ab Windows 7 für Anwendungen mit .NET Framework und .NET Core (Windows Forms und WPF) sowie MFC verfügbar sein.
Bessere Interoperabilität zwischen WinRT und .NET
Als Basis für Project Reunion will der Hersteller in .NET 5.0 die Interoperabilität zwischen .NET und der WinRT verbessern. Grundsätzlich ist diese Interoperabilität schon zu Zeiten von .NET Framework und Windows 8 möglich gewesen (siehe Pfeile zwischen den beiden Seiten in der ersten Abbildung).
WinRT stellt dafür bisher Metadatendateien mit der Dateinamenserweiterung .winmd im Ordner C:\Windows\System32\WinMetadata bereit. In .NET 5.0 will Microsoft diese Interoperabilität komplett überarbeiten [23]. Das neue Modell basiert auf einem neuen Werkzeug (C#/WinRT [24]), das die Windows-Entwicklungsgruppe bereitstellt. Microsoft greift dabei auf die seit .NET Framework 1.0 bestehenden Runtime Callable Wrapper (RCW) und COM Callable Wrapper (CCW) zurück. Das neue Verfahren soll unabhängig von der .NET Runtime sein, die Konzepte von COM und WinRT verstecken, und sowohl Unterstützung für mehr C#-Features als auch den Intermediate Language Linker (IL Linker) und Ahead-of-Time-Kompilierung (AOT) bieten. Microsoft stellt die WinRT-Operabilität zukünftig nicht mehr als Teil der Betriebssysteminstallation, sondern als Windows SDK .NET Package auf NuGet.org [25] bereit.
Keine 100-Prozent-Kompatibilität
Projekte, die WinRT nutzen, müssen beim Umstieg auf .NET 5.0 Referenzen auf .winmd-Dateien durch neue Referenzen auf die neuen .NET-Interop-Assemblies ersetzen und folglich neu kompiliert werden. Auch weitere Codeänderungen sind möglich. Auch in WinUI 3 kann es neben den Namensräumen Änderungen geben, die die am Code bestehender UWP-Apps erfordern.
Das Erscheinen der endgültigen Version von WinUI 3 war ursprünglich für den November 2020 zusammen mit .NET 5.0 angekündigt. Ryan Demopoulos, Principal Program Manager Lead bei Microsoft, erklärte jedoch im Build-2020-Vortrag "Everything you need to know about WinUI [26]" das aufgrund der COVID-19-Situation zu diesem Termin erst eine Preview 4 erscheinen wird und die RTM-Version auf 2021 verschoben ist. Die Preview 4 soll aber schon für den produktiven Einsatz erlaubt sein. Dies ist mit der Preview 1 derzeit nicht erlaubt. Diese besitzt noch einige technische Einschränkungen, zum Beispiel keine Unterstützung für XAML Islands. (ane [27])
URL dieses Artikels:
https://www.heise.de/-4724998
Links in diesem Artikel:
[1] https://www.heise.de/news/Microsoft-legt-Sourcen-fuer-GW-BASIC-Interpreter-offen-4726428.html
[2] https://www.heise.de/news/Kommentar-So-kann-Microsoft-die-Abwanderung-von-NET-Entwicklern-nicht-stoppen-4725901.html
[3] https://www.heise.de/news/Microsoft-Build-2020-Blazor-WebAssembly-ist-fertig-4725818.html
[4] https://www.heise.de/news/Microsoft-baut-Top-5-Supercomputer-mit-10-000-GPU-Beschleunigern-4725457.html
[5] https://www.heise.de/news/Microsoft-Build-2020-Vierte-Preview-von-NET-5-0-und-weitere-Ausblicke-4725047.html
[6] https://www.heise.de/news/Microsoft-Build-2020-C-9-0-mit-viel-Fingerkuppenschonung-4725001.html
[7] https://www.heise.de/news/Microsoft-Build-2020-Microsoft-will-Windows-APIs-wiedervereinen-4724998.html
[8] https://www.heise.de/news/Microsoft-Build-2020-Neue-Werkzeuge-fuer-Windows-Entwickler-4723981.html
[9] https://www.heise.de/news/Build-2020-Aus-Xamarin-Forms-wird-MAUI-4724947.html
[10] https://www.heise.de/news/Microsoft-Build-Neues-bei-Teams-WSL-und-PowerToys-4723951.html
[11] https://www.heise.de/news/Build-2020-Was-Entwickler-erwarten-koennen-4723752.html
[12] https://www.heise.de/hintergrund/Windows-8-Apps-benoetigen-neue-Windows-Runtime-1344071.html
[13] https://www.heise.de/news/Build-2018-Microsoft-kuendigt-Windows-Desktopprogrammierung-fuer-NET-Core-3-0-an-4044476.html
[14] https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-and-com-for-uwp-apps
[15] https://github.com/microsoft/ProjectReunion
[16] https://github.com/microsoft/winrt-rs
[17] https://marketplace.visualstudio.com/items?itemName=Microsoft-WinUI.WinUIProjectTemplates
[18] https://github.com/microsoft/microsoft-ui-xaml
[19] https://www.heise.de/news/Build-2020-Aus-Xamarin-Forms-wird-MAUI-4724947.html
[20] https://github.com/microsoft/react-native-windows
[21] https://platform.uno/
[22] https://docs.microsoft.com/en-us/microsoft-edge/webview2/
[23] https://github.com/dotnet/runtime/issues/35318
[24] https://github.com/microsoft/cswinrt
[25] https://www.nuget.org/packages/microsoft.windows.sdk.net
[26] https://mybuild.microsoft.com/sessions/b0300eb4-a462-48ec-956d-7caa18470e3c?source=schedule
[27] mailto:ane@heise.de
Copyright © 2020 Heise Medien