Minimale Exe-Datei- bzw. Compilatsgröße VCL-freier Delphiprogramme

[Delphi-Laie]

Hallo Delphifreunde!

Interessiert am VCL-freien Programm LuckiePing, konnte ich die dem Archiv beiliegenden Quelltexte auch compilieren, und das gelang mir (aufsteigende Delphiversionsnummern) ab Delphi 4. Soweit mir bekannt, steigt die Größe der Compilate mit jeder Delphiversionsnummer immer mehr an. Ein kleineres Compilat als das mit Delphi 4 erhaltene ist es deshalb vermutlich nicht möglich.

Doch die erhaltene Exe-Dateigröße ist mit 74 kByte immer noch fast doppelt so groß wie das beigelegte Original (38 kByte). Funktional kann ich keinen Unterschied zwischen beiden erkennen. Es scheint im kleineren Original vor allem der "untere" bzw. "hintere" Teil verkleinert zu sein bzw. zu fehlen, der eher den "nichtausführbaren" Teil der Exe-Datei ausmacht, was ja auch logisch ist.

Nun meine Frage: Weiß jemand, mit welchen Zaubereinstellungen man solch kleine Exe-Dateien erhält, in denen der redundante Teil signifikant verringert wird?

Ein Packer wie upx scheint nicht angewandt worden zu sein, dafür ist auch im kleineren Exe-Datei-Original noch zu viel "Quelltext" zu erkennen.

Viele Grüße

Delphi-Laie

[lbccaleb]

Vllt. wurde das Programm mit kleineren Units, als den Standart Delphi Units compiliert. Du kannst die Datei Größe reduzieren, indem du zb. die System.pas bearbeitest. Assarbad hatte da mal was auf seiner Webseite.

[p80286]

Wie sieht's aus mit Bereichsüberprüfung und Konsorten?
Das ist ja auch nicht ohne ein Mehr an Code zu bekommen!

Gruß
K-H

[Delphi-Laie]

Zitat:

Zitat von lbccaleb (Beitrag 1165388)

Vllt. wurde das Programm mit kleineren Units, als den Standart Delphi Units compiliert. Du kannst die Datei Größe reduzieren, indem du zb. die System.pas bearbeitest. Assarbad hatte da mal was auf seiner Webseite.

Ja, danke, daran dachte ich auch schon.

Bei mir ist allein schon die Summe der Unit-Compilate (dcu-Dateien) größer als die beigelegte Exe-Datei. Also müssen die abgespeckten Standardunits (entweder als Quelltext oder in compilierter Form) auch den beigefügten Units "untergeschoben" werden, meine ich.

Auf Assarbads Webseite fand ich zwar schon sehr viel, aber dazu noch nichts. Eigene diesbezügliche Experimente waren bisher nicht erfolgreich, aber das war auch inklusiv VCL, wo fast alles von allem abhängt.

[Delphi-Laie]

Zitat:

Zitat von p80286 (Beitrag 1165392)

Wie sieht's aus mit Bereichsüberprüfung und Konsorten?

In den Projektoptionen->Compiler?

Ich experimentierte auch schon mit den Optionen im Compiler- und Linker-Reiter (auch beim Debug), jedoch ohne irgendwelche erkennbaren Auswirkungen auf die Compilatsgröße.

Des Pudels Kern ist, daß in der "besseren" Exe-Datei die Redundanz im hinteren Teil verringert oder beseitigt ist/wurde.

[himitsu]

Ohne Debuginfos und mit minimaler RTTI (vorallem ohne die erweiterte RTTI)
werden auch neuere Compilate kleiner.

Man beachte auch, daß immer mehr Baiscode in den EXEn enthalten ist und daß die Resourcen über die Zeit gewachsen sind.
(leider kann/tut der Linker keine ungenutzen Resourcen entfernen)

[jaenicke]

Zitat:

Zitat von Delphi-Laie (Beitrag 1165384)

Nun meine Frage: Weiß jemand, mit welchen Zaubereinstellungen man solch kleine Exe-Dateien erhält, in denen der redundante Teil signifikant verringert wird?

Die dort enthaltenen Informationen mögen für dich und deine Anwendungen nicht wichtig sein, aber redundant sind sie deshalb noch lange nicht. Wir nutzen z.B. Features wie die erweiterten RTTI-Informationen und brauchen diese Daten daher.

Dann zu deinem Beispiel:
Die genannte LuckiePing.exe wurde mit UPX komprimiert:

Anhang 36865

Zitat:

Zitat von himitsu (Beitrag 1165403)

Man beachte auch, daß immer mehr Baiscode in den EXEn enthalten ist und daß die Resourcen über die Zeit gewachsen sind.
(leider kann/tut der Linker keine ungenutzen Resourcen entfernen)

Wie auch? Schließlich lässt sich nicht feststellen welche davon benutzt werden...

[p80286]

Zitat:

Zitat von Delphi-Laie (Beitrag 1165396)

Auf Assarbads Webseite fand ich zwar schon sehr viel, aber dazu noch nichts.

Dann versuch einmal den Hinweis auf NicoBendlin, da gibt es "Hello World" in 5KB.
(MiniDExe)

Gruß
K-H

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1165407)

Wie auch? Schließlich lässt sich nicht feststellen welche davon benutzt werden...

Über Compilerschalter wird das scheinbar nicht beachtet. {$IFDEF}

Jedenfalls war mir so, als wenn es dennoch immer eingebunden wurde.

Aber selbst wenn, es gibt leider keine Compilerschalter für "mache nur, wenn dieser Typ BENUTZT wird".

[shmia]

Du kannst auch noch ein paar Bytes rausschneiden, indem du die Relocationstabelle beseitigst:
StripReloc

[Delphi-Laie]

Allmählich lichtet sich das Dunkel...

an himitsu: RTTI dürfte für Delphi-4-Compilate noch nicht relevant sein (bitte korrigieren, falls das nicht stimmt). Bei XE2 konnte ich damit die Compilatsgrößen hingegen um ca. 30% verringern.

an jaenicke: upx kenne ich zwar, kam aber gar nicht auf die Idee bzw. dachte nicht daran, daß es hier verwandt worden sein könnte. Ist m.E. auch ein zweifelhafter Taschenspielertrick, der mit größerer Speicherbedarf einhergeht, besser: erkauft wird. Und tatsächlich: Das beigelegte kleinere Original benötigt mehr davon als mein erhaltenes Compilat. Daß man 7Zip zur diesbezüglichen Spurensuche einsetzen kann, wußte ich hingegen noch nicht. Ich bekam das Objekt meiner Untersuchung und meines Interesse mit meinem 7Zip der Version 9.2 zunächst nur über den Menüpunkt "Entpacken" in ein Unterverzeichnis halbwegs seziert. Nach einigem Suchen gelang es mir schließlich über "intern öffnen", auch zu dieser vollständigeren Ansicht zu gelangen.

an shimia: StripReloc nahm ich zwar schon mal als Wort war, nicht aber, was das ist und wozu man das einsetzen kann. Mein Interesse dafür ist nunmehr geweckt.

Danke an allen, die sich bisher beteiligten!

Gruß

Delphi-Laie

Ergänzung: Mit decompress des upx-Programmes komme ich fast auf meine Compilatsgröße (das Original ist nur noch ein Quentchen kleiner).

Ergänzung 2: Mit StripReloc kam ich auf 70 kByte gegenüber 73 kByte des expandierten Originals -> kleiner Glückshormonausstoß!

[Medium]

Reicht immer noch nicht für eine Nominierung in der einzig wahren Disziplin :P

[himitsu]

Windowsprogramme bekommen beim Compilieren im PE-Header mitgeteilt, wo sie im RAM liegen möchten.

Falls das nicht möglich ist, müssen sie verschoben werden, dabei ändern sich natürlich auch Speicheradressen, für Sprungziele, Konstanten usw., welche nun wo anders liegen.
Dafür gibt es diese Tabelle, denn darüber kann Windos nun diese Speicheradressen "korrigieren"/anpassen.

StripReloc entfernt diese Tabelle einfach, womit es beim Verschieben zu Fehler kommt, da diese Adressen nicht mehr angepaßt werden können, weil winodws sie ja nicht kennt.

Das ist vorallem für DLLs wichtig, da irgendwie niemand sich die Mühe macht dort sich ein hübsches Fleckchen auszusuchen und demnach alle Delphi-DLLs an der selben Stelle liegen würden. (bei C++ und Co. natürlich genauso, jemachdem was dort als Standardwert vorhanden ist)

Die EXE wird "meistens" als Erstes geladen, womit ihr Platz "meistens" frei ist.
Ausnahme ist EXEPacker, Encrypter, Antihackerschutz und Dergleichen, wo ein Miniprogrammcode noch vor der EXE gestartet wird und dieses dann die eigentliche EXE läd.



Auch kann man viele Resourcen entfernen, da sie meistens nicht verwendet werden.
So bringt Delphi sein eigenes kleines Cursor-Set (Mauszeiger).
Kann man sich gerne mal über einem Resource-Hacker/Editor ansehn.



Und ja, neuere RTTI-Informationen sind natürlich auch erst in den entsprechenden neueren Delphi-Versionen dazugekommen.



Ansonsten geh ich davon auß, daß man heutzutage genug Speicher hat.
Ich versuche zwar hier und da was einzusparen (über den Programmcode und meine eigenen Resourcen), aber übertreiben muß man es nun auch nicht unbedingt.

[mleyen]

1 kb Delphi-exe
aber statt den dort verwendeten system.pas und sysinit.pas verwendest du besser meine

falls du noch dabei produktiv programmieren willst, solltest du die KOL-Units nutzen (wird aber wieder bissl größer)

:thumb: :stupid:

[Luckie]

Um es noch mal etwas auszuführen, was himitsu schon gesagt hat. Module (Exe-Dateien, DLLs) werden unter Windows an die sogenannte Imagebaseaddress geladen. auf diese Adresse beziehen sich alle Adressen im Kompilat. Diese Imagebaseaddress wird beim Kompilieren festgelegt. Kann ein Modul nicht an die Imagebaseaddress geladen, weil sich dort schon ein Modul befindet, wird sie an eine andere Adresse geladen. Jetzt stimmen natürlich die Adressen im Programmcode nicht mehr und Windows muss sie neu berechnen. Dazu benötigt Windows den Reallocationtable. Da eine Exe in der Regel als erstes geladen wird, kann man ihn aus der Exe entfernen. Bei DLLs sollte man dies tunlichst nicht tun, da man nicht weiß, ob die Imagebaseaddress schon belegt ist oder nicht. Desweiteren ist der Reallocationtable nicht sehr groß, so dass es das Modul nicht signifikant verkleinert.