Kernel et Nostub: pourquoi en préférer un plutot que l'autre? - Page 3

freka a écrit :
il ne faut pas se borner a denigrer a tout prix parce qu'on est pas d'accord sur certains points, j'ai vu des exemples et contres exemples completement debile, juste pour contredire... Le seul avantage que l'on peut tirer de ce genre de discussion, est de se sentir un peu moins con, en voyant que les personnes qu'on estime ne le sont pas moins que soi-meme.

Je ne suis pas d'accord avec toi... le seul qui dénigre et qui est fermé ici c'est Kevin, meme TiMad a posté quelque chose de tres sensé et bien construit, avec des idées nouvelles, donc tu vois ça ne sert pas à rien.

De plus il n'y a eu aucun dérapage, aucune tension, donc aucune raison de fermer le topic.

je le vois pas comme ca, tu vois ca comme une discussion, moi de l'exterieur, je le vois comme une dispute, certe pas mechante, mais une dispute qui n'arrete jamais

personellement, je cherche a contredire kevin sur tous les points parce qu'il m'énerve a toujours VOULOIR avoir raison, regarde mon premier post dans ce topic...

freka
a écrit : je le vois pas comme ca, tu vois ca comme une discussion, moi de l'exterieur, je le vois comme une dispute, certe pas mechante, mais une dispute qui n'arrete jamais

Non faut vraiment pas le voir comme ça... on a peut etre des divergences de points de vue, mais ça ne veut pas dire qu'on ne s'entend pas. Et c'est la meme chose entre PpHd et Kevin.

Et j'ajouterais pour finir que je suis d'accord avec TiMad sur le fait qu'il devrait y avoir quelques librairies standardisées sur la TI, ça permettrait d'économiser pas mal de place sans pour autant s'encombrer de fichiers inutiles. Par contre, les mettre dans AMS présente beaucoup d'inconvénients et je ne pense pas que ce soit la solution idéale.

Faut demandera ti de mettre plusieurs API defini par nous-meme dans la prochaine rom ca c'est l'idée

Et puis Kevin n'est pas si ferme : il a participe au developement de preos et il a ajoute les numeros de versions dans obj2ti. C'etait tres sympa de sa part.

comme quoi, même en étant borné sur le nostub, il pense qd même au bien être de la communauté

Perso je vois que des avantages a la mettre en rom...
Mais si ca plait a personne, j'utiliserai un espace de 64ko libre qqpart
mais c'est beaucoup moins propre...

Les trous à $21...... ?

moi j'approuve Timad, pourquoi ne pas utiliser ces 40 KO de libres ? surtout pour xlib ça serait un grand avantage je trouve

Des choses telles que ceci ne sont pas tolérables (et l'auteur de ceci n'est pas le seul visé):
'Votre refus d'ajouter les ROM_CALLs des derniers AMS dans la bibliothèque de TIGCC afin de garder la compatibilité 1.0x, c'est pas "un boulet" ?'
Avant de réagir, je tiens à remercier Kevin pour avoir dit que j'avais participé à la documentation.
Vous serez autorisés à critiquer la documentation de TIGCC et les routines de TIGCC de manière destructive (car les suggestions constructives sont toujours les bienvenues), quand vous en aurez fait chacun autant que Kevin et moi (autrement dit, plus d'une cinquantaine de fonctions d'AMS 2.xx, et un grand nombre de routines d'AMS, notamment les routines sur les long longs faites par Kevin pour ne citer qu'elles)...

Ceux qui me critiquent: plutôt que de se préoccuper de la communauté, en documentant des fonctions qui pourraient être utiles à d'autres programmeurs, ils font des kernels et des choses du même genre, des trucs qui ne marchent pas sur VTI (même si il paraît que c'est résolu maintenant), contrairement à TIGCC qui est tant critiqué.

(Si ceci en froisse quelques uns, c'est un peu fait pour. Ca fait longtemps que je retiens ce que je veux dire: j'édulcore régulièrement mes posts à propos du débat kernel/_nostub avant de les envoyer. Celui-ci n'a pas échappé à la règle).

sBibi
a écrit : personellement, je cherche a contredire kevin sur tous les points parce qu'il m'énerve a toujours VOULOIR avoir raison, regarde mon premier post dans ce topic...

Et toi, tu m'énerves parce que tu veux toujours m'attaquer personnellement (comme tu viens de l'avouer) au lieu de participer à la discussion de manière objective ou bien te taire.

Nitro
a écrit : Et j'ajouterais pour finir que je suis d'accord avec TiMad sur le fait qu'il devrait y avoir quelques librairies standardisées sur la TI, ça permettrait d'économiser pas mal de place sans pour autant s'encombrer de fichiers inutiles.

Je ne suis pas d'accord, moi.

Par contre, les mettre dans AMS présente beaucoup d'inconvénients et je ne pense pas que ce soit la solution idéale.

Là par contre oui, je suis entièrement d'accord. Il vaut mieux une DLL _nostub normale qu'une saleté qui traffique AMS.

freka a écrit :
Faut demandera ti de mettre plusieurs API defini par nous-meme dans la prochaine rom ca c'est l'idée

PpHd
a écrit : Et puis Kevin n'est pas si ferme : il a participe au developement de preos et il a ajoute les numeros de versions dans obj2ti. C'etait tres sympa de sa part.

J'ai quand-même eu des motivations pratiques:
- J'ai participé à PreOs parce que c'est le seul kernel compatible avec mon h220xTSR.
- J'ai mis les numéros de version dans Obj2ti pour éviter que les gens migrent de Obj2ti vers MakePrgm (et donc de TIGCC vers les outils de développement de PreOs) juste pour les numéros de version.
Mais je suis content que vous appréciez ces contributions.

XDanger a écrit :
Des choses telles que ceci ne sont pas tolérables (et l'auteur de ceci n'est pas le seul visé):
'Votre refus d'ajouter les ROM_CALLs des derniers AMS dans la bibliothèque de TIGCC afin de garder la compatibilité 1.0x, c'est pas "un boulet" ?'
Avant de réagir, je tiens à remercier Kevin pour avoir dit que j'avais participé à la documentation.
Vous serez autorisés à critiquer la documentation de TIGCC et les routines de TIGCC de manière destructive (car les suggestions constructives sont toujours les bienvenues), quand vous en aurez fait chacun autant que Kevin et moi (autrement dit, plus d'une cinquantaine de fonctions d'AMS 2.xx, et un grand nombre de routines d'AMS, notamment les routines sur les long longs faites par Kevin pour ne citer qu'elles)...
Ceux qui me critiquent: plutôt que de se préoccuper de la communauté, en documentant des fonctions qui pourraient être utiles à d'autres programmeurs, ils font des kernels et des choses du même genre, des trucs qui ne marchent pas sur VTI (même si il paraît que c'est résolu maintenant), contrairement à TIGCC qui est tant critiqué.

Je voulais rajouter que si absolument vous voulez programmer vos propres routines, il serait sympa de nous demander ce qui reste à implémenter dans TIGCCLIB au lieu de coder la 36000^{ème *} librairie graphique dynamique qui ne sert à rien.

* = J'exagère évidemment!

(Si ceci en froisse quelques uns, c'est un peu fait pour. Ca fait longtemps que je retiens ce que je veux dire: j'édulcore régulièrement mes posts à propos du débat kernel/_nostub avant de les envoyer. Celui-ci n'a pas échappé à la règle).

Moi aussi, je dois souvent me retenir pour rester poli. Vous remarquerez que je n'utilise pratiquement jamais des smilies comme "" et pourtant j'en aurais souvent envie.

Que pensez vous de la rapidité du stub et du nostub par rapport au graphisme (sprite, scrolling...)?

Le mode de programmation n'a rien à voir là-dedans. La vitesse ne dépend (à 99 que des routines employées. (J'ai mis à 99% parce qu'il y a une différence de quelques cycles selon la méthode d'appel utilisée pour appeler les routines, qui d'ailleurs ne dépend pas que du mode _nostub/kernel, mais aussi d'autres paramètres du style USE_FLINE_ROM_CALLS. Mais cette différence est négligeable.)

Donc si je comprend bien, la vitesse n'a rien a voir dans la difference...Il n'y a donc qu'une seule difference: l'utilisatoin de la memoire, c ca?

La seule différence notable est ta vision de la manière dont tu souhaite programmer!

Dans tous les cas, le nostub poura toujours etre plus rapide que le kernel.. (bsr..)

Puis pour ceux qui traite de salté ... l'implentation en rom de routine graphique, je trouve cela completement deplorable...

1. Vous dites tous, que le gain en memoire est un atout important... mais la je vous rapelle que ca permet quand meme d'economiser un max de memoire.... Alors faudrai pas se contredire...

2. C'est une methode tout a fait propre... d'ailleur, modifier la rom est tres propre (cf RomEdit & autoinst).

3. Niveau compatibilité, il suffit de patcher la rom ... en precisant son hardware... la compatibilité est donc de 100%

4. Cela permet d'eviter d'avoir 200 lib graphiques... perso meme si c'est genlib qui est en rom, je l'utiliserai!

5. Je ne sortirai pas de nouvelle version de Xlib sous format statique , ou un pseudo format imitant les lib statique! Pourquoi, parce que genlib le fait deja, et je pense que cela apportera des programmes Gros en taille... imaginez si tout le monde inclu Xlib dans son prog.... ca fait des prog enormes! Pour l'imitation des lib dynamiques en nostub, je ne vois pas l'interet, car Genlib le fait deja, et je refuse d'avoir sur ma calc genlib + XLib...

TiMad
a écrit : Dans tous les cas, le nostub poura toujours etre plus rapide que le kernel.. (bsr..)

En effet.
Et ça sera aussi plus rapide que tes routines en ROM, qui ont nécessairement besoin de jsr.

1. Vous dites tous, que le gain en memoire est un atout important... mais la je vous rapelle que ca permet quand meme d'economiser un max de memoire.... Alors faudrai pas se contredire...

Économiser la mémoire qu'on a est une chose, se procurer de la mémoire en trifouillant dans la ROM est une autre!

2. C'est une methode tout a fait propre... d'ailleur, modifier la rom est tres propre (cf RomEdit & autoinst).

Non, c'est très sale, et plus il y a des programmes qui traffiquent la ROM, plus il y a risque de problèmes.

3. Niveau compatibilité, il suffit de patcher la rom ... en precisant son hardware... la compatibilité est donc de 100%

Qui te dit qu'on pourra patcher AMS sur la V200?

4. Cela permet d'eviter d'avoir 200 lib graphiques... perso meme si c'est genlib qui est en rom, je l'utiliserai!

Je verrai plutôt plusieurs librairies (pas nécessairement toutes des librairies graphiques - peut-être il y en aurait pour différentes fonctions) qui voudront toutes s'installer au même endroit de la ROM, et ainsi semer un beau bordel.

5. Je ne sortirai pas de nouvelle version de Xlib sous format statique , ou un pseudo format imitant les lib statique! Pourquoi, parce que genlib le fait deja,

Genlib n'est pas une librairie statique, c'est une librairie dynamique!!! C'est différent!

et je pense que cela apportera des programmes Gros en taille... imaginez si tout le monde inclu Xlib dans son prog.... ca fait des prog enormes!

Pas tant que ça! Je pensais que tu avais bien compris le principe des librairies statiques, mais apparemment non! Seules les fonctions effectivement utilisées par le programme se retrouveront dans le programme!!!
Et puis, ça donnera peut-être plusieurs programmes avec les mêmes routines, et alors? Ça évite les conflits de version, ça rend l'utilisation des programmes plus simple (pas de librairie à installer), etc...

Pour l'imitation des lib dynamiques en nostub, je ne vois pas l'interet, car Genlib le fait deja, et je refuse d'avoir sur ma calc genlib + XLib...

Non, genlib n'est pas une DLL _nostub, c'est une DLL kernel avec une énorme librairie d'importation (librairie statique à linker avec le programme pour pouvoir utiliser la librairie dynamique) qui ne sert qu'à reloger genlib.


Et s'il faut installer _X_Lib dans la ROM, c'est encore plus compliqué à utiliser qu'un kernel!!!
Tu veux résoudre le problème des kernels avec un autre kernel, qui de plus doit être installé en ROM (donc TIB Receiver etc., à moins que tu ne saches faire un patch on-calc). Ce n'est pas du tout un progrès, c'est une régression! C'est beaucoup pire que les kernels (même avec un patch on-calc)!

L'intéret du _nostub est de pouvoir lancer un programme normalement, sans avoir à installer quoi que ce soit avant! Ton _X_Lib en ROM n'est pas du _nostub!

Je suis desolté de te dire ca mais si je raisonne comme toi, il n'y a pas beaucoup de programmes qui sont nostub... d'ailleur meme toi tu n'utilises pas de prog nostub, car tu a installer HW2patch ou ton tsr....

Je sais tres bien les avantages du nostub comme ses inconvegnants...
Xlib n'est plus du tout au meme stade d'avancement que la derniere version que j'ai distribuée....
Elle gere ses propres routines de Grays, elle a son propre format de Gplan, donc ses propres routines de plan ainsi que ses propres routines de sprites etc....
Rien que tout ca fait deja pas mal gonfler le programme...
Sans imaginer le fait que si les programmeurs utilisent XDraw Level, le programme devient alors vraiment lourd niveau taille....


De plus il n'y a aucun probleme a patcher une rom de la meme maniere qu' Etienne et moi l'avont fait pour RomEdit!

j'ai moi-même patché ma ROm après avoir modifié les fontes avec ROMedit...
mais ct du temps où le port marchait bien

je soutient que mettre quoi que ce soit en ROM de la sorte est une mauvaise idée...

Bein je vois pas la difference entre la patcher une fois et 2 fois a la suite....
Franchement je me demande pourquoi tout le monde est contre...
Pour la programmation, rien ne sera plus simple... plus besoin de libs... et pour l'utilisateur, il poura mettre beaucoup plus de programme...

TiMad
a écrit : Je suis desolté de te dire ca mais si je raisonne comme toi, il n'y a pas beaucoup de programmes qui sont nostub... d'ailleur meme toi tu n'utilises pas de prog nostub, car tu a installer HW2patch ou ton tsr....

Un programme 100% _nostub est un programme qu'on peut lancer sur une calculatrice avec un AMS non patché et fraichement réinitialisée sans avoir à installer quoi que ce soit avant.
Mes TSRs on font partie parce qu'ils intègrent h220xTSR.
Et la plupart des programmes _nostub n'a besoin ni de h220xTSR ni du HW2Patch!

Je sais tres bien les avantages du nostub comme ses inconvegnants...

Je n'ai pas l'impression que ce soit le cas en lisant tes messages dans ce topic.

Xlib n'est plus du tout au meme stade d'avancement que la derniere version que j'ai distribuée....
Elle gere ses propres routines de Grays, elle a son propre format de Gplan, donc ses propres routines de plan ainsi que ses propres routines de sprites etc.... Rien que tout ca fait deja pas mal gonfler le programme...

Que la routine de niveaux de gris soit celle de _X_Lib ou de TIGCCLIB ne change rien au point de vue taille de programme sauf si ta routine est mal optimisée en taille.
Même chose pour les routines de sprites.
Et enfin, le format des GPlans n'a rien à voir avec la taille du programme non plus.

Sans imaginer le fait que si les programmeurs utilisent XDraw Level, le programme devient alors vraiment lourd niveau taille....

Encore, ça veut dire qu'il faut optimiser ta routine au lieu d'aller traffiquer dans la ROM.

De plus il n'y a aucun probleme a patcher une rom de la meme maniere qu' Etienne et moi l'avont fait pour RomEdit!

Il n'est même pas on-calc, RomEdit! C'est vraiment lourd de devoir envoyer un AMS entier avec TIB Receiver pour changer une fonte ou installer une librairie!

TiMad
a écrit : Bein je vois pas la difference entre la patcher une fois et 2 fois a la suite....

Reflasher (pas "patcher" sauf si le patch est on-calc) 2 fois prend 2 fois plus de temps, consomme 2 fois plus de piles et use 2 fois plus la FlashROM que reflasher une fois. Donc il faut réduire au minimum le nombre de reflashages nécessaires. Et pour installer une librairie, un reflashage n'est vraiment pas nécessaire!

Franchement je me demande pourquoi tout le monde est contre...

Parce que ce n'est pas facile d'utilisation (c'est bien pire que les kernels de ce point de vue-là), parce que c'est dangereux (je te signale qu'il y a déjà eu des calculatrices rendues inutilisables par TIB Receiver), parce que ça use la FlashROM pour rien, parce que si tout le monde pense comme toi, ça sera la bagarre pour la place libre, etc...

Pour la programmation, rien ne sera plus simple... plus besoin de libs...

Ça ne changera rien pour la programmation. Il faut quand-même une table de sauts (sinon tu fais quoi si une routine change de taille) etc. Une librairie statique est même plus simple de ce point de vue-là.
Et de toute façon, c'est ton header qui doit s'occuper de l'importation des fonctions, quelle que soit la méthode employée (librairie statique, librairie dynamique ou ta mauvaise idée).

et pour l'utilisateur, il poura mettre beaucoup plus de programme...

Si tu crains vraiment que la librairie statique prend trop de place, fais une DLL _nostub normale, à installer dans la place prévue pour cela: la mémoire archive (pas la FlashROM système!). Mais je ne pense pas que la librairie statique fasse perdre tant de place!

Et ton idée est vraiment une insulte pour l'utilisateur. Avant d'utiliser le programme, il devra:
1. aller télécharger la mise à jour de AMS sur le site de TI
2. patcher cette mise à jour sur PC
3. aller télécharger TIB Receiver
4. l'envoyer sur la calculatrice
5. le lancer
6. envoyer la mise à jour patchée de AMS
Je préfère encore (de loin!) les programmes pour kernel plutôt que cela!

XDanger a écrit :
Vous serez autorisés à critiquer la documentation de TIGCC et les routines de TIGCC de manière destructive (car les suggestions constructives sont toujours les bienvenues), quand vous en aurez fait chacun autant que Kevin et moi (autrement dit, plus d'une cinquantaine de fonctions d'AMS 2.xx, et un grand nombre de routines d'AMS, notamment les routines sur les long longs faites par Kevin pour ne citer qu'elles)...

je n'ai jamais critique le boutot effectue sur la doc tigcclib. y'a vraiment beaucoup de boulots effectues, et c'est vraiment tres bien. J'ai dit qu'il y avait des fonctions non documentee.

Ceux qui me critiquent: plutôt que de se préoccuper de la communauté, en documentant des fonctions qui pourraient être utiles à d'autres programmeurs, ils font des kernels et des choses du même genre, des trucs qui ne marchent pas sur VTI (même si il paraît que c'est résolu maintenant), contrairement à TIGCC qui est tant critiqué.

Dis,tu vises qui la ? Parce que je vois pas je ne t'ai jamais critique pourtant ? je t'ai meme fait des compliments. Je ne comprends pas Pourtant ce que tu me dis me fait penser que c'est moi la personne visee.

Le patch n'est pas on calc.. il sera a faire sur pc comme HW2 patch... donc je ne vois pas en quoi cela change de devoir patcher une fois sa rom avec HW2patch et une autre fois avec un autre patch...
Cela ne detruit donc en aucun cas la flash...

Pour les routines, tu parles d'optimisations... mais une lib graphique tu optimises d'abord en vitesse.. la taille on s'en fout...
Pour la propre routine de gray... cela economise de la mem car quand on utilise tigcc.. il y a une routine a l'nterieur qui est inutiles, et perde de la place inutiliement.
L'utilisation de romcall ne pose pas de probleme...

Puis qui a dit que je voulais forcement mettre Xlib, ce qu'il faut c'est normalisé l'utilisation de certainne routine et les mettre en ram

TiMad
a écrit : Le patch n'est pas on calc.. il sera a faire sur pc comme HW2 patch...

C'est déjà faux. Le HW2Patch le plus récent est on-calc même pour AMS 2.05.

donc je ne vois pas en quoi cela change de devoir patcher une fois sa rom avec HW2patch et une autre fois avec un autre patch...

- Que le tien n'est pas on-calc.
- Qu'il n'est pas indispensable.
- Que je n'utilise pas le HW2Patch non plus. h220xTSR rulez! (Et c'est en RAM, pas en FlashROM!)

Cela ne detruit donc en aucun cas la flash...

2 patches = 2 fois plus de risques de détruire la FlashROM. Ce risque existe!

Pour les routines, tu parles d'optimisations... mais une lib graphique tu optimises d'abord en vitesse.. la taille on s'en fout...

On ne s'en fout pas, et le problème est là! 1 KO de plus passe encore si ça va vraiment plus vite, 10 KO de plus ne passent plus!

Pour la propre routine de gray... cela economise de la mem car quand on utilise tigcc.. il y a une routine a l'nterieur qui est inutiles, et perde de la place inutiliement.

C'est 1 KO seulement! On s'en fiche!

L'utilisation de romcall ne pose pas de probleme...

Que viennent-ils faire par là? Je n'ai pas parlé de ROM_CALLs qui poseraient problème, moi.

Puis qui a dit que je voulais forcement mettre Xlib, ce qu'il faut c'est normalisé l'utilisation de certainne routine et les mettre en [FlashROM]

Non, non, et encore non, pour les raisons que je n'ai pas envie de répéter pour la 10^ème fois.

Ils y a des choses contradictoire chez toi kk:
>Tu ventes le nostub parce qu'il n'a pas besoin de kernel pour etre lancé, pourtant tu utilises un Tsr que tu doits lancer a chaque reset pour que tes programmes marchent...
>La majorité des personnes de cette comunauté utilise HW2patch et non ton tsr... et dans les 3/4 des cas, le patch se fait on-pc
>patcher on calc est plus riquer que de patcher on pc... et d'ailleur ma derniere rom 2.05 a été patcher on pc...
>Il n'y a aucun risque a modifier la rom de cette maniere... Romedit le fait tres bien et je n'ai jamais eut de mail comme quoi cela avait niker leurs roms... il suffit de savoir faire un prog sur pc qui ecrit proprement dans la rom (pas dure...), le reste c'est tibreceiver qui s'en charge et qui le fait tres bien.

Donc niveau risque il n'y a aucun risque.. tout est pris en charge pas tubreceiver...

Maintenant, il faut arreter de se cacher les yeux et regarder les avantages...
on gagne un gain non negligeable en place et compatibilité...
plus de kernel, plus de lib a la c** etc ....

Franchement, il n'y a aucun probleme.. et d'ailleur je ne vois que le fait que tu veuilles faire passer ton format de lib avant les autres...
Perso je refuse de mettre Xlib sur ce format... peut etre que neurone le fera, mais certainement pas moi.. je preferait le sortir en version kernel!

Et cette idée d'ajouter des rom call n'est pas pour imposer une lib... d'ailleur ce que je propose c'est normaliser les lib... et en cela je ne vois rien de mal....

TiMad a écrit :
Ils y a des choses contradictoire chez toi kk: >Tu ventes le nostub parce qu'il n'a pas besoin de kernel pour etre lancé, pourtant tu utilises un Tsr que tu doits lancer a chaque reset pour que tes programmes marchent...

Mes programmes qui nécessitent h220xTSR sont des TSRs! Et comme ils sont en RAM (je ne traffique pas la ROM, moi), il n'y a pas d'autre moyen que de les réinstaller à chaque reset.
Et comme h220xTSR est intégré dans les TSRs, pour l'utilisateur, c'est comme s'il n'existait pas. L'utilisateur installe le TSR qu'ils veut installer (AutoClBr par exemple), et h220xTSR est automatiquement installé avec. C'est d'ailleurs une des 2 raisons principales pour lesquelles j'ai écrit h220xTSR. L'autre est que le HW2Patch n'était pas on-calc pour AMS 2.05 au moment où j'ai écrit h220xTSR. (Le HW2Patch on-calc pour AMS 2.05 est sorti 2 semaines plus tard.)

>La majorité des personnes de cette comunauté utilise HW2patch et non ton tsr... et dans les 3/4 des cas, le patch se fait on-pc

Ce n'est que parce que:
- h220xTSR et le HW2Patch en RAM ne sont sortis que quand AMS 2.05 avait déjà quelques mois.
- Le premier kernel compatible avec h220xTSR n'est sorti que très récemment.
Et vu qu'ils ont déjà installé le HW2Patch en ROM, c'est normal qu'ils ne vont pas s'amuser à reflasher AMS juste pour pouvoir mettre h220xTSR à la place. Mais parmi les nouveaux venus, il y aura de plus en plus de personnes utilisant h220xTSR maintenant que PreOs-Hw2Tsr est disponible.

>patcher on calc est plus riquer que de patcher on pc... et d'ailleur ma derniere rom 2.05 a été patcher on pc...

C'est faux:
1. Le patch on-calc ne modifie qu'un segment de la FlashROM. TIB Receiver en modifie une vingtaine. Donc le patch on-PC est 20 fois plus risqué.
2. Le calcul précédent ne tient pas compte du fait qu'un des segments modifiés par TIB Receiver contient la zone des certificats, qui sera effacée pendant un moment! Donc le TIB Receiver est de loin plus risqué que les patches on-calc!

>Il n'y a aucun risque a modifier la rom de cette maniere... Romedit le fait tres bien et je n'ai jamais eut de mail comme quoi cela avait niker leurs roms...

Mais il y en a qui se sont pleints de ce fait sur ce forum!

il suffit de savoir faire un prog sur pc qui ecrit proprement dans la rom (pas dure...), le reste c'est tibreceiver qui s'en charge et qui le fait tres bien.

Ben, apparemment non, il ne le fait pas toujours très bien vu le genre de choses qu'on peut lire!

Donc niveau risque il n'y a aucun risque..

Si.

tout est pris en charge pas tubreceiver...

... qui est très dangereux.

Maintenant, il faut arreter de se cacher les yeux et regarder les avantages... on gagne un gain non negligeable en place

Bof... Pas tellement que tu ne le désires. 64 KO maximum, sinon il n'y a plus de place en ROM.

et compatibilité...

Qu'est-ce que ça change pour la compatibilité si la librairie est dans un fichier en mémoire archive (ou en RAM) ou dans un segment de la FlashROM système?
Ce que je vois, c'est plutôt des incompatibilités potentielles avec d'autres choses. Par exemple avec de nouvelles versions de AMS qui pourraient utiliser la partie du bloc non utilisée!

plus de kernel,

C'est quoi alors ta librairie à installer en ROM? Moi, j'appelle ça un kernel en ROM! (Un kernel au sens utilisé sur TI-89/92+ étant pour moi défini comme un morceau de code qui doit être installé - pas seulement envoyé à la calculatrice comme une librairie dynamique normale - pour permettre à certains programmes de fonctionner.)

plus de lib a la c** etc ....

C'est quand-même une librairie dynamique, même si elle est installée en FlashROM système! Et une librairie qui de plus doit être installée, donc encore pire qu'une librairie dynamique normale.

Franchement, il n'y a aucun probleme.. et d'ailleur je ne vois que le fait que tu veuilles faire passer ton format de lib avant les autres...

Je veux avant tout te convaincre de ne pas aller fouiller dans la FlashROM système, elle n'est pas faite pour que monsieur Sabatier puisse y enregistrer sa librairie dynamique!

Et si je veux "faire passer mon format de lib avant les autres", c'est parce qu'il a d'importants avantages techniques par rapport aux autres: facilité d'utilisation (surtout: rien à installer), pas de présence on-calc de fonctions qui ne sont pas effectivement utilisées par un programme (donc économie de place), pas de conflits de version (un programme utilisera toujours la version de la librairie pour laquelle il a été prévu, ce qui élimine tout risque d'incompatibilités dues à un changement dans la fonctionnalité interne de la librairie), etc.

Perso je refuse de mettre Xlib sur ce format... peut etre que neurone le fera, mais certainement pas moi..

Si tu me permets de le faire, je le ferai, moi.

je preferait le sortir en version kernel!

C'est toujours mieux que d'aller traffiquer en FlashROM système. Même si c'est un choix entre 2 mauvaises solutions, et que le format kernel n'est que la moins pire des 2.
Et si tu veux en faire une DLL plutôt qu'une librairie statique, pourquoi pas une DLL _nostub?

Et cette idée d'ajouter des rom call n'est pas pour imposer une lib... d'ailleur ce que je propose c'est normaliser les lib...

Elle est où la différence entre "imposer" et "normaliser"???

et en cela je ne vois rien de mal....

Si: tout le monde voudra "normaliser" (imposer) sa librairie, et si tout le monde pense comme toi, tout le monde voudra utiliser la place libre en FlashROM système, donc on finira par devoir reflasher à chaque fois qu'on veut essayer un autre jeu/programme, ce qui serait vraiment une situation intolérable.

Pourquoi on n'en veut pas ? Pour deux raisons :
- le risque existe, et il est énorme... non seulement venant de TIB Receiver, mais aussi parce que executer du code à partir de la FlashROM systeme à certains endroits donne un controle total sur les protections de la FlashROM et permet tres simplement de bousiller la zone des certificats, suffit d'un petit bug. Le résultat est une calculatrice inutilisable pour de bon.
- tres probable incompatibilité totale avec les versions futures d'AMS, ainsi que les prochains Gate Arrays.

Ces deux raisons sont largement suffisantes et sont nettement plus importantes que le gain en place.