GTC (encore) - Page 4

Quelle archi ? x86 ?

Heu... GCC compile pour AMD 64 par défaut, quand on est sur une distrib 64 bits ?

Oui.

OK. Il est capable de compiler pour x86 quand même, via une option ?

[edit] OK j'ai trouvé. Je vais compiler pour les deux architectures.

x86-64 instruction set

[edit] Ca marche pas...gcc flashappy.c -mtune=i586 -O2
flashappy.c:1: error: CPU you selected does not support

OK, ça complique les choses. Je vais compiler sur l'eeePC, ça sera plus simple.

Sinon, la plupart des linuxiens devraient pouvoir choper un gcc qui va bien sur leur machine et compiler eux-même la bête (surtout que parmi les personnes qui sont susceptibles d'être intéressées par le programme d'ExtendeD, il y aura - à mon avis - surtout des programmeurs).

Oui, mais c'est par principe. Tout est toujours à faire soi-même sous Linux. La facilité n'est que pour Windows. Ca n'encourage pas à passer à Linux. Il est temps de s'ouvrir, l'OS est arrivé à un point où il a le potentiel pour toucher tout le monde. Il faut arrêter de penser "linux c'est pour l'élite", sinon la situation ne décoincera jamais. M'enfin ce n'est pas le sujet.

Voici, pour x86 et AMD64 : Fichier joint : flashappy.tar.bz2

C'est -m32 pour compiler un binaire 32 bits.

Et sinon, TIGCC ne sera pas illégal vu que TIGCC ne référencera nulle part le patch, il permettra juste (si et quand ce sera implémenté) de créer des FlashApps non signées, après comment vous les envoyez, c'est votre problème, comme pour les Flash OS!

Et sinon, c'est possible de faire un patch on calc comme HW3Patch et Xpand? Parce que ce serait quand-même plus pratique.

C'est beaucoup moins dangereux pour moi de faire comme ça, et ça demande peu de tests, personnellement je reste sur du FreeFlash.

On n'aura jamais l'envoi de FlashApps accessible à l'utilisateur moyen alors.
Tu t'imagines l'utilisateur moyen qui ne comprend rien (cf. forum Questions ) compiler un patcheur PC (voire 2, le patcheur et FreeFlash) pour son OS, lancer le(s) patcheur(s), envoyer le programme de réception de FreeFlash sur sa TI, lancer le programme de réception et envoyer l'OS modifié? AMHA on aura droit à plein de calculatrices en l'état "Press I to install code" parce que leurs utilisateurs n'utilisent pas FreeFlash correctement.
AMHA un patch à la HW3Patch est beaucoup plus simple à utiliser.

Rédige un tuto

./102 : Soit, je suis d'accord.
Je répondais simplement en vitesse à la demande du topic. Je ne veux pas de prendre de risques ni consacrer du temps à ça. Le code source est disponible pour ceux souhaitent.

Pas besoin de compiler Kevin, ExtendeD fourni déjà un exécutable Windows dans l'archive.

Si flashappy sort officiellement, par exemple sur ticalc.org, on peut proposer une archive contenant la version Linux également.

Et ça ne tournera pas sur la moitié des distributions parce que la glibc avec laquelle ça a été compilé est plus récente que celle avec laquelle on veut le faire tourner. Il faut soit un paquetage pour chaque distribution, soit compiler. Je n'ai fait que de mauvaises expériences avec le tarball binaire de TIGCC et il va bientôt disparaître (il n'y aura que le tarball source, le RPM et les paquetages tiers (par exemple le .deb de Romain)).

Boah, en 2042 tout le monde aura cette bibliothèque ou des versions ultérieures.

Martial Demolins (./83) :

Pollux (./81) :
il n'y a qu'une seule passe sur le fichier.

Tu résouds quand les distances des sauts et des adressages ? t'as forcément au moins deux passes non ?

Non, les références à des éléments non définis sont supposées être par défaut en .w, mais si ça passe pas parce que le programme est trop gros on note les labels qui posent problème, et on recompile absolument tout depuis le début C'est un peu bourrin, mais comme ça permet de se débarrasser complètement des références déjà résolues ça a l'avantage d'être super léger en RAM tout en restant rapide pour les programmes de moins de 32k (c'est typiquement ce genre de programme qu'on va créer en programmant on-calc), et on peut même se débrouiller pour faire un programme bien plus gros que 32k qui n'a pas besoin de deuxième passe du moment que les fonctions du début du programme font pas référence aux fonctions de la fin.

Kevin Kofler (./100) :
Et sinon, c'est possible de faire un patch on calc comme HW3Patch et Xpand? Parce que ce serait quand-même plus pratique.

Je confirme, si tu pouvais faire ça ce serait vraiment génial

Pollux (./108) :
mais si ça passe pas parce que le programme est trop gros on note les labels qui posent problème, et on recompile absolument tout depuis le début

Ça s'appelle une deuxième passe.

Ouais mais ça arrive pas en général

Excusez-moi mais j'ai pas tout compris ...

À quoi sert ce patch ?

Un patch on-calc est plus difficile à réaliser qu'un patch on-computer, parce qu'il faut réaliser des modifs qui ne font qu'effacer des bits, et essayer de minimiser le nombre de words touchés...
Côté callee (modifier la routine de vérif), peut-être qu'on peut, sans se casser la tête, mettre tous les bits à zéro (ori.b #0,d0 est une instruction neutre) jusqu'à un rts. Mais il faut trouver un rts aligné sur un multiple de 4 octets par rapport au début de la routine.
Côté caller (shunter l'appel à la routine de vérif), essayer de mettre des ori.b #0,d0 et/ou des nop.

ExtendeD (./101) :
C'est beaucoup moins dangereux pour moi de faire comme ça, et ça demande peu de tests, personnellement je reste sur du FreeFlash.

Il reste à porter FreeFlash sur HW4.

j'ai deux certificats 89 et v200 si tu veux, je te fwd le mail de TI

edit : ok j'ai 2 pages de retard ^^

Lionel Debroux (./112) :
Un patch on-calc est plus difficile à réaliser qu'un patch on-computer, parce qu'il faut réaliser des modifs qui ne font qu'effacer des bits, et essayer de minimiser le nombre de words touchés...

Pas forcément, on peut aussi effacer tout le secteur et écrire ce qu'on veut.

moui pas bête, ça. non?

"pourquoi pas mettre des nops" : parce que comme l'explique Lionel on ne peut que faire passer des bits de 1 à 0, à moins de tout recopier comme l'explique Kevin.
"Pourquoi pas écrire $4e75 à l'entrée du ROM CALL directement" : Parce que c'est l'appel spécifique qu'on veut patcher, et non la ROM Call utilisée dans d'autres cas.

J'ai finalement écrit un patch à la Xpand pour éviter qu'on se retrouve encore au même points 5 pages de topic plus loin Je vais en profiter pour tester sur 92+.

FlashAppy ça dépasse 8 caractères, quelqu'un aurait un meilleur nom ?

Mais ce truc va permettre d'installer des applications qu'on n'a pas achetées ?