 |
Mardi 03 juin 2025 - 04:54 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Note : traduction par David Brunet.
...qu'aurait été l'Amiga avec son DOS originel ?
Andy Finkel est le directeur actuel du département "Amiga Software" chez Commodore. Il a été impliqué dans les machines Commodore depuis la période précédant la sortie du VIC-20.
Comme la plupart d'entre vous le savez déjà, AmigaDOS n'était pas le premier choix du DOS/système de haut niveau pour l'Amiga. Ce que nous appelons maintenant AmigaDOS était vraiment un DOS de remplacement, basé sur un système d'exploitation connu sous le nom de Tripos (article 1, article 2). Celui-ci fut développé au laboratoire informatique de l'Université de Cambridge par le Tripos Research Group, et converti sur Amiga à une vitesse incroyable par le Dr Tim King et son équipe de programmeurs de chez MetaComCo. Quand le DOS d'origine conçu pour l'Amiga échoua à se matérialiser (ceci serait d'ailleurs une histoire intéressante à raconter), l'Amiga fut lancé avec AmigaDOS. Le reste appartient à l'histoire.
De temps en temps, on rappelle que le DOS d'origine est écrit selon les spécifications d'origine. Cela fut même raconté par certains membres de l'équipe Amiga, mais la direction d'Amiga décida qu'il ne serait pas possible d'achever le DOS et de l'intégrer à temps dans l'Amiga, d'autant plus que les ingénieurs logiciels avaient déjà fait une croix sur leurs week-ends en famille. Ils ne rentraient plus chez eux... et ne dormaient plus non plus.
Il demeure une grande question... comment aurait été l'Amiga si nous avions gardé le DOS d'origine ? Quel aurait été le caractère de l'Amiga ? La vie aurait-elle été parfaite ?
Il n'y a vraiment aucun moyen de le savoir, évidemment. Mais si je m'arrêtais ici, nous aurions un article très court, non ? Alors pourquoi ne pas jeter un coup d'oeil sur les spécifications de ce DOS d'origine, et peut-être même faire une petite comparaison avec AmigaDOS ?
Ces questions intéressent grandement les développeurs, et une petite mention de CAOS sur Usenet a provoqué une vague de courriers électroniques demandant davantage de détails (ils voulaient les spécifications). J'ai donc décidé de rédiger cet article, cela m'a semblé plus amusant que l'article sur lequel je travaillais précédemment ("Un Guide pour DOSBase" ou "Pourquoi cette bibliothèque est-elle différente de toutes les autres ?"). Dans l'idéal, cet article aurait dû être rédigé par une des personnes de l'équipe Amiga ayant travaillé sur CAOS (principalement Carl Sassenrath, auteur également d'Exec) durant des temps immémoriaux (cela remonte à 1984). Ils furent cependant silencieux sur ce sujet durant tout ce temps, j'ai donc utilisé la version prototype (sur une station Sage, très difficile à mettre en route). Les spécifications données ici proviennent de la documentation provisoire de CAOS.
Commodore Amiga Operating System
CAOS signifie "Commodore Amiga Operating System". Son but était le suivant (phrase tirée de la documentation) :
"C'est un système d'exploitation petit et complet, fonctionnant sur une petite (mais géniale) machine destinée au marché grand public. Son principal but n'est pas de fournir un environnement sophistiqué de développement logiciel, mais plutôt de fournir une base pour des programmes agréables et utiles. Cela ne veut pas dire qu'il néglige les besoins du programmeur. Extérieurement, il est destiné aux utilisateurs finaux. Mais en interne, il a été conçu pour prendre en charge les demandes complexes de la plupart des applications. Il offre de riches fonctionnalités supplémentaires pour un système d'exploitation de sa catégorie."Les buts de CAOS sont :
- La fonctionnalité.
- La convivialité (interfaces interne et externe faciles à utiliser).
- La programmabilité (langage interactif par lot, riche ensemble de fonctions pour le programmeur).
- L'extensibilité (modulaire et extensible).
- La fiabilité.
- La performance.
- La taille (raisonnablement compact).
- La maintenance.
Cela vous semble familier, non ? Oui, c'est vrai. AmigaDOS dépend d'Exec pour les mêmes fonctions.
Qu'aurait donné CAOS ? Qu'en est-il du multiprocessus, du système de fichiers, de la gestion de la mémoire et des commandes ? En gros, ce sont les mêmes choses que nous offre AmigaDOS (et ce n'est pas étonnant car AmigaDOS dût prendre la place de CAOS). Cependant, CAOS et AmigaDOS disposent de leurs propres atouts. Par exemple, CAOS fournit également une gestion étendue de la mémoire par rapport à ce que propose AmigaDOS, sans compter qu'il aurait été capable de faire du pistage de ressources.
Il y a au moins trois domaines intéressants à examiner concernant CAOS : le multiprocessus, le système de fichiers et la gestion de la mémoire. Il y a aussi les commandes projetées, utiles pour bidouiller avec des fichiers et des opérations similaires.
Nous pourrions commencer par les deux thèmes les plus simples : le multiprocessus et la gestion de la mémoire. Vous vous demandez peut-être pourquoi le multiprocessus fait partie des plus simples ? C'est parce qu'il ressemble beaucoup (du moins dans ses grandes lignes) au multiprocessus sous AmigaDOS.
Processus
Les processus CAOS sont construits autour des tâches Exec. CAOS dépend fortement des structures de données et des primitives de contrôle d'Exec pour le multiprocessus (cela vous semble familier, non ?). Une structure de processus CAOS est construite par-dessus une structure de tâche Exec. Exec gère le changement de contexte, la communication intertâche, la synchronisation, la mise en file d'attente et l'exclusion mutuelle. Comme avec AmigaDOS, seuls les processus peuvent communiquer avec le système de fichiers.
La structure Process de CAOS contient (tout comme la structure Task) des informations sur sa pile, le code du programme, les données du programme, le pistage des ressources et le code d'exception (je le répète mais à l'exception du pistage des ressources, cela ressemble beaucoup aux informations des processus AmigaDOS, non ?).
Le pistage des ressources est une différence très importante. CAOS fut conçu pour conserver une liste contenant des blocs de ressources utilisés par le processus : blocs de contrôle de fichiers, blocs d'entrées/sorties, ports de messages, bibliothèques, utilisation de la mémoire, données partagées, superpositions, etc. (le développement de cette partie de CAOS prit du retard sur le reste, ce qui peut expliquer que nous ne disposons même pas d'un aperçu actuellement).
Les processus s'exécutent en mode utilisateur, en utilisant une pile unique (style mode utilisateur). A l'exception des changements de contexte, qui fonctionnent en mode superviseur (en utilisant la pile superviseur) et bien sûr les interruptions, tout allait rester en mode utilisateur. Les routines du système d'exploitation se comportent bien (elles ne dérangent pas la pile) et utilisent des quantités bien définies d'espace de pile (elles n'allouent pas de grands espaces pour les variables locales ou récursion). C'est une grande différence car AmigaDOS fait un usage intensif de la pile pour ses opérations. Tant pis.
Il existe trois façons de créer un processus :
- Le créer à partir de zéro, en allouant de nouvelles structures de données et de code.
- Le cloner à partir du processus parent, en créant de nouvelles structures de données, mais en partageant le code du parent.
- Le relier au parent, et le remplacer.
- Allouer la structure de processus.
- Allouer la pile.
- Ouvrir l'entrée, la sortie et l'erreur standard.
- Charger le code et le rendre prêt à l'exécution (le relocaliser).
- Charger les données statiques.
- Traduire le fichier de paquet (s'il existe) et créer un bloc de contrôle de paquet.
- Précharger le fichier de paquet.
- Initialiser les vecteurs d'exception.
- Ajouter la tâche à la liste des tâches d'Exec (avec AddTask), ce qui le met dans la file d'attente pour exécution.
Gestion de la mémoire
Une autre tâche importante que CAOS était censée effectuer est la gestion de la mémoire. En regardant le système d'exploitation actuel, on peut noter qu'Exec dispose d'un riche ensemble de primitives pour gérer la mémoire. CAOS possède des fonctionnalités supplémentaires absentes d'AmigaDOS (d'autres sont présentes).
En gros, CAOS offre des régions de mémoire bien gérées. Dans ces régions de mémoire, le gestionnaire de mémoire de CAOS règne en maître (c'est comme s'il pouvait capturer une partie de la mémoire avec l'appel Exec "AllocEntry"). CAOS gère alors la mémoire dans cette sous-région, allouant des secteurs pour le code, les données, la pile du programme et ainsi de suite. Évidemment, la mémoire peut se fragmenter. Étant donné que le chargement par diffusion (NDT : "scatter-loading") ne faisait pas partie (lors de la publication des spécifications) de la conception du DOS, le gestionnaire de mémoire de CAOS a besoin d'un moyen pour faire face à la fragmentation. Si une sous-région mémoire se fragmente, alors CAOS essaye d'effectuer une collecte et un compactage des fragments de mémoire de ces régions. Il commence par supprimer les sous-régions marquées comme candidates au recouvrement. Si cela ne permet pas de retrouver suffisamment de mémoire, les sous-régions sans utilisateurs (par exemple des bibliothèques et des périphériques logiques avec un compte d'accès à zéro) sont supprimées. Si cela échoue également, un point d'entrée spécial est appelé pour les sous-régions localisables et non rechargeables. Si cela échoue encore, alors l'utilisateur a la visite du gourou (ou voit s'afficher une requête pour mémoire insuffisante).
Lorsqu'un programme doit gérer la mémoire dans les sous-régions allouées par CAOS, le programme manie la mémoire en termes de segments. Les segments peuvent être relocalisables ou fixes, permanents ou réutilisables. Dans le cas où la mémoire devient insuffisante, le gestionnaire de mémoire de CAOS essaye de compacter les segments relocalisables et de supprimer les segments réutilisables. Les segments non relocalisables sont maintenus ensemble en haut ou en bas d'une région, afin d'éviter une défaillance catastrophique de l'algorithme de relocalisation/compactage du gestionnaire de mémoire.
Les segments peuvent aussi subir une sorte de forme d'échange : ils peuvent être lus ou écrits à partir d'un fichier disque pré-alloué.
Croyez-le ou non, la SegList d'AmigaDOS dispose de presque autant de fonctionnalités. A part le type de segment de relocalisation et du gestionnaire de mémoire, vous pouvez pratiquement faire de même avec les SegLists.
Le système de fichiers de CAOS
Nous arrivons maintenant à la chose difficile : le système de fichiers. Il s'agit de l'élément qui devrait différer le plus d'AmigaDOS. Proposer un système de fichiers est la chose la plus importante que doit fournir un système d'exploitation de disque.
CAOS utilise un concept de fichiers comme AmigaDOS. Un fichier étant un objet de données abstrait, avec un ensemble normalisé de méthodes d'accès, qui apparaît à l'utilisateur en tant que flux de données cohérent, quel que soit son format de stockage. Beaucoup de systèmes informatiques reposent sur ce concept.
CAOS gère quatre types de fichiers : les fichiers ordinaires, les fichiers de répertoire, les fichiers image et les fichiers spéciaux.
Un fichier ordinaire est utilisé pour le stockage de données. Les données peuvent être de n'importe quelle nature : ASCII, binaire, peu importe. Il n'y a pas de structure imposée par le système sur le contenu d'un fichier ordinaire.
Les fichiers ordinaires sont également typés afin d'aider CAOS et l'utilisateur à comprendre le contenu des fichiers. Un fichier ordinaire peut être typé comme contenant des informations graphiques, du texte, un code de programme ou des données de programme. Dans le cas d'un fichier ordinaire de type texte, la seule limite imposée est qu'aucune ligne de texte ne doit dépasser 512 octets.
Un répertoire est un fichier utilisé pour représenter les noms de fichiers en données réelles. Ils sont traités différemment des fichiers ordinaires en ce sens qu'il existe une structure imposée par le système pour leur contenu et qu'ils sont protégés contre l'écrasement. Un répertoire peut contenir le nom d'un autre fichier répertoire, et ainsi de suite : un système d'arborescence de fichiers est géré.
Les fichiers image fournissent une méthode symbolique de liaison aux objets de données internes du système. CAOS aurait utilisé ces fichiers pour donner un accès de type "système de fichiers" aux objets internes du système comme les bibliothèques, les périphériques logiques, les chaînes d'interruption, etc. Cela aurait permis l'existence d'une méthode de haut niveau standard pour traiter ces objets de bas niveau. Le système de fichiers aurait agi comme un espace d'adressage symbolique.
Les fichiers image sont considérés comme une "option", des fichiers de pseudo-devices spéciaux auraient été utilisés à la place. Cependant, j'aime vraiment ce concept. C'est l'un des concepts ingénieux que j'aimerais avoir avec le DOS actuel (et je pense que j'ai trouvé un moyen de réimplémenter cela dans AmigaDOS).
Les fichiers spéciaux sont traités comme des fichiers ordinaires, mais ne représentent généralement pas une interface vers un périphérique de stockage. Ils sont utilisés pour fournir un accès standard aux périphériques d'entrées/sorties.
CAOS gère les noms de fichiers jusqu'à 30 caractères maximum. Un chemin peut être spécifié en utilisant le caractère "/". Les chemins absolus (du volume racine) et relatif (du répertoire courant) sont gérés. Le nom de fichier "." (un point) est réservé et se réfère au répertoire actuel. Le nom de fichier ".." (deux points) est également réservé, il se réfère au parent du répertoire spécifié ou courant. Enfin, un chemin (en incluant le nom du fichier) ne peut pas dépasser 255 caractères.
CAOS gère les liens matériels et les liens symboliques. Un lien matériel est juste un pointeur vers la structure de données interne d'un fichier (en fait, un répertoire sous CAOS est un tableau de liens matériels). Un lien symbolique fait référence à un fichier en utilisant le nom du fichier et en effectuant un remplacement de texte. Par exemple, si un programme demande au système de fichiers d'ouvrir un fichier appelé "library" (qui est en fait un lien symbolique vers "/exec/lib/library"), le système de fichiers va remplacer le nom "/exec/lib/library" avant de procéder à l'ouverture du fichier.
CAOS conserve des informations utiles sur les fichiers, par exemple un champ de description (jusqu'à 255 caractères d'information à titre de référence), la date de création, la date de mise à jour, le nombre de liens, les autorisations (lecture, écriture, exécutable, verrouillage), le type (répertoire, imprimable, non imprimable, etc.), l'identifiant de l'utilisateur, la taille, les blocs alloués au fichier. Les fichiers image et les fichiers spéciaux peuvent ne pas conserver toutes les informations. Les informations par défaut sont renvoyées lorsqu'un programme interroge le système de fichiers sur l'un de ces fichiers.
Les fichiers peuvent être ouverts pour les opérations de lecture ou d'écriture. Les opérations sur les blocs et les caractères sont gérées. Vous pouvez aussi rechercher n'importe quel octet dans un fichier ordinaire. On ne peut cependant pas faire cela avec des fichiers image et des fichiers spéciaux.
Les répertoires système comme "/" (la racine), "/dev" et "/Exec" sont des répertoires spéciaux dans lesquels le système conserve généralement ses fichiers spéciaux, ses fichiers image, etc.
Jetons un oeil sur les limites imposées par CAOS (c'est toujours un bon moyen de comparaison). La taille maximale d'un fichier est d'un mégaoctet, la longueur maximale d'un nom est de 30 caractères. La taille maximale d'un chemin (avec le nom) est de 255 caractères (mais aurait pu être fixée à 512 s'il y avait eu suffisamment de demandes). Le nombre maximal de fichiers est fixé au quart du nombre de blocs (environ 440 sur une disquette), le nombre maximal de fichiers ouverts est de 16 par processus, et la longueur maximale d'une substitution de texte d'un lien symbolique est la même longueur qu'un chemin.
Fonctions et commande du système de fichiers
Il existe trois types d'opération pour les fichiers :
- Accès aux fichiers de haut niveau (sécurisé, simple).
- Opérations de bas niveau sur les fichiers, qui fonctionnent directement sur le bloc de contrôle des fichiers (les fonctions de niveau supérieur se délèguent en appels sur ces routines de bas niveau).
- Les opérations de maintenance (les utilitaires).
Les opérations de fichiers basées sur les descripteurs sont le moyen le plus facile d'accéder au système de fichiers. Vous ouvrez un fichier en utilisant un nom (et un chemin), et en retour vous obtenez un descripteur, que vous utilisez pour toutes les opérations de fichiers suivantes.
Les fonctions sont :
- Open (ouvrir).
- Close (fermer).
- Read (lire).
- Write (écrire).
- Seek (chercher).
- EOF (fin de fichier).
- Size (retourne la taille du fichier en octets).
- Truncate (tronquer).
- Update (mettre à jour - écrit tous les tampons mémoire sur le périphérique qui comporte le fichier).
- Name (nom - retourne un pointeur au nom du fichier).
- Options (options).
- Lock (verrouiller - empêcher l'accès simultané).
- Unlock (déverrouiller - déverrouille le fichier précédemment verrouillé).
- LastError (dernière erreur).
- Control (contrôle - contrôle d'accès aux fichiers).
Les méthodes d'accès haut niveau aux fichiers décrites ci-dessus reposent sur une méthode d'accès de plus bas niveau encore que les blocs de contrôle de fichiers. Les fonctions utilisant le bloc de contrôle de fichiers sont :
- MapFile (passer d'un descripteur à un bloc de contrôle).
- OpenFile (ouvrir fichier - à un nom donné on renvoie un bloc de contrôle de fichiers).
- CloseFile (fermer fichier).
- ReadFile (lire fichier).
- WriteFile (écrire fichier).
- Update (mise à jour).
Programmes/utilitaires
Les programmes sous CAOS auraient été assez similaires à ceux que nous avons sous AmigaDOS (sauf bien sûr que la syntaxe de type Unix aurait été utilisée). Nous aurions eu Link (programme pour créer des liens), SoftLink (pour créer des liens symboliques), Remove (pour supprimer), Rename (pour renommer), FileInfo (pour avoir des informations sur le fichier), SearchDir (pour rechercher un répertoire), CurrentDir (pour avoir le répertoire courant), ChangeDir (pour changer de répertoire), MakeDir (pour créer un répertoire), etc.
Autres fonctions relatives aux fichiers
Comme AmigaDOS, CAOS gère les volumes afin de représenter de façon logique les disques, les périphériques, les partitions, les réseaux et la structure de la mémoire. On peut accéder aux volumes quand ils sont connectés. Les volumes pour les disques et les réseaux sont activés quand leur structure d'identification de volume a été lue et vérifiée (pour les disquettes, cela se fait automatiquement quand la disquette est insérée). Et lorsque l'accès à un volume est terminé, le volume devient soit absent, soit déconnecté ou est dans une situation critique (comme quand apparaît une requête du genre "Vous devez replacer *Nom du volume* dans un lecteur").
CAOS conserve les informations d'identification des volumes, comme le nom (jusqu'à 30 caractères), la description, la date et le statut de la protection en écriture. En utilisant le type de fichiers "spécial", il est possible d'accéder directement à un volume. Dans le cas d'une disquette, le fichier spécial donne le même type d'accès (mais d'une manière standard au système de fichiers) comme si le trackdisk.device était utilisé directement.
CAOS hors service ?
Voici donc un rapide aperçu de CAOS. Admettons qu'il soit disponible de nos jours : qu'aurions-nous à gagner ? Personnellement, je pense que l'on aurait un système beaucoup plus intégré. En jetant un oeil sur ses spécifications, vous pouvez voir qu'AmigaDOS est vraiment aussi puissant qu'aurait dû être CAOS. Le problème est qu'AmigaDOS est différent du reste du système d'exploitation. CAOS, de son côté, aurait utilisé le même type de structures de données que le reste du système d'exploitation, le même type de pile, les mêmes langages (C et assembleur) et aurait facilité la compréhension du système.
Lien
- Documentation de CAOS préservée sur Archive.org.
|
