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
|
|
|
|
Test d'OS Devkit 1.10
(Article écrit par Gilles Bihan et extrait d'Amiga News - avril 1996)
|
|
Depuis sa création, le langage de programmation AMOS n'a eu de cesse d'évoluer. La version initiale, après quelques rectifications,
est devenue professionnelle, apportant un cortège de nouveautés qui donnent à cet outil une pérennité sur Amiga incalculable.
Pour renforcer les efforts de François Lionet, une pléiade d'extensions a vu le jour afin de compléter les lacunes constatées. Un
domaine cependant n'avait pas ou peu connu de succès ; il s'agit des choix technologiques retenus dans la conception du langage ne
le favorisant pas : le développement d'application AmigaDOS.
Un langage controversé
En effet, la programmation sous AMOS faisait abstraction du Workbench, et les quelques instructions orientées multitâche ne
permettaient pas de réaliser des applications "pleinement" compatibles. Certains puristes voyaient en cela une hérésie, rejetant
de facto l'utilisation de ce langage, et ce malgré la large audience obtenue auprès du public par ce dernier. Il est vrai qu'un
programme écrit en AMOS, bien qu'utilisant au maximum la puissance de la machine, n'était pas totalement satisfaisant pour
l'esprit. Une passerelle avec le système d'exploitation existe bien, mais cette coexistence des deux environnements ne favorise
pas le dialogue, et s'affranchit trop souvent des règles d'éthique logicielle prescrites par le défunt Commodore. On se retrouvait
avec des produits hors normes, sans homogénéité avec l'environnement.
De plus, ces tares n'ont eu de cesse de freiner l'expansion de ce langage, le cantonnant essentiellement à l'écriture de
programmes de jeux (ce qui est d'ailleurs son but initial et sa préférence), obérant ipso facto ses chances de reconnaissance
dans le monde du développement professionnel sur Amiga. En conséquence de quoi, AMOS bien qu'outil de prédilection des
développeurs du dimanche, ne connut pas la renommée qui lui est dévolue.
L'essence d'une idée
Loin de ce sombre tableau, il est bon de noter que malgré tout, bon nombre de développeurs se sont investis dans ce produit,
et au premier rang figure sans nul doute Brice Fromentin. Ce dernier, soucieux d'éviter les lourdeurs implacables des
errances du C ou de ses avatars, a eu l'idée, et surtout la volonté, de mettre au point une extension capable de palier les
carences ci-dessus relevées. Pour mémoire, rappelons que les extensions AMOS, écrites en assembleur, s'intègrent parfaitement
au langage en offrant de nouvelles instructions utilisables comme un simple "Print". Conscient de cette notion, rien de plus
simple alors que d'étoffer ce langage à l'infini, l'imagination n'étant que la seule borne.
De tout cela est né le OS DevKit, un excellent raccourci vers le développement d'applications Intuition à partir de ce langage
si agréable à utiliser. Une fois la bibliothèque d'extension intégrée dans votre environnement de programmation, toutes les
instructions s'implémentent et ne font plus qu'un avec l'imposante panoplie déjà à votre disposition.
Le kit, en effet, se présente sous la forme de deux disquettes. L'installation est semi-automatique, et a posé quelques soucis,
à savoir entre autres choses qu'il a fallu l'exécuter en démarrant sur la disquette d'installation. Hormis ces balbutiements,
il ne reste qu'à inscrire l'extension dans les préférences d'AMOS. Bien que cela soit facile à réaliser, la procédure doit
être suivie avec minutie sous peine de déstabiliser le langage. Une fois ces opérations réalisées, vous découvrez dans votre
répertoire AMOS un fichier d'aide AmigaGuide seul élément visible de la transformation.
Les principes de base
L'appel des fonctions est des plus simples, car il est identique aux fonctions standard d'AMOS. Il suffit d'intégrer les
instructions dans votre code source et de lancer l'exécution. Par contre, plus intéressante est la dichotomie retenue dans
la forme lexicale des noms d'instruction. En effet, l'auteur, soucieux de les identifier plus facilement, leur a collé
des extensions.
Les appels de fonctions sont précédés d'un raccourci significatif. Par exemple, pour ouvrir une fenêtre de requête ASL, on
invoque "_asl Do", où "_asl" est le nom de la bibliothèque apparentée et "Do", la commande à exécuter. De la même manière
on trouve également "_scr Open" où dans ce cas "_scr" est le raccourci d'écran.
Dans un souci de clarté, un mot-clé peut venir s'intercaler dans certaines hypothèses. Par exemple, pour fixer une valeur
dans une structure, on va intercaler un "Set" comme "_spr Set Height" qui fixe la hauteur d'un sprite. Hormis ces commandes
actives, on trouve également des ordres que l'on peut classer dans la catégorie "lecture/écriture", et qui servent à extraire
une ou plusieurs valeurs des structures internes. Par exemple, pour connaître le contenu du texte d'un gadget dans une
structure Intuitext on utilise la commande "_gad What Text" (notez la désignation triple).
Ce système de notation est efficace, car très parlant, et surtout il permet d'identifier facilement les commandes. Il
présente également l'avantage d'utiliser les noms usuels retenus dans les bibliothèques Amiga.
Le noyau standard d'AMOS s'accommode très bien de l'utilisation du DevKit dans la mesure où l'ensemble est cohérent, et que
le langage offre des commandes minimales de gestion du multitâche (par exemple : "AMOS to here"). Ce sont d'ailleurs par
ces dernières que l'on ouvre une porte vers le monde Intuition, et que l'on redonne éventuellement la main au langage.
L'étendu des commandes
Bon nombre de bibliothèques ont vu le jour sur notre système, et cette extension AMOS ne cherche qu'à intégrer les plus
classiques, à savoir "Exec", "Intuition", "Graphics", "Dos", "Asl" et "Gadtools". Normalement, avec tout cela, on utilise
95% des ressources, le reste étant plus exotique. Toutes les commandes de base sont implémentées, avec en plus quelques
commandes bonus. En effet, la commande "_Sys Cpu" donne le numéro de microprocesseur. Idéal pour faire un utilitaire d'information
système ! "_Cold Reboot" réalise un démarrage à froid de la machine.
Hormis ces fonctions pratiques, l'organisation des commandes s'ordonne de manière classique. Les appels de bibliothèque sont
réalisés directement dans le code de l'instruction AMOS. A l'ouverture d'OS Devkit, une initialisation des pointeurs sur
les adresses de base bibliothèque est faite. On retrouve d'ailleurs cela dans les fonctions du genre "_base Asl" qui retourne
une adresse de localisation de la bibliothèque ASL. Par la suite, à chaque appel de fonction, l'OS Devkit fait lui-même
les passages de paramètres dans les registres machines.
Ce système fait quasiment disparaître les appels fastidieux à de multiples pointeurs et la recherche des numéros de fonction.
C'est en cela que ce produit peut s'apparenter le plus à une immense macro gérant pour vous un grand nombre de commandes systèmes.
Cette extension est une passerelle logicielle entre les deux environnements (on peut aussi appeler cela une interface). Ces
facilités trouvent cependant vite une limite : aucun contrôle ne s'effectue sur le codage des données à transmettre. De ce
fait, un utilisateur novice risque de rencontrer de nombreux plantages, car une bonne connaissance du système d'exploitation
est nécessaire.
Cependant, ces instructions sont complétées par un judicieux panel de commandes gérant l'écriture et la lecture des pointeurs
et des structures. Par exemple, pour ouvrir une fenêtre, on utilise l'instruction "_wnd Open" suivie entre parenthèses des
valeurs de paramétrage. Si on omet ces valeurs, la fenêtre s'ouvrira avec une présentation par défaut. On peut indiquer les
coordonnées du coin supérieur gauche ainsi que la hauteur et la largeur de la fenêtre. On peut enfin passer en ligne les drapeaux
Intuition. Dans le même état d'esprit, certains passages de paramètres sont fait par une instruction spécifique.
Par exemple, "_scr Def Title" définit le titre du futur écran à ouvrir. Ou encore, "_scr What Width" donne la largeur actuelle
de l'écran. Très souple, ce système de contrôle facilite grandement le travail avec les bibliothèques et la gestion des appels
de fonction. Cela présente aussi l'avantage d'offrir une lecture aisée de vos codes sources. Plus besoin de chercher dans une
structure, la ligne qui correspond à une définition particulière. La définition des décalages les plus courants se fait par OS Devkit.
L'auteur a également pris en considération la gestion de certaines structures complexes. Je pense notamment aux listes chaînées.
Il a créé à cette occasion des commandes de gestion qui vont de la genèse à la destruction, avec bien entendu, des commandes de
déplacement et de recherche. On peut donc ajouter des noeuds ou retrouver une chaîne précise dans une liste. Le Workbench 2.0 a
introduit des listes particulières pour la gestion de certains éléments graphiques : les TagLists (listes de
balises). Elles n'ont pas été oubliées, et répondent à la même logique que les commandes précédentes.
Une extension en or
Nul besoin d'en dire plus pour convaincre certains de développer leurs applications Workbench sous AMOS. Bien que le paquetage se
suffise à lui-même, l'absence d'un manuel papier se fait remarquer. La documentation au format AmigaGuide se présente plus comme
un index qu'un véritable mode d'emploi. Il est dommageable que l'auteur ne l'ait pas complété par un tutoriel et un résumé des
connaissances essentielles à détenir sur la programmation système.
Un programmeur AMOS ne possédant aucun rudiment de C ou d'assembleur risque de ne pas y trouver son compte. A l'image de la
richesse en informations distillées dans le manuel d'AMOS, on aurait aimé quelque chose de plus consistant, permettant à un
néophyte de mettre le pied à l'étrier, surtout que les documentations techniques sur l'Amiga ne courent pas les rues
(l'auteur promet dans ce domaine quelques améliorations).
Conclusion
Pour ce qui est des résultats, ils sont excellents, même si j'ai constaté un ralentissement certain dans l'exécution des
programmes par rapport à ce qu'il est possible de réaliser avec les mêmes commandes en C ou en assembleur. L'osmose produite
avec AMOS oblige à conserver ce dernier en tâche de fond, ce qui, le connaissant, n'est pas toujours des plus prudents.
Le compilateur AMOS réagit normalement et ne souffre visiblement d'aucune altération. Par contre, vos oeuvres ne fonctionneront
qu'à partir du Workbench 2.0.
En définitive, c'est un excellent produit qui ne se contente pas d'imiter l'interface Intuition sous écran AMOS, et qui
facilitera bien des développements futurs pour ceux qui auront le courage de s'immiscer dans les arcanes du système natif.
Nom : OS Devkit.
Auteur : Brice Fromentin.
Genre : extension pour AMOS.
Date : 1996.
Configuration minimale : Amiga OCS, 68000, 1 Mo de mémoire, AmigaOS 2.0.
Licence : commercial.
Prix : 390 FF.
|
|