La vraie nature de WinRT

La semaine dernière, Microsoft organisait un évènement dénommé Build Windows, dans le but de faire la lumière sur la dernière version de Windows, nom de code Windows 8, prévu pour débarquer l’année prochaine. Lors de cet évènement, MS en a profité pour dévoiler un nouveau type d’application pour Windows : les applications Metro, orientées grand public et basées sur une nouvelle couche logicielle dénommée Windows Runtime alias WinRT.

Depuis, on peut entendre beaucoup de bruit sur la véritable nature de WinRT : est-ce que WinRT remplace Silverlight ? WPF ? Win32 ? A tel point que cela en devienne assez dur de comprendre le concept, pourtant très simple et très puissant à la fois. Heureusement plusieurs bons articles sont apparus sur la toile pour expliquer qu’est-ce que WinRT et comment il va fonctionner conjointement avec le reste du système d’exploitation. Cet article va donc essayer d’expliquer ce qu’est véritablement WinRT et pourquoi le concept est si puissant !

Windows 8, le premier Windows schizophrène

Comme le faisait remarquer Mary Jo Foley sur son blog All About Microsoft, c’est que s’il y a bien une slide que tout le monde gardera en mémoire du Build, c’est celle-ci, qui représente l’architecture des applications pour Windows 8.

Ce qui est intéressant ici est la séparation entre les Metro Style apps, les fameuses applications développées exclusivement pour Windows 8, et … tout le reste ! Oui la partie droite en bleu représente l’intégralité des applications existantes ! Cela aurait d’ailleurs dû couper court à toutes les discutions de mort de Silverlight / .NET : tout cela sera présent dans Windows 8 comme c’est le cas dans Windows 7 !

Comment dans ce cas, vont cohabiter les différentes applications ? Quel est l’intérêt de créer un nouvel écosystème applicatif, quand on a déjà, et de loin, le plus vaste ?

Et bien tout simplement, parce que Windows 8 a deux personnalités ! Une personnalité qu’il a héritée de son père Windows 7, qui reprend toute la partie bureautique de Windows (bureau, barre de lancement rapide, icônes, fichier, et ainsi de suite), et une personnalité qu’il a hérité de son lointain cousin Windows Phone 7 (je ne veux pas savoir comment c’est arrivé !), qui instaure pour la première fois dans Windows une interface très très très orientée grand public, avec les fameuses live tiles, notifications, et les applications sans chrome qui mette l’accent sur le contenu, la typographie, l’expérience utilisateur… Attendez mais ça me rappelle quelque chose !

Effectivement, cela défini parfaitement Metro, cet ensemble de règles qui font qui ont permis de créer une toute nouvelle expérience utilisateur sur Windows Phone, comme je l’avais décrit l’année dernière dans cet article : https://sebastienmornas.wordpress.com/2010/08/29/qu-est-ce-que-metro/ Et c’est effectivement un bien bel exemple d’interface Metro que nous a présenté avec le nouveau « Start screen » de Windows 8, qui remplacera donc le menu démarrer qui était apparu avec Windows 95 ! Ils nous avaient prévenus, Windows 8 est un tournant dans l’histoire de Windows !

Nous y voilà, Windows 8 aura donc deux facettes, une classique qui sera un Windows 7 amélioré, et une qui transforme le PC en grand Windows Phone. Qui a dit « tablette » ? Bien évidemment le but avoué de Windows 8 est de conquérir le marché des tablettes tout en conservant celui des ordinateurs. Cette interface Metro est ainsi une aide précieuse pour faire adopter Windows aux tablettes, car bien qu’elle soit prévue pour être utilisée autant à la souris / clavier qu’aux doigts, on imagine sans mal que le tactile sera notre moyen favoris pour naviguer dedans !

WinRT, un composant phare de Windows 8 Metro

Une des nouveautés de Windows 8 est également sa compatibilité avec l’architecture ARM, qui n’était pas supporté jusqu’à Win8. Cela rentre aussi dans la stratégie de pousser Windows sur tablette, un secteur où les processeurs x86 sont présents, mais pas dominants. Seulement voilà, comment porter toutes les applications natives de Windows sur ARM, sachant que le jeu d’instruction est sensiblement différent ? En un mot : impossible (ou plutôt « trop contraignant » mais ça faisait deux mots).

C’est pour cela que Microsoft a besoin de constituer un nouvel écosystème d’applications résolument orienté vers le grand public, en plus de son écosystème d’applications existantes ; le but étant également que toutes ces nouvelles applications soient autant utilisable à la souris que via un écran tactile. Oui je parle bien des applications Metro, qui pourront fonctionner de la même manière sur toutes les versions de Windows 8 de la même manière, même sur un système ARM. Pour cela, pas besoin de compiler son application pour plusieurs architectures, c’est une toute nouvelle couche logicielle qui permettra aux applications Metro de communiquer avec l’OS : le Windows Runtime.

Je pense que ce n’est que maintenant, après avoir compris le contexte derrière Windows 8 que l’on peut réellement saisir ce qui se cache derrière le diagramme présenté au début de l’article. Dans le schéma présenté au début de l’article, WinRT est une couche qui descend aussi bas que Internet Explorer, Win32 et .NET / Silverlight ; pourquoi ?

Parce que WinRT n’est pas une couche de plus qui s’insère entre deux couches existantes, bien au contraire, c’est une couche entièrement indépendante de Win32, qui discute directement avec l’OS sans intermédiaire ! C’est en ce sens que Paul Thurrott écrit son article WinRT is replacing Win32, bien que pour moi cela soit faux : WinRT est une alternative, pas un remplacement !

Mais WinRT ne s’arrête pas au niveau de Win32, mais qui monte également plus haut, incorporant une partie des blocs HTML / JavaScript, C / C++ et C# / VB.NET, et il y a une raison à cela : WinRT permet d’écrire des applications via des langages natifs (C/C++), managés (C#/VB.NET) et même web (HTML/JavaScript), et contient donc des mécanismes pour pouvoir utiliser les mêmes APIs depuis tous les langages supportés (nous y reviendront plus tard).

WinRT, en soit, est composé d’un grand nombre d’APIs, qui ressemble grandement à des APIs .NET, et qui sont accessibles aux trois langages. Magique ? Non. Ingénieux ? Certainement ! Derrière ce sont des APIs bas niveaux, entièrement développée en C++, pour s’assurer une performance maximale, mais qui sont exposées en utilisant un format de métadonnées standardisée par Microsoft (ECMA 335 pour les puristes, et oui, c’est les mêmes métadonnées utilisées par le .NET Framework !), ce qui permet d’utiliser de la réflexion, des langages dynamiques, etc.

En ce qui concerne la partie graphique, WinRT contient également toutes les mécaniques pour écrire des interfaces en XAML, comme on le ferait pour écrire des interfaces Silverlight ou WPF. C’est en cela que Silverlight et WinRT + XAML se ressemble beaucoup. Mais derrière, c’est très différent. La partie graphique de WinRT est entièrement exécuté par DirectX, de manière native, ce qui assure des performances à hauteur et un support encore plus abouti du GPU. Comme DirectX est extrêmement présent dans WinRT, cela promet également de pouvoir écrire des jeux DirectX encore moins couplé au matériel.

Les wrappers JavaScript et C# / VB.NET

Si les APIs de WinRT sont écrite en C++, on peut comprendre qu’utiliser WinRT depuis C++ est assez naturel. En revanche, comment peut-on l’utiliser depuis JavaScript ou les langages basés sur .NET ?

Pour ce qui est du C# et du VB.NET, le principe est le même que le P/Invoke couramment utilisé par les développeurs .NET pour appeler des méthodes définie dans les DLL du système. Le principe, mais pas la syntaxe, car pour consommer un objet WinRT, il suffit de l’instancier comme n’importe quel objet .NET et de l’utiliser de la manière la plus managée qui soit. Fantastique ! Mais en ce qui concerne le reste du Framework ? Pas d’inquiétude, le CLR 4.5 sera là pour exécuter notre code managé, mais sera simplement restreint pour ne pas utiliser les APIs bas-niveau du Framework (par exemple la gestion de fichiers). Miguel De Icaza, le papa du projet Mono, a justement écrit un excellent article sur WinRT à ce propos.

Pour ce qui est de JavaScript et HTML, il faudra passer par une bibliothèque JavaScript nommée WinJS, qui ne fonctionnera que dans Windows 8 (pas sur le web, ce qui est normal) et qui offrira les mêmes APIs que pour .NET / C++ dans un style résolument plus JavaScript. Le code JavaScript, ainsi que l’interface HTML5 / CSS3 sera interprété par le même moteur de rendu / exécution de script que IE10, bien que l’application ne soit pas vraiment exécutée par ledit navigateur.

Pour conclure

Windows Runtime, je ne sais pas de qui c’était l’idée, mais c’est une fort bonne idée ! Avec WinRT, il est possible de faire des applications avec le style d’écriture .NET (et la productivité qui va avec), tout en manipulant des objets natifs sans le savoir, ce qui augmente sensiblement les performances. Plus important encore, WinRT permet de fédérer l’écriture d’applications pour la plateforme Windows, le but étant de recréer un écosystème d’application modernes, fluide et intuitives. J’ai hâte d’y être !