squale92 a écrit :
Tu ne considère pas le kernel comme indispensable.
et il ne l'est pas pour faire tourner une bone partie des progs dispo.
(INDISPENSABLE)
mais il est nécessaire, du moins, pour moi.
Je détaille:
Nous avons vite compris (je mets "nous" parce que c'était plus ou moins la même chose pour moi) que programmer en
_nostub n'est en rien plus difficile que programmer en mode kernel. Personnellement, c'était en me lançant dans la programmation de TSRs (en assembleur, je précise) que j'ai découvert le mode
_nostub, parce qu'il était clairement (et correctement) dit dans les documentations qu'il n'est pas possible d'écrire un TSR en mode kernel à cause de la libération automatique des handles. J'ai donc appris la programmation en mode
_nostub (qui à l'époque était assez exotique, surtout en assembleur) et j'ai vite vu qu'il était tout aussi simple pour le programmeur que le mode kernel. (D'ailleurs, la programmation en
_nostub est devenue de plus en plus facile avec l'évolution de
TIGCCLIB.) La documentation de
TIGCCLIB m'a fait comprendre que les librairies comme
graphlib,
userlib,
filelib,
util,
linelib, ... n'étaient rien d'autre qu'un gaspillage de place énorme, parce que presque toutes les fonctions qu'elles proposaient (et c'est toujours le cas!) avaient un équivalent en
ROM_CALL. (D'ailleurs
RUNPROG I qui utilisait
userlib::runprog était nettement plus gros que
RUNPROG II qui est en
_nostub et qui utilise plusieurs
ROM_CALLs à la place.)
Par conséquent, les kernels ne sont pas indispensables pour le programmeur. Et si les programmeurs apprennent à s'en passer, ils ne seront pas indispensables pour l'utilisateur non plus. C'est d'ailleurs pour ça que je suis parfois aussi intolérant envers ceux qui programment en mode kernel: il suffit d'
un seul programme pour kernel pour que l'utilisateur ait besoin d'un kernel, c'est pour ça que
tous les programmes doivent être en
_nostub!
))
Tout ceci parce que mon trap #4 appelle le trap #11 de AMS, et que je ne savais pas que celui-ci détruit d7. Heureusement que j'ai remarqué le bogue juste avant la sortie prévue de PreOs 0.62, ce qui m'a permis de demander à PpHd de retarder la sortie de quelques heures afin d'attendre la mise à jour de h220xTSR, ce qu'il a fait.)
