Windows et WinRT, la nouvelle fondation pour le développement Windows ?

Après ces jours de sessions pour la BUILD de Microsoft qui sont assez chargés, je suis arrivé à poser mes idées sur ma compréhension sur cette nouvelle interface WinRT.

J’ai donc passé pas mal de temps sur les stands des équipes qui ont développé cette plateforme, et je vais essayer d’expliquer ce que j’en ai compris.

En général :

WinRT est un set d’objets accessibles pour construire des applications Metro
WinRT est accessible depuis C++, .NET (C# & VB), ainsi que Javascript lorsque l’on développe une application Metro
WinRT se base, pour ce qui est de la projection des objets natifs, sur un format nommé Windows Metadata (.Winmd); certains objets venant de Win32 ou COM possédant ces métadonnées sont alors exposés pour fournir des services aux applications Métro (voir image)
Selon le Runtime qui l’appelle, WinRT donnera l’objet (le même pour tous les runtimes) en l’entourant d’un wrapper permettant l’utilisation de cet objet par ce runtime
Cet objet natif venant de WinRT reste un objet Win32 ou COM, seule sa facade permet au runtime qui l’instancier et de l’utiliser

Pour ce qui est des languages :

Les parties C++ et Javascript ne voient que les objets WinRT venant du runtime au travers de ces objets exposés depuis leurs Metadatas,
Seule la partie C#/VB.NET peut à la fois accéder aux objets natifs exposés par WinRT et à certains objets .NET,
.NET accédé dans e cadre de Metro utilise un « Metro Profile » limitant les objets .NET accessibles et certaines de leur utilisation dans le cadre d’une application Metro (ex: charger dynamiquement une assembly venant d’internet),
Les objets natifs et managés venant du Framework 4.5 passent par WinRT avant d’être donnés à votre application,
Certains objets accessibles depuis .NET dans une application Metro ont été changé pour d’autres, mais de manière complètement transparente (System.String vient maintenant d’un type natif HSTRING, avec toutes les méthodes que vous lui connaissez),
Ces deux types d’objets sont « Garbage Collectés » par WinRT lui-même, ce qui fait que même un objet natif n’a pas besoin d’être disposé ,
Le XAML écrit dans une application Metro utilise un moteur de rendu XAML entièrement écrit en C++ (nom de code Jupiter), ce qui explique la rapidité et la fluidité de l’interface (GREAT STUFF!),
Ces contrôles sont disponibles sous d’autre namespaces que ceux de SL et WPF pour montrer la différence de contrôle,
WPF et Silverlight existent toujours sous Windows 8, mais n’utilisent pas Jupiter pour leur rendu, uniquement le framework .NET standard, et seront rendu sur le desktop,
Le profile Metro de .NET 4.5 empêche l’utilisation d’objets XAML .NET comme ceux venant des namespaces WPF,
Le moteur XAML Jupiter fonctionnant à l’identique et incluant tous les contrôles venant de WPF et Silverlight, il est possible de changer leur style (ex. appliquer le style d’un bouton SL sur un bouton Metro),
Seul C++ parmi les langages utilisés solicite moins WinRT pour la partie Metadonnées car ces objets natifs sont plus proches de C++ que des autres runtimes,
Il est possible d’écrire son propre code C++ utilisant le SDK de WinRT et ensuite de l’utiliser dans du code .NET ou JavaScript,
Les contrôles XAML pour Metro supportent tous deux les évènement souris et touch (plus de doublons d’évènement entre ces deux types).

Une fois vu tous ces points, je ne peux m’empêcher de me demander…
WinRT exposant certaines APIs de manière transparent pour un code .NET compilé en « Any CPU » ou un code JavaScript, un portage de WinRT serait tout à fait possible pour Windows Phone, permettant alors à une application de tourner sur tous les devices ave un seul package… Je pense que l’on pourra reparler de toute cela dans pas trop longtemps

En bonus, voici l’image du booth des DEVs de la BUILD, avec un schéma intéressant de ce à quoi ressemble la version un peu plus « détaillée » de l’intégration de WinRT avec tout le reste