> Le but du Kernel est, si je me souviens bien de l' "epoque" des debuts de DoorsOS, de fournir a LA GLOBALITE des programmes présents sur la calc des features faciles d'acces et tres facilement comprehensibles pour les débutants en ASM
Même s'il apporte maintenant plus que ça, le kernel-based reste en effet en partie le mode de compatibilité avec les kernels (Fargo) des TI-92, sur lesquelles il n'y avait pas d'accès facile aux ROM_CALLs. Des réinventions souvent buggées de la roue ont été faites (l'horrible filelib - elle est maintenant stable, mais ça n'a pas toujours été le cas).
Sur les modèles plus modernes, ce n'est vraiment plus le cas: l'API est facilement accessible. Et franchement, utiliser les fonctions de la VAT, ce que la majorité des programmeurs fait, n'est pas plus compliqué que d'utiliser celles de filelib, qui les copient.
> Alors quand j'entend parler des fonctions "inutiles" ou plutot "inutilisées" des libs asm ca me fait frémir
> De quelle maniere etes vous capables de prévoir ce qu'un utilisateur peut posseder ou non sur sa calculatrice ?!
Bêtement statistique: selon ce qu'un programme fait, on sait à peu près ce qu'il utilise; on sait plus ou moins la proportion de programmes similaires...
Regarde les fonctions proposées dans Genlib: très peu de programmes utilisent les fonctions de dessin de triangle, de cercle, etc. Si c'est un programme qui n'a pas besoin de vitesse, les fonctions d'AMS vont très bien. Seuls certains moteurs 3D utilisent des triangles remplis - et il n'y en a pas 36, de tels moteurs 3D. Le wire frame est plus courant, mais il reste que ce n'est pas la majorité des programmes qui utilise des routines rapides de dessin de ligne (pour l'interface des menus, DrawLine suffit bien !).
Un programmeur gère en général son clavier et son link tout seul, sans passer par des fonctions comme celles de Genlib (surtout que le link de Genlib est mal fait, PpHd le marque lui-même dans la doc). C'est plus vrai en C qu'en ASM, mais beaucoup de programmeurs ne programment que peu, voire pas du tout, en ASM, car c'est plus difficile. Voir entre bien d'autres Malcolm Smith (TRgenius), Travis Fischer (Fisch2).
> Si ya des stats existantes alors je veux bien les voir mais ... je doute.
L'instabilité chronique de DoorsOS, qui reste très connu, et la montée en puissance parallèle du mode de programmation natif de la machine, ont rendu le kernel beaucoup moins utilisé que ce qu'il ne l'était au départ. Ce forum est à peu près le seul où on rencontre des programmeurs en kernel-based. A l'international, c'est différent. Une partie des utilisateurs de kernels n'utilise un kernel que comme anti-"ASAP or Exec string too long" et protection anti-crash - mais pour ça, il y a KerNO, qui est beaucoup plus petit et consomme beaucoup moins de RAM.
Rappel: "kernel", pour désigner ce que ça désigne, est aussi inapproprié que "_nostub" pour AMS native. Il faudrait dire quelque chose comme "surcouche de compatibilité Fargo/DoorsOS et d'ajout de fonctions (reprises pour certaines en AMS native)".