Obligement - L'Amiga au maximum

Vendredi 17 novembre 2017 - 22:17  

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 - les notifications
(Article écrit par Frédéric Delacroix et extrait d'Amiga News - octobre 1994)


On le sait déjà, les progrès faits par AmigaOS depuis sa version 2.0 sont immenses. Parmi les nouveautés, la notification répond à un besoin lié à la nouvelle gestion des Préférences à partir de cette version : elle permet de détecter les changements effectués sur un fichier. Dans le cas des Préférences, c'est le programme IPrefs qui se charge de cette surveillance.

Le principe

Sur Amiga, les lecteurs de disquette, le disque dur, le RAM Disk, tout ce qu'on peut imaginer, sont gérés par des processus séparés. Ainsi, DF0: gère le lecteur interne, RAM: le RAM Disk, RAD: le disque récupérable, SER: le port série, etc. Le rôle de ces processus, appelés "handlers", est de gérer les périphériques, soit directement, soit par l'intermédiaire des devices d'exec. La dos.library est ainsi, en gros, un protocole de communication entre les processus : le programme et les handlers, d'où l'apparition des fameux paquets DOS (DosPackets), que nous n'étudierons pas en détail ici.

Certains handlers, comme PRT (imprimante) ou SPEAK (le narrateur) n'acceptent que des données brutes, ce n'est évidemment pas le cas de ceux qui gèrent des fichiers. Le code s'occupant alors de ces handlers s'appelle alors un "filesystem" (système de fichiers). Sur Amiga, deux systèmes de fichiers se trouvent déjà en ROM : le premier gère soit l'OFS (Old File System, utilisé surtout avant le Kickstart 2.0) ou le FFS (Fast File System, version aux performances améliorées). Le FFS est apparu avec le Kickstart 1.3, et résidait sur disquette (répertoire L:), on ne pouvait pas amorcer une disquette FFS. De nos jours (Kickstart 2.0 et plus), l'OFS et le FFS ont été réunis dans un seul module, situé en ROM, d'où son nom de "ROM FileSystem" (système de fichiers en ROM). Le second système de fichiers se trouve au sein même du RAM-handler, le gestionnaire du RAM Disk.

Le Workbench 2.1 a également apporté le système de fichiers CrossDOS, qui permet d'accéder aux disquettes au format MS-DOS comme s'il s'agissait de disquettes Amiga. D'autres système de fichiers peuvent prendre en compte un lecteur de CD, ou d'autres formats étrangers, on peut trouver le ProFileSystem dans le domaine public (on peu bogué me semble-il) ; on a ici un aperçu de la puissance du système de l'Amiga.

En fait, les systèmes de fichiers et les handlers ont le même rôle : recevoir et interpréter les messages des autres processus qui leur parviennent sous forme de paquets DOS : lecture, écriture, ouverture de fichier, etc. Les processus nommés DF0:, DF1:, DH0: sont ainsi de multiples incarnations du système de fichiers en ROM, chargés chacun du device DOS correspondant. Ce qui nous concerne ici est le fonctionnement de l'un de des paquets DOS, apparu avec le Kickstart 2.0, et plus précisément son interface avec la dos.library : la notification.

La notification consiste à demander à un handler (chargé d'un device DOS) de vous prévenir lorsqu'un objet à sa charge est modifié (par vous-même ou une autre tâche, peu importe). Pour l'instant, il n'est pas possible de surveiller les lectures. Précisons tout de suite que les systèmes de fichiers ne sont absolument pas obligés d'autoriser la notification. Le système de fichiers en ROM et le RAM-handler l'utilisent (pas sans bogues mineurs, d'ailleurs), pas CrossDOS.

Les opérations suivantes peuvent déclencher une notification : écriture dans un fichier (dans ce cas, la notification intervient à la fermeture du fichier), création d'un fichier, création d'un répertoire, effacement d'un fichier, création de liens matériels (hard links), changement de nom, de commentaire, de date ou d'attributs de protection. De plus, la notification est associée au volume et non au device. C'est-à-dire que si vous enlevez la disquette avec le fichier surveillé et en insérez une autre, les fichiers de celle-ci ne sont pas surveillés. C'est comme si, par exemple, DF0: désignait la disquette en DF0: et non le lecteur lui-même.

Concrètement

Toute demande de notification passe obligatoirement par une structure, définie dans dos/notify.i, fort judicieusement nommée "NotifyRequest".

Assembleur

Voyons les champs importants de cette structure :

"nr_Name" contient un pointeur sur le nom de l'objet (fichier ou directory) à surveiller. Ce nom sera étendu (en résolvant les assignations et liens) par la fonction "StartNotify()", un pointeur sur ce nom complet sera alors disponible dans le champ "nr_FullName".

"nr_Flags" contient quelques drapeaux (flags) qui indiquent au handler comment procéder. Les drapeaux définis indiquent si la notification doit être faite par l'envoi d'un message (drapeau NRF_SEND_MESSAGE) ou d'un signal (drapeau NRF_SEND_SIGNAL), si le handler doit attendre la réponse avant d'envoyer une nouvelle notification (drapeau NRF_WAIT_REPLY, valable uniquement avec NRF_SEND_MESSAGE) et s'il doit envoyer une notification tout de suite (drapeau NRF_NOTIFY_INITIAL). Vient ensuite une union. Rappelons que dans ce cas, seule la taille du plus grand des champs est réservée au sein de la structure. Dans le cas du drapeau NRF_SEND_MESSAGE, on trouve un pointeur sur le MsgPort où le message doit être envoyé (champ "nr_Port"), ou, dans le cas de NRF_SEND_SIGNAL, l'adresse de la tâche à signaler et le numéro du signal (et pas le masque correspondant !) à utiliser.

Il va de soi que le signal doit avoir été alloué par AllocSignal() avant ! Les autres champs sont privés et doivent être mis à 0. Une fois la structure NotifyRequest réservée et initialisée, on peut le déclarer grâce à la fonction suivante de la dos.library :

succès.StartNotify(NR)
D0        D1

A partir de ce moment, la structure NotifyRequest ne doit plus être modifiée : en effet, le handler peut y accéder à tout moment pour envoyer des messages. A propos, voyons la structure des messages reçus dans le cas du flag NRF_SEND_MESSAGE :

Assembleur

Outre le message Exec placé au début, le seul champ important pour nous est "nm_NReq" : il pointe la structure NotifyRequest concernée, ce qui est bien pratique si on surveille beaucoup d'objets à la fois. La raison d'être des champs "nm_Class" et "nm_Code" est l'imitation d'une structure IntuiMessage, d'où la possibilité d'utiliser le port IDCMP d'une fenêtre pour la notification. Ce n'est toutefois pas recommandé.

La valeur retournée par StartNotify() indique si le handler a ou non accepté votre demande de notification. Contrairement à ce que racontent les autodocs, si StartNotify() a échoué, il ne faut pas appeler la fonction suivante. Celle-ci permet de retirer une demande de notification : la structure NotifyRequest (passée en argument) pourra alors être libérée ou réutilisée.

EndNotify(NR)
   D1

Bogues ?

Comme je l'ai dit plus haut, la notification est légèrement boguée dans les versions actuelles des deux systèmes de fichiers en ROM, rien de très grave, rassurez-vous.

Premièrement, la version 36 (Kickstart 2.0) du système de fichiers en ROM n'envoie pas de notifications du tout, mais tout le monde devrait posséder au moins la version 37 de nos jours. De plus, le système de fichiers en ROM n'accepte de notification sur un répertoire que si celui-ci existe déjà au moment de StartNotify(), la création d'un fichier en MODE_READWRITE ne déclenche pas de notification, et EndNotify() ne marche pas correctement sur les fichiers situés sur une disquette non insérée dans un lecteur. Le ram-handler, quant à lui, n'envoie pas de notification si un fichier est modifié dans un répertoire surveillé (alors que cela constitue aussi une modification du répertoire en question).

Enfin, le système de fichiers en ROM ignore (pour la notification) SetComment(), SetFileDate() et SetProtection(). Le RAM handler ignore SetComment() et SetProtection().

Programme d'exemple

Nous en savons assez pour écrire un programme de surveillance de fichiers et de répertoires. Pour corser un peu, je l'ai prévu pour surveiller plusieurs objets en même temps, ce qui montre un peu la gestion des listes.

Une dernière chose : sachant que tous les systèmes de fichiers n'implémentent pas la notification (en particulier CrossDOS et tous les systèmes de fichiers de réseaux), il vaut mieux ne pas trop se reposer dessus et prévoir, lorsqu'il s'agit de relire un répertoire ou de recharger un fichier, une action manuelle. De plus, on peut aussi détecter les changements effectués sur un répertoire en comparant les dates de modifications (ce que font certaines requêtes de fichiers).

Sur ce, je vous laisse avec le listing du programme, à bientôt.

Assembleur
Assembleur
Assembleur
Assembleur


[Retour en haut] / [Retour aux articles]