WinRT est un remplacement pour le très ancien Winapi basé sur le langage C. Il s'agit d'une api qui doit être utilisable dans de nombreux environnements d'exécution. Il y a 20 ans, il était relativement facile d'interopérer avec une api C. Les choses ont évolué depuis, COM est devenu la colle universelle dans la dernière moitié des années 1990. Pratiquement tous les environnements d'exécution de langage couramment utilisés sous Windows supportent COM.
Un ramasseur de déchets est un détail d'implémentation de l'exécution du langage. Le collecteur de .NET est très différent de celui de Javascript, par exemple. Les objets natifs créés dans l'un ou l'autre doivent respecter les règles très strictes du collecteur. Ce qui signifie qu'il aurait fallu créer des versions de WinRT spécifiques à chaque langage d'exécution. Ce n'est pas possible, même une entreprise aussi importante que Microsoft ne peut se permettre de créer et de prendre en charge une version WinRT spécifique pour chaque liaison linguistique. Ce n'est pas non plus nécessaire, étant donné que ces langues prennent déjà en charge COM.
Actuellement, la meilleure liaison pour WinRT est C++, car COM fonctionne plus efficacement avec une gestion explicite de la mémoire. Avec l'aide des nouvelles extensions du compilateur C++ qui la rendent automatique, très similaire à _com_ptr_t de l'ancien temps avec une syntaxe de type C++/CLI pour l'éviter. La liaison aux langages gérés est relativement simple puisque le CLR dispose déjà d'un excellent support d'interopérabilité COM. WinRT a également adopté le format de métadonnées de .NET. À ce jour, aucun travail n'a été effectué sur les compilateurs gérés.
EDIT : Larry Osterman, un programmeur et blogueur Microsoft bien connu, a laissé un commentaire plutôt intéressant dans une réponse maintenant supprimée. Je vais le citer ici pour le préserver :
WinRT est non géré parce que le système d'exploitation est non géré. Et en concevant WinRT de la manière dont il a été conçu, il acquiert la capacité d'être exprimé dans de nombreux langages différents, et pas seulement en C++, C# et JS. Par exemple, je pourrais facilement imaginer un ensemble de modules Perl qui mettent en œuvre les API de WinRT et qui fonctionnent sur le bureau. Si nous l'avions implémenté en .Net, cela aurait été extrêmement difficile
56 votes
C'était un mauvais choix aussi mauvais que de le fermer. Vous insistez maintenant sur les références et les sources, alors que vous les avez supprimées plus tôt en fermant la question. Maintenant, vous supprimé d'excellentes sources, provenant des programmeurs qui ont travaillé dessus.
9 votes
J'ai voté comme hors sujet car cela ne répond pas à une question pratique de programmation. C'est juste de la curiosité. Aucun programmeur ne va modifier son code suite à cette question.
0 votes
@HansPassant - les réponses supprimées contiennent des ouï-dire, des spéculations et des opinions personnelles plutôt que des faits réels vérifiables. Oui, il se peut qu'il y ait deux ou trois employés (actuels et anciens) de MS qui interviennent dans les commentaires, mais nous voulons des faits vérifiables. réponses . La question elle-même est déjà suspecte car elle attire ce type de réponses. Elle est au même niveau que des questions comme "Pourquoi Windows n'est-il pas écrit en .NET ?".
17 votes
Selon ce raisonnement, des questions comme "comment la planète Terre s'est-elle formée ?" auraient été absolument terribles dans la communauté scientifique parce qu'elles attiraient beaucoup de spéculations religieuses. Il y a de bonnes réponses à cette question - ce n'est pas parce qu'elle attire beaucoup de mauvaises réponses que c'est une mauvaise question. Vraiment, pourquoi ne pas simplement déplacer cette question vers P.SE ?
0 votes
@ReiMiyasaka Cette question est hors sujet pour P.SE. P.SE n'est pas un dépotoir pour tout ce qui n'est pas constructif sur Stack Overflow.
22 votes
@casperOne C'est une question légitime de "tableau blanc" pour beaucoup de développeurs - nous voulons connaître les raisons présumées techniques de la décision, afin de pouvoir appliquer le même raisonnement ailleurs. Est-ce parce que le garbage collector est difficile à profiler ? Est-ce parce qu'il donne un accès plus facile aux abstractions matérielles de plus bas niveau ? S'il n'y a pas de raisons techniques, c'est tout simplement regrettable, mais cela n'a rien à voir avec la qualité de la question elle-même.
0 votes
@ReiMiyasaka Si elle a été formulée comme telle, c'est une question légitime, mais cette question ne ressemble en rien à celle que vous avez posée dans votre commentaire.
3 votes
@casperOne Quoi ? C'est en fait formulé presque exactement comme ma question : "Est-ce un problème de performance ? Cela signifie-t-il que la collecte des déchets n'est pas adaptée aux API de niveau inférieur ?"
0 votes
@casperOne Nous devrions peut-être aborder la question de la méta. Je pense qu'il y a quelque chose d'intéressant à dire sur la classification d'une question comme celle-ci.
7 votes
Je suis d'accord avec @HansPassant ; cette question doit être rouverte et traitée comme valide. "Pourquoi n'est-il pas géré ?" est une très bonne question en ce qui concerne les fondamentaux de WinRT.
2 votes
"Aucun programmeur ne va modifier son code à la suite de cette question." Vraiment ? Je suis venu ici parce que j'envisage de jeter WPF pour quelque chose de mieux, et WinRT est un candidat sur lequel j'ai besoin d'en savoir plus.
0 votes
@bre : Je ne suis pas sûr qu'une réponse à cette question vous aiderait à déterminer que WinRT était en quelque sorte "mieux" que WPF. Si c'est une question de performances, alors rien ne change fondamentalement lorsqu'on utilise un langage CLR. Comme avec WPF, vous avez toujours beaucoup de transitions gérées/non gérées. Si vous voulez renoncer à cela, vous devez choisir un langage de programmation non géré (C++ avec ou sans WRL, C++/CX, C++/WinRT). Il s'agit essentiellement d'une réécriture, et non d'une simple modification de votre code.