Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : Assembleur - arp.library
(Article écrit par Max et extrait d'Amiga News Tech - août 1992)
|
|
ARP, pour AmigaDOS Replacement Project, est un projet ambitieux : développé par quelques fous irréductibles,
son but n'est ni plus ni moins que de remplacer la dos.library !
Mais vous allez me dire (car je vous connais, sacrés petits fripons) "pourquoi donc vouloir remplacer la
dos.library ?". La réponse se résume en un seul mot : BCPL. Vous n'êtes en effet pas sans ignorer que
cette bibliothèque a été développée dans ce langage, ancêtre du C certes, mais ô combien contraignant :
les pointeurs sont divisés par 4, le premier octet des chaînes de caractères contient leur longueur (qui
est donc de fait limitée à 256 caractères), etc.
Relativisons cependant les choses : l'arp.library ne se positionne pas réellement à la place du DOS ;
elle ne fait qu'apporter une couche supplémentaire entre lui et les applications l'utilisant. Mais quelle couche !
Ainsi, toutes les fonctions de la dos.library existent également dans l'arp.library. Elles portent le même nom
et ont les mêmes décalages, ce qui fait que le compilateur, ou l'assembleur, utilisera automatiquement ARP
plutôt que le DOS, et ce de manière totalement transparente au programmeur (son seul souci
étant d'inclure les fichiers adéquats). La raison d'être de ces duplicatas des fonctions DOS, est justement
d'éviter au programmeur d'avoir à ouvrir la dos.library (d'où, d'ailleurs, le nom de "remplacement"
donné à ARP).
Mais ARP fait bien plus que tout cela : elle propose d'autres fonctionnalités, complémentaires au DOS celles-là,
comme une requête de fichiers (c'est la plus célèbre), la libération automatique des ressources
allouées, la gestion des caractères génériques (wildcards), l'analyse (parsing) de la ligne de commande
comme toutes les commandes de C:, la gestion de programmes résidents...
Enfin, signalons que ARP n'est pas seulement une bibliothèque. Les auteurs ont en effet réécrit la plupart des
commandes CLI/Shell en assembleur et/ou en C. Ces nouvelles versions utilisent bien entendu l'arp.library
et sont beaucoup plus légères en kilo-octets que les originales.
Les traqueurs
Avec ARP, toutes les ressources que vous allouez sont "traquées", c'est-à-dire mémorisées dans une liste, pour
permettre une libération à la fois globale et automatique, en fin de programme. Les ressources sont traquées
à l'aide d'une ResList, qui a la structure suivante :
Le noeud "rl_Node" sert à ARP à lier toutes les structures ResList entre elles. Le champs
"rl_TaskID" pointe sur la structure Task du propriétaire de la liste. "rl_FirstItem"
est une liste des ressources traquées par celle tâche, et "rl_Link" est utilisé de manière interne à la bibliothèque,
pour la gestion de "rl_FirstItem".
Une ressource traquée est également représentée par une structure :
Un pointeur sur une structure "DefaultTracker" est renvoyé par la fonction GetTracker().
Cette structure contient deux unions (c'est-à-dire des variables d'utilisation différente
mais situées à la même addresse), en l'occurrence "tr_Object" et "tr_Extra".
Ne vous y trompez pas, chaque union occupe exactement quatre octets dans la structure !
La première union contient généralement un pointeur sur la ressource allouée (mémoire, écran,
fenêtre...) tandis que la seconde contient des informations supplémentaires (taille de la mémoire,
etc.).
Lorsque le programme se termine, toutes les ressources qu'il avait allouées sont libérées,
soit lorsqu'il appelle CloseLibrary(ArpBase), soit en appelant explicitement ArpExit 0.
ARP V39 gère actuellement les types de ressources suivants :
- TRAK_AAMEM, EQU 0 : élément par défaut (ArpAlloc()).
- TRAK_LOCK, EQU 1 : Lock (ArpLock()).
- TRAK_FILE, EQU 2 : fichier ouvert (ArpOpen()).
- TRAK_WINDOW, EQU 3 : Window.
- TRAK_SCREEN, EQU 4 : Screen.
- TRAK_LIBRARY, EQU 5 : Library ouverte.
- TRAK_DAMEM, EQU 6 : bloc mémoire (DosAllocMem()).
- TRAK_MEMNODE, EQU 7 : Noeud AllocEntry().
- TRAK_SEGLIST, EQU 8 : Liste de segments.
- TRAK_RESLIST, EQU 9 : ResList.
- TRAK_MEM, EQU 10 : Bloc mémoire (AllocMem).
- TRAK_GENERIC, EQU 11 : élément générique (personalisé).
- TRAK_DALIST, EQU 12 : DAlist (FileRequest()).
- TRAK_ANCHOR, EQU 13 : AnchorChain (MatchFirst()/Next()).
- TRAK_MAX, EQU 13
La plupart des types définis ci-dessus sont créés automatiquement par la bibliothèque
lors de l'appel de la fonction correspondante : par exemple, ArpLock() crée un DefaultTracker
de type TRAK_LOCK. Il n'existe cependant pas de fonction de type ArpOpenLibrary(),
ArpOpenWindow() ou ArpOpenScreen(). Il faut alors utiliser une fonction supplémentaire, GetTracker() :
L'appel en assembleur de passe un tout petit peu différemment (le C utilise des routines "glue"
qui ne se contentent pas de transférer les paramètres depuis la pile vers les registres...) :
En démonstration de ces fonctions de "traque" de ressources, je vous propose un petit programme qui, à
la façon de PPMore, permet de visualiser le contenu d'un fichier ASCII.
(code source non complet)
|
