Warum sind *.exe's so groß

[thepaul]

Hi,

beim Borland Compiler ist doch immer von sehr kompakten Programmen die Rede. Wenn ich aber meine Programme erstelle, kann ich meistens mit einer ZIP-Komprimierung bis zu 50% Größe einsparen.

Han ich da was falsch eingestellt oder sind die Progs doch nicht sooooooo kompakt?

MfG Paul

[Alexander]

Du hast alles richtig gemacht. Es müssen nur jede Menge an Laufzeit-Krams mitgegeben werden . Normalerweise wird das halt mit in die EXE geschoben, daher auch die Größe.
Bei VB ist das z.B. nicht anders, nur wird das nicht in die EXE geschrieben...
Aber ich will da gar nicht so genau drauf eingehen, da wir das schon öfter hatten

PS: Aber ein Tipp noch: Wenn du kleine Anwendungen schreiben will, dann gibt es 2 Möglichkeiten. Du kannst einmal so Programmieren´, dass du auf die VCL/CLX verzichtet und alles selber übernimmst (nonVCL) oder aber, du kannst mit .NET arbeiten. Da sind die ausführbaren Dateien auch recht klein, aber man hat mit D2005 eine vernünftige IDE, die man auch voll ausreizen kann (mit nonVCL nicht möglich ).

[Robert_G]

Falls du mehreren Echsen ausgeben willst, solltest du dich mal über RunTime-Packages schlau machen.
Dadurch kannst den Riesenbatzen, den die VCL und ein paar andere Packages ausmachen, auslagern. Dadurch musst du sie nur einmal ausliefern um sie in mehreren Echsen zu verwenden.
Nachtrag: Um den Effekt zu sehen musst du nur mal in den Projektoptionen unter Packages "build with runtime packges" aktivieren.
Deine Echse sollte jetzt nur noch ein paar Kilobyte groß sein.
Wenn du nur bestimmte Packages extern verklinken willst löschst du einfach allen anderen aus der Liste (der semikolongetrennte Text unten).

[Nicolai1234]

Zitat von Robert_G:

Nachtrag: Um den Effekt zu sehen musst du nur mal in den Projektoptionen unter Packages "build with runtime packges" aktivieren.
Deine Echse sollte jetzt nur noch ein paar Kilobyte groß sein.
Wenn du nur bestimmte Packages extern verklinken willst löschst du einfach allen anderen aus der Liste (der semikolongetrennte Text unten).

Ich habe das mal gemacht und es funktioniert wirklich, aber wie kann ich die packages "manuell" mit ausliefern, wenn ich jemandem die exe gebe?

[tommie-lie]

Zitat von Nicolai1605:

Ich habe das mal gemacht und es funktioniert wirklich, aber wie kann ich die packages "manuell" mit ausliefern, wenn ich jemandem die exe gebe?

Indem du die Packes aus dem Systemverzeichnis (Endung .bpl) zusammensuchst, die benötigt werden. Inwiefern das Lizenzrechtlich wann und unter welchen Umständen bei welcher Mondphase erlaubt ist, weiß ich nicht.

[Robert_G]

Zitat von Nicolai1605:

Zitat von Robert_G:

Nachtrag: Um den Effekt zu sehen musst du nur mal in den Projektoptionen unter Packages "build with runtime packges" aktivieren.
Deine Echse sollte jetzt nur noch ein paar Kilobyte groß sein.
Wenn du nur bestimmte Packages extern verklinken willst löschst du einfach allen anderen aus der Liste (der semikolongetrennte Text unten).

Ich habe das mal gemacht und es funktioniert wirklich, aber wie kann ich die packages "manuell" mit ausliefern, wenn ich jemandem die exe gebe?

Ich habe mir ein MergeModule mit allen Packages angelegt, die ich IMMER brauche.
Dann noch weitere MergeModule, die Projektbezogen sind.
Das ganze installiere ich in die Common Files (bzw. gemeinsame Dateien) in einen Unterordner. Außerdem füge ich der Umgebungsvariable %PATH% diesen Ordner hinzu.
Wenn ich jetzt ein SetUp erstelle muss ich nur noch die MergeModules hinzufügen und der Rest passiert dann von alleine.
Willst du es "zu Fuss" machen, dann lege einen Ordner (am besten in die common files) an und füge diesen zu %PATH% an. (also wie oben nur halt "zu Fuss" )
Dadurch kann deine Anwendung ganz normal starten. Ohne das die Packages im Anwendungsverzeichnis leigen müssen.

Das ganze ist vielleicht auch für die Hobbyprogrammierer praktisch, die ihre Anwendungen im Internet anbieten.
Ihr könntet einfach sagen das hier braucht ihr für meine Programme, und schon spart ihr Traffic (wenn ein User 2 Apps lädt muss er die Packages nur einmal laden )

@tl
Sinn und Zweck der Trennung von DesignTime & RunTime packages ab D6 war es, genau diese Streitigkeiten zu beseitigen.

[tommie-lie]

Zitat von Robert_G:

@tl
Sinn und Zweck der Trennung von DesignTime & RunTime packages ab D6 war es, genau diese Streitigkeiten zu beseitigen.

Hmm...
Ich meinte jetzt eigentlich namentlich vclXX.bpl und rtlXX.bpl, denn die brauche ich, wenn die die Laufzeitpackages nicht in die EXE linke...
Wenn ich mich recht erinnere ging es bei den Streitigkeiten um die Klassen, die in designXXX.bpls zu finden sind, bzw alles, was sich in %DELPHI%/Bin an Packages befindet. However, brauchen tut man's trotzdem, ob in der EXE oder als Package anderswo, und damit sind wir wieder bei VisualBasic angelangt...

[Prof.Y]

Zitat von Robert_G:

Ich habe mir ein MergeModule mit allen Packages angelegt, die ich IMMER brauche....

Eine Setup.exe läßt sich ganz leicht und billig (=Gratis) mit InnoSetup und die ISTools sehr profimäßig anlegen.
Damit kannst Du trennen:
1 Setup mit FullInstall (Progi + BPL)
oder
1 Setup mit nur Progi + 1 Setup mit nur BPL und gemeinsame Biblios

Die BPLs sollten im Windows-Verzeichnis oder noch besser im "Anwendungsdaten-Verzeichnis" ausgelagert => kein Path-Änderung nötig (was Aufgrund mancher AntiVirus-Software sooderso nicht immer zugelassen wird...)

Weiterhin kannst Du mit InnoSetup einen "Default Setup" anlegen... dann brauchst Du pro Projekt nur noch die Exe hinzuzufügen und das wär's (fast;)

Gruß,

[Garfield]

Eine Alternative:

Ich hatte mehrere Programme unter Delphi 3 Professional und Delphi 7 Personal compiliert und dabei festgestellt, dass die *.EXE unter Delphi 7 Personal deutlich größer geworden sind. Ich packe die *.EXE dann mit UPX. Dadurch werden sie zwischen 50 und 70 % kleiner. Der Bedarf an Arbeitsspeicher steigt allerdings etwas an. Ich hatte das bei einem Programm getestet und da waren es ~10 %.

[Robert_G]

Zitat von Prof.Y:

Zitat von Robert_G:

Ich habe mir ein MergeModule mit allen Packages angelegt, die ich IMMER brauche....

Eine Setup.exe läßt sich ganz leicht und billig (=Gratis) mit InnoSetup und die ISTools sehr profimäßig anlegen.

Dagegen halte ich mit Orca msi
Wer ein VisualStudio sein eigen nennt hat dort schon eingabute SetUp Projects, die sich autom. anhand der Projekte in der Solution voreinstellen. (Sollte Borland UNBEDINGT einführen )
Unter Windows sollte man Installationen IMMER mit MSI machen alles andere sind nur billige Bastellösungen (sorry für die NSIS-Fans, ist leider so )
Nur MSI-Installationen bewahren ein System vor doppelt installierten Bibliotheken oder geklauten Bibliotheken bei einer Deinstallation.
Außerdem schützt Windows dann deine Anwendung installiert beim Klick auf den ShortCut Bibliotheken, die zwischendurch gelöscht wurden (es reparariert eigentlich alles wieder, Registry, environment path,...)

Zitat von Prof.Y:

Damit kannst Du trennen:
1 Setup mit FullInstall (Progi + BPL)
oder
1 Setup mit nur Progi + 1 Setup mit nur BPL und gemeinsame Biblios

Deshalb MergeModules, die definiere ich einmal und muss die nur noch einem Setup hinzufügen.

Zitat von Prof.Y:

Die BPLs sollten im Windows-Verzeichnis oder noch besser im "Anwendungsdaten-Verzeichnis" ausgelagert => kein Path-Änderung nötig (was Aufgrund mancher AntiVirus-Software sooderso nicht immer zugelassen wird...)

Die "common files" sind aber genau dafür da.