Pourquoi WinRT n'est-il pas géré? [fermé]

165

Windows 8 introduit WinRT, qui ressemble à .NET mais non géré. Pourquoi n'est-il pas géré? Est-ce un problème de performances? Cela signifie-t-il que le garbage collection n'est pas adapté aux API de niveau inférieur?

c# .net windows-8 windows-runtime

— user380719
source

C'était un mauvais appel , aussi mauvais que de le fermer. Vous insistez maintenant sur les références et les sources, vous avez coupé cela plus tôt en fermant la question. Vous avez maintenant supprimé d' excellentes sources, des programmeurs qui y travaillaient.

— Hans Passant

J'ai voté hors sujet car cela ne répond pas à une question de programmation pratique. C'est juste de la curiosité. Aucun programmeur ne changera son code à la suite de cette question.

— Raymond Chen

@Kev Par ce raisonnement, des questions comme "comment la planète Terre s'est-elle formée?" aurait été absolument terrible dans la communauté scientifique parce que cela a attiré 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. Mais vraiment, pourquoi ne pas simplement déplacer cette question vers P.SE?

— Rei Miyasaka

@casperOne C'est une question légitime de "tableau blanc" pour beaucoup de développeurs - nous voulons connaître les raisons vraisemblablement 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 que cela donne un accès plus facile aux abstractions matérielles de niveau inférieur? S'il n'y a pas de raisons techniques, alors c'est tout simplement malheureux - mais cela n'a rien à voir avec la qualité de la question elle-même.

— Rei Miyasaka

Je suis d'accord, avec @HansPassant; cette question doit être rouverte et traitée comme valable. "Pourquoi n'est-il pas géré?" est une très bonne question en ce qui concerne les fondamentaux de WinRT.

— Rob Perkins

Réponses:

191

WinRT remplace l'ancien Winapi basé sur C. C'est une API qui doit être utilisable dans de nombreux environnements d'exécution. Il y a 20 ans, une API C était relativement facile à interopérer. Cela a évolué depuis, COM est devenu la colle universelle dans la dernière moitié des années 1990. Pratiquement n'importe quel environnement d'exécution de langage couramment utilisé dans Windows prend en charge COM.

Un garbage collector est un détail d'implémentation d'exécution du langage. Le collecteur pour .NET est très différent du collecteur pour 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 à son tour qu'ils auraient dû créer des versions WinRT spécifiques à chaque environnement d'exécution de langue. Cela ne fonctionnera pas, même une entreprise aussi grande que Microsoft ne peut pas se permettre de créer et de prendre en charge une version WinRT spécifique pour chaque liaison de langue. Ce n'est pas non plus nécessaire, étant donné que ces langages prennent déjà en charge COM.

À l'heure actuelle, la meilleure liaison pour WinRT est C ++ puisque COM fonctionne plus efficacement avec une gestion de mémoire explicite. Avec l'aide des nouvelles extensions de compilateur C ++ qui le rendent automatique, très similaire à _com_ptr_t de l'ancien avec une syntaxe de type C ++ / CLI pour l'éviter. La liaison aux langages gérés est relativement simple car le CLR a déjà un excellent support d'interopérabilité COM. WinRT a également adopté le format de métadonnées de .NET. Afaik, aucun travail n'a été fait du tout sur les compilateurs gérés à ce jour.

EDIT: Larry Osterman, un programmeur et blogueur Microsoft bien connu, a laissé un assez bon commentaire dans une réponse maintenant supprimée. Je vais le citer ici pour le préserver:

WinRT n'est pas géré car le système d'exploitation n'est pas géré. Et en concevant WinRT tel qu'il a été conçu, il gagne la capacité de s'exprimer dans de nombreux langages différents, pas seulement C ++, C # et JS. Par exemple, je pourrais facilement voir un ensemble de modules Perl qui implémentent les API WinRT qui fonctionnent sur le bureau. Si nous l'avions implémenté dans .Net, cela aurait été extrêmement difficile

— Hans Passant
source

Je ne sais pas sur les compilateurs, mais je suis presque sûr que la projection WinRT .NET a fait beaucoup de travail sur CLR. Ils ont peut-être réutilisé le code COM Interop, mais il y a aussi des différences (par exemple, IInspectablevous permet de faire des choses comme interroger un objet pour son type de classe réel ou la liste de toutes les interfaces prises en charge, et avec les fichiers winmd, on peut projeter des métadonnées WinRT pour tout cela dans Reflection ). Et les fichiers winmd ne sont pas non plus immédiatement utilisables comme assemblages d'interopérabilité, CLR doit les gérer spécialement.

— Pavel Minaev

Pas sûr, vous ignorez l'éléphant. IInspectable est un remplacement pour IDispatch qui est resté bloqué en 1997. Vous travaillez pour Microsoft, n'hésitez pas à dévoiler certains des secrets ici :)

— Hans Passant

Des travaux ont été effectués dans les 3 langues pour prendre en charge les projections linguistiques.

— RéintégrerMonica Larry Osterman

Je dirais que pour le moment, «la meilleure liaison pour WinRT» est en fait C #. La liaison CLR est optimisée même au-delà de l'interopérabilité COM assez rapide, et les langages .NET dans l'aperçu du développement implémentent déjà un excellent support pour les fonctions asynchrones omniprésentes avec «wait». Dans quelques-unes des démos, le code C # faisait beaucoup plus que les exemples C ++ et fonctionnait plus facilement. Peut-être que plus tard, C ++ obtiendra une extension d'assistance asynchrone, mais dans cette version, l'async C ++ avait l'air terrible. Et vous êtes moins susceptible de fuir la mémoire à long terme du CLR de récupération de place que l'implémentation C ++ problématique en termes de cycle. C # FTW!

— Govert le

@Hans: La 3ème projection est le CLR pour tous les langages CLR (principalement C # et VB). De plus, WinJS n'est pas une projection, c'est un ensemble de bibliothèques de support. La projection est directement intégrée au moteur Chakra JS.

— RéintégrerMonica Larry Osterman le

WinRT n'est pas géré car il est destiné à remplacer Win32 - l'API accessible aux développeurs de plus bas niveau pour Windows. Une API non gérée est toujours la plus potentiellement performante qui puisse être exposée au développeur et le raisonnement est qu'il sera toujours possible d'envelopper une API gérée, ce qui est précisément ce que font les `` projections ''.

Cela signifie également que les développeurs C ++ peuvent utiliser WinRT sans sauter par les obstacles que C ++ / CLI introduit (voir http://www2.research.att.com/~bs/bs_faq.html#CppCLI ) Cela signifie cependant que vous allez toujours devez étudier COM si vous souhaitez utiliser WinRT.

La vraie question est «pourquoi COM est-il nécessaire? pourquoi Microsoft a-t-il dû l'inventer? Parce que le simple C ++ sans toutes les fonctionnalités supplémentaires de COM est inadéquat pour un vrai travail de POO et les affirmations de Stroustrup de C ++ vous donnant la «portabilité» sont très très malhonnêtes à la lumière de la réalité de travail. Voir http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/

— Andz
source

Lien mis à jour pour les réflexions de Bjarne sur C ++ / CLI: stroustrup.com/bs_faq.html#CppCLI