Größe C++ dll ändert sich nicht

[dbdeath74]

Hallo,

nachdem ich den Test von Luckie hier link erfolgreich zum laufen gebracht habe,
wollte ich eine bestehende c++ Anwendung zu einer dll umbauen :)

Gesagt getan :D funktioniert auch prächtig.
dll datei ist 356kb groß ....

Okay ich hatte auch einfach das Konsolenprogramm umgebaut zu einer dll.
Also erstmal alle unnötigen includes gelöscht, nen Haufen funktionen ich nicht in der dll haben will rausgeschmissen, und die Ausgabe in die Konsole natürlich auch raus.

Rein gefühlsmäßig würde ich sagen ich habe mindestens 50% rausgeschmissen (ich habe jetzt nicht die Größe jeder header datei die includiert war nachgeschaut.

okay clean project, alles neu compilieren und bauen lassen.
Und die dll ist immer noch 356kb groß :wall: :gruebel:

Das gibts doch net :?:

Habe ich irgendeine Option bei Visual c++ 2005 express übersehn oder warum wird die dll immer genau gleichgroß?

Gruß Oliver

[Der_Unwissende]

Eine Dll die immer gleich groß wird? Nein, sowas gibt es auch da nicht, schau dir einfach mal die unterschiedlichen Größen verschiedener DLLs an. Wie groß eine Headerdatei ist, sagt nicht so direkt was über die eingebundene Größe ein. Du hast in den Headern nur Konstanten-Definitionen und halt die "forward" Deklaration einzelner Methoden. Wenn du in C etwas wie die Signatur einer Datei hinschreibst, dann erwartet der Compiler einfach nur, dass die Funktion noch irgendwo in der Datei folgt. Hier kann es also schon sein, dass die zugehörige .c Datei um einiges größer ist als die .h.
Zudem hast du natürlich gerade bei einer Dll einen gewissen Overhead, der einfach nötig ist um verschiedenen Programmen die Bindung zur Laufzeit zu ermöglichen. Ist dieser Overhead im Verhälnis zu deinem Programm einfach groß, wirst du natürlich kaum eine Änderung bemerken.
Dann kann es auch noch sein, dass der Compiler schon selbst optimiert und nur das linkt, was wirklich erreicht werden kann. Dann fliegen unnötig eingebundene Bibliotheken automatisch.

Du siehst, einige Möglichkeiten.

Gruß Der Unwissende

[dbdeath74]

Hallo,

dessen bin ich mir durchaus bewusst.
Nur war die exe vorher auch so groß.

Wenn ich aber Sachen wie

Code:

#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <winioctl.h>

komplett rausschmeisse und die Anwendung von 10 umfangreichen funktionen auf eine kürze die mich interessiert würde ich erwarten das es wenigstens ein bißchen kleiner wird.
Und nicht aufs kb genauso groß.

Deswegen meine Vermutung das er sie nicht wirklich neu gemacht hat (auch wenn ich clean, compile und rebuild mache).

Ich dachte vielleicht habe eine Option übersehn, bin ja nicht so der VC guru *g :angel2:

Gruß Oliver

[SirThornberry]

wenn du nur die H-Dateien entfernst spielt das keine Rolle da die H-Dateien ne Headerdefinition sind damit der Compiler weiß wie der entsprechende Aufruf auszusehen hat. Nach dem compilieren spielen also Hinweise für den Compiler keine Rolle mehr.

[dbdeath74]

ja das ist klar.
aber ich habe ja wirklich viele Sachen rausgeschmissen.

Ich habe jetzt mal einfach den bereinigten sourcecode genommen und ein neues dll projekt gemacht und siehe da die dll hat nur 46kb und geht immer noch oO

Also irgendeine Einstellung muss es geben die das vorher verhindert hat :gruebel:

Gruß Oliver

[OregonGhost]

Hast du in beiden Fällen im Release-Modus kompiliert?
Und hast du die Standardbibliothek möglicherweise im einen Fall statisch eingebunden? Gerade bei der Umstellung von Windows- auf Konsolenanwendung (oder umgekehrt) kommen da einige Einstellungen durcheinander.

[dbdeath74]

Hmmm release modus ? :gruebel:

Nein ich habe in beiden Fällen im debug modus kompiliert.
Ich habe die Option zwar gesehn, aber als ich gesehn habe das dann wieder alle Projekteinstellungen weg sind habe ich wieder zurückgestellt.

Ich dachte das wären nur verschiedene "Profile", in dennen man verschiedene Einstellungen treffen kann.
Macht der release modus noch irgendetwas anderst?

Ich hatte im debug modus einfach das Projekt gecleant(debug ordner ist dann leer), neu compiliert und einen rebuild gemacht.
Für mein Verständniss dachte ich das er es auch dann wirklich neu macht.

Oder es war wirklich irgendeine Projekteinstellung. Beim neuen Projekt hatte ich dann gleich dll ausgewählt, während ich beim alten in den Projektoptionen auf dll umgestellt hatte. Wer weiß was da bei den 200 Optionen noch anderst war.

Gruß Oliver

[dbdeath74]

Hallo,

nun weiß ich warum man den release modus benutzen sollte *g
VC++ benutzt spezielle debug dlls im debug modus die normalerweise nicht auf Nicht-Entwicklungsrechnern vorhanden sind.

Nun bin ich aber auf die nächste Grausamkreit von MS gestossen ...
Die Abhängigkeit von speziellen dlls die von der Entwicklungsumgebung abhängen....

Dazu kommt noch das man ab XP diese dlls nicht einfach dem Program beilegen kann, sondern das sie speziell installiert werden müssen.

Zitat:

The second change is that projects created with VC2005 IDE now dynamically link to the C-runtime libraries by default. In VC2003, only MFC and managed C++ apps dynamically linked to the CRTs by default.

Finally, the C and C++ runtimes are now implemented as Side-by-Side DLLs. It's no longer enough to copy MSVCR80.DLL/MSVCP80.DLL/MSVCM80.DLL (from now on called the CRT DLLs) into the System32 directory. You must now load the CRT DLLs through a manifest. If you attempt to load the CRT DLLs without using a manifest, the system will detect this, raise an R6034 assertion, and abort(). That's why the CRT DLLs are now located in WinSXS and not in the System32 directory.

Die Problematik ist auch hier beschrieben: link

Es gibt aber einen Workaround.
Damit meine dll trotzdem auf anderen rechnern läuft musste ich nun die crt dlls dazupacken, eine xml manifest datei anlegen und dann läuft es auch auf jedem Rechner.

Diese Vorgehensweise ist aber sehhhhr unbefriedigend, vor allem da ich nichts davon in meiner dll verwende *grr. Der Orginal Code ist von 2000, ich benutze nur stdio.h und windows.h
Nur weil MS der Meinung ist das müsste so sein wenn man mit VC2005 etwas kompiliert :wall:

Kann mir jemand eine gute kostenlose C++ Entwicklungsumgebung empfehlen mit der ich eine ganz simple dll erstellen kann?

Gruß Oliver

[Luckie]

Eclipse mit den C/C++ Plugin?

[OregonGhost]

Ein Bekannter von mir ist ganz begeistert vom Borland C++-Builder X, ich weiß nicht, ob es den noch kostenlos gibt.

Wenn du bei Visual-C++ bleiben willst:

Die CRT kann meines Wissens auch einfach statisch eingebunden werden (also so, wie auch im Normalfall die VCL in Delphi eingebunden wird). Eine von den 200 Optionen ist dafür zuständig, das müsste eigentlich Code Generation->Runtime Library sein. Da man sogar der ATL sagen kann, dass sie die CRT statisch linken soll, sollte das eigentlich hierüber möglich sein.
Ja, du hast recht, grundsätzlich ist der Unterschied zwischen Release und Debug, dass du einfach zwei verschiedene Sets von Einstellungen hast. Wie du aber schon festgestellt hast, sind es wirklich eine Menge Einstellungen, und Release entfernt eben alle Debug-Informationen, aktiviert Optimierungen usw.
DLLs und Anwendungen brauchen auch normalerweise eine Menge unterschiedlicher Einstellungen. Die beiden Sets von Einstellungen werden beim Erstellen des Projekts entsprechend voreingestellt.

Edit:
Auszug aus dem von dir verlinkten Artikel auf codeproject.com:

Zitat:

The final option is to statically link your executable to the CRT (by the way, this is how the bootstrapper is able to run without the CRTs). To statically link to the executables, go to the Project -> Project Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library (change from "Multi-Threaded DLL" to "Multi-Threaded").

If you're careful enough, you can even get the application to run on Windows NT! The pieces of the CRT that require InterlockedCompareExchange and GetLongPathNameW get discarded out of your final executable, and thus your app can run on Windows NT. In order for this to happen, you have to be careful about which C functions you call (no iostream, no locale, no algorithm), and you'll probably have to upgrade to the latest service pack for Windows NT (plus all post service pack patches).

Using this method is not much better than rebuilding the CRTs. Once again, if your application consists of several DLLs where each DLL expects STL/CRT parameters, you will get serious bugs until you rebuild by dynamically linking the CRT.

And if Microsoft issues a fix for their routines, and you use this method, you become solely responsible for fixing both yours and Microsoft's bugs.

Der Artikel beschreibt halt auch, wie man die CRT-DLLs sauber installiert kriegt und so weiter, für ein "ernsthaftes" großes Projekt ist das sicherlich auch nicht das schlechteste.