Claude SIMON a écrit 539 commentaires

Quand j'ai écrit ce framework, ce n'est pas parce que j'étais insatisfait de la qualité des logiciels produits de manière classique. La qualité dont je parle est celle perçue par mes clients et dont ils me font part. J'ignore lesquels des points que tu cites ils prennent en compte dans leur opinions qu'ils ont des logiciels que je développe pour eux. Quand à moi, en tant que développeur, je trouve que les bugs de jeunesse sont facilement corrigés, que je n'ai pas de difficulté particulière à faire évoluer mes logiciels, et que la maintenance requiert peu d'efforts. Ceci dit, j'ai peu d'éléments de comparaison, ayant quasiment toujours travaillé uniquement avec mon framework.

Le framewok en question, ça reste un framework C++ ; il n'y a pas de nouveau langage, ou de méta-langage. Donc, un Hello world ! ne différerait pas de manière significative avec la version écrite en C++ standard.

Pour ce qui est de Haïku, je ne connais pas donc je ne saurais dire. Si similitude il y a, elle serait totalement fortuite.

Je sais que je sors des sentiers battus (on me l'a suffisamment fait remarqué dans le journal sur XUL mentionné ci-dessus, d'ailleurs avec le même genre de remarque, mais sur le diptyque XUL/JS) ), mas ça ne m'a pas trop mal réussis jusqu'à présent.

Quoi qu'il en soit, merci pour tes encouragements !

Pour nous émanciper des géants du numérique : Zelbinium !

Peut-être que le logiciel a des similitudes avec SàT, mais le projet faisant l'objet de ce journal ne se limite pas à ce seul logiciel.

Ce n'est pas par plaisir de développer ma propre solution que je travaille sur ce projet, mais c'est pour développer une solution qui offre des possibilités qu'aucune autre n'offre.

J'ai étudié des solutions existantes, mais aucune ne répondait à mes attentes. Maintenant, si j'en ai loupée une, je veux bien que l'on me fasse la découvrir. C'est l'un de buts de ce journal, que l'on puisse m'indiquer si, et, le cas échéant, où je me fourvoie.

Pour nous émanciper des géants du numérique : Zelbinium !

Comme je l'ai clairement, et à plusieurs reprises, indiqué dans le journal, le logiciel fait peu, très peu, mais pas rien. Et comme c'est précisé dans le titre, ce n'est que le commencement. Il en faut bien un.

Aussi peu qu'il fasse, ça m’étonnerait que ce soit faisable avec des scripts, qu'ils soient à la con ou pas. Mais je ne connais pas tous les langages, alors il est possible que je me trompe, et je serais enchanté d'en apprendre plus sur le sujet.

Comme indiqué dans le journal, on peut télécharger les sources, voire les consulter en ligne, lancer la version Windows de l'application en quelque clics (et quelques commandes saisies dans la console, il est vrai) voire la lancer sur d'autres OS (bon, là, c'est vrai, ce n'est pas aussi simple qu'avec Windows, parce que je ne sais pas faire). Bref, il y a largement de quoi se rendre compte que le framework est loin d'être vide.

Sinon, l'objectif de ce framework est de simplifier le développement d'applications (je ne suis pas masochiste). Et je répondrais volontiers à toute question sur des points qui peuvent paraître obscurs.

Pour nous émanciper des géants du numérique : Zelbinium !

Pas la peine de sortir. Le fait est que, bien avant que l'on ne parle de HTML5, j'utilisais XUL pour mes interfaces graphiques. J'ai d'ailleurs écris ce journal à ce sujet. Pour le natif, j’utilisais XULRunner ; par contre, pour le Web, comme seul Firefox était capable d'afficher du XUL, je devais faire une version de l'interface en HTML pour pouvoir l'afficher dans d'autres navigateurs.

Ce que j'appelle XDHTML n'est en fait que ce que je faisais déjà avec XUL, mais en plus avancé, et avec HTML5. Avec l'avantage, cette fois-ci, de pouvoir utiliser le même code pour la version native et la version Web

Pour nous émanciper des géants du numérique : Zelbinium !

Ça ne serait pas plutôt :

 struct _item *voisin;

Parce que sinon, la structure se contient elle-même…

Pour nous émanciper des géants du numérique : Zelbinium !

Je ne me suis jamais vraiment intéressé à ces histoires de certificats, mais j'ai un serveur sous Debian 8 et, suite à une mise à jour réalisée dernièrement, j'ai trouvé le courrier suivant dans la boite mail du compte root de mon serveur (quelque chose de similaire avait été affiché lors de la mise à jour proprement dite, mais je n'y ai pas vraiment prêté attention) :

ca-certificates (20141019+deb8u1) stable; urgency=medium

  Update Mozilla certificate authority bundle to version 2.6.
    The following certificate authorities were added (+):
    + "CA WoSign ECC Root"
    + "Certification Authority of WoSign G2"
    + "Certinomis - Root CA"
    + "CFCA EV ROOT"
    + "COMODO RSA Certification Authority"
    + "Entrust Root Certification Authority - EC1"
    + "Entrust Root Certification Authority - G2"
    + "GlobalSign ECC Root CA - R4"
    + "GlobalSign ECC Root CA - R5"
    + "IdenTrust Commercial Root CA 1"
    + "IdenTrust Public Sector Root CA 1"
    + "OISTE WISeKey Global Root GB CA"
    + "S-TRUST Universal Root CA"
    + "Staat der Nederlanden EV Root CA"
    + "Staat der Nederlanden Root CA - G3"
    + "TÜRKTRUST Elektronik Sertifika Hizmet Saglayicisi H5"
    + "TÜRKTRUST Elektronik Sertifika Hizmet Saglayicisi H6"
    + "USERTrust ECC Certification Authority"
    + "USERTrust RSA Certification Authority"
    The following certificate authorities were removed (-):
    - "A-Trust-nQual-03"
    - "America Online Root Certification Authority 1"
    - "America Online Root Certification Authority 2"
    - "Buypass Class 3 CA 1"
    - "ComSign Secured CA"
    - "Digital Signature Trust Co. Global CA 1"
    - "Digital Signature Trust Co. Global CA 3"
    - "E-Guven Kok Elektronik Sertifika Hizmet Saglayicisi"
    - "GTE CyberTrust Global Root"
    - "SG TRUST SERVICES RACINE"
    - "TC TrustCenter Class 2 CA II"
    - "TC TrustCenter Universal CA I"
    - "Thawte Premium Server CA"
    - "Thawte Server CA"
    - "TURKTRUST Certificate Services Provider Root 1"
    - "TURKTRUST Certificate Services Provider Root 2"
    - "UTN DATACorp SGC Root CA"
    - "Verisign Class 4 Public Primary Certification Authority - G3"

D’après ce que j'en comprend, on y voit que les certificate authorities USERTrust RSA Certification Authority et COMODO RSA Certification Authority, référencées par les messages retournés par openssl, ont été ajoutées.

Il y a peut-être un problème dans ta procédure de mise à à jour…

Pour nous émanciper des géants du numérique : Zelbinium !

Pour les exclusions, il y a raison particulière de ne pas avoir utilisé le même format que gitignore ? Là, le format où tmp signifie en fait un fichier avec une extension .tmp, je trouve ça assez déroutant.

Tout simplement le fait que j'ignorais l'existence de gitignore. Bref, ce n'est pas un format que j'ai exclu sciemment…
Comme pour toutes les autres fonctionnalités du programme, j'ai juste implémenté la première mise en œuvre qui me passait par la tête (pour faire court). Le tmp équivalent à .tmp, c'est juste une facilité que j'ai rajoutée car facile à coder. Maintenant, il faut voir ce que tout cela donne à l'usage, et affiner/modifier en conséquence…

Pour nous émanciper des géants du numérique : Zelbinium !

Voir ce commentaire.

Pour nous émanciper des géants du numérique : Zelbinium !

fwtchrq se contente de parcourir l’arborescence et d'en comparer le contenu avec une image qu'il en a faite lors d'un précédent lancement. De par les marqueurs qu'il place dans l’arborescence surveillée, il est capable de détecter les créations/renommages/déplacements/suppressions de répertoires. Par contre, concernant les fichiers, vu qu'il s'appuient uniquement sur leur taille et leur horodatage, il rapportera le renommage d'un fichier, par exemple, comme une création et une suppression de fichiers. Pour les mêmes raisons, une permutation de fichiers sera, à priori, rapporté comme une modification de chacun des fichiers

inotify serait, à priori, un bon outil pour détecter un renommage de fichier. Toutefois, j'ai essayé inotifywatch -r sur mon arborescence de test, qui est extrêmement fournie : c'est lent, et, en outre, il n'a pas été en mesure d'aller jusqu'au bout faute d'un nombre suffisant de inode watches. Je suis donc, pour l'instant, dubitatif quand à l'intérêt de cet outil dans le cadre du développement de fwtchrq.

Il y une gestion des exclusions, que l'on spécifie à l'aide d'un fichier, tel que celui que l'on trouve à l'adresse : http://hg.savannah.gnu.org/hgweb/epeios/file/70ebcb4eaa50/tools/fwtchrq/Exclusions.txt. Le fichier d'exclusion à utiliser et à spécifier dans le fichier de configuration, comme on peut le voir à cette adresse (la section en question est en commentaire) http://hg.savannah.gnu.org/hgweb/epeios/file/70ebcb4eaa50/tools/fwtchrq/fwtchrq.xcfg. Lorsqu'un répertoire est exclu, il est vraiment totalement ignoré par le logiciel.

Comme indiqué dans le journal, il ne s'agit là vraiment que d'un tout premier jet. Ce logiciel peut évoluer dans n'importe quelle direction (utilisation de inotify sous GNU/Linux et équivalent pour les autres systèmes, prise en compte d'autres critères que la taille et l'horodatage pour les fichiers, configurabilité de la gestion des exclusions…), pour peu que la demande soit telle que cela vaille la peine pour moi d'y investir le temps nécessaire…

Pour nous émanciper des géants du numérique : Zelbinium !

Quel est l'intérêt ? De ce que j'en connais, Git est un logiciel de gestion de version ; or, dans la page dédié à fwtchrq, il y a les liens vers un dépôt Mercurial hébergé sur Savannah contenant les sources de fwtchrq…

Pour nous émanciper des géants du numérique : Zelbinium !

L'ennui avec les noms de logiciels, comme avec les noms de domaines d'ailleurs, c'est que, si vous arrivez à en trouver un qui soit assez court, évocateur, joli (quoique l'on puisse entendre par ce terme ; la prononçabilité, par exemple), facile à retenir, etc., et bien, il y des chances que ce nom, ou une forme proche, soit déjà utilisé. Le risque existe alors d'avoir un jour à le changer, avec tous les désagréments que cela implique (modification de tous les documents comportant ce nom), sous peine de risquer un conflit avec une quelconque entité qui utilise un vocable qui présente, ne fût-ce que vaguement, des similitudes avec le nom en question pour désigner l'un de ses produits. C'est déjà arrivé à plus d'un logiciel.

Par ailleurs, je référence mes logiciels sur différents sites, à l'instar, par exemple, de xppq, qui est référencé sur Savannah et Freshcode, pour ne citer que ces deux-là. Pour pouvoir référencer son logiciel sur l'un de ses sites, il faut lui affecter un identifiant unique, et il est pratique alors d'utiliser le nom même du logiciel, comme cela est visible dans les URL ci-avant, plutôt que d'avoir à en trouver un autre, et à devoir se le rappeler, pour chaque site pour lequel cet identifiant est déjà utilisé.

fwtchrq n'est pas le premier logiciel (et, j'espère, pas le dernier non plus) libre que je développe. Et je n'ai pas envie, à chaque fois que j'entreprends de développer un nouveau logiciel, de perdre des heures à chercher un nom qui soit assez court, évocateur, joli, facile à retenir, etc., puis à devoir vérifier qu'il, ou une forme proche, ne soit pas déjà utilisé, découvrir qu'il l'est déjà et avoir à en chercher un autre je ne sais combien de fois, tout en n'ayant jamais la certitude d'avoir poussé mes recherches suffisamment loin pour avoir définitivement écartée l'épée de Damoclès.

Bref, les noms de mes logiciels semblent peut-être biscornus, mais c'est le prix à payer pour avoir une probabilité raisonnablement forte de n'avoir jamais à les changer…

Pour nous émanciper des géants du numérique : Zelbinium !

J'ai implémenté un tel système dans mon framework ; j'en ai parlé dans ce journal.
Le système a un peu évolué depuis ; la courte description sur cette page est plus à jour.
L'implémentation en question n'est pas disponible en tant que bibliothèque dédiée, mais les sources étant accessibles, ça peut peut-être quand même être utile…

Pour nous émanciper des géants du numérique : Zelbinium !

Je suis actuellement en train de développer une application web, ma première en AJAX, et j'ai bien entendu rencontré le problème des input time/date non implémentés, mais j'ai pu m'en accommoder. Par contre, il y a un autre bug, qui, lui, m'embête bien car je ne vois absolument pas comment le contourner. Et celui-là, en plus d'être apparemment au point mort (plus de trois ans sans nouveau commentaire !), est antédiluvien (il date de 2001 !). Donc, j'ai une application web qui tourne sur tous les navigateurs modernes (y compris Safari), sauf IE (pour autant qu'on puisse encore le qualifier de moderne), Edge (à priori à cause d'un bug qui lui fait exécuter, sans raison, un script en boucle, mais il devrait y avoir moyen de le contourner) et donc, hélas, Firefox…

Pour nous émanciper des géants du numérique : Zelbinium !

Quand on achète un ordinateur avec Windows et des crapwares préinstallés, qu'on le reformate pour réinstaller Windows, évidemment sans les crapwares, ou pour installer un autre OS, n'est-ce pas comparable au fait d'aller sur un site web bardé de publicités avec un bloqueur de publicités ?

Je me faisais cette réflexion parce qu'il semble y avoir justement une prise de conscience de certains des acteurs de la publicité sur Internet de leurs abus dans le domaine, et ce suite à la généralisation des bloqueurs de publicités. Peut-être que les responsables des crapwares auront un jour une démarche similaire, pour autant qu'il soit concevable qu'il puisse exister des crapeware respectueux de l'utilisateur, tout comme des publicités non intrusives…

Pour nous émanciper des géants du numérique : Zelbinium !

J'ai moi-même installé squirrelmail sur mon serveur, et cela n'a pas été sans mal, ceci pour dire que mes connaissances sont assez limitées dans le domaine, donc ce qui suit est peut-être erroné. Cependant, pour ce que je crois en avoir compris de son fonctionnement, mis à part si on lui demande d'afficher toute la liste des courriers d'une boîte et que ceux-ci soient vraiment nombreux, je ne vois pas trop pourquoi squirrelmail poserait problème, vu que ce n'est pas lui qui gère directement les courriers.
Avec certaines distributions GNU/Linux, le format de stockage de courriers est mbox par défaut, un format dans lequel plusieurs courriers sont stockés dans un seul et même fichier. Donc, avec une boîte mail de 1 Go, on peut se retrouver avec un fichier de la même taille contenant tous les courriers de cette boîte. On peut aisément imaginer que la manipulation d'un tel fichier, notamment pour accéder à un courrier en particulier, puisse prendre un certains temps.
En ce me qui concerne, le format mbox posait problème pour la sauvegarde des courriers. A chaque nouveau courrier qui arrivait dans ma boîte, je me retrouvais à devoir sauvegarder l'ensemble de tous les courriers, même ceux déjà sauvegardés, puisque tous étaient stockés dans un seul et même fichier (mes sauvegardes s'appuient sur rsync). C'est pour cela que je suis passé au format de stockage de courrier Maildir, avec lequel chaque courrier est stocké dans un fichier qui lui est propre, ce qui a évidemment résolu mon problème de sauvegarde.
Maildir ou mbox, ce n'est pas squirrelmail qui gère cela, mais le serveur SMTP (enfin, je crois, et sans doute que le serveur IMAP doit aussi être configuré en conséquence). Face à un problème comme le tiens, je vérifierais d'abord le format de stockage des courriers, parce que si c'est mbox, il y a de fortes chances que le problème vienne de là, et changer de webmail ne le résoudrait en rien.

Pour nous émanciper des géants du numérique : Zelbinium !

Il y a quelques années de cela, j'ai eu exactement le même problème avec une machine d'une connaissance fraîchement installée (la machine, pas la connaissance, encore qu'elle venait d'emménager) à partir des CD-ROMs officiels (je ne sais par contre plus de quelle version de Windows il s'agissait), et que j'avais directement branchée sur une box pour réaliser les mises à jour de sécurité. J'ai dû la reformater, la réinstaller totalement, et procéder aux mises à jour de sécurité en prenant soin de la connecter à Internet via mon serveur GNU/Linux, faisant office de pare-feu matériel, pour qu'elle soit fonctionnelle. Bref, il semblait que cette version de Windows, telle que fraîchement installée à partir des CD-ROMs, comportait des failles à l'affût desquelles de nombreux bots circulaient sur Internet, failles heureusement comblées par les mises à jour de sécurité, mais encore fallait-t-il pouvoir les installer avant que ces bots ne puissent entrer en action…

Ceci dit, cela me surprendrait qu'une version somme toute assez récente de Windows ne soit pas conçue pour faire face à ce genre de situation, et, qu'en outre, de nos jours, les dispositifs conçus pour offrir un accès à Internet ne soient pas, par défaut, configurés pour préserver les machines qui y sont connectées de ce genre de mésaventure, mais sait-on jamais…

Pour nous émanciper des géants du numérique : Zelbinium !

Mon but n’est pas d'utiliser à tout prix des technologies web. Il se trouve que HTML5, typiquement une techno web, est un bon candidat pour remplacer XUL, que je voulais abandonner pour les raisons citées dans le journal. Par contre, j'utilisais déjà C++ avec XUL (alors que, tout comme avec HTML, l'usage est également d'utiliser JavaScript), et cela fonctionnait parfaitement, donc je n'avais aucune raison de passer à JavaScript.

Pour nous émanciper des géants du numérique : Zelbinium !

C'est juste qu'avec HTML, je pouvais ajouter des éléments et attributs maisons (les fameux xdh-... et data-xdh-... du journal) qu'il était facile de traiter avec des outils DOM classiques, alors qu'avec le JSON-like de QML je ne pouvais pas (ou je n'ai pas trouvé comment) faire la même chose.
Au final, c'est surtout, comme indiqué à la fin du journal, la perspective de pouvoir avoir un seul et même code (C++ qui plus est) pour la version web et la version native d'une application qui m'a fait préférer HTML à Qt et consorts.

Pour nous émanciper des géants du numérique : Zelbinium !

[…] un BAC STI électronique (F3 pour les grabataires…) […]

F3, c'était électrotechnique. Le BAC électronique, c'était F2…

(grabataire, peut-être, mais pas encore sénile… :-))

Pour nous émanciper des géants du numérique : Zelbinium !

Les premières lignes de ce qui est devenu le framework Epeios datent d'il y a plus de quinze ans. Les domaines d'application de ce framework, et par conséquent le nombre de ligne qui le compose, n'ont cessé de s'accroître depuis. Rédiger la documentation correspondante représenterait une tâche titanesque pour une personne seule, sans compter, le framework évoluant sans cesse, le temps qui serait nécessaire rien que pour la tenir à jour.

J'utilise quotidiennement ce framework, et cette absence de toute documentation ne m'a jamais dérangé (le fait que c'est moi qui l'ai développé n'y est sans doute pas étranger), aussi préfère-je consacrer mon temps au développement et à l'amélioration de ce framework, plutôt qu'à la rédaction d'une documentation qui ne me serait d'aucune utilité. Si je le mentionne systématiquement lorsque l'un de mes logiciels (c'est-à-dire tous) se base sur ce framework, c'est parce que cela a certaines implications pour le logiciel en question. Par exemple, cela implique qu'il soit multi-plateformes et multi-architectures, qu'il possède un mécanisme spécial de gestion des arguments, que j'ai décrit dans ce journal, lorsque c'est un utilitaire en ligne de commande, qu'il utilise une registry interne rempli par un fichier de configuration…

Ceci dit, il y a cela fort (fort) longtemps, j'avais écrit un début de documentation. J'en ai retrouvé la trace durant mes investigations à l'occasion de la rédaction de ce commentaire. Apparemment, j'en avais même écrit plusieurs versions (voir ici et ici). Je n'ai pas relu, donc je ne garantis rien quant au contenu…

Pour nous émanciper des géants du numérique : Zelbinium !

Ce ne sont pas des acronymes, simplement des assemblages de quelques lettres issues de l'intitulé (anglais) du logiciel concerné. La dernière lettre n'a pas de signification particulière.

Pour nous émanciper des géants du numérique : Zelbinium !

Par exemple, lorsque l'on travaille sur plusieurs partitions en même temps, on a tendance à les travailler dans un certain ordre, pour être sûr de n'en oublier aucune. Ce faisant, on risque de mettre en place une sorte de réflexe pavlovien.
Ainsi, supposons qu'après avoir travaillé une partition A, relativement facile, on travaille systématiquement la partition B, avec laquelle on rencontre des difficultés. Même si on ne se focalise pas sur ces difficultés, après avoir travaillé A, notre subconscient peut nous faire aborder la partition B de manière moins sereine, parce qu'il sait que la partition qui suit A est systématiquement plus difficile. Avec dpkq, comme les partitions ne se suivent pas dans le même ordre d'une session à l'autre, ce genre d'appréhension inconsciente ne peut se mettre en place.

D'autre part, les segments concernant les partitions que je rejoue régulièrement pour ne pas les oublier sont assez nombreux ; il me faut plusieurs jours pour en faire le tour. dpkq me permet de n'en oublier aucun, bien que je ne les joue jamais dans le même ordre, sachant que dpkq ne pioche jamais deux fois le même segment si tous les autres n'ont pas été piochés au moins une fois.

Quant aux fiches elle-mêmes, il faut savoir qu'une fois que j'ai déchiffré une pièce, je la connais par cœur, donc je ne recours plus qu'exceptionnellement à la partition. La fiche me montrant une image de la partition, avec les numéros des mesures à travailler dans le cadre de cette fiche, cela me suffit à me remémorer la partie à travailler (comme mentionné, je joue par cœur, donc sans l'inconfort d'avoir à suivre la partition sur la tablette). Si j'ai un trou de mémoire, la consultation de la fiche me permet généralement de le combler.
Au final, une fois travaillées, je peux ranger mes partitions, au lieu de les empiler sur mon piano/orgue pour les avoirs toujours à portée de main… D'un autre coté, si je n'ai que rarement besoin des partitions pour ces pièces, c'est aussi parce que dpkq me permet de me les remémorer de manière régulière, systématique et exhaustive…

Pour nous émanciper des géants du numérique : Zelbinium !

Je n'étais pas réellement "passé" sous Linux à cette époque, puisque ma machine de travail était toujours sous Windows, mais j'avais installé Linux sur une de mes anciennes machines pour en faire un serveur Web. J'avais un temps envisagé d'y installer Windows NT, mais la machine en question n'était pas assez puissante. J'ai donc opté pour Linux, dont un ami possédait des CD's d'installation (InfoMagic), bien que je ne l'avais jamais utilisé auparavant (mais j'avais déjà eu affaire à des machines sous UNIX). A priori, l'installation s'est déroulé sans problème (du moins, je ne me souviens pas d'en avoir rencontrés), sachant que, mis à part les composants de base, la machine n'était équipée que d'une carte Ethernet (outre l'alimentation, le câble Ethernet était d'ailleurs le seul autre câble branché sur cette machine). Ainsi, grâce à Linux, et un arrangement avec mon FAI de l'époque qui m'a permis de bénéficier d'une IP fixe, j'ai pu auto-héberger mes premiers services Internet. C'était en 97.

Pour nous émanciper des géants du numérique : Zelbinium !

De ce que je comprends, xppq est un transformateur XML, un peu comme xslt. Il utilise une partie de son code pour parser ses arguments.

Je ne dirais pas transformateur, dans la mesure où c'est une toute approche que XSLT, déjà par le fait que tout ce qui est relatif aux directives xpp est directement dans le fichier à traiter, et non pas dans un fichier à part, comme avec XSLT…

Je me demande par contre si "pp" veut dire "pull parser".

pp a la même signification dans xppq que dans cpp, à savoir PreProcessor. En fait, xppq est conçu pour être à XML ce que cpp est au C/C++.

De toute manière, je ne savais pas ce qu'est un pull parser, mais, pour ce que j'en ai compris, xppq implémente bien un parser de ce type…

Pour nous émanciper des géants du numérique : Zelbinium !

Je suis d’accord, est-ce que ça remplace getopt ? J’ai aussi l’impression que ça veut reprendre la gestion des fichiers de conf en donnant une approche à la base de registre…

En effet, cela ne remplace pas seulement getopt, mais prend effectivement en charge la gestion des fichiers de configuration. C'est dû à l'utilisation du framewok Epeios, avec lequel le point d'entrée du logiciel n'est pas le classique main(...) ou équivalent (qui est en fait défini par le framework), mais une autre fonction, (SCLTOOLMain(...), en fait, pour des application en ligne de commande). Lorsque cette dernière est appelée, les fichiers de configurations sont déjà chargés, et les arguments de la ligne de commande sont déjà traités, la registry ayant été remplie en conséquence.

Bref, c’est flou.

Comme écrit précédemment (en fait dans un commentaire plus bas), la rédaction de documentation n'est, hélas, pas mon fort (c'est un métier)…

Pour nous émanciper des géants du numérique : Zelbinium !