PreOS 0.70 - Page 6

Bah, vous allez bien trouver quelque chose de ok.
Une fonction uninstall a exporter ?

Flanker
: bah elle me convient pas, vu qu'elle n'autorise pas l'exportation de fonctions, ni les RAM_CALL

Les RAM_CALLs ne seront jamais permis par ma convention!

PpHd
: Une fonction uninstall a exporter ?

Ça n'apporterait rien par rapport au système de désinstallation de la 2.00 qui permet déjà au hook de réagir en appelant n'importe quelle fonction!

qui appelle une fonction qui n'est pas prouvée, rappellons-le

Kevin Kofler
:

Flanker
: bah elle me convient pas, vu qu'elle n'autorise pas l'exportation de fonctions, ni les RAM_CALL

Les RAM_CALLs ne seront jamais permis par ma convention!

bah je sais bien, c'est même la raison qui m'a conduit à faire un nouveau standard de TSR / Hook

On s'en balance...

j'aime bien le except flanker

Il ne va pas utiliser ma convention quoi que je fasse (il vient de dire qu'il n'aime pas la 2.00 non plus), alors je m'en fous de ses objections.

Vous pourriez etre plus poli, les garcons.

The reasons for this change:
* Those uninstallation events bloat UnInEvHk and increase the risk of bugs.
* There was only one person who found a use for these extensions, the one designing those changes in the first place: Flanker.
* This one person is now going to program his event hooks using kernel mode, and to add even more stupid extensions to the standard to accomodate this. So it looks like there will soon be zero users of the event hook convention 2.00.
* I never liked those additions in the first place. My original standard was simple and easy to implement.
* Now is the right time to revoke those changes, because the event hooks have to be updated for TI-89 Titanium support anyway, and as I said, hardly anyone is using the new signature anyway. (I kept using the old one in my TSRs.)

putain mais t'es vraiment pitoyable. tu n'as trouvé que ça comme vengeance
c'est complètement n'importe quoi. Increase the risk of bugs ? donne une bonne raison
more stupid extensions ? mais tu ne sais même pas ce que je suis en train de programmer !
My original standard was simple and easy to implement. Ca c'est une bonne raison ! Attention c'est compliqué ! faut pas y toucher !
Those uninstallation events bloat UnInEvHk. Ca j'y peux ruien si tu sais pas faire un programme suffisament optimisé. UnHook est aussi gros qu'uninevhk 2.00 et 40% plus petit que le 3.0.

PS: La convention 3.00 interdira explicitement l'usage du mode kernel.

Lequel ?

lol pphd (sur tict)

Mais non.

Kevin Kofler
: Tous les changements de la version 2 seront révoqués. Tu l'as voulu avec tes trucs kernel à la noix.

Je compte rajouter kernel::exit et kernel::atexit. Nan, Kevin. Pas taper.

ils vont faire quoi exactement ?

heu je serais tenté de dire qu'il vont faire ce que ferai normalement exit et atexit de tigcclib car il risquent de poser des problèmes à cause des kack de kernel.h.
J'ai raison?

http://tigcc.ticalc.org/doc/stdlib.html#atexit
et
http://tigcc.ticalc.org/doc/stdlib.html#exit

j'ai bien recu la RC2 merci pour le moment aucun bug remarque

moi non plus, aucun bug de remarqué, mais il faut dire que je ne l'ai pas encore essayé

j'ai l'impression que RegisterHook ne marche pas
Sinon, c'est peut-être un peu tard, mais j'ai l'impression que les libs conditionnelles marchent mal avec PreOS 0.67 (j'utilise 2 fois le RAM_CALL dans un programme et au désassembleur j'ai vu un jsr $0 à la place du 2e appel )

j'ai l'impression que RegisterHook ne marche pas Sinon, c'est peut-être un peu tard, mais j'ai l'impression que les libs conditionnelles marchent mal avec PreOS 0.67 (j'utilise 2 fois le RAM_CALL dans un programme et au désassembleur j'ai vu un jsr $0 à la place du 2e appel )

Ha toi aussi t'as un 0 qui traine? je croyais que c'était un bug de moi qui me mélangais avec des problèmes de flags!

bon, bah c'est peut-être bien un bug alors ^^

Par contre t'a bien fait un kernel_LibEnd(je suis plus sur du nom) avant le second appel?

nan, j'ai pris le RAM_CALL qui libère la lib directement après l'appel. En plus, ça serait plutôt un problème de relogement.

toujours à propos de PreOS 0.70, j'ai un EV_Hook qui vaut 0x53EE9E, qui ne correspond pas à du code (et encore moins à l'EV_Hook d'origine)

edit : pour ça, j'ai trouvé l'orgine du bug :
add.l #$10+kernel::KERNEL_SPACE,(a1)
donne
add.l #$500010,(a1)

pour le bug de EV_registerHook, le move.w -$34(pc),a1 me semble incorrect

J'aurais vraiment du les tester un peu plus ces fonctions
Au moins elles existent

>J'ai l'impression que RegisterHook ne marche pas
Explicite. Pas de sauvegarde ? Peut etre. T'as les sources. Regarde

>j'utilise 2 fois le RAM_CALL dans un programme et au désassembleur j'ai vu un jsr $0 à la place du 2e appel
Programme ASM / C ? Filer moi les executables, les sources et des infos sur comment l'avoir.
Apparait-il avec preos 0.70 ?

>toujours à propos de PreOS 0.70, j'ai un EV_Hook qui vaut 0x53EE9E, qui ne correspond pas à du code (et encore moins à l'EV_Hook d'origine)
Top genial. Tu peux m'envoyer le code ?

PS:

lis mieux le ./178