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 : AmigaBasic - Mise à jour Workbench 1.2 -> 1.3
(Article écrit par Cécil B. de Mil et extrait d'Amiga News Tech - février 1990)
|
|
Ôte-toi de là, que j'm'y mette !
Depuis le Workbench 1.2 et à chaque nouvelle version du système, on se trouve confronté au problème de
la mise à jour de la configuration de l'ordinateur. Il n'est en effet pas rare de subir des plantages
et des gurus lorsqu'on mélange les versions du système.
Un jour ou l'autre, tout utilisateur se retrouve confronté à ce dilemme : doit-il, pour installer un logiciel,
copier tous les fichiers de la disquette originale vers son disque système, ou peut-il ne copier "intelligemment"
que les quelques fichiers réellement nécessaires ?
La première approche semble la plus sûre, mais elle présente deux inconvénients : gaspillage de la mémoire de masse,
et grande difficulté pour conserver un environnement homogène, car chaque logiciel semble être conçu pour être le
seul installé. La seconde approche semble être la plus raisonnable et la plus élégante, car elle permet de
mieux utiliser les ressources de l'ordinateur et elle respecte tout le travail de configuration déjà effectué
(version du système, fichier de démarrage, Preferences, pointeur, imprimante...).
Automatiser la mise à jour
Avec l'arrivée du système 1.3.2 (uniquement pour remédier à quelques bogues), je me suis attaqué à
l'automatisation du processus de mise à jour d'une configuration logicielle. En fait, un système
d'exploitation (ou n'importe quelle autre combinaison de programmes) satisfait rarement de manière
identique tous les utilisateurs. Chacun dispose d'une marge de manoeuvre pour le configurer et l'adapter.
Si à chaque progrès, à chaque avancée, à chaque version tout le travail est à refaire, la majorité
des utilisateurs refusera de faire évoluer sa configuration, si le gain n'est pas évident.
Dans mon cas particulier, l'intérêt du 1.3.2 résidait dans la réduction des bogues
liés à la mauvaise gestion du nouveau coprocesseur Super Agnus par certains programmes (dont le
DiskCopy de la disquette Workbench), coprocesseur dont est équipé mon Amiga 2000 acheté récemment.
Faire une installation propre, c'est n'installer que les fichiers nécessaires, c'est-à-dire ceux modifiés
ou nouveaux, sans pour autant détruire ceux qui sont le fruit de nombreuses heures d'expériences et
de travail acharné.
Les fichiers de configuration
Quels sont les fichiers de configuration ? En ce qui concerne l'Amiga et son système d'exploitation, il
faut accorder une attention toute particulière aux fichiers suivants :
S:startup-sequence : fichier de démarrage (équivalent de autoexec.bat sous MS-DOS).
S:startupII : fichier de configuration auxiliaire, exécuté depuis la startup-sequence pour
profiter des avantages d'un processus Shell (la startup-sequence est exécutée par un processus CLI,
qui ne peut utiliser ni les commandes résidentes, ni les alias).
Devs:System-configuration : fichier des paramètres gérés par le programme Preferences
(couleurs du Workbench, position de l'écran, caractéristiques du port série, choix de l'imprimante,
options pour l'impression graphique, etc.). Malheureusement, ce fichier est sous forme binaire.
Pour en étudier le contenu, il faut faire appel au programme Preferences.
Note : le répertoire S: correspond, sauf ordre contraire (commande Assign), au répertoire Sys:S
et Devs: au répertoire Sys:Devs. Sys:, enfin, étant le nom générique de la disquette ayant servi
au démarrage : Ouf !
Comparer les fichiers
Avant de remplacer ces fichiers, il faut comparer la nouvelle version avec l'ancienne, pour voir ce
qu'elle apporte. Si ce sont de simples détails esthétiques (genre numéro de version), on peut s'en passer
ou les appliquer manuellement ; si les différences sont plus importantes, il faudra vraisemblablement
extraire de l'ancien fichier tout ce qui était spécifique pour l'ajouter dans le nouveau. C'est en
partie pour cette raison que je recommande de toujours signaler par des commentaires adéquats les ajouts
et autres modifications dans un fichier de configuration.
C'est parce qu'il faut traiter ces trois fichiers avec prudence que le processus de mise à jour
ne doit pas être totalement automatique, mais au contraire interactif. De manière similaire, c'est
parce qu'il y a beaucoup de fichiers concernés qu'il doit être "intelligent" et effectuer tous les
tests possibles pour ne proposer comme candidats à la mise à jour, que les fichiers réellement nouveaux.
Comment détecter ces fichiers ? Plusieurs cas peuvent se présenter :
1. Le cas le plus simple est celui dans lequel le fichier existe sur la disquette source,
mais pas sur la disquette destination.
2. Les fichiers de départ et de destination n'ont pas la même taille (plus souvent qu'on ne le pense,
les nouveaux fichiers se révèlent être plus petits que ceux qu'ils remplacent).
3. Les fichiers n'ont pas la même date de création, mais ce critère n'est pas toujours fiable
car bon nombre de systèmes ont une notion du temps bizarre (horloge qui n'est pas à l'heure, horloge
détraquée, etc.) et bon nombre d'utilisateurs n'ont pas encore pris l'habitude de copier les fichiers
avec la commande "Copy ... Clone" qui conserve la date originale et les attributs des fichiers (contrairement
à la même commande "Copy" sans l'option "Clone"). En conséquence, lorsque les dates diffèrent, il convient
d'effectuer un autre test sur le contenu même des fichiers, afin de déterminer si il est resté identique.
4. Enfin, il y a quelques rares occasions (surtout à la suite de commandes Copy
mal conduites sans l'option Clone, ou après l'utilisation de programmes de sauvegarde qui positionnent l'attribut
"archivé") où ce sont les attributs des fichiers (protégés contre l'écriture, contre la lecture, contre
l'effacement, contre l'exécution, fichier script, archivé, fichier pur que l'on peut rendre résident) qui
ne sont pas identiques, auquel cas, il suffit de modifier les attributs de l'ancien fichier grâce à la commande "Protect".
Une fois cette recherche accomplie, l'utilisateur doit avoir la possibilité de suivre la recommandation du
programme (Copy ou Protect) ou de l'ignorer pour chacun des fichiers que la première phase aura
trouvé intéressant.
Comment réaliser cette détection ?
Étant donné que les tests couvrent des domaines différents, il fallait choisir un langage versatile capable
de collecter et de comparer toutes les informations pertinentes sur les fichiers (taille, âge, contenu),
et accessible à tous. Comme le BASIC Amiga est diffusé avec la machine, tout le monde y a accès, mais est-il
suffisamment puissant ?
En fait, il s'avère tout à fait adapté, car il peut utiliser toutes les commandes d'AmigaDOS grâce à la
fonction "Execute" de la bibliothèque DOS, qui permet l'utilisation d'une ligne de commande comme si
celle-ci avait été introduite dans une fenêtre CLI/Shell. Comme on va le voir, récupérer les commandes
d'AmigaDOS grâce à la routine Execute nous économisera beaucoup de programmation.
De plus, l'utilisation de ces commandes nous garantit un certain niveau de performance. Malgré cela, le
programme met de 10 à 15 minutes pour établir la liste des fichiers susceptibles de mise à jour, c'est
pourquoi de nombreux "Print" de mise au point sont encore présents dans le listing : ils permettent de
mieux suivre le déroulement du programme, mais ils le ralentissent de manière notable. Mais enfin, ce
n'est pas tous les jours qu'on refait son système, n'est-ce pas ?
Le listing
|
