wo laufen Programme die mit dem Visual Studio 6 erstellt wurden?

Ich hatte die Aufgabe ein Programm zu schreiben das bestimmte Werte von einem Computer ausliesst. Es ist ein Supportprogramm das losgeschickt wird wenn unsere Hauptapplikation auf einem Kundenrechner nicht läuft. Die Funktionen die nur bei WindowsXP oder Win2000 zur Verfügung stehen (zB WMI) habe ich in eine DLL ausgelagert die dann geladen wird wenn das passende Betriebsystem vorliegt. Ähnliches für WinNT. Wenn nur ein blankes Win95 erkannt wird soll mein Programm eine Meldung ausgeben. (Aber nicht abstürzen oder sagen "Funktion xyz in kernel32.dll nicht gefunden") Außerdem soll mein Programm monolitisch sein. Es soll nur eine einzige .exe Datei sein, ohne Setup, etc. Meine DLLs sind also als Ressource einkompiliert und werden nur kurzzeitig in das TempVerzeichnis extrahiert und von dort mit LoadLibrary geladen.

Jetzt stapfe ich auf der suche nach Testrechnern durch die Firma. Gleich auf dem ersten WinXP Rechner wird die MFCO42D.DLL und die MSVCP60D.DLL verlangt. Vermutung: Es liegt daran das mein Programm mit der Debug Konfiguration kompiliert wurde. (Ich kann mein Programm aus irgendwelchen momentan nicht in der Release Konfiguration kompilieren.) Kann ich davon ausgehen das ansonsten mein Programm auf einem nackten Win95 Rechner laufen würde? Wenn nein wie schaffe ich das? Muß ich irgendein altes Visual Studio installieren? Für mein Tool darf es kein Setup geben. Die MFC Dateien darf ich nicht mitgeben.

wo laufen Programme die mit dem Visual Studio 6 erstellt wurden?

Auf dem Rechner?
Nein, mal im ernst: Überall da, wo die Vorraussetzungen dafür vorhanden sind. Also, wenn Du gegen die DLL-Version der CRT/MFC gelinkt hast: Überall da wo die msvcrt/mfc42.dll vorhanden oder installiert wurde.
Persönlich würde ich statisch linken, da hast Du das Problem mit den DLLs nicht.

Jakata schrieb:

Ich hatte die Aufgabe ein Programm zu schreiben das bestimmte Werte von einem Computer ausliesst. Es ist ein Supportprogramm das losgeschickt wird wenn unsere Hauptapplikation auf einem Kundenrechner nicht läuft.

Dann empfehle ich auf jeden Fall statisch zu linken um alles unnötige aus dem Weg zuräumen!

Jakata schrieb:

Die Funktionen die nur bei WindowsXP oder Win2000 zur Verfügung stehen (zB WMI) habe ich in eine DLL ausgelagert die dann geladen wird wenn das passende Betriebsystem vorliegt.

Wie gesagt: Linke statisch gegen die CRT/MFC!!!
Auch würde ich solche Funktionen die es bei bestimmten OS-versionen nicht gibt nicht in eine DLL auslagern (diese DLL musst Du ja dann auch mitliefern), sondern diese Funktioenn einfach via LoadLibrary/GetProcAddress "einbinden"!

Jakata schrieb:

Außerdem soll mein Programm monolitisch sein. Es soll nur eine einzige .exe Datei sein, ohne Setup, etc.

Dann mach dass, was ich gerade beschrieben habe!

Jakata schrieb:

Meine DLLs sind also als Ressource einkompiliert und werden nur kurzzeitig in das TempVerzeichnis extrahiert und von dort mit LoadLibrary geladen.

Lass die DLLs weg! Warum so kompliziert? Wenn Du eh LoadLibrary verwendest kannst Du es doch gleich ohne DLL machen!

Jakata schrieb:

Jetzt stapfe ich auf der suche nach Testrechnern durch die Firma. Gleich auf dem ersten WinXP Rechner wird die MFCO42D.DLL und die MSVCP60D.DLL verlangt.

Debug-Versionen der DLLs darfst Du gar nicht ausliefern! Das verstösst gegen die EULA...

Jakata schrieb:

Vermutung: Es liegt daran das mein Programm mit der Debug Konfiguration kompiliert wurde.

Wie gesagt: Ist nicht erlaubt.

Jakata schrieb:

(Ich kann mein Programm aus irgendwelchen momentan nicht in der Release Konfiguration kompilieren.)

Dann hast Du aber noch größere Hunde begraben die Du zuerst mal finden solltest... und lass die DLLs weg...

Jakata schrieb:

Kann ich davon ausgehen das ansonsten mein Programm auf einem nackten Win95 Rechner laufen würde?

Wenn Du gegen die DLL-Version der CRT linkst: Natürlich nicht! Wie kann ein Win95 DLLs kennen die erst 98 (VC6) rausgekomen sind!?

was soll ich statisch linken? Der VS Kompiler linkt doch bereits statisch gegen die MFC DLLs. Ich habe im VS6 einfach ein MFCAppWizard Exe erstellt. Das sollte doch statisch sein?

Wenn Du auf meine selbst erstellten DLLs anspielst: So brauche ich nur in meiner eigenen DLL die Funktionen CreateWMIReport und GetWMIReport zu suchen und auszuführen. Die ganzen WMI Funktionen mit Funktionszeigern nachzubauen würde wohl sehr lange dauern. So linke ich statisch gegen die MS Funktionen und brauche nur meine beiden Simpel-Funktionen nachzubilden und auzuführen. Was spricht gegen das dynamische Laden selbst erstellter DLLs?

Es gab doch aber einen Vorgänger von Visual Studio 6? Mit denen hat man Programme mit WinNT bzw Win95 erstellt? In dieser FAQ: http://www.mpdvc.de/html.htm#Q80
wird erwähnt das man für Dos Programme Visual C++ V1.52c benutzen sollte. Laut dem MFC Wiki Artikel gibt es die MFC seit 1992. Es wäre also denkbar das bei Win95 eine ältere MFC DLL beiliegt?

Ansonsten muß ich mir überlegen meine GUI in normaler WinApi nachzubauen...

was soll ich statisch linken? Der VS Kompiler linkt doch bereits statisch gegen die MFC DLLs.

DLL != statisch!
Stelle es in den Projekteinstellungen um: Project|Settings|C/C++|Code generation|Use runtime library: (hier irgendwas *ohne* DLL auswählen)[/quote]

Jakata schrieb:

Wenn Du auf meine selbst erstellten DLLs anspielst: So brauche ich nur in meiner eigenen DLL die Funktionen CreateWMIReport und GetWMIReport zu suchen und auszuführen. Die ganzen WMI Funktionen mit Funktionszeigern nachzubauen würde wohl sehr lange dauern.

WMI ist doch COM... was hat dass mit Funktionen in anderen DLLs zu tun???

Jakata schrieb:

Es gab doch aber einen Vorgänger von Visual Studio 6? Mit denen hat man Programme mit WinNT bzw Win95 erstellt?

Man kann doch auch mit VC6 Programme für Win95/NT erstellen, oder geht es bei Dir nicht?

Jakata schrieb:

Laut dem MFC Wiki Artikel gibt es die MFC seit 1992. Es wäre also denkbar das bei Win95 eine ältere MFC DLL beiliegt?

Tut es aber nicht. Und was nützen Dir ältere DLLs, wenn Du *neuere* brauchst?

Jakata schrieb:

Ansonsten muß ich mir überlegen meine GUI in normaler WinApi nachzubauen...

Wie gesagt: Linke statisch, dann hast Du das Problem nicht!
Auch wird Dir reine WinAPI auch nicht helfen, wenn Du nicht statisch linkst, da Du dann immer noch die CRT-DLLs mitgeben musst!

Ich kann mein Programm aus irgendwelchen momentan nicht in der Release Konfiguration kompilieren

Vergleiche mal von Release und Debug die Projekteigenschaften bzw. welche Libs jeweils eingebunden sind. Vielleicht fehlt im Release was?

Oder du schaltest durch

#ifdef _DEBUG
#endif

Quellen aus, die in deinem Release eigentlich erforderlich sind.

@Jochen: Der Umstieg von "Multithreaded DLL" auf "Multithreaded" und die Änderung "Projekt -> Einstellungen -> Registrierkarte Allgemein -> MFC in einer gemeinsam genutzten DLL verwenden" auf "Benutze statische MFC Bibliothek" bewirken das ich keine externen MFC dll mehr benötige. Richtig? Also ist mein Programm von diesem Gesichtspunkt aus Win95 ready?

Wenn ich diesen Code auf einem nacktem Windows95 ausführe, wo wird es dann "krachen"? Soweit ich im Web gesucht habe ist Com auch für Win95 vorhanden. CoCreateInstance würde dann die CLSID von WMI nicht finden und etwas anderes als 0 zurückgeben? (Ich kann es nicht testen, weil wir in der Firma nur WinXP haben.) Wenn es so ist muß ich den Code nicht in eine extra DLL auslagern.

hres = CoInitializeEx(0, COINIT_MULTITHREADED);
if (hres>=0) {
	hres = CoInitializeSecurity(0, -1, 0, 0, RPC_C_AUTHN_LEVEL_DEFAULT,RPC_C_IMP_LEVEL_IMPERSONATE, 0, EOAC_NONE, 0);
	IWbemLocator *pLoc=0;
	hres = CoCreateInstance(CLSID_WbemLocator,  0,  CLSCTX_INPROC_SERVER,  IID_IWbemLocator,  reinterpret_cast<void **>(&pLoc));
	...