Executables in Visual C++ und MinGW

Jochen Kalmbach

Also für die ganz Faulen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-143003.html

Existiert eigentlich noch ein weiterer kostenloser Compiler für Windows, der so standardkonform wie der G++ ist und der beim Erstellen der Exe-Dateien wirklich nur das mit einbindet, was gebraucht wird (wie beim VC6) und nicht eine einzelne stdc++ hat, die er dann komplett mitlinkt?

Ja, VisualC++ 2005 Express. Davon reden wir hier die ganze Zeit.

Es sollte eigentlich klar sein, dass ich diesen von meiner Frage implizit ausgeschlossen habe. (Eben weil wir die ganze Zeit davon sprechen, meinte ich natürlich: Gibt es außer MinGW und VC2005 noch so einen Compiler?) Zumal sich ja auch herausgestellt hat, dass der eben nicht die obigen Voraussetzungen erfüllt. Wie war das noch mal: 108 KB für eine Anwendung, die nur ein cout durchführt vs. 52 KB für dasselbe Programm bei VC6? Das sieht für mich so aus, als würde VC2005 die Standard Bibliothek durchaus als einzelne Komplettbibliothek mitlinken (wie der MinGW, bloß mit einigen Optimierungen), aber meine Frage war, welcher standardkonforme Compiler das nicht tut, sondern bei #inlcude <iostream> wirklich nur die iostream einbindet, weil die Implementierung als Ansammlung von Quellcodes und Assember-Dateien vorliegt (wie bei VC6) und nicht als eine DLL-ähnliche Komplettbibliothek.

Jochen Kalmbach

@Eric: Es scheint so also ob Du keine Ahnung hast was der MS Compiler/Linker da wirklich macht. Auch willst Du nicht begreifen, dass es "Fortschritte" zwischen VC6 und VC2005 gab. Die "vergrößerung" der EXE magst Du zwar nicht als "Fortschritt" ansehen, ist es aber, da in VC2005 wesentlich mehr auf Code-Sicherheit geachtet wurde. Das macht das Ding halt dann etwas größer.

Und was andere Compiler anbelangt: Du kannst Comeau verwenden, der ist am Standard-Konformsten.

@Eric: Es scheint so also ob Du keine Ahnung hast was der MS Compiler/Linker da wirklich macht.

Mag sein. Klärst Du mich da bitte auf?

Auch willst Du nicht begreifen, dass es "Fortschritte" zwischen VC6 und VC2005 gab. Die "vergrößerung" der EXE magst Du zwar nicht als "Fortschritt" ansehen, ist es aber, da in VC2005 wesentlich mehr auf Code-Sicherheit geachtet wurde. Das macht das Ding halt dann etwas größer.

Was heißt hier nicht begreifen wollen? Bisher hat mir ja noch keiner konkret erklärt, dass die zusätzliche Größe mit Codesicherheit statt mit Linken der gesamten Standard Library zusammen hängt, also musste ich bisher selbst kombinieren. Und wenn ich sehe, dass ein Programm mit einer leeren main 48 KB groß ist und eins mit einer main mit cout 108 KB, während früher beides nur 52 KB groß war, dann denke ich nun mal zuerst daran, dass VC2005 die gesamte Standard Library mit komplett linkt und nicht daran, dass die Impleementierung der iostream aufgrund von Codesicherheit so viel größer ist.

Und was andere Compiler anbelangt: Du kannst Comeau verwenden, der ist am Standard-Konformsten.

Ja, aber der kostet auch dementsprechend. Und außerdem weiß ich nicht, wie groß die Exe-Dateien dort werden.

Die Bitte war übrigens ernst gemeint.

Jochen Kalmbach

Das meiste hab ich ja schon gesagt... der MS Linker bindet nur das in die EXE ein, was die EXE auch benötigt. Und das wurde halt mit VC8 um einiges erweitert hauptsächlich was das Thema Sicherheit anbelangt (es werden Zeiger jetzt intern verschlüsselt gespeichert; Parameter-Überprüfungen werden jetzt nicht nur im Debug-Build gemacht sondern prinzipiell). Das macht es halt "wesentlich" größer als bei VC6, da dies alles noch nicht drin war.

Wie sieht's denn mit den Quellcodes aus? Sind die einsehbar (wie bei VC6) oder nicht (wie bei MinGW)?

Kann mir noch jemand sagen, wie groß eine Anwendung, die nur eine Ausgabe (cout) tätigt, ist, die im Release-Modus mit VC2003 kompiliert wurde?

P.S.: Braucht so eine VC2005-Konsolenanwendung (wenn sie kein MFC benutzt, sondern nur Standard-Header einbindet und vielleicht noch die Windows.h) eigentlich irgendwelche zusätzlichen Dateien (DLL oder dieses Manifest)?

Jochen Kalmbach

Eric P. schrieb:

Wie sieht's denn mit den Quellcodes aus? Sind die einsehbar (wie bei VC6) oder nicht (wie bei MinGW)?

Quellcode zu was? CRT/MFC/STL/ATL? Ja die sind einsehbar (musst sie nur bei der Installation ausgewählt haben).

Eric P. schrieb:

P.S.: Braucht so eine VC2005-Konsolenanwendung (wenn sie kein MFC benutzt, sondern nur Standard-Header einbindet und vielleicht noch die Windows.h) eigentlich irgendwelche zusätzlichen Dateien (DLL oder dieses Manifest)?

Wenn Du die Default-Einstellungen verwendest, dann *musst* Du noch die 3 CRT-Dateien (DLLs) mitliefern. Dann dürfte aber Deine EXE wesentlich kleiner als sein.

Ich rate Dir nicht die Default-Einstellungen zu verwenden, sondern gegen die "statische Version der CRT" zu linken! Damit musst Du dann nix mitliefern und ersparst Dir unnötigen manifest-Ärger...
(Properties|C/C++|Code Generation|Runtime Library: Multi-threaded (Debug))
Die EXE wird dann logischerweise etwas größer, da ja die Funktionen aus den DLLs in der EXE drin sind...

Warum brauchen die Anwendungen überhaupt DLL-Dateien? Beim alten 6er war das noch gar nicht der Fall, nur bei MFC-Anwendungen. Konsolenprogramme brauchten gar nichts weiter und die DLL-Dateien für WinAPI-Anwendungen sind ja sowieso auf jedem Windows vorhanden. Ich verstehe deshalb nicht, warum die Anwendungen der 2005er Version DLL-Dateien statisch oder dynamisch linken müssen. Vor allem, wenn die Quellcodes vorhanden und einsehbar sind. Wenn die Funktionalitäten zum Beispiel der iostream schon als Code implementiert sind, wozu ist da noch eine Runtime Library nötig? Damals haben Konsolenanwendungen auch nicht die MSVCRT.DLL gebraucht.

Jochen Kalmbach

Eric P. schrieb:

Warum brauchen die Anwendungen überhaupt DLL-Dateien? Beim alten 6er war das noch gar nicht der Fall, nur bei MFC-Anwendungen.

Nein, das war bei VC6 genauso! Du musstest auch die msvcrt.dll mitliefern, wenn Du gegen die DLL-Version der CRT gelinkt hast!
Erst seit Windows XP ist die msvcrt.dll Bestandteil des OS und muss somit nicht mehr mitgeliefert werden. Vermutlich hast Du Glück gehabt, da viele Programme eine passende msvcrt.dll installieren...
Aber wie gesagt: Wenn Du statisch linkst, benötigst Du gar keine DLL! Weder bei VC6 noch bei VC8!

Eric P. schrieb:

Konsolenprogramme brauchten gar nichts weiter

Das hat überhaupt nichts mit Consolen- oder Windows-Programme zu tun! Du kannst in einem Consolen Programm genauseo MFC/ATL verwenden.... und CRT sowieso...

Eric P. schrieb:

Ich verstehe deshalb nicht, warum die Anwendungen der 2005er Version DLL-Dateien statisch oder dynamisch linken müssen. Vor allem, wenn die Quellcodes vorhanden und einsehbar sind. Wenn die Funktionalitäten zum Beispiel der iostream schon als Code implementiert sind, wozu ist da noch eine Runtime Library nötig?

Deine Ausführungen sind mir schleierhaft; bzw. ich verstehe sie nicht...

Eric P. schrieb:

Damals haben Konsolenanwendungen auch nicht die MSVCRT.DLL gebraucht.

Blödsinn! Natürlich haben alle diese DLL benötigt, welche die CRT dynamisch gelinkt haben!

Nein, das war bei VC6 genauso! Du musstest auch die msvcrt.dll mitliefern, wenn Du gegen die DLL-Version der CRT gelinkt hast!

Definitiv nicht. Erstens gibt es zwar bei MFC-Anwendungen durchaus die Einstellungsmöglichkeit, die DLL-Dateien entweder statisch oder dynamisch zu linken (in der Professional-Version), während das bei Konsolenanwendungen (ohne MFC) überhaupt nicht geht. Zweitens habe ich es selbst auf einem frisch installierten Windows 95 ausprobiert: Eine Konsolenanwendung ohne MFC funktioniert problemlos. Genauso wie eine WinAPI-Anwendung. Aber bei einer MFC-Anwendung sagt er, dass die MSVCRT.DLL und die MFC42.DLL fehlt. Ergo brauchten Konsolenanwendungen ohne MFC keine MSVCRT und diese wird nur bei MFC-Anwendungen gebraucht. (Und da ich mit der Standard-Version kompiliert habe, ist auch nicht denkbar, dass die MSVCRT.DLL implizit statisch gelinkt wurde, weil es da kein statisches Linken gibt.)

Erst seit Windows XP ist die msvcrt.dll Bestandteil des OS und muss somit nicht mehr mitgeliefert werden.

Die MSVCRT.DLL war bereits bei Windows 98 (First Edition) dabei. Auch das hab ich ausprobiert.

Das hat überhaupt nichts mit Consolen- oder Windows-Programme zu tun! Du kannst in einem Consolen Programm genauseo MFC/ATL verwenden.... und CRT sowieso...

Du weißt, was ich meine. Es ist natürlich klar, dass auch in Konsolenanwendungen die MFC benutzt werden kann, aber wenn ich von einer Konsolenanwendung spreche, meine ich in der Regel eine Anwendung ohne MFC.

Ich verstehe deshalb nicht, warum die Anwendungen der 2005er Version DLL-Dateien statisch oder dynamisch linken müssen. Vor allem, wenn die Quellcodes vorhanden und einsehbar sind. Wenn die Funktionalitäten zum Beispiel der iostream schon als Code implementiert sind, wozu ist da noch eine Runtime Library nötig?

Deine Ausführungen sind mir schleierhaft; bzw. ich verstehe sie nicht...

Ganz einfach: Wenn ich eine Sammlung von Klassen schreibe und diese als Quellcode weitergebe, dann braucht der Anwender diese Quellcodes nur mitzukompilieren und meine gesamten Funktionalitäten werden direkt in sein Programm übernommen. Wenn ich eine DLL-Datei habe, dann kann er diese entweder statisch mitlinken oder dynamisch drauf zugreifen.
Wenn nun Visual C++ 2005 die Implementierung der Funktionen aus den Headern als Quellcode vorliegen hat, wieso muss dann noch eine DLL statisch oder dynmaisch gelinkt werden. Entweder Quellcodes oder DLLs. Wenn die Standard Library als Quellcode einsehbar ist, wieso gibt es dann eine DLL, die die Standard Library enthält? Sonst hat man doch auch keine Datei

#include "My Class.h"

void MyClass::function()
{
}

und eine DLL, die MyClass::function() beinhaltet. Deshalb verstehe ich den Sinn des ganzen nicht.

Jochen Kalmbach

Eric P. schrieb:

Erstens gibt es zwar bei MFC-Anwendungen durchaus die Einstellungsmöglichkeit, die DLL-Dateien entweder statisch oder dynamisch zu linken (in der Professional-Version), während das bei Konsolenanwendungen (ohne MFC) überhaupt nicht geht.

Du sagst es...
Das hat aber nix mit Konsolen-Anwendung zu tun!
Wenn ich eine Windows-Anwendung ohne MFC mache, brauch ich auch keine MFC! Genauso ist es auch mit einer Consolen-Anwenundung. Wenn ich hier die MFC haben will, dann brauch ich eben die MFC; wenn nicht dann nicht!

Eric P. schrieb:

Zweitens habe ich es selbst auf einem frisch installierten Windows 95 ausprobiert: Eine Konsolenanwendung ohne MFC funktioniert problemlos.

Und? Wie waren die C/C++-CRT-Runtime-Einstellungen? Statisch oder DLL? Das hat mit der MFC nix zu tun!

Eric P. schrieb:

Genauso wie eine WinAPI-Anwendung. Aber bei einer MFC-Anwendung sagt er, dass die MSVCRT.DLL und die MFC42.DLL fehlt.

??? Jetzt auf einmal fehlt die mscvrt.dll doch!? Vielleicht liegt es daran, dass Du gegen die DLL Version linkst!? Linke statisch, dann fehlen sie plötzlich nicht mehr!

Eric P. schrieb:

Ergo brauchten Konsolenanwendungen ohne MFC keine MSVCRT

Also; ein letztes Mal: DAS HÄNGT NUR VON DEN "RUNTIME-SETTINGS" DER CRT AB!!! (DLL ODER STATSCH). Hat nix mit MFC zu tun... und gleich gar nix mit Console/Windows...

Eric P. schrieb:

...ist auch nicht denkbar...

Du sollst nicht denken, sondern in Deinen Einstellungen *nachschauen*!

Eric P. schrieb:

Die MSVCRT.DLL war bereits bei Windows 98 (First Edition) dabei. Auch das hab ich ausprobiert.

Es scheint wohl so zu sein, da hab ich mich getuscht...
(http://support.microsoft.com/kb/156976/en-us)

The file MSVCRT.DLL is included in Windows 2000, Windows 98, and Windows Me, but not in Windows 95 or Windows NT 4.0.

Eric P. schrieb:

Das hat überhaupt nichts mit Consolen- oder Windows-Programme zu tun! Du kannst in einem Consolen Programm genauseo MFC/ATL verwenden.... und CRT sowieso...

Du weißt, was ich meine. Es ist natürlich klar, dass auch in Konsolenanwendungen die MFC benutzt werden kann, aber wenn ich von einer Konsolenanwendung spreche, meine ich in der Regel eine Anwendung ohne MFC.

Dann sag doch einfach "Anwendung ohne MFC"!

Eric P. schrieb:

Wenn nun Visual C++ 2005 die Implementierung der Funktionen aus den Headern als Quellcode vorliegen hat, wieso muss dann noch eine DLL statisch oder dynmaisch gelinkt werden.

Es gibt nicht zwei sondern drei Möglichkeiten:
1. Sourcen direkt einbinden
2. Sourcen in DLL "packen"
3. Sourcen in LIB "packen"

Das erste scheidet aus, da sonst ein "Hello-world" Programm ca. 5 min. zum Compilieren benötigt.
Das zweiten wird von MS bevorzugt, finde ich aber im normalfall schlecht, da hier DLLs mitgegeben werden müssen.
Das dritte ist meine bevorzugte Version, da das Compilieren schnell geht und ich keine (ich wiederhole nochmals K E I N E) DLLs mitgeben muss (egal ob MFC oder nicht!)

Ich bin mir natürlich der Tatsache bewusst, dass das Linken von DLL-Dateien erstmal an sich nichts mit der Frage zu tun hat, ob die MFC genutzt wird oder nicht. Aber was ich sagen will, ist: Nur MFC-Programme müssen in VC6 überhaupt gegen eine MSVCRT.DLL linken, andere Programme tun das nicht.

Eine MFC-Anwendung mit dynamisch gelinkten DLL-Dateien läuft unter Windows 95 nicht, es sei denn, man packt die Dateien MSVCRT.DLL und MFC42.DLL in den Programmordner oder nach C:\WINDOWS\SYSTEM. Und eine MFC-Anwendung mit statisch gelinkten DLL-Dateien ist mindestens 1,22 MB groß.
Eine Nicht-MFC-Anwendung läuft unter Windows 95 ohne Probleme, es werden DLL-Dateien also nicht dynamisch gelinkt. Und dass die MSVCRT.DLL statisch gelinkt wird, ist auch auszuschließen, denn dann könnte so eine Anwendung nicht 52 KB groß sein, da die MSVCRT.DLL schon 284 KB groß ist.
Ergo benötigen Nicht-MFC-Anwendungen unter VC6 gar keine MSVCRT.DLL, weder statisch noch dynamisch und ich wüsste auch nicht, wo man das einstellen soll. Wie man die Dateien bei MFC-Anwendungen linken will, das stellt man unter "Projekt", "Einstellungen", "Allgemein" ein. Außerdem wird man dazu am Anfang beim Anlegen eines Projektes befragt. Wenn man allerdings die MFC nicht verwendet, gibt es überhaupt keine Einstellungsmöglichkeit, wo man die Art des Verlinkens festlegt. Wo sollte die denn stehen? Ich habe bisher noch keinen Menüpunkt geunden, wo ich auswählen kann: Runtime statisch oder dynamisch linken. Es gibt also keine Runtime-Settings. Die einzigen DLL-Einstellungsmöglichkeiten existieren, wenn man MFC-Anwendungen hat. Also gehe ich davon aus, dass in VC6 nur MFC-Anwendungen so konzipiert sind, dass sie DLL-Dateien brauchen. Alles andere kommt gänzlich ohne MSVCRT.DLL aus. (Anders als beim VC2005, wo man überall wählen muss, wie man die denn nun linkt.)

Es gibt nicht zwei sondern drei Möglichkeiten:
1. Sourcen direkt einbinden
2. Sourcen in DLL "packen"
3. Sourcen in LIB "packen"

Gut, das mit der Lib hab ich vergessen. Aber trotzdem bleibt die Frage: Wenn Microsoft nur mit den DLLs arbeitet, warum sind dann die Quellcodes sichtbar bzw. wofür werden die gebraucht?

Nachtrag:
Oder ist die statische C-Runtime gar nicht die MSVCRT.DLL, sondern die MSVCRT.LIB? Aber dann stellt sich trotzdem die Frage: Es ist nur eine einzelne Datei. Die Runtime besteht nicht aus mehreren Lib-Dateien, die je nach Bedarf eingebunden werden, sondern es ist eine einzelne Datei und die ist immerhin noch 185 KB groß. Wenn sie in ein Programm gelinkt wird, müsste das doch auch mindestens 185 KB groß sein. Wie kann es, wenn es die Standard-Bibliothek einbindet und nutzt, trotzdem auf 52 KB kommen und von keiner externen DLL-Datei abhängig sein?

Jochen Kalmbach

Eric P. schrieb:

Aber was ich sagen will, ist: Nur MFC-Programme müssen in VC6 überhaupt gegen eine MSVCRT.DLL linken, andere Programme tun das nicht.

NEIN!!! "msvcrt.dll" heisst *nicht* MFC.dll!!!
MSVCRT => Microsoft Visual C Runtime!!! (nix MFC!)

MFC => MFC42.DLL!!!

Eric P. schrieb:

Eine Nicht-MFC-Anwendung läuft unter Windows 95 ohne Probleme,

NEIN! Wenn die msvcrt.dll nicht da ist und Du gegen die DLL-version der CRT linkst, dann brauchst Du diese DLL! (aber ich gebe es jetzt auf).

Eric P. schrieb:

Und dass die MSVCRT.DLL statisch gelinkt wird, ist auch auszuschließen, denn dann könnte so eine Anwendung nicht 52 KB groß sein, da die MSVCRT.DLL schon 284 KB groß ist.

Der Linker rügt nur diese Funktionen der EXE hinzu die auch benötigt werden. Die msvcrt.dll enthält dagegen alle.

Eric P. schrieb:

Aber trotzdem bleibt die Frage: Wenn Microsoft nur mit den DLLs arbeitet

Wer sagt das?

Eric P. schrieb:

warum sind dann die Quellcodes sichtbar bzw. wofür werden die gebraucht?

Womöglich, dass Du in die CRT-Funktionen reindebuggen kannst!?
Sonst immer wird geklagt das MS den Source vorenthält, jetzt beklagst DU DIch, das MS den Source mitliefert...
Der zweite Grund ist: Du kannst natürlich die CRT verändern wie Du willst und diese zu Deinem Programm dazulinken wie Du lustig bist...

Jochen Kalmbach

Eric P. schrieb:

Oder ist die statische C-Runtime gar nicht die MSVCRT.DLL, sondern die MSVCRT.LIB? Aber dann stellt sich trotzdem die Frage: Es ist nur eine einzelne Datei. Die Runtime besteht nicht aus mehreren Lib-Dateien, die je nach Bedarf eingebunden werden, sondern es ist eine einzelne Datei und die ist immerhin noch 185 KB groß. Wenn sie in ein Programm gelinkt wird, müsste das doch auch mindestens 185 KB groß sein. Wie kann es, wenn es die Standard-Bibliothek einbindet und nutzt, trotzdem auf 52 KB kommen und von keiner externen DLL-Datei abhängig sein?

.... ein letztes Mal:
Die C-Runtime gibt es in VC5-VC2003 in *drei* verschiedenen Kombinationsmöglichkeiten.
LIB-Dateien gibt es dazu jeweils immer, da *nie* die Sourcen direkt eingebunden werden (dass kannst Du auch, musst Du aber von hand machen).

Diese Ausprägungen sind:
- Debug / Release
- Multithreaded / Singlethreaded (das letztere wurde in VC2005 entfernt)
- Statisch / Dynamisch

Und wir reden eigentlich nur über das letzte.

Die passenden LIBs sind:
Statisch:
LIBC.LIB / LIBCD.LIB / LIBCMT.LIB / LIBCMTD.LIB
(diese LIBs enthaöten *keine* Import-Verweise auf MSVCRT*.dll)

Dynamisch:
MSVCRT.LIB / MSVCRTD.LIB
(und diese msvcrt*.lib enth#lt *nur* Import-Verweise auf die msvcrt*.DLL

rüdiger

Der MinGW linkt glaube ich Standardmäßig statisch. Daher hast du einen fixen Overhead drin. Versuch mal als Compiler-Flag -dynamic. Ich weiß aber nicht ob das geht.

Ansonsten kann dir -Os -fomit-frame-pointer -s vielleicht helfen ein etwas kleineres Binary zu bekommen

NEIN!!! "msvcrt.dll" heisst *nicht* MFC.dll!!!
MSVCRT => Microsoft Visual C Runtime!!! (nix MFC!)

MFC => MFC42.DLL!!!

Ich weiß. Ich hab doch gesagt, dass ich weiß, dass das an sich erstmal nichts miteinander zu tun hat. Aber trotzdem sieht es in der Praxis so aus: In VC6 braucht jede MFC-Anwendung die MSVCRT.DLL entweder dynamisch oder statisch gelinkt. Und: In VC6 braucht keine Anwendung ohne MFC die MSVCRT.DLL. Es gibt nichtmal eine Möglichkeit, einer Nicht-MFC-Anwendung zu sagen, dass sie die MSVCRT.DLL irgendwie linken soll.

Eine Nicht-MFC-Anwendung läuft unter Windows 95 ohne Probleme,

NEIN! Wenn die msvcrt.dll nicht da ist und Du gegen die DLL-version der CRT linkst, dann brauchst Du diese DLL! (aber ich gebe es jetzt auf).

Wie gesagt: Es gibt in VC6 keine Möglichkeit, bei einem Programm, das nur die Standard-Header benutzt, die MSVCRT.DLL dynamisch zu linken. Deshalb funktionieren solche Programme unter Windows 95 immer. Weil eine Anwendung, die nur die Standard-Header (und die windows.h) benutzt, die CRT gar nicht dynamisch per DLL linken kann.

Mir ist da übrigens noch mal etwas aufgefallen. Von www.mingw.org:

The need to statically link the stdc++ into the binary is two fold. First MSVCRT.dll does not contain C++ stdlib constructs.

Nach dem, was hier steht, ist die MSVCRT.DLL gar nicht für Standard-Funktionalitäten da. Demnach könnte man es also gar nicht so machen, dass man die MSVCRT.DLL dynamisch linkt und auf die LIBC.LIB verzichtet, da sie ja für die Standardfunktionalitäten gar nicht zuständig ist. Und somit erklärt sich auch, wieso man in VC6 keine Option hat, bei Standard-Anwendungen diese DLL dynamisch zu linken. Denn wenn die MSVCRT.DLL keine Standardfunktionalität (aus diesen 32 ISO-Headern) bietet, dann muss man die LIBC.LIB ohnehin immer mitlinken. Die MSVCRT.DLL ist somit wohl ohnehin für ganz andere Dinge zuständig und nicht für die Implemetierung der iostream.

Der Linker rügt nur diese Funktionen der EXE hinzu die auch benötigt werden. Die msvcrt.dll enthält dagegen alle.

Ah ja, da liegt der Hund also begraben. Ich wusste nicht, dass es geht, dass sich der Linker nur die Funktionen raussucht, die nötig sind.

Sonst immer wird geklagt das MS den Source vorenthält, jetzt beklagst DU DIch, das MS den Source mitliefert...

Ich hab mich nicht beklagt, ich habe nur nach dem Sinn gefragt.

Der MinGW linkt glaube ich Standardmäßig statisch. Daher hast du einen fixen Overhead drin. Versuch mal als Compiler-Flag -dynamic. Ich weiß aber nicht ob das geht.

Na ja, er soll ja schon statisch linken. Eine Anwendung, die von DLL-Dateien abhängig ist, ist so wie so nicht das wahre. Aber ich hätte es eben gern, dass er nur die Funktionalitäten mitlinkt, die auch gebraucht oder zumindest per #include eingebunden sind. Eben so, wie es Visual C++ macht. Dass nicht ein

#include <string>

die gesamte Standard Library einbindet.

Jochen Kalmbach

Wie gesagt: IMHO redest Du Blödsinn und ich werde jetzt keine weiteren Kommentare dazu abgeben. (Punkt)

LinkeT

die grosse einer exe ist relativ egal ... der cpu lädt eh nie das gesamte programm rein
effektiv ist die grösse der funktionen interresant (und da wird dank multitasking wieder mal vom OS reingschnibbelt)

auch wenn alle funktionen un co in dlls gepackt werden und die exe nur noch 50kb gross wäre läuft nix schneller (im gegenteil das programm muss erstmal beim start auf alle dlls zugreifen -> hin un her röddeln auf der platte)

wenn du mehrere anwendungen schreibst die alle samt ein paar funktionen hast lohnt sich das ganze nur für den benutzer da er so hdd-speicher spart beim neusten taktik shooter von ubi ist die exe 33mb gross also für mich bisslang absoluter record (UT2007 wird vllt grösser mal schaun)[ausgenommen selbst extrahierenden archiven]

mit MFC kenn ich mich [och] nich aus

edit
"eine anwendung die von dlls abhängig ist eh nicht das wahre" ... wirste merken wenn du nen update rausbringst wo nur eine funktion geändert werden muss (die in einer dll hätte liegen können) dlls haben nicht viele nachteile (nur dass das program *etwas* länger zum starten brauch) aber mehr vorteile (erweiterbarkeit[plugins], updates, mehrfach gebrauch*)

mehrfach gebrauch* zb:
du hast ein client und einen server lieferst beides mit einmal einige funktionen sind beim server und client identisch -> nur eine dll für 2 Programme (du sparst exakt die grösse der dll)