Par contre Folco, t'aurais pu prévenir que ton exécutable était compressé, j'ai failli me casser une dent en mordant dedans

Zerosquare (./38) :Ah ?!
Les versions 64 bits de Windows sont capables de faire tourner certains des installeurs 16 bits les plus courants, donc ça vaut le coup d'essayer quand même.
clr.w -(sp) ROMC HeapDeref movea.l a0,a2 move.w #1,-(sp) ROMC HeapDeref movea.l a0,a3 move.w #2,-(sp) ROMC HeapDeref movea.l a0,a4 move.w #3,-(sp) ROMC HeapDeref movea.l a0,a5 move.w #4,-(sp) ROMC HeapDeref movea.l a0,a6 bra *Ca liste les adresses des handles 0-4 dans a2-a6
#0 : FFFFFFFF #1: 00003FD44 #2: 00423538 #3: 0008862 #4: 0008888Donc ça colle pas avec ta sortie.
Pen^2 (./40) :Pas mal de softs ont continué à utiliser des installeurs 16 bits pendant un certain temps, parce que :
Je pensais que les exécutables win16 c'était fini depuis un moment... ? Il y a un truc spécial pour les installeurs ?
movea.l $C8,a0 lea 0(a0,441*4),a0 ; Maintenant a0[x] contient l'adresse du handle #x
Folco (./41) :Ah oué je sors des putaings de conneries aussi
Tous les autres seraient hors flash sur 89 standard (car au-delà de 2Mo)
build.sh PedroM-89.tib test.89z test.asm tios.h Vti.exeMême pas de skin
xdef _ti89 xdef _main include "tios.h" _main: suba.l a0,a0 ; Handle in a0 trap #3 ; Deref it movea.l a0,a2 ; Save it movea.l #1,a0 trap #3 movea.l a0,a3 movea.l #2,a0 trap #3 movea.l a0,a4 movea.l #3,a0 trap #3 movea.l a0,a5 movea.l #4,a0 trap #3 movea.l a0,a6 bra * rtsSous PedroM, le trap #3 déréférence le handle contenu dans a0.w, et renvoie son adresse dans a0.l (feature géniale de PedroM BTW).
#0 $FFFFFFFF #1 $0003FD44 #2 $00223564 #3 $00008482 #4 $000084A8Donc on a un handle fictif, un en mémoire haute, un en flash et deux en mémoire basse.
Folco (./56) :Il n'y a pas de décompresseur officiel pour le compresseur utilisé (ASPack). Il y a des outils non officiels qui le font, mais c'est le genre de machins qui se trouvent sur des sites de cracks russes, donc j'ai moyennement confiance. Sinon on peut le faire à la main aussi, en reconstruisant un exécutable correspondant à l'état de la mémoire du processus après décompression, mais c'est assez pénible (il y a plusieurs sections différentes à reconstruire).
C'est pas possible de le garder décompressé, tout simplement ?
Zerosquare (./55) :Tu ne peux pas faire un jsr sur un bout de code qui s'occupe de faire le patch, ajouté à la fin de l'exe compressé, puis un rts pour démarrer la version décompressée ?
Il faut que je trouve un moyen de le patcher à chaud après décompression, si possible sans changer la taille sur le disque (pour pas avoir à modifier plein de trucs pour compenser).