Obligement - L'Amiga au maximum

Jeudi 23 novembre 2017 - 10:03  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

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

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


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


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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


Programmation : Assembleur - commande ReadLink (commande DOS de copie des liens)
(Article écrit par Lionel Guillang et extrait d'Amiga News - mai 1993)


Suite à l'article de Pierre Ardichvili dans un numéro précédent, il me paraît intéressant de revenir sur les liens et d'approfondir un peu la question, d'un point de vue programmation.

Flashback

Pour résumer l'épisode précédent, je dirai simplement que les liens sont des fichiers ou répertoires fantômes qui renvoient des homologues physiques, un peu comme les assignations et les alias. Mais contrairement à ceux-ci, ils ne sont pas maintenus dans des listes en RAM par l'AmigaDOS, mais écrits sur disque (pour plus de détails, reportez-vous à l'article).

L'avantage évident, c'est qu'il n'est nul besoin de les redéfinir chaque démarrage du système par d'interminables scripts. Un point important est qu'ils apparaissent de façon complètement transparente et naturelle à l'utilisateur et au programmeur. Ainsi, tous les programmes qui "ignorent" leur existence les gèrent, sans s'en rendre compte (à quelques exceptions près). Mais il y a un inconvénient à cette transparence : dès que l'on veut traiter des liens en tant que tels, on s'aperçoit très vite qu'ils sont insaisissables par les techniques classiques (Lock(), Examine(), Open(), etc.).

En effet, le DOS s'emploiera, chaque fois qu'il le peut, à nous tromper ; ça peut être assez gênant dans certaines applications spécifiques, comme par exemple un programme de copie de sauvegarde de disque dur. Il faudra pouvoir "résoudre" les liens, sans quoi on risque d'avoir des surprises : imaginez la sauvegarde d'un lien qui renvoie à un répertoire de plusieurs dizaines de Mo. Si le programme se laisse duper, le dit répertoire sera tout bonnement sauvegardé et restauré deux fois, entraînant les problèmes que l'on imagine si la partition était proche de la saturation !

Et alors ?

Le petit programme que je vous propose (ouf, j'y arrive !) permet donc de résoudre les liens de tout type (matériels et symboliques). Il se présente sous la forme d'une commande DOS, ReadLink en l'occurrence, à laquelle on transmettra un nom de lien et qui retournera le chemin complet du répertoire ou fichier physique correspondant.

J'admets que l'utilité d'une telle commande est un peu douteuse, mais cela permet de faire un exécutable. J'en profite pour faire une petite parenthèse sur quelques petites absurdités du système 2.0 : le Shell est livré avec une commande MakeLink qui permet de créer des liens matériels uniquement ; par contre, la doslib contient une fonction, MakeLink(), qui permet de créer des liens de tout type, et une autre, ReadLink(), qui permet de résoudre les liens symboliques uniquement ?! Va comprendre, Charles !

Comment ça marche ?

Si le principe est relativement simple, la mise en oeuvre, elle, est un peu fastidieuse. Après avoir testé la validité de l'argument, on tente un appel à la fonction ReadLink() qui nous déchargera de tout le travail si on est en présence d'un lien symbolique : elle retourne le chemin complet (ou une erreur !) et il n'y a plus qu'à l'afficher. Si ça ne marche pas, c'est que l'argument passé est soit un lien matériel, soit une entrée physique.

Et c'est là que l'affaire se corse parce que la détermination de l'un ou l'autre des cas n'a rien de triviale. En effet, si on bloque (lock) puis examine, le DOS nous retournera systématiquement des informations concernant une entrée physique. Les seules fonctions qui permettraient de déterminer la nature de l'entrée sont ExNext() et ExAll() ; mais pour pouvoir les utiliser, il faut déjà avoir un "lock" sur le répertoire parent, qui ne sera pas, dans le cas d'un lien, le répertoire réel contenant le lien, mais celui contenant l'entrée physique correspondante (ça va, vous suivez ?)... La solution de l'accès direct aux secteurs n'est pas non plus très satisfaisante étant donné que, pour les mêmes raisons, il faudrait procéder à une recherche séquentielle du "bloc header" (en-tête de bloc).

Il n'y a donc aucun moyen, à priori, de résoudre le problème (si quelqu'un a trouvé une parade, qu'il en fasse profiter la communauté !). C'est pour cette raison que j'ai introduit une condition obligatoire pour que ReadLink s'y retrouve : un lien ne doit pas porter le même nom que l'entrée physique à laquelle il correspond. Sur un plan pratique, cela a en plus l'avantage d'éviter de se prendre les pieds dans le tapis et de ne plus savoir lequel est le vrai et lequel est le faux.

Pour retrouver le chemin complet de l'entrée physique, on utilise une routine classique de localisation de répertoire : on remonte jusqu'à la racine de l'arborescence en conservant les iodes, puis on redescend en examinant chaque répertoire et en concaténant son nom.

Pour déterminer si l'on est en présence d'un lien matériel ou non, on commence par comparer le système de fichiers du chemin obtenu avec celui de l'argument : s'ils sont différents, ce ne peut être un lien, Sinon, ultime test, on compare les noms : s'ils sont différents, c'est bien un lien matériel et on peut afficher le résultat. Voilà, le reste c'est du tout classique.

Notez que pour le même prix, vous avez un exemple d'utilisation de la fonction ReadArgs(). Veinards, va !

Listing

Assembleur
Assembleur
Assembleur


[Retour en haut] / [Retour aux articles]