Executables in Visual C++ und MinGW

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)