Executables in Visual C++ und MinGW

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)