Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

WinRT : les bases

[new:30/09/2012]WinRT est au cœur de la nouvelle plateforme Windows 8. Beaucoup de rumeurs, d’attente aussi ont laissé s’installer une méconnaissance donnant l’impression d’un flou alors que tout cela est naturel : WinRT n’est pas encore sorti ! Maintenant que Windows 8 va sortir, que les RTM vont être distribuées, il est temps de préciser les choses. Qu’est-ce que WinRT ?

WinRT

C’est un nouveau modèle de programmation, un nouveau framework qui permet de construire des applications Metro Style (qu’on appelle aujourd’hui Windows 8 App) en utilisant le langage de votre choix, qu’il s’agisse d’un langage managé (C# ou VB.NET), C++ ou JavaScript.

J’utiliserai encore souvent le terme Metro ou Metro Style ici pour parler des applications Windows 8 écrites sous WinRT et respectant la charte graphique particulière appelée Metro jusqu’à maintenant. Vous le savez, ce nom est abandonné faute d’un accord avec Metro AG en Allemagne. Mais je ne suis qu’un blogger indépendant et non un employé de MS, Metro AG ne pourra m’interdire de parler de ce que je veux en l’appelant comme je le veux. Lorsque Microsoft aura imposé une appellation non ambigüe comprise par tous comme l’était Metro Style, j’en ferai usage. Ici je maintiendrais encore le terme Metro pour éviter toute confusion.

WinRT permet aux développeurs de construire des applications qui utilisent massivement les services et fonctionnalités exposées par Windows, ce qui était assez difficile auparavant il faut bien le dire (malgré l’avancée énorme qu’à représenté .NET sur ce point).

Ci-dessous vous pouvez voir le célèbre diagramme qui a fait peur à autant de monde qu’il en a soulagé...

image

Ce diagramme montré au Build de septembre dernier a été commenté en long et en large mais pas forcément de façon constructive et technique.

On note surtout que WinRT (Windows Runtime APIs) est une couche fine qui repose directement sur le noyau de l’OS pour en exposer les fonctions. Ces fonctions peuvent être utilisées par toutes les applications “Metro”, depuis tous les langages.

Dans ce contexte Microsoft parle de “language projection”, ce qui permet d’utiliser WinRT d’une façon qui semble native à tous les langages supportés.

Pour un développeur .NET, utiliser WinRT est très proche de l’écriture de code .NET. Les concepts habituels tels que les constructeurs, les propriétés, le développement asynchrone, et la grande majorité des autres spécificités de .NET sont les mêmes lorsqu’on écrit une application WinRT.

Le schéma ci-dessus nous montre que XAML est programmable aussi bien depuis C# et VB.NET que depuis C/C++ alors que JavaScript ne peut être utilisé que pour créer des applications utilisant Html/Css (pour l’instant il n’y a pas de de support pour la syntaxe Razor et rien n’est indiqué en ce sens).

WinRT expose un nombre assez impressionnant de fonctions aux applications Metro. Un grand nombre de choses qui se programmaient via .NET est aujourd’hui pris en charge par WinRT.

Des choses comme les I/O, l’accès aux services, et même Xaml lui-même sont devenues des parties intégrantes de WinRT.

Le schéma suivant montre les fonctions couvertes par WinRT :

image

Architecture

Le schéma suivant montre un vue simplifiée de l’architecture de WinRT :

image

A la base nous trouvons Windows et son noyau. Directement au dessus se trouvent les blocs de base de WinRT.

Il s’agit d’une plateforme vraiment énorme, plus grosse encore que le framework .NET complet. Plus complexe. Malgré tout chaque langage avec ses spécificités utilise tout ce potentiel de façon native.

Les Métadonnées

La gestion des métadonnées est visible sur la gauche du schéma précédent. Les Windows Metadata (aussi appelées WinMD) sont des fichiers assez similaires aux fichiers de métadonnées de .NET. Sous WinRT, WinMD est conceptuellement identique : ces fichiers décrivent ce qu’un composant WinRT peut faire. Cela diffère de .NET dans le sens où il s’agit bien ici d’un fichier séparé (sous .NET les métadonnées sont stockées dans l'assemblage lui-même). Les WinMD sont installés avec Windows 8 et sont utilisés par exemple par Intellisense quand on écrit des applications Metro dans Visual Studio.

Les fichiers WinMD sont stockés dans Windows\System32\WinMetaData.

On peut les ouvrir avec ILDASM. On découvre alors toute l’influence de .NET sur WinMD.

Toutes les classes WinRT sont dans le namespace Windows.*, point d’entré principal vers ce gigantesque univers d’APIs.

La projection des langages

Le terme a été évoqué plus haut. WinRT est écrit en c++ natif. Etant natives, les APIs de WinRT auraient normalement du être appelées en utilisant du code d’interop (COM).

Or, la plupart des développeurs n’aiment pas COM. Mais heureusement pour eux Microsoft l’a compris ! Ils ne nous ont donc pas donné les APIs natives comme framework de base. A la place nous avons la projection des langages. Il faut entendre par là une technique permettant d’utiliser les composants natifs d’une façon naturelle et familière pour chaque langage. Microsoft ne force personne à apprendre ou utiliser un nouveau langage. Ils ont simplement “projeté” WinRT dans chaque langage que nous connaissons déjà.

De fait, les applications Windows 8 “Metro” sont écrites en utilisant soit un langage managé, soit C++ ou JavaScript. Pour les applications bureau classique de Windows 8 rien ne change comme le montre le premier schéma, on utilise soit du managé avec .NET, soit du natif avec C/C++ soit du Silverlight; soit de l’Html pour les documents de type Web visibles avec un navigateur.

Finalement, s’il n’y avait pas la norme de présentation très spécifique de Metro style, Windows 8 n’apparaitrait être qu’une nouvelle version de Windows 7 se programmant avec exactement les mêmes langages (managés ou non, Silverlight, WPF, Html/Js, C++ etc). La couche WinRT ainsi que l’aspect fortement normatif de l’interface Metro créent la nouveauté, le reste en fait ne change que peu.

D’un autre côté, les changements dans l’OS sont réels et nombreux et si nous avons cette impression de continuité c’est parce que Microsoft a justement tout fait pour ne pas bouleverser les habitudes des développeurs ! Il ne faudrait pas comprendre le problème à l’envers en prenant cet immense effort de continuité comme l’expression naïve d’un non changement ou d’un heureux hasard.

Tout a changé, mais tout a été fait pour que ces changements impactent le moins possible nos habitudes. Voilà ce qu’est WinRT.

Le runtime broker

Le broker est responsable du contrôle des applications Metro. Par exemple il est essentiel pour la sécurité de vérifier qu’une application déclare correctement ses capacités, comme accéder au répertoire “Mes Images” par exemple, et qu’elle les montre bien à l’utilisateur en lui permettant de les autoriser ou des les refuser. Accéder à une Webcam demandera à la fois de le déclarer convenablement et d’être accepter par l’utilisateur par exemple, c’est le broker qui s’assure de tout cela pour la sécurité de l’OS et de l’utilisateur.

Si WinRT n’est pas managé, il s’apparente par certains contrôles à un environnement managé. Le broker est l’élément clé de cette surveillance des applications.

Asynchronisme

Windows 8 est présenté comme un OS “rapide, fluide et réactif”. Et de ce qu’on peut tester aujourd’hui c’est plutôt vrai. Microsoft met très en avant les performances de son nouvel OS. Ils veulent que les utilisateurs aient une expérience fluide et réactive même sur des machines qui ne le sont pas forcément. Pour la première d’ailleurs passer à une nouvelle version de Windows n’implique pas forcément acheter une machine plus puissante avec plus de Ram. Windows 8 peut même redonner vie à des machines anciennes. Je l’ai testé avec succès.

Il n’y a pas des milliers de solutions à cette équation... l’asynchronisme est l’unique issue.

Cela implique que les développeurs fassent beaucoup d’efforts pour comprendre et utiliser l’asynchronisme de WinRT. Car une limite fatidique a présidé à la conception des APIs : Tout code pouvant durer plus de 50 millisecondes fait l’objet d’une API asynchrone sans option pour une version synchrone.

C’est radical, le curseur n’a pas été réglé très haut, et le couperet tombe vite. Un nombre important d’APIs de WinRT se trouvent donc être asynchrones.

Par exemple tous les accès à des fichiers sont asynchrones car potentiellement qu’il s’agisse de la création, de l’accès ou de la modification d’un fichier sur disque dur, SSD ou autre, tout cela peut prendre plus de 50ms.

Une telle programmation avec les langages que nous possédons aujourd’hui serait un véritable enfer. Heureusement, Microsoft a anticipé cet inconvénient en introduisant async et await dans C#. Cela permet de traiter les APIs asynchrones de façon simple et performante.

Nous verrons souvent dans de prochains billets sur la programmation WinRT a quel point ces nouveaux mots clé sont utilisés souvent.

Quel est le contenu de WinRT ?

Une fois posés les fondamentaux de WinRT, ses fonctions, son architecture, il est intéressant de se demander ce qu’il a dans la boite en tout cas pour un développeur .NET ...

J’ai posté la liste des APIs de WinRT dans un précédent billet (Metro Style / WinRT : les APIs), j’invite le lecteur à s’y référer pour regarder chaque namespace et son contenu.

Dans ma série “De Silverlight à WinRT” en quatre parties (partie 1, partie 2, partie 3) j’expose aussi de nombreuses facettes de WinRT qui permettent de mieux en comprendre les rouages.

Enfin, dans le quatrième de volet de cette série je parle du projet “WinRT Genome Project” qui permet de comparer les APIs .NET à celles de WinRT, outil bien pratique pour trouver des équivalences et mesurer les différences entre les deux frameworks.

On comprend alors que la surface de WinRT est énorme et que dans de nombreux cas on écrira du code purement WinRT et non plus du code managé. Par exemple en Xaml, un simple contrôle de type Button ne se trouve plus dans System.Windows.Controls mais plutôt dans Windows.UI.Xaml. Comme expliqué plus haut, toutes les APIs WinRT sont dans le namespace “Windows.*”. Le button Xaml est donc un code purement WinRT et non plus .NET même lorsqu’on pense écrire du code managé C#/Xaml sous WinRT.

La question reste alors de savoir si on peut utiliser tout .NET dans une application WinRT C#/Xaml...

La réponse est non.

Le framework .NET a été au fil du temps “saucissonné” pour s’adapter à différents contextes et il existe en réalité déjà plusieurs frameworks .NET... Le complet, le client profile, celui de Silverlight, celui de Windows Phone.

Microsoft a créé différents “profils” d’utilisation de .NET, chacun ayant une surface adaptée à son contexte et possédant moins d’APIs que le framework complet, mais souvent en contrepartie des APIs spécialisées pour le contexte en question.

Windows 8 n’échappe pas à cette règle. Le framework .NET utilisable sous WinRT (et non pas celui du bureau classique, complet) n’est qu’un profil parmi les autres. Le schéma suivant résume la situation de façon évidente :

image

Dans ce profil particulier les namespaces suivants sont disponibles (sous réserve des modifications de la finale de Windows 8 qui arrive très bientôt) :

  • System.Collections
  • System.ComponentModel
  • System.Diagnostics
  • System.Dynamic
  • System.Globalization
  • System.IO
  • System.Linq
  • System.Net
  • System.Numerics
  • System.Reflection
  • System.Resources
  • System.Runtime
  • System.Security
  • System.ServiceModel
  • System.Text
  • System.Threading
  • System.Xml

Même si cette liste parait longue, le profil WinRT de .NET est assez compressé... Il est même plus petit que le profil .NET de Windows Phone ! Comme les applications Metro ciblent principalement le consommateur de base, tout ce qui concerne l’entreprise n’est pas couvert. Il n’y pas de support du mode Console, par d’intégration ASP.NET, pas d’Entity Framework... Gardez ces limites à l’esprit lorsque vous allez vous lancer sous WinRT !

D’un autre côté n’allez pas conclure que la liste ci-dessus résume tout ce qui est utilisable en C#/Xaml... Bien entendu que non : comme expliqué les applications managées ont aussi accès à tout WinRT via le namespace Window.* !

Mais certaines choses n'auront pas d’équivalent. Il faut en avoir conscience avant de se lancer dans une application.

Conclusion

Ce billet clos la série (en partie évoquée plus haut) de billets “génériques” consacré à WinRT. Je pense que les bases ont été posées et que chacun peut, grâce à ces papiers, se faire une idée relativement bonne de ce qu’est ou n’est pas WinRT et quelle forme prend la programmation sous cet environnement.

Dans de prochains billets j’aborderai la programmation elle-même des applications sous WinRT. Faites chauffer vos simulateurs, vérifiez vos machines virtuelles et l’installation des derniers outils de développement pour Windows 8, le moment va venir de mettre les mains dans la machine !

Mais je vais temporiser encore un peu les choses car beaucoup de développeurs n’ont pas encore accès à un environnement de développement Windows 8 final. Nous savons que d’ici la fin du mois (et dans quelques jours seulement pour un premier cercle) les RTM auront été diffusées à tous les MVP, tous les partenaires. Mais pas encore au public. Ceux d’entres vous qui ne font pas partie de ces premiers cerclent ne disposent au mieux que de la dernière CP.

Il y a des choses que je ne peux encore ni évoquer ni même laisser penser que je pourrais être au courant. Même cette phrase ambigüe, stricto sensu, pourrait être interprétée comme une violation de ces secrets.

Donc comment écrire des articles avec exemples de code alors que la version de Windows 8 et des outils de développement que je pourrais utiliser ne sont pas censés exister et que rien qu’évoquer le fait que je puisse y avoir accès est déjà un débordement passible des foudres Microsoftiennes ?

Le lecteur sera j’en suis sur compréhensif et devra attendre que certains secrets n’en soient plus pour que je puisse montrer ici des exemples de code et des captures d’écran sans danger de violer ma NDA.

Encore un peu de patience... J’ai plein d’autres choses à vous parler d’ici là, comme MonoDroid par exemple ou le développement sous Windows Phone 7.x car finalement pour couvrir le maximum de clients, au moins dans l’année à venir, mieux vaudra développer en mode 7.x compatible avec WP8 que de se lancer dans du pur WinRT pour smartphone en se coupant de la base actuelle d’utilisateurs... Et cela permettra même de parler de développement cross-plateforme entre WP7/WP8 et WinRT.

Plein de sujets de billets, trop peut être même (car je n’ai qu’un temps restreint pour écrire tout ça !), mais mieux vaut avoir trop d’idées et trop d’envies que pas assez !

Alors Stay Tuned !

blog comments powered by Disqus