PpHd (./122) :
Tout çà parce que j'ai voulu faire une release de qualité et pas à la va-vite. Surtout que la deadline réelle du point de vue utilisateur, c'était septembre, et il est sorti début septembre.

La Titanium était sortie aux USA en juillet et le semestre commence à la mi-août dans beaucoup d'états US.

Si un nouveau kernel doit sortir le jour, parce que preos c'est has been, ben il supportera ces fonctionnalités.

Peut-être, peut-être pas...

Je vais finir par l'implanter même si ca double la taille de preos ce truc. Plus sérieusement, je ne l'ai pas fait parce que ca double pratiquement la partie résidente de preos (en plus de lui faire dépasser 8K ce qui est le maximum possible pour un kernel).

Hmmm, serait-il possible de déléguer une partie du travail de décompression et relogement à stdlib comme pour la décompression des packs archives?

Mais je ne comprends pas trop pourquoi ça pose tellement de problèmes de place dans PreOs alors que cette décompression est suffisamment compacte pour aller dans le code de démarrage de certains programmes _nostub (grands avec beaucoup de relogements) et économiser quand-même de la place. Et aussi dans la petite mémoire de la TI-92 I (Fargo).

Sinon, des relogements au format MLink peut-être? Le dernier ld-tigcc gère ça pour les programmes _nostub, ça compresse un peu moins bien, mais le code de décompression est nettement plus petit.

Et les plug-ins permettant de faire évoluer les fonctionnalits ?

Une architecture à plug-ins sur TI, ça ne fait que des fichiers de plus à envoyer, il vaut mieux tout linker dans l'exécutable, et comme ça on évite aussi les problèmes de protection.

Et sinon, il est possible de faire une application scriptable en TI-BASIC (en exportant des fonctions C/ASM aux scripts TI-BASIC), ce qui ne crée pas de problèmes de protection et ce qui permet de coder les scripts on-calc. Le désavantage, c'est qu'il faut là aussi des fichiers externes et que le TI-BASIC est lent.