-Chaque module qui veut en appeler un autre repasse la main au gestionnaire, afin que celui-ci vérifie si le module est déjà présent en RAM ou non (gérer tout ça avec une pile d'appels, c'est encore vague dans ma tête mais je pense que c'est faisable). Si le module n'est pas en RAM, il le recopie: il peut facilement connaitre son emplacement s'il a l'adresse par le n° de fonction dans la lib (merci le kernel), ainsi que sa taille (peut par exemple être stockée au début, sous forme (label_fin_module - label_début_module)).

Non. Il faut faire une librarie par module, et regrouper toutes les librairies en un seul pack.
A partir de la tout ce que tu dis est directement possible avec PreOS : il charge / decharge tout seul ce qui n'est plus necessaire quand ce n'est plus necessaire.
Le seul inconvenient est le surcout du header kernel pour les modules.
Mais apres reflexion (pour cf), je me suis rendu compte qu'on ne pouvait pas vraiment faire mieux.

-Toutes les allocations mémoires se font aussi par des fonctions du gestionnaire, afin que celui-ci libère si nécessaire de la RAM en effaçant autant de modules que
nécessaire, sauf le module courant (voire ceux marqués inneffaçables... à voir).

Simple: tous tes modules ne definissent pas de variables globales dynamiques mais font reference au gestionnaire principal (Et la PreOS te reloge correctement ton module).
Par ailleurs tu peux ajouter un systeme de cache (comme j'ai fait pour cf2 ) pour accelerer largement le tout.

-Impossibilité pour chaque module de conserver des données, vu qu'il peut être déchargé à tout instant. Le launcher doit donc s'occuper de créer un handle, et de réserver un registre d'adresse constamment pour que chaque module ait de la place pour aller écrire ce qu'il veut (handle, diverses données, bref toutes les variables habituelles).

Pas si tu les stockes dans ton launcher.
Le launcher a un nom de librarie (par exemple 'laucnher').
Dans launcher.asm:
launcher@0000: dc.l 0

Dans ton module chargé :
move.l laucnher@0000,d0
etc

PreOS reloge tout ca correctement (mais >= 0.70 seulement).

-Inconvénient majeur, que je ne sais pas comment contourner sans hack du format de fichier défini par PpHd (Kernel Format Vx), c'est la question des relogements... :'( Et donc là, pas de BSS et pas de lib dynamique...

Les BSS c'est niet. Desole

D'ailleurs à ce sujet, si tu passes par là PpHd, tu pourrais décrire comment tu gères l'attribut correspondant ?

PreOS ne deprotege pas la flash. Mais si on lui demande d'executer un programme readonly archivé, il va pas broncher, et il va l'executer en flash.
(Donc un autre programme peut deproteger la flash).

Et les RAM calls, ils marchent comment? Ils sont résolus en temps d'éxécution ou quand PreOS reloge le programme?

Au moment de la relocation.

PreOS ne permet pas l'exécution en Flash, parce que sous AMS c'est moyennement possible

Pourquoi moyennenement ?

Donc à priori on aurait $(3ff-100+1)/4=192 traps disponibles à partir de $100. Je ne me trompe pas?

Sur TI, ca fait parti de la pile superviseur.