Au cours des deux dernières semaines, il y a eu plusieurs annonces de Microsoft qui ont partiellement inversé les directions passées en termes de développement de Windows. En bref, Microsoft minimise (sinon désapprouve complètement) le modèle de plate-forme Windows universelle.

Voici quelques liens pertinents :

• Microsoft publie les détails de la migration UWP vers Win32, mais ce n’est probablement pas ce que vous pensez  https://www.windowscentral.com/microsoft-publishes-uwp-win32-migration-details
• L’UWP n’est plus à la mode alors que Microsoft publie des conseils pour la migration des applications vers Windows App SDK  https://www.neowin.net/news/uwp-no-longer-fashionable-as-microsoft-releases-guidance-for-migrating-apps-to -windows-app-sdk/
• Microsoft désapprouve officiellement UWP  https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp

UWP a été l’objectif de développement d’applications pour Microsoft depuis la sortie de Windows 8, et il remplaçait l’accent mis sur l’architecture .NET en tant que plate-forme de développement Windows.

C’est maintenant une évolution très intéressante du point de vue des développeurs (et des fournisseurs d’outils de développement comme Embarcadero) qui sont restés concentrés sur le modèle de développement Windows natif classique, car nous sommes à nouveau des citoyens de première classe après très longtemps.

De natif à .NET et UWP

Pendant de nombreuses années, le modèle de développement natif basé sur l’implication de l’API Windows classique et l’exploitation des trois bibliothèques noyau/utilisateur/GDI et de toutes leurs extensions a été considéré comme une approche obsolète et obsolète qui serait bientôt abandonnée. C’est le modèle classique utilisé par Delphi et C++Builder (avec la bibliothèque VCL), mais aussi par Visual C++ (avec la bibliothèque MFC).

Les développeurs Windows ont d’abord été encouragés à migrer vers .NET (avec l’idée que les futures API de plate-forme nécessiteraient .NET et que les applications classiques cesseraient à un moment donné de fonctionner sur Windows). Au fil du temps, il est devenu clair que ce ne serait pas le cas.

Alors que l’accent mis sur .NET ralentissait, Microsoft a commencé à pousser l’idée suivante : la plate-forme Windows universelle. Cela était principalement motivé par deux idées : l’une, la possibilité d’exécuter la même application sur un PC de bureau, mais aussi un téléphone Windows, une console de jeu et une technologie de visière ; deux, une plate-forme plus sécurisée avec un accès limité au système d’exploitation sous-jacent. Au niveau des API, la prise en charge de l’UWP impliquait d’utiliser les API de la plateforme WinRT, différentes et incompatibles avec les API classiques.

UWP a mis du temps à rattraper son retard. Pour Delphi et RAD Studio, il n’y avait pas d’option, mais la migration de Visual C++ et .NET et C# impliquerait également l’utilisation de différentes bibliothèques d’exécution et de différents contrôles d’interface utilisateur, ce qui représente une réécriture importante d’une application existante. Lorsque Windows 8 a été lancé pour la première fois (autorisant toujours les applications API classiques), très peu d’applications UWP étaient disponibles, y compris celles de Microsoft. Cependant, certaines des nouvelles fonctionnalités de la plate-forme n’étaient disponibles que via les API WinRT, c’est pourquoi les développeurs et les outils (RAD Studio inclus) ont proposé des options pour appeler les API WinRT à partir d’une application classique. La prise en charge des notifications Windows de RAD Studio, par exemple, est implémentée avec cette approche.

Alors que Microsoft continuait à pousser pour UWP, indiquant que les applications classiques allaient être obsolètes, les développeurs n’ont pas vraiment écouté. L’étape suivante consistait à promouvoir ce que l’on appelle le « Desktop Bridge », c’est-à-dire la possibilité pour les applications natives d’exploiter davantage les API WinRT et d’être « packagées » dans un conteneur léger pour plus de sécurité. Cette dernière fonctionnalité a été réalisée en empaquetant une application en tant qu’APPX et plus tard MSIX. Encore une fois, RAD Studio propose depuis longtemps ce support directement dans l’IDE.

Microsoft a initialement décrit le pont comme un moyen d’aider à migrer les applications vers UWP, ce qui était toujours l’objectif de l’entreprise. Les développeurs pouvaient déplacer leur application un formulaire à la fois. Il est rapidement devenu évident que les développeurs n’avaient pas vraiment d’intérêt à convertir leurs grandes bases de code, mais étaient intéressés par l’utilisation de toutes les fonctionnalités de la plate-forme. APPX et MSIX ont également ouvert les portes du Microsoft Store pour les applications traditionnelles.

Avance rapide jusqu’à l’année dernière. Microsoft a annoncé Project Reunion (maintenant rebaptisé Windows App SDK) dans le but d’offrir une interopérabilité complète aux applications UWP pour appeler des API natives et des applications natives pour appeler n’importe quelle API UWP – mais a fini par donner aux applications natives une priorité beaucoup plus élevée, avec UWP maintenant laissé pour compte – ce que les annonces ci-dessus indiquent.

Retour à Natif

Donc, en d’autres termes, après plus de 15 ans au cours desquels Microsoft a considéré les applications Windows natives comme des applications Windows de seconde classe, bientôt des citoyens disparus, nous avons maintenant un renversement total de position. Les applications natives, ou applications API classiques, sont là pour rester et sont prioritaires dans le cadre de la modernisation, de la prise en charge des nouvelles API, de la prise en charge de Windows 11, etc. Microsoft prévoit d’apporter les consentements et les API UWP au monde natif.

Cela se produit de plus en plus, par exemple avec le contrôle WebView 2 (Chromium Edge intégré, que Delphi et C++Builder enveloppent et prennent en charge), un composant COM. D’autres nouvelles API utilisent également COM, tandis que d’autres sont natives et certaines sont basées sur WinRT, mais accessibles à partir d’applications natives.

Si le modèle d’API natif est là pour rester, c’est une excellente nouvelle pour Delphi et C++Builder. Non seulement c’est le modèle auquel Embarcadero a toujours accordé la priorité absolue (enfin, à l’exception de la courte ère Delphi .NET), mais c’est aussi le modèle que nous avons étendu et étendu au fil du temps bien plus que nos concurrents ne l’ont fait avec leurs bibliothèques.

Si vous considérez les frameworks d’interface utilisateur alternatifs qui utilisent l’API classique, comme la bibliothèque MFC ou la bibliothèque WinForms, ils ont reçu beaucoup moins d’attention et d’améliorations de Microsoft que la bibliothèque VCL. Des contrôles d’interface utilisateur supplémentaires aux contrôles intégrés WinRT et Reunion, de la prise en charge de High DPI au style d’interface utilisateur, la bibliothèque VCL n’a cessé de se développer à un rythme beaucoup plus rapide que les bibliothèques natives concurrentes.

C’est pourquoi RAD Studio se positionne aujourd’hui une fois de plus comme la meilleure solution disponible pour créer des applications clientes Windows natives. Non seulement cela, mais il offre une migration étonnamment facile pour les bases de code de 10 ou 20 ans, sans précédent par d’autres offres.

C’est agréable d’être un développeur Delphi et C++Builder et de créer des applications Windows de première classe, maintenant sans même avoir à craindre que Microsoft ne désapprouve le modèle d’application dans la prochaine version de Windows.