sorti quelques jours avant
mais l'implémentation de référence du désinstalleur
nom déprécié, en passant, étant donné que "tsr" n'est pas assez spécifique à mon avis
si tu voyais tout ce que je peux comme noms à des fonctions : que dirais-tu d'une fonction qui s'appelle __L1A56 ?
[...]Unhook est réentrante
) que le W3C veut faire...............
)
.
Flanker
:sorti quelques jours avant
la première version de la fonction marchait bien avant que tu ne saches qu'il y avait un second standard de TSR
Mais on a fini par se mettre d'accord, donc c'est bon.
mais l'implémentation de référence du désinstalleurpourquoi de référence ? Parce que c'est la tienne ?
Et parce que la documentation est meilleure (plus de commentaires, readme plus complet). Cela dit, ton implémentation est nettement mieux optimisée (en taille en tout cas, je ne peux pas commenter sur la vitesse).
nom déprécié, en passant, étant donné que "tsr" n'est pas assez spécifique à mon avis
quan on exécute le programme, ça ne se voit pas trop
et je pense que tu seraissi tu voyais tout ce que je peux comme noms à des fonctions : que dirais-tu d'une fonction qui s'appelle __L1A56 ?
En effet, ton code est souvent illisible (et pas seulement à cause de ça). 
[...]Unhook est réentrante
Il me semble qu'elle est récursive (et pas réentrante), vu que quand j'efface Comb, ça efface sans problème tous les TSR qui l'utilisentToutes les variables utilisées sont mises sur la pile
Et pour le cas de A qui veut effacer B qui veut effacer C (non, pas A qui veut effacer B et C, mais le cas où il y a demande d'effacement transitive!), ça marche? J'ai été obligé de m'inventer des trampolines complexes pour permettre ça dans mon code et la simplicité de ton code sur ce point-là me rend (peut-être à tort!) sceptique.
je viens de modifier un tsr pour faire le test
C'est exactement pour ça que je trouve que ton désinstalleur n'est pas une bonne référence.
En effet, ton code est souvent illisible (et pas seulement à cause de ça).
Flanker
:Et pour le cas de A qui veut effacer B qui veut effacer C (non, pas A qui veut effacer B et C, mais le cas où il y a demande d'effacement transitive!), ça marche? J'ai été obligé de m'inventer des trampolines complexes pour permettre ça dans mon code et la simplicité de ton code sur ce point-là me rend (peut-être à tort!) sceptique.
oui, ça marche sans problème
avec une fonction moins complexe
En effet, ton code est souvent illisible (et pas seulement à cause de ça).
je trouve mes sources de TSR particulièrement lisibles, pourtant
clr.w -(a7) move.l d4,-(a7) move.w d7,-(a7) move.l 284(a5),a0;PopupDo jsr (a0) addq.l #8,a7 tst.w d0 beq _effacement_popup include "tsr_delete.h" _effacement_popup: move.w d7,-(a7) move.l 604(a5),a0;HeapFree jsr (a0) addq.l #2,a7 pea success_str(pc)
clr.w -(a7)
move.l #$ffffffff,-(a7)
move.w d4,-(a7)
ROM_CALL PopupDo ;show the popup menu
move.w d0,d5 ;save the return value to d5
ROM_CALL HeapFree ;delete the popup menu
addq.l #8,a7
tst.w d5 ;check if ESC presses
beq displayappname ;if yes, display the app name
cmp.w #4095,d5 ;check if "incompatible" selected
beq incompatible3 ;display "incompatible" error message
ROM_CALL2 EV_hook
skip:
move.l (a4),a5 ;get the address of the event hook
move.l a5,a3 ;save the address of EV_hook to change to a3
sub.l #$40010,a5 ;remove: * $40000 for HW2 AMS 2.0x
; without HW2Patch
; * $10 to get the begin of the
; handle (if compatible)
lea.l 12(a5),a4 ;move the "old event hook" placeholder to
;a4 (this is the EV_hook replacement)
subq.w #1,d5 ;remove 1 from the number of the event hook
bne skip ;continue until the correct event hook is reached
move.l a4,a6 ;save the old event hook
uninstall_now:
Et maintenant essaye avec 4 (A qui efface B qui efface C qui efface D). Tôt ou tard, tu vas avoir des problèmes avec tes variables globales sauv_usp et sauv_usp2. Tu ne peux pas stocker une infinité de valeurs là-dedans. C'est pour ça que je travaille avec des trampolines sur la pile pour restaurer la bonne valeur de %a7 à chaque fois
A chaque fois il n'y a qu'une valeur qui pointe vers la précédente, quelque part dans la pile. Je n'en stocke qu'une. Je suis d'accord avec toi sur le fait que je ne peux pas en stocker une infinité, mais ça tombe bien, vu que je n'en stocke qu'une Le seul problème éventuel, c'est un débordement de pile (mais il faudrait beaucou p de TSR imbriqués )
... dont tu n'as toujours pas démontré la correction.
Chez moi, presque toutes les instructions sont commentées. Chez toi, c'est loin d'être le cas.
je préfère commenter uniquement les instructions essentielles, pour expliquer vaguement le fonctionnement, et me concentrer sur le code.
(par contre, c'est clair que ce serait mieux avec ROM_CALL et ROM_CALL2) Et puis s'il a pas envie de perdre son temps à commenter son code, c'est parfaitement légitime... (perso je suis pas un fana des commentaires partout non plus; mais je comprends qu'on puisse aimer aussi...)
HdStrLen: move.w (a7),-(a7) jsr HeapDeref move.l a0,(a7) jsr strlen addq.l #2,a7 rts
ROM_CALL PopupDo ;show the popup menu move.w d0,d5 ;save the return value to d5
Et ne crois pas que c'est de la science-fiction et que TIFS ne générerait pas du code comme ça : l'une des rares optimisations de TIFS consiste à réserver un mot (ou 2) sur la pile et à utiliser move *,(a7) au lieu de move *,-(a7). Bon, je ne suis pas sûr qu'il soit capable de générer ce code-là en particulier, mais en tout cas le risque est loin d'être nul.
Pollux
: Au fait Kevin, tu n'as pas le droit de faire ce que tu fais au début de ton code (réutiliser le handle qd il est déjà sur la pile).
En pratique, ça marche,
Mais il faudra que je mette un commentaire qui explique que c'est sale.
) ou en somme nous, je vous le demande bien )
