Discussion :

[bvsud]

Bonjour à tous

Suite à l'information donnée par Paul Toth, lors de ma question http://www.developpez.net/forums/d15...aucoup-lourds/ sur les EXE devenus très lourds, j'ai regardé les options de compilation.

Que j'active ou non certaines options (informations de débogage, optimisation, etc) je me retrouve avec un EXE du même poids. A l'octet près.

Pourquoi ?

[Lung]

Tu as testé les modes de construction ?
Sous XE7, mon dernier projet pesait 12,5 Mo en débug et 2.5 Mo en release.

[bvsud]

"Mode de construction" : peux-tu préciser ?

Pour celui auquel je pense, c'est un projet Win32. Il y a 8 boutons, un Statusbar, 3 Groupbox, un menu général, un TJvSHFileOperation, un TJvSearchFiles, 4 JvPopupMenu, deux ou trois labels. Un thème, aussi, mais de Delphi, pas un truc extérieur.

Les options sont ici :

[Thierry Laborde]

Bonjour,

En fait Lung parle du gestionnaire de projets :

http://docwiki.embarcadero.com/RADSt...ire_de_projets

Dans lequel on peut choisir une configuration de construction (Par défaut il y en a 2 : DEBUG et RELEASE, mais on peut en créer d'autres). Et quand on compile avec la configuration RELEASE l'exe est beaucoup plus petit.

[dehorter olivier]

Bonjour,

En fait Lung parle du gestionnaire de projets :

http://docwiki.embarcadero.com/RADSt...ire_de_projets

Dans lequel on peut choisir une configuration de construction (Par défaut il y en a 2 : DEBUG et RELEASE, mais on peut en créer d'autres). Et quand on compile avec la configuration RELEASE l'exe est beaucoup plus petit.

Il me semblait bien qu'il y en a 2 (debug et release); mais sur mon projet je ne vois que DEBUG (pour l'instant cela me convient) mais aurais-je fait un bêtise ? Y a t-il un moyen de la faire réapparaitre ? Sinon, pas de problème, je reconstruirai les options

a+

[Paul TOTH]

un projet standard créé avec Delphi XE7 propose les deux environnements, mais un clic droit sur "Configuration de construction" permet d'en créer autant qu'on veux


le nom n'a aucune importance, c'est juste un libellé qui permet de regrouper une série d'options.

dans la fenêtre "Options de projet" il est aussi possible d'Enregistrer et d'Appliquer (charger) une configuration, il est donc possible de récupérer le debug/release d'un projet vierge vers un projet existant

[dehorter olivier]

dans la fenêtre "Options de projet" il est aussi possible d'Enregistrer et d'Appliquer (charger) une configuration, il est donc possible de récupérer le debug/release d'un projet vierge vers un projet existant

C'est ce que je vais faire, merci

[bvsud]

Effectivement, ça change tout.

Je pense que les librairies d'exécution seront toujours dans l'EXE, de sorte à pouvoir exécuter celui-ci même lorsque Delphi n'est pas installé.

Ce qui m'inquiète, c'est ça :



"Lier avec les packages d'exécution". Ici, la photo a été prise avec une version Debug. En realease, ça reste exécutable, en principe, malgré ce False sur "Lier avec les packages d'exécution" ?

[ShaiLeTroll]

Activer "Lier avec les packages d'exécution" implique le déploiement des BPL énumérés
Si tu as un grand nombre d'exe et de dll, cela a tout son sens et permet d'échanger des objets entre Exe et DLL
A voir si les BPL sont installés dans System32, dans un chemin ajouté au PATH ou dans le même répertoire que les exe et dll

Si tu n'as qu'un gros EXE, le déploiement en laissant intégré les bibliothèques sera plus facile
Ensuite, un petit coup de UPX et un EXE en release de 15Mo passe à 3Mo !

Le même EXE en Debug monte à 56Mo !

[bvsud]

UPX : comme LZEXE ? http://bellard.org/lzexe.html

Un bijou de programmation assembleur. Ds une boîte de l'Allier (années 90), j'ai appris qu'avec l'accord du créateur, un programmeur avait lu son source, et avait écrit le soft inverse : UNlzexe.

Si ça fonctionne comme sous MSDOS, ça ne devrait pas ralentir le lancement de l'application.

P.S. : Unlzexe était écrit en C

[Paul TOTH]

UPX : comme LZEXE ? http://bellard.org/lzexe.html

Un bijou de programmation assembleur. Ds une boîte de l'Allier (années 90), j'ai appris qu'avec l'accord du créateur, un programmeur avait lu son source, et avait écrit le soft inverse : UNlzexe.

Si ça fonctionne comme sous MSDOS, ça ne devrait pas ralentir le lancement de l'application.

P.S. : Unlzexe était écrit en C

les compresseurs d'exe ont un impact désastreux sur la gestion mémoire, au lieu d'avoir un chargement par portion de l'application selon ses besoins, tout est chargé d'un coup.

[bvsud]

Alors, ça a changé.

Sous MSDOS, impossible de faire la différence - enfin, à l'oeil nu. Même avec des XT, pas des AT.

Donc, ne pas utiliser de compresseur. Je vais bosser ces modes de construction.

[Paul TOTH]

Alors, ça a changé.

Sous MSDOS, impossible de faire la différence - enfin, à l'oeil nu. Même avec des XT, pas des AT.

Donc, ne pas utiliser de compresseur. Je vais bosser ces modes de construction.

sous MSDOS tu pouvais aussi fonctionner par Overlay, et là je doute qu'un compresseur soit compatible puisque l'idée des Overlay est là encore de charger le programme par portions.

[bvsud]

Oui, les overlay !

C'était très difficile à programmer, déboguer davantage encore, mais surtout pas très fiable. Beaucoup de progs plantaient là-dessus. Je leur préférais des modules EXE s'appelant les uns les autres. Et puis c'était plus "clair", plus limpide, au niveau programmation.

Quand ça marchait, Les types qui faisaient ça en étaient fier. On comprend pourquoi. Ability, un intégré, jouait là-dessus. Mais avec lui, ça ne marchait pas. "Il s'est bien vendu" me disait un commercial (qd-même très technique), mais il était buggué. C' est dommage".