Catégorie: "Atari ST"

STUT ONE 3 - Le code source

[NDA: Article écrit en Juin 1996, publié dans ST Magazine n° ? en ?]

STUT ONE est un logiciel vous permettant de réaliser un serveur Minitel avec un simple ATARI STF connecté à un Minitel. Nous vous avons parlé de ce logiciel à plusieurs reprises dans ST Magazine, et en particulier dans les numéros 72 et 105 où nous vous avions fourni, respectivement, les versions 2.6 et 3.0 du logiciel. Nous arrivons aujourd'hui au terme de cette longue aventure en levant le voile sur le code source de la version 3. Vous le trouverez sur la disquette accompagnant le magazine.

DEBALLAGE

En décompactant le fichier STUT_SRC.ZIP se trouvant sur la disquette [attaché à cette page web] vous obtiendrez une collection de modules C (*.C) avec leurs headers (*.H) ainsi que quelques fichiers ressource (.RSC) et le fichier liant tout ceci en un seul et même projet: STUT_3.PRJ.

Tout ceci totalise 1,5 Mega-octets de code source! C'est un chiffre relativement important, surtout si on le compare aux 500 Kilo-octets de code source de la version 2.6... Toujours est-il: prévoyez quelques 5 ou 6 Mega-octets de place libre sur votre disque dur si vous voulez pouvoir décompacter puis recompiler le logiciel...

RESSOURCES NECESSAIRES

Alors justement: de quoi avez vous besoin pour recompiler le logiciel? D'un disque dur avec de la place libre, bien sûr, mais aussi d'un compilateur C. Sachez que STUT ONE 3 a été développé avec Pure C version 1.1 (du 20 Mars 1993). L'utilisation de ce même compilateur pour recompiler le logiciel sera bien évidemment préférable à toute autre solution.

Ceci dit, si vous avez un minimum d'expérience avec le portage d'applications en langage C d'une plate-forme à une autre, ou encore d'un compilateur C à un autre, vous pourrez vous en sortir avec tout compilateur C/ATARI digne de ce nom, moyennant quelques retouches mineures du code source, de manière à l'adapter aux bibliothèques (*.LIB) fournies avec votre compilateur.

STUT ONE 3 étant une application d'assez grande taille (comparativement aux applications ATARI courantes), une machine équipée de 4 Mo de RAM est préférable pour le développement et la compilation. L'exploitation peut se faire sur une machine de 1 Mo de RAM si l'on s'en tient à un serveur Minitel d'envergure limitée.

Concernant la taille de l'écran, le minimum confortable est le monochrome 640 * 400 pixels. STUT ONE 3 peut néanmoins supporter une utilisation en mode "moyenne résolution ST", c'est à dire 640 * 200 pixels. Vous découvrirez que des fichiers de ressources spécifiques à ce mode sont inclus dans la distribution de code source. En tout état de cause, si vous avez la possibilité de faire fonctionner le logiciel en mode VGA (640*400, 16 couleurs), ne vous privez surtout pas!

Au niveau disque dur, si quelques Mega-octets sont indispensables à la compilation, il est envisageable de faire tourner un petit serveur sur une machine équipée uniquement de lecteurs de disquettes.

Finalement, STUT ONE 3 est un logiciel serveur Minitel, son utilisation nécessite donc l'emploi d'un ou de plusieurs Minitels. Vous avez besoin d'un Minitel pour vérifier votre travail et pour vous connecter à distance. Mais vous avez également besoin d'un ou de plusieurs Minitels (selon le nombre d'appels simultanés que votre serveur aura à traiter) pour recevoir les appels entrants. Le nombre de Minitels que vous pouvez brancher dépend du nombre de ports série dont dispose votre ordinateur. Néanmoins, maintenant que vous disposez du code source, vous pouvez envisager d'interfacer STUT ONE avec le port MIDI ou encore une carte multi-séries. L'utilisation de modems à la place des Minitels est également envisageable.

COMPILATION

La compilation du logiciel sous Pure C exige que vous chargiez le fichier projet (STUT_3.PRJ) d'une part, et que vous fixiez précisément certaines options de compilation d'autre part.

Mais avant même de parler des options de compilation, parlons d'un petit détail qui a son importance: les tabulations. En effet, comme tout programme écrit dans les règles de l'art les plus évidentes, le code source de STUT ONE fait un fort usage d'indentations et d'alignements dans les tableaux ou les listes d'arguments. Ceux-ci sont souvent obtenus au moyens de tabulations. Ce que vous devez savoir c'est que la taille de ces tabulations est censée être de 3 caractères. Si vous ne visualisez pas le source en ayant fixé la taille des tabulations à 3, vous risquez de vous retrouver avec un code source ressemblant plus à une salade de mots-clef qu'à un programme structuré. Dans Pure C, la taille des tabulations se règle dans le menu Options/Shell:tabsize.

Au niveau de la compilation (menu Options/Compiler) maintenant, deux options doivent absolument être cochées: "Default char is unsigned" (-K) et "Use absolute calls" (-P).

Au niveau de l'édition des liens (menu Options/Linker), il n'y a pas d'indications particulières, si ce n'est de réserver au moins 4096 octets à la pile (Stack).

Une fois ces quelques options correctement paramétrées, vous pouvez tout simplement lancer un "make" pour compiler et linker tous les modules. Ce processus peut être assez long. A titre d'exemple, sur mon Mega STE à 16 Mhz avec 4 Mo de RAM, il a fallu 9 minutes 30 pour tout compiler. C'est en partie pour cette raison que le logiciel est découpé en de multiples modules de petite taille. En effet, par la suite, si vous modifiez un module, un "make" ne recompilera que le module en question et le "linkera" avec les autres modules déjà compilés (sous forme de fichier *.O) auparavant.

La fichier compilé aura une taille approximative de 170 Ko... si vous n'avez pas inclus d'informations de debug ni de table des symboles, etc. L'inclusion de toutes ces options vous sera néanmoins fort utile si vous décidez de modifier le code source et que vous avez besoin de le debugguer au moyen d'un debugger (tel que Pure Debug par exemple).

UN MOT SUR LA LICENCE

Tout comme la version 2, STUT ONE 3 est soumis aux termes de la GNU General Public License (GPL version 2). Cela implique que vous êtes libre d'utiliser le logiciel, de le modifier et même de le revendre, tout ceci à la condition expresse que vous diffusiez également le code source intégral correspondant à toute version compilée que vous diffuseriez par quelque moyen que ce soit.

Contrairement aux licences d'utilisation classiques des logiciels, la GPL est une licence destinée à protéger les utilisateurs, plutôt que les vendeurs de logiciels. Le texte complet de la licence est fourni dans le fichier LICENCE.TXT.

LE CODE SOURCE

Comme nous l'avons déjà évoqué plus haut, le code source est décomposé en une multitude de modules plus ou moins importants. Chacun de ces modules remplit (en théorie) un ensemble de fonctions corrélées. Les modules les plus soignés ressemblent même à des objets et sont plus ou moins inspirés de la terminologie objet du C++. Prenons un exemple...

Au hasard: SERIAL.C. Si vous ouvrez ce fichier, vous devriez comprendre très vite qu'il s'agit d'une sorte de "classe" permettant de gérer les ports série de l'ordinateur (c'est écrit dans les commentaires au début du fichier :-).

Ce fichier contient par exemple la définition de la "méthode" (une fonction C) Serial_WaitTXEmpty( n_device ), dont la fonction est d'attendre que le buffer de transmission (TX par opposition à réception/RX) du port n_device soit vide. Cette méthode pourra par exemple être appelée depuis un autre module qui désirerait s'assurer que toutes les informations ont bien été envoyées avant de faire autre chose.

Cette méthode est publique, c'est à dire, qu'elle peut être appelée depuis un autre module. Néanmoins, afin que l'autre module puisse appeler la méthode, il faut lui déclarer. C'est à cet effet que l'interface publique du module SERIAL.C a été regroupée dans le fichier SRIAL_PU.H. Tout module désirant faire appel à une méthode publique du module SERIAL.C peut dès lors le faire en ayant simplement inclus le fichier de déclarations de la manière suivante:

#include "SRIAL_PU.H"

SERIAL.C contient également des méthodes privées, à usage exclusivement interne. C'est le cas par exemple de get_iorec() qui permet à des fonctions de gestion des ports séries d'accomplir leur tâche en obtenant des informations du système d'exploitation. Cette "fonction privée" est déclarée "static" de manière à ne pouvoir être référencée qu'à l'intérieur du module SERIAL.C et sa déclaration ne figure bien sûr pas dans l'interface publique (SRIAL_PU.H).

Voilà pour le principe d'organisation générale. La liste complète des modules se trouve dans STUT_3.PRJ avec une brève description. Vous pouvez obtenir plus d'informations en ouvrant chacun des modules séparément. Vous constaterez en effet que ceux-ci sont en général abondamment commentés.

L'AVENIR ?

Voilà, vous avez entre les mains le fruit de plusieurs années de travail et de recherche en matière de télématique conviviale (vous trouvez que j'exagère? :-) et vous avez le champ libre quant aux possibilités d'évolution: gestion de modems, transformation en serveur BBS, en serveur vocal ou même en logiciel de création multimédia! (Si on y réfléchit, le moteur d'arborescence à la base du logiciel peut être appliqué à un grand nombre de tâches diverses...)

Quant à moi, je vais aller m'occuper d'une autre vision de la télématique que l'on nomme l'Internet...

François PLANQUE
Ingénieur système chez Planete.net

Juin 1996

NDA: Le code source de STUT ONE 3 fait appel aux routines de débogage des mallocs expliquées dans un autre article.

Programmer un serveur Minitel (2): Dompter le Minitel!

[NDA: Article écrit en Setembre 1995, publié dans ST Magazine n° 100 en Décembre 1995.]

Le mois dernier, je vous présentais le code source du logiciel serveur Minitel STUT ONE 2.6X et son fonctionnement général. Ce mois ci, mous allons nous intéresser aux traitements spécifiques nécessaires pour communiquer avec un Minitel. Vous allez découvrir que malgré sa petite taille, il ne se laisse pas dompter si facilement... Le Minitel est il asocial? C'est la question que nous allons élucider ici, en tentant de communiquer avec lui...

Inutile de vous dire que, pour nos explications, nous allons très fortement nous baser sur le code source de STUT ONE fourni sur la disquette du mois dernier. Si vous avez été assez fou pour ne pas vous procurer le numéro précédent de l'unique magazine au monde qui n'a pas peur d'expliquer comment fonctionnent les composantes indispensables de notre monde (un serveur Minitel par exemple!), sachez qu'il n'est peu être pas trop tard et qu'avec un peu de chance, il en reste un exemplaire à la boutique Pressimage...

LES OREILLES DU MINITEL

Posez donc votre Minitel sur une table et regardez le en face. Regardez le bien. Est-ce que vous voyez des oreilles? Oui? Alors je vous conseille d'arrêter de manger des champignons... Non? Rassurez vous c'est normal! Simplement parce que les oreilles du Minitel sont sur sa face arrière!

Vous avez maintenant le choix entre retourner votre Minitel ou bien contourner votre table. Toujours est-il que sur la face arrière, vous verrez une prise DIN, ronde avec 5 canaux auditifs (5 trous quoi). C'est dans cette oreille là qu'il faut causer pour que votre Minitel vous écoute. C'est surtout, par là que le serveur va causer pour dominer le Minitel, tel un maître son esclave.

L'autre oreille du Minitel, elle se situe au bout d'un tentacule (un cordon quoi) qui part de la face arrière et se loge dans la première prise téléphonique qu'elle trouve. C'est par là que le Minitel écoute ce que veulent les connectés du serveur. Ce qu'il entend par là, il devra le rapporter à son maître: l'ordinateur serveur...

Mais comment fait-il, justement, pour parler au maître. Eh bien, en fait, les oreilles du Minitel sont aussi des bouches et il peut donc parler avec ses oreilles! C'est vraiment incroyable l'anatomie de ces bêtes là!

Le mode de fonctionnement de ces organes est néanmoins assez simple à la base: quand le serveur envoie quelque chose dans une oreille, le Minitel l'envoie au connecté par l'autre. Et quand le connecté fait une requête dans l'autre oreille, le Minitel la transmet au serveur par la première...

Vous connaissez cette moquerie: "çà rentre par une oreille et çà ressort par l'autre". Oui? Eh bien, elle est tout à fait adaptée au fonctionnement du Minitel. En gros, le Minitel est donc une boîte sans cervelle, tout à fait stupide et qui ne sait s'affranchir que d'un éventail de tâches très limité. Ceci implique que nous allons constamment devoir être derrière lui...

MAIS A QUOI SERT-IL?

En temps normal, quand vous utilisez le Minitel en tant qu'interprète, pour vous connecter au 11 par exemple (commercialement parlant, je devrais dire: quand vous vous connectez au 3615 STMAG)... quand vous vous connectez au 11 donc, c'est un peu différent, puisque les informations à afficher arrivent par l'autre oreille - celle qui est dans la prise téléphonique. Les commandes que vous tapez repartent également par cette 'oreille'...

Résumons nous: les deux oreilles fonctionnent à peu près de la même manière. Quand vous parlez dans l'une, çà ressort par l'autre, et en plus çà s'affiche sur l'écran. Et quand vous parlez dans l'autre, çà ressort par la première et çà s'affiche aussi sur l'écran. Et encore plus subtil: quand vous tapez sur le clavier, çà lui sort par les deux oreilles en même temps, au Mintel!

Vous avez probablement un doute là... En effet, pourquoi deux oreilles au fonctionnement identique ont elles une apparence physique si différente? Il y a en effet une petite différence, elle se situe au niveau des signaux: l'oreille-fiche-téléphonique parle une langue "analogique" alors que l'oreille-prise-DIN-5-broches parle une langue "digitale". Quant au clavier et à l'écran, ils parlent une langue "humaine".

Le métier du Minitel est donc un métier d'interprète (même si vous ne l'aviez jamais remarqué jusque là). Le Minitel effectue instantanément la traduction entre trois langue: le "digital", la langue des ordinateurs, "l'analogique", la langue du réseau téléphonique, et "l'humain", la langue des utilisateurs.

Cet interprète, vous le payez 20 Francs/mois, ce qui est peu cher payé, voire complètement immoral. Néanmoins, comme il ne bronche pas, on ne va pas se priver et on va le faire travailler à plein régime.

Bien sûr, cette explication est un peu simpliste, et je vais vous la résumer, façon techno-maniac pour être sûr que tout le monde comprend bien: Le Minitel n'est autre qu'un terminal asynchrone interconnectant de manière complète un écran 40*25 8 niveaux de gris, un clavier AZERTY étendu, un modem V23 et un codec TTL. C'est clair? Bon, alors continuons...

AFFICHE!

La légende veut que les sysops de serveurs RTC, et à fortiori les auteurs de logiciels serveurs comme vous et moi, soient assoiffés de pouvoir. Ce pouvoir, ils, enfin nous, l'avons tout d'abord exercé sur notre chien, maintenant sur notre Minitel et le mois prochain, nous tenterons de l'exercer sur nos connectés. Ensuite nous serons probablement maîtres du monde. Mais d'ici là, nous avons du boulot! Je ne vais pas ici vous expliquer comment faire asseoir ou coucher votre Minitel, néanmoins, je vais tenter de vous montrer comment le faire afficher... Faciiiiile.

Première solution: vous allumez votre Minitel et vous écrivez en langage humain sur le clavier. Le Minitel va afficher en langage humain sur l'écran. C'est simple, rapide et efficace, sauf que vous allez vite en avoir marre de taper au clavier et de recommencer pour chaque nouveau connecté.

Deuxième solution: vous appelez le 11 et là bas un gentil ordinateur se charge de parler dans l'oreille téléphonique de votre Minitel pour le faire afficher. L'inconvénient c'est qu'il n'affiche pas vraiment ce que vous voulez!

Troisième solution: vous lui parlez dans son oreille-prise-DIN, mais cette oreille ne comprend que le "digital". Le grand bonheur, c'est que vous avez dans les parages un ordinateur de type ATARI ST (Avouez, nous savons tout!) parfaitement à même de parler le 'digital' avec votre Minitel. Un câble entre la prise DIN et la prise série de votre ATARI et ils sont prêts à se parler.

Votre ordinateur dispose également de la capacité fort intéressante de pouvoir être programmé. Vous pouvez donc lui faire mémoriser un série d'actions qu'il refera autant de fois que vous le désirez. Dans le cas qui nous intéresse, nous voulons qu'il mémorise des "phrases" et qu'il les répète dans l'oreille du Minitel lorsque bon nous semble.

En GfA Basic, il y a plusieurs manières de parler au Minitel en utilisant la prise série. La première s'applique très rapidement comme ceci:

OUT 1,65,66,67

Cette instruction affiche ABC sur l'écran de votre Minitel. Le 1 correspond au port série. Si vous avez plusieurs ports série, le 1 correspond au port série par défaut réglé dans le panneau de contrôle. Nous n'avons pas à chercher plus loin ici, puisque STUT ONE 2 ne gère qu'un seul port série. Les nombres 65, 66 et 67 quant à eux correspondent aux codes ASCII des lettres A, B et C.

La deuxième méthode est un peu plus civilisée:

OPEN "",#99,"AUX:"
PRINT #99,"ABC";
CLOSE #99

Il faut ici commencer par ouvrir un canal vers le port série (AUX:). Ici nous attribuons arbitrairement le n° 99 à ce canal. Ensuite nous pouvons faire des prints vers le port série, et c'est, ma foi, bien agréable. A la fin du programme, nous n'oublions pas de refermer la porte derrière nous...

La deuxième méthode, plus civilisée, semble avoir tous les avantages. Eh oui, on pourrait par exemple stocker une grande chaîne de caractères dans la variable page$ et l'afficher en un tournemain avec:

PRINT #99;page$;

Malheureusement ce n'est pas si simple, en effet, le Minitel se laisse piloter par un certain nombre de codes de contrôles assez barbares. Dans ce cas, on aura par exemple le choix entre:

OUT 1,27,66

et

PRINT #99;chr$(27);chr$(66);

pour passer en encre verte.

Déjà, la première solution semble plus courte. Autre exemple:

PRINT #99;"çà c'est génial";

produira quelque chose de bizarre. En effet, le Mintel et l'ATARI ne sont pas d'accord sur la représentation des caractères accentués. Pour afficher une telle phrase, il faut donc l'analyser caractère par caractère et envoyer des codes spéciaux à chaque fois que l'on rencontre un caractère accentué. C'est ce que fait la procédure affiche_msg() par exemple. La conversion d'un caractère accentué en une chaîne de caractères équivalente pour le Minitel se fait en appelant la procédure code_accent().

STUT ONE mélange donc allègrement la méthode OUT1,x et la méthode PRINT #99;x$; pour afficher sur le minitel, selon ce qui est le plus pratique à un instant donné.

VITESSE, PARITE ET LES AUTRES...

Envoyer des caractères vers le port série, d'une manière ou d'une autre, est une bonne chose. Mais en pratique cela pose quelques petits problèmes de compréhension entre la machine qui émet et celle qui est censée recevoir. Nous évoquions plus haut que le port série de l'ordinateur et la prise DIN 5 broches parlaient la même langue: le 'digital'. Soit, mais cette langue se décompose en plusieurs 'dialectes'! Il y a des paramètres tels que le débit, le nombre de bits par caractère, la parité et le contrôle de flux sur lesquels ils doivent se mettre d'accord.

Le Minitel impose des échanges à 7 bits par caractère et une parité paire. Quant à la vitesse (le débit), il y a plusieurs possibilités. D'un côté, sur la prise téléphonique, le Minitel (hormis les modèles les plus récents que seuls les employés de France Télécom peuvent s'offrir) ne peut communiquer qu'à 1200 bps. Que signifie bps? Cela signifie 'bits par secondes'. Dans ce cas précis on peut aussi parler de 1200 bauds, mais évitez, çà vous évitera de dire des âneries par la suite.

Concrètement, à quoi correspond cette vitesse? Nous avons vu que le Minitel utilisait 7 bits par caractère. Il y a également un bit de parité (paire). S'ajoute à cela, un bit de début de caractère et un bit de fin de caractère. Sans eux, deux Minitels (ou modems) communiquant entre eux ne sauraient pas où commencent les caractères. Ca nous fait donc 10 bits par caractère. Si on divise alors 1200 par 10 on se rend compte que le Minitel transmet (ou reçoit, selon les cas) 120 caractères par seconde. Sachant que son écran de 40 colonnes et 25 lignes fait 1000 caractères, un écran complet peut donc théoriquement s'afficher en 8,3 secondes, ce qui est déjà assez long...

Mais ce chiffre correspond à une suite de caractères blancs sur fond noir, sans jamais changer de couleur, sans clignotement, sans soulignement, sans animations, sans caractères semi-graphiques, etc... En effet à chaque fois que l'on veut introduire l'un des effets ci-dessus, il faut introduire dans le flux de caractères affichables, des caractères de contrôle permettant de changer de couleur, de passer en inverse vidéo, etc... Ces caractères de contrôles viennent rarement seuls, c'est souvent une séquence de 2, 3 ou 4 caractères d'un coup. Pour distinguer ces séquences de caractères du texte, elles commencent généralement par le caractère 'escape' de code ASCII 27 ($1B en héxadécimal). Vous le retrouverez dans l'exemple plus haut permettant de passer en entre verte.

C'est ainsi que le Minitel est devenu célèbre pour sa légendaire vitesse de transmission. La seule solution pour que çà aille un tout petit peu plus vite est d'afficher des pages un peu plus dépouillées...

Imaginez maintenant que vous êtes en train de créer une page vidéotex (un écran Minitel). Si a chaque modification, vous devez attendre 10 secondes pour voir le résultat, vous allez vite devenir fou. C'est pour cela que sur la prise DIN (qui s'appelle en fait prise péri-informatique), le Minitel 1B peut communiquer jusqu'à 4800 bps et le Minitel 2, jusqu'à 9600 bps. Et celui qui me parle de bauds sur la prise péri-informatique sera banni à jamais!

Au début, on se dit donc la chose suivante: on va communiquer à 9600 bps entre l'ordinateur et le Minitel, et puis derrière, sur la ligne téléphonique, ma foi, on ne communiquera qu'à 1200 bps, puisqu'on ne peut pas aller plus vite. Oui, c'est très intéressant çà! Comme çà, quand on fait des tests en local, çà va vite, et puis quand un type est connecté sur notre serveur, eh bien çà va aussi vite que çà peut!

Mais ce n'est pas si simple. Dans le cas précis où un type est connecté à 1200 bps et que l'ordinateur envoie une page vers le Minitel à 9600 bps, le Minitel reçoit, en une seconde, 8 fois plus d'informations qu'il ne peut en transmettre dans le même intervalle de temps. Ces données doivent êtres mises en mémoire par le Minitel, pour les envoyer un peu plus tard. Mais l'ordinateur continue d'envoyer, et le Minitel doit mettre de plus en plus de données en Mémoire. Cette mémoire, qu'on appelle une mémoire tampon (buffer en anglais) est limité. Dans le cas du Minitel, elle fait 256 octets, c'est à dire que c'est comme s'il n'y en avait pas. En envoyant à 9600 bps, vous la remplissez en un peu plus d'un quart de seconde! Et en moins d'une demi seconde, vous aurez envoyé plus de données que le Minitel n'a pu en stocker ou envoyer. Ces données en trop disparaîtront littéralement dans le néant (il y a un trou noir dans tous les Minitel, sisi, croyez moi!).

La seule solution pour éviter ces fâcheux problèmes, est de repasser la liaison ordinateur-Minitel à 1200 bps lorsqu'on travaille en mode connecté. Si vous arrivez à comprendre çà, vous êtes sur la bonne voie. Les éminents programmeurs d'une éminente société d'édition du nom de Log Access n'ont jamais saisi... [NDA: Private joke... sorry!]

CHANGER DE VITESSE

Bon, accrochez-vous, on va faire une comparaison vraiment tirée par les cheveux! Quand vous conduisez une voiture, si vous voulez changer de vitesse, vous devez d'abord débrayer et ensuite vous pouvez manipuler le levier de vitesse. Si vous ne débrayez pas avant de changer de vitesse, vous n'arriverez pas au résultat escompté. Vous aurez même des effets secondaires indésirables...

Eh bien pour changer la vitesse de la liaison ordinateur-Minitel, c'est pareil. L'ATARI dispose d'un appel système: XBIOS(15) pour changer la vitesse du port série. La procédure init_rs_520_1040 utilise cet appel système. Mais cet appel système, c'est comme le levier de vitesse: il faut 'débrayer' avant de l'utiliser!

En effet, imaginez que l'ordinateur communique avec le Minitel à 1200 bps et que tout à coup vous changez la vitesse de l'ordinateur à 9600 bps. La vitesse du Minitel, elle, reste à 1200 bps. Et les deux appareils ne peuvent plus communiquer jusqu'à ce que vous les mettiez à nouveau sur la même vitesse.

Pour changer la vitesse de la prise péri-informatique du Minitel, on peut utiliser la combinaison de touches Fnct+P puis 9 sur le clavier du Minitel (9 comme 9600, 4 comme 4800, 1 comme 1200 ou 3 comme 300 bps). Néanmoins ce sera vite lassant si vous devez répéter cette gymnastique avec vos doigts à chaque fois. Les ingénieurs de France Télécom y ont pensé et ont prévu une séquence de codes (vous savez celles qui commencent par Escape) que l'on peut envoyer par la prise péri-info, ce qui changera sa vitesse. Seulement voilà, si vous avez changé la vitesse de l'ordinateur, tout ce qu'il pourra bien envoyer à la prise péri-info sera incompris. Il faut donc demander au Minitel de changer de vitesse AVANT de changer la vitesse de l'ordinateur! Vu?

De plus, il ne faut pas changer la vitesse de l'ordinateur avant d'être sûr que les codes de changement de vitesse soient bien arrivés au Minitel. Il faut donc marquer une petite pose. Mais, bien sûr, entre le moment où le Minitel à changé de vitesse et celui ou l'ordinateur l'a fait aussi, il y a un laps de temps pendant lequel toute communication est impossible. Si le Minitel avait quelque chose d'important à dire à ce moment là, par exemple "j'ai détecté un appel entrant", l'ordinateur ne l'entendra pas.. et comme le Minitel ne le répétera pas... on distingue dores et déjà un deuxième trou noir! Les aléas de la technique... mmmh...

Permettez moi de faire une parenthèse et de vous dire comment les américains on traité le problème. Vous savez déjà que chez eux, les voitures sont automatiques et qu'on n'y débraye pas avant de changer de vitesse. Eh bien, quand ils ont inventé le modem à plusieurs vitesses, ils ont continué dans cette voie. Prenez un modem compatible Hayes, branchez-le, réglez la vitesse de l'ordinateur à n'importe quelle vitesse, envoyez une commande AT quelconque, et hop, le modem à adopté la vitesse. Changez la vitesse de l'ordinateur, renvoyez une commande Hayes, hop le modem s'est adapté... "Trop puissant le protocole Hayes!" serait-on tenté de dire. M'enfin, revenons en au Minitel...

Le corollaire du problème, c'est que quand STUT ONE démarre, il n'a aucune idée de la vitesse actuelle du Minitel, et pourtant il doit s'aligner sur cette vitesse pour commencer à communiquer avec lui! Il a trois chances sur quatre de se planter. Voici donc la méthode utilisée pour obtenir un taux de réussite de 100%. STUT ONE passe la prise série de l'ATARI successivement aux vitesses de 9600 bps, 1200 bps et 300 bps. A chaque fois, on demande au Minitel de passer à 4800 bps. Soit le Minitel reconnaît la requête lors d'un des trois essais, soit il était déjà à 4800 bps. Ensuite on passe l'ordinateur à 4800 bps et là on est sûr d'être à la même vitesse que le Minitel. On peut maintenant continuer sur de bonnes bases.

LES BASES, PARLONS-EN DES BASES!

Maintenant que vous savez à peu près tout ce qui est nécessaire pour envoyer des caractères, commandes et autres séquences de codes au Minitel, il ne vous reste plus qu'à connaître la syntaxe desdites commandes.

Je vous ai dévoilé au début, comment passer en encre verte. Je suis conscient que ce n'est pas très palpitant, mais vous pourrez trouver pratiquement toutes les séquences de commande du Minitel rien qu'en fouinant dans le code source de STUT ONE. La procédure code_vdt() est particulièrement adaptée pour commencer vos recherches. En effet, c'est elle qui s'occupe de traduire les pages vidéotex composées en langage SOVI.

Maintenant, si vous voulez de la documentation officielle, sachez qu'elle existe. Ca s'appelle "Spécifications Techniques d'Utilisation du Minitel 1B" (STUM1B pour les intimes) et çà se commande au CNET (renseignements dans les agences France Télécom). Existe aussi en version STUM2, additif au STUM1B et décrivant les nouvelles fonctions du Minitel 2. On espère le STUM4 pour bientôt... Remarquez, on est pas encore sûr du nom, ce sera peut-être aussi STUM-TVR (Télétel Vitesse Rapide) STUM-Photo ou même STUM'95 (Si ils s'inspirent de Microsoft...)

Bon allez, je vous laisse tenter de dompter votre Minitel. Bon courage!

Débugguer les mallocs!

[NDA: Article écrit en Juillet 1995 et publié dans ST Magazine n° 99 en Novembre 1995. Il est intéressant de constater qu'il existe depuis des produits commerciaux d'aide à la gestion de la mémoire, basés sur des concepts très similaires à ceux exposés ici!]

Sous ce titre de science-fiction, se cache en fait un petit utilitaire, qui se révélera sans aucun doute, fort pratique pour tous ceux qui utilisent la gestion dynamique de la mémoire en C.

Gestion dynamique de la mémoire?

Qu'entendons nous au juste, par "gestion dynamique de la mémoire" ? Il s'agit simplement de toutes les fonctions offertes avec le C ANSI permettant d'allouer et de réserver des zones de mémoire dynamiquement, sur le tas (heap). Concrètement, il s'agit des fonctions suivantes:

  • malloc() "Memory ALLOCation", pour réserver une zone.
  • calloc() pour réserver une zone et l'initialiser à 0.
  • realloc() pour réallouer une zone avec une taille différente.
  • free() pour libérer une zone préalablement allouée.
  • strdup() pour dupliquer une chaîne de caractères, ce qui entraîne un malloc() pour contenir la nouvelle chaîne de caractères.

Le recours à ces fonctions est en particulier nécessaire à chaque fois que vous ne pouvez pas prévoir, lors de l'écriture du programme, la taille de la zone de mémoire dont vous aurez besoin.

De même, si vous avez besoin d'un grande quantité de mémoire, mais seulement sur une durée limitée par rapport à la durée d'exécution de votre programme, vous voudrez réserver cette mémoire au moment voulu et la libérer dès que vous n'en avez plus besoin...

Lire la suite »

Programmer un serveur Minitel (1)

[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.

Programmer un serveur Minitel (1)
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 toute façon, 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 à[FP1] 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'éxécuter 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), chacunes 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ées plusieurs fois pour des usages différents en divers endroits du programme. Bien sûr, c'est une source de bug 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 cela fonctionne, je vous conseille vivement de n'utiliser plus que des variables 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.

Les Protocoles Réseau

[NDA: Article écrit en Mars 1995, publié dans ST Magazine n° 94 en Mai 95]

Lorsque je vous invitais, il y a un an déjà, à prendre le train de l'Internet en marche, je ne m'attendais pas moi même à un développement aussi rapide en France. Le nombre de prestataires de services grand public (World-Net, FranceNet, Pressimage...) augmente tous les mois alors que les prix se font de plus en plus abordables. Les entreprises françaises sont de plus en plus connectées et tout le monde en parle: Internet est en passe de faire partie de notre vie quotidienne au même titre que le Minitel. Minitel, qui au passage, prend un sérieux coup de vieux!

LE PROTOCOLE DU FUTUR

Bien sûr, le réseau Internet n'est pas le seul. En France, un autre grand réseau est Transpac. Et puis, il y a les réseaux privés comme celui de CompuServe et ce "Marvel" [NDA: nom de code de ce qui deviendra MSN, avant que MSN ne passe à l'Internet...] que Microsoft déploie actuellement sur le monde entier. Finalement il y a les réseaux locaux des entreprises, institutions et universités.

Tous ces réseaux ont la fâcheuse tendance à ne pas être compatibles entre eux. Il est impossible de relier directement l'un d'eux à un autre et de voir ainsi, une machine reliée au premier échanger des données avec une machine sur le second. La cause en est que le format des données et le protocole utilisé pour leur transmission est différent sur chaque réseau. Ce ne sont que quelques conventions, et pourtant chaque propriétaire de réseau se réserve jalousement l'exclusivité de son protocole... Bien évidemment, ça n'arrange rien à l'interconnexion de ces réseaux.

Pour palier au problème, on utilise des "gateways" entre les différents réseau. Ces machines traduisent les données dans un sens et dans l'autre. Les performances globales sont tout simplement affligeantes et la plupart du temps, les capacités de chaque réseau sont limitées par celles de l'autre.

Pourtant il existe une exception notoire: le protocole TCP/IP. Ce protocole peut être utilisé sur un réseau local (du plus simple reliant un ordinateur à une imprimante jusqu'au réseau d'entreprise à 5000 postes ou plus) mais également sur un réseau de grande envergure. De plus, ce protocole est libre d'utilisation, très bien documenté et livré en standard avec un certain nombre de machines en particulier tous les systèmes UNIX. Que demander de plus? C'est ainsi que des dizaines de milliers d'entreprises, d'universités et d'institutions sont équipées d'un réseau local fonctionnant sous TCP/IP. Et bien sûr, le protocole étant là pour ça, les universités et les institutions, suivies des entreprises ont relié leurs réseaux locaux entre eux. Depuis, le phénomène à fait boule de neige et l'agglomération de réseaux interconnectés à donné naissance à l'Internet.

Internet tire son nom de IP. En effet IP veut dire Internet Protocol. C'est grâce à IP que n'importe quel ordinateur dans le monde peut être identifié par une adresse unique. Chaque ordinateur peut ainsi échanger des données avec précisément n'importe quel autre ordinateur qui l'intéresse, pour peu qu'il soit relié au réseau.

Lire la suite »