Debug und Release liefert nahezu gleichgroße Exe-Dateien

[Hobbycoder]

Hi,

mir ist gerade bei einem Projekt, welches ich aus D7 nach 10.1 rübergeholt habe, auf gefallen, dass Release- und Debug-Compilat nahezu gleich groß sind.
Bei anderen Projekten, die unter 10.1 begonnen wurden, ist das nicht so.
Ich habe mal die Einstellungen für Release und Debug mit einem neu angelegten verglichen, bzw. diesen Einstellungen angepasst, aber das hat nahezu nichts verändert.

Hier mal die Einstellungen
Debug:
/Delphi-Compiler/Bedingungen = DEBUG
/Delphi-Compiler/Compilieren/Debug-Informationen = Debug-Informationen
/Delphi-Compiler/Compilieren/Lokale Symbole = Aktiviert
/Delphi-Compiler/Compilieren/Mit Debug-DCUs = Aktiviert
/Delphi-Compiler/Compilieren/Symbolreferenzinfo = Referenzinfo
/Delphi-Compiler/Compilieren/Optimierung = nicht Aktiviert
/Delphi-Compiler/Compilieren/Stack-Frames = Aktiviert
/Delphi-Compiler/Linken/Debug-Informationen = Aktiviert
/Recourcen-Compiler/Verzeichnisse und Bedingen/Definiert ein Präprozessorsymbol = DEBUG;DEBUG

Release:
/Delphi-Compiler/Bedingungen = RELEASE
/Delphi-Compiler/Compilieren/Debug-Informationen = Keine Debug-Informationen
/Delphi-Compiler/Compilieren/Lokale Symbole = nicht Aktiviert
/Delphi-Compiler/Compilieren/Mit Debug-DCUs = nicht Aktiviert
/Delphi-Compiler/Compilieren/Symbolreferenzinfo = Ohne
/Delphi-Compiler/Compilieren/Optimierung = Aktiviert
/Delphi-Compiler/Compilieren/Stack-Frames = nicht Aktiviert
/Delphi-Compiler/Linken/Debug-Informationen = nicht Aktiviert
/Recourcen-Compiler/Verzeichnisse und Bedingen/Definiert ein Präprozessorsymbol = RALEASE;RELEASE

Ich nehme mal an, dass es wohl aus der direkten Übernahme aus D7 herrührt, und beim Anlagen der Projektparameter ein Fehler entstanden ist. Welche Einstellung könnte ich noch ausprobieren, damit ich das gleich Verhalten erhalte, wie bei Projekten, die ich direkt unter 10.1 erzeuge'

Gruß Hobbycoder

[Mavarik]

Hast Du auch die Einstellungen für die richtige Targetplattform verglichen? Auch für 32/64 Bit?
Auch die Dateien im richtigen Unterverzeichniss?

Mavarik

[Hobbycoder]

Ja. In diesem Fall handelt es sich nur um Win32. Eine andere Plattform gibt es nicht. Ich verwende einige Fremdkomponente, für die es teilweise gar keine 64-Bit-Version gibt. Von daher werde ich auch bei Win32 bleiben.

[Bernhard Geyer]

Zitat:

Zitat von Hobbycoder (Beitrag 1363845)

... dass Release- und Debug-Compilat nahezu gleich groß sind.

Definiere "nahezu". Normalerweise habe ich hieh auch nur wenige 100 kByte unterschied.

[Mavarik]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1363853)

Zitat:

Zitat von Hobbycoder (Beitrag 1363845)

... dass Release- und Debug-Compilat nahezu gleich groß sind.

Definiere "nahezu". Normalerweise habe ich hieh auch nur wenige 100 kByte unterschied.

Nee, Eher so 25% kleiner

[Hobbycoder]

Debug-Größe aus D7 übernommenes Project: 29.136.384 Bytes
Release-Größe aus D7 übernommenes Projekt: 29.513.216 Bytes

Debug-Größe eines unter 10.1 erzeugtem Projekt: 19.988.820 Bytes
Release-Größe eines unter 10.1 erzeugtem Projekt: 5.058.048 Bytes

Sicherlich werden in den Projekten unterschiedlich viele Units verwendet und auch die Anzahl der Forms unterscheidet sich. Aber eine derart fast gleiche Größe, kann ich mir nicht vorstellen, dass das so korrekt ist.

[Rollo62]

Wenn das Probleme macht dann würde ich die Projektdateien neu anlegen.

Dann hättest du die Defaulteinstellungen.

Rollo

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1363856)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1363853)

Zitat:

Zitat von Hobbycoder (Beitrag 1363845)

... dass Release- und Debug-Compilat nahezu gleich groß sind.

Definiere "nahezu". Normalerweise habe ich hieh auch nur wenige 100 kByte unterschied.

Nee, Eher so 25% kleiner

Nee. Nicht bei unseren Debug-Einstellungen:
XE6 Debug zu Release: 21483 -> 21225 (kByte)

[Bernhard Geyer]

Zitat:

Zitat von Hobbycoder (Beitrag 1363857)

Debug-Größe aus D7 übernommenes Project: 29.136.384 Bytes
Release-Größe aus D7 übernommenes Projekt: 29.513.216 Bytes

Debug-Größe eines unter 10.1 erzeugtem Projekt: 19.988.820 Bytes
Release-Größe eines unter 10.1 erzeugtem Projekt: 5.058.048 Bytes

Das ist im 2ten Projekt noch einiges mehr an Debug-Infos aktiviert.
hast du auch beim 32/64-Bit Projekteinstellungen geschaut.
Könnten ja noch unterschiedlich zu den Basis-Release-Einstellungen sein.

[MichaelT]

So schaut es auch bei mir aus.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1363867)

Zitat:

Zitat von Hobbycoder (Beitrag 1363857)

Debug-Größe eines unter 10.1 erzeugtem Projekt: 19.988.820 Bytes
Release-Größe eines unter 10.1 erzeugtem Projekt: 5.058.048 Bytes

Das ist im 2ten Projekt noch einiges mehr an Debug-Infos aktiviert.
hast du auch beim 32/64-Bit Projekteinstellungen geschaut.
Könnten ja noch unterschiedlich zu den Basis-Release-Einstellungen sein.

[MichaelT]

Das wird vermutlich nicht den großen Unterschied ausmachen...

Zitat:

Zitat von Hobbycoder (Beitrag 1363845)

Hi,
...
/Recourcen-Compiler/Verzeichnisse und Bedingen/Definiert ein Präprozessorsymbol = RALEASE;RELEASE
...
Gruß Hobbycoder

[Hobbycoder]

Zitat:

Zitat von MichaelT (Beitrag 1363883)

Das wird vermutlich nicht den großen Unterschied ausmachen...

Zitat:

Zitat von Hobbycoder (Beitrag 1363845)

Hi,
...
/Recourcen-Compiler/Verzeichnisse und Bedingen/Definiert ein Präprozessorsymbol = RALEASE;RELEASE
...
Gruß Hobbycoder

Sicher nicht, aber der Vollständigkeit halber habe ich das mit aufgeführt.

[Bernhard Geyer]

Das RELEASE-Define gibt auch erst seit den Delphi-Versionen mit dproj-Datei.
Der eigentliche Compilerdirektive ist $D+

[Hobbycoder]

Ich habe jetzt mal meine Projektdatei neu angelegt, die Konfiguration habe ich ganz bewusst mit den Defaultwerten übernommen. Ich habe danach lediglich die Uses und das erzeugen der Forms in die neue Dpr-Datei umkopiert.

Zwar hat sich dadurch die Größe meiner Release-EXE nicht verändert 27 MB, aber die Debug-EXE ist jetzt knapp 72 MB groß :shock:
Wenn ich MadExcept rausnehme sind es ungefär 2 MB weniger.

Hab grad noch mal die D7-Version rausgekramt: Knapp 15 MB

Einiges wird sicherlich den Fremdkomponente geschuldet sein, die in ihren neueren Version sicherlich auch einen erweiterten Funktionsumfang mit sich bringen. Auch Änderungen in den Units von Delphi wird ein Teil zum Opfer fallen. Aber 15 (incl. Debug-Informationen) zu 27 ohne erscheint mir sehr viel. Und die 72 der Debug-EXE....wow, damit hätte ich nicht gerechnet.

[Bernhard Geyer]

Du musst auch die Einstellungen im Bereich Linker anschauen.
Da gibt's einige Einstellungen die eine Exe sehr viel größer machen (aber auch nötig sind damit z.B. AQTime Laufzeitmessungen durchführen kann) und bei neu angelegten Projekten in der Debug-Konfiguration standardmäßig angewählt sind.
Diese großen Unterschied bekommst du auch unter alten Delphis hin wenn du die TD32-Debug-Infos aktivierst.

[Hobbycoder]

Das einzige, was dort aktiviert ist (wie gesagt, Default und nicht von mir geändert) ist Debug-Informationen und das solle ja so sein. Beim Map-Datei steht detailliert, aber das ist ja sowieso eine separate Datei.

Was ich noch ändern könnte wäre unter Compilieren - Debug-Informationen. Dort steht Debug-Informationen, ich könnte aber auf "begrenzte Debug-Information" umschalten. Aber es ist ja Default und ich weiß nicht, welche Einschränkungen ich mir damit beim Debuggen einhandele.

Ich meine, wenn die Debug-EXE so groß sein soll/muss, dann ist es halt so. Ist ja nicht so, dass es mich wesentlich stört. Ich war nur etwas erschrocken.
Meine Frage im Eröffnungsthread zielt ja eigentlich darauf ab, dass ich nicht eine EXE-Datei weitergeben will, die mehr Daten enthalten (also Debug-Informationen) als für die Ausführung beim Anwender notwendig ist.

Durch das erzeugen der neuen Projektdatei sieht es für mich jedoch eher so aus, dass in meiner ursprünglichen Debug-EXE keine Debug-Informationen drin waren, jedoch das Debugging ohne Probleme funktionierte.
Ich hätte durch das Neuerzeugen der Projektdatei erwartet, dass die Release-EXE kleiner wird, und die Debug-EXE so bleibt. Stattdessen ist es umgekehrt. Und das hat mich gewundert.

[Uwe Raabe]

Zitat:

Zitat von Hobbycoder (Beitrag 1363910)

Aber 15 (incl. Debug-Informationen) zu 27 ohne erscheint mir sehr viel. Und die 72 der Debug-EXE....wow, damit hätte ich nicht gerechnet.

Das ist tatsächlich nicht unüblich und eher normal. Ein kürzlich von D7 auf Berlin hochgezogenes Projekt ist im Release von 7,5 MB auf 38 MB angewachsen. Aber die EXE-Größe hat als Kriterium so gut wie kein Gewicht. Daß wir ca. ein Drittel der Fremdkomponenten einfach wegrationalisieren konnten allerdings schon.

[Bernhard Geyer]

Wie schon geschrieben gibt es mehrer Einstellungen für Debug-Infos.

Zum Debuggen in der IDE brauchst du nur die Debug-Einstellung auf die Compiler-Seite. Dann wird die Exe nur geringfügig größer.
Den Schalter auf der Linker-Seite brauchst du z.B. um mit AQTime zu arbeiten. Und dieser Schalter macht (wie auch schon zu Delphi 6-Zeiten die Exe sehr viel größer).
Da hat sich nichts grundlegendes in den letzten 20 Jahren geändert.

Und wenn deine alte Debug-Exe klein war dann hatte Sie nur auf der Compilerseite den Schalter gesetzt aber nicht auf Linker-Seite.

Und deine Release-Exe bekommst du etwas kleiner mit {$WEAKLINKRTTI ON} in der dpr-Datei.
Dann darfst du aber nicht auf automatisch erzeugte erweiterte RTTI-Infos setzen in deinem Quellcode.

[EWeiss]

Exe Größe Hin oder Her ich meine das in Delphi Kompilierte Dateien unnötig aufgebläht sind.
Ich Kompiliere eine DLL..

Jetzt frage ich mich ernsthaft was haben da ein Icon\IconGroup, Cursor\CursorGroup und andere dinge zu suchen?
Die werden weder benötigt noch erfüllen sie irgendeinen zweck und sind nicht von Nöten damit meine DLL funktioniert.

Was soll das also? Und warum kann man diese NICHT benötigen Dinge aus dem Kompilat nicht ausschließen.

EDIT:
Zudem sind die Package Informationen für mich ein Ansatz um das Kompilat zu dekompilieren.
Warum muss diese öffentlich in einer DLL durch das Kompilieren mit eingebunden werden.


gruss

[himitsu]

Das liegt daran, dass der Compiler da nichts optimieren kann, da er nicht wissen kann ob eine Ressource benötigt wird, also wird alles einkompiliert, was in irgendeiner Unit inkludiert wurde.
Bei Klassen und Funktionen ist das was Anderes ... wird die nicht verwendet, sie sind nicht public (im Interface) und es handelt sich nicht um ein Package, dann kann sie einfach vom Linker weggelassen werden.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1363930)

Das liegt daran, dass der Compiler da nichts optimieren kann, da er nicht wissen kann ob eine Ressource benötigt wird, also wird alles einkompiliert, was in irgendeiner Unit inkludiert wurde.
Bei Klassen und Funktionen ist das was Anderes ... wird die nicht verwendet, sie sind nicht public (im Interface) und es handelt sich nicht um ein Package, dann kann sie einfach vom Linker weggelassen werden.

Ich verwende wie gesagt weder Icons noch Cursor noch irgendwelche Packages also warum werden meine Units
durch die Package Info öffentlich gemacht.

Sie haben keinen Nutzen in irgendeiner Form.

Zitat:

da er nicht wissen kann ob eine Ressource benötigt wird

Nein ?
Ich kann sie doch explicit angeben in dem ich sie zu meinem Projekt addiere.
Wenn ich keine hinzufüge sollte auch keine zum Kompilat addiert werden.. Meine Meinung.
Wie man im Shot sehen kann den ganzen Müll (sorry) bis auf die Versions Info brauche ich einfach in der DLL nicht.

gruss

[himitsu]

Weil das Zeugs sich in vielen VCL-Units versteckt, welche du verwendest.
Und die PackageInfo ist z.B. für die RTTI mit drin.
DVCLAL sind die Lizenzinfo deiner Delphi-Version/Edition. (darüber wird geregelt ob und was in deinem Kompiilat verwendet werden darf ... z.B. falls DataSnap einkompiliert ist, aber dafür nur eine Starter/Prof verwendet wurde)

Nichtgenutztes weglassen geht halt nicht bei Ressourcen.

Bei Ressourcen und RTTI kann man auch indirekt drauf zugreifen, womit es da keine erkennbare Verbindung gibt.
Fazit: Der Compiler/Linker muß alles mit rein nehmen, falls es doch gebraucht wird.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1363935)

Weil das Zeugs sich in vielen VCL-Units versteckt, welche du verwendest.

Nichtgenutztes weglassen geht halt nicht bei Ressourcen.

JA nur verwende ich kein zumindest keine *dfm.

gruss

[himitsu]

Wie gesagt, die Unit muß nur eingebunden sein und schon ist die Ressource drin.

Drum gab es damals mal die schwachsinnigste Komponente ever.
TXPManifest ... die nur dafür sorgte, dass automatisch eine Unit ins Uses eingetragen wurde.
Nahm man die Kompoente wieder von der Form, blieb das Manifest dennoch in der Anwendung drin. :lol:

[Bernhard Geyer]

Zitat:

Zitat von EWeiss (Beitrag 1363928)

Exe Größe Hin oder Her ich meine das in Delphi Kompilierte Dateien unnötig aufgebläht sind.
Ich Kompiliere eine DLL..

Jetzt frage ich mich ernsthaft was haben da ein Icon\IconGroup, Cursor\CursorGroup und andere dinge zu suchen?

Also unsere DLLs haben kein Icon/IconGroup. Wenn du diese nicht benötigst dann deaktiviere/lösche sie doch aus dem Projekt.
Cursor\CursorGroup ist drin. Liegt halt an den VCL-Komponenten welche diese einbinden. Wenn du diese nicht benötigst, sorge durch passende Uses-Anweisung das sich nicht gezogen werden.

Zitat:

Zitat von EWeiss (Beitrag 1363928)

Die werden weder benötigt noch erfüllen sie irgendeinen zweck und sind nicht von Nöten damit meine DLL funktioniert.
Was soll das also? Und warum kann man diese NICHT benötigen Dinge aus dem Kompilat nicht ausschließen.

Hab jetzt in unserer kleinesten DLL (ohne VCL) geschaut. Dort ist weder das eine noch das andere drin.
Also macht der Compiler/Linker nichts was nicht durch das eigene Handeln (uses-Anweisung) verschuldet wäre.

Zitat:

Zitat von EWeiss (Beitrag 1363928)

Zudem sind die Package Informationen für mich ein Ansatz um das Kompilat zu dekompilieren.
Warum muss diese öffentlich in einer DLL durch das Kompilieren mit eingebunden werden.

RTTI und Co. macht es nun mal nötig das diverse Infos in solchen gemeinsam genutzten DLLs (was anderes sind die BPLs ja nicht) zur verfügung gestellt werden.
Stören diese, dann arbeite ohne BPLs.

[EWeiss]

Zitat:

Wenn du diese nicht benötigst dann deaktiviere/lösche sie doch aus dem Projekt.

Wie?
Denn ich habe schon gesagt das die DLL keine *.dfm Unit eingebunden hat.

Zitat:

Hab jetzt in unserer kleinesten DLL (ohne VCL) geschaut. Dort ist weder das eine noch das andere drin.

Ich verwende kein VCL.
Diese DLL verwendet nur Header von Diversen Plugin Typen welche dann benutzt werden um mit diesen zu kommunizieren.

Zitat:

Stören diese, dann arbeite ohne BPLs.

Wie kommst du darauf das ich BPLs verwende tue ich nicht.
Und wenn dann müssen sie irgendwo im Suchpfad liegen.

gruss

[Bernhard Geyer]

Zitat:

Zitat von EWeiss (Beitrag 1363939)

Zitat:

Wenn du diese nicht benötigst dann deaktiviere/lösche sie doch aus dem Projekt.

Wie?
Denn ich habe schon gesagt das die DLL keine *.dfm Unit eingebunden hat.

Solche Ressourcen sind nicht an dfm-Units gebunden.

Zitat:

Wie kommst du darauf das ich BPLs verwende tue ich nicht.

Sehe gerade es geht um die PACKAGEINFO-Bereich.
Den Packt Delphi auch in DLLs auch wenn es nicht immer nötig wäre.
Bei BPLs ist es nötig um um feststellen zu können wenn eine Pas-Datei sonst mehrfach geladen würde was ja dem Highlander-Prinzipg bei gemeinsam genutzter Runtime (Dll.TObject = Exe.TObject) nicht sein darf.

[EWeiss]

Na ja ist ja nicht Lebenswichtig wollte die dinge nur mal ansprechen.
Unter Verwendung von UPX werden diese Ressourcen eh eliminiert. (bzw. komprimiert)

Zitat:

Wie gesagt, die Unit muß nur eingebunden sein und schon ist die Ressource drin.

Was mich aber interessieren würde welche Unit käme da in frage die Icons und Cursors mit einbindet?

gruss

[Bernhard Geyer]

Zitat:

Zitat von EWeiss (Beitrag 1363941)

Zitat:

Wie gesagt, die Unit muß nur eingebunden sein und schon ist die Ressource drin.

Was mich aber interessieren würde welche Unit käme da in frage die Icons und Cursors mit einbindet?

gruss

Einbindung solcher Resourcen erfolgt über eine $R-Angabe (Jedenfalls ist das die Methode die ich kenne und die auch bei alten Delphis funktioniert)

Delphi-Quellcode:

{$R MeineResourcenDateimitGanzFilenIconsundCurser.res}

Also musst du in den Units die du direkt oder indirekt verwendest nach "{$R" suchen

[EWeiss]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1363943)

Zitat:

Zitat von EWeiss (Beitrag 1363941)

Zitat:

Wie gesagt, die Unit muß nur eingebunden sein und schon ist die Ressource drin.

Was mich aber interessieren würde welche Unit käme da in frage die Icons und Cursors mit einbindet?

gruss

Einbindung solcher Resourcen erfolgt über eine $R-Angabe (Jedenfalls ist das die Methode die ich kenne und die auch bei alten Delphis funktioniert)

Delphi-Quellcode:

{$R MeineResourcenDateimitGanzFilenIconsundCurser.res}

Also musst du in den Units die du direkt oder indirekt verwendest nach "{$R" suchen

Kann es sein das hier irgendetwas von meiner Frage nicht verstanden wurde?
Ich habe keine Ressource die ich einbinde die irgendwelche Cursor oder Icon Dateien enthält.
Wenn dem so wäre würde ich nicht fragen da es in dem Fall von mir selbst verursacht wurde.

Delphi-Quellcode:

{$R '_resource\Bass_Vis.res'}

enthält lediglich die Version nichts anderes.

Und ja habe alle Dateien im Projekt durchsucht.
Also noch mal welche Unit die ich nicht selbst erzeugt habe.. bsp. System, Windows, Classes enthält oder generiert Cursor oder Icon Ressourcen.

gruss

[Ghostwalker]

@EWeiss

Letztlich muss es eine Unit sein, egal ob das nun eine Interface-Unit (sprich Header-Datei) oder
eine Unit mit Komponenten ist (Achtung auch nicht visuelle Komponenten wie z.B. TTimer) könnten hier die Ursache sein. Kannst du mal angeben welche konkret enthalten sind ?

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1363947)

@EWeiss

Letztlich muss es eine Unit sein, egal ob das nun eine Interface-Unit (sprich Header-Datei) oder
eine Unit mit Komponenten ist (Achtung auch nicht visuelle Komponenten wie z.B. TTimer) könnten hier die Ursache sein. Kannst du mal angeben welche konkret enthalten sind ?

Das ist schwierig da diese sich über das komplette Projekt verteilen.
Die Projekt Units binden bzw. die DPR bindet nur eine Ressourcen Datei ein mit der Versions Info.

Eventuell kann ich mir vorstellen das die Graphics unter umständen Cursor oder Icon Symbole mit einbindet.
Und darauf hätte ich dann keinen direkten Einfluss da diese nun mal benötigt wird.

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1363945)

Also noch mal welche Unit die ich nicht selbst erzeugt habe.. bsp. System, Windows, Classes enthält oder generiert Cursor oder Icon Ressourcen.

Kannst du das an einem Minimalprojekt nachstellen?

Mir ist eigentlich nur eine Unit in Delphi bekannt, die sowohl Icons als auch Cursor registriert: Vcl.IMouse.pas, aber du benutzt ja keine VCL.

[Bernhard Geyer]

Zitat:

Zitat von EWeiss (Beitrag 1363945)

Und ja habe alle Dateien im Projekt durchsucht.
Also noch mal welche Unit die ich nicht selbst erzeugt habe.. bsp. System, Windows, Classes enthält oder generiert Cursor oder Icon Ressourcen.

Was hält dich davon ab das Source-Verzeichnis von Delphi zu durchsuchen? Dann hast du die Antwort.

[Ghostwalker]

Probier mal http://portableapps.com/apps/utiliti...ditor_portable.

Damit kannst du dir direkt die Resourcen der dll/exe anguggen, die einkompiliert werden.
Das könnte dir einen Hinweis geben, wo bzw. mit welcher Unit du dir die Icons/Cursors reinziehst.

die Graphics hab ich mir mal angesehen, da wird aber nichts inkludiert.

Hab grad einen kleinen Test gemacht (TE 2006). Wenn du ein DLL-Projekt neu anlegst, wird automatisch
im Hauptteil ein {$R *.RES} eingefügt, was bei mir dazuführt, das eine Icon-Resource hinzugefügt wird.

einfach die Zeile löschen und schon ist auch das Icon weg (bzw. die komplette Icon-Group)

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1363955)

Probier mal http://portableapps.com/apps/utiliti...ditor_portable.

Damit kannst du dir direkt die Resourcen der dll/exe anguggen, die einkompiliert werden.
Das könnte dir einen Hinweis geben, wo bzw. mit welcher Unit du dir die Icons/Cursors reinziehst.

die Graphics hab ich mir mal angesehen, da wird aber nichts inkludiert.

Hab grad einen kleinen Test gemacht (TE 2006). Wenn du ein DLL-Projekt neu anlegst, wird automatisch
im Hauptteil ein {$R *.RES} eingefügt, was bei mir dazuführt, das eine Icon-Resource hinzugefügt wird.

einfach die Zeile löschen und schon ist auch das Icon weg (bzw. die komplette Icon-Group)

Danke Uwe..
Du kennst ja mein Projekt viel hat sich da nicht geändert.
Es gibt nur die schon genannte Ressourcen Datei die ich einbinde. Diese {$R *.RES} existiert nicht.

Zur Ressource selber hab ich ja schon ein Bild hochgeladen die anzeigt was alles addiert wird.
Es ist ja nicht so das es mich sonderlich stört wollte nur darauf hinweisen das die Kompilate unnötig aufgebläht werden.
Hier kann man also als Beispiel sehen das man letztendlich nicht mal weis woher und wie diese eingebunden werden obwohl sie eigentlich nicht vorhanden sein dürften.

gruss

[EWeiss]

Nur nochmal zur Abschließenden Information.
Nach dem löschen aller unnötigen Ressourcen in der DLL von Hand nach dem Kompilieren ist die DLL um 60KB kleiner.
Und es funktioniert immer noch alles genauso wie es soll.
Es befindet sich jetzt nur noch die Version Information in der Ressource. (So wie es eigentlich sein sollte)

Jetzt fragt sich einer was soll also der ganze Müll da drin wenn man ihn zur Ausführung der DLL nicht braucht.
Nochmal es geht mir nicht um die Größe der Datei sondern um das unnötige Aufblähen der Kompilate.

gruss

[bra]

Zitat:

Zitat von EWeiss (Beitrag 1364000)

Nur nochmal zur Abschließenden Information.
Nach dem löschen aller unnötigen Ressourcen in der DLL von Hand nach dem Kompilieren ist die DLL um 60KB kleiner.

Wow... 60 kB ist jetzt natürlich eine massive Verkleinerung... :roll:

[EWeiss]

Zitat:

Zitat von bra (Beitrag 1364010)

Zitat:

Zitat von EWeiss (Beitrag 1364000)

Nur nochmal zur Abschließenden Information.
Nach dem löschen aller unnötigen Ressourcen in der DLL von Hand nach dem Kompilieren ist die DLL um 60KB kleiner.

Wow... 60 kB ist jetzt natürlich eine massive Verkleinerung... :roll:

Der "bra" mal wieder!

bevor du dumme Kommentare abgibst solltest du erst mal alles lesen.
Aber falls du zusätzlich Lesehilfe benötigst nochmal extra für dich.

Zitat:

Nochmal es geht mir nicht um die Größe der Datei sondern um das unnötige Aufblähen der Kompilate.

Und ja 60KB sind sehr viel nämlich 60KB zu viel wenn man bedenkt das diese zur Ausführung der DLL nicht von nöten sind.

gruss

[MichaelT]

Mich wundert woher RALEASE stammt :-D. Aber war das nicht mal als 'Bug' früher im Gespräch, also vor Jahren. Ich kann mich nicht mehr erinnern.

Zitat:

Zitat von Hobbycoder (Beitrag 1363886)

Zitat:

Zitat von MichaelT (Beitrag 1363883)

Das wird vermutlich nicht den großen Unterschied ausmachen...

Zitat:

Zitat von Hobbycoder (Beitrag 1363845)

Hi,
...
/Recourcen-Compiler/Verzeichnisse und Bedingen/Definiert ein Präprozessorsymbol = RALEASE;RELEASE
...
Gruß Hobbycoder

Sicher nicht, aber der Vollständigkeit halber habe ich das mit aufgeführt.