#FF00AA

Attention, article technique. Ca ne parle même pas de web, mais de programmation Windows, alors vous pouvez zapper. En plus, avec mon rythme de sommeil actuel, je suis explosé, donc cet article va être complètement décousu. Et puis ce n’est même plus nouveau, ce dont je parle. C’est dire si c’est intéressant.

Alors, si vous êtes curieux, vous pouvez toujours cliquer sur l’icône pour télécharger le programme, il ne sert pas à grand chose, c’est une démonstration technique, mais bon, ça occupe et j’aime bien frimer avec mes logiciels. (En espérant que ça marche sur d’autres ordinateurs que le mien. Evidemment, puisque c’est le sujet du post, il faut le runtime .NET.)

Si vous utilisez Windows, et que vous aimez bien jouer avec des logiciels neufs de temps en temps, vous êtes sûrement déjà tombé nez à nez avec un freeware qui exigeait l’installation du runtime .NET. Si vous avez l’ADSL, ce n’est pas grand chose : suivre le lien et cliquer là où il faut, ou lancer Windows Update, ça s’installe, c’est sur le site de Microsoft alors on fait confiance (mouahaha), et puis voilà. Mais si vous êtes en RTC, parce que ça existe encore, la preuve, c’est plus difficile à encaisser, de télécharger 20 Mo de merde Microsoft pour pouvoir lancer un petit shareware de 100 Ko.

Parce que, .NET, c’est forcément de la merde, non ? Ne serait-ce que parce que ça a un nom ridicule, qui donne à penser que ça contient juste quelques fonctions pour se connecter au Web et interpréter du XML. Super. Et puis c’est surtout très réminiscent des DLL Visual Basic, ces trucs trop gros pour l’époque (où beaucoup de monde était encore en RTC) qui existaient en quinze versions différentes. Un truc pour programmeurs flemmards et incompétents, qui ne savent pas coder tout seuls, quoi. Non ? Eh bien, non.

Emporté par la curiosité, ou peut-être l’ennui, mais je crois que ça va ensemble, j’ai fini par me décider hier à charger le SDK, à lire la documentation, à voir ce que ça peut apporter, ce truc, et figurez-vous que je suis arrivé à un constat inattendu : c’est bien ! (Ah, zut, j’ai niqué le suspense.) Pour situer, il faut dire que quand je m’étais remis à la programmation Windows, il y a deux ans et demi (wow, déjà), pour réaliser Ghrone, et que j’avais donc découvert Visual C++, j’avais été terriblement déçu : les MFC (l’interface orientée objet qui permettait de programmer sous Windows en C++), ça alors, oui, c’était de la merde ! Bien sûr, j’avais peut-être tendance à en attendre trop, parce que deux en plus tôt je m’étais mis à la programmation BeOS (orienté objet dès sa conception, et incroyablement simple à programmer). Mais je suis sûr et certain qu’à l’époque où je programmais sous Borland C++ (en 1995-96, quand j’ai fait un joli clone de NeXTstep pour Windows 3.1, à l’époque où le clonage n’était pas encore la grande mode) les classes étaient mieux fichues, le code était moins bordélique, et tout était bien plus simple et pratique.

Je ne vais pas rentrer (encore plus) dans les détails, parce que soit ça ne vous intéresse pas, soit vous savez déjà tout ça, alors, pour synthétiser : entre ma déception passée avec Visual C++, le nom ridicule de .NET, tout le bruit que Microsoft en avait fait pendant des années avant que ça se tasse et que les commentateurs disent que c’était beaucoup de bruit pour rien, je ne m’attendais vraiment pas à grand chose.

Surprise ! .NET, c’est précisément tout ce que les MFC auraient dû être depuis des années : une vraie surcouche orientée objet qui masque enfin tous les appels système et permet d’accéder au système Windows de façon intelligente, en automatisant toutes les petites choses évidentes qui demandaient plein de code bête avec les MFC.

J’ai décidé de m’y mettre quand j’ai appris (en lisant les blogs MSDN, et heureusement que je me suis mis aux agrégateurs pour ça, parce que sinon ils sont franchement indigestes) que Microsoft proposait un compilateur Visual C++ gratuit. Pour ceux qui voudraient tenter le coup, un petit spoiler : laissez tomber. La programmation .NET en C++, c’est absolument imbitable, parce qu’ils cherchent visiblement à respecter les standards du langage à coups de macros et de définitions lourdes et bizarres, et que le code qui en résulte est horrible. Sans parler du fait qu’il n’y a pratiquement pas d’exemples en C++ dans la documentation — mais ça, c’est autant une cause qu’une conséquence. Microsoft a créé C# pour .NET (mais Visual Basic marche aussi, c’est exactement le même langage, mais sans les accolades) et, contrairement à ce qu’on peut croire quand on ne s’y est pas intéressé, ce n’est pas juste pour faire leur intéressant, ça a vraiment un intérêt.

La grosse particularité de .NET en tant qu’environnement de programmation, et la principale raison pour laquelle la version C++ est inutilisable, c’est la gestion de la mémoire : le runtime .NET fournit un garbage collector (c’est le cas aussi dans Java, je crois ?). Maintenant que j’ai compris ce que c’était (je ne m’étais jamais vraiment intéressé au concept, alors ça restait pour moi de l’ordre de la magie), je vais pouvoir ne pas vous l’expliquer, mais juste confirmer que, oui, c’est vraiment important : avant, on passait des heures et des heures dans la documentation Windows à chercher à déterminer quand et comment on devait créer une chaîne de caractères ou une structure, et quand on devait la détruire. Pareil pour tout le monde, c’est pas que je sois idiot, c’est que les API Windows, celles qui n’étaient pas tellement masquées par les MFC, ne sont pas toujours très cohérentes à ce niveau. Ce qui est marrant, c’est qu’il me semble bien que Borland C++, il y a huit ans, sans avoir besoin d’ajouter un garbage collector, évacuait déjà pas mal ce problème, simplement en protégeant le programmeur des méchantes API Windows. Mais Microsoft, non, il a fallu qu’ils réinventent leur système d’exploitation et leur langage de programmation. Bah.

Tout ça, c’est très sympathique, mais ce n’est pas le plus spectaculaire. La disparition des pointeurs, c’est reposant, mais ce qui est le plus impressionnant dans .NET (et surtout, ce qui m’intéresse le plus), c’est le contrôle de l’interface utilisateur, qui est enfin aussi simple qu’il peut l’être. Quelques exemples :

Button button1 = new Button();
button1.Click += new System.EventHandler(button1 Click);
MainWindow.Controls.Add(button1);

Hop, le bouton est créé et rattaché à la fenêtre, et on intercepte les clics, en trois lignes. Pas de constantes à définir pour créer des événements, pas de classes à dériver — on peut parfaitement programmer une petite application sans même créer de classe pour la fenêtre principale !

ListBox listBox1 = new ListBox();
listBox1.Size = new System.Drawing.Size(120, 173);
listBox1.Anchor = AnchorStyles.Bottom | AnchorStyles.Left | AnchorStyles.Right;
listBox1.Items.All = new object[] {“Item One”, “Item Two”, “Item Three”, “Item Four”};

Outre le remplissage de la liste en une ligne, il y a quelque chose d’incroyable dans ce bout de code : grâce à Anchor, cette liste se repositionne et se redimensionne automatiquement quand l’utilisateur change la taille de la fenêtre. C’est carrément effarant qu’on ait dû attendre .NET pour avoir cette fonctionnalité, mais je suis tellement content que je n’ai pas envie de me plaindre.

ContextMenu button1ContextMenu = new ContextMenu();
button1.ContextMenu = button1ContextMenu;

Et hop, un menu contextuel affecté à un bouton (ou à la fenêtre principale, ou à n’importe quoi) en deux lignes. Et, bien sûr, j’ai coupé dans le code, mais il suffit aussi de quelques lignes pour le remplir et définir les fonctions qui seront appelées quand l’utilisateur cliquera. Limpide.

Il est temps de conclure l’opération publicitaire (gratuite, vous croyez quand même pas que j’accepterais de l’argent de Microsoft) en beauté, avec mon logiciel à moi : en quelques heures de programmation, en quelques pages de code, un logiciel qui affiche une image (euh, ouais… non mais, sérieusement, c’était une galère, avant — en plus, c’est un JPEG, alors qu’à l’époque de Ghrone j’avais dû charger une librairie indépendante sur le web pour pouvoir lire autre chose que du BMP), charge le fil RSS de mon blog, l’affiche dans un mini Explorer, et ouvre le browser quand on double-clique sur un post.

Temps de programmation : huit heures. Dont deux heures à essayer de faire un fichier C++ qui passe l’étape de la compilation (je vous dis, laissez tomber), une heure à chercher le compilateur C# qui est fourni gratuitement avec .NET (pas compris pourquoi il est dans le répertoire Windows, pas dans celui du SDK), une heure pour comprendre comment intégrer une putain d’icône dans les ressources du programme (j’ai toujours eu du mal avec les ressources dans Windows, je ne sais pas pourquoi, je trouve vraiment le système mal fichu — et là c’est évidemment pire quand on travaille en ligne de commande), une heure pour lancer le browser par défaut quand on double-clique dans la liste (je ne sais pas si ça vient de .NET, de Firefox ou du Service Pack Windows anti-monopole, mais on ne peut plus demander l’exécution d’une URL, il faut aller chercher soi-même dans la base de registre l’emplacement du browser par défaut) et une autre heure pour que le contrôle ActiveX lance aussi le browser par défaut quand on clique sur un lien.

Ce qui veut dire, donc, qu’en deux heures seulement j’ai pu créer mon tout premier programme en C# sous .NET, avec l’affichage d’une image en haut, la gestion d’une liste, l’intégration d’un mini-browser, et la lecture d’un fil RSS. Deux heures, alors que je découvrais .NET et que la documentation incluse est loin d’être optimale (pour ça aussi, il me semble que les docs Borland étaient mieux, à l’époque).

Du coup, forcément, je vais me remettre à la programmation, il va bien falloir. J’en avais parlé il n’y a pas longtemps, mais là je sais que c’est réellement possible : j’ai envie de faire un clone de Exposé + Dashboard + Dock. C’est faisable. Il faut juste que je reste motivé assez longtemps.