|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Disposant depuis quelques mois d'une version du Workbench et d'AmigaDOS 1.3, et depuis début décembre de la version commercialisée, je me propose de donner ici quelques impressions d'utilisation. ![]() Il n'est pas question de faire ici une énième présentation détaillée de cet ensemble. Par ailleurs, le manuel de la version 1.3 des logiciels dont je ne dispose que d'une copie en anglais, est clair et très bien fait. Il comporte la documentation des fichiers de la disquette Extras 1.3, un excellent chapitre plein d'exemples sur les startup-sequence et même la documentation de MicroEmacs. Il est publié directement par Commodore et est du même niveau de qualité que le traditionnel manuel publié par Bantam Computer Books. Il ne dispense pas, par ailleurs, de l'achat de ce dernier manuel, au contraire, il s'y réfère souvent. J'espère que les auteurs de "Clés Pour Amiga" et de la "Bible De l'Amiga" publieront rapidement des compléments en français pour la version 1.3. Je vais donc dans cet article vous faire part de quelques constatations personnelles, d'ordre très pragmatique sur la version 1.3, en indiquant toutefois que je n'ai pas connu la version 1.2 en Kickstart sur l'A1000, et que j'ai l'optique particulière d'un utilisateur d'Amiga 2000 avec extension de mémoire et disque dur. Il y a donc des possibilités très intéressantes de la version 1.3 pour ceux qui disposent d'un Amiga 500 sans extension de mémoire, et qui me sont nécessairement moins apparentes. Aucun des jugements que je vais porter dans ce qui suit n'est donc vérité d'évangile, ni applicable sans considérer en même temps la configuration de votre système. J'aborderai trois grands thèmes : 1. Les possibilités additionnelles. 2. L'interface utilisateur. 3. L'accroissement des performances. 1. Les possibilités additionnelles Elles se situent au niveau du CLI et du Shell. des commandes que l'on trouve dans le répertoire C, des utilitaires, des polices de caractères, des gestionnaires d'imprimantes et du disque virtuel. 1.1. Le CLI L'Amiga a beau avoir une structure, encore à l'heure actuelle, très en avance sur celles des PC, le bon vieux CLI ne satisfaisait pas tout le monde, il suffit pour s'en convaincre de voir le nombre d'utilitaires du domaine public destinés à lui ajouter des fonctions très désirables, comme l'affichage du chemin et du répertoire courant, en tête de ligne. Pour cela, entre autres, il a été créé un programme du domaine public appelé ARP (A Replacement Program) associé à une bibliothèque. Le nom par lui-même en dit long sur ce que pensaient ses auteurs du CLI comme interface utilisateur. La version 1.3 d'AmigaDOS offre la possibilité d'écrire un fichier de commandes CLI-Startup qui est invoqué à chaque démarrage du CLI. C'est très intéressant car cela permet par exemple d'avoir automatiquement sous CLI l'invite de commande de ARP qui affiche le répertoire courant, avec son chemin. Mais pourquoi diable encore utiliser encore le CLI alors qu'on a le Shell ? Nous le verrons plus loin. 1.2. Le Shell Le Shell offre beaucoup de nouvelles possibilités, la première étant de disposer, comme tout Shell qui se respecte, d'un historique des commandes et de la possibilité d'éditer les lignes sans avoir à les refaire en entier, ce qui économise beaucoup de frappes. Dommage que l'on ne puisse pas, comme dans ConMan, sauver l'historique dans un fichier pour le réutiliser par la suite, ou même, toujours comme dans ConMan, créer de tels fichiers par Ed. Ici, le domaine public a toujours une longueur d'avance. Le Shell dispose également, comme décrit ci-dessus pour le CLI, d'un fichier shell-startup qui permet de faire beaucoup de choses, entre autres :
...est bien illustratif. La commande "Ren" ci-dessus donne, grâce à l'application du fichier "DPAT", contenu dans le tiroir "S" de la disquette Workbench 1.3, la possibilité de renommer des fichiers en série, par exemple :
...est censée faire passer toute une série de fichiers appelés Chap1, Chap2, etc., du répertoire racine de la disquette placée en DF0: dans le répertoire "Livre" tout juste créé. Seulement, il y a plusieurs raisons pour que cela ne marche pas. D'abord, vérifiez que votre startup-sequence comporte bien la commande :
...car la commande "Alias" n'est pas une commande du répertoire C, elle est tapie bien au chaud dans le gestionnaire Shell-Seg, dont le fait qu'il ne soit pas monté en résident par la commande ci-dessus n'empêche en aucune façon l'ouverture de fenêtres Shell par ailleurs. Il est tout de même étonnant que l'on puisse ainsi ouvrir un Shell incomplet. Vérifiez, en outre, que vous avez bien créé une unité ENV: (voyez comment faire un peu plus loin lors de la description de SetEnv), car DPAT en a besoin. Vous éviterez ces deux pièges et bien d'autres en étudiant à fond les startup-sequence de la disquette Workbench 1.3. Mais le pire est encore à venir : la syntaxe donnée dans l'exemple, à savoir :
...est fausse, ça ne marche que sans les guillemets. Mais à la fin, ça marche quand même. La commande "Alias" peut évidemment être utilisée à tout moment dans une fenêtre Shell, mais elle sera particulièrement précieuse dans votre fichier Shell-Startup pour personnaliser votre système en fonction de vos besoins. 1.3. Les commandes du répertoire C Il y en a 64, dont quelques-unes sont nouvelles, d'autres sont améliorées. Parmi les nouvelles, à remarquer la présence de : FF qui n'est autre que le programme FastFonts disponible auparavant dans le commerce. La vitesse d'affichage du texte est considérablement accrue. Nous en reparlerons au sujet de More. Resident : cette commande a la puissance mais aussi le pouvoir de dévastation de la dynamite. Le manuel consacre une page entière aux précautions à prendre avant de mettre une commande résidente en mémoire, mais comme il y en a certainement qui vont essayer de jouer avec Resident sans avoir le manuel, sachez ce qui suit : Pour être mise sans danger en mémoire en tant que résidente, une commande doit être pure, c'est-à-dire réentrante et réexécutable. Réentrante signifie qu'elle peut être exécutée pas plusieurs programmes en même temps, réexécutable veut dire qu'elle ne laisse pas dans la mémoire des traces susceptibles de poser des problèmes lors d'une deuxième exécution. L'immense majorité des programmes ne sont ni réentrants ni réexécutables à la fois. La mise en résidence en mémoire d'une commande non pure peut avoir des conséquences catastrophiques, pouvant aller jusqu'à corrompre la structure d'un disque dur. Le manuel consacre une page entière aux précautions à prendre avant de le faire. Avant de mettre une commande du répertoire C en résidence en mémoire, vérifiez par la commande "List" qu'elle a le bit "Pure" (non, il n'y a pas de faute d'orthographe). Exemple :
Notons encore que la commande "Protect" vous permet de mettre le bit "Pure" à une commande qui ne l'a pas, et que la commande "Resident" permet de forcer le bit "Pure". Vous avez donc la possibilité d'essayer ce qui se passe avec une commande non pure mise en résidence en mémoire, mais protégez votre disquette Workbench en écriture, et annulez toutes les assignations à des répertoires du disque dur. Lancez votre commande plusieurs fois de suite, puis arrangez-vous pour qu'elle soit appelée simultanément par plusieurs programmes. Si tout se passe bien, faites de nombreux essais, surtout si vos commandes agissent sur des écritures de fichiers, et vérifiez l'intégrité des fichiers en question. Ne vous plaignez jamais d'ennuis encourus pour avoir utilisé Resident ; la sécurité, c'est de n'utiliser avec ces commandes que les commandes que vous avez trouvées avec le bit "Pure" dans le répertoire "C" de votre disquette Workbench 1.3. Vous êtes prévenus ! IconX permettant de lancer un fichier de commandes à partir du Workbench. Setpatch destiné à être mis en tête de la séquence de démarrage "pour remédier à un certain nombre de bogues connus des ROM Kickstart 1.2 et 1.3 (sic)". Je trouve la démarche très honnête car il est rare qu'un constructeur reconnaisse officiellement dans un de ses manuels d'instructions qu'il y a des défauts, non seulement dans des programmes anciens, mais aussi dans la toute dernière version, et fournisse le remède en même temps. Bravo Commodore. SetEnv, GetEnv. Il est possible de créer une unité logique appelée ENV: (environnement) par une commande "Assign". Exemple :
SetEnv permet alors de créer une variable d'environnement :
Cette ligne crée dans l'unité logique ENV: (ici le répertoire "ram:envir) une variable de nom "Editor" et de valeur "DF0:c/Ed". GetEnv permet de retrouver la valeur d'une variable d'environnement.
...donne l'affichage : "DF0:c/Ed". Pour le moment, la seule utilité directe de cet ensemble est de donner au programme de lecture de fichiers More un "environnement" sous la forme d'un éditeur de votre choix appelable par pression d'une touche. Voyez plus bas pour plus d'informations sur More. Le manuel signale également la possibilité d'utiliser ces variables d'environnement avec la nouvelle version de la commande "If", mais je n'ai pas creusé ceci. Il est encore indiqué qu'à l'avenir, d'autres commandes seront créées, qui pourront faire appel à des variables d'environnement. Voilà donc un outil très prometteur, mais il faudra un peu de temps pour pouvoir disposer de toute sa puissance. Parmi les commandes modifiées, remarquons : List dont je vous laisserai le plaisir de découvrir toutes les facettes le jour où vous aurez en main la documentation du 1.3. La plus remarquable modification est l'addition d'une option "LFormat". L'exemple d'application donné dans le manuel prend presque une page et il faut bien nous limiter ; disons qu'elle permet de créer instantanément un fichier de commandes susceptible d'appliquer une commande donnée à une série de fichiers désignés par joker (#?). En d'autres termes, ceci dorme la possibilité d'utiliser avec des jokers des commandes qui normalement ne les acceptent pas, et ça marche sans problèmes. Protect qui permet de modifier les nouveaux attributs des fichiers (bit d'archive, bit "pure", bit de fichier de commandes). Prompt qui permet dans une fenêtre Shell d'afficher le répertoire courant et le chemin. Run qui permet maintenant de commander l'exécution d'une tâche en arrière-plan et de refermer la fenêtre CLI dans laquelle la commande "Run" a été lancée, comme le faisait Runback du domaine public. C'est particulièrement utile pour lancer dans la startup-sequence des programmes qui doivent rester en activité mais qui ne rendent pas la main au CLI. La syntaxe est :
Status qui, dans le même ordre d'idées, permet maintenant d'écrire dans un fichier le numéro du processus (CLI ou Shell) dans lequel tourne un programme. Ce numéro peut être récupéré par "Break" pour arrêter ledit programme, et tout ceci peut être fait par le truchement d'un fichier de commandes lancé par "Execute". L'exemple du livre est :
Il faut évidemment que le programme puisse être arrêté par "Ctrl-C", "Ctrl-D", "Ctrl-E" ou "Ctrl-F" sans quoi la commande "Break" est impuissante. Eval qui, ô merveille, nous permet de faire de l'arithmétique décimale, hexadécimale, octale ou booléenne, en envoyant le résultat dans un fichier ou à l'écran, dans la base souhaitée et sous un format déterminé. Étonnant, non ? Amusons-nous un peu :
...fait le produit de F hexadécimal par 15 décimal, l'affiche en octal avec quatre chiffres, et va à la ligne, ce qui donne "0341", ce qui est parfaitement conforme au résultat attendu. Bon, ça m'a donné mal à la tête et il y a les deux tonnes d'anthracite à décharger dans la cour, avançons. Skip qui, grâce à sa nouvelle option "Rack", permet le saut en arrière à une étiquette donnée par "LAB:" en conjonction avec "Eval" et "If", on en arrive à pouvoir considérer l'ensemble des commandes CLI ou Shell comme un langage de programmation. Sachant aussi que "Skip >NIL: ?" attend une réponse un peu comme une instruction "Input" en BASIC, c'est en plus un langage interactif. Vous pourrez donc modifier le cours de votre startup-sequence en répondant à une question que vous vous serez posée par "Echo". Ceci permet d'avoir par exemple une seule disquette de démarrage pour plusieurs configurations, et sera particulièrement utile lors du démarrage par disque dur. Info qui peut maintenant être appliqué à une seule unité ; par exemple on peut demander "Info Part:" où "Part" est par exemple le nom d'une partition du disque dur. Attention : ça ne marche qu'avec le nom de la partition tel qu'il figure dans la "Mountlist" (liste de montage). Par exemple, j'ai une partition qui s'appelle "Store" et qui est référencée p4 dans la liste de montage. Si je fais :
J'obtiens :
Par contre, si je fais :
J'obtiens :
Est-ce un bogue ? Non, car le manuel donne la syntaxe :
C'est donc parfaitement logique mais c'est un petit piège. À propos, vous connaissez cette horrible fenêtre de requête qui donne la sueur froide : "Software error. Task held. Finish all disk activity... Select CANCEL to reset/debug". Vous savez par expérience que cliquer dans "Cancel", si vous n'avez pas GOMF, amène automatiquement le détesté Guru. Bon, en lisant bien, on se dit que "la" tâche qui est suspendue est celle qui a causé l'erreur, mais le système est-il mort pour autant ? Eh bien, non ! Ou du moins pas toujours. Si vous avez PopCLI ou quelque chose d'équivalent, ouvrez donc un nouveau CLI et si vous avez de la chance, vous pourrez continuer à travailler ! Comme quoi dans les documentations ou dans les messages, un certain sens de l'exégèse est utile (j'ai mis ça car je trouve que ça fait vachement bien dans un article). Cette trouvaille est due à M. James Nakakihara, du courrier des lecteurs dans Amiga World de novembre 1988, page 12. Je m'interroge d'ailleurs sur l'utilité de cette fameuse fenêtre de requête, car un (bon) programmeur mettra dans son programme ce qu'il faut pour traiter l'erreur qui cause le gel du système, alors que l'utilisateur du CLI, auquel il me semble que cette fenêtre de requête est destinée, ne trouve pas dans sa documentation un traître mot sur ce qu'il doit faire face à cette fenêtre. Dans mon expérience, cliquer le gadget "Retry" n'a jamais donné de résultat, et sans GOMF, cliquer "Cancel" a toujours donné un Guru. Disons pour la défense de Commodore que l'Amiga est une machine destinée à un éventail très large d'utilisateurs, et qu'il est bien difficile de contenter tout le monde. Install bénéficie maintenant de deux options : "NoBoot" et "Check". Pas besoin de faire un dessin pour voir qu'Install est devenu un outil antivirus rudimentaire mais utile. Nous en resterons là pour les commandes du répertoire C. Les amateurs de CLI ne seront pas déçus, il y a matière à quelques bonnes soirées au clavier pour tirer la substantifique moelle de tout ceci. Il y a aussi de quoi se faire peur, pour ceux qui aiment. 1.4. Le tiroir "System" ![]() NoFastMem est utile pour faire tourner certains programmes archaïques (attention, ça remonte au plus à 1985, puisqu'avant l'Amiga n'existait pas ; dans notre monde particulier, la préhistoire n'est jamais très loin) qui se trouvaient tout malheureux d'être chargés ailleurs que dans le bas de la mémoire. Je me souviens avoir acheté tout au début de mon expérience de l'Amiga, en juin 1987, un programme qui s'appelait Music Studio, qui a refusé de marcher et que le vendeur a repris sans discuter, alors qu'il suffisait sans doute de faire NoFastMem. FastMemFirst change l'ordre dans lequel l'Amiga va utiliser la mémoire. Rappelons que la mémoire vive est divisée en deux blocs. Un premier bloc de 512 ko (bientôt 1 Mo avec la nouvelle puce Agnus) est le seul bloc auquel les coprocesseurs spécialisés aient accès. Le deuxième bloc, mémoire externe ou sur carte, s'appelle mémoire rapide ou "Fast RAM". Son accès (direct et réservé) au 68000 peut être un peu plus rapide. FastMemFirst change l'ordre d'utilisation de mémoire en mettant à la disposition du système d'abord la mémoire rapide. Il n'est utile qu'avec plus de 1 Mo de mémoire. Je n'ai pas fait d'essais dans ce sens. Il y a encore une commande MergeMem qui permet, dans le cas de l'utilisation de plusieurs cartes d'expansion mémoire, de fusionner les listes de mémoire de plusieurs blocs de mémoire de même type, afin d'accommoder des fichiers plus volumineux. Sur mon système, si je fais :
J'obtiens l'affichage :
Ceci correspond bien à la configuration mémoire existante, et le système me dit qu'on ne mélange pas les torchons et les serviettes. Donc, si j'ai bien compris, ma configuration ne traitera pas de fichiers plus gros que 2 Mo. Dans le tiroir System, il y a toujours "Format", mais avec une option "FFS" (Fast File System) applicable aux partitions de disques durs, nous y reviendrons au chapitre "Performances". Il y a encore FixFonts, qui remet à jour les fichiers ".font" lorsqu'on ajoute ou enlève des polices dans les tiroirs du répertoire "Fonts". 1.5. Le tiroir "Preferences" ![]() On y trouve aussi CopyPrefs, qui permet de recopier au bon endroit de la disquette de démarrage le nouveau fichier "system-configuration" résultant d'une modification des préférences. Tout ceci est très bien, mais ce qui manque cruellement, c'est un utilitaire permettant do choisir un parmi "n" fichiers system-configuration en cliquant une icône ou par un appel simple sous CLI. Pourquoi ? Simplement parce que l'on peut avoir deux imprimantes, ou vouloir à l'occasion imprimer un écran graphique en vertical ou en horizontal sans se livrer à toute la gymnastique de Preferences. Procurez-vous "SetPrefs" (Fish 157) et cette joie ne vous sera plus refusée. Le nouveau programme "Preferences" a été moult fois décrit en divers endroits, son utilisation ne m'a causé aucun problème. 1.6. Le tiroir "Utilities" ![]() ClockPtr. Probablement l'horloge la plus intelligente et la moins perturbatrice qui soit. Je l'ai adoptée après en avoir essayé plusieurs autres. Un certain nombre de programmes d'horloge, en particulier ceux qui font automatiquement revenir l'horloge à l'avant-plan , sont assez dérangeants pour certains autres programmes. Je me souviens d'une horloge de ce genre, qui, même cachée à l'arrière-plan, causait un rafraîchissement de la fenêtre de travail de Textcraft Plus toutes les minutes. Très amusant ! Ici, avec ClockPtr, Commodore a fait le bon choix. CMD pour rediriger la sortie parallèle ou série vers un fichier. InstallPrinter. Une petite gentillesse pour transférer un pilote d'imprimante du disque "Extras" (il n'y avait plus assez de place pour les mettre sur le disque Workbench) sans devoir passer par le CLI. PrintFiles permet d'imprimer plusieurs fichiers. More. Vingt dieux la belle église ! L'ancien More ne permettait le défilement du texte à lire que dans un sens, d'où l'apparition du fameux utilitaire "Less" que l'on trouve partout sur les disquettes Fish pour lire les docs ou les ReadMe. Le nouveau More est superbe ; on peut en bref s'y mouvoir comme dans un bon éditeur. En conjonction avec FF, la vitesse l'impression est vraiment... impressionnante, même à partir d'une disquette. More peut encore effectuer une recherche de chaîne de caractères, et, comme signalé plus haut, appeler par simple pression de la touche "E" l'éditeur que vous avez spécifié grâce à l'unité logique ENV:. Voilà un utilitaire à la hauteur de l'Amiga. GraphicDump a aussi fait sa toilette, il permet de faire une copie graphique de l'écran en quatre tailles fixes et une réglable, et il marche sans problèmes. 1.7. Les gestionnaires ("handlers") Il y a bien entendu le gestionnaire "NewCon" qui permet de faire marcher le Shell. Il y a aussi le "RAD:", nouveau disque virtuel résistant à une réinitialisation à chaud, et qui permet à ceux qui ont la ROM Kickstart 1.3 de faire des réinitialisations ultra-rapides. Ceci a déjà été décrit dans A-News, je n'y reviens pas. Je ne l'ai pas encore fait, n'ayant pas en main la ROM 1.3 au moment où j'écris ces lignes, mais j'ai des commentaires très enthousiastes d'autres utilisateurs. Auparavant, j'utilisais le "recoverable RAM Disk" de ASDG (encore et toujours trouvé dans le domaine public) et il m'a rendu de bons services. J'ai néanmoins installé sans regret RAD: à sa place, il marche très bien, et a résisté à des dizaines de redémarrages suite à des accidents les plus divers. Et enfin d'autres divers gestionnaires : Clips: (assignation pour le clipboard.device), Aux: (pour la série sans tampon mémoire), Speak: (qui sert à "lire" un fichier) et Pipe: (pour transférer des données entre programmes). 1.8. Les bibliothèques Les nouvelles bibliothèques mathématiques doivent permettre de tirer avantage de la présence d'un coprocesseur. Je n'en ai pas, pas de commentaire. 1.9. Les unités logiques ("devices") Il y a, comme déjà signalé, de nombreux pilotes d'imprimantes en plus sur la disquette Extras, mais, ce qui est remarquable, c'est la présence dans le manuel de 16 pages d'information sur les imprimantes, décrivant les fonctions gérées par le pilote et donnant les positions appropriées des commutateurs DIP pour chacune d'entre elles. J'ai même trouvé le pilote qui permet d'imprimer sur une Epson FX-85 la phrase : "L'évêque de Nîmes va çà et là en buvant de la ciguë." Entre nous, essayez ça sur votre imprimante, si tout passe, chapeau ! 1.10. Les polices de caractères ("fonts") Il en a trois nouvelles, Helvetica, Courier et Times. Elles sont jolies, la police "Times" fait très distinguée. Voilà pour les possibilités additionnelles, et je suis sans doute passé à côté d'un certain nombre de choses intéressantes, mais le courrier des lecteurs est là pour quelque chose, à vous de jouer. A noter que les démos graphiques (dots, etc.) ont été supprimées, sans doute pour une raison de place sur la disquette. 2. L'interface utilisateur ou la symphonie inachevée Le Shell, c'est bien, mais il manque un tas de choses :
Retenons toutefois, en guise de transition au chapitre suivant, la nette amélioration de la vitesse d'affichage des textes grâce à FF. 3. La performance Personnellement, je range dans ce chapitre la compatibilité avec 1.2. En particulier, en ce qui concerne FFS, à part quelques programmes anciens ou quelques programmes du domaine public qui s'attachaient davantage à la structure des blocs qu'au principe de gestion des fichiers d'AmigaDOS, tout ce qui marchait sous 1.2 marche sous 1.3. De grandes marques d'ordinateurs, que je ne citerai pas car je travaille pour l'une d'entre elles, se sont attiré la fidélité solide de leurs clients, précisément en assurant la compatibilité des versions successives de leurs systèmes d'exploitation, ce qui protège l'investissement en logiciel de leurs clients. Commodore semble vouloir suivre cette voie pour l'Amiga, nous ne pouvons que nous en féliciter. Au chapitre de la vitesse, j'ai signalé l'effet de FF. Lisez un texte sous le nouveau More, vous serez impressionné. Enfin, les plus gâtés sont les possesseurs d'un disque dur, grâce à FFS (Fast File System). Après avoir formaté une partition de mon disque dur en FFS et constaté que le programme principal de Sculpt-Animate 3D, qui s'appelle "sa" et qui pèse 354 ko, chargeait en moins de deux secondes, j'ai effectué quelques mesures de vitesse, dans une partition formatée en FFS, dans une partition formatée de manière classique, et, par curiosité, dans RAM:. La première série d'essais consiste à mesurer le temps de chargement de deux programmes, l'autre à mesurer le temps nécessaire à la copie d'un fichier, à l'intérieur d'une même partition. De manière à se trouver dans des conditions identiques, je suis parti de deux partitions reformatées. Il est vraisemblable que dans des partitions ayant déjà fait l'objet de nombreuses opérations d'effacement et de réécriture, les temps obtenus seraient un peu plus longs, mais pour que la mesure ait un sens, il faudrait travailler avec des partitions ayant des histoires identiques. Voici les résultats : Chargement d'un programme avec respectivement la RAM:, une partition normale et une partition FFS :
Ceci appelle deux remarques : D'abord, en ce qui concerne les programmes, les gains de temps sont évidemment différents car le chargement du programme ne comporte pas seulement le chargement du code en mémoire, mais aussi des opérations d'initialisation plus ou moins longues. Il est tout de même agréable de voir charger Sculpt-Animate 3D en deux secondes, et Deluxe Paint II en quatre secondes (ce temps comprenant dans le second cas le choix de l'option d'écran ). Enfin, en ce qui concerne la rapidité de manipulation des fichiers, les chiffres parlent d'eux-mêmes. Il s'y ajoute la possibilité d'avoir des commandes résidentes, donc d'exécution rapide, et l'ensemble devient vraiment très agréable d'utilisation. 4. L'impression On se plaignait de la lenteur de l'impression, l'Amiga n'était vraisemblablement pas à l'optimum de ses capacités de pilotage d'une imprimante, celle-ci semblait mème l'attendre. Eh bien maintenant, c'est l'Amiga qui l'attend. Le printer.devise a été réécrit. Mais les améliorations ne résident pas que dans la vitesse, une quantité de paramètres hyper précis peuvent être transmis. Pour cela, il suffit de cliquer dans l'icône "Change Printer" (Modifier l'imprimante) des préférences, et vous découvrirez de vos yeux ébahis qu'il existe maintenant deux modes : Graphic 1 et Graphic 2. Graphic 1 est l'équivalent de Graphic Select sur le Workbench 1.2, mais il dispose de l'option "Gray Scale 2" (Échelle de gris n°2) pour le moniteur A2024 haute définition et qui affiche sept niveaux de gris au maximum. Graphic 2 en est même effrayant de par la multitude de paramètres, on se demande combien de feuilles vont être nécessaires à la définition idéale de ces paramètres... Voici quelques informations pour vous aider :
5. Les cactus Au niveau des bogues, le Workbench 1.3 n'a pas l'air d'en avoir plus que le Workbench 1.2, c'est-à-dire pas beaucoup. Attention toutefois, les ennuis parfois observés quand on travaille sur beaucoup d'icônes à la fois en maintenant la touche "Shift" enfoncée et en cliquant sur plusieurs icônes, ont l'air de toujours être là. En particulier, si après avoir ainsi activé de l'ordre de 6 à 8 icônes, on déplace légèrement la souris en cliquant la suivante, il arrive que tout le paquet d'icônes se mette à clignoter pour un temps plus ou moins long, après quoi il peut se passer différentes choses, dans la plupart des cas, heureusement rien, à part une sueur froide. Avec Workbench 1.2, il m'est arrivé, en utilisant l'option de sélection multiple d'icônes et la fonction "Discard" du Workbench, de voir disparaître toutes les icônes de la fenêtre et bien entendu tous les fichiers correspondants. Prudence donc dans ce domaine. Ce qui est plus savoureux, c'est le mécanisme de l'obtention des disquettes 1.3. Vous allez chez un revendeur avec vos disquettes 1.2, et il est censé vous donner des disquettes 1.3 en échange, gratuitement, ce qui est appréciable et apprécié. Je me suis donc pointé chez un revendeur Commodore, bien sympathique et serviable d'ailleurs, qui m'a proposé de faire moi-même les copies sur un Amiga 500 muni de deux lecteurs de disquette qui se trouvait là. Pas de problèmes, sauf que je me suis trouvé gratifié en prime du virus Byte Bandit. Lorsque je le lui ai fait remarquer, il m'a dit : "Pas étonnant, il y a toute la journée des clients qui viennent faire des copies sur cette machine...". Je lui ai immédiatement fait cadeau d'une copie de la disquette VirusDisk distribuée par Giorgio Cupertino. Commodore a vraiment des clients en or (vous voyez mes chevilles qui enflent) ! Au demeurant, c'est la même chose aux États-Unis, car vous pouvez lire la même histoire dans la documentation de VirusX. Et maintenant, avec les disquettes, on fait quoi sans documentation ? Si vous lisez l'anglais, vous pouvez peut-être vous procurer le manuel, moyennant finances, par l'intermédiaire de votre revendeur. S'il ne l'a jamais vu, en voici les références : Commodore Amiga Enhancer Software featuring AmigaDOS version 1.3 including Kickstart 1.3 Workbench 1.3 Extras 1.3 Ouf ! C'est le titre, il remplit toute la couverture. Comme je l'ai déjà dit, ce manuel est très bien fait, il y a des chapitres explicatifs sur les nouvelles fonctions, et plusieurs exemples de startup-sequence pour réaliser des configurations les plus diverses. Pour ceux qui ont des problèmes avec l'anglais, il faudra prendre patience. Peut-être Commodore France nous fera-t-il la surprise d'une documentation en français pour le 1.4 ? Ce serait un cadeau merveilleux (Bruce Lepper on nous dit que Commodore France est en train de préparer le plus rapidement possible un manuel en français pour la version 1.3). Conclusion D'intéressantes possibilités nouvelles, une performance accrue, un début d'amélioration d'une interface utilisateur dont il ne faudrait tout de même pas oublier que c'était une des meilleures, si pas la meilleure dans la gamme de prix de l'Amiga, le tout sans compromis au niveau de la compatibilité, voilà un bilan très positif, et de quoi attendre le 1.4 sans risquer de s'ennuyer. Bon amusement !
|