amigaos-exec

Contexte 1985 : pourquoi AmigaOS s’est distingué

Au milieu des années 1980, une interface graphique ne constituait déjà plus à elle seule une singularité. Ce qui devenait intéressant, c’était la capacité d’un ordinateur domestique à faire plusieurs choses à la fois sans que l’ensemble du système ne s’effondre. C’est exactement là que l’Amiga s’est distingué : graphisme, audio, interface à la souris et, en même temps, véritable multitâche préemptif sur une machine qui n’était pas tarifée comme une workstation.

Mais le point décisif est le suivant : ce multitâche n’était pas seulement un terme marketing. Il était inscrit dans le cœur même du système. Exec gérait les tâches, les priorités, les ports, les messages et les signaux de manière à permettre à plusieurs composants du système d’être actifs simultanément sans dépendre du bon vouloir coopératif de tous les programmes en cours d’exécution. En 1985, cela n’était pas normal dans le domaine de l’informatique domestique.

En même temps, le système n’était pas monolithique au sens d’un noyau qui engloutit tout. Très tôt, AmigaOS était clairement stratifié : Exec comme noyau, au-dessus les bibliothèques et services système, Intuition pour l’interface graphique, AmigaDOS pour le shell, les systèmes de fichiers et l’espace de noms. Celui qui ne sépare pas ces couches finit par tout décrire de façon imprécise.

« Le véritable progrès n’était pas l’interface. C’était l’architecture en dessous. »

Exec : ce que fait réellement le noyau

Exec est le véritable cœur du système. Pas « tout l’OS », mais la partie qui fournit les mécanismes fondamentaux : gestion des tâches, scheduling, signaux, ports de messages, interruptions, allocation mémoire, ouverture et fermeture des bibliothèques et des devices. On peut décrire Exec comme un petit noyau. Non pas parce que le terme « microkernel » est devenu à la mode plus tard, mais parce que sa véritable mission est concentrée sur ces mécanismes de base.

Exec organise une grande partie de ses structures internes sous forme de listes chaînées. Ce n’est ni un hasard ni un exercice d’élégance. C’est efficace, facile à suivre et cohérent sur une machine 68000 aux ressources limitées. Ready lists, waiting lists, ports, nodes – toute la logique du système est fortement orientée listes.

Ce qui compte avec Exec, ce n’est pas qu’il fasse « beaucoup ». Au contraire : il fait relativement peu – mais exactement ce qu’il faut. Tout ce qui se trouve au-dessus peut s’appuyer sur ces mécanismes de base. C’est la raison pour laquelle le système paraissait si vivant malgré un matériel limité.

Niveau tâche et niveau interruption

Précisément parce qu’Exec gère les interruptions au cœur du système, il faut séparer proprement le contexte de tâche et le contexte d’interruption. Une tâche normale s’exécute comme entité planifiable dans le flux habituel d’Exec. Une interruption, au contraire, interrompt ce flux en réponse à un événement matériel et ne s’exécute pas comme un contexte DOS ou shell ordinaire. Au niveau interruption, d’autres règles s’appliquent : rester bref, éviter les effets de bord inutiles, ne pas introduire de logique DOS et ne pas faire d’hypothèses confortables sur les appels bloquants.

Sur l’Amiga, avec ses interruptions de niveau 1 à 7 et ses custom chips, cela est pratiquement important. L’architecture n’est pas intéressante parce qu’elle « sait aussi faire des interruptions », mais parce qu’elle montre clairement que les événements matériels asynchrones et les tâches planifiables sont deux niveaux distincts. Si on les mélange, un système lisible devient vite illisible.

Tâches, scheduling et priorités

Exec travaille avec des tâches, pas avec des processus fortement isolés au sens moderne. Il n’existe pas de protection mémoire au sens actuel. Cela signifie : le scheduler peut être élégant et rapide, mais un programme défaillant peut malgré tout endommager l’ensemble du système. Ce n’est pas une contradiction, mais la forme réelle de cette machine.

Le scheduler est préemptif. Une tâche en cours n’a pas besoin de céder volontairement le processeur ; Exec peut commuter dès que les conditions sont réunies. À cela s’ajoutent les priorités. Une tâche exécutable de priorité plus élevée prend le pas sur les autres. C’est pratique, mais aussi dangereux : une tâche mal écrite avec une priorité inutilement élevée peut effectivement freiner tout le système.

C’est l’un des traits caractéristiques de l’Amiga : techniquement élégant, mais non paternaliste. Le système aide, mais ne protège pas contre chaque erreur. Il est puissant tant que les acteurs savent ce qu’ils font.

Signaux, ports de messages et messages

L’un des points forts d’Exec est la communication inter-processus. Non pas au moyen de lourds frameworks abstraits, mais directement et efficacement : une tâche peut attendre des signaux ; des messages peuvent être envoyés entre tâches via des ports de messages. Le système reste asynchrone et lisible.

Signaux

Chaque tâche dispose d’un masque de signaux. Les signaux sont des marqueurs binaires sur lesquels une tâche peut attendre via Wait(). C’est la forme de synchronisation la plus légère : « quelque chose s’est produit, continue ». Rien de plus. C’est précisément ce qui les rend utiles.

Ports de messages

Un port de messages est un point d’arrivée pour les messages. Une tâche possède généralement un ou plusieurs ports ; d’autres tâches peuvent y envoyer des messages. En interne, un port contient des listes de messages. Un port n’est donc pas un simple handle, mais un véritable nœud du modèle Exec.

Messages

Les messages sont des structures de données avec un en-tête et une charge utile, envoyées aux ports. Le principe de base est fondé sur les pointeurs : on ne copie pas nécessairement de gros blocs de données ; on transmet des structures. C’est rapide, mais cela exige une logique propre de possession et de durée de vie.

Ce modèle est remarquable parce qu’il est à la fois simple et utile à l’échelle du système. Ce n’est pas une solution spéciale pour une couche graphique quelconque, mais un bloc de base. C’est précisément pourquoi on le retrouve ensuite dans la couche DOS – là toutefois sous une forme spécialisée avec DOS packets et handlers.

Bibliothèques, devices et stratification du système

AmigaOS n’est pas seulement un noyau avec quelques syscalls. C’est un système de bibliothèques et de devices ouverts au besoin. exec.library est la base ; au-dessus se trouvent d’autres bibliothèques comme intuition.library, graphics.library ou dos.library. Cette structure est l’un des traits définitoires du système.

Une bibliothèque n’est pas simplement « supposée présente » ; elle est ouverte explicitement. Cela a des conséquences pratiques : les versions peuvent être vérifiées, l’appelant sait sur quoi il s’appuie, et la stratification reste visible. C’est plus sobre que bien des systèmes ultérieurs qui cachent trop de choses implicitement.

• exec.library : mécanismes fondamentaux – tâches, ports, messages, signaux, interruptions, mémoire.
• intuition.library : fenêtres, menus, gadgets, interaction graphique.
• graphics.library : écrans, bitmaps, primitives de dessin.
• dos.library : shell, accès aux fichiers, espace de noms, communication avec les handlers, processus, redirection, exécution de scripts.

Il est important de distinguer les Exec devices et les devices AmigaDOS. Un Exec device est la couche proche du matériel, comme trackdisk.device ou serial.device. Un device AmigaDOS est la couche espace de noms, comme DF0:, SER: ou CON:. Entre les deux se trouve généralement un handler ou un handler de système de fichiers. Celui qui mélange ces niveaux décrit le système de manière incorrecte.

Tout aussi importante en pratique est la logique d’appariement : OpenLibrary() et CloseLibrary() vont ensemble. Ouvrir explicitement une bibliothèque n’est que la moitié de la vérité ; la refermer proprement plus tard fait partie du même modèle discipliné. Les oublis de CloseLibrary() n’étaient pas de simples fautes esthétiques, mais une vraie source de problèmes progressifs, d’incohérences et d’états désordonnés dans des logiciels de longue durée.

TRIPOS, BCPL et l’origine d’AmigaDOS

La partie DOS proprement dite du premier AmigaOS n’est pas née directement d’Exec, mais d’une autre lignée : TRIPOS et BCPL. C’est important, car nombre de particularités du premier AmigaDOS viennent exactement de là.

TRIPOS était un système d’exploitation portable issu du monde académique, ensuite porté sur le 68000 par MetaComCo. Commodore a utilisé cette base pour le premier AmigaDOS. C’est pourquoi AmigaDOS 1.x était fortement marqué par BCPL. Cela se voit non seulement historiquement, mais très concrètement dans les termes et les types de données.

BPTR et BSTR

BCPL utilise des conventions de pointeurs différentes de celles du C. Un exemple classique est le BPTR : pas un pointeur d’octet ordinaire, mais un pointeur adressé par mot dans le style BCPL. En pratique, cela signifie que les valeurs sont décalées ou mises à l’échelle par rapport aux adresses normales, et qu’on ne peut pas les traiter simplement comme des pointeurs C ordinaires. Il en va de même pour BSTR, c’est-à-dire les chaînes codées par longueur au lieu des chaînes C terminées par zéro.

Cet héritage BCPL était l’une des raisons pour lesquelles le premier AmigaDOS paraissait souvent plus raide, du point de vue du C ou de l’assembleur, qu’Exec. Non pas parce que les idées DOS étaient mauvaises, mais parce que la représentation des données venait d’un autre monde.

Celui qui veut comprendre les API du premier AmigaDOS doit garder cette origine à l’esprit. Sinon, certaines choses paraissent inutilement exotiques alors qu’elles sont simplement cohérentes historiquement.

dos.library et l’espace de noms DOS

dos.library est la couche qui transforme les mécanismes bruts d’Exec en environnement de shell et de système de fichiers utilisable. C’est là que résident l’espace de noms, l’exécution des commandes du shell, l’adressage des handlers, les locks, les file handles, la redirection, la logique de script et les détails de processus. C’est le véritable noyau d’AmigaDOS.

L’espace de noms d’AmigaDOS n’est ni un espace de noms Unix ni un modèle de lettres de lecteurs de type MS-DOS. Des noms comme DF0:, DH0:, RAM:, CON:, SER:, PIPE: ou NIL: sont des noms logiques de devices DOS dans le même espace de noms. À cela s’ajoutent des assigns comme SYS:, C:, S:, L: ou LIBS:. Cet espace de noms est plus souple qu’un modèle rigide à lettres, mais il exige que les termes soient correctement distingués.

• Nom de volume / device : par exemple DH0: ou DF0: – point de départ d’un chemin.
• Assign : alias logique vers un répertoire ou plusieurs répertoires, par exemple LIBS:.
• Cibles DOS fondées sur des handlers : CON:, SER:, PIPE:, NIL: – pas des « fichiers », mais utilisables comme tels dans l’espace de noms DOS.

Cela peut paraître inhabituel au premier abord, mais techniquement c’est propre : tout ce qui se comporte comme une extrémité DOS vit dans le même espace de noms et peut être adressé par la couche DOS. C’est exactement ce qui rend la redirection et la gestion souple des devices si élégantes.

La couche DOS elle-même – avec locks, file handles, assigns, handlers, DOS packets, RUN et EXECUTE – est détaillée sur la page sœur amigados.htm. Ici, l’accent est délibérément mis sur la stratification générale avec Exec en dessous.

Handlers, devices et DOS packets

L’un des points les plus importants est le suivant : vis-à-vis des systèmes de fichiers et des devices DOS, AmigaDOS ne travaille pas directement avec les Exec devices bruts, mais avec des handlers. Un handler est un processus qui traite un ensemble standardisé de requêtes DOS.

Concrètement, cela signifie que lorsqu’un programme appelle Open("DF0:fichier", ...) ou Read(fh, ...), dos.library n’exécute pas elle-même tout le travail lié au système de fichiers. Les requêtes sont envoyées au handler compétent – généralement via un port de messages et sous forme de DOS packets. Le handler traduit ensuite cette requête DOS en opérations de bas niveau appropriées, souvent en utilisant un Exec device comme trackdisk.device.

DOS packets

Les DOS packets sont des structures de messages spécialisées pour les opérations DOS et système de fichiers. On peut les comprendre comme des messages de style Exec avec une structure de paramètres supplémentaire. Pour les programmes ordinaires, l’important est qu’on travaille généralement via dos.library et non en construisant soi-même des DOS packets. Pour les auteurs de handlers, en revanche, ce modèle est central.

C’est un découplage propre. dos.library n’a pas besoin de connaître chaque système de fichiers ou chaque device spécial dans le détail. Il suffit que les handlers comprennent les conventions des packets.

Shell, CLI et modèle de processus

Le shell n’est pas simplement une fenêtre avec un prompt. C’est un processus DOS. C’est ici que la différence entre Exec et AmigaDOS devient particulièrement tangible.

Un Process DOS est plus qu’une tâche Exec. Formellement, on peut le décrire comme une combinaison d’une structure de tâche Exec, d’un port de messages Exec et d’une valeur de processus AmigaDOS. Dans le contexte DOS, l’identifiant interne du processus est le pointeur vers le port de messages Exec pr_MessagePort, à partir duquel on peut retrouver la tâche Exec associée.

C’est crucial, car le shell et l’exécution des commandes vivent exactement à ce niveau. Un shell lit les entrées, évalue la redirection, cherche les commandes dans le chemin de recherche, lance des programmes externes et des scripts, et gère le contexte – répertoire courant, flux ouverts, prompt, codes de retour et autres détails semblables. C’est de la logique DOS, pas de la logique Exec.

CLI, Shell, NewShell, NewCLI

Plusieurs processus shell peuvent exister en même temps. Ils sont numérotés en interne. NEWSHELL ou NEWCLI lance un nouveau processus shell. Ce n’est pas seulement une nouvelle fenêtre, mais réellement un contexte DOS supplémentaire avec son propre état.

C’est précisément pour cette raison qu’AmigaDOS se prête bien aux scripts et à une utilisation en plusieurs shells parallèles. Chaque shell est son propre contexte DOS, et non une simple autre vue d’un état global.

Assigns, locks et file handles

Assigns

Un Assign est un nom logique qui pointe vers un répertoire – ou même vers plusieurs répertoires. LIBS:, C:, S: ou L: sont les exemples classiques. Ainsi, un logiciel n’a pas besoin de savoir sur quel volume concret se trouve une ressource ; il demande simplement LIBS: ou C:.

Il est particulièrement fort que les assigns ne soient pas liés à une seule cible. Avec les options appropriées, un assign peut être étendu à d’autres répertoires. Le système parcourt alors la liste des assigns dans l’ordre. C’est une solution étonnamment flexible pour une machine de cette catégorie.

Locks

Dans AmigaDOS, un lock n’est pas seulement « verrouillé » au sens courant, mais une structure concrète d’accès et de référence. Les locks servent à référencer un objet de manière univoque et à contrôler les accès concurrents. Les distinctions essentielles sont les shared locks et les exclusive locks.

• Shared lock : pour la lecture ; plusieurs peuvent coexister.
• Exclusive lock : pour l’écriture ; les conflits avec d’autres locks sont empêchés.

C’est important, car de nombreuses fonctions DOS ne poursuivent pas seulement avec des chemins en texte, mais s’appuient ensuite en interne sur des locks. Un lock est donc à la fois un mécanisme de protection et un moyen de navigation dans le système de fichiers.

File handles

Un file handle est le canal d’accès actif à un fichier ouvert ou à une extrémité DOS de type flux. Pour le programme appelant, c’est la surface de travail concrète : lire, écrire, se déplacer, fermer. Un file handle est donc le pendant opérationnel d’un lock. Le lock référence et protège ; le file handle travaille activement avec l’objet ouvert.

Il est important que les file handles puissent pointer vers bien plus que de simples fichiers disque. CON:, SER:, PIPE:, NIL: – tout cela peut être ouvert et traité comme une extrémité de fichier au sens DOS. C’est précisément de là que viennent l’élégance de la redirection et la force du shell du système.

Pipes, redirection, Execute et Run

Redirection

La redirection appartient à la couche shell. Avec < et >, l’entrée ou la sortie peuvent être redirigées vers des fichiers ou des devices DOS. Le shell analyse la ligne de commande et fait en sorte que le programme lancé voie d’autres flux d’entrée et de sortie que la fenêtre console d’origine.

PIPE:

PIPE: est un canal de communication à base de handler pour des E/S tamponnées entre programmes. Ce qui est techniquement intéressant, c’est qu’il apparaît comme une extrémité DOS dans l’espace de noms. Pour les programmes qui attendent des entrées et sorties séquentielles, PIPE:name peut se comporter comme un fichier, même si, en arrière-plan, il s’agit d’un mécanisme inter-processus tamponné.

Cela montre à quel point la couche DOS de l’Amiga est forte : un mécanisme de communication n’est pas ajouté comme un cas exotique à part, mais intégré proprement dans le même espace de noms que les fichiers et les devices.

Execute

Execute(), ou la commande shell EXECUTE, appartient à la couche DOS et shell. Execute() exécute une ligne de commande shell. Il faut retenir ceci : la fonction ne revient normalement qu’une fois l’exécution demandée terminée. Ce n’est donc pas le chemin primitif du type « lancer en arrière-plan et oublier ».

En outre, Execute() peut être utilisé avec des file handles appropriés de manière à créer un nouveau contexte shell interactif. C’est précisément pourquoi Execute() a sa place sur une page consacrée à AmigaDOS et non sur une page consacrée à Exec seul.

Run

RUN est la réponse du shell à « lancer en arrière-plan ». La commande charge et démarre un programme ou une activité shell de manière à rendre la main au prompt pendant que le shell courant continue à fonctionner. Ce n’est pas une nouvelle théorie du scheduling – c’est de la logique concrète de processus DOS.

En pratique, un point est important : l’activité lancée reste liée à son contexte d’origine, en particulier pour l’entrée et la sortie, sauf si l’on redirige délibérément vers NIL: ou ailleurs. C’est pourquoi on ne peut pas simplement fermer un shell tant que des processus lancés en arrière-plan sont encore attachés à ses flux.

Guru Alert expliqué précisément

La célèbre Guru Meditation n’est ni seulement un culte, ni seulement un « écran de crash ». Plus précisément, il s’agit d’un mécanisme d’alerte et d’erreur du système. Le nombre affiché est structuré et encode des informations sur la classe d’erreur et le sous-système concerné.

Ce qui compte ici, c’est la vision sobre : un Guru Alert n’est pas un message philosophique et pas automatiquement un débogueur au sens moderne. C’est une alerte système visible et formatée. Dans certains cas, l’erreur est prévue comme récupérable, dans d’autres elle est fatale. Cela dépend de la classe d’alerte.

Un exemple concret

Prenons par exemple une alerte comme 00000003 00000000. Ce n’est pas « juste un nombre culte », mais une valeur d’erreur codée plus un second longword servant de contexte supplémentaire. En simplifiant, la première partie porte l’information d’alerte proprement dite – c’est-à-dire la classe et la zone d’erreur – tandis que la seconde peut fournir un contexte complémentaire, par exemple une autre valeur ou une référence d’adresse.

Le point essentiel n’est pas de mémoriser chaque nombre, mais de comprendre le principe : un Guru Alert était pensé comme un diagnostic structuré. C’est précisément ce qui le rend techniquement plus intéressant que sa réputation ultérieure de simple nom de crash.

Si le Guru Alert reste si fortement mémorable aujourd’hui, ce n’est pas seulement à cause du nom. C’est parce qu’à cet endroit, le système devient visiblement honnête : il ne masque pas une défaillance grave derrière une amabilité générale, il montre qu’un problème fondamental s’est produit.

Dans le contexte classique de l’Amiga, il ne faut pas oublier une chose : sans protection mémoire, une erreur grave d’un programme n’est pas proprement contenue dans la seule tâche fautive. C’est précisément pour cela que les alertes à ce niveau sont systémiquement importantes.

« Un Guru Alert n’est pas une légende. C’est l’énoncé formalisé qu’une chose a déraillé à un point fondamental. »

Ce qui reste remarquable aujourd’hui

Ce qui est remarquable, ce n’est pas seulement que l’Amiga disposait très tôt d’un multitâche préemptif. Ce qui est remarquable, c’est la combinaison d’élégance technique et de lisibilité pratique. Exec en dessous, DOS au-dessus, handlers comme processus intermédiaires, bibliothèques comme couche système explicite, shell et espace de noms comme structure supérieure utilisable – ce n’est pas un chaos développé au hasard, mais une structure reconnaissable.

Il est tout aussi remarquable que cette élégance ne doive pas être confondue avec une architecture moderne de protection. Le système est ouvert, rapide, direct – et donc vulnérable. Il exige de la compétence. En ce sens, AmigaOS n’est pas un système confortable, mais un système honnête.

Pour moi, c’est précisément là que réside sa valeur durable : aujourd’hui encore, AmigaOS / Exec / AmigaDOS permet d’étudier proprement ce qu’est une bonne stratification, comment la communication inter-processus peut rester utilement légère, et pourquoi la logique du shell et du système de fichiers doit exister comme couche propre au-dessus du noyau.

« AmigaOS était fort là où il était stratifié – pas là où l’on jetait tout dans un seul mot. »

La couche DOS en détail se trouve sur amigados.htm. Les systèmes concrets sur lesquels cette architecture devenait perceptible au quotidien se trouvent sur hardware.htm et amiga4000t.htm.