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

[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

[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)

[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.