compression... - Page 2

Pollux :
m'enfin je sais pas si y a encore la fameuse limite de kevin sur les dll

Laquelle ?

une seulle Dll appelable par programme

En même temps.

je pense faire un système mixte : certaines compressions seront connues en dur, et si le format n'est pas connu, il ira voir s'il est dans le fichier de conf

le code est déjà entamé, j'ai presque fini la fonction de compression (il ne reste plus qu'à faire la compression elle-même en fait, tout ce qui va autour est à peu près fini)

call_ziplib:
 lea     ziplib_str(pc),a0
 moveq   #1,d1
 jsr     kernel::LibsBegin
 lea     lib_descriptor(pc),a1
 move.l  a0,(a1)
 beq     \exit

 bsr     deref_file_to_compress ; renvoie dans a0 un pointeur vers le fichier à compresser dans la VAT (c'est correct, j'ai vérifié)
 moveq   #1,d0
 
 move.w  #6,-(a7)
 pea     lib_descriptor(pc)
 jsr     kernel::LibsCall
addq.l  #6,a7

 move.l  lib_descriptor(pc),a0
 jsr     kernel::LibsEnd		

\exit:
 rts
ziplib_str:
 dc.b   'ziplib',0
 even

;
; Function: Compress or Extract a file
;
; Input:    A0   = Pointer to file in the VAT
;	    D0.B = 0 disable commentary 
;		   1 semi-commentary (error displayed)
;		   else enable commentary (Windows, Confirmations,...)
;
; Output:        D0.B = 0 no error 				
;		   	1 can't manipulate because file is archived
;         	   	2 compressed file bigger than original
;		   	3 not enough memory
;			4 Program running
;		    NO OTHER REGISTERS DESTROYED
;----------------------------------------------------------------------------
;ziplib::zipfile	equ	ziplib@0006

et pourtant, rien n'est compressé

call_ziplib:
 lea     ziplib_str(pc),a0
 moveq   #1,d1
; jsr     kernel::LibsBegin
 lea     lib_descriptor(pc),a1
 move.l  a0,(a1)
 beq     \exit

 bsr     deref_file_to_compress
 moveq   #2,d0
 jsr     ziplib@0006
 
 move.w  #6,-(a7); jsr ziplib@0006
 pea     lib_descriptor(pc)
; jsr     kernel::LibsCall

 addq.l  #6,a7


 move.l  lib_descriptor(pc),a0
; jsr     kernel::LibsEnd		

\exit:
 rts
ziplib_str:
 dc.b   'ziplib',0
 even

en appelant ziplib directement, ça passe, bug de preos ?

finalement, je fais

call_ziplib:
 lea     ziplib_str(pc),a0
 moveq   #1,d1
 jsr     kernel::LibsBegin
 lea     lib_descriptor(pc),a1
 move.l  a0,(a1)
 beq     \exit


 moveq   #6,d0; jsr ziplib@0006
 jsr     kernel::LibsPtr
 move.l  a0,a2

 bsr     deref_file_to_compress
 moveq   #1,d0
 jsr     (a2)

 move.l  lib_descriptor(pc),a0
 jsr     kernel::LibsEnd		

\exit:
 rts
ziplib_str:
 dc.b   'ziplib',0
 even

mais ça marche, ça compresse bien (et ça décompresse aussi ) mais par contre, mon programme se transforme en expression


edit: c'est bon, la compression marche (un ptit pb de pointeur, un a2 au lieu d'un a0 qui expliquait en même temps les deux bugs précédents)

edit2 : c'est bon, les deux premières fonctions compress@0000 (compression) et compress@0001 (extraction) marchent, mais il n'y a que ziplib d'intégrée
911o pour l'instant

à propos des Pack Archives :
j'aimerais bien faire quelques fonctions supplémentaires pour les gérer : du genre
- récupérer la liste des fichiers contenus dans un pack archive
- récupérer leur taille
- extraire tous les fichiers dans le dossier pack_archive

ptêt une fonction compress:ack_info qui renverrait un handle au même format que le handle d'un dossier (ie 4 octets pour le nombre de fichiers, puis 14o par fichiers, dont 8 pour le noms et 6 pour des infos supplémentaires)

c'est possible à votre avis ?

34, 35, 36: Pourquoi tu fais pas kernel::LibsRun ?
Faudrait gerer les retour d'erreur un peu plus proprement aussi.

>c'est possible à votre avis ?
Sans probleme.

tu parles d'un kernel::LibsExec ?

et comment ça, gérer plus proprement les retours d'erreur ?

1. Oui
2. Ben la, s'il y a une erreur, ben on s'est pas trop ce que c'est. Et kernel::LibsPtr peut aussi renvoyer nul si la fonction demandée n'existe pas.

1. LibsExec peut conduire à un HeapCompress, non ? Et du coup, le SymPtr va être complètement invalide ?

2. Moué, je vais ptêt mettre un place un système de code d'erreur
ok pour le pointeur nul (je pensais que le numéro de version suffisait)

Flanker :
ptêt une fonction compress:ack_info qui renverrait un handle au même format que le handle d'un dossier (ie 4 octets pour le nombre de fichiers, puis 14o par fichiers, dont 8 pour le noms et 6 pour des infos supplémentaires)

et pourquoi pas faire une fonction patch0xC8() qui remplacerait SymFind* pour faire comme si le contenu des packs archive était un répertoire ?

j'ai déjà fait un tsr qui remplace la jump_table, mais ça fait foirer plein de programmes qui se basent sur l'adresse de la jump table pour déterminer le modèle

alors tu peux faire un lanceur et/ou un patch du kernel qui patche les programmes en conséquence
(ou encore tu peux faire en sorte que 0xC8 pointe à une adresse impaire dans la ROM, et tu interceptes les adress error en remplaçant ton 0xC8 foireux par la bonne adresse, en priant pour que les programmes ne fassent pas la détection de la calc *après* avoir fait des appels en ROM utilisant la même valeur de 0xC8 )

lol
autant patcher directement la rom

c'est une idée

ayé, la compression pepzip marche nickel, je vais pouvoir passer à la compression xpak

ayé, la compression xpak marche nickel, je vais pouvoir m'attaquer à la décompression ppg

(j'ai mis plus de temps que prévu, tout ça à cause du bug d'A68k )

Sasume :
lzf0.

j'ai pas trouvé sur google :/

Flanker :
j'ai déjà fait un tsr qui remplace la jump_table, mais ça fait foirer plein de programmes qui se basent sur l'adresse de la jump table pour déterminer le modèle

Sim effectue un patch de la jump table pour émuler ngetchx() sans problème. no_calc_detect.asm patch pour éviter le problème de détection de modèle (pas que pour le problème de la jump table en fait). L'autre problème est GrayOn() par exemple qui recherche l'hardware parm block à partir de $C8 : Sim place un pointeur vers copie du parm block en RAM à $104 (cf kbdemu.c/InstallNgetchxEmu()). il faut en plus se débrouiller pour que l'adresse de la copie soit < $10000 pour être considérée valide par GrayOn() (en utilisant une variable dans la pile par exemple).

Flanker
:

Sasume :
lzf0.

j'ai pas trouvé sur google :/

Ca probablement : http://p080.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=116.topic

ah ok, merci bien

accessoirement, XPAK, KOMP, ZIP et PEP sont déjà supportés pour la compression et la décompression

maintenant, il faut que j'utilise un fichier de conf pour permettre de définir le format de compression par défaut (pour l'instant il faut spécifier le format pour compresser, il est déterminé automatiquement pour décompresser)

il trouve automatiquement les répertoires des programmes de compression ?

ayé, LZFO est ajouté à la liste
Pollux > quand c'est un programme basic (je veux dire, dont l'appel se fait par une commande basic), oui

Comment tu retrouves le format de compression original ?

je regarde juste l'extension

Flanker> y'a moyen que les fonctions soient plus bas niveau, genre :
HANDLE compresslib(HANDLE h, int compType)
parce qu'en fait, j'ai justement fait en sorte de ne pas être dépendant d'un format de compression en particulier dans le hibView que je prépare, et j'ai déclaré :

typedef short (*FctIsComp) (HANDLE h);
typedef HANDLE (*FctUnComp) (short id, HANDLE h);

Ca marche avec ziplib, par contre les autres j'ai pas du tout essayé.

hibou :
Flanker> y'a moyen que les fonctions soient plus bas niveau, genre :
HANDLE compresslib(HANDLE h, int compType)
parce qu'en fait, j'ai justement fait en sorte de ne pas être dépendant d'un format de compression en particulier dans le hibView que je prépare, et j'ai déclaré :

typedef short (*FctIsComp) (HANDLE h);
typedef HANDLE (*FctUnComp) (short id, HANDLE h);

Ca marche avec ziplib, par contre les autres j'ai pas du tout essayé.

c'est en projet
comme pour les autres libs, il faut impérativement passer par un appel basic, je pense utiliser une variable temporaire pour y mettre le handle