In den letzten Wochen gab es mehrere Ankündigungen von Microsoft, die die bisherige Richtung in Bezug auf die Windows-Entwicklung teilweise umkehren. Kurz gesagt, Microsoft spielt das Modell der universellen Windows-Plattform herunter (wenn es nicht vollständig veraltet ist).

Hier einige relevante Links:

• Microsoft veröffentlicht Details zur Migration von UWP zu Win32, aber es ist wahrscheinlich nicht das, was Sie denken  https://www.windowscentral.com/microsoft-publishes-uwp-win32-migration-details
• UWP nicht mehr in Mode, da Microsoft Anleitungen zum Migrieren von Apps zum Windows App SDK veröffentlicht  https://www.neowin.net/news/uwp-no-longer-fashionable-as-microsoft-releases-guidance-for-migrating-apps-to -windows-app-sdk/
• Microsoft stellt UWP offiziell ein  https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp

UWP ist seit der Veröffentlichung von Windows 8 der Schwerpunkt der Anwendungsentwicklung für Microsoft und ersetzte den Fokus auf die .NET-Architektur als Windows-Entwicklungsplattform.

Dies ist aus der Sicht von Entwicklern (und Entwicklern von Entwicklungstools wie Embarcadero) eine sehr interessante Entwicklung, die sich weiterhin auf das klassische native Windows-Entwicklungsmodell konzentriert haben, da wir nach sehr langer Zeit wieder erstklassige Bürger sind.

Von native zu .NET und UWP

Viele Jahre lang galt das native Entwicklungsmodell, das auf der Einbeziehung der klassischen Windows-API und der Nutzung der drei Kernbibliotheken Kernel/User/GDI und all ihrer Erweiterungen basiert, als veralteter Ansatz, der bald aufgegeben werden sollte. Dies ist das klassische Modell, das von Delphi und C++Builder (mit der VCL-Bibliothek), aber auch von Visual C++ (mit der MFC-Bibliothek) verwendet wird.

Windows-Entwickler wurden zunächst ermutigt, auf .NET umzusteigen (mit der Idee, dass die zukünftigen Plattform-APIs .NET erfordern würden und klassische Anwendungen irgendwann nicht mehr unter Windows laufen würden). Im Laufe der Zeit wurde klar, dass dies nicht der Fall sein würde.

Als sich der .NET-zentrierte Fokus verlangsamte, begann Microsoft, die nächste Idee voranzutreiben: die universelle Windows-Plattform. Dies wurde in erster Linie von zwei Ideen angetrieben: Zum einen die Möglichkeit, dieselbe Anwendung auf einem Desktop-PC auszuführen, aber auch ein Windows-Telefon, eine Spielekonsole und eine Visiertechnologie; zweitens eine sicherere Plattform mit eingeschränktem Zugriff auf das zugrunde liegende Betriebssystem. Auf API-Ebene bedeutete die Unterstützung von UWP die Verwendung der WinRT-Plattform-APIs, die anders und mit den klassischen APIs nicht kompatibel waren.

UWP holte nur langsam auf. Für Delphi und RAD Studio gab es keine Option, aber auch die Migration von Visual C++ und .NET und C# würde die Verwendung unterschiedlicher Laufzeitbibliotheken und unterschiedlicher UI-Steuerelemente erfordern – was eine umfassende Neufassung einer bestehenden Anwendung bedeutet. Als Windows 8 zum ersten Mal ausgeliefert wurde (das immer noch klassische API-Anwendungen zulässt), waren nur sehr wenige UWP-Apps verfügbar, auch von Microsoft. Einige der neuen Plattformfunktionen waren jedoch nur über die WinRT-APIs verfügbar, weshalb Entwickler und Tools (einschließlich RAD Studio) Optionen zum Aufrufen von WinRT-APIs aus einer klassischen Anwendung heraus entwickelt haben. Mit diesem Ansatz wird beispielsweise die Unterstützung von Windows-Benachrichtigungen von RAD Studio implementiert.

Während Microsoft weiterhin auf UWP drängte und darauf hinwies, dass klassische Apps veraltet sein würden, hörten die Entwickler nicht wirklich zu. Der nächste Schritt war die Förderung der sogenannten „Desktop Bridge“, d. h. die Möglichkeit für native Anwendungen, mehr der WinRT-APIs zu nutzen und für zusätzliche Sicherheit in einem leichten Container „verpackt“ zu werden. Diese letzte Funktion wurde erreicht, indem eine Anwendung als APPX und später als MSIX verpackt wurde. Auch hier bietet RAD Studio diese Unterstützung seit langem direkt in der IDE an.

Microsoft beschrieb die Bridge ursprünglich als eine Möglichkeit, Anwendungen zu UWP zu migrieren, was immer noch das Unternehmensziel war. Entwickler können ihre Anwendung um ein Formular nach dem anderen verschieben. Es wurde schnell klar, dass Entwickler kein wirkliches Interesse daran hatten, ihre großen Codebasen zu konvertieren, sondern daran interessiert waren, alle Plattformfunktionen zu nutzen. APPX und MSIX öffneten auch die Tore des Microsoft Store für traditionelle Anwendungen.

Schneller Vorlauf zum letzten Jahr oder so. Microsoft kündigte Project Reunion (jetzt umbenannt in Windows App SDK) mit dem Ziel an, vollständige Interoperabilität für UWP-Anwendungen zum Aufrufen nativer APIs und native Anwendungen zum Aufrufen beliebiger UWP-APIs zu bieten jetzt hinter sich gelassen – darauf deuten die obigen Ankündigungen hin.

Zurück zu Einheimischen

Mit anderen Worten, nach über 15 Jahren, in denen Microsoft native Windows-Anwendungen als zweitklassige, bald verstorbene Bürger betrachtete, haben wir jetzt eine völlige Umkehrung der Position. Native Apps oder klassische API-Apps werden bleiben und erhalten Priorität im Zusammenhang mit Modernisierung, Unterstützung neuer APIs, Windows 11-Unterstützung usw. Microsoft plant, UWP-Zustimmungen und APIs in die native Welt zu bringen.

Dies geschieht zunehmend, zum Beispiel mit dem WebView 2-Control (Chromium Edge embedded, das Delphi und C++Builder umhüllen und unterstützen), eine COM-Komponente. Andere neue APIs verwenden ebenfalls COM, während andere nativ sind und einige auf WinRT basieren – aber von nativen Anwendungen aus zugänglich sind.

Wenn das native API-Modell bestehen bleibt, sind dies fantastische Neuigkeiten für Delphi und C++Builder. Dies ist nicht nur das Modell, dem Embarcadero immer höchste Priorität eingeräumt hat (nun, mit Ausnahme der kurzen Delphi .NET-Ära), sondern es ist auch das Modell, das wir im Laufe der Zeit viel mehr erweitert und erweitert haben als unsere Wettbewerber ihre Bibliotheken.

Wenn Sie die alternativen UI-Frameworks betrachten, die die klassische API verwenden, wie die MFC-Bibliothek oder die WinForms-Bibliothek, wurden sie von Microsoft viel weniger fokussiert und verbessert als die VCL-Bibliothek. Von zusätzlichen UI-Steuerelementen bis hin zu eingebetteten WinRT- und Reunion-Steuerelementen, von der Unterstützung für High DPI bis zum UI-Styling wurde die VCL-Bibliothek viel schneller erweitert als konkurrierende native Bibliotheken.

Aus diesem Grund gilt RAD Studio heute einmal mehr als die beste verfügbare Lösung zum Erstellen nativer Windows-Clientanwendungen. Darüber hinaus bietet es eine erstaunlich einfache Migration für 10 oder 20 Jahre alte Codebasen, die mit anderen Angeboten ihresgleichen sucht.

Es ist schön, ein Delphi- und C++Builder-Entwickler zu sein und jetzt erstklassige Windows-Anwendungen zu entwickeln, ohne befürchten zu müssen, dass Microsoft das Anwendungsmodell in der nächsten Windows-Version veraltet.