Warum sind Executables so groß

Warum sind Executables so groß? Klar, man hat da ein paar verschiedene Sektionen etc., aber letztlich kann ich z.B. nicht nachvollziehen warum eine .exe Datei die VS aus Code generiert der nichts (!) macht immer noch 7KB groß ist. Und sobald man die Ausgabe auch nur anguckt, springt es auf 300KB. Sollte so etwas nicht eher im Bereich von einigen (hundert) Byte liegen?

das ist abhängig vom compiler.

unter linux erzeugt der mingw cross-compiler für einfache hello-world-programme 500KB große dateien.

wahrscheinlich ist eh ein großteil von dem, was in so einer exe liegt, müll, den der compiler nicht aufgeräumt hat.

meine vermutung.

manche compiler haben auch spezielle optimierungen drauf, wo dann dein quellcode vom compiler "verbessert" wird, so erhofft man sich, dass die programme stabiler laufen und die exes kleiner sind. aber danke, am ende optimiert der meinen code noch kaputt.

volkard

Also erstmal, 7k ist nicht viel.
Der Code macht nicht nichts, er macht trotzdem die Konsole auf, wozu er eine DLL vorher lädt, initialisiert Stack und Heap, wozu er auch globale Variablen anlegt. Und Schwupps, will man dann noch Code und Daten in getrennten Speicherseiten haben, zahlt man besser mal zwei. Ach, nicht schlimm. Meistens hat man soo viel Anwendercode, daß die 7k Grundlast total egal sind.

Anders natürlich, wenn man ein BS bauen will. Dann kommt schonmal Frust auf.
Nur einmal virtual geschrieben, und zack, ist die Funktion dabei, die nötigenfalls mit einem "pure virtual call"-Error abbricht nebst Anzeige. Natürlich der Einfachheit halber mit cout-Sachen angezeigt und zack, hat man 300k am Backen. Und den Code für dynamic_cast nebst den Exceptions, der Exception-Zwischenspeicher ist mal defensiv 30k groß und liegt als globales Array erstmal in der exe, 30k wieder. Und man könnte ja die Exception nicht fangen wollen, also der Standard-Handler für unhandled_exception ist drin, der zeiht wieder Ausgabe. new? Könnte werfen, also zahlt man die 30k.

Ist normalerweise aber überhaupt nicht Schlimm. Macht die exe größer, aber frißt kein physikalisches RAM zur Laufzeit, solange es nicht echt gebraucht wird. Die exe wird über die normalen File-Mapping-Mechanismen in den Speicher gemappt und es flutschen nur die Seizen ins RAM, die auch gebraucht werden. Theoretisch. Praktisch flutsch auch mal alles rein als Optimierung, in der Annhame, daß man es brachen wird. Unter Speicherdruck flutsch es aber auch wieder raus.

Es ist unter Umständen üblich, daß die Sachen um cout miteingebunden werden. 300k. Meistens kann man den Compiler zwingen, den Kack mal zu lassen. Bei MSVC mit den dynamischen Laufzeitbibliotheken binden, ist aber doch inzwischen voreingestellt, dachte ich. Unter linux auch.

Ok, crosscompiling bestraft sich hier, der GCC wird wohl kaum die DLLs von MS benutzen können mit MS-cout.

SideWinder

Auch interessant, als Ergänzung zu den von volkard gebrachten Grundlagen: http://www.catch22.net/tuts/reducing-executable-size

MfG SideWinder

Kellerautomat

Netter Artikel
Gibts sowas vielleicht auch fuer Unix basierte Systeme? (OS