Komfortabler Dateimanager mit vielen Funktionen

Visual Studio

Windows Vista SDK im VC 6 einbinden

By Sven on 08.03.2007 - 11:29 in Visual Studio 6 with 4 Kommentare

Das letzte Platform SDK, welches noch anstandslos mit dem VC 6 funktioniert, ist das für Windows Server 2003 vom Februar 2003. Alle nachfolgenden SDKs bringen LIB-Dateien in einem neueren Format mit (VS 2003), welche der Linker vom VC 6 nicht mehr verwenden kann.

Will man also weiter mit dem VC 6 arbeiten und trotzdem nicht auf die neuen Definitionen für Vista verzichten, so muss man diese aus den Include-Dateien des Vista-SDKs zusammenklauben und in eigene Headerdateien stecken. Auf Dauer ist dies aber recht mühsam, da es teilweise mehrstufige Abhängigkeiten gibt. Daher habe ich nach einer Möglichkeit gesucht, dieses Gefrickel zu umgehen.

Die Lösung ist denkbar einfach: Man verwendet die Headerdateien vom Vista-SDK und die LIB-Dateien vom W2k3-SDK. Die alten LIB-Dateien sind kein großer Nachteil, da neuere Funktionen, die nur ab Vista verfügbar sind, sowieso dynamisch eingebunden werden sollten. Ansonsten versagt die Anwendung auf älteren Systemen ihren Dienst.

Hier nun die Schritt-für-Schritt-Anleitung:

  1. Das include-Verzeichnis im alten PSDK auf “include.old” umbenennen.
  2. Das include-Verzeichnis vom Vista-SDK in das alte PSDK kopieren
  3. Die strsafe.h im neuen include-Verzeichnis durch die aus “include.old” ersetzen.
  4. Alle .idl-Dateien im neuen include-Verzeichnis löschen und durch die aus “include.old” ersetzen.

Beim ersten Kompilieren werden bei höchster Warnstufe (W4) noch vier Warnungen in der WinGDI.h und WinNT.h ausgegeben. Die in der WinGDI.h werden durch ein dem VC 6 unbekanntes pragma ausgelöst, eine Auskommentierung der beiden Zeilen hilft. In der WinNT.h werden zwei Funktionen ohne Rückgabewert angemeckert, Abhilfe schafft hier eine temporäre Deaktivierung der Meldung 4035 für die beiden Funktionen.

Das Ersetzen der .idl-Dateien ist nötig, da der alte MIDL-Compiler das neue Schlüsselwort “annotation” nicht versteht und das Kompilieren an dieser Stelle abbricht. Die neue strsafe.h benutzt teilweise neue Funktionskennungen und ist daher mit der alten strsafe.lib nicht mehr kompatibel.

Neue CLSID- bzw. IID-Wert für Vista findet der Linker in der Regel in den LIB-Dateien, diese stehen uns hier aber nicht zur Verfügung. Daher muss man sich diese selbst definieren. Der Aufwand ist aber recht gering, wie das folgende Beispiel zeigt:

#define MFX_DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \
        EXTERN_C const GUID DECLSPEC_SELECTANY name = { l, w1, w2, { b1, b2,  b3,  b4,  b5,  b6,  b7,  b8 } }
		
MFX_DEFINE_GUID(CLSID_FileOpenDialog, 0xDC1C5A9C, 0xE88A, 0x4dde, 0xA5, 0xA1, 0x60, 0xF8, 0x2A, 0x20, 0xAE, 0xF7);
MFX_DEFINE_GUID(CLSID_FileSaveDialog, 0xC0B4E2F3, 0xBA21, 0x4773, 0x8D, 0xBA, 0x33, 0x5E, 0xC9, 0x46, 0xEB, 0x8B);

MFC 8.0 für Visual C++ 6

By Sven on 08.12.2006 - 18:49 in Visual Studio 6 with 2 Kommentare

Damit auch andere VC6-Entwickler in den Genuss der MFC 8.0 kommen können, habe ich mit Hilfe des Patch Makers vom Clickteam die Änderungen zusammengefasst und als Download zur Verfügung gestellt. Voraussetzung für die Installation des Patches ist eine Kopie des Original-atlmfc-Verzeichnisses von Visual Studio 2005 und das Platform SDK vom Februar 2003. Neuere Versionen des Platform SDKs funktionieren nicht, da der VC6 mit den Lib-Dateien nichts mehr anfangen kann.

Alle Änderungen sind mit Ausnahme der Ersetzungen von throw(…) und __interface mit dem Kürzel SR: dokumentiert und insgesamt auch noch einmal in der Datei changelog.txt aufgelistet.

Exemplarische Vorgehensweise:
  1. Originales atlmfc-Verzeichnis aus VS2005 nach [VS6]\VC98 kopieren
  2. Patch ausführen und [VS6]\VC98\atlmfc als Produktverzeichnis auswählen
  3. Pfadangaben in [VS6]\VC98\atlmfc\src\vcvars32.bat anpassen (VSCommonDir, MSDevDir, MSVCDir, PSDK)
  4. Modulnamen MyMfc80 für die eigene MFC in [VS6]\VC98\atlmfc\src\makemfx.bat, [VS6]\VC98\atlmfc\include\afx.h und [VS6]\VC98\atlmfc\src\nolib.cpp anpassen
  5. Eingabeaufforderung öffnen und nach [VS6]\VC98\atlmfc\src wechseln
  6. Umgebungsvariablen initialisieren (vcvars32.bat)
  7. Statische ATL erstellen (makeatl.bat)
  8. MFC erstellen (makemfc.bat)
  9. Lib-Dateien aus [VS6]\VC98\atlmfc\lib\Intel nach [VS6]\VC98\atlmfc\lib kopieren
  10. Pfadangaben zur MFC im Developer Studio anpassen
Hinweise
  1. Die ATL steht nur als statische Bibliothek zur Verfügung, die ATL-Server-Klassen sowie alle Headerdateien in [VS6]\VC98\atlmfc\include\! können nicht verwendet werden.
  2. Die WinForms-Erweiterungen können natürlich auch nicht verwendet werden.
  3. Die Klassen für den Zugriff auf Datenbanken (OLEDB und DAO) wurden von mir nicht getestet.
  4. Die Benutzung geschieht auf eigene Gefahr, ich übernehme keine Verantwortung für eventuelle Probleme.
  5. Die Verwendung der MFC 8.0 für Visual C++ 6 ist lizenzrechtlich nur Entwicklern gestattet, die auch die entsprechende Lizenz für Visual Studio 2005 erworben haben.

Produktivitätsstudie für Visual Studio 2005

By Sven on 23.05.2006 - 12:24 in Visual Studio 2005 with 4 Kommentare

Microsoft hat Veritest beauftragt, einen Produktivitätsvergleich zwischen ASP.NET und ASP.NET 2.0 zu erstellen. Zwei Entwicklerteams (ASP.NET und ASP.NET 2.0) wurde eine Projektaufgabe gestellt, die vorgegebene Zeit betrug fünf Tage. Der Auftrag war so formuliert, dass es schwer bzw. unmöglich war, ihn in dieser Zeit zu erfüllen.

Das Ergebnis der Studie zeigt, dass mit ASP.NET 2.0 deutliche Produktivitätssteigerungen möglich sind, die vor allem auch auf die neue Entwicklungsumgebung zurückzuführen sind. ASP.NET 2.0-Entwickler erledigen in der gleichen Zeit etwa 113% mehr Aufgaben als ASP.NET-Entwickler. Bei einigen Teilen der Aufgabe wurden einzelne Webseiten sogar bis zu 357% schneller erstellt.

Ob eine Studie für C++-Programmierer zwischen Visual Studio 6 und 2005 auch so ausgehen würde? 😉

Kein Fehler aufgetreten

By Sven on 19.05.2006 - 12:46 in MFC with Keine Kommentare

Henrik hat festgestellt, dass SpeedEdit beim Öffnen einer leeren Datei mit der Erweiterung .url die Meldung “Kein Fehler aufgetreten.” ausgibt. Beim Debuggen habe ich dann auch recht schnell den Grund dafür gefunden.

In der Funktion OpenDocumentFile des CDocManager-Objektes wird die Funktion AfxResolveShortcut aufgerufen, mit deren Hilfe Verknüpfungen aufgelöst werden sollen. AfxResolveShortcut verwendet dafür die Schnittstelle IShellLink und gibt im Erfolgsfall den aufgelösten Pfadnamen zurück. Bei einer leeren .url-Datei vermeldet IShellLink::Resolve zwar Erfolg, IShellLink::GetPath gibt aber einen leeren String zurück. AfxResolveShortcut meldet den Erfolg weiter und die MFC verwendet nun statt des Dateinamens für die .url-Datei den leeren String, um die Datei zu öffnen.

Abhilfe schafft die zusätzliche Prüfung auf einen leeren aufgelösten Pfadnamen in der Datei docmgr.cpp (Zeile 928):

if (AfxResolveShortcut(AfxGetMainWnd(), szPath, szLinkName, _MAX_PATH) && szLinkName[0])
{
    Checked::tcscpy_s(szPath, _countof(szPath), szLinkName);
}

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.

Eine Woche mit Visual Studio 2005

By Sven on 11.05.2006 - 12:20 in Visual Studio 2005 with 8 Kommentare

Letzte Woche habe ich mich dazu gezwungen, alle Aufgaben mit Visual Studio 2005 durchzuführen. Nach vielen Jahren Entwicklung mit dem inzwischen acht Jahre alten Visual Studio 6 hat man sich aber an gewisse Dinge gewöhnt, die man ohne Zwang nicht so einfach aufgeben will. Dementsprechend hat es das VS2005 bei mir auch recht schwer, obwohl man meinen könnte, dass das sieben Jahre jüngere Produkt den alten Hasen ausstechen müsste.

1. Langsamer Editor

Ich benutze einige Makros, die mir vordefinierte Textblöcke auf Tastendruck an der aktuellen Stelle im Quelltext einfügen. Im VS2005 dauert das immer zwischen einer und zwei Sekunden, man kann dem Editor quasi dabei zusehen, wie er die aktuelle Zeile nach unten verschiebt und den Textblock einfügt. Der VC6 macht das so schnell, dass man die Zeit überhaupt nicht messen kann.

2. Projektmappen-Explorer

Die Baumansicht im Projektmappen-Explorer wird komplett neu gezeichnet, wenn man ein Projekt oder einen Ordner zum ersten Mal nach dem Start aufklappt. Klappt man ihn zu und wieder auf, dann geschieht das für diesen einen Eintrag in Zukunft ohne Flackern. Nach dem Schließen des letzten Fensters wird die Baumansicht ebenfalls sichtbar aktualisiert, obwohl hier eigentlich kein Grund dafür existiert. Das Flackern erzeugt bei mir eine ziemlich unruhige Stimmung. Leider wird auch der Status aller aufgeklappten Zweige gespeichert und beim nächsten Start wiederhergestellt. Im Gegensatz zum VC6 muss man daher alle aufgeklappten Einträge auch selbst wieder zuklappen, um bei umfangreichen Projekten nicht die Übersicht zu verlieren.

3. Geringfügig größere Fontdarstellung

Als Schriftart im Editor verwende ich schon seit vielen Jahren Courier New in Größe 10. Das Auge hat sich daran gewöhnt und möchte nichts anderes sehen. Natürlich lässt sich die gleiche Schriftart auch im VS2005 einstellen, allerdings scheint Microsoft hier andere Maße zu verwenden. Die wohlgemerkt gleiche Schriftart mit gleicher Größe (10) wird im VS2005 etwas größer dargestellt, so dass natürlich auch weniger Zeilen zu sehen sind. Ich habe es versuchsweise mal mit einer 9er-Schrift probiert, diese ist mir aber für die tägliche Arbeit zu klein.

4. Dialogeditor

Die Arbeit mit dem Dialogeditor ist extrem gewöhnungsbedürftig. Alle Angaben zu einem Dialogfeld werden nun im Eigenschaften-Fenster vorgenommen. Im VC6 erscheint auf Doppelklick oder <Enter> ein kleines Fenster, die verschiedenen Optionen sind auf mehreren Registerkarten gruppiert. Auf Wunsch kann das Fenster auch über einen Pin gesteuert ständig sichtbar bleiben. Genau dieses seit Jahren gewohnte Verhalten zum Ändern eines Textes wird einem im VS2005 zum Verhängnis. Ein <Enter> auf ein Dialogelement löscht einfach den Text des Elementes, und das auch noch ohne jedwede Undo-Möglichkeit. Man muss also den Text erneut eingeben (sofern man ihn noch weiß) oder VS2005 ohne Speichern der Dialogvorlage beenden und neu starten. Ich hatte das Problem natürlich auch im Betatest an Microsoft weitergeleitet, das ganze ist “Resolved as by Design”:

Thanks for reporting the issue. However, setting the cursor for the Caption property isn’t a guaranteed operation. Hence the decision is to do in-place editing of captioning. The behavior you see is an artifact of that.

Übrigens war dieses Problem auch schon im VS.NET 2003 enthalten. Für mich ist das immer noch ein klarer Showstopper.

Bei eigenen vordefinierten längeren Initialisierungstexten für Kombinationsfelder verliert man nun recht schnell den Überblick. Im VC6 sind diese Texte noch in einem mehrzeiligen Editierfeld bearbeitbar, in VS2005 hat man nur noch ein einzeiliges Editierfeld.

5. Stringtable-Editor

Öffnet man eine Stringtabelle zum Bearbeiten, dann werden die Einträge nicht automatisch nach aufsteigender ID sortiert, sondern in der Reihenfolge, wie sie in der jeweiligen .rc-Datei enthalten sind. Wenn man also auf eine sortierte Darstellung wie im VC6 Wert legt, dann bleibt einem nichts anderes übrig, als jedesmal zuerst auf die entsprechende Spalte zu klicken. Auch dies ist “Resolved as by Design”:

We encourage you to click on the column header to sort the way you want since there is no automatic sorting as you add or change items. Thanks for your report.

Mittlerweile hat Microsoft aber wohl ein Einsehen gehabt und einen Fix eingecheckt. Ich warte gespannt auf das SP1.

6. Eigenschaften-Fenster für Botschaften und Befehle

Das Eigenschaften-Fenster zum Hinzufügen von Handlern für Botschaften und Ereignisse ist kein Alternative zum gewohnten Class Wizard. Da sich der Inhalt des Eigenschaften-Fensters an die aktuelle Cursorposition anpasst, ist es nicht ganz einfach, einen Punkt zu finden, der einem das Bearbeiten ermöglicht. Nach meinen Erfahrungen muss man sich in der Headerdatei innerhalb der Klassendefinition befinden, allerdings nicht in einer Zeile mit einer Funktion. Im VC6 ist ein Tastendruck in der jeweiligen Quelltextdatei sehr viel fixer.

7. Zugriff auf die geöffneten Fenster

Die geöffneten Fenster werden im VS2005 als Registerkarten in einer Reihe angezeigt. Wenn man dann einmal ein paar mehr Fenster geöffnet hat, dann rutschen die zuerst geöffneten Fenster nach rechts heraus und sind nur noch über ein Menü erreichbar. Im VC6 verwende ich schon seit vielen Jahren WndTabs, welches die geöffneten Dateien auf Wunsch logisch gruppiert und auch ständig sichtbar hält. Leider gibt es keine Version für VS2005. Letztlich würde das wohl auch durch die geänderten Objektmodelle auf eine komplette Neuentwicklung hinauslaufen, und dazu fehlt Oz Solomon leider die Zeit.

8. Visual Assist

Der letzte Punkt ist eher Visual Assist zuzurechnen. Im VC6 verwende ich noch Visual Assist 6, in dem es die von mir heißgeliebte Funktion “Display best guesses in inverse tooltips” gibt. Visual Assist analysiert dabei das Tippverhalten und schlägt zuletzt häufig benutzte passende Eingaben vor. Das inverse InfoTip verschwindet nach einer einstellbaren Zeitspanne von selbst, alternativ lässt sich mit <Tab> der angezeigte Text übernehmen. Die Trefferrate ist dabei äußerst beeindruckend. In der aktuellen Version von Visual Assist X für VS2005 werden statt einem Vorschlag gleich mehrere passende in einem Auswahlfeld angezeigt. Für mich ist das aber eher ein Rückschritt, da das Auge nun auf einen größeren Bereich zu achten hat.

Leider muss ich das Fazit ziehen, dass der VC6 für mich auch weiterhin die erste Wahl bleibt. Von den Funktionen her ist VS2005 ohne Zweifel sehr viel mächtiger, allerdings sind viele Kleinigkeiten, die für meine tägliche Arbeit wichtig sind, im VC6 viel besser gelöst. Für mich ist der VC6 einfach das ausgereiftere Produkt. Ich frage mich aber auch, ob ich der einzige bin, dem die oben erwähnten Sachen auffallen und stören.

Schlechtes Ptr

By Sven on 08.05.2006 - 15:01 in Visual Studio 2005 with 2 Kommentare

Aufgefallen beim Debuggen mit Visual Studio 2005. Ungültiger Ptr wäre sicher passender, in der englischen Version heißt es Bad Ptr.

Schlechtes Ptr

Aktualisierte MSDN Library für Visual Studio 2005

By Sven on 05.05.2006 - 11:59 in Visual Studio 2005 with Keine Kommentare

MSDN-Abonnenten können sich ab sofort eine aktualisierte deutsche MSDN Library für Visual Studio 2005 herunterladen. Neuerungen zur ersten Ausgabe liegen vor allem in der Dokumentation zu:

  • Visual Studio 2005 Team Foundation Server
  • SQL Server 2005
  • Internet Information Server SDK
  • Internet Security and Acceleration Server SDK

Bei der Installation wird die vorhandene deutsche Installation erkannt und die Aktualisierung angeboten, allerdings verlangt das Installationsprogramm nach einer “Visual Studio 2005 DVD”. Meine vorhandene MSDN-DVD, von der auch die Installation erfolgte, hat es nicht akzeptiert. Eine Deinstallation der alten MSDN Library und eine anschließende Neuinstallation brachte aber den gewünschten Erfolg.

Kleines Dankeschön

By Sven on 21.12.2005 - 11:14 in Visual Studio 2005 with 7 Kommentare

Da freut man sich doch:

AwardThank you for being a great contributor to Microsoft Visual Studio 2005.

You have been nominated to receive the Award for Customer Excellence. This award recognizes your extraordinary contribution to the Visual Studio 2005 product and will be shipped to you without charge.

Trotzdem werde ich dem VC6 weiterhin treu bleiben und VS2005 nur für die 64bit-Entwicklung und für das verzeichnisübergreifende Suchen und Ersetzen von Text verwenden. 🙂

Top