Archives pour la catégorie C++

WinRT ou le retour en force du COM+

J’ai voulu ajouter « Lol » à la fin du titre de ce lien, mais il paraît que ça ne se fait pas.

On retrouve plein d’articles sur le NET nous parlant de WinRT, des incidences lorsqu’on doit développer en C#.
Je vous propose donc ce petit post, non pas pour vous parler de WinRT mais plutôt pour vous parler de COM(+) et vous expliquer ce choix, qui semble hasardeux, de Microsoft.

Tout d’abord, un petit rappel.

Observez le schéma de l’article, il a fait le tour du monde. Avec Windows 8, il y a deux façon de considérer Windows. La première en mode WinRT (partie de gauche), l’autre en mode desktop (partie de droite).

En mode WinRT, on vise un nouveau type d’application dites « Metro style Apps », dénomination valable jusqu’en août 2012 date où l’on appris que le terme était déposé et sujet à copyright. On parle désormais d’application ModernUI (ou Windows 8 style)
En mode Desktop, on développe classiquement, C++, C#, VB.NET, Assembleur

Beaucoup de développeurs .NET ont espéré, comme Java en son époque, que Windows allait devenir « CLR ». En d’autres termes, l’OS serait une grande machine virtuelle, on gagnerait en simplicité tout en se débarrassant de ces bonnes vieilles API Win32.

Mais que faire alors des anciennes applications justement Win32 ? Il aurait suffit de les virtualiser ! On le fait déjà quelque part pour faire fonctionner les applications 32bits (et même 16 bits!) sur du Windows 64 bits (merci WoW64^^). Développer une application tournant dans l’OS/CLR, qui émulerait les API Win32 et ferait fonctionner toute application non .NET dans cette Sandbox ! Simple ,non ?

Oui mais voilà, ce n’est absolument pas ce que Microsoft a fait ! Mais allons donc ? Pourquoi ? C’était si simple !

Disons que ce n’est pas parce qu’une chose a l’air simple en apparence qu’elle l’est dans les fait. Tout d’abord, au risque de passer pour un dinosaure, il faut savoir que depuis fort longtemps tout Windows est COM… ou DCOM… Enfin COM+. De quoi je parle ? Du fait que peut après l’apparition de la base de registre (Windows 95), Microsoft a planché sur des vrais soucis de communication inter logiciel : faire en sorte qu’un copier/coller fonctionne entre un Word et un Excel et mieux, que les logiciels échangent des comportements en temps réel (exporter un tableau Excel dans Word par Exemple). Microsoft a commencé par une technologie type OLE (Object Linking and Embedding) qu’ils ont rapidement muté en composant ActiveX et composant COM : les composants ActiveX étant « visuel » (comme une applet Java), les composants COM étant eux des composants sans interface.

Il faut imaginer dès l’époque que tout était bien pensé. On parlait de composants comme au sens moderne. Car à la différence de l’objet qui tourne dans un processus, le composant a une sorte d’existence propre, des entrées et des sorties (je vous passe les histoires de surrogate chez Microsoft^^). Vous avez bien lu ! J’ai fait un raccourci, mais un objet est une représentation binaire qui n’a de sens que dans son process ! Le composant, lui, existe en dehors !
Pour ces raisons, lorsque vous faites du WCF, vos objets exposés peuvent et même doivent prendre la dénomination de composants. Idem pour COM+, ce bon vieux CORBA (certes, on parle d’IOR pour des références d’objets interopérable à distance, mais la vision externe est un « composant »), CCM (pour ceux qui connaissent) et surtout les EJB !

OLE/COM date des années 1995… Et fut transformé en DCOM vers 1998 (Le D signifiant Distributed), technologie permettant d’appeler les composants COM à partir d’un autre ordinateur puis renommé COM+ dès les années 2000. COM+ est le mix de DCOM et d’une technologie transactionnelle (MTS – Microsoft Transaction Server) développée par Microsoft dans l’optique de concurrencer CORBA et ses service OTS (Object Transaction Service). Il faut imaginer MTS comme le service JTS de JEE, où la partie transactionnelle des EJB stateless (avec un peu de stateful mais avec des limitations beaucoup plus forte), où bien encore du WCF avec des TransactionFlow et autres TransactionScopeRequired configurés.

Quand .NET est apparu, il fut vanté par rapport à COM+ pour sa simplicité. Il ressemblait à Java, finit les DLL Hells (ou l’enfer des DLL car COM+ exigeaient des inscriptions en base de registre, le versioning était très compliqué).

Sauf que COM+, tandis que .NET évoluait, a énormément évolué de son côté… notamment en se débarrassant de l’obligation d’aller en base de registre… mais également en améliorant le versionning, la possibilité de faire du side-by-side, etc.

Le choix de faire du WinRT en « COM-like » est beaucoup plus logique qu’il n’y parait. Contrairement aux apparences, C++ ne peut pas être concurrencé par des technologies à base de VM sur un ordinateur. Tout simplement parce que, même si pour bon nombre de projets de gestion c’est suffisant, la performance ultime ne peut être atteinte qu’en se calant le plus possible à la machine : RAM, disques, processeurs, CPU et registres.
Pour ces raisons, Microsoft a fait évoluer son OS dans le bon sens, le rendant multiplateforme (bienvenue aux processeurs ARM) tout en faisant évoluer C++ !

Mais il ne faut pas se tromper. Quand on cible WinRT en C++, on développe en C++/CX (Component Extensions) comme l’on développait en C++/CLI (Common Language Infrastructure) lorsqu’on ciblait la CLR. Ca c’est la façon qui arrange tout le monde. C++ dans le même sac que C#, VB.NET, Javascript, etc… car c’est juste un autre langage, on ne gagne rien.

Demeure pour le puriste, que l’on peut faire du WRL (Windows Runtime C++ Library) ! WRL c’est l’équivalent d’ATL (Active Template Library) en COM+ ! Débarrassé de pratiquement tout, on attaque les choses sérieuses et on a latitude pour réaliser des appels à l’OS… d’un autre monde 😉

Toutefois, même si je suis un aficionados d’ATL, et donc de WRL, je ne le recommande absolument pas en situation projet, à moins d’y être fortement contraint (pour des raisons de performances notamment, ou bien parce que vous développer un composant hyper technique). Car cela demande énormément de compétence et s’avère très difficile à la maintenance !

Visual Studio 2012 et C++ 11 (C++0x)

C++0x a mis du temps a sortir puis l’année dernière en août, grande nouvelle, approuvé unanimement. Portant désormais le nom de C++11 il apporte de grand changement par rapport à l’ancienne norme (datant de 2003).

Nouveautés dans le langage, nouveautés dans la bibliothèque standard mais également  les bibliothèques du technical report 1 (Kisako ? Le technical report 1 est un document proposant des additions à la bibliothèque standard : has tables, expressions régulières, smart pointers, etc. Sorti en 2003, nombre de ces additions ont été implémentées par les vendeurs au point où la plupart font désormais partis du standard officiel C++11).

Pourquoi ce post ? Parce ce que Visual Studio 2012 (anciennement nommé VS 2011) est en release candidate et qu’il apporte des nouveautés à l’implémentation partielle de C++11  sous VS2010 !!

Voici la liste, probablement non exhaustive de ces nouveautés conformes à C++ 11 :

*       rvalue references en version 2.1 <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1138>  par rapport à la 2.0
*       lambdas en version 1.1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf>  par rapport à la 1.0.
*       decltype en version 1.1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf>  par rapport à la 1.0

*       Amélioration d’Alignment (mais non complet) <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf>
*       Enumérateurs fortement typés <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf>
*       Forward declared enums <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf>
*       Standard layout and trivial types <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm>
*       Atomics <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html>
*       Strong compare and exchange <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2748.html>
*       Bi-directional fences <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2752.htm>
*       Data-dependency ordering <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm>
*       Range-based for loop <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html>