Komfortabler Dateimanager mit vielen Funktionen

Nichts ist unmöglich

By Sven on 15.05.2006 - 14:48 in MFC, Visual Studio 6

Der wohl größte Nachteil beim VC6 ist die mitgelieferte MFC in der Version 6.0. Der Technikstand der MFC 6.0 ist eigentlich Windows 98, in den späteren Servicepacks kamen keine Neuerungen mehr hinzu. Für eine zeitgemäße Unterstützung aktueller Windows-Versionen ist man daher auf eigene Erweiterungen angewiesen. Alternativ kann man auch versuchen, die aktuelle MFC mit dem VC6 zu kompilieren. Mit der Zeit wird das aber immer schwieriger, da die neueren Versionen natürlich auch gerne die jeweils aktuelle Compilertechnologie verwenden.

Die MFC 7.2 vom Visual Studio.NET 2003 hatte ich schon Ende 2003 adoptiert, letzte Woche ist mir das nun auch mit der MFC 8.0 vom Visual Studio 2005 gelungen. Ein ziemliches KO-Kriterium waren anfangs die umfangreichen Templates der ATL, die den VC6-Compiler ziemlich ins Schwitzen gebracht haben. An den String-Klassen hat er sich dann aber mit einem stetigen

fatal error C1001: INTERNER COMPILER-FEHLER
(Compiler-Datei “msc1.cpp”, Zeile 1794)
Bitte wählen Sie im Menü “?” von Visual C++ den Befehl “Software Service”, oder
öffnen Sie die Hilfedatei für den Software Service, um weitere Informationen zu erhalten.
Fehler beim Ausführen von cl.exe.

vergeblich die Zähne ausgebissen. Als Workaround kam dann wieder meine Lösung von 2003 zum Einsatz. Die ATL-Stringklassen wurden komplett entfernt und durch die CString-Implementation der MFC 6.0 ersetzt. Da die MFC 8.0 nun vermehrt auch CStringA und CStringW einsetzt, habe ich die CString-Klasse einfach verdoppelt und eine Ansi-Fassung (CStringA) sowie eine Unicode-Fassung (CStringW) implementiert. Per typedef wird dann in einer Ansi-Anwendung aus CStringA der normale CString, bei einer Unicode-Anwendung entspricht CString dann CStringW.

Dazu habe ich für CStringA und CStringW noch einmal separat eine ATL-Implementation (CAtlStringA und CAtlStringW) eingebaut, so dass man auch die eine oder andere ATL-Klasse verwenden kann.

Weitere größere Fallstricke sind u.a.

  • einige Definitionen aus der VC8-Laufzeit, die man zusammentragen muss
  • fehlende Laufzeitunterstützung für time64-Funktionen, welche sich aber aus der VC8-CRT ausleihen lassen
  • einige sichere Stringfunktionen der VC8-Laufzeit, welche entweder durch die alten Stringfunktionen oder durch sichere Stringfunktionen der strsafe.h ersetzt werden müssen
  • das Schlüsselwort throw(…), welches in verschiedenen Dateien durch throw() ersetzt werden muss
  • Statische Konstanten in Templates, die entweder in #defines umgewandelt oder als Klassenmember im Konstruktor initialisiert werden müssen
  • declspec(selectany) für einige globale Variablen
  • das Schlüsselwort __interface, welches durch struct ersetzt werden kann
  • die OLEDB-Templates in atldbcli.h, welche durch die atldbcli.h aus der MFC 6.0 zzgl. der Definition für CVBufHelper und CVirtualBuffer aus der atlbase.h (auch MFC 6.0) ersetzt werden können
  • die Implementation in dllmodul.cpp, welche beim Linken von mit _USRDLL kompilierten Dlls zwei fehlende Funktionsimporte bemängelt und durch die Fassung aus der MFC 7.2 ersetzt werden kann

Nachdem dann alles ohne Fehlermeldungen kompiliert wird, müssen nur noch die vier DEF-Dateien für die MFC-Dlls angepasst werden. Das ging diesmal bedeutend schneller als bei der MFC 7.2, da alle Referenzen auf die ATL-Klassen durch Suchen/Ersetzen auf die CStringA/W-Klassen korrigiert werden können. VS2005 behandelt und exportiert wchar_t als eigenen Typ, während der VC6 hier noch mit unsigned short arbeitet. Dementsprechend müssen die Exportbeschreibungen für Unicode-Funktionen, die Variablen mit wchar_t enthalten, auch noch angepasst werden. Aber auch hier geht ein globales Ersetzen von “_W” durch “G” sehr schnell vonstatten. Dazu kommen noch die nötigen Exporte für die CStringA/W-Klassen, die sich mit Hilfe der MAP-Dateien zusammenstellen lassen.

Ich hatte schon überlegt, ob ich hier einen genauen Portierungsablauf dokumentieren sollte, aber das ist ziemlich trocken und wohl für die meisten Leser auch eher uninteressant. Ein komplettes Downloadangebot der geänderten Quelltexte ist vermutlich lizenzrechtlich nicht möglich, alternativ könnte man aber zwischen der originalen VS2005-Version und den angepassten Quelltexten ein Diff erstellen, mit dem sich dann aus der VS2005-Version die angepasste Version erstellen lässt. Tips zu einem einfach zu benutzenden Diff-Tool (möglichst ohne Cygwin-Voraussetzung) sind willkommen.

Es gibt 2 Kommentare zu diesem Beitrag

Trackback URL | RSS-Feed für Kommentare

  1. Justin sagt:

    Zum Thema Diff-Tools: WinMerge und BeyondCompare sind sehr zu empfehlen. WinMerge ist Open-Source, BeyondCompare hingegen Shareware.

    Gruß

  2. Sven sagt:

    Ich habe mich schon für die Freeware-Version von Patch Maker entschieden. Das Programm erstellt eine ausführbare Datei, man muss anschließend nur noch das Zielverzeichnis eingeben.

Top