TIGCC :: Lib kernel? - Page 4

lol heureusement que vous avez quelques différents sinon on pourrait croire que c'est le même

Vous venez du même forum, vous postez dans les même topic pour défendre les mêmes idées (avec les mêmes arguments foireux ). Donc forcément votre liste doit se ressembler. Mais cherche donc quelqun d'autre sur le forum qui soit de votre avis
Quand tu auras fini je pourrais faire pareil, et on en déduira simplement qui pose le plus de probleme

P.S : Celui qui à chaque fois qu'un projet ou une idée ne vient pas de la TICT se jette dessus en lui trouvant tous les défauts du monde, c'est moi ?

Kevin Kofler
a écrit : Pas toujours. Par exemple, la TICT (Thomas et Lionel) préfère la compilation séparée pour les différents modèles de calculatrices, alors que moi, je préfère la compatibilité on-calc.

lol, autant dire que vous avez les memes idées alors

Moi, je suis contre les débats kernel/nostub en général, mais force m'est de reconnaitre que j'eus longtemps des problèmes dans les débuts des kernels et librairies (entre doors OS et uniOS, sans compter les multiples versions des libs et du shell doors explorer). Mais depuis, PreOS uniformise le tout, et la plupart des progs kenel fonctionnent bien (kirby exepté, d'ailleurs on se demande pkoi il utilise une vielle version de preOS)

Mais je suis moi aussi pour la compatibilité on-calc, et aussi pour la compatibilité linguistique en basic

kirby fonctionne chez moi

Il y a juste le bug a la sortie qui sera corrigé dans la prochaine version mais qui n'a absolument rien a voir avec le kernel

Kevin Kofler a écrit :
Euh... À la limite, ça devrait être tolérable même dans TIGCC Programming, mais dans ce cas, la limite de ce qui est accepté dans le topic sera bien plus stricte.

Bon, ok pour Off-topic.

Non, c'est le contraire: même si les librairies dynamiques en général sont apparues après les librairies statiques, elles sont techniquement inférieures. J'ai déjà dit pourquoi:

1. La caractere 'easy to use' n'a rien a voir avec la technologie employee.
2. Faire un linkage a l'execution est plus complexe qu'un linkage a la compilation, et necessite une techno superieure.

Voilà une bonne raison pour laquelle les librairies statiques sont plus pratiques.

Mais meme pour une lib statique, c'est deconseille. Ne serait ce que lorsqu'on melange des .h et des .a de differentes versions (Ca m'est deja arrive, et c'est pas beau).

Tant pis. Si on programme en assembleur, il faut être prêt à adapter légèrement son code si on utilise une nouvelle version de ses librairies. Ou alors on continue à utiliser l'ancienne version, ça ne dérangera personne.

Pourquoi faudrait-il adapter son code assembleur ?
Surtout que le gain est faible.

Sûr? Tu as dit toi-même que dans genlib, certaines parties de l'ABI et même de l'API pourraient être améliorées.

Oui. J'ai pris de l'experience depuis. Mais globalement je suis quand meme satisfait de ce que j'ai fait. Ca a pu evoluer sans grosses contraintes.

Version qui a de bonnes chances d'être incompatible avec la version 1 dans les 2 sens, vu qu'il y a "un tout nouveau concept dans l'approche des fonctionnalites de la librairie". Donc 2 copies (entières, pas seulement partielles comme pour les librairies statiques) de la librairie on-calc. N'est-ce pas exactement ce que la librairie dynamique est censée empêcher?

C'est bien pour ca qu'il faut avoir de l'experience pour eviter de refaire des versions incompatibles sans arret.
Du point de vue pratique, je ne connais aucune librarie qui a connu cela.

"Régulièrement" dans le sens de "périodiquement". Mais pas extrêmement fréquemment. S'il va voir chaque mois, ça suffit. Et puis, personnellement, j'envoie souvent des mails aux utilisateurs de h220xtsr.a pour leur rappeler de mettre à jour h220xTSR. Tu as déjà pu le voir d'ailleurs. Ça résout plus ou moins ce problème-là.

Il faut le faire. Il faut y penser.

* Même chose pour une librairie dynamique.
* Peu probable si la librairie est bien faite.

Faux car une librarie dynamique DOIT garantir la compatibilite de l'ABI.
Ou alors c'est elle qui a tord, et pas toi. Tu peux te retourner contre elle.

1 minute.

Plus tous les trucs d'imcompatibilite.

Personnellement, je teste moi-même, et si ça marche, c'est bon. S'il y a un problème, qu'on me le reporte et je le corrigerai, souvent le même jour.

Mais ce n'est pas suffisant.

Un message ici et un sur le forum de la TICT. 5 minutes.

Et si ce message disparait rapidement du forum a cause d'une actualite surchage ?

Moi, ça me prend 1 heure au pire.

Parce que tu n'utilises pas beaucoup de librarie statique independante de ta volontee.

Et avec une librairie dynamique:
* c'est l'utilisateur qui se tape les étapes 1-3
* en cas de problèmes, le programmeur se tape les étapes 4-8 exactement comme pour une librairie statique. Et cela même si la nouvelle version de la librairie dynamique ne lui apporte rien! Alors que pour une librairie statique, il se tape les étapes 4-8 seulement si la mise à jour lui apporte quelque chose.

1. C'est l'administrateur que le fait. Il peut y avoir un administrateur par classe par ex.
2. C'est moins frequent que pour une lib statique. Par exemple, Genlib n'a pas bouge en 3 ans.

En général, l'utilisateur ne met à jour que s'il y a un problème. Et dans le cas d'une librairie statique, il sait quoi mettre à jour: le programme qui pose problème. Dans le cas d'une librairie dynamique, il doit mettre à jour le programme et toutes les librairies que ce programme utilise (y compris le kernel) pour être sûr que le problème n'est pas dû à l'utilisation d'anciennes versions.

Un probleme peut survenir sans que l'utilisateur ne l'ait encore vu. S'il sait qu'un bug grave (par exemple, une corruption du certificat) est suceptible d'arriver dans une lib statique. Il voudra mettre a jour ces programmes. Que peut-il faire avec des libs statiques ? Rien, il ne peut rien faire !

Seulement si la mise à jour entraîne un problème. Si les librairies sont bien faites, ça a peu de chances de se produire. Et encore une fois, c'est la même chose avec les librairies dynamiques: là aussi, il faut essayer toutes les combinaisons pour voir quelle librairie est à l'origine du problème.

Mais les libs dynamiques imposent plus de contraintes que les libs statiques, donc elles sont moins soumises au changement.

Je parle des programmes publiés, pas de ceux faits pour l'usage personnel. S'il a toujours un kernel sur sa calculatrice, il peut programmer en mode kernel pour son usage personnel et ça ne dérangera personne. Ce sont les programmes sortis publiquement qui devraient être en _nostub. Même si personnellement, je programme toujours en _nostub.

Rien que pour cela, c'est une raison suffisante d'avoir une version kernel.

Ce n'est pas un bon argument parce que la différence de vitesse n'est pas telle qu'elle ait une vraie importance.

Mais c'est un argument. POINT.

Non. Il n'y avait pas de système de .a dont seulement les fichiers objets vraiment utilisés seront automatiquement linkés.

On pouvait le faire a la main. Ca ne changeait guere d'une compil a l'autre.

Tu étais souvent fatigué alors.

mea culpa, alors.

C'est bien ce que je critique: le manque de sérieux...

C'est l'esprit mediterraneen ca ! Tu devrais revenir en Italie plus souvent

Non, c'est le problème des librairies dynamiques.

Heureusement qu'il y avait le smiley.

Non franchement, ce n'est pas le problème d'une des 2 méthodes, mais du mélange de ces 2 méthodes. Il n'y a pas de problème avec les librairies statiques seules (chaque programme utilise sa version et il n'y a pas de conflits). Avec les librairies dynamiques seules, il peut y avoir des problèmes de compatibilité entre programmes et librairies dynamiques (contrairement aux librairies statiques, où chaque programme utilise la version de la librairie pour laquelle il est prévu), mais en mettant une partie de la librairie en statique, ces problèmes sont pratiquement garantis.

Cela depend de ce que l'on met en statique. Et frnachement il y a peu de chance si on a bien defini l'ABI.

Il y en a plusieurs:
* devoir installer le kernel à chaque reset
* devoir mettre à jour le kernel régulièrement

C'est vraiment genant a ce point la ?

Et dans le cas d'utilisation de librairies dynamiques, il y a aussi les désavantages d'utilisabilité des librairies dynamiques.

Moi j'y vois des avantages.

Encore un néologisme.

C'est pas de moi ! Ca existe vraiment dans l'industrie, et ca signifie grosso merdo 'couche intermediaire entre l'hard et le soft'. J'ai pas exactement compris la difference avec le systeme d'exploitation.

Qu'est-ce qui "prend beaucoup de place"? Le code de démarrage? Le header de commentaires et autres données?

Le tout.

Je croit (si je me trompe pas) que le terme midware est utilisé quand il y n'y a pas d'os en tant que tel (genre un automate etc...)

Affirmation restante a vérifier..

Un problème avec les libs dynamiques, c'est la gestion des versions...
Ce n'est pas tous les utilisateurs finaux qui updatent les programmes (valable aussi pour les programmes utilisant des libs statiques linkées en interne, mais ceux-là ne posent pas de problèmes de compatibilité avec d'autres versions de la lib dynamique, évidemment ).
L'année dernière, j'ai découvert sur une calculette d'un de mes camarades de lycée (dans l'autre classe de Terminale S). Il y avait DoorsOS II 0.95, de très vieilles versions de softs comme Solar Striker ou TI-Chess (il avait encore un TI-Chess 2.0 !), une partie de la panoplie de softs kernel qui plantent souvent avec DoorsOS (tunnel, frogger...). Matthieu Gallet m'a dit qu'il avait aussi découvert des antiquités.

Les updates ne se font pas, à moins d'avoir quelqu'un qui s'y connaisse bien en TI (et encore, pour les updates de kernel, il faut que celui qui s'y connaît bien soit pro-kernel, ce qui n'est pas mon cas...). Réponse à "Ca plante souvent": "C'est normal, c'est kernel."

arf, enfoiré ("C'est normal, c'est kernel.")
moi g mis preos sur des calcs de gens de mon ecole qui avaient doorsos et qui connaissaient pas unios

L'année dernière, j'ai découvert sur une calculette d'un de mes camarades de lycée (dans l'autre classe de Terminale S). Il y avait DoorsOS II 0.95, de très vieilles versions de softs comme Solar Striker ou TI-Chess (il avait encore un TI-Chess 2.0 !), une partie de la panoplie de softs kernel qui plantent souvent avec DoorsOS (tunnel, frogger...)

Si on a de vieux jeux nostub on a encore plus de chance que ca ne marche pas que de vieux jeux kernel donc le problème de compatibilité est le même.

PpHd
a écrit : 1. La caractere 'easy to use' n'a rien a voir avec la technologie employee.

Si. Une bonne technologie est une technologie facile à utiliser.

2. Faire un linkage a l'execution est plus complexe qu'un linkage a la compilation, et necessite une techno superieure.

Ce n'est pas parce que c'est plus complexe que c'est mieux.

Mais meme pour une lib statique, c'est deconseille. Ne serait ce que lorsqu'on melange des .h et des .a de differentes versions (Ca m'est deja arrive, et c'est pas beau).

C'est surtout pas malin...

Pourquoi faudrait-il adapter son code assembleur ?

Parce que les programmeurs assembleur se comptent sur le doigt d'une main de nos jours.
Oui, j'en fais partie, mais personnellement, ça ne me dérange pas de modifier quelques lignes pour m'adapter à un changement d'ABI tant que ça n'arrive pas trop souvent. Si on est trop paresseux pour le faire, on n'a qu'à programmer en C.

Surtout que le gain est faible.

Mais il existe quand-même.

C'est bien pour ca qu'il faut avoir de l'experience pour eviter de refaire des versions incompatibles sans arret. Du point de vue pratique, je ne connais aucune librarie qui a connu cela.

Sur calculatrice peut-être, mais c'est parce qu'il n'y a que très peu de librairies dynamiques. Sur PC, cf. libstdc++... Non seulement l'ABI du compilateur change sans arrêt, mais la librairie elle-même aussi. Et la version qui accompagne GCC 3 est très différente de celle qui accompagnait GCC 2.

Il faut le faire. Il faut y penser.

Mais c'est le boulot de l'auteur de la librairie, pas celui du programmeur qui l'utilise.

Faux car une librarie dynamique DOIT garantir la compatibilite de l'ABI. Ou alors c'est elle qui a tord, et pas toi. Tu peux te retourner contre elle.

Et la librairie statique est censée garantir la compatibilité de l'API. Si tu recompiles et que ça ne marche pas, il y a un problème.

Plus tous les trucs d'imcompatibilite.

Il ne devrait pas y en avoir.

Mais ce n'est pas suffisant.

Pour moi oui.

Et si ce message disparait rapidement du forum a cause d'une actualite surchage ?

Il aura quand-même été lu.

Parce que tu n'utilises pas beaucoup de librarie statique independante de ta volontee.

D'un côté, tu as raison. h220xtsr.a et tigcc.a ne sont pas vraiment indépendantes de ma volonté. h220xtsr.a est entièrement en mon contrôle, et pour tigcc.a, je peux opposer un changement s'il me pose un vrai problème. D'un autre côté, tu as tord: même si la librairie n'est pas en ton contrôle, elle n'est quand-même pas censée te faire travailler plus qu'une simple recompilation.

1. C'est l'administrateur que le fait. Il peut y avoir un administrateur par classe par ex.

Ce sont quand-même des milliers de personnes à devoir faire le travail plutôt qu'une seule.

2. C'est moins frequent que pour une lib statique. Par exemple, Genlib n'a pas bouge en 3 ans.

Et TIGCCLIB garde la compatibilité source depuis qu'elle existe.

Un probleme peut survenir sans que l'utilisateur ne l'ait encore vu. S'il sait qu'un bug grave (par exemple, une corruption du certificat) est suceptible d'arriver dans une lib statique. Il voudra mettre a jour ces programmes. Que peut-il faire avec des libs statiques ? Rien, il ne peut rien faire !

Tu me montreras la librairie susceptible de corrompre les certificats. Je ne l'ai jamais vue. Et c'est tellement improbable que je ne pense pas qu'un plantage puisse faire ça.

Mais les libs dynamiques imposent plus de contraintes que les libs statiques, donc elles sont moins soumises au changement.

Faux.
Je n'ai jamais vu un auteur de librairie statique sur calculatrice se dire: "Tiens, on va rajouter un halo blanc à tous les grands sprites. Tant pis si les auteurs comptaient sur le fait qu'il n'y a pas d'effets artificiels de ce genre..."

Rien que pour cela, c'est une raison suffisante d'avoir une version kernel.

Non. La version _nostub marche sur toutes les TI-89/92+/V200.

On pouvait le faire a la main. Ca ne changeait guere d'une compil a l'autre.

C'est quand-même lourd. J'en ai fait l'expérience en portant Backgammon pour Fargo (cf. topic Backgammon, dès que j'aurai fini de poster ça). J'ai bien eu ld-tigcc sous la main (donc en théorie le support des librairies statiques), mais ça ne m'a pas servi vu que j'ai été obligé de porter les fonctions dont j'avais besoin une par une.

Cela depend de ce que l'on met en statique. Et frnachement il y a peu de chance si on a bien defini l'ABI.

Il y a beaucoup de chances... On ne peut en général pas couper une librairie en 2 de cette manière.

C'est vraiment genant a ce point la ?

Oui.

Moi j'y vois des avantages.

Est-ce un avantage de devoir récupérer la version à jour de chaque libraire séparément au lieu de mettre à jour le programme et d'avoir les librairies qu'il utilise mises à jour automatiquement?

C'est pas de moi ! Ca existe vraiment dans l'industrie, et ca signifie grosso merdo 'couche intermediaire entre l'hard et le soft'. J'ai pas exactement compris la difference avec le systeme d'exploitation.

Même toi, tu ne comprends pas le terme, donc...

Le tout.

Le header de commentaires prend très peu de place. Une vingtaine d'octets. Le header kernel, lui, prend une cinquantaine d'octets sans compter le stub.
Quant au code de démarrage, il prend un peu plus de place, mais seulement si on a besoin de ses fonctionnalités. Il est normal que les fonctionnalités prennent de la place. Pour les fonctionnalités qu'il offre, le code de démarrage de TIGCCLIB est très compact.

> moi g mis preos sur des calcs de gens de mon ecole qui avaient doorsos et qui connaissaient pas unios
Moi pas Ils ne connaissaient pas UniversalOS, mais ça n'est pas pour ça que j'ai mis PreOS (qui n'était pas encore à la 0.62/0.64, plus stables que la 0.52 que j'ai fait planter (je ne sais plus quel crash) en quelques minutes sur VTI...)

> Si on a de vieux jeux nostub on a encore plus de chance que ca ne marche pas que de vieux jeux kernel donc le problème de compatibilité est le même.
Des arguments techniques, s'il te plaît ?

Uther Lightbringer
a écrit : Si on a de vieux jeux nostub on a encore plus de chance que ca ne marche pas que de vieux jeux kernel donc le problème de compatibilité est le même.

Pas du tout. CBlaster et CReversi étaient seuls programmes en assembleur/C à fonctionner sur HW2 AMS 2 dès le départ. Comme par hasard, ils étaient en _nostub.

Kevin> effectivement, CBlaster et CReversi utilisaient à fond les propriétés de la calc (routines de fonts custom, etc...)

Voilà pourquoi je dis toujours d'utiliser DrawStr plutôt que des hacks bizarroïdes. Autre solution: si vraiment on a besoin des adresses des fontes, il faut les récupérer avec la méthode officielle (OO_GetAttr). Mais ça n'existait pas quand CBlaster et CReversi étaient écrits, donc DrawStr et le buffer rempli par des boucles de DrawChar étaient les 2 seules solutions propres. Celle des kernels n'est pas propre!

Tu penses vraiment qu'un viewer de texte par exemple, s'il était conçu au moment d'AMS 1, utiliserait DrawStr?

Il était censé utiliser:
a) DrawStr ou
b) la solution choisie au départ par le TICT eBook Reader: on affiche dans un buffer en RAM avec une boucle de DrawChar.
Les 2 méthodes sont propres.

... et les 2 méthodes sont horriblement lentes. Je crois que nous n'avons malheureusement pas la même vision des choses...

TXTRider utilises les fontes de boot.

Et c'est bien ce que je lui reproche.

Pollux
a écrit : ... et les 2 méthodes sont horriblement lentes. Je crois que nous n'avons malheureusement pas la même vision des choses...

La méthode d'origine du TICT eBook Reader (il utilisera bientôt OO_GetAttr sur AMS 2 et une lecture d'adresses dans DrawStr sur AMS 1 - la méthode pour AMS 1 est un hack, mais comme AMS 1 n'évolue plus, ce n'est pas grave) n'est pas "horriblement lente". Elle prend quelques millisecondes au démarrage, mais c'est la même chose pour la recherche des fontes dans la ROM avec la méthode utilisée par le kernel.

Il va utiliser une fonte perso ?

Non, il va récupérer l'adresse de la fonte dans les ACB sur AMS 2 et dans DrawStr sur AMS 1.

pkoi il n'a pas fait ca avant en utilisant la méthode des kernels ?

Parce que:
* c'est sale
* c'est également lent lors de l'initialisation
* ça récupère les fontes du boot, pas celles utilisées par AMS

XDanger a écrit :
Un problème avec les libs dynamiques, c'est la gestion des versions...
Ce n'est pas tous les utilisateurs finaux qui updatent les programmes (valable aussi pour les programmes utilisant des libs statiques linkées en interne, mais ceux-là ne posent pas de problèmes de compatibilité avec d'autres versions de la lib dynamique, évidemment ).

Ben il faut un administrateur.

L'année dernière, j'ai découvert sur une calculette d'un de mes camarades de lycée (dans l'autre classe de Terminale S). Il y avait DoorsOS II 0.95, de très vieilles versions de softs comme Solar Striker ou TI-Chess (il avait encore un TI-Chess 2.0 !), une partie de la panoplie de softs kernel qui plantent souvent avec DoorsOS (tunnel, frogger...). Matthieu Gallet m'a dit qu'il avait aussi découvert des antiquités.
Les updates ne se font pas, à moins d'avoir quelqu'un qui s'y connaisse bien en TI (et encore, pour les updates de kernel, il faut que celui qui s'y connaît bien soit pro-kernel, ce qui n'est pas mon cas...). Réponse à "Ca plante souvent": "C'est normal, c'est kernel."

Il faudrait que tu dises: "c'est normal. C'est un vieux kernel". Dis la verite quand meme.

Kevin Kofler a écrit :
Si. Une bonne technologie est une technologie facile à utiliser.
Ce n'est pas parce que c'est plus complexe que c'est mieux.

Stop ! Je te parle du niveau technologique a utilise.
Evidemment qu'une secreatire est mieux qu'un traitement de texte.

C'est surtout pas malin...

Ca arrive !

Parce que les programmeurs assembleur se comptent sur le doigt d'une main de nos jours.

Pas tant que ca.

Oui, j'en fais partie, mais personnellement, ça ne me dérange pas de modifier quelques lignes pour m'adapter à un changement d'ABI tant que ça n'arrive pas trop souvent. Si on est trop paresseux pour le faire, on n'a qu'à programmer en C.

Forcement, ca va pas encourager a programmer en asm ca...

Sur calculatrice peut-être, mais c'est parce qu'il n'y a que très peu de librairies dynamiques. Sur PC, cf. libstdc++... Non seulement l'ABI du compilateur change sans arrêt, mais la librairie elle-même aussi. Et la version qui accompagne GCC 3 est très différente de celle qui accompagnait GCC 2.

que veux-tu que je dises a part que c'est mal concu ?
Et qu'en penses plus faire du C++ avec des libs dynamiques et pas une tres bonne idee (Car les definitions des classes changent sans arret => Bon plantage).
Faut etre rigoureux. Encore plus en C++

Et la librairie statique est censée garantir la compatibilité de l'API. Si tu recompiles et que ça ne marche pas, il y a un problème.

a condition d'utiliser le bon compilo (Ex: tigcc v0.93 a v0.94).

Il aura quand-même été lu.

Pas par tous ceux que ca auraient pu interresser.

D'un côté, tu as raison. h220xtsr.a et tigcc.a ne sont pas vraiment indépendantes de ma volonté. h220xtsr.a est entièrement en mon contrôle, et pour tigcc.a, je peux opposer un changement s'il me pose un vrai problème. D'un autre côté, tu as tord: même si la librairie n'est pas en ton contrôle, elle n'est quand-même pas censée te faire travailler plus qu'une simple recompilation.

Oui. Mais y'a une chance neanmoins.

Ce sont quand-même des milliers de personnes à devoir faire le travail plutôt qu'une seule.

Ca serait tellement mieux.

Et TIGCCLIB garde la compatibilité source depuis qu'elle existe.

Pas tout a fait... Y'a des trucs qui disparaissent

Tu me montreras la librairie susceptible de corrompre les certificats. Je ne l'ai jamais vue. Et c'est tellement improbable que je ne pense pas qu'un plantage puisse faire ça.

...
Un code de corruption de certificat ne prend pas plus d'une centaine d'octets...
Bonjour la protection de chez ti
C'est une des raisons qui me poussent a mettre PedroM.

Faux.
Je n'ai jamais vu un auteur de librairie statique sur calculatrice se dire: "Tiens, on va rajouter un halo blanc à tous les grands sprites. Tant pis si les auteurs comptaient sur le fait qu'il n'y a pas d'effets artificiels de ce genre..."

Forcement je suis le seul a l'offrir cet technologie. Et tout le monde (sauf, a la rigueur, Pollux) a ete d'accord.

Non. La version _nostub marche sur toutes les TI-89/92+/V200.

Mais il a fallu la patcher.

C'est quand-même lourd. J'en ai fait l'expérience en portant Backgammon pour Fargo (cf. topic Backgammon, dès que j'aurai fini de poster ça). J'ai bien eu ld-tigcc sous la main (donc en théorie le support des librairies statiques), mais ça ne m'a pas servi vu que j'ai été obligé de porter les fonctions dont j'avais besoin une par une.

Ca n'a rien a voir !
Et tu aurais pu les prendre des sources de PedroM

Il y a beaucoup de chances... On ne peut en général pas couper une librairie en 2 de cette manière.

Mais suffit de mettre des fonctions qui n'utilisent que la lib dynamique ou que du calcul simple.

Oui.

Alala.

Est-ce un avantage de devoir récupérer la version à jour de chaque libraire séparément au lieu de mettre à jour le programme et d'avoir les librairies qu'il utilise mises à jour automatiquement?

Oui. Plus de flexibilite. Toi utilisateur est libre de les mettre a jour.

Même toi, tu ne comprends pas le terme, donc...

C'est la couche entre system d'exploitation et application.

Le header de commentaires prend très peu de place. Une vingtaine d'octets. Le header kernel, lui, prend une cinquantaine d'octets sans compter le stub.
Quant au code de démarrage, il prend un peu plus de place, mais seulement si on a besoin de ses fonctionnalités. Il est normal que les fonctionnalités prennent de la place. Pour les fonctionnalités qu'il offre, le code de démarrage de TIGCCLIB est très compact.

Mon header kernel est + petit...

-"c doux, c'est neuf ? "
-"Non, c'est un prgm nostub"

Kevin Kofler a écrit :
La méthode d'origine du TICT eBook Reader (il utilisera bientôt OO_GetAttr sur AMS 2 et une lecture d'adresses dans DrawStr sur AMS 1 - la méthode pour AMS 1 est un hack, mais comme AMS 1 n'évolue plus, ce n'est pas grave) n'est pas "horriblement lente". Elle prend quelques millisecondes au démarrage, mais c'est la même chose pour la recherche des fontes dans la ROM avec la méthode utilisée par le kernel.

Et bonjour la compatibilite PedroM !!!!
Et dire que je comptais mettre un max d'ebook !!
Merci !!