MS VC++ 6 und Nachfolger
-
Wie hoch ist der Anteil: Wer verwendet noch den guten alten VC++ 6 ?
-
Hier, ich.
-
NES-Spieler schrieb:
Hier, ich.
NES-Spieler! Schämst du dich nicht dafür? Für Hobby-Entwickler gibt es doch kostenlos eine neuere Version!
-
Dann sag mir mal, wie ich mit der Express-Edition MFC programmieren soll!
-
MFC sollte man am besten gar nicht mehr nutzen.
wxWidgets rockt die Bude!
-
Man erhält m.E., z.B. auf www.codeproject.com, immer noch deutlich mehr Sourcecode (sofort einsetzbare Klassen, gerade für spezielle Controls) für die MFC als für wxWidgets. Nenne bitte eine Homepage für wxWidgets analog zu www.codeproject.com
-
Nun, da könnten böse Zungen nun ja behaupten, dass bei wxWidgets diese ganzen Controls schon enthalten sind.
-
Da die meisten Controls/Klassen bei CodeProject nicht dauerhaft gepflegt werden kannste die sowieso nicht einsetzen sondern nur Ideen daraus nehmen und selbst coden.
-
Da die meisten Controls/Klassen bei CodeProject nicht dauerhaft gepflegt werden kannste die sowieso nicht einsetzen sondern nur Ideen daraus nehmen und selbst coden.
Das ist richtig, man muss meistens nachbessern, um die eigenen Ziele zu erreichen, aber wohl besser als bei NULL anzufangen.
-
Ich mag die MFC, gibts denn für Widgets auch diese ganzen Automatisierungen (Nachrichtenfunktionen erzeugen usw.)?
-
Wenn man hier im Forum die Beitragsdichte in der Sektion "MFC" mit der in der Sektion "andere GUI ..." vergleicht, dann erkennt man immer noch die Überlegenheit der MFC. Borland ist auch dick dabei.
Natürlich kann eine so alte Klassensammlung wie die MFC nicht den neuesten Stand bezüglich C++/OOP umsetzen. Die Basis war und ist C/WinAPI. Will man aber etwas Spezielles machen, so benötigt man meist eine WinAPI-Funktion. Mit dieser C/C++/WinAPI/MFC-Mischung kann man in der Praxis eine ganze Menge machen. Im Einzelfall können andere Oberflächen selbstverständlich praktikabler sein, vor allem, wenn das Programm plattformübergreifend arbeiten soll, aber das sind nur wenige.
-
Noch ein Satz an Archi: Wie ich auf http://www.codeproject.com/cpp/vcredists_x86.asp mitbekommen habe, laufen mit Visual C++ 2005 erstellte Anwendungen nicht so ohne weiteres auf Computern, die das nicht installiert haben. Dafür braucht man dann erst diese DLL-Dateien und einen meiner Meinung nach nicht unerheblichen Aufwand, um da irgendwelches Zeug zu installieren. (Ich hab mir das nicht genau durchgelesen, aber offensichtlich reicht es nicht nur, ein paar DLL-Dateien in einen Ordner zu kopieren.) Aber bei Visual C++ 6.0 ist das alles nicht nötig. Wenn ich damit MFC-Anwendungen programmiere, laufen die auf allen Betreibssystemen ab Windows 98 (Erste Ausgabe). Und sollte wirklich noch einer Windows 95 benutzen, ist das auch kein Problem: Zwei DLL-Dateien (MFC42.DLL und MSVCRT.DLL) in den Ordner, wo die Anwendung liegt oder wahlweise in den Windows32-Ordner, und fertig. Der Benutzer kann das Programm sofort starten, ohne irgendwas anderes ausführen zu müssen, und wenn er es nicht mehr will, löscht er es ganz einfach.
-
NES-Spieler schrieb:
Wie ich auf http://www.codeproject.com/cpp/vcredists_x86.asp mitbekommen habe, laufen mit Visual C++ 2005 erstellte Anwendungen nicht so ohne weiteres auf Computern, die das nicht installiert haben.
Das war bisher auch so. Da hat sich mit VC8 nichts geändert!
NES-Spieler schrieb:
um da irgendwelches Zeug zu installieren.
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! Da ist mit VC8 nichts neues passiert; nur das manifest ist dazugekommen...
Du kannst natürlich immer noch statisch linken, dann umgehst Du das mitgeben der DLLs (und der manifests).NES-Spieler schrieb:
(Ich hab mir das nicht genau durchgelesen, aber offensichtlich reicht es nicht nur, ein paar DLL-Dateien in einen Ordner zu kopieren.)
Doch es reicht. Du musst jetzt nur noch eine Datei mehr kopieren (nämlich das Manifest).
NES-Spieler schrieb:
Und sollte wirklich noch einer Windows 95 benutzen, ist das auch kein Problem: Zwei DLL-Dateien (MFC42.DLL und MSVCRT.DLL) in den Ordner, wo die Anwendung liegt oder wahlweise in den Windows32-Ordner, und fertig. Der Benutzer kann das Programm sofort starten, ohne irgendwas anderes ausführen zu müssen, und wenn er es nicht mehr will, löscht er es ganz einfach.
Sofort starten heisst für mich aber ohne was zu kopieren. Und das geht mit VC6 auch nicht, wenn Du DLLs verwendest.
-
Ich MUSS diesen alten Compiler benutzen... mein Prof will es so
Habt Ihr das auch, dass nach dem 20. oder 30. STRG+F5 irgendwann der ganze Compiler zusammenbricht und man ihn neustarten muss? Da steht dann für 5 Sek "project_xy saved..." und dann kommen 2 Exceptions...
-
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?