MS VC++ 6 und Nachfolger
-
Du musst nichts installieren, wenn Du es nicht willst. Aber wie gesagt; das war bisher auch schon immer so. Wenn Du DLLs verwendest, dann musst Du die entweder installieren oder eben Deiner Anwendung mitgeben!
Also, nach allem, was ich da gelesen habe, reicht es wohl nicht aus, einfach nur drei Dateien per Drag&Drop zu kopieren, sondern man ist durchaus gezwungen, richtige Installationen durchzuführen. (Siehe Zitat unten.)
Sofort starten heisst für mich aber ohne was zu kopieren. Und das geht mit VC6 auch nicht, wenn Du DLLs verwendest.
Ja, gut, aber da ist es eben nur ein einfacher Kopiervorgang. Bzw. für Windows 95-Benutzer bereite ich einfach einen Ordner/eine Zip-Datei vor, wo die DLL-Dateien mit drin liegen. Dann kann man das auch gleich starten. Aber zumindest muß man da keinerlei Installationen durchführen.
P.S.: Falls der Schreiber des Artikels sich geirrt hat, können wir ja mal was ausprobieren: Du schickst mir eine simple mit Visual C++ 2005 und MFC geschriebene Anwendung und packst alles mit rein, was man dazu braucht, inklusive einer kurzen Notiz, wo was hingehört. Und dann probiere ich mal aus, ob das in Windows 98 geht, ohne daß man irgendwas installieren muß. (Sprich: Die einzige Datei, die von mir per Doppelklick ausgeführt wird, ist das eigentliche Programm, alles andere wird allerhöchstens irgendwohin kopiert.) Die E-Mail-Adresse, die ich dafür angelegt habe, lautet: MalSehenObDasMitVisualCPP2005Funktionier@web.de (Das fehlende T hinter "funktioniert" muß übrigens so sein. Da habe ich mich schon beim Erstellen der E-Mail-Adresse verschrieben.)
IDE builds
[...]
However, when you try to run on another machine (a machine that does not have Visual C++ installed), you receive this message:
[...]
Now that your app is configured to load the CRTs through a manifest, the CRT DLLs must now be placed in a directory recognized by the side-by-side technology. You can either load the CRT DLLs via a shared side-by-side assembly, or through applocal assemblies.
[...]
Installing the shared CRTs
If you choose to install a shared side-by-side assembly, they will need to be installed with a Windows Installer setup project (copying doesn't work). The setup will create policies, manifests, and some registry keys to the HKLM registry (the manifests and policies are important for the side-by-side engine to recognize the isolated library).
[...]
For older Windows (Win2K and below), there is no such concept as a side-by-side DLL, and the CRT DLLs will need to be installed either in the System32 directory or the same folder as the application. All this means that you have to create a complicated installer that behaves differently on different operating systems (even the service pack level of the OS can alter the behaviour of your installer).
Fortunately, Microsoft has already written a merge module that does all this for you (including registering the side-by-side DLL). Look in the "\Program Files\Common Files\Merge Modules" to find a set of MSM files (ignore the properties that say it's Beta 2. It actually installs the final release). The files that have "CRT" in their names are the ones you need to redistribute (if you use MFC/ATL, you'll also need the other MSMs). By including these files in your setup project, your setup will properly install the runtime DLLs in the correct location.
[...]
If you're not using Windows Installer, you can use the executable located in "\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bootstrapper\Packages\vcredist_x86\vcredist_x86.exe". All you have to do is execute this redistributable in your third party setup.
[...]
For example, if you're trying to run your app on a Win2K computer, you have to download the latest Windows 2000 service pack (SP4), install that, reboot, then download Windows Installer 3.1, install that and reboot. Then finally, you need to copy the vcredist_x86 file and install that. Such a number of steps (which significantly alters the operating system, requires many reboots, and probably breaks the existing apps) are very inconvenient for an end user. If any one of these components is not present, the merge module will fail with a nondescript error at the end user's expense (I got an error 1723 when testing). This complex install process was a design decision made by Microsoft.
-
NES-Spieler schrieb:
Du musst nichts installieren, wenn Du es nicht willst. Aber wie gesagt; das war bisher auch schon immer so. Wenn Du DLLs verwendest, dann musst Du die entweder installieren oder eben Deiner Anwendung mitgeben!
Also, nach allem, was ich da gelesen habe, reicht es wohl nicht aus, einfach nur drei Dateien per Drag&Drop zu kopieren, sondern man ist durchaus gezwungen, richtige Installationen durchzuführen. (Siehe Zitat unten.)
Du brauchst hier nicht den halben Artikel zu quoten... mach es und behaupte nicht falsch Sachen.
Der wichtigste Satz ist ja wohlYou can either load the CRT DLLs via a shared side-by-side assembly, or through applocal assemblies
Der Artikel beziehst sich sonst darauf, wie man einen Installer schreibt. Das ist aber nicht notwendig, wenn Du die DLLs mitlieferst!
-
An Jochen Kalmbach:
Das, was Du mir da geschickt hast, waren ja nur Konsolenanwendungen. Die haben ja unter der 6er Version auch keine Probleme gemacht (obwohl sie da nichtmal DLL-Dateien brauchten). Kannst Du mir nicht eine MFC-Anwendung schicken (eine dialogfeldbasierte Anwendung mit einem OK- und einem Abbrechen-Button)? Ich würde gern mal sehen, ob das ebenfalls funktoniert. Danke.
-
Erhard Henkes schrieb:
Wie hoch ist der Anteil: Wer verwendet noch den guten alten VC++ 6 ?
ich nehme den um c-codes auf'm pc zu testen und zu debuggen (unit tests). der c-compiler ist schnell und zickt nicht rum. vs7/vs8 usw. sind von der bedienung her umständlicher...
-
NES-Spieler schrieb:
An Jochen Kalmbach:
Das, was Du mir da geschickt hast, waren ja nur Konsolenanwendungen. Die haben ja unter der 6er Version auch keine Probleme gemacht (obwohl sie da nichtmal DLL-Dateien brauchten).Mann... Du hast keine Ahnung. Wenn Du gegen die DLL-Version der CRT linkst, musst Du auch die DLLs der CRT mitliefern!
Das die heutzutage auf einem System drauf sind ist sehr wahrscheinlich, da VC6 schon über 8 Jahre alt ist...NES-Spieler schrieb:
Kannst Du mir nicht eine MFC-Anwendung schicken (eine dialogfeldbasierte Anwendung mit einem OK- und einem Abbrechen-Button)? Ich würde gern mal sehen, ob das ebenfalls funktoniert. Danke.
Warum sollte ich? Was für die einen DLLs gilt, gilt auch für die anderen. Es geht. (Punkt)
-
kann es sein, daß die statischen Libaries und die entsprechenden DLL's nicht identisch sind?!?
Ich habe mal ein Projekt mit statischen Libs erzeugt und darin eine ListBox eingebaut, dann habe ich umgestellt auf DLL-linken und noch eine weitere ListBox erstellt - nur das Resultat (also die neue Listbox) war etwas anders als vorher, währen die alte Listbox unverändert war...
man konnte mit der DLL-Version mehr anfangen als mit der statisch gelinkten Version. Ist das normal, oder hab' ich was übersehen?
-
Newbi007 schrieb:
kann es sein, daß die statischen Libaries und die entsprechenden DLL's nicht identisch sind?!?
Sie sind in der Funktion komplett identisch. Unterschiede bestehen im gesamten Konstrukt wenn andere DLLs ins Spiel kommen, die auch die MFC verwenden.
Die CRT ist sowieso gleich, was den Funktionsweise und Umfang betrifft.
-
Mann... Du hast keine Ahnung. Wenn Du gegen die DLL-Version der CRT linkst, musst Du auch die DLLs der CRT mitliefern!
Schön, nur daß Konsolenanwendungen in Visual C++ 6.0 gegen keinerlei CRT-DLLs gelinkt werden. Die einzige DLL-Datei, von der so eine Konsolenanwendung abhängig ist, ist die "kernel32.dll". Ich weiß ja nicht, was für zusätzliches Zeug man da noch benutzen kann, das dann DLL-Dateien erfordert, aber ein Programm, welches zum Beispiel iostream, cstdlib und sogar windows.h inkludiert, braucht keine weiteren DLL-Dateien,α was mit dem Dependency Walker nachgeprüft werden kann.
Das die heutzutage auf einem System drauf sind ist sehr wahrscheinlich, da VC6 schon über 8 Jahre alt ist...
Das liegt nicht nur daran, daß heutzutage alles schon bei den Detriebssystemen dabei ist. Führe eine Standardinstallation von Windows 95 durch und starte ein auf einem anderen Computer mit VCPP6 erstelltes Konsolenprogramm! Wenn es nicht gerade die MFC-Klassen oder derartiges benutzt, kannst Du es ohne Probleme starten.
-
NES-Spieler schrieb:
Schön, nur daß Konsolenanwendungen in Visual C++ 6.0 gegen keinerlei CRT-DLLs gelinkt werden.
Das hat doch mit Konsolenanwendungen nichts zu tun! Das sind Compiler/Linker-Einstellungen!
Mein Beispiel ist gegen die DLL-Version der CRT gelinkt und somit von msvcr80.dll abhängig (zeigt zumindest mein depends.exe an).
-
Gut, speziell mit Konsolenanwendungen hat es nichts zu tun, aber generell mit der Frage, was für ein Projekt man auswählt, schon (bzw. sind Compiler- und Linker-Einstellungen von verschiedenen Projektarten per default jeweils unterschiedlich): Konsolenanwendungen und ich glaube auch einfache WinAPI-Programme können sofort gestartet werden und sind von keinen DLL-Dateien abhängig. MFC-Programme dagegen brauchen die "mfc42.dll" und die "msvcrt.dll". Aber das scheint sich ja mit den neuen Versionen geändert zu haben, so daß die alle von einer CRT-Datei abhängig sind.
-
NES-Spieler schrieb:
MFC-Programme dagegen brauchen die "mfc42.dll" und die "msvcrt.dll". Aber das scheint sich ja mit den neuen Versionen geändert zu haben, so daß die alle von einer CRT-Datei abhängig sind.
du kannst den ganzen schrott statisch linken dann braucht dein programm nur die dlls, die windoze sowieso hat (kernel32, ntdll, usw...)
-
In der Standard-Ausgabe geht das leider noch nicht. Außerdem wäre es unnötig, da, wie gesagt, alle Betriebbsysteme ab Windows 98 (Erste Ausgabe) diese DLL-Dateien haben. Und für den Rest kann ich sie auch einfach mitgeben.
-
NES-Spieler schrieb:
In der Standard-Ausgabe geht das leider noch nicht. Außerdem wäre es unnötig, da, wie gesagt, alle Betriebbsysteme ab Windows 98 (Erste Ausgabe) diese DLL-Dateien haben. Und für den Rest kann ich sie auch einfach mitgeben.
Komisch, dass ich die MFC-Dlls bei 98 SE und XP noch mitgeben muss.
Du meinst doch:
msvcr71.dll
MFC71.dll
msvcp71.dll
Oder?Naja, jedenfalls reichen die, damit eine mit VC2003 erstellte MFC-Anwendung läuft.
-
Ich sprach noch immer von der 6er Version von Visual C++, nicht von 2003.
