Kommentare zu: MFC 8.0 für Visual C++ 6 http://blog.speedproject.de/2006/12/08/mfc-80-fuer-visual-c-6/ Mehr .core als .nett Mon, 06 Feb 2012 09:59:52 +0000 hourly 1 http://wordpress.org/?v=3.1.4 Von: Sven http://blog.speedproject.de/2006/12/08/mfc-80-fuer-visual-c-6/comment-page-1/#comment-11246 Sven Sat, 09 Dec 2006 18:43:03 +0000 http://blog.speedproject.de/2006/12/08/mfc-80-fuer-visual-c-6/#comment-11246 Die Linker-Warnungen beim Kompilieren haben bei mir bisher auch noch keine negativen Seiteneffekte erzeugt. Sofern man seine Programme sowohl mit der MFC 6 als auch mit der MFC 8 verwenden will, muss man wirklich aufpassen. Die MFC 6 ist an einigen Stellen noch auf 32-bit begrenzt (z.B. Dateizugriff in CFile). Auch die Funktionsdeklaration von CWnd::OnNcHitTest hat sich geändert. Die neuen Schlüsselwörter in der ATL sind wirklich problematisch, teilweise hängen Compiler-Funktionen und ATL-Konstrukte auch arg miteinander zusammen. Bei ATL-COM-Servern muss man auch zwingend weiterhin die BEGIN_OBJECT_MAP/END_OBJECT_MAP-Makros verwenden, das automatische Einsammeln der Objekte funktioniert aufgrund des alten Compilers nicht. Bei mir wurden die größten Probleme aber schon mit dem Umstieg auf die MFC 7 abgestellt, so dass ich meine Projekte ohne wesentliche Fehlermeldungen auch auf die MFC 8 umstellen konnte. Die Linker-Warnungen beim Kompilieren haben bei mir bisher auch noch keine negativen Seiteneffekte erzeugt. Sofern man seine Programme sowohl mit der MFC 6 als auch mit der MFC 8 verwenden will, muss man wirklich aufpassen. Die MFC 6 ist an einigen Stellen noch auf 32-bit begrenzt (z.B. Dateizugriff in CFile). Auch die Funktionsdeklaration von CWnd::OnNcHitTest hat sich geändert.

Die neuen Schlüsselwörter in der ATL sind wirklich problematisch, teilweise hängen Compiler-Funktionen und ATL-Konstrukte auch arg miteinander zusammen. Bei ATL-COM-Servern muss man auch zwingend weiterhin die BEGIN_OBJECT_MAP/END_OBJECT_MAP-Makros verwenden, das automatische Einsammeln der Objekte funktioniert aufgrund des alten Compilers nicht.

Bei mir wurden die größten Probleme aber schon mit dem Umstieg auf die MFC 7 abgestellt, so dass ich meine Projekte ohne wesentliche Fehlermeldungen auch auf die MFC 8 umstellen konnte.

]]> Von: Kay http://blog.speedproject.de/2006/12/08/mfc-80-fuer-visual-c-6/comment-page-1/#comment-11244 Kay Sat, 09 Dec 2006 14:37:24 +0000 http://blog.speedproject.de/2006/12/08/mfc-80-fuer-visual-c-6/#comment-11244 Hi Svenni :) Hab das mal bei meinem 135k Zeilen Projekt "Q8Tool" ausprobiert: MFC und ATL konnte ich problemlos kompilieren, es gab jedoch ein paar Warnings ("makemfc.bat 1>makemfc.log 2>makemfc.err"). In makemfc.log findest Du dann u.A.: -LINK : warning LNK4078: multiple ".text" sections found with different attributes (40000040) -mfcdload.lib(advapi.obj) : warning LNK4099: PDB "atldload.pdb" was not found with "E:\VStudio\VC98\LIB\mfcdload.lib" or at "E:\VStudio\VC98\atlmfc\src\MFC\INTEL\atldload.pdb"; linking object as if no debug info Das ist sicherlich nicht tragisch. Bis auf zwei Fehler konnte ich alles durch Umstellen von Datentypen bewerkstelligen: <blockquote>#if _MFC_VER< =0x600 #define FILEPOS DWORD #define FILELEN DWORD #define genericFileException CFileException::generic #else #define FILEPOS ULONGLONG #define FILELEN ULONGLONG #define genericFileException CFileException::genericException #endif</blockquote> Was aber für mich bisher nicht sauber lösbar scheint ist der rege Gebrauch von "__if_exists", "__if_not_exists" und ähnlichem in diversen ATL Include Dateien, das der VC6 Compiler nicht unterstützt. Bei mir funktionieren deshalb die ATL Makros "BEGIN_CONNECTION_POINT_MAP" und "END_CONNECTION_POINT_MAP" nicht. Ich habe "__if_exists" und "__if_not_exists" in den beiden Macros geändert, musste noch mein selbstgestricktes Free_Threaded "IConnectionPointImpl" anpasse, weil in ATL8 CComDynamicUnkArray::GetUnknown und CComDynamicUnkArray::GetCookie keine statischen Methoden mehr sind. Der Compiler läuft jetzt mit Q8Tool sauber durch. :mrgreen: Falls noch Seltsames auftritt, melde ich das hier ;) Hi Svenni :)

Hab das mal bei meinem 135k Zeilen Projekt “Q8Tool” ausprobiert:

MFC und ATL konnte ich problemlos kompilieren, es gab jedoch ein paar Warnings (“makemfc.bat 1>makemfc.log 2>makemfc.err”).
In makemfc.log findest Du dann u.A.:
-LINK : warning LNK4078: multiple “.text” sections found with different attributes (40000040)
-mfcdload.lib(advapi.obj) : warning LNK4099: PDB “atldload.pdb” was not found with “E:\VStudio\VC98\LIB\mfcdload.lib” or at “E:\VStudio\VC98\atlmfc\src\MFC\INTEL\atldload.pdb”; linking object as if no debug info

Das ist sicherlich nicht tragisch.

Bis auf zwei Fehler konnte ich alles durch Umstellen von Datentypen bewerkstelligen:
#if _MFC_VER< =0×600
#define FILEPOS DWORD
#define FILELEN DWORD
#define genericFileException CFileException::generic
#else
#define FILEPOS ULONGLONG
#define FILELEN ULONGLONG
#define genericFileException CFileException::genericException
#endif
Was aber für mich bisher nicht sauber lösbar scheint ist der rege Gebrauch von “__if_exists”, “__if_not_exists” und ähnlichem in diversen ATL Include Dateien, das der VC6 Compiler nicht unterstützt.
Bei mir funktionieren deshalb die ATL Makros “BEGIN_CONNECTION_POINT_MAP” und “END_CONNECTION_POINT_MAP” nicht.

Ich habe “__if_exists” und “__if_not_exists” in den beiden Macros geändert, musste noch mein selbstgestricktes Free_Threaded “IConnectionPointImpl” anpasse, weil in ATL8 CComDynamicUnkArray::GetUnknown und CComDynamicUnkArray::GetCookie keine statischen Methoden mehr sind.

Der Compiler läuft jetzt mit Q8Tool sauber durch. :mrgreen:
Falls noch Seltsames auftritt, melde ich das hier ;)

]]>