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

Post complet »

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.

Simulation d'écran Minitel
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.

Post complet »