exe zu groß!

[bixi400]

Hi!

Ich sehe immer wieder Programme die haben nur um die 35kb.
Wenn mein Programm nur aus einer Leeren Form besteht hat
die EXE Datei 353 kb! :(
Kann man da nicht was einstellen das meine Programme auch
so klein werden?

[c113plpbr]

In diesem Forum schwirren ein paar tutorials über nonVCL-Programmierung rum, ich empfehle dir diese mal zu konsultieren ... das hilft in sachen dateigröße ungemein!

ciao, Philipp

[edit]... wenn man an was anderes denkt als dass man schreibt ... ^^[/edit]

[Stanlay Hanks]

Hi. Wenn dein Programm richtig klein werden soll, musst du das ganze wohl in nonVCL programmieren.
Was du aber noch machen könntest, wäre das Programm mit UPX zu komprimieren.

Man liest sich, Stanlay :hi:

PS: nonAPI...auch schön :mrgreen:

[NicNacMan]

die einfachere lösung wäre die exe zu packen (ich meine nicht als zip):
http://upx.sourceforge.net/


edit: sch*****, zu langsam :wink:

[jbg]

Zitat:

Zitat von bixi400

Ich sehe immer wieder Programme die haben nur um die 35kb.

Die brauchen aber unmengen an MB an zusätzlichen DLLs. Ich kann auch ein VCL Programm schreiben, das 5-10 KB groß ist und mehr als nur ein Formular enthält ohne auf die VCL verzichten zu müssen. Denn auch die VCL kann in eine DLL ausgelagert werden.

Direkte WinAPI Programmierung kommt nur in Frage, wenn das Projekt sehr, sehr klein ist und wenig auf die GUI angewiesen ist. Ansonsten stehen zu investierende Zeit und Nutzen im falschen Verhältnis.

[MrKnogge]

wenn du mal mit api programmierung anfangen möchtest, so kann ich dir nur Luckie's Api tutorial empfehlen.

[Wheelie]

Die im Vergleich zu nicht mit Delphi entwickelten Anwendungen heftige Größe der EXE-Dateien musst du mehr oder weniger in Kauf nehmen. Dafür benötigst du keine zusätzlichen Runtime-Files wie z.B. bei VB oder beim Borland C++ Builder. Standalone-Anwendungen, deren Größe im Bereich von mehreren KB liegt, sind auch oft mit Win32ASM erstellt worden (MASM). Trotzdem bin ich der Meinung, dass der Entwicklungsaufwand in keinem Verhältnis zum Platzersparnis der Exe steht.
Mit UPX kannst du deine Programme packen.

EDIT: man war ich wieder lahm :cry:

[jbg]

Wer ganz kleine Programme haben will, der sollte .NET nutzen (egal welche Sprache). Da bekommt sehr kleine Exe-Dateien (was aber verschwiegen wird, wie auch bei MFC Anwendungen: die 40MB der .NET Runtime Environment)

Mit direkter WinAPI Programmierung wird man nach Windows Longhorn ziemlich im Regen stehen, denn dann ist die WinAPI nur noch zweite Wahl, wenn es nach Microsoft geht, und das tut es beim Windows Betriebssystem.

[Matze]

Es wird die Dateigröße zwar nicht sonderlich minimieren, aber du kannst überflüssige Units aus den Uses entfernen.

[tommie-lie]

Zitat:

Zitat von jbg

Da bekommt sehr kleine Exe-Dateien (was aber verschwiegen wird, wie auch bei MFC Anwendungen: die 40MB der .NET Runtime Environment)

Mit dem Unterschied, daß das .NET-Framework wiederverwertbar ist und einen gewissen Namen hat. Die VCL-Packages (nicht DLL, BPL ;-)) von Borland würde kein DAU einfach so ins Systemverzeichnis kopieren, aber auf .NET steht Microsoft drauf, da ist die Installationsbereitschaft wesentlich größer. Und ist's einmal drauf, kann jede .NET-Anwendung dieses Framework benutzen. Die VCL-Packages müssen aber jeder Delphi-Anwendung beiliegen, da den Usern ja ständig eingeredet wird, non-MS wäre unsicher und man solle niemals was ins Systemverzeichnis kopieren, wo alle Anwendungen die Chance haben, Dateien zu sharen.

Zitat:

Zitat von jbg

Mit direkter WinAPI Programmierung wird man nach Windows Longhorn ziemlich im Regen stehen, denn dann ist die WinAPI nur noch zweite Wahl, wenn es nach Microsoft geht, und das tut es beim Windows Betriebssystem.

Solange die API noch zur Verfügung steht, steht man selber auch nicht im Regen, egal ob MS das für erste oder zweite Wahl hält. Und ich denke, daß das auch nach Longhorn noch der Fall sein wird. Erst wenn sich .NET komplett durchgesetzt hat, werden die API-Calls vielleicht nicht mehr aus dem Anwendungsbereich heraus zur Verfügung stehen, wenn das .NET-Framework vollständig im Kernel-Mode läuft, ergo im Kernel integriert ist und kein "Plugin" mehr ist. Aber bis dahin wird wohl noch das ein oder andere Jährchen vergehen.

[MathiasSimmack]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von jbg

Da bekommt sehr kleine Exe-Dateien (was aber verschwiegen wird, wie auch bei MFC Anwendungen: die 40MB der .NET Runtime Environment)

Mit dem Unterschied, daß das .NET-Framework wiederverwertbar ist und einen gewissen Namen hat.

Und als Ergänzung: Das .NET-Framework hat ja auch eine gewisse Größe, und es muss auch erst mal installiert werden. So gesehen, @jbg, ist .NET bisher kein Vorteil. Es wirkt auch nicht gerade ... äh ... schön, wenn sich der potentielle Kunde für ein 30k großes Programm erst mal das 20meg dicke .NET-Framework installieren muss. ;) Die geringe Dateigröße fällt tatsächlich erst ins Gewicht, wenn ein komplettes Betriebssystem auf .NET basiert.

Zitat:

Die VCL-Packages müssen aber jeder Delphi-Anwendung beiliegen, da den Usern ja ständig eingeredet wird, non-MS wäre unsicher und man solle niemals was ins Systemverzeichnis kopieren, wo alle Anwendungen die Chance haben, Dateien zu sharen.

Wobei ich das durchaus nützlich finde. Du darfst ja nicht vergessen, dass Microsoft nicht verboten hat, eigene Bibliotheken in die Systemverzeichnisse zu kopieren. Es ist nur eine Empfehlung um Versionschaos zu vermeiden. Ich hatte selbst mal mit zwei Programmen zu tun, von denen das vermeintlich aktuellere eine ältere Version einer DLL installiert hat - mit dem unschönen Nebeneffekt, dass das andere dann nicht mehr richtig funktionierte.
Wenn aber eine Runtime- oder was weiß ich-DLL ihre Versionsnummer im Namen trägt und sich dann nicht mit einer evtl. älteren/neueren Version in die Quere kommt, spricht auch nichts gegen das Kopieren in das Systemverzeichnis.

Zitat:

Zitat:

Zitat von jbg

Mit direkter WinAPI Programmierung wird man nach Windows Longhorn ziemlich im Regen stehen, denn dann ist die WinAPI nur noch zweite Wahl, wenn es nach Microsoft geht, und das tut es beim Windows Betriebssystem.

Solange die API noch zur Verfügung steht, steht man selber auch nicht im Regen, egal ob MS das für erste oder zweite Wahl hält.

Und abgesehen davon wird sich Longhorn sicher auch nicht sofort nach der Veröffentlichung durchsetzen. Es gibt ja jetzt noch mehr als genug Rechner, auf denen 95 oder NT4 läuft. Ich selbst habe auch noch mein gutes altes 98 am Start.

[supermuckl]

@ work haben wir auch haufenweise NT 4 rechner ( ja auch die neuen 2k3 systeme parallel )

ich persönlich mag .NET überhaupt nicht, da es wie gesagt noch ein plugin ist und daher ziemlich langsamer sein wird als direkt im kernel mit einkompiliert

ausserdem wird das wohl wie mit win311 und seinen 16bit programmen sein.. die laufen heute immernoch ;) und sogar dos krempel
also ich werde als letzter auf .NET "umsteigen".. wenn nich sogar total auf linux und dem microschnufti dreck komplett aus dem weg zu gehen und unabhängiger zu sein :)

ich hoffe kylix wird weiter entwickelt werden.. und wenn nicht mach ich meine projecte halt mit Kdevelop in C++ oder pascal/delphi mit diversen free pascal compilern

[tommie-lie]

Zitat:

Zitat von MathiasSimmack

wenn sich der potentielle Kunde für ein 30k großes Programm erst mal das 20meg dicke .NET-Framework installieren muss. ;)

Aber wenn er das Framework ersteinmal hat, dann hatter's und braucht bis zur nächsten Version vom Framework nicht mehr runterladen.

Zitat:

Du darfst ja nicht vergessen, dass Microsoft nicht verboten hat, eigene Bibliotheken in die Systemverzeichnisse zu kopieren.

Microsoft vielleicht nicht, aber die ganzen Sensationsreporter, die meinen, ihr nicht vorhandenes Wissen an ahnungslose PC-Neukäufer weiterreichen zu müssen.

Zitat:

Wenn aber eine Runtime- oder was weiß ich-DLL ihre Versionsnummer im Namen trägt und sich dann nicht mit einer evtl. älteren/neueren Version in die Quere kommt, spricht auch nichts gegen das Kopieren in das Systemverzeichnis.

Das ist ja bei der VCL der Fall, zumindest heißen die Packages bei mir vclXXX60.bpl.
Aber den meisten Leuten wird einfach Angst gemacht, sowas zu machen, und deswegen muss unsereiner entweder die Dateien immer mitliefern (entweder "lose" oder in die EXE binden), oder auf nonVCL umsteigen, wenn wir in Sachen Dateigröße mit VB oder MSVC konkurrieren wollen.

Zitat:

Und abgesehen davon wird sich Longhorn sicher auch nicht sofort nach der Veröffentlichung durchsetzen. Es gibt ja jetzt noch mehr als genug Rechner, auf denen 95 oder NT4 läuft. Ich selbst habe auch noch mein gutes altes 98 am Start.

Eben, deswegen denke ich ja auch, daß das noch einige Jahre dauern wird, bis sich .NET endlich vollständig durchgesetzt hat, mindestens noch zwei Windowsgenerationen.

[jbg]

Zitat:

So gesehen, @jbg, ist .NET bisher kein Vorteil. Es wirkt auch nicht gerade ... äh ... schön, wenn sich der potentielle Kunde für ein 30k großes Programm erst mal das 20meg dicke .NET-Framework installieren muss

Warum schreibe ich eigentlich was in Klammern dazu :wink: :

Zitat:

(was aber verschwiegen wird [...]: die 40MB der .NET Runtime Environment)

[MathiasSimmack]

Zitat:

Zitat von jbg

Warum schreibe ich eigentlich was in Klammern dazu :wink:

Ich habe das schon gesehen. ;) Es wird ja IMHO auch nicht "verschwiegen" im Sinn des Wortes. Es wird nur ab und zu vergessen, dass .NET-Programme eben auch das .NET-Framework voraussetzen. Und damit relativiert sich der angebliche Vorteil der geringen Größe erst mal wieder ... Das wollte ich sagen. Hätte ich wohl gleich tun sollen. :stupid:

[mytar]

Die normale Größe bei meinem Programm beträgt, ca. 1MB
Mit UPX nur noch knapp 600KB, gibt es noch eine Möglichkeit wie ich das optimieren kann?

mytar

[Wheelie]

Zitat:

Zitat von mytar

Die normale Größe bei meinem Programm beträgt, ca. 1MB
Mit UPX nur noch knapp 600KB, gibt es noch eine Möglichkeit wie ich das optimieren kann?

mytar

Ich glaube nicht, dass du an der Echse noch was optimieren kannst (mit irgendwelchen Tools). Du kannst aber das Projekt optimieren (zu große Grafiken, überflüssige Units, etc.). Meistens sind es irgendwelche Komponenten, die deine Echse um 200-300 KB wachsen lassen. Wenn du die samt Units rauswirfst und diese durch primitivere Komponenten ersetzt, holst du bestimmt noch ein paar KB raus.

[MrKnogge]

Zitat:

Zitat von mytar

Die normale Größe bei meinem Programm beträgt, ca. 1MB
Mit UPX nur noch knapp 600KB, gibt es noch eine Möglichkeit wie ich das optimieren kann?

mytar

Du kannst auch die komprimierungs-stufe einstellen, gib einfach mal den parameter "-h" an die ee, und du erhalst die gesamten paramter, oder such hier im Forum nach UPX-GUI, dann kannst du den UPX-Packer per Oberfläche bedienen.

[mytar]

Ich denke nicht das ich große Komponenten eingefügt habe,

ich hab PageControl,

Vielleicht ist es die ImageList,
oder ActionToolbar und ActionMainMenuBar?

Was sagt ihr?

[MrKnogge]

die größe liegt hauptsächlich an der Unit "Forms", die du für deine Formulare benötigst. Wie bereits geschrieben, um auf die zu verzichten, müsstest du auf API oder .NET umsteigen, oder du komprimierst eben deine exe-file.

[Wheelie]

Zitat:

Zitat von mytar

Ich denke nicht das ich große Komponenten eingefügt habe,

ich hab PageControl,

Vielleicht ist es die ImageList,
oder ActionToolbar und ActionMainMenuBar?

Was sagt ihr?

auf diese komponenten solltest und kannst du wahrscheinlich auch gar nicht verzichten. ich meinte eher welche, die du irgendwo im netz gefunden hast und die kunterbunt geschmückt sind.

[MathiasSimmack]

ActionToolbar und ActionMenu sind IMHO "kunterbunte" Komponenten. ;) Im Normalfall reicht sicher auch ein TMainMenu und eine normale Toolbar.

[Luckie]

Was hast du den für Bitmaps in die ImageList reingehauen?

[Norbert987]

sonst versuch mal ASPack, komprimiert meine exe Dateien auf 40%.

[Luckie]

Man sollte aber wissen, was man tut, wenn man solche Exe-Packer einsetzt. Windows tut man damit keinen Gefallen, da man das Speichermanagement von Windows aushebelt. Eigentlich gibt es keinen Grund die Exe klein halten zu wollen, CD-ROMs und Brenner sind mittlerweile standard und wenn ich sie ins Internet stelle, dann nehme ich ein normales Packprogramm für Dateien, wie Zip oder was auch immer.

[alcaeus]

Luckie hat Recht. Und selbst wenn im INet eine Anwendung noch 1MB groß ist, bei der heutigen Verbreitung von Breitbanzugängen dürfte das wohl wirklich kein Problem sein. Und wenn du es nur mal schnell jemandem vorbeibringen willst, auf so einem 128-256 MB USB-Stick kriegt man viele Daten drauf. Außerdem gibts ja noch die CD(RW), und auch die DVD falls eine CD nicht reicht. Also ich würde mir wegen der Größe keine Sorgen machen.
Und noch was: Datenbankkomponenten lassen die Dateigröße sehr schnell ansteigen.

Greetz
alcaeus