Kernel vs Nostub? - Page 26

moué
j'aimerait bien etre la si un jour texas sort un ams 3.x avec des romcalls ki changent, et voir si recompiler/adapter une dizaine de lib est plus lent que se debrouiller avc des exe nostubs :]

>j'aimerait bien etre la si un jour texas sort un ams 3.x avec des romcalls ki changent, et voir si recompiler/adapter une dizaine de lib est plus lent que se debrouiller avc des exe nostubs :]
Ca serait étonnant qu'ils changent des trucs utilisés par les programmes assembleur ou les FlashApps. Peu de ROM_CALLs ne sont utilisés ni par les uns ni par les autres.
Comme aime à le dire PpHd, ça n'est pas impossible. C'est juste (là, c'est mon avis) très improbable.

Il n'y a que rarement des hacks très peu sûrs en _nostub. Le _nostub ne fait pas ce qui a été fait avec les vieux kernels et les vieux programmes kernel-based, largement breakés dans les plus grandes largeurs quand AMS 2.xx est apparu, à cause entre autres de hacks pas sûrs du tout.
Et les hacks _nostub sont (à quelques exceptions près que j'ai faites, et que je vais demander à Sebastian de retirer), justement, testés pour être sûrs sur les versions existantes. Si le ROM_CALL est exporté, il est, sauf exception toujours possible, utilisé pour être compatible avec les futures versions d'AMS.
Bien sûr, je parle ici de la compatibilité avec AMS, pas avec autre chose qu'AMS...

il esxite encore ce topic ?

ouai et faut le remonter!

Clair, la mauvaise foi des participants (que tout le monde se sente visé) me fait passer de bons moments

pi ca fait de la lecture

oué que 26page, mais on a presque rattrapé le topic GTC qui est bcp bc plus vieux

Allé courage !
faut dépasser le topic de GTC

Oui mais ca fait quelque pages déja que l'on ne débat plus de kernel/nostub je crois qu'on a épuisé a peu pret tous les arguments de part et d'autre et que la plupart en ont marre vu que ca ne menne a rien

c vrait...

Va falloir faire dévier se topic alors

Tiens j'ai une idée :

[sondage=13414]

NON. Il y a EV_hook qui marche très bien.

Pré réponse de Kevin Kofler:
AMS dispose déja de son propre système d'évenement alors pourquoi en redéfinir d'autres incompatibles.

mince il a été plus rapide que moi, la préréponse est devenue une post réponse en plus du fait qu'il a gardé son calme

Lol


Kevin : L'homme qui post plus vite que son ombre

Trop fort, y'a qu'un clampin à avoir voté "non" on se demande qui

Kevin> EV_Hook que je sache est pas utilisable en kernel (bon tu me dira "Kernel sux" mais bon)

"un systeme evenementielle pour les programme Kernel" : c'est-à-dire exactement ?

Ouais moi aussi j'aimerais savoir ce que c'est

cf Pedrom App sur le forum T3


Tiens a propos de pedrom, je viens de tomber sur une viellerie qui trainait sur un de mes durs :

jesuisunemerde.zip
#souvenir##souvenir#

mouarf je suis arrivé trop tard pour l'avoir celui-là...

héhé

Tu peut avoir la version "allégé" de qq broutilles (dansgeureuses de surcroit) sur ticalc.org

Ah oui, elle est allégée ? J'avais pas fait attention.

oué ya des sources en moins... (genre les sources (originale?) de maxmem et hw2patch !!)
J'veux pas poser de polémiques, mais soit JM = WH, soit, WH a reussi a piquer les sources de JM, elle sont clair et bien commenté..

Et ya deux trois autrs brisoles de peu d'interet qui traines aussi

>soit JM = WH
Non, c'est du simple désassemblage (comme tout le reste du package). Et ce sont de vieilles sources (pour AMS <= 2.03).

Sa c du déssasemblage :

        moveq	#$A,d0
Verify_Good:
        cmpm.w	(a0)+,(a1)+
        dbne	d0,Verify_Good
        bne.w	Fini
        move.l	#$30005,-(sp)
        pea	MsgWarning(pc)
        pea	MsgAbout(pc)
        movea.l	1744(a5),a0	; DlgMessage
        jsr	(a0)
        adda.w	#$C,sp
        cmpi.w	#13,d0
        bne.s	Fini
        lea	Factice(pc),a0
        move.w	(a0),-(sp)
        move.w	#$4E71,(a0)	; remplace la boucle factice par un nop
        bsr.s	ChkArch
        lea	Factice(pc),a0
        move.w	(sp)+,(a0)
;        bra.s	Fini
;Exit:
;        move.l	($AC),d0
;        cmpi.l	#$100,d0
;        beq.s	Fini
;        bsr.s	ChkArch
;        lea	loc_0_182,a0
;        move.l	($AC),8(a0)
;        move.w	#6,d0
;        lea	($40100).l,a1
;
;loc_0_15E:
;        move.w	(a0)+,(a1)+
;        dbf	d0,loc_0_15E
;        move.l	#$100,($400AC).l

Fini:
        movem.l	(sp)+,d1-a6
        rts	

??

je le veux ce desassembleur

>godzil : oui, sûrement.

Oui je confirme j'avais pas bien regardé, c bien du désassemblage, ya des n° de ligne genre L004.

Il a du se faire chier quand meme a relire la source, la comprendre et la commenter..

Bah il a du tout reprendre alors ...

oué l'é(té) fou :/

hmhm