En termes simples, Windows Runtime Library (WinRT) est l'interface de programmation d'applications (API) par défaut utilisée par Windows 8. Elle ne remplace pas l'API Win32 qui fonctionne sous toutes les applications Windows, mais l'augmente plutôt. C'est une API native non gérée qui peut être exploitée à partir de nombreux langages différents via un mécanisme appelé projection de langage (vous pouvez en savoir plus sur les projections plus loin dans ma réponse).
Caractéristiques de Windows Runtime:
- Toutes les parties de l'API sont conçues pour être asynchrones.
- L'API est sandboxée et conçue pour la création facile d'applications autonomes ou prêtes pour l'app store.
- It exposes the WPF/Silverlight XAML UI model to developers.
- The API definitions are in a metadata format, which is the same as the one used for .NET (ECMA 335).
- It wraps both the Win32 API and the new UI system together.
- It has a simple programming model for creating UIs. It is especially tailored for Windows developers who do not need to learn the Win32 API or terms like LPARAM or WndProc.
- The Silverlight/WPF XAML UI model is exposed to developers.
- It implements the look of Windows (formerly known as Metro)
WinRT consists of 109 new namespaces. These namespaces share the Windows. prefix. They seem to be logically grouped under the following 14 categories:
- ApplicationModel
- Data
- Devices
- Foundation
- Globalization
- Graphics
- Management
- Media
- Networking
- Security
- Storage
- System
- UI
- Web
More about WinRT:
WinRT Projections
Ce que nous appelons "bindings" Microsoft appelle désormais "projections". Les projections sont le processus d'exposition des API à trois environnements : Natif (C et C++), HTML/Javascript et .NET.
Si vous créez un composant en C++ ou dans un langage .NET, son API sera stockée dans un fichier WinMD et vous pourrez la consommer depuis les trois environnements (Natif, JavaScript et .NET). Même en C++, vous n'êtes pas exposé à COM. L'utilisation de COM est cachée derrière les outils de projection C++. Vous utilisez ce qui ressemble et se ressent comme une API orientée objet C++.
Pour prendre en charge les différentes constructions de WinRT, la plate-forme sous-jacente définit un ensemble de base de types et leurs mappages vers divers environnements. En particulier, les objets de collection dans WinRT sont mappés à des constructions qui sont natives de chaque environnement.
Asynchronous APIs
Microsoft estime que lorsqu'un développeur a le choix entre une API synchrone et une API asynchrone, les développeurs choisiront la simplicité d'une API synchrone. Le résultat fonctionne généralement bien sur le système du développeur, mais est terrible lorsqu'il est utilisé dans la nature.
Avec WinRT, Microsoft a suivi une règle simple : si une API est censée prendre plus de 50 millisecondes pour s'exécuter, l'API est asynchrone.
L'idée est bien sûr de s'assurer que chaque application Metro est conçue pour toujours répondre aux entrées de l'utilisateur et pour ne pas se bloquer, bloquer ou fournir une mauvaise expérience utilisateur.
La programmation asynchrone a historiquement été un processus lourd car les callbacks et l'état doivent être mis en cascade à des dizaines d'endroits et la gestion des erreurs (généralement une mauvaise gestion des erreurs) est saupoudrée sur plusieurs couches de code.
Pour simplifier ce processus, C# et VB ont été étendus pour supporter le pattern await/async inspiré de F#, transformant la programmation asynchrone en une joie. C++ a obtenu une configuration qui est aussi bonne que ce que vous pouvez obtenir avec C++ lambdas et Javascript utilise des promesses et "then ()".
Est-ce .NET ou pas ?
Certains développeurs sont confus quant à savoir si .NET est là ou pas en premier lieu, car toutes les API .NET ne sont pas présentes (File I/O, Sockets), beaucoup ont été déplacées et d'autres ont été introduites pour s'intégrer à WinRT.
Lorsque vous utilisez C# et VB, vous utilisez le cadre .NET complet. Mais ils ont choisi d'exposer un sous-ensemble plus petit de l'API aux développeurs pour pousser la nouvelle vision de Windows 8.
Et cette nouvelle vision inclut des systèmes de sécurité/sandbox et la programmation asynchrone. C'est pourquoi vous n'avez pas d'accès direct au système de fichiers ou d'accès aux sockets et pourquoi les API synchrones que vous aviez l'habitude de consommer ne sont pas exposées.
Maintenant, vous remarquez que j'ai dit "exposé" et non "parti".
Ce qu'ils ont fait, c'est qu'ils n'ont exposé au compilateur qu'un ensemble d'API lorsque vous ciblez le profil Metro. Ainsi, votre application n'appellera pas accidentellement File.Create par exemple. Au moment de l'exécution cependant, le CLR chargera la bibliothèque de classes complète, celle-là même qui contient File.Create, donc en interne, le CLR pourrait appeler quelque chose comme File.Create, c'est juste vous qui n'y aurez pas accès.
Cette scission est similaire à ce qui a été fait dans le passé avec Silverlight, où toutes les API n'ont pas été exposées, et où mscorlib a reçu des droits que votre application n'avait pas pour assurer la sécurité du système.
Vous pourriez penser que vous pouvez utiliser une astuce (référencer la bibliothèque GAC au lieu de la référence du compilateur ou utiliser la réflexion pour obtenir des API privées, ou P/Invoking into Win32). Mais toutes ces utilisations seront attrapées par l'application d'examen de l'AppStore et vous ne pourrez pas publier votre application par le biais du magasin de Microsoft'
Vous pouvez toujours faire n'importe quel hack moche que vous voulez sur votre système. Il ne sera simplement pas possible de publier cela via l'AppStore.
Enfin, l'équipe .NET a profité de cette occasion pour faire un peu de nettoyage de printemps. mscorlib.dll et System.dll ont été divisés en diverses bibliothèques et ils ont déplacé certains types.
Sources : WinRT démystifié, Qu'est-ce que WinRT ?, DevExpress Data Blog, Page sur Metrocompanionapps.com.
.