Win3x.Org

BAS340.COM :
TSR PERMETTANT D'UTILISER LE BASIC A3.40 D'IBM SUR UN COMPATIBLE IBM


A l'adresse F600:0000h, les interprètes (ou interpréteurs) BASIC d'IBM supposent et nécessitent la présence d'un BASIC de ROM (ou BASIC cassette), version C1.00 ou C1.10, qui n'existe pas sur les compatibles IBM (appelés aussi compatibles PC ou clones IBM).
L'interprète BASIC A3.40 d'IBM constitue quelque peu une exception. Il s'agit d'une version 4.00 auquelle est ajoutée une grande partie du BASIC C1.10 d'IBM dans la limite du format COM.
Cf. viewtopic.php?t=6199
Elle essaye d'obtenir l'adresse du BASIC de ROM grâce à la fonction 22h de l'interruption 15h du BIOS -- qui remplit son rôle sur les derniers PS/2 -- pour savoir si elle diffère de F600:0000h. Ensuite, elle reconstitue cette ROM en fin de mémoire conventionnelle en récupérant les 5120 premiers octets qui lui manquent.
Bien que seuls les véritables PC IBM (PC, PC/XT, PC/AT et PS/2) soient équipés du BASIC cassette, il est aisé de détourner l'interruption 15h pour que sa fonction 22h pointe sur une copie des 5 premiers Ko de ROM. C'est le but du programme résident (TSR) BAS340 : permettre l'utilisation du BASIC A3.40 à la place de GW-BASIC 3.2x sur un compatible IBM dépourvu de BASIC cassette.
De plus, ce programme vérifiera s'il est nécessaire qu'il s'installe en recherchant un éventuel BASIC cassette ou sa propre présence. Il ne s'installe pas si la version de DOS rencontrée est antérieure à la 3.30 car le BASIC A3.40 refuserait de fonctionner.
Enfin, il peut se retirer de la mémoire sous une condition : que ce soit lui le dernier à avoir détourné l'interruption 15h du BIOS.

Le TSR BAS340.COM (7 Ko) Clics : 91 L'interprète BASICA 3.40 (49 Ko) Clics : 88 Le TSR BAS340.COM Nouvelle version (7 Ko) Clics : 65

BAS340 comporte l'option R pour s'enlever de la mémoire puis restituer le vecteur d'origine de l'interruption 15h. Cela est intéressant dans le cadre d'un fichier de commandes ayant ce contenu, par exemple :

Code : Tout sélectionner IF EXIST C:\BASIC\BAS340.COM GOTO BASIC ECHO Programme BAS340.COM non trouvé ECHO. GOTO FIN :BASIC C:\BASIC\BAS340.COM BASICA.COM %1 %2 %3 %4 %5 %6 %7 %8 C:\BASIC\BAS340.COM R :FIN

Je rappelle la syntaxe de BASICA 3.40 :

Code : Tout sélectionner BASICA [fichier BAS] [< entrée] [>[>] sortie] [/C:tampon série] [/D] (double précision permise pour les fonctions mathématiques) [/F:nombre de tampons de fichiers disponibles] [/M:[octets réservés aux données du BASIC][,paragraphes totaux alloués]] [/S:taille maximale d'enregistrement dans un fichier à accès direct]

Ainsi que ses combinaisons d'édition de type Ctrl+touche (^touche) :

Code : Tout sélectionner ^B mot précédent (^Gauche) ^F mot suivant (^Droit) ^C ligne BASIC suivante ^J lie des lignes d'écran en ligne BASIC ^E efface fin de ligne BASIC ^L vide l'écran (^Orig) ^G sonnerie ^M valide ligne BASIC (Entrée) ^H retour arrière ^N fin de ligne BASIC (Fin) ^I tabulation (Tab) ^R bascule insertion/surfrappe (Inser) Clavier QWERTY (caractères ASCII 91 à 95) : ^[ efface la ligne BASIC (Echap) ^\ avance le curseur (Droit) ^] recule le curseur (Gauche) ^^ monte le curseur (Haut) ^_ descend le curseur (Bas)

BAS340 utilise l'astuce des deux FCB créés par DOS dans le PSP du programme pour récupérer l'option R dans FCB#1 et vérifier qu'il n'y ait pas d'autre paramètre dans FCB#2. On serait tenté de croire que FCB#1 rempli de blancs signifie aucun paramètre et vice-versa. Cependant, deux situations prouvent le contraire :
- le paramètre existe mais ne peut être converti en un nom valide ;
- le nom du programme suit la commande LH (LOADHIGH) de MS/DOS & PC/DOS et se retrouve en FCB#1.
C'est pourquoi, lorsqu'on le lance, BAS340 regarde l'octet 80h du PSP. S'il est à zéro, le reste de la ligne de commande (DTA) est forcément vide.
Si vous comptez utiliser des paramètres conjointement à LH, l'astuce des FCB par défaut n'est plus pratique. D'ailleurs, elles ne fonctionnent pas du tout avec la commande INSTALL du CONFIG.SYS de MS/DOS & PC/DOS.
Sous DR DOS, les commandes INSTALL & HIINSTALL du CONFIG.SYS ainsi que la commande HILOAD ne pertubent pas le fonctionnement des FCB par défaut.

Un problème avec les programmes résidents est qu'ils ont souvent besoin d'avoir recours à des fonctions non documentées du DOS.
Ce TSR-ci est tellement simple qu'il n'en a pas besoin pour fonctionner. En revanche, pour le désinstaller proprement à coup sûr, leur emploi est inévitable.

Voyons d'abord la méthode officielle :
1. Rétablir les vecteurs d'interruption utilisés. Si l'un d'entre eux a été détourné de nouveau par un autre TSR, la mémoire ne peut être libérée ; sinon poursuivre.
2. Libérez le bloc de mémoire du TSR à l'aide de la fonction 49h du DOS (version 2 et plus).

Cette méthode ne tient pas compte des redirections permises par la ligne de commande. Prenons BAS340.COM, créons un fichier ENTREE de longueur nulle (BAS340 considère les blancs seuls comme caractères sauf sous DR DOS) et tapons :

Code : Tout sélectionner BAS340 < ENTREE > SORTIE

Les fichiers ENTREE et SORTIE restent ouverts. Si SHARE est actif, ENTREE ne peut pas être modifié car il est utilisé en lecture. D'ailleurs, certains logiciels tel EDITOR de DR DOS refuseront aussi de travailler avec SORTIE car, même si l'accès est permis, ils remarqueront qu'il est déjà ouvert.
Une fois le TSR déchargé, on aimerait bien que tous les fichiers soient fermés.
Il faut donc changer de méthode dès le point n°2 :
- transformer le TSR en fils du programme de désinstallation ;
- le terminer par la fonction 4Ch de l'int 21h et redonner la main à son père.
Pour ce faire, le DOS non documenté vient en aide :
- le mot à l'offset 16h du PSP qui donne le segment du PSP du parent ;
- le service 50h du DOS qui définit le PSP actif .
Voici les nouvelles étapes :
2. A l'offset 16h du TSR, inscrire le segment du PSP du programme de désinstallation.
3. A l'offset 0Ah (vecteur de l'int 22h), mettre une adresse de retour à destination de ce dernier.
4. Rendre actif le PSP du TSR et appeler le service 4Ch du DOS.

Une fois le TSR retiré et les fichiers associés fermés, l'exécution se poursuit dans le parent. Malheureusement, tous ses registres sont à restaurer. Cela signifie que la pile courante est celle du processus auquel il est affilié. Il s'agit très certainement de l'interprète de commandes (COMMAND.COM) -- si c'est un outil de mise au point, mieux vaut que sa pile ne soit utilisée.


P.S. : merci d'avoir mis à jour les liens.
A présent, l'émulation de la fonction 22h de l'interruption 15h est fidèle à sa description technique.
La première version reste intéressante pour démontrer les limites d'un TSR n'usant que du DOS documenté (ignorance d'éventuels fichiers de redirection).