PpHd, si c'est utilisable en _nostub sans un 3ème fichier (librairie de décompression), si le décompresseur n'est pas plus gros que le gain de place par rapport à ttpack, et si ce n'est pas trop lent, peut-être qu'on l'utilisera.
1. "BSS", donc le programme à lancer est en mode kernel, n'est-ce pas? Donc pour moi, ce n'est pas utilisable en _nostub (pour moi, "utilisable en _nostub" = ne nécessite pas de kernel = il existe une version _nostub).
2. Il faut lancer ton programme, donc il n'est pas utilisable sans un 3ème fichier, même pas en mode kernel.
-> Le premier critère (utilisable en _nostub sans un 3ème programme) n'est pas rempli du tout. Donc ton implémentation est beaucoup moins pratique que ttpack. Je la retiens même inutilisable, et pour un programmeur 100% _nostub, elle l'est en effet.
Passons maintenant à la critique de l'algorithme:
16 KO, c'est vraiment excessif! (Un éventuel lanceur qui utiliserait ta technique de compression ne tournerait jamais avec HW2 AMS 2.00-2.03 sans soit un patch, TSR et/ou kernel, soit un autre lanceur, donc un 3ème programme.) Pour un programmeur en _nostub, pour des raisons techniques, la taille maximale acceptable pour un algorithme de compression est 7 KO, ce qui donnerait un lanceur de 8 KO, et là encore, ça serait limite.
Donc, désolé, mais je ne vois aucun usage pour ta technique de compression, même si tu faisais une implémentation en _nostub avec un lanceur personnalisable (c'est ce que je voulais dire par "l'algorithme doit être utilisable en _nostub sans un 3ème fichier" - il doit être implémentable dans un lanceur pour maintenir le système à 2 fichiers).
Et donc pour moi, ta technique de compression ne mettra pas tout le monde d'accord (en tout cas pas moi) comme tu avais promis.
D'ailleurs:
>Sauf que l'utilisation de ttpack pour compresser des donnees externes est idiot.
>Un : 2Ko de routines pour le decompresseur de programme.
>Deux : 2Ko de routines pour le decompresseur des images.
>Donc le gain de 2 Ko est perdu pour le doublage de la routine...
ttpack compresse normalement à 2/3 de la taille d'origine - parfois même mieux - donc:
1. On ne perdrait que 4/3 KO.
2. Si on a plus de 4 KO de données, on gagne plus que ce qu'on perd. Si on a autant de données que SMA, on peut gagner une centaine de KO!
[edit]Edité par Kevin Kofler le 18-09-2001 à 22:52:33[/edit]
>install() ?
Ah donc se moquerait-il carrément de moi?
PpHd???
Un : 2Ko de routines pour le decompresseur de programme.
Deux : 2Ko de routines pour le decompresseur des images.
Donc le gain de 2 Ko est perdu pour le doublage de la routine...
Si tu es pas bete, tu as normalement un prog en basic ki lance avec un seul decompresseur tt les ppg (et pas un lanceur par jeu, ce k je trouve effectivement debile) ou encore un shell genre ash ou d'autres ki devraient arriver tres bientot... donc il n' y a (plus) k 2Ko de perdu
[edit]Edité par Aghnar le 19-09-2001 à 18:45:31[/edit]
PpHd Le 19/09/2001 à 18:52 Non, je parlais du cas ou le porgramme se servait de l'extracteur lui meme.
