FTP, description technique


Il n'est pas nécessaire de définir plus ce qu'est ce "client FTP".

Par contre il est peut-être intéressant d'en fournir quelques informations quant à la façon dont il a été réalisé.

Par exemple, il a été développé en utilisant les outils de développement Borland C++.

Oui, mais pas tous. Plus en détail, pour les non connaisseurs, Borland fournit un outil de développement "Object Vision" qui en théorie permet de développer un programme C++ aisément. Microsoft aussi d'ailleurs, "Visual C++".

Ces 2 ensembles sont en théorie aptes à créer aisément (...."aisément" ???) un programme Windows!.... Oui mais!

Borland, "suiveur", est "officiellement" en collaboration avec Microsoft sur le sujet, recevant "officiellement" les informations nécessaires à créer tout ce qu'il faut pour ..... faire la concurence à ..... (?) Pas normal cela, contre nature de Bill, lisez les journaux!

Bref, voici donc ce qu'il en est!

Tout simplement, la première constatation technique immédiate pour un développeur est que le même programme, exactement le même programme, à la ligne près, prend beaucoup plus de place lorsque compilé en Borland que en Microsoft C++!!!!!

Des chiffres? En voici: le FTP dans une version intermédiaire faisait 43 Kbytes en C++ Microsoft et 83 Kbytes en Borland C++.

La question intéressante est de savoir pourquoi! Et la réponse, car nous avons analysé pourquoi, est simple: Borland ne dispose pas, contrairement à ce qui est officiellement annoncé par les 2 compères, des données nécessaires à utiliser les fonctions de base incorporées dans Windows! Simple!

Plus explicitement? Simplement, quand Microsoft veut réaliser quelque chose dans un programme, il dispose des source des logiciels Windows. Il est simple alors de faire appel à une fonction "non divulguées", (non publique! ) qui fait la chose très simplement et très efficacement, en utilisant pour cela ce qui existe, que votre ordinateur utilise en permanence mais dont Microsoft ne donne pas les points d'accès aux autres fournisseurs de logiciels. Dès lors, Borland doit implémenter dans ce qu'on appelle le "run-time", les mêmes fonctions, alors que Microsoft lui se contente d'appeler la fonction existant dans Windows. Et c'est là que les choses se passent!

Plus clairement donc, tout logiciel écrit sous Borland intègre une seconde fois ce qui existe déjà simplement parce que Microsoft ne fournit pas les informations strictement nécessaires. Et vous pouvez constater que l'on peut s'en passer, mais que cela consomme de la mémoire ..... mais aussi de la puissance de calcul, ce qui devrait aussi convenir à la "formation Wintel" ( formation = l'escadrille! )

Vous vous en foutez? .... nous aussi! Car à bien y regarder, nous avons jusqu'içi réalisé quelques beaux exercices, le FTP, "pas mal", mais il y en a d'autres aussi ou même plus petit! Pas forcément comparables d'ailleurs. Mais par contre, le "viewer", nous sommes tranquille! Il a dans sa version actuelle la plus évoluée les mêmes fonctionalités que ses "grands frères" mais sa taille !!!! Un régal pour ceux qui ont de petites machines, des 386, 486, .... même 286! Et les disques deviennent soudain trop grands!

Mais ce qui est plus surprenant (plus tracassant pour vous les utilisateurs), est que cet exercice, nous l'avons fait 3 fois en 1 an! Et que le point commun est une réduction surprenante des tailles des programmes! ( de la RAM et des disques aussi, en conséquence, avec comme compère la vitesse de calcul, donc la puissance requise )

Et tant qu'à parler d'escadrille, voiçi le tableau de chasse:

- un logiciel de décompression, le plus petit au monde ( Nous n'avons à ce jour pas trouvé plus petit que le nôtre )

Pour info puisqu'il ne vous est pas accessible à ce jour, en mode "exécutable", c-à-d que le fichier devient un "*.exe", il fait 2663 octets (précis non?) Et le second est ..... LZEXPAND, (Microsoft), un peu plus de 2800 octets. Oui mais! .... LZEXPAND ne fait pas la même chose. Lui se contente d'être un programme de décompression classique que de plus vous ne pouvez appeler que de l'intérieur d'un autre programme. Le nôtre est un "archiveur" pouvant décompresser en une seule passe plusieurs fichiers incorporé dans l'archive. De plus, le nôtre est un exécutable, automatique.... cliquer, c'est parti. Bref, dans une version équivalente à LZ..... il pesait aux environs de 2300 octets. Autant vous dire de suite que, intégré au viewer, il le grossit à peine tout en lui permettant d'utiliser des pages comprimées de 3 à 4. La raison pour laquelle nous osons affirmer que nous pouvons faire tenir plusieurs centaines de pages sur une disquette, "avec le viewer en prime". Quant à la vitesse, ....; elle va de concert. Moins de code = plus rapide!

Mais nous ne le mettons pas sur serveur actuellement car la version "figée" est un exécutable et nous pensons que nombre d'utilisateurs imaginerons que "des virus" .... d'autant que ne pouvons contrôler toute la chaîne .... c'est plausible! Cela viendra cependant, quand nous aurons mis au point la technique permettant de contrôler le fichier avant de l'exécuter. La signature électronique par exemple.

Par contre, ce décompresseur est utilisé par nous dans l'édition électronique de documents divers fournis sur disquette ou CD avec le browser intégré.

- le "browser" ..... la bête. Il comporte plusieurs centaines de milliers de lignes de code, est aussi "full object" jusque dans les plus petits détails. Et ce qui ne gâche rien, il est aussi indépendant de Windows "Micromachin" que son usage le permet. Plus précisément: comme il doit fonctionner sur Microtruc, il faut bien que parfois il demande à "machin" de visualiser quelque chose! Et croyez que si nous le pouvions nous le ferions autrement mais malheureusement .....

Mais le côté amusant est que, à force de compliquer les choses et de nous mettre des "bugs" dans les mains, Microtruc nous a incité à faire quelque chose qui soit le plus indépendant possible, question de ne pas avoir un affichage bizaroïde et erratique. Il y a des mois donc, constatant les bizarreries du "truc" (W....), nous avons décidé de compléter la portabilité et de diminuer donc la dépendance. Question par exemple de s'ouvrir encore plus aux APPLE's ou autres DOS (oui je sais, c'est Micro ... quelque chose). Le résultat est superbe: il n'est plus nécessaire d'attendre la bonne volonté de Win xx et son bon vouloir à afficher quelque chose au moment où on le désire; il suffit de lui dire où et quand ..... et qu'il se débrouille, on a autre chose à faire!

Bref, le "petit" tient dans un petit méga, programme et datas .... et dans ce méga il se permet de prendre en charge plusieurs pages HTML, gère les fichiers en mode "virtual", ....., et se contente d'un "bête" programme d'affichage pour visualiser ce qu'il faut OU il faut et si possible (merçi) QUAND il faut. Bref, le truc vous calcule une page en un éclair, quelques centièmes de seconde, l'envoie en un balayage à l'affichage et c'est le "Micro...." du coin qui mettra quelques dizièmes de seconde à l'afficher, nous on est déjà ailleurs!

La version actuelle en est à ce stade. Le temps de contrôler et finaliser et vous pourrez en disposer, en "viewer".

Donc, pour résumer, c'est un programme "objets" mais pas forcément C++. Il est écrit EN C++ mais parfois avec une technique de vieux routier du C et de l'assembleur, avec la connaissance parfaite de ce qui accélère ou réduit un programme! Ecrit aussi avec des techniques mises au point avant que les compilateurs C++ existent, en assembleur parfois.

Autant dire de suite que si vous trouvez un concurrent qui approche de la taille ..... nous on peut réduire très facilement. Par exemple, le décompresseur est ainsi passé de 41 Koctets à 2.663 octets! A l'estime, le viewer devrait faire entre 25 et 35 Koctets! (complet) Et pour vous rassurer, nous avons déjà réalisé un "gros" logiciel similaire en complexité qui faisait ....

23 Koctets.

NB: imaginez que comprimé, ce logiciel serait encore plus petit! Et, comme au paragraphe précédent ...... Eh oui, nous pouvons même comprimer une partie du code et la décomprimer "online" quand il est nécessaire. D'aucuns diront "perte de temps; avec les disques actuels ....." Oui mais! Sur un PENTIUM, ce n'est pas la bécane qui ralentit mais l'accès disque. Le processeur lui attend que le disque veuille bien lui fournir le programme ..... Et pendant ce temps il a tout le temps de décomprimer! C'est déjà rapide actuellement, imaginez que le programme soit encore 3 fois plus petit. Et notez que Micromachin pense de même (mais le dit très peu! ), regardez du côté de "Doublespace"! (Ou mieux, du côté de RAMDoubler pour les fans APPLE)......

Evidemment, cela ne plaît pas à QUANTUM ou autres SEAGATE, mais cela devrait plaire à votre portefeuille!

Donc, question de temps, question aussi de décider que le code est "stable" et donc aussi que les "responsables" Internet ne changent pas tous les 6 mois ce qu'ils disent une norme.

Une petite remarque: nous, on a les sources. Nous, on a tout écrit, sans Microtruc, sans Netmachin, .... Nous, on n'a pas besoin de "plugins". Il nous suffit d'ajouter l'extension nécessaire, quelques kilooctects, et on peut faire ce que les autres font aussi. Et rien que l'interface "plugin" et ce qui est dans le "plugin" comme interface .... nous suffira à réaliser TOUT ce qu'il faut faire. Le seul problème étant que nous ne ferons pas "toutes les extensions"! Mais comme nous on n'est pas là pour vendre les programmes originaux de tous les éditeurs ..... on peut aussi choisir l'extension qui convient le mieux pour une application!

- le troisième mousquetaire (ils étaient quatre!).... Le FTP: un simple intermède. Mais tant qu'à devoir faire un programme pour tester les protocoles Internet, ..... nous avons choisi d'en faire un réel, fonctionnel et utile. Il n'est donc pas optimisé pour la taille; il est simplement "objets", question de le rendre facile à modifier et de lui ouvrir quelques développements.

Relisant plus haut, vous constaterez qu'il est "immédiat" de lui enlever quelques kilos, 40 les doigts dans le nez en passant par Microbazar!

Mais il est quasi immédiat, affaire de quelques jours de programmation, de lui ajouter quelques gadgets comme le drag-drop vers la poubelle ou le serveur (les APPLEfanas vont apprécier le PC). Ce qui nous freine est le manque de temps et que certains nous en voudront de prouver que cela ne requiert nullement des grosses bécanes, WIN9x révision XX , et que cela ne demande même pas plus de mémoire ( encore que, à bien y regarder, mettez en route un programme MFC truc révison XX et vous verrez, cela se pèse en "multipliez par 10 la taille, par 20 le temps de calcul, .....")

 

- le quatrième mousquetaire devrait être un logiciel SMTP. Quoi que c'est? Pour ceux qui ne le savent pas "simple mail transport protocol"! Protocole simple de courrier en français.

Eh non, nous n'avons pas dit "POP !", ça, c'est pour la relève du courrier ("Post Office Protocole", protocole de bureau de poste)

Donc, l'autre, à l'étude, ce pourrait être un SMTP.

Mais justement, "à l'étude", car il semble raisonnable que puisque le "browser" est si réduit, il soit incorporé dans le SMTP, question de pouvoir visualiser un Email en HTML, avec mise en page et tutiquanti. (photos du dernier né p.ex.)

Donc, ce qui est dans nos projet, c'est bien un "mailer HTML". (On est Internet ou pas)

Le "problème" est que pour ce mailer, il faudra aussi un éditeur HTML. Et c'est là que les options prises pour le browser deviennent amusantes! Imaginez que le browser est "full objects". Il manipule donc tout en objets. Il peut donc ainsi prendre une ligne et la déplacer! Ou prendre une image et la déplacer (Certains clients vont comprendre pourquoi une démo comportait une image qu'on déplacait avec la souris! )

Donc, au passage il devrait y avoir un éditeur HTML. Oh pas un "complicate". Un simple petit éditeur capable de créer un simple petit document, ..... avec quand même des photos (du dernier né), titres en <H1>, ......

Un truc où on prend un "hard rule" (<HR>!) et le dépose là où on veut.

Bref, un bon petit éditeur "drag/drop" (glisser/déposer pour les francs!) tout bêtement.

 

Mais, comme à l'intérieur de certains et dans les outils que nous avons réalisé pour .... il y a quelques autres "bêtes" intéressantes!

Par exemple une "moulinette" à éliminer le code inutile dans les pages HTML. Oui, car en ingénieur, notre responsable technique a parfois mal au ventre en voyant ce que les "bons" éditeurs HTML placent comme code inutile dans les pages! Et il parait qu'il faudrait éviter d'encombrer inutilement les canaux Internet! Pour info, contrôlé maintes fois, le code utile ou requis est en moyenne 3 fois plus réduit que ce qui est créé par tous les "bons" éditeurs HTML.

Bref, nous imaginons seulement de créer un logiciel intégrant l'analyseur du browser et qui supprimerait tous les codes inutiles, avec un "optimiser" qui en déplaçant certains éléments réduirait encore. (un peu; parfois)

Et comme derrière CE programme se cache aussi un autre produit ...... on ne dit rien de plus mais on se tâte. En résumé, il y aura un petit éditeur HTML, très petit. Probablement avec contrôleur intégré de syntaxe.

 

Résumé:

A relire ce qui est écrit plus haut, il est évident que ce package démontre que nous avons un viewer HTML. Que ce logiciel analyse une page et que (ce n'est pas écrit), il contrôle que les "tags" sont corrects et corrige ce qu'il peut.

Il est aussi évident que nous avons un (ou des) logiciels utilisant un Winsock (bon, on expliquera pour ceux qui ne connaissent pas!). Donc, on peut aisément incorporer ce module "Winsock" dans tout autre logiciel, le browser par exemple!, c'est évident. Donc, le "viewer" est quasi un "browser", en ajoutant le moteur de connection!

Comme nous avons écrit "en corrigeant ....", cela veut dire qu'il corrige les erreurs. Il peut donc placer les tags qu'il faut où il faut!...... ça, c'est sur la route de l'éditeur.

Remarquez que un éditeur html, c'est aussi un programme pour créer un document! ..... donc un "mailer"! Et tant qu'à analyser cela, en lui enlevant les codes HTML ..... cela devient un éditeur "texte", "mailer" classique genre "EUDORA (tm)"..... mais le nôtre sera aussi un mailer HTML! (pas EUDORA tm).

Bon, envoyer un email en HTML ne sert à rien si personne ne peut le lire ..... Netscape et Internet Explorer le peuvent. Nous aussi. Donc, le POP3 ..... c'est forcé!

Et vous avez là en description ce qui devrait devenir disponible ultérieurement, parfois à court terme, simple question de décider de le mettre en ligne.

Mais il y a une remarque sur la remarque: certains logiciels sont simples, juste question d'ajouter quelques centaines de lignes à ce qui existe, et de décider de les ajouter!

Et en complément, l'ensemble de ces logiciels devrait donner quelque chose que d'autres appelent "Suite ...."; un ensemble de logiciels interconnectés capable de résoudre la majorité de ce qui est nécessaire sur Internet.

Non on n'oublie pas les acharnés du DOS!