[NDA: Article écrit en Juillet 1995, publié dans ST Magazine n° 99 en Novembre 1995.]
Le Minitel à beau être technologiquement dépassé, il n’en reste pas moins le moyen de consultation électronique de données le plus répandu en France avec près de 7 millions d’unités installées. En ouvrant un serveur Minitel, vous avez donc un public potentiel assez large! Néanmoins, il vous faut un logiciel adapté à vos besoins. Nous vous proposons ici de partir du “best-seller” STUT-ONE pour réaliser votre propre logiciel, sur mesure!
HISTORIQUE
Il y a deux ans (déjà!) nous vous offrions sur la disquette du magazine, le logiciel serveur STUT ONE 2.6 et nous vous expliquions comment l’utiliser pour créer un serveur Minitel (numéros 72 à 75). Remercions au passage Thomas Conté pour l’initiative. Avant de lire la suite, nous vous recommandons vivement de relire ces numéros, ou, si besoin est, de les commander à la boutique Pressimage.
Simulation d'écran Minitel
Aujourd’hui, STUT ONE 2.6 est encore très utilisé mais… vous vous êtes fait la main dessus et il finit par accuser certaines limitations que vous jugez probablement insupportables. Disons par exemple qu’il ne supporte pas d’autre protocole de téléchargement que Transteaser ou encore que la capacité des BALs est trop limitée.
Alors bien sûr il y a STUT ONE 3… mais personne ne peut dire quand est-ce qu’il sera fini! Je suis particulièrement bien placé pour le dire, puisque j’en suis l’auteur! De toutes façons, STUT 3 fonctionne sur un principe assez différent de STUT 2 et vous demanderait une phase d’adaptation assez importante…
Finalement, vous êtes nombreux à me poser régulièrement des questions sur l’art et la manière de programmer un logiciel serveur sur ST et je n’ai pas toujours le temps de répondre. Parfois, vos questions sont tellement techniques qu’elles m’obligeraient à effectuer des recherches approfondies dans le code source de STUT ONE pour retrouver la solution.
Pour toutes ces raisons, nous avons décidé de vous offrir ce mois-ci le code source intégral de STUT ONE version 2.6X. Vous le trouverez sur la disquette. [NDA: Vous le trouverez en téléchargement sous cet article.]
NOTRE OBJECTIF…
Nous n’avons pas l’intention de vous donner un code source de 500 Kilo-octets et de vous dire “débrouillez-vous avec çà!”. Nous allons en fait vous donner plus de détails sur la manière dont il est structuré et surtout les grands principes à appliquer lorsque l’on programme un logiciel serveur. Vous pourrez constater que le code source ne respecte pas toujours ces principes; mais cela s’explique peut-être par le fait que j’ai déterminé ces principes en partant des erreurs commises en écrivant le logiciel!
Nous n’allons cependant pas nous attarder sur les détails d’utilisation du logiciel. C’est surtout par manque de place, mais aussi parce que nous l’avons déjà fait dans les numéros 72 à 75 de ST Mag.
Si vous êtes utilisateur de STUT ONE 2.6, vous pourrez prochainement le modifier selon vos besoins et ajouter les fonctions qui vous manquaient jusque là. Si vous n’utilisez pas encore STUT ONE, c’est peut-être le moment de vous y mettre; vous ne risquez rien, puisque vous pourrez TOUT adapter à vos besoins spécifiques. Quant à ceux qui ont déjà ou sont en train de programmer leur logiciel serveur “maison”, ils pourront bien sûr s’inspirer des principes donnés ici, voire intégrer les leurs à STUT ONE.
Cette version de STUT ONE est programmée en GfA-Basic, mais en fait, le langage utilisé n’a pas beaucoup d’importance. En effet, nous ne faisons pas ici un cours de programmation, mais plutôt une revue de concepts applicables aux serveurs télématiques. En conséquence, vous êtes donc supposés savoir déjà programmer… mais, le cas échéant, apprendre le GfA-Basic reste une tâche tout à fait abordable…
Par contre, il faut savoir que cette version de STUT ONE ne gère que le Minitel (pas de modem), et un seul (un seul connecté à la fois). Nous nous limiterons donc (dans un premier temps du moins) à expliquer le fonctionnement de logiciels serveurs Minitel Monovoie.
Dernier détail: STUT ONE est prévu pour être utilisé sur le réseau téléphonique commuté (RTC) et non sur Transpac. Concrètement, cela veut dire que votre serveur est accessible par un numéro de téléphone standard à 8 chiffres et non pas par un quelconque 36 15 suivi d’un code. La programmation d’un serveur pour Transpac serait sensiblement différente… elle implique le multivoies, une partie des fonctions est prises en charge directement par les Points d’Accès Videotex de France Télécom, etc… Mais de toute façon, vu le coût d’une ligne Transpac, çà n’intéresserait qu’un nombre très restreint de nos lecteurs!
A part cela, j’ai un avertissement à donner: le style de programmation utilisé dans ce logiciel n’est vraiment pas un exemple à suivre. Si vous le faites quand même, je ne réponds plus de rien le jour ou voudrez débugguer votre application!
A VOS MARQUES…
Si vous décompactez le fichier fourni sur la disquette vous obtiendrez un dossier prosaïquement nommé “SOURCE” contenant le code source de STUT ONE 2.6X et tous les fichiers nécessaires à son exploitation. Vous avez le logiciel complet prêt à l’emploi. Vous trouverez également le fichier LICENSE.TXT dans lequel vous trouverez les conditions d’utilisation du logiciel (nous en reparlerons!)
Le gros morceau c’est le fichier STUT_26X.LST. Il contient 20 000 lignes de GfA-Basic bien tassées. J’entends par là, qu’il y a peu de commentaires, ce qui est un tort. (Rassurez-vous, il y en a quand même un certain nombre!) Sachez simplement que ce fichier doit être chargé dans votre interpréteur GfA-Basic avec l’option MERGE (Ca prend quelques minutes, vu la taille!). Vous pourrez ensuite le sauvez en STUT_26X.GFA ce qui sera plus rapide! Nous vous avons fourni le source sous forme de .LST parce que les .GFA ne sont pas compatibles d’une version à l’autre. Pour le développement, j’ai utilisé les version 3.07 puis 3.50… si vous avez une autre version, essayez et vous verrez bien! La seule certitude est que çà ne marchera pas avec les versions antérieures à la 3.0.
STUT_26X.RSC est le fichier de ressources; c’est là que sont définis les menus et boîtes de dialogues utilisées par le programme. Vous avez besoin d’un éditeur de ressources pour le modifier. N’importe lequel fera l’affaire, mais le fichier de définition STUT_26X.RSD vous rendra la vie plus agréable si c’est “Interface” que vous utilisez. ATTENTION: le fichier .RSC est assez gros: il fait près de 64 Ko… et les fichiers ressources de plus de 64 Ko posent souvent de gros problèmes… surtout avec le GfA!
STUT_26X.DEF est un fichier texte (éditable avec 7Up par exemple) qui contient un certain nombre de paramètres par défaut. Une copie est fournie sous COPY_26X.DEF pour le cas où vous auriez modifié ces paramètres au delà du raisonnable et que vous voudriez rapidement revenir à l’original.
Finalement STUT_26X.NEW est un fichier contenant un serveur de base sous forme pseudo-compactée. STUT ONE va lire ce fichier lorsque vous invoquez l’option “Créer un nouveau serveur”.
…PRET
Voilà, vous êtes maintenant prêts à utiliser le code source. Si vous le chargez dans l’interpréteur et que vous cliquez sur “Run” il devrait s’ éxecuter sans aucun problème et pouvoir charger, sans aucun problème non plus, votre serveur réalisé sous STUT ONE 2.60. (En fait, le format des fichiers est resté le même depuis la version 2.4, si ma mémoire est bonne.) Songez seulement que vous aurez besoin de plus de mémoire qu’à l’accoutumée, puisque le GfA-Basic à lui seul, en occupera une certaine partie. Vous bénéficierez ensuite immédiatement des corrections de quelques bugs gênants dans STUT ONE 2.60.
STUT ONE 2.6X est en fait l’ultime évolution de STUT ONE 2.63. La version 2.6X était destinée à devenir la version 2.7 mais elle n’a jamais été achevée. Vous constaterez d’ailleurs que certaines nouvelles fonctions ne sont que partiellement implantées… Je pense en particulier à la gestion de TEXTES qui utilise actuellement le même espace mémoire que la gestion des pages vidéotex… Mais rassurez vous, la compatibilité ascendante avec la version 2.63 est totale.
Pour la petite histoire, sachez simplement que si j’ai arrêté le développement de STUT 2.7, c’est d’une part, parce que je ne supportais plus les caprices du GfA-Basic et de son compilateur ainsi que leurs limitations respectives et d’autre part, parce que j’avais tout un panier d’idées nouvelles qui auraient été très difficiles à rajouter à la version 2.6. J’ai alors recommencé un nouveau logiciel: STUT 3, écrit en langage C, multivoies et tout çà… Le hic, c’est que j’ai eu les yeux plus gros que le ventre, où plutôt devrais-je dire: les pensées plus rapides que les doigts, et je suis loin d’avoir fini de le programmer. Aujourd’hui, STUT 2.6 lui reste encore supérieur quant au nombre de fonctions disponibles…
Si vous disposez d’un compilateur GfA Basic, vous devriez également pouvoir compiler le source sans problème en utilisant les options par défaut. Cependant, il y a une variable globale (inter!) à mettre à 0 dans le code source.
Si vous n’avez pas encore réalisé de serveur avec une version antérieure de STUT ONE que vous pouvez charger et si vous n’avez pas encore reçu vos numéros 72 à 75 de ST Mag, le meilleur endroit pour commencer est de cliquer sur l’option “Créer un nouveau serveur…” du menu “Fichier” de STUT ONE. Après çà, vous devrez utiliser une méthode un peu plus heuristique pour arriver à vos fins! (Pour ceux qui veulent des termes plus concrets: vous devrez utiliser votre pifomètre!)
…PARTEZ!
Bien, si vous êtes arrivés jusque là sans recourir à l’utilisation de médicaments pour le nerfs ou la migraine, c’est que vous avez le profil requis pour développer un serveur, ou du moins, pour faire évoluer STUT ONE! Surtout, pas de panique, mais si néanmoins vous avez coincé alors que vous êtes très intéressé par la suite, contactez-moi par Minitel (j’ai dit: PAR MINITEL!) au (1) 00.00.29.45 [NDA: ce numéro n’est plus attribué… évidemment :)] code STUT ou bien sur Internet [NDA: en fait, aujourd’hui je ne pourrai plus vous en dire grand chose :)]. Il y a aussi le 36 15 STMAG… mais il y a fort à parier que si vous vous intéressez à la programmation d’un serveur RTC, vous n’ayez pas des sentiments très tendres envers les 36 15…
Commencez donc par regarder le code source dans son intégralité avec les procédures repliées (Control-Help en ayant le curseur sur un nom de procédure). Vous constaterez qu’il y a cinq parties principales.
La première est un bla-bla parlant du logiciel et de sa licence qu’il est bon de lire au moins une fois mais qui n’a aucune influence sur le fonctionnement du logiciel proprement dit. Bon, trêve de plaisanterie, passons aux choses sérieuses…
La deuxième partie est le programme principal. Il est assez court et appelle de nombreuses fonctions qui se chargent d’effectuer les différentes tâches. Il y a quelques détails à noter lors de l’initialisation. Tout d’abord la variable inter! indique au reste du programme que l’on tourne sous l’interpréteur ou que le programme est compilé (dans ce cas, vous devez bien sûr le compiler vous même!). Sous interpréteur, certaines actions supplémentaires sont effectuées par rapport au programme compilé. En particulier, on dessine un fond de bureau au démarrage puisque le GfA démarre avec un écran blanc. Sous interpréteur, on fixe aussi “à la main” (avec CHDRIVE et CHDIR) le dossier dans lequel se trouvent les fichiers utilisés par STUT ONE (.RSC .DEF etc…) puisque le GfA reste toujours dans le dossier courant… ce qui peut changer au cours du temps. Lorsque l’on lance un programme compilé (.PRG) par contre, le dossier courant est le dossier contenant le .PRG (en général) et le fond de bureau est déjà dessiné.
Après le programme principal, on trouve toutes les procédures et fonctions regroupées en trois catégories: les procédures générales, les procédures d’édition et les procédures d’exploitation. Les procédures d’édition servent pour toutes les fonctions concernant l’édition d’un serveur (création de pages vidéotex, de pages arbo, etc…) alors que les procédures d’exploitation servent pour toutes les fonctions utilisées en mode serveur proprement dit (affichage des pages, saisie de messages, détection de sonnerie, téléchargement, etc…). Les procédures générales quant à elles, servent dans tous les cas.
Cette décomposition est un héritage de l’époque ou le 520 STF était la machine la plus répandue alors qu’il fallait un mega de mémoire vive pour faire tourner STUT ONE. On pouvait alors séparer le logiciel en deux parties: un éditeur (MAKE_ONE: prog ppal + proc générales + proc d’édition) et un serveur proprement dit (USE_ONE: prog ppal + proc générales + proc d’exploitation), chacune d’entre elles pouvant alors s’accommoder de 512 Ko de RAM seulement. Sachez néanmoins qu’il vous faudra quelque peu modifier les procédures ayant pour suffixe _520_1040 dans chaque cas.
Ceci dit, même si la majorité des utilisateurs disposent aujourd’hui d’un Mega-octet de RAM et souvent plus, la séparation est restée. Elle est en effet bien pratique pour retrouver plus rapidement une procédure donnée. Par contre, à l’intérieur de chacun des trois grands groupes, les procédures sont classées selon l’anarchie la plus totale, puisqu’elles y apparaissent par ordre alphabétique! Autrement dit, soit vous savez comment s’appelle la fonction qui vous intéresse, soit vous allez mourir ailleurs! Il serait clairement profitable de réorganiser toutes ces procédures en sous-groupes fonctionnels…
Mais vous voudrez sans doute faire bien plus que çà, aussi allons nous maintenant entrer dans les détails de fonctionnement du serveur.
LE NOYAU DU SERVEUR
Ce qui nous intéresse ici, ce sont les procédures d’exploitation. C’est là que nous trouverons les fonctions spécifiques à un serveur télématique; le reste du logiciel, quant à lui, n’est que de la programmation GEM “relativement” classique, avec des fautes de style en plus! On me dit parfois que je devrais avoir plus de respect pour mon travail… En tout cas, Claude Attard à traité le sujet récemment, reprenez ses articles, si besoin est, pour vous y retrouver. (Je dois quand même signaler que STUT ONE 2 utilise très mal le GEM: fenêtre non déplaçables, etc… et il se permet même des horreurs comme de faires des PRINT TOS dans les fenêtres GEM… c’était pour que çà aille plus vite! blurg!)
Bref, lorsque vous lancez le serveur depuis le menu principal, vous appelez en fait une des procédures suivantes: local, off_line ou normal, selon le mode choisi. Ces procédures s’occupent en fait d’ouvrir la fenêtre serveur et de débuter une connexion. Si en mode local, vous démarrez immédiatement sur les chapeaux de roues, les procédures off-line et normal sont un peu plus complexes.
En effet, en mode off-line, le serveur affiche des écrans de pub (ou autres…) sur le Minitel local en attendant qu’on appuie sur Connexion/Fin pour démarrer une connexion (c’est un mode “spécial salon” pour faire des écrans qui défilent avec des messages: “Notre produit est génial et pas cher, pour en savoir plus, approchez-vous et appuyez sur Connexion/Fin!”).
Finalement, en mode normal, le serveur attend de détecter une sonnerie et que la connexion soit établie pour commencer. (La détection de sonnerie se fait soit par réception de codes spéciaux provenant d’un Minitel 2 ou 12 ou bien par détection d’un appui sur le bouton FEU du joystick, si vous avez connecté un détecteur de sonnerie en lieu et place du joystick!)
Une fois la connexion établie, chacune des procédures ci-dessus appelle la procédure serveur. Vous y trouverez tout d’abord un certain nombre d’initialisations devant être effectuées au début de chaque nouvelle connexion. Puis, on entre dans la boucle principale du serveur… C’est le moment de sortir le grand jeu!
Le principe même de STUT ONE (révolutionnaire à l’époque! sisi!) est de tourner dans une boucle infinie. A chaque tour de boucle on traite la “page arbo” courante: on la décode, on affiche les pages vidéotex correspondantes, on effectue des saisies au clavier, on fait divers traitement et finalement on définit la prochaine page arbo sur laquelle il faut se rendre. A ce moment là, on boucle et on recommence tout çà. Grosso modo, on ne sort de cette boucle principale que le lorsque le connecté à appuyé sur “Connexion/Fin”. Enfin çà, c’est la théorie; en pratique, on sort également suite à une erreur dans l’arbo, un ordre du sysop, etc…
La page arbo courante est identifiée par son nom (8 lettres) dans la variable page_a$. Une fois que cette page a été trouvée dans le tableau contenant toutes les pages arbo, on va généralement vouloir afficher une page vidéotex. Cette page vidéotex est indiquée dans le parametre$(0) de la page arbo en cours.
Mais le traitement commun s’arrête là. Ensuite, chaque page arbo peut avoir une fonction différente. Ainsi, certaines pages auront pour fonction de présenter un menu à l’utilisateur, d’autres saisiront un message, d’autres afficheront la liste des messages en BAL, d’autres permettront de télécharger un fichier, etc… Pour traiter ainsi les actions spécifiques à chaque page, la boucle principale contient un SELECT/CASE qui va aiguiller le traitement vers une procédure dédiée à une fonction arbo donnée. La fonction de la page arbo courante est codée sous forme de numéro dans la variable fnct|. Vous constaterez que certains codes ne sont plus attribués. En effet, certaines fonctions arbo sont devenues obsolètes au fil des versions successives de STUT ONE.
UN EXEMPLE DE TRAITEMENT
Prenons par exemple une page arbo de fonction MENU (Fonction n°7). Elle est traitée par la procédure menu. Malgré les quelques commentaires très hermétiques (pour tout vous avouer, à une époque, j’ai du limiter au strict minimum les commentaires par manque de mémoire vive!)… malgré l’herméticité des commentaires donc, vous devriez réussir à distinguer quatre phases dans la gestion de la page menu. Ce sera sensiblement le même schéma pour les autres fonctions arbo.
Dans un premier temps, on extrait des paramètres de la page arbo, certaines données importantes telles que la position du champ de saisie sur la page. Toutes ces données sont disponibles dans un tableau de chaînes de caractères appelé parametre$(). Ce tableau est rempli lors du décodage de la page par la procédure serveur. Quant à l’ordre des paramètres dans le tableau, il n’est pas aléatoire mais presque! Il dépend en fait plus ou moins de l’ordre des champs de saisie dans les formulaires de saisie. Voyez pour cela les procédures d’édition…
Vous pourrez constater également que les noms de variables sont parfois on ne peut plus explicites, puisque du type g3, m8 ou encore l2. Ces lettres signifient en fait portée Globale, portée Moyenne et portée Locale. C’était une astuce pour économiser de la mémoire, puisque chaque variable de ce type pouvait être utilisée plusieurs fois pour des usages différents en divers endroits du programme. Bien sûr, c’est une source de bugs difficilement égalable! La méthode propre aurait été d’utiliser des variables locales (instruction LOCAL) mais il s’est trouvé que l’utilisation de LOCAL produisait des bugs inadmissibles lors de la compilation avec les premières versions du GfA 3.00, 3.01 etc… Quand je vous disais que j’ai fini par succomber aux caprices du GfA… Mais maintenant que GfA sait correctement compiler avec des variables LOCAL, je vous conseille vivement de n’utiliser plus que des variables ainsi déclarées avec LOCAL.
Après les initialisations spécifiques à la page arbo, on trouve une boucle contenant trois étapes: l’affichage de la (ou des) page(s) vidéotex, la saisie d’une commande ou d’un mot clef puis le traitement de la saisie.
Le fait de gérer l’affichage de la page vidéotex dans la boucle peut vous sembler bizarre, mais cela est dû au système de pages interruptibles. En effet, si vous commencez à taper une commande au clavier pendant l’affichage de la page vidéotex, celle-ci va s’interrompre et le champ de saisie va s’afficher immédiatement. Si vous appuyez alors sur Annulation, la page vidéotex continue à être affichée là ou elle s’était arrêtée.
Notez que cette pratique est techniquement assez délicate. En effet, lorsque l’on reprend l’affichage de la page interrompue, on a entre-temps déplacé le curseur à l’écran, modifié la couleur d’écriture courante, etc… Reprendre l’affichage là où on s’était arrêté serait donc le meilleur moyen pour réaliser une superbe page vidéotex style Picasso à peu de frais. Pour éviter cet écart de style qui ne plairait sans doute pas à tout le monde, la procédure locate_ptr se charge de remonter en arrière dans les codes composant la page, à partir de la position courante, jusqu’à ce qu’elle trouve un endroit “sûr” pour continuer l’affichage. Un endroit “sûr” peut être un CLS (code 12), un HOME (code 30) ou un LOCATE (codes 31 yy xx).
La saisie d’une commande ou d’un mot clef est ensuite assurée par une procédure générique: get_command. Cette procédure est appelée par la grande majorité des fonctions arbo. Nous l’étudierons un peu plus en détails la prochaine fois.
get_command nous rend la main lorsqu’une touche de fonction (Sommaire, Suite, Retour, Guide, Envoi, etc…) a été pressée. Il est possible de passer en paramètres à get_command, les noms des pages arbo auxquelles il faut se rendre lors de l’appui à ces touches. Ceci explique la présence de la ligne:
EXIT IF LEN(page_a$)
En effet, si la variable page_a$ a été remplie par get_command, c’est qu’il faut quitter la page courante (donc la boucle) pour aller à une autre.
La procédure menu traite ensuite les cas plus délicats, par exemple, en ce qui concerne la touche Sommaire, on se rendra à une page arbo différente selon que l’appui était précédé de * ou non. (Notez que * est un exemple, le caractère “spécial” est configurable dans parametre$(2)).
Si aucune condition n’a mené à remplir la variable page_a$, c’est qu’on ne doit pas quitter la page courante; on affiche alors éventuellement un message “touche sans effet” et on boucle…
LOOP UNTIL LEN(page_a$)
ENCORE UN MOT
Voilà, après avoir fait le tour du propriétaire, vous devriez commencer à avoir une certaine idée de la manière dont fonctionne STUT ONE. Vous devriez même deviner comment fonctionnent les autres logiciels serveur d’après la manière dont on les utilise.
Conceptuellement, STUT ONE 2.6 est probablement assez bien architecturé (Si vous pensez le contraire, écrivez-moi!). Par contre, la méthode utilisée ne permet pas le multitâche/multivoies. Nous en reparlerons… Mais sans aller jusque là, vous avez déjà dû constater que dans la pratique, ce logiciel peut être grandement amélioré, ne serait-ce qu’en éliminant les “astuces” destinées à économiser la mémoire vive… si vous en avez assez!
J’attends donc vos réactions et je vous donnerais plus d’explications la prochaine fois. En attendant, vous pourrez probablement rencontrer d’autres personnes intéressées par le développement de STUT ONE version 2.6X sur le serveur dédié: (1) 00.00.29.45 code STUT.
Finalement, avant de nous quitter, il convient de dire un mot sur la licence d’utilisation du logiciel et de son code source.
LICENCE
STUT ONE 2.6X et son code source sont placé sous la “GNU General Public License”. Cette licence garantit la plus grande liberté d’utilisation du logiciel à tous. Elle vous permet de l’utiliser, de le modifier et de le diffuser librement. MAIS ATTENTION: dans tous les cas, vous devez indiquer le logiciel original et les modifications que vous y avez apportées et VOUS DEVEZ FOURNIR LE CODE SOURCE de toute version du logiciel que vous diffusez, à qui vous le demande.
Cette licence, encore appelée GPL pour les intimes a été élaborée par la Free Software Foundation dans le but d’offrir la plus large diffusion possible aux logiciels placés sous cette licence. C’est notamment le cas de tous les outils GNU, y compris Emacs ou les compilateurs gcc et g++ également disponibles sur ATARI.
Vous trouverez sur Internet un certain nombre de logiciels placés sous la GPL, ce qui est toujours très intéressant dans la mesure ou vous avez accès au code source. Notez bien qu’un logiciel sous GPL n’est ni un domaine public, ni un freeware, ni un shareware. Le texte complet de la licence est fourni dans le fichier LICENSE.TXT.