Obligement - L'Amiga au maximum

Vendredi 29 mars 2024 - 08:34  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Dossier : Principes d'AmigaDOS : économique et virtuel
(Article écrit par un auteur inconnu et extrait d'Amiga News Tech - avril 1989)


Il y a deux principes que l'on ne peut ignorer lorsque l'on considère AmigaDOS : il est pensé économique, c'est-à-dire qu'il ne charge que ce qui est nécessaire, grâce à une construction modulaire, et il est virtuel, car il a une approche identique, quelles que soient les entités qu'il manipule (disquettes, disques durs, disques virtuels, réseaux, ports d'entrées-sorties...).

Les périphériques

AmigaDOS gère essentiellement des périphériques ("devices") de manière standard, au travers de gestionnaires ("dos drivers") qui ont pour rôle d'adapter les commandes aux spécificités du périphérique : ainsi, copier un fichier d'un répertoire dans un autre, l'envoyer sur l'imprimante ou l'envoyer dans une fenêtre, fait appel à la même commande,"Copy" :

Copy df0:s/startup-sequence RAM:
Copy df0:s/startup-sequence PRT:
Copy df0:s/startup-sequence CON:20/20/400/100

...puisque c'est le destinataire (RAM-Handler, printer.device ou AmigaDOS) qui fera le boulot. Cette organisation permet une très grande flexibilité, parfaitement illustrée par l'ajout dans AmigaOS 1.3 du gestionnaire de console NEWCON:, qui ajoute aux banales fenêtres CON: des possibilités d'éditions à l'aide des touches de curseurs.

D'une certaine manière, on peut dire qu'AmigaDOS repose sur cette standardisation des entités qu'il manipule (il est en cela extrêmement proche des systèmes Unix). Ainsi, AmigaDOS connaît le port série sous le nom de "SER:", le port parallèle sous celui de "PAR:", l'imprimante sous celui de "PRT:", les lecteurs de disquette sous ceux de "DF0:", "DF1:", "DF2:", "DF3:" et les disques durs sous ceux de "DH0:", "DH1:", etc. ainsi que "JH0:", "JH1:", etc.

Il connaît aussi deux disques virtuels en mémoire, RAM: et RAD:, un système d'intercommunication "PIPE:", un port série sans mémoire tampon "AUX:" et des tonnes d'autres choses que vous pouvez découvrir, en tapant la commande CLI "Info".

J'espère que vous avez remarqué que chacun de ces noms est terminé par un ":" , c'est la marque qui permet à AmigaDOS de faire appel au gestionnaire approprié (qu'il soit inclus dans AmigaDOS ou présent de manière séparé). Le principe de ces "NOMS:" a été étendu à l'utilisation de périphériques virtuels, en quelque sorte on peut associer un surnom "TOTO:" à un périphérique déjà connu, ou plutôt à un endroit précis de ce périphérique. C'est-à-dire en fait à un répertoire d'un périphérique pour autant qu'il le permette. Ainsi, on peut associer le surnom "PERSO:" au sous-répertoire "t" de la disquette contenue dans le premier lecteur par la commande CLI "Assign PERSO: df0:t" ; cela permet de remplacer toutes les références à df0:t par un renvoi sur "PERSO:".

Les répertoires

AmigaDOS exploite à fond cette possibilité pour retrouver ses petits, car il est bâti sur de nombreux fichiers qu'il a fallu répartir entre plusieurs répertoires. Les commandes du système (Dir, Copy, Type...) ont été regroupées dans un répertoire "C:" (C comme commandes), les fichiers qui contiennent des suites de commandes à exécuter sont dans le répertoire "S:" (S comme séquence de commandes), les bibliothèques chargées à la demande sont dans les répertoires "LIBS:" et "L:", les gestionnaires de périphériques sont dans le répertoire "DEVS:" (DEVS comme "devices" alias périphériques logiques), les polices de caractères sont dans le répertoire "FONTS:" et les utilitaires avec une icône pour l'utilisation depuis le Workbench sont dans le répertoire "SYSTEM:".

Si l'utilisateur n'utilisait qu'une seule disquette, AmigaDOS pouvait se contenter d'aller chercher les fichiers nécessaires dans les répertoires de la disquette, mais il lui fallait en fait conserver des indices sur la disquette de démarrage (supposée contenir les informations nécessaires au système) et ses répertoires, pour pouvoir y faire appel : c'est l'explication de ces requêtes "Please insert volume copy of WorkBench in any drive".

Pour construire ces indices, AmigaDOS procède comme suit : la disquette de démarrage se voit munie du surnom "SYS:", puis c'est au tour des répertoires nécessaires au système c, l, libs, devs, fonts, s, t, qui gagnent les surnoms "C:", "L:", "LIBS:", "DEVS:", "FONTS:", "S:", "T:". On a vu plus haut qu'AmigaDOS savait appeler les gestionnaires spécifiques série, parallèle, etc. lorsque les surnoms "SER:", "RAM:", etc. étaient présents dans un nom de fichier. De manière similaire, lorsqu'il sera en présence de surnoms "SYS:", "C:", etc. il les remplacera par les références complètes de la disquette ou des répertoires. Pour vous en persuader, examinez les informations fournies par la commande CLI "Assign", vous y trouverez à la fois les raccourcis des répertoires ("directories") et les périphériques ("devices").

Si vous m'avez suivi jusqu'ici, vous comprendrez que la commande CLI "Dir C:" est équivalente à "Dir SYS:C" (ou à "Dir C", si votre répertoire par défaut est votre disquette Workbench). En utilisant la commande CLI "Info", vous découvrirez qu'AmigaDOS, non content de connaître les lecteurs de disquette comme les périphériques logiques DF0:, DF1:... connaît aussi les disquettes par leurs noms, car il transforme le nom d'une disquette en surnom, en lui suffixant le ":".

Ainsi, même avec un lecteur, vous pouvez obtenir le contenu de la disquette Extras 1.3 en tapant la commande CLI "Dir "EXTRAS 1.3:"" depuis votre Workbench, car AmigaDOS vous demandera d'insérer le volume "EXTRAS 1.3" (attention, les guillemets sont impératifs en raison du caractère espace contenu dans le nom).

Tout ceci acquiert une grande utilité avec les extensions mémoire et les disques durs. En effet, imaginez que vous copiez toutes les commandes du répertoire C: dans le disque virtuel RAM: (à l'accès instantané) par la commande CLI "Copy C:#? RAM:test", il suffit alors de compléter par "Assign C: RAM:test" pour qu'aussitôt les commandes du CLI s'exécutent depuis la mémoire vive. Il faut préciser cependant le rôle de l'interpréteur CLI : lorsqu'on tape un nom de commande, le CLI va d'abord demander à AmigaDOS de charger cette commande depuis le répertoire courant et, en cas d'échec, il va recommencer en ayant transformé le nom, en lui préfixant l'indicatif du répertoire des commandes C:.

Path

De manière plus générale, on peut taper sans remords des noms tels que Dir, Copy, Info, List... puisque le CLI va chercher à trouver ces commandes dans toute une liste de répertoires, qui définissent une sorte de chemin de recherche faisant au minimum référence au répertoire courant et à C:. C'est la commande "Path" qui permet de visualiser et de modifier ce chemin. Si nous reprenons notre idée de copier les commandes en mémoire, on peut se contenter de ne copier que les commandes les plus utilisées par la commande CLI "Copy C:Dir|Copy|Delete|CD|Ed RAM:test" et de rajouter ce répertoire au chemin de recherche par la commande CLI "Path RAM:test ADD".

Assign, Execute et Run

En ce qui concerne l'utilisation d'un disque dur, la commande "Assign" permet de rattacher les noms des répertoires système (C:, S:, DEVS:, L:, LIBS:, FONTS:...) aux répertoires correspondants du disque dur (bien plus performant qu'une simple disquette).

De même, la commande CLI "Execute", qui permet de faire exécuter les commandes CLI contenues dans un fichier (à l'instar de la startup-sequence), exploite la technique des noms virtuels pour trouver le fichier à exécuter dans le répertoire S: des fichiers-séquence. Ainsi les commandes "Execute startup-sequence" et "Execute S:startup-sequence" sont strictement équivalentes.

La commande CLI "Run", qui lance un programme en multitâche en créant un CLI juste pour l'exécuter, tire parti des possibilités du chemin de recherche (Path), puisqu'elle explore tous les répertoires spécifiés à la recherche du programme désiré par l'utilisateur. Ainsi, si nous utilisons un programme antivirus (par exemple VirusX) contenu dans le répertoire "Util", nous pourrons l'utiliser de manière fort simple, en ajoutant le répertoire "Util" au chemin de recherche par la commande "Path SYS:Util ADD" et le garder disponible en permanence, en le lançant en multitâche par la commande "Run VirusX".

Ces deux commandes peuvent être tapées uniquement lorsqu'elles sont nécessaires, mais elles se révèlent d'une telle utilité, qu'elles mériteraient d'être inscrites dans les fichiers de démarrage.


[Retour en haut] / [Retour aux articles]