Compresseur Delphi EXE ?

Question

À un moment donné, j'avais un petit utilitaire de compression qui réduisait la taille de téléchargement de mes EXE compilés en Delphi, mais maintenant je ne le trouve plus. Des recommandations ?

Par ailleurs, y a-t-il des inconvénients à utiliser ce type d'utilitaires ? (Je les utilise principalement pour raccourcir les temps de téléchargement pour les utilisateurs ruraux / dial-up).

---

Question connexe : Y a-t-il des inconvénients à utiliser UPX pour compresser un exécutable Windows ?

Answer 1

Il y a quelques années, j'ai envisagé de compresser mon exécutable pour réduire la taille du téléchargement.

Ce que j'ai fini par faire, et ce que je vous recommande, est d'utiliser un programme d'installation tel que Inno Setup à la place. Non seulement il crée un seul EXE qui installera/désinstallera votre programme, mais il compresse également cet EXE pratiquement autant qu'un compresseur séparé le ferait pour votre exécutable seul.

Lorsque le programme est installé, il est décompressé, de sorte qu'il n'apparaît jamais comme un virus et n'augmente pas les temps de chargement.

Je bénéficie ainsi d'un téléchargement de taille réduite et d'une installation d'aspect professionnel script en même temps.

p.s. Inno Setup est gratuit.

Answer 2

Nous vous recommandons de ne pas le faire :

• Les compresseurs EXE peuvent faire ressembler votre application à un virus (auto-modification)
• gzip/zip sont tout aussi efficaces pour compresser et ne modifient pas votre application.
• Les compresseurs EXE augmentent le temps de chargement de votre application (à moins que vous ne parliez que du programme d'installation, ce qui est différent).

Ce site à l'allure folle me rappelle un argument que j'ai entendu dans un passé lointain (je ne suis pas sûr qu'il soit encore vrai aujourd'hui, les emballeurs modernes ont probablement une stratégie différente aujourd'hui). Cet article fait référence à Win32 ! :)

http://topic.csdn.net/t/20000408/08/6785.html

Les systèmes d'exploitation multitâches modernes tels que Windows 95/98 et NT utilisent ce que l'on ce qu'on appelle un système de "mémoire virtuelle". Lorsque programmes démarrent, tout leur code n'est n'est pas chargé en mémoire immédiatement au démarrage, comme c'était le cas avec les programmes DOS. comme c'était le cas avec les programmes DOS. Au lieu de cela, seules des parties du du code en cours d'exécution active sont stockées en mémoire. Par exemple, disons que votre programme a une option d'impression dans son menu, et du code derrière lui qui gère l'impression. Ce code ne sera chargé en mémoire que lorsque la fonction est sélectionnée pour la première fois par l'utilisateur. Et si, après le chargement du code en mémoire mémoire, la fonction d'impression n'est pas utilisée pendant un certain temps, le système "élimine" le code. le code, libérant ainsi la mémoire qu'il mémoire qu'il occupait, si une autre application a désespérément besoin de mémoire. Cela fait partie d'un processus appelé "pagination" et est complètement transparent pour le programme.

Une autre façon de paginer sous Win32 conserve la mémoire est qu'elle permet à plusieurs d'un programme (ou DLL) à partager la même partagent la même mémoire pour le code. Sur Autrement dit, dans des circonstances circonstances normales, il n'y a pas de réelle différence dans la quantité de physique allouée au code entre le démarrage de 100 instances d'un programme et le démarrage d'une seule instance.

Si tous les programmes Win32 se comportaient comme programmes DOS, en chargeant tout en mémoire mémoire et le gardant jusqu'à ce que le jusqu'à ce que le programme se termine et aussi sans partageant aucune mémoire entre plusieurs instances, vous pouvez probablement imaginer à quelle vitesse la mémoire physique peut s'épuiser sur des systèmes avec une quantité limitée, provoquant le démarrage de l'échange de disque.

Pourtant, c'est précisément ce que l'actuel compresseurs d'EXE Win32 actuels font à vos EXE/DLL ! Ils vont complètement contre le système de pagination de l'OS en décompressant tout le code en mémoire et et le gardent là jusqu'à la fin. Et parce que le code n'est pas stocké dans un format "brut" dans le fichier EXE (c'est-à-dire de la même la même manière qu'il est stocké en mémoire), le OS est incapable de partager du code entre plusieurs instances.

Answer 3

Je n'en connais aucun qui soit spécifique à Delphi, mais UPX est très populaire pour ce genre de choses. Le seul inconvénient est que l'exécutable doit être décompressé lorsqu'il est lancé, ce qui peut prendre un certain temps. Il semble cependant être très rapide pour les exécutables de taille raisonnable.

Answer 4

Celui auquel vous pensez probablement est ASPack - Il s'agit d'un compresseur d'EXE écrit en Delphi, mais qui peut compresser n'importe quel EXE. Il peut cependant être particulièrement efficace sur les EXE Delphi. Je suis d'accord avec les autres réponses : vous ne devriez pas utiliser un compresseur d'EXE uniquement pour gagner du temps de téléchargement. Il peut y avoir des situations spécifiques où un compresseur d'EXE est une bonne idée, mais en général, ce n'est pas le cas.

Utilisez plutôt un bon constructeur d'installation, surtout si vous en trouvez un qui utilise la compression 7zip. Je sais InstallAware utilise 7zip en interne pour une compression maximale. Selon les versions de Delphi que vous possédez, vous pouvez également disposer d'une licence InstallAware.

Si ce n'est que vous pouvez construire une archive auto-extractible avec un comportement d'installation basique avec 7zip gratuitement. Il s'agit d'un téléchargement séparé pour les SFXs pour les installateurs.

Answer 5

Utilice UPX avec l'option lzma pour une compression maximale.

upx --lzma yourfile.exe