Komfortabler Dateimanager mit vielen Funktionen

MFC

Volle Kraft voraus

By Sven on 16.05.2006 - 11:49 in MFC, Visual Studio 6 with 1 Kommentar

Das gedankliche Hin und Her in den letzten Wochen zwischen dem altbewährten VC6 und dem VS2005 mit der neuen MFC 8.0 ist endlich beendet. Mit einigen kleinen Compileranpassungen kann ich die MFC 8.0 nun auch im VC6 verwenden. So brauche ich die gewohnte Umgebung nicht verlassen und kann zumindestens bis zur nächsten Version von Visual Studio die Vorteile der aktuellen MFC nutzen.

Nun ist der Kopf wieder frei für neue Funktionen im SpeedCommander. Seid gespannt.

Nichts ist unmöglich

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

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.

Unkaputtbar

By Sven on 25.06.2005 - 22:41 in MFC with 3 Kommentare

Seit meinem Umstieg auf Visual C++ vor knapp 10 Jahren programmiere ich mit der MFC (Microsoft Foundation Classes), und im Laufe der Jahre habe ich die MFC als eine verlässliche und robuste Bibliothek kennengelernt. Die MFC deckt alle Grundlagen für eine moderne Windows-Anwendung ab, kleine oder größere Erweiterungen findet man entweder im Netz oder programmiert man sich selbst.

In dem einen oder anderen Gespräch mit C++Entwicklern konnte ich feststellen, dass sich mit dem nahenden Longhorn und der Werbung für die schöne .nette Welt gewisse Ängste entwickeln, dass man in naher Zukunft mit C++ und der MFC nur noch im Regionalexpress fährt und vom .NET-Transrapid bald überholt wird. Ich selbst teile diese Ansicht nicht, denn auch in Longhorn wird .NET ein Aufsatz auf dem Betriebssystem bleiben. Das Windows-API wird natürlich weiter Bestand haben, da einerseits das gesamte Betriebssystem darauf aufbaut und Microsoft sich auch nicht erlauben kann, mit Longhorn einfach alle Brücken zu “alter” Software zu kappen. In diesem Fall müssten sie das gesamte Betriebssystem auf gänzlich neue Füße stellen, und das kann selbst Microsoft sich nicht leisten.

Auch Avalon und seine Beschreibungssprache XAML hat für den normalen Anwendungsprogrammierer keine wirkliche Bedeutung. Oder glaubt tatsächlich jemand, man könnte einen Dateimanager oder ein Packprogramm mit einer XML-Sprache programmieren? Das nun auf später verschobene WinFS wird sicher auch aus nativen Anwendungen ansprechbar sein, ansonsten wäre wohl keine Integration in den Explorer möglich.

Steve Teixeira hat nun einen Ausblick auf die Zeit nach Visual Studio 2005 gegeben, und dieser dürfte den einen oder anderen zweifelnden C++/MFC-Programmierer doch sehr erfreuen:

MFC continues to be the C++ application framework of choice for many developers because the breath and depth of support that MFC provides for the Microsoft platforms remains unmatched by other frameworks. Visual Studio 2005 makes it possible for the C++ developer to leverage existing C++ code, the strengths of MFC, and the advantages of .NET, all within a single application.

Looking beyond Visual Studio 2005, C++ developers should expect deepened integration between MFC and the .NET framework. After the release of Windows Longhorn, Microsoft intends to add MFC support for key Longhorn APIs and features. Microsoft also intends to support the Avalon user interface framework in MFC, providing MFC developers with a bridge to the future of platform user interface design. In essence, as the platform evolves, developers can look forward to seeing MFC updated to leverage the latest managed and native APIs and frameworks.

MFC developers have access to more frameworks than any other type of developer on the platform. As such, MFC developers are free to leverage the best from all worlds as it makes business and technological sense to do so. Microsoft fully expects to support this capability into the foreseeable future.

Also, auf die nächsten 10 Jahre!

Top