EXE kleinstmöglich machen

[freejay]

Hallo,

bisher hat mich die Größe meiner EXEn ja nicht wirklich interessiert, aber im Moment entwickeln wir ein Programm, dass über das Internet upgedatet werden muss. Und da es noch etliche User mit Modemzugang gibt, sollte die EXE kleinstmöglich sein.

Ich habe mal ein leeres Projekt erstellt (ein Fenster mit einem CLOSE-Button) und da hat die EXE bereits knapp 400 kB! Und unsere Schmerzgrenze war eigentlich ca. 300 kB...

Daraufhin habe ich alle Compileroptionen für Debug-Informationen ausgeschaltet und erwartet, dass die EXE deutlich kleiner wird: Sie ist aber nach erneutem Kompillieren exakt genauso groß, wie mit eingeschalteten Debug-Infos!

Wie kann ich denn die EXE "kleinkriegen"?

Gruß

Andreas

[fwsp]

da musst du non-vcl proggen.

[freejay]

und wie soll ich das machen, wenn das Programm eine grafische Benutzeroberfläche haben soll...

[3_of_8]

Als erstes mal: nonVCL Programmierung. Hilft ungemein.

Als nächstes: unnötige Units aus dem uses nehmen. Hilft auch bissel was.

Dann als letztes: Du schreibst sämtliche Delphi Standard Units neu, und zwar als z.B. MySysUtils. Das hilft extrem viel, wenn du nur das reinschreibst, was du auch wirklich brauchst.

EDIT: Schau dir Luckies WinAPI Tutorial an.

[DGL-luke]

Du kannst sie mit UPX (oder inenem anderen exe-packer) packen - die komprimierung ist aber höchstens genausogut wie ein 7zip-sfx (http://7-zip.org), und außerdem gibt es einige nachteile (dei hier schon zu genüge besprochen wurdne, einfach mal nach upx suchen)

Viel besser wäre es, ganz einfach differenzielle Patches zu erstellen. Z.B. VPatch (weiss nicht, ob man da in der DP noch was findet).
ansosnten kannst du NonVCL programmieren. Luckie hat da ein paar tutorials - http://www.michael-puff.de/dirindex....phi/Tutorials/ - win32api-tutorials müsste es sein.

Du verzichtest dann auf VCL-Kompoentne und erstellst die deine fenster und Controls selber, mit Hilfe der WinAPI.

Damit kann man extrem kleine Programme schreiben.

Ansonsten wäre natürlcih ein kompletter Verzicht auf GUI möglich, oder das auslagern der programmlogik (die dann alleine geupdated wird) in eine DLL (mit statischer Linkung ziemlcih bequem möglich).

Was für dich das beste ist, kann man am besten herausfinden, wenn du kurz erklärst, was dein Programm genau machen soll.

[faux]

Desweiteren könntest du Programmteile die du oft Updaten willst/musst in DLLs auslagern.

Grüße
Faux

[3_of_8]

Oder alles in Runtimepackages.

[freejay]

Ok, das schockiert mich alles ganz schön: reine API generierte Oberflächen? Ich will doch das Rad nicht neu erfinden! Aber wenn's nicht anders geht...

Trotzdem natürlich vielen Dank bis hier hin!

Dennoch nochmals nachgefragt: Müsste die EXE nicht kleiner werden, wenn man die Debug-Informationen rausnimmt?

[3_of_8]

Übrigens: Das Rad neu erfindent ist leicht übertrieben. Schau dir mal ein C(++) Programm an, da ist alles nonVCL. Die VCL ist nunmal benutzer(programmierer)freundlich, aber dafür auch groß und etwas langsamer.

[Bernhard Geyer]

Oder du entwickelst für .NET und dann sind deine Anwendungen winzig. Der Anwender muß jedoch auf seinen Rechner erst mal die passende .NET-Version haben. Und dies ist ein ganz schöner Brocken.
Aber mittlerweile hat ein überwiegender Teil der aktuellen PC's .NET 1.1 oder auch schon 2.0 drauf.
Ist damit ähnlich wie Delphi für Win32 und Runtimepackages.

[jbg]

Zitat:

Zitat von freejay

Dennoch nochmals nachgefragt: Müsste die EXE nicht kleiner werden, wenn man die Debug-Informationen rausnimmt?

Bei Delphi werden Debug-Infos in den .dcu Dateien abgelegt und nicht wie bei anderen Compilern in der Exe. Wenn du die Debug-Infos in der Exe haben willst, musst du unter den Projektoptionen/Linker die TD32-Debuginfos aktivieren. Aber dann wird deine Exe mehrere Megabyte groß.

Zitat:

Übrigens: Das Rad neu erfindent ist leicht übertrieben. Schau dir mal ein C(++) Programm an, da ist alles nonVCL.

Klar, denn die haben ja keine VCL, also ist alles non=nicht VCL. :lol: Die meisten (nicht BCB) C++ Programmierer schreiben ihre Windows-Programme mit der MFC, die in 90% der Fälle nicht viel mehr als "das Handle aus dem Parametern der WinAPI Funktion vor den Funktionsnamen mit Punkt getrennt setzen" macht.

Zitat:

Die VCL ist nunmal benutzer(programmierer)freundlich, aber dafür auch roß und etwas langsamer.

Das "groß" kommt davon, dass in der VCL keine Interfaces benutzt werden und somit eine Klasse fast alle anderen mit in das Programm zieht, womit der das Smartlinking nicht mehr richtig greifen kann.

[freejay]

Zitat:

Zitat von 3_of_8

Übrigens: Das Rad neu erfindent ist leicht übertrieben. Schau dir mal ein C(++) Programm an, da ist alles nonVCL.

Doch ich sehe das schon so. Einen einmal erreichten Grad an Unterstützung durch die IDE oder VCL oder andere Komponenten nutze ich um schneller, bessere Software für die User zu entwickeln und möchte ich nicht mehr missen. Ich habe keinerlei Interesse daran Dinge, die einfach gelöst werden können (weil's dafür Komponenten o.ä. schon gibt) nochmal zu erfinden. Außerdem entsteht durch das Verwenden bestehender, lang erprobter Lösungen/Komponenten/etc. ein höherer Grad an Zuverlässigkeit (zumindest theoretisch...) und man kann sich auf die wirklich wichtigen Dinge konzetrieren: Funktionalität und Ergonomie. Die eingesetzte Technik ist - zumindest in meinem Umfeld - nicht das Entscheidende.

[3_of_8]

Ich auch nicht - aber wenn mans ganz klein haben will, ist es eine gute Möglichkeit.

Und: Das Rad neu erfinden heißt für mich, die komplette EXE mit nem HEX-Editor schreiben. ;)

[freejay]

Danke an alle!

[DGL-luke]

jbg: Der Delphi-Compiler kennt Smartlinking?!

[jbg]

Zitat:

Zitat von DGL-luke

jbg: Der Delphi-Compiler kennt Smartlinking?!

Klar. (Wobei der Delphi-Compiler zugleich der Linker ist).

Hier ein einfaches Beispiel:

Delphi-Quellcode:

program Test;

  procedure TestProc;
  begin
    WriteLn('Diese Prozedur wird gar nicht in die Exe-Datei aufgenommen und hat auch keine blauen Punkte links stehen');
  end;

* begin
*   WriteLn('MyProgram');
*   ReadLn;
* end.

[DGL-luke]

und was ist mit dem da:

Delphi-Quellcode:

unit uImportant;

interface

procedure NeverUsed;
procedure Used;

implementation


procedure NeverUsed;
begin
  DoSomeThingIrrelevant;
end;

procedure Used;
begin
  DoSomeThingRelevant;
end;

end.

und jetzt das Programm:

Delphi-Quellcode:

program Test;

{$APPTYPE CONSOLE}

uses uImportant;

begin
  Used;
end;

Wird NeverUsed mitgelinkt?

[Namenloser]

Compiliers doch und schau, ob daneben blaue Punkte stehen :wink:

[Nils_13]

Übertreibt ihr da nicht ein bisschen ? Ein nonVCL-Programm ist verdammt klein, hier geht es nur noch um Bytes/KB. Bis man sich dann die Units geschrieben hat, kann man doch gleich mit Assembler unter z.B. Win32 anfangen. In Assembler wird dann aus der 300 eine 3.

[Go2EITS]

@freejay
Also 400 KB sind nicht viel, auch für ein normales 56K Modem nicht.
Und mit UPX bist zur Komprimmierung der EXE gut bedient.

NonVCL ist nur eine Alternative, wenn Du Zeit hast Dich damit auseinanderzusetzen.
Da kannst Du durch das Weglassen einiger in der Uses Klauses stehenden Units Platz sparen.
Das schnellste Ergebnis im Verhältnis zur Zeit hast Du ohne NonVcl.

Beste Grüße
Go2EITS

[Daniel G]

Zitat:

Zitat von Go2EITS

Und mit UPX bist zur Komprimmierung der EXE gut bedient.

Wobei man dann lieber direkt ein Zip - Archiv nehmen und diesen dämlichen Exe - Compressor weglassen kann...

[DGL-luke]

Zitat:

Zitat von Go2EITS

Und mit UPX bist zur Komprimmierung der EXE gut bedient.

MÖÖP

UPX

UPX zerstört dir das komplette Sperichermanagement von Windows, wie bereits geschrieben habe. dann lieber ein SFX.

@freejay: Hast du denn meinen Beitrag gelesen? http://www.delphipraxis.net/internal...=589656#589656

[Go2EITS]

@daniel G
Die Probleme kannte ich noch nicht mit UPX. Das sehe ich mir mal an...
Aber der Kunde bekommt eine EXE.
Ein Zip bedeutet, dass das Programm erst das Update entzippen muss und dann die alte EXE mit der
neuen EXE überschreiben muss. Ob er dies der Threadersteller will?

Kann es sein, dass einige Router die EXE nicht durchlassen?????? :roll:

[Nachtrag]
Phoenix hat in seinem Beitag mit UPX keine Probleme. Für den Zweck wird es reichen.
UPX! Fragwürdig?
[/Nachtrag]

[DGL-luke]

Zitat:

Zitat von Go2EITS

Ob er dies der Threadersteller will?

wir wissen leider nicht, was er will :roll:

[sniper_w]

Zitat:

Zitat von 3_of_8

Schau dir mal ein C(++) Programm an, da ist alles nonVCL.

Das etwas mit oder ohne VCL gemacht wird, hat nichts mit C / C++ oder Delphi Sprache zu tun, sondern lediglich mit der IDE.

[Meflin]

Tja, die beste Möglichkeit die Exe klein zu bekommen dürfte wohl - wie bereits erwähnt - die Verwendung des .Net Frameworks sein.

UPX (und andere Exe-Packer) so kategorisch abzulehnen wie gotos (*hüstel*) halte ich für grundsätzlich falsch. Ich sehe ein dass es keinen sinn macht eine 100MB-Exe zu UPXen, bei einer 1MB-Exe dürfte das das Windows Speichermanagement aber heutzutage herzlich wenig stören ;)

Bei verwendung von Zip o.ä. bleibt eben immer, dass man mitunter auch noch kostenpflichtige Zusatzsoftware braucht - bei .Net gewissermaßen zwar auch, aber das kostet nix und ist sowieso meistens vorinstalliert.

Ergo: -> .Net

[jbg]

Zitat:

Zitat von Meflin

und ist sowieso meistens vorinstalliert.

Lebst du in einer anderen Welt als ich? Bis jetzt ist mir nur die Vista BETA untergekommen, bei der das .NET Framework vorinstalliert ist.

[Daniel G]

Zitat:

Zitat von jbg

Zitat:

Zitat von Meflin

und ist sowieso meistens vorinstalliert.

Lebst du in einer anderen Welt als ich?.

1.1 ist zumindest schon auf der Windows xp CD mit drauf, was ich aber vorher auch nicht gewusst habe... :gruebel:

[Nils_13]

Bei mir war es nicht vorinstalliert. Das Netframework ist hinzu auch noch groß und muss erst installiert werden. Dadurch sinkt die Komfortablität der Anwendung und sie wird im Prinzip nur noch größer.

[jbg]

[quote="Daniel G"]

Zitat:

Zitat von jbg

1.1 ist zumindest schon auf der Windows xp CD mit drauf

Nur auf den neueren (ab 2005). Und viele haben ihr Windows schon vor 2005 (mit-)gekauft.

[DGL-luke]

Zitat:

Zitat von Meflin

Bei verwendung von Zip o.ä. bleibt eben immer, dass man mitunter auch noch kostenpflichtige Zusatzsoftware braucht

7-zip sfx - kostet nix und ist fast immer kleiner als zip.

alternativ im updater das 7zip-backend (sollts als dll geben) integrieren.

Sollte ich mal update brauchen, werd ichs wohl so machen:

1. Dateistruktur erstellen

/versions/Ma.Mi.Re.Bl/program.exe
(Major,Minor,Revision,Build)

2. VPatch drüber laufen lassen, ergebnis program_Ma.Mi.Re.Bl_to_latest.upd

3. Ergebnisse mit 7zip komprimieren

Das updateprogramm holt sich per FTP die benötigte (self)Ma.Mi.Re.Bl_to_latest_.7zip, entpackt sie, und lässt sie vom VPatch-Updater auf die exe patchen.

Aber wie gesagt - was der threadersteller will, wissen wir noch nciht genau.

[Daniel G]

Zitat:

Zitat von jbg

Nur auf den neueren (ab 2005). Und viele haben ihr Windows schon vor 2005 (mit-)gekauft.

Stimmt, auf den alten ist noch 1.0 drauf, hatte ich verwechselt...

[Coder]

Mhh, wenn es möglichst klein sein soll...
mit VCL.
Wer noch kleinere Exes haben möchte, sollte downgraden.
Ich habe ein Projekt (leere Exe, ohne Komponenten, Codezeile) mit Delphi 3 Pro compiliert.
181.248 Byte.
NonVCL fängt bei 20 kB an, KoL auch etwa.

jeweils nur die .exe komprimiert

Delphi-Quellcode:

04.08.2006  23:58               76.089 mini.uha
04.08.2006  23:41               77.824 Mini_Pecompact.exe
04.08.2006  23:57               77.548 Mini.7z
04.08.2006  23:41               80.384 Mini_upx.exe
04.08.2006  23:56               81.868 Mini.rar
04.08.2006  23:41               83.968 Mini_aspack_Trial.exe
04.08.2006  23:55               97.832 Mini.zip
04.08.2006  23:41  Original >> 181.248 Mini.exe     

               8 Datei(en)        756.761 Bytes

mini_unit.zip (647 KB)

http://rapidshare.de/files/28223873/...packt.zip.html

^^ wer sich das mal anschauen möchte
ist incl. Source

[Luckie]

Bitte häng die Datei an, dazu gibt es das Feature. Bei Rapidshare brauche ich immer fünf Minuten bis ich den Donloadlink irgendwo auf der Seite gefunden habe und weiß dann doch nicht, ob ich morgen nicht doch fünf Waschmaschinen geliefert bekomme. :roll:

[Meflin]

Zitat:

Zitat von jbg

Lebst du in einer anderen Welt als ich? Bis jetzt ist mir nur die Vista BETA untergekommen, bei der das .NET Framework vorinstalliert ist.

Scheint so. AFAIR (aber ich kann da irren) ist das .Net-Framework im SP2 integriert, evtl auch shcon im SP1. Und wer ohne SP2 unterwegs ist, dem kann man auch nicht mehr helfen :lol: ;)

Zitat:

Zitat von DGL-luke

7-zip sfx - kostet nix und ist fast immer kleiner als zip.

Ich schrieb ja auch explizit "mitunter". Außerdem kann es dir bei einem solch relativ kleinen Anbieter schnell passieren, dass sich die Lizenzen ändern. Viele gute ehemalige Freeware kostet heute.

Zitat:

Zitat von Nils_13

Bei mir war es nicht vorinstalliert.

Aber du hast es oder?

Zitat:

Dadurch sinkt die Komfortablität der Anwendung

ähh... was bitte?

Zitat:

und sie wird im Prinzip nur noch größer.

Interessante Logik. Dein Programm braucht Windows, also ist es im Prinzip 6 GB Groß und verdammt unkomfortabel oder was :gruebel:

[Hador]

Zitat:

Zitat von Meflin

Zitat:

Zitat von DGL-luke

7-zip sfx - kostet nix und ist fast immer kleiner als zip.

Ich schrieb ja auch explizit "mitunter". Außerdem kann es dir bei einem solch relativ kleinen Anbieter schnell passieren, dass sich die Lizenzen ändern. Viele gute ehemalige Freeware kostet heute.

Die alte Version bleibt dann aber immer noch unter der ehemaligen Lizenz verfügbar.
Sie können nicht einfach sagen: "Du hast vor 10 Jahren kostenlos ein Programm von uns bekommen, jetzt will ich aba Geld dafür haben. Oder du musst es ausbauen."

Daher:
- Dateien mit 7z packen
- 7z-Dll in Programm integrieren (wird automatisch entpackt)
- oder zip nehmen. Dass sollte immer kostenlos entpackbar sein.
- oder eigenen Algo implementieren (Ansätze gibt es schon in der CodeLib)

[Meflin]

Zitat:

Zitat von Hador

Die alte Version bleibt dann aber immer noch unter der ehemaligen Lizenz verfügbar.
Sie können nicht einfach sagen: "Du hast vor 10 Jahren kostenlos ein Programm von uns bekommen, jetzt will ich aba Geld dafür haben. Oder du musst es ausbauen."

Naja, da kenne ich mich rechtlich nicht genug aus. Ich denke doch dass sie sagen können: du darfst unsere Software nicht mehr so einfach mit deiner weitergeben, aber ka.
Die sauberste Lösung wäre in dem Fall wohl tatsächlich ein eigenes Packverfahren, oder die Verwendung eines Open Source Algorithmus.

[Daniel G]

Zitat:

Zitat von Meflin

oder die Verwendung eines Open Source Algorithmus.

so wie den aus der CL?

Huffman