Question

À un moment donné, j’avais un joli petit utilitaire de compression qui écrasait les fichiers EXE compilés de Delphi avec une taille de téléchargement plus petite, mais je ne parviens pas à le trouver. Des recommandations?

De plus, y a-t-il des inconvénients à utiliser ces types d’utilitaires? (Je les utilise principalement pour raccourcir les temps de téléchargement pour les utilisateurs ruraux / par modem).

Question associée: Existe-t-il des inconvénients à l’utilisation de UPX pour compresser un exécutable Windows?

Était-ce utile?

La solution

Il y a des années, j'ai envisagé de compresser mon exécutable pour réduire le téléchargement.

Ce que j’ai finalement fait et ce que je vous recommande, c’est d’utiliser un programme d’installation tel que Configuration Inno à la place. Non seulement cela crée un seul fichier EXE qui installera / désinstallera votre programme, mais il compresse également ce fichier EXE presque autant qu'un compresseur séparé ferait à votre exécutable seul.

Lorsque le programme est installé, il est décompressé. Il ne semble donc jamais être un virus et n'augmente pas le temps de chargement.

Ainsi, je bénéficie des avantages d’une taille de téléchargement réduite et d’un script d’installation professionnel.

p.s. Inno Setup est gratuit.

Autres conseils

Nous vous recommandons de ne pas:

  • Les compresseurs EXE peuvent donner l’apparence d’un virus à votre application (auto-modification)
  • Les fichiers gzip / zip sont tout aussi efficaces pour la compression et ne bricolez pas votre application
  • Les compresseurs EXE augmentent les temps de chargement de votre application (à moins que vous ne parliez que du programme d'installation, ce qui est différent

Ce site à la folie soulève un argument que j'avais entendu dans un passé lointain (que ce soit vrai ou non, je ne suis pas sûr qu'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 qui est   appelé une "mémoire virtuelle". système. Quand   les programmes commencent, tout leur code est   non chargé en mémoire immédiatement   au démarrage, comme ce fut le cas sous DOS   programmes. Au lieu de cela, seules des portions de   le code étant activement exécuté sont   stocké en mémoire. Par exemple, disons   votre programme a une option Imprimer sur son   menu, et le code derrière ce qui gère   l'impression. Ce code ne sera que   chargé en mémoire une fois l'impression   Cette fonctionnalité est d'abord sélectionnée par l'utilisateur.   Et si après le code est chargé dans   mémoire, la fonction d'impression n'est pas utilisée   pendant un certain temps, le système "rejettera"   le code, libérant la mémoire il   occupé, si une autre application   a désespérément besoin de mémoire. Cela fait partie   d'un processus appelé "paging". et est   complètement transparent pour le programme.

     

Une autre façon de paginer sous Win32   conserve la mémoire est-il cause de multiples   instances d'un programme (ou DLL) à   partager la même mémoire pour le code. Dans   autrement dit, sous la normale   circonstances il n'y a pas de réel   différence dans la quantité de physique   mémoire allouée pour le code entre   démarrage de 100 instances d'un programme   et en commençant une instance.

     

Si tous les programmes Win32 se comportaient comme   Programmes DOS, tout charger dans   la mémoire et le garder jusqu'à la   programme terminé et aussi pas   partager toute mémoire entre plusieurs   des cas, vous pouvez probablement imaginer   à quelle vitesse la mémoire physique pourrait fonctionner   sur les 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   Les compresseurs EXE Win32 font à votre   EXE / DLL! Ils vont complètement   contre le système de pagination du système d'exploitation par   décompresser tout le code en mémoire et   le garder là jusqu'à la fin.   Et parce que le code n'est pas stocké dans un   " raw " format dans le fichier EXE (c’est-à-dire le   de la même manière, il est stocké en mémoire), le   Le système d'exploitation ne peut pas partager le code entre   plusieurs instances.

Je n'en connais aucun qui soit spécifiquement destiné à Delphi, mais UPX est très populaire pour cela. genre de chose. Le seul inconvénient est que l'exécutable doit être décompressé lors de son lancement, ce qui peut prendre du temps. Cela semble être très rapide pour les exécutables de taille raisonnable, cependant.

Celui auquel vous songez probablement est ASPack . Il s'agit d'un compresseur EXE écrit en Delphi, mais va compresser n'importe quel EXE. Cela pourrait très bien fonctionner avec les fichiers EXE de Delphi. Je conviens avec les autres réponses qu'il ne faut pas utiliser un compresseur EXE pour économiser sur les temps de téléchargement. Il peut y avoir des situations spécifiques où une compression EXE est une bonne idée, mais ce n’est généralement pas le cas.

Utilisez plutôt un bon générateur d’installation, surtout si vous pouvez en trouver un qui utilise la compression 7zip. Je sais que 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.

Sinon, vous pouvez créer une archive auto-extractible avec un comportement d'installation de base avec 7zip gratuitement. Il s’agit d’un téléchargement séparé pour les SFX pour les installateurs.

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

upx --lzma yourfile.exe

Le principal inconvénient d'un fichier EXE ou DLL compressé est que le système d'exploitation ne peut pas partager le code entre plusieurs instances.
Donc, vous gaspillez de la mémoire, vous devez décompresser chaque fois que vous démarrez une instance, afficher un comportement semblable à un virus sans même un avantage de téléchargement par rapport à une installation compressée.
Seul le cas positif concerne un lancement direct à partir d’un lecteur réseau.

Je pense que les serveurs Terminal Server (comme Citrix) utiliseront la même mémoire que le binaire de votre application si elle est décompressée. Ce qui signifie qu'un fichier compressé peut sentir un petit désastre dans un environnement Citrix.

UPX devrait fonctionner, bien que ce ne soit pas spécifique à Delphi.

Je voterais aussi pour upx. Outre les inconvénients mentionnés, il protège également de l’ingénierie inverse de base et de ces "hacker de ressources" boiteux. outils. En passant, ils sont nombreux et la plupart d’entre eux ne parviennent pas à ouvrir un fichier exécutable compressé.

J'ai posé une question sur les inconvénients de l'utilisation d'UPX sur les exécutables Delphi ici sur SO il y a quelque temps, et j'ai obtenu d'excellentes réponses.

Existe-t-il des inconvénients à Vous utilisez UPX pour compresser un exécutable Windows?

Vous pouvez utiliser PECompact , car les utilisateurs ne peuvent pas le décrypter facilement. (indiqué sur la page principale, faites juste défiler un peu) c’est mieux que ASPack ou UPX, je l’utilise sur mes précédents projets Delphi

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top