Größe der Delphi-EXE-Dateien?

[Ungeübter]

Hi,


ist euch nicht auch schon einmal die gewaltige Größe von kompillierten *.EXE Dateien in Delphi aufgefallen? Ich habe eben mal einen kurzen Vergleich zwischen einem Standartprojekt (also so wie es sich nach dem Öffnen eines neuen Projektes darstellt, sprich nur ein leeres Formular) in Delphi 5 und Visual Basic 6 gemacht und wundere mich doch sehr über den gewaltigen Unterschied in der Dateigröße obwohl beide im Ergenis das Selbe darstellen.

Ergebnis:

Delphi 5 Professional: 287 KB

Visual Basic 6: 16 KB (!)


Gruß

[Nicolai1234]

Dazu gibt es schon unmengen an Threads. Such einfach mal danach...

[Pseudemys Nelsoni]

Das hatten wir hier schon 23523532 mal. Benutz mal die Suche

[mirage228]

Bei Visual Basic musst Du aber Runtimes mitliefern (bzw. sie sind schon bei Windows dabei) die im Endeffekt fast genauso groß sind (wenn nicht sogar größer).

mfG
mirage228

[sakura]

Kleine Delphi Dateien: Suche nach [dp="non-VCL or nonVCL"]non-VCL[/dp]

Kleine Formulare: Nutze Delphi.NET ;-) Dann reden wir von den gleichen Voraussetzungen unter VB und Delphi. Die Run-Time (.NET Framework) muss evtl. auch noch installiert werden.

Bei normalen VB Anwendungen muss die Runtime auch mit ausgeliefert werden, bei normalen Delphi-Anwendungen dafür nicht.

...:cat:...

[jfheins]

Wenn ich mal schaue, bei meinem CrackMe sind 4 Formulare, 2 VCL, 2 non-VCL macht ~ 800 KB
Ein VCL-Form alleine hat bei mir 361 KB ...
Also: non-VCL proggen :coder2:

[sakura]

Zitat:

Zitat von jfheins

Wenn ich mal schaue, bei meinem CrackMe sind 4 Formulare, 2 VCL, 2 non-VCL macht ~ 800 KB

Die VCL kommt mit ca. 340 KB daher. Jedes weitere (leere) VCL-Form mit ca. 0,5 KB. Die VCL wird nur einmal eingebunden. Wenn Du jetzt aber Bilder oder andere Dinge mit einbindest, so müssen deren Daten mit rein und ich denke mal, dass ist der Großteil Deiner Daten.

...:cat:...

[SirThornberry]

Wenn du unter "project->Options->Packages" den haken bei "Build with Runtimepackages" setzt werden die Delphiprogramme auch kleiner. Allerdings musst du dann wie bei VB die RuntimePackages mit liefern da diese nicht in der Exe sind.

[PierreB]

Zitat:

Allerdings musst du dann wie bei VB die RuntimePackages mit liefern

Mich würde mal interessieren was das genau für Dateien (also welche) sind ??

[Michael_Bayer]

Zitat:

Zitat von PierreB

Zitat:

Allerdings musst du dann wie bei VB die RuntimePackages mit liefern

Mich würde mal interessieren was das genau für Dateien (also welche) sind ??

VBRUNxxx.DLL heißt die Datei.

EDIT: xxx steht für die Version - also 100 für Version 1, 200 für 2 usw

[bigg]

Die kleinste Delphi / Pascal *.EXE ist ca. 8,5 KB groß.
PS: Erzeugt mit D7 Personal.

Könnte jemand mal die größe mit D3 überprüfen :stupid:

[PierreB]

Hm, ich hab deine test.dpr kompiliert, es kommt 15KB raus ! :gruebel:

[Pseudemys Nelsoni]

er hat upx benutzt.

[PierreB]

Zitat:

Die kleinste Delphi / Pascal *.EXE ist ca. 8,5 KB groß.

Also ist das falsch. Die kleinste reineDelphi-Exe ist 15KB groß.

[bigg]

Hehe wer hätte das gedacht.
Deine Version verbraucht 0,5 KB mehr. :gruebel:

Zitat:

Also ist das falsch. Die kleinste reineDelphi-Exe ist 15KB groß.

14 KB ohne Windows.pas und ohne Kompression.

[Chewie]

Natürlich gehts noch kleiner.
Man kann die Windows-Unit sparen, und wenn man sich eine eigene system.pas und sysinit.pas schreibt, kann man das ganze nochmals gewaltig verringern. Diese Dateien sind hier auch schon irgendwann rumgegeistert, soweit ich mich erinnere kriegt man da Größen im Bereich 2-3 kb raus.

[Ultimator]

Bei mir ist die kleinste Delphi-EXE (Konsolenprogramm) laut Explorer 13,5 KB (13.824 Bytes) groß ;-)

[PierreB]

Zitat:

Diese Dateien sind hier auch schon irgendwann rumgegeistert, soweit ich mich erinnere kriegt man da Größen im Bereich 2-3 kb raus.

Und dann noch per UPX komprimieren und man hat ein 1KB Programm. ;)

[Mephistopheles]

Üblicherweise tut's UPX bei diesen Größen nicht mehr. Ansonsten hat Chewie recht. Allerdings können die dann meist nicht viel ;) ... ist ja bei entsprechenden C-Programmen auch nicht anders.

Und zu VB ... naja, was soll man dazu wohl sagen.

[MagicAndre1981]

Bitte kein UPX, das hatten wir doch schon oft. UPX hebelt das Speichermanagement von Windows aus.
Nutzt nonVCL oder .NET und eure "Exen" sind schön klein.

André

[jbg]

Und wen interessiert es heutzutage, wie groß die exe-Dateien sind? Bei so kleinen, nicht wirklich brauchbaren Programmen, mag das vielleicht eine Rolle spielen, um damit anzugeben, dass der eine Compiler kleinere Exe-Dateien erstellt, als der andere. Aber bei größeren Projekten ist das sowas von belanglos (wenn nicht gerade für ein embedded System programmiert wird, aber da gibt es sowieso meistens nur einen oder zwei kompatible Compiler).

[stefan2005]

hi,
also bei mir braucht so ein Programm:

Delphi-Quellcode:

program test;
uses Windows;
begin
  MessageBox(0, Pchar('Hallo Welt. Hallo Welt. Hallo Welt. Hallo Welt.'), Pchar('Hallo'), 64);
end.

mit
- Delphi 6 Personal: 8 KB
- Delphi 2005 AE: 14 KB

(alles ungepackt)

cu,
stefan2005

[Kernel32.DLL]

Zitat:

Zitat von jbg

Und wen interessiert es heutzutage, wie groß die exe-Dateien sind? Bei so kleinen, nicht wirklich brauchbaren Programmen, mag das vielleicht eine Rolle spielen, um damit anzugeben, dass der eine Compiler kleinere Exe-Dateien erstellt, als der andere. Aber bei größeren Projekten ist das sowas von belanglos (wenn nicht gerade für ein embedded System programmiert wird, aber da gibt es sowieso meistens nur einen oder zwei kompatible Compiler).

Mich interessierts schon, wie groß die Exen sind, die ich auf meiner HP zum Download anbiete. Nehmen wir z.B. "CPUiD", eines meiner Programme. Das Programm ist non-vcl und in ein *.zip File verpackt ist das Ding gerade mal 23 kb groß. Bis jetzt habe ich um die 700 Downloads gehabt. Das ergibt einen Traffic von ~22.4 MB. Wäre das Programm jetzt "normal" geschrieben (also mit der VCL), hätte ich zehnmal soviel Traffic gehabt. Es lohnt sich also schon.

[Mephistopheles]

Zitat:

Zitat von MagicAndre1981

Bitte kein UPX, das hatten wir doch schon oft. UPX hebelt das Speichermanagement von Windows aus.

Der Philosoph, der tritt herein,
Und beweist euch, es müßt' so seyn:
Das Erst' wär' so, das Zweite so,
Und drum das Dritt' und Vierte so;
Und wenn das Erst' und Zweit' nicht wär',
Das Dritt' und Viert' wär' nimmermehr.

Nunja, das sollte für EXE-Dateien meist irrelevant sein, da diese so oft nicht im Speicher landen (auch auf die absolute Größe kommt es hier an - Tool kleiner als 100kB oder 10MB-Programm ...). Schlimm wird's erst bei DLLs, denn hier funktioniert jener Mechanismus nicht mehr, der es vielen Programmen erlaubt exakt die gleiche (geladene) DLL zu benutzen - wobei bei einem Schreibversuch auf eine Speicherseite, diese Seite nur für das jeweilige modifizierende Programm verändert wird.
Also bei EXE-Dateien würde ich es doch für fraglich erachten, ob das Argument von Relevanz ist.

Allerdings ist das nachträgliche Packen einer EXE mit einem echten Packer (ZIP, RAR, ACE, 7Z) sowieso meist effektiver - und nur das spielt für die Datenübertragung im Internet eine Rolle. Daher sollte dies bevorzugt werden. Gleiches wie für VB gilt ja auch für die MFC, allerdings hat jeder immer die MFC-Runtimes mit auf seinem Rechner, weil sie von genügend Programmen benutzt werden. Bei VB gibt's dann noch die Versionshölle und da wird's unlustig.