Folco (./134) :
Ca apporte quelques dizaines d'octets supplémentaires
Où "quelques dizaines" est de l'ordre de grandeur de 100 ou 1000 (c'est-à-dire au moins 1 KO supplémentaire). Rien que les headers kernel consomment 50 octets pour chaque morceau, ensuite chaque export consomme 2 octets, et les appels à LibsBegin etc. prennent de la place aussi, bref je ne vois pas du tout comment tu fais tes calculs...
pour gagner des kilos.
Des kilos là où ça ne sert pas (comme je l'ai déjà expliqué), en RAM pendant l'exécution, alors que la place supplémentaire est consommée en archive en permanence et réduit donc le nombre de logiciels qu'on peut mettre sur la calculatrice en même temps.
Je ne vois pas ce que vient faire ton overhead négligable.
Il ne l'est pas.
Kernel. SMA, CF, et en tout cas la grande majorité sont en kernel (ya qu'à voir les vieux sites de la fin des années 90, xop, nop etc...). Peu de jeux sont sortis après en proportion.
N'importe quoi, regarde un peu les jeux les plus populaires: TI-Chess (214608 téléchargements sur ticalc.org!), Ice Hockey 68k, Super Mario 68k etc., tout du _nostub!
SMA et CF consomment beaucoup trop de place en archive (on ne peut mettre rien d'autre sur la calculatrice si on a un modèle avec seulement 2 MO de FlashROM!), donc presque personne n'y joue. CF consomme aussi trop de RAM: dès qu'on installe un TSR ou une FlashApp, ça ne tourne plus, et il y a des problèmes de mémoire même avec rien d'autre que PreOs et CF avec les AMS les plus récents! Qu'on consomme 1 KO ou 150 KO n'a aucune importance en pratique, mais entre 150 et 192 KO, ça change énormément de choses, parce que c'est ce qui fait la différence entre un jeu qui marche et un jeu qui ne marche pas! De plus, CF est bogué, et c'est normal, c'est une bêta qui n'a jamais été finalisée!
Argument faible : regardons le programme le plus mal écrit et faisons comme lui. Le jour où tous les codeurs se donneront trois minutes de réflexion par programme pour cette question, ton argument sera complètement obsolète. 
Tu n'as toujours pas compris la différence entre ton monde des rêves (où tout le monde programme comme tu le conçois) et le monde réel! Les jeux comme CF qui consomment toute la RAM ne disparaîtront pas du jour au lendemain, et même en allant moins dans l'extrême, il y a par exemple TI-Chess qui a besoin de 100 KO, de même que beaucoup d'autres jeux, donc ça ne sert strictement à rien en pratique de consommer moins de 100 KO. Quand tu dépasses 100 ou 150 KO, c'est là que tu devrais te préoccuper de la consommation de RAM, mais avant, ça ne sert absolument à rien.
Et sinon, tu veux mettre quoi dans la RAM ainsi économisée? Des fichiers? Au prochain plantage, pouf!
Des TSRs? Je vois mal comment tu veux remplir 192 KO avec seulement des TSRs! ...
En fait tu me croyais assez con pour aller chercher le fichier dans la RAM, choper son handle et faire un kernel::exec dessus ? 
Non, un LibsBegin sur un fichier externe.
Pour un programme PedroM-only, tu t'en fous peut-être (mais du coup ton programme ne vise pas grand monde), mais je te signale que sous AMS, si tu fais un pack archive de 60 KO, ton programme aura besoin d'au moins 60 KO en RAM, parce qu'au moment de l'exécution, un twin est créé, et même si PreOs libère le twin (le fait-il?), ce sera trop tard, les 60 KO auront déjà été consommés. Le programme ne se lancera même pas si tu n'as pas au moins 60 KO de libres! Pour écrire un programme qui ne consomme qu'1 KO sous AMS, il faut donc au moins 2 fichiers (lanceur et pack archive). C'est aussi une des raisons pour lesquelles les PPGs fonctionnent avec 2 fichiers (lanceur et PPG).
n'importe quel programme peut tourner sous PedroM dans 300 bytes
Et ça ne sert strictement à rien dans le monde réel.
(EDIT: Les headers kernel, c'est 50 octets, pas 50 KO, évidemment.)
(même si tout dépend de la taille de la pendule, évidemment)
(même si tout dépend de la taille de la pendule, évidemment)
)
