un article de Serge Camiré
Tout ce qu’on regroupe généralement sous le parapluie COM
Détails ici sur le COM Au tout début, on voulait créer un mécanisme d’échange de données et de méthodes entre applications (à condition de demeurer sous DOS ou Windows).
Ceci a pu donner naissance à Visual Lisp (ci-après VL) et à Visual Basic for Applications (ci-après VBA) d’AutoCAD. Pour revenir à VL, on a vu apparaitre en R14 toutes les fonctions préfixée vl-, vla-, vlr-, etc. Celles qui commencent par vla- sont justement des exemples d’implémentation d’automation (le a dans vla). La façon dont cela fonctionne est que le concepteur du logiciel (dans ce cas-ci, Autodesk avec AutoCAD) doit réécrire en IDL chacune des fonctions qui existe déjà en ObjectARX qu’il entend exposer ou rendre accessible dans COM (mais cela sort du cadre de cet exposé). Ce qu’il faut retenir est que ce processus est long. Pour cela, on n’a retrouvé que quelques fonctions au début puis cela s’est enrichi au fil des versions.
Aujourd’hui, VL est très riche mais toujours plus pauvre que ObjectARX duquel il est issu. Ce qui caractérise une fonction COM est que de prime abord, on n’est pas censé connaitre l’utilisateur. Dans ce contexte, on doit créer plus de overhead (je ne saurais trouver un terme plus précis qui illustre cette surcharge) pour le typage des données et cela comporte une certaine lourdeur. On va même jusqu’à solliciter la base de registre pour stocker des informations sur comment identifier le serveur de données.
À ne pas confondre, on peut définir des fonctions en ARX qui seront directement exposées à VL et puisque ces 2 applications se connaissent, elles communiquent directement sans protocoles sur le typage de données. Le VBA d’AutoCAD est une coquille autour du noyau VBA que l’on retrouve généralement dans “C: Program Files Fichiers communs Microsoft Shared VBA”. C’est le même noyau sur lequel on retrouve le VBA d’Excel ou de Word. Autodesk paie Microsoft pour ‘licenser’ son VBA. C’est aussi ce qui explique que l’on obtient de l’aide sur VB lorsqu’on appuie sur F1. Toujours est-il que le VBA d’AutoCAD communique avec AutoCAD grâce au interface COM. L’objet ThisDrawing est un “raccourci” extrêmement utile sur la base de données du dessin. On peut ensuite découvrir tout le modèle d’objets d’AutoCAD (les blocs, les styles, les dictionnaires, etc…). Tous ces objets ont été travaillés un à un pour être disponible. Lorsqu’on change la couleur d’une ligne, c’est qu’une propriété a été exposée d’ObjectArx à COM.
Ce qui est bon de retenir est qu’en 2008, AutoCAD a commencé à supporter le 64 bits. Tout-à-l’heure, je disais que le VBA d’AutoCAD est une coquille sur un VBA central., donc qui échappe au bon vouloir d’Autodesk. Le VBA central n’étant pas fait pour supporter le 64 bits, il a fallut qu’Autodesk fasse preuve d’imagination pour continuer à supporter ses utilisateurs. Un prix à payer, on ne pouvait plus typer (c’est du mauvais français ou un néologisme ?) les données d’aussi près qu’avec l’ancien VBA (un Dim MyLine as AcadLine devenant Dim MyLine as Object)) puisque les pointeurs sur la base de données sont en 64 bits.
C’est là que le Dot Net vient à la rescousse. Un mot sur VB6. Le VB utilisait les capacités de l’Automation (depuis VB3 je crois). On pouvait très facilement ajouter des OCX à nos boites de dialogue. L’interprétation du code et le support du COM était assurés par ce qu’on appelle la machine virtuel de VB (les fichiers msvbvm*.dll). Voir Visual BASIC. Le principe est repris par DotNet.
Tout ce qu’on regroupe généralement sous le parapluie .NET
Détails ici sur le .NET Avec la présence de plus en plus soutenue du Web dans notre quotidien, Microsoft a voulu étendre le concept d’échange de données et de méthodes (les fonctions) au travers de tous systèmes d’exploitation, de réseaux, de processeurs. Visual Studio 6 (avec lequel nous avons connu VB6) est devenu Visual Studio DotNet (ou .Net).
Aujourd’hui, appellation clinquante DotNet n’existe plus et on parle de Visual Studio tout simplement. Pour que tout cela fonctionne, il fallait que Microsoft développe d’abord le concept de FrameWork. Un frameWork est la fondation qui s’installe sur tout système d’exploitation et il en existe un différent pour chacun. Le framework a le même rôle que la machine virtuelle de VB soit de servir d’interprète ou de courtier. On peut faire l’analogie avec les base de données. On dispose du langage SQL et on n’a pas besoin de savoir comment est codée la base données et, dans certaines mesures, de savoir si c’est Access, MySQL, Oracle, Sybase, Progress ou autre. On les exécute et c’est tout. Pour que cela fonctionne, SQL doit être interprété par un système (l’équivalent du FrameWork) qui le traduit ensuite en code spécifique à la base de données (le système d’exploitation).
Tout ce qu’on a connu avec Win API avec des instructions telles “Declare Function LeNom Lib “kernel32″ Alias “LeNomA” (ByVal LaVariable As String) As Long ” ont été refaites dans le FrameWork pour se détacher de Windows. Je ne connais pas le MacOS mais tout ce qui pouvait exister et lui être caractéristique a été porté dans le FrameWork.
Maintenant qu’on dispose d’un FrameWork, on peut y faire rouler des applications locales ou des applications Web beaucoup plus riches (voir [un bon article). Comment fait-on ? On développe un langage neutre. C’est ce qu’on appelle le Microsoft Intermediate Language (MSIL).et qui sera traduit par le Common Language Runtime (CLR). Le CLR, c’est le composant de machine virtuelle du framework. C’est comme l’interpréteur de commandes SQL ou l’interpréteur de VB. Pas de panique, personne ne programme en MSIL. C’est l’environnement de programmation Visual Studio qui le fait. Il traduit nos programmes en VB ou en C Sharp dans ce langage. À ce stade, le code MSIL n’est que pré-compilé. La compilation réelle se fait lors de la première exécution sur le poste de travail de l’utilisateur. Cette prise en charge depuis le code natif jusqu’à sa conversion introduit le concept de code géré (managé ou managed code). Lorsqu’on voit cet appellation, on sait maintenant que notre code passera par un langage neutre et sera traité par le FrameWork.
Existe-t-il du code non géré ? Bien sur. C’est comme avant avènement de l’espace Objet (R10). Il n’avait qu’une présentation et personne ne lui avait donnée de nom. Le code non managé c’est ObjectArx. Attention, seul le C++ peut généré du code non managé. Le C++ peut aussi donner du code managé selon l’option choisie lors de la création du projet et on ne convertit pas de l’un à l’autre. Une application managé doit toujours reposer sur un FrameWork. Donc, si on fait des applications autonomes, on peut être concerné par le fait que nos clients (qui seraient sur Windows 98) ait la bonne version de celui-ci.
Puisque nous sommes avec AutoCAD, on ne se pose même pas de question, le FrameWork est installé et mis à jour automatiquement. Le fichier découlant d’une application managé est un dll.Il est bon de savoir que puisqu’il n’est pas compilé, le code demeure facilement décompilable d’où existence de programme obfuscateur (un utilitaire qui transforme le bytecode d’un programme en un bytecode aux fonctions équivalentes mais plus difficile à décompiler, comme la commande Protect.exe pour AutoLISP). Un programme ObjectARX est un dll (renommé avec l’extension arx) mais qui est réellement compilé. Un dll de DotNet peut, selon le choix du développeur : 1) être signé numériquement et une version spécifique doit exister pour l’application 2) être détectée dans le répertoire de l’application (comme dans la bonne vielle R13 qu’on copiait d’un poste à l’autre) 3) être placé dans un répertoire commun et, grâce à un manifeste, déclarer qu’il peut utiliser ou se conjuguer avec d’autres dll plus récents.
Ce dernier type est intéressant parce que justement on souhaite que nos applications survivent à diverses versions d’AutoCAD. Lorsqu’on programme des applications .Net, on a besoin de Visual Studio. Il existe la version gratuite nommée Express. Cette version génère le fichier mais ne permet pas de lancer AutoCAD et de pouvoir suivre le débogage pas à pas. Il paraitrait qu’il y a une façon de contourner cette lacune.