Obligement - L'Amiga au maximum

Vendredi 17 août 2018 - 13:18  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · 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 en d'autres langues


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Logiciels
 · Jeux
 · Scène démo
 · Divers


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 : 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 de l'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 de l'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

amigados
amigados
amigados
amigados


[Retour en haut] / [Retour aux articles]