Komfortabler Dateimanager mit vielen Funktionen

Archive for November, 2007

VS 2008: C/C++-Laufzeit selbst kompilieren

By Sven on 30.11.2007 - 11:19 in C++/ATL, Visual Studio 2008 with Keine Kommentare

Wer möchte, dass sich seine Anwendungen ohne Installation von einem USB-Stick starten lassen, der hat ab Visual Studio 2005 schlechte Karten. Bis einschließlich Visual Studio .NET 2003 konnte man die benötigten C/C++-Laufzeitbibliotheken sowie die MFC einfach so dazupacken, ab Visual Studio 2005 beharren diese Module nun auf einer separaten Installation in das WinSxS-Verzeichnis. Es gibt zwar auch die Möglichkeit, anwendungslokale Manifeste zu verwenden, aber das ist mir ehrlich gesagt viel zu umständlich. Die beste und vor allem stressfreiste Lösung für einen nativen Entwickler sind immer noch zwei Dlls (oder drei bei Verwendung der STL), die man einfach in das Anwendungsverzeichnis kopiert.

Der Aufwand dafür ist gar nicht so groß. Man muss lediglich die C/C++-Laufzeit sowie die MFC ohne Manifest kompilieren und hat dann alle Möglichkeiten, die man vor Visual Studio 2005 auch hatte. Man muss aber darauf achten, dass man keine Bibliotheken verwendet, die man nur als Binärversionen zur Verfügung hat und die bereits ein Manifest enthalten. Viele Entwickler schrecken aber vor dem Kompilieren zurück, daher möchte ich euch an dieser Stelle eine Schritt-für-Schritt-Anleitung aufzeigen. In diesem Artikel geht es erst einmal um die C/C++-Laufzeit, die MFC nehmen wir uns das nächste Mal vor.

Alle Änderungen spielen sich unterhalb des VC-Verzeichnisses ab, daher sind alle folgenden Pfadangaben relativ zum VC-Verzeichnis (VisualStudioInstallDir\VC).

1. Sicherung

Der erste Schritt ist die Sicherung der originalen Dateien. Bei mir hat es sich bewährt, im VC-Verzeichnis zwei neue Verzeichnisse !orig und !changed anzulegen. In das !orig-Verzeichnis werden zuerst die Verzeichnisse

  • atlmfc
  • crt
  • include
  • lib

kopiert, damit wir uns ungestört an den anderen Dateien vergehen können. So erhalten wir eine originale und eine angepasste Konfiguration, die sich dann schnell durch das Verschieben der vier Ordner austauschen lassen.

2. Anpassen der Dateien

Für eine manifestlose Laufzeit müssen wir erst einmal die Manifestdefinitionen entsorgen. Diese befinden sich in den Dateien crtdefs.h und use_ansi.h. Beide Dateien kommen doppelt vor, einmal in include und einmal in crt\src. In crt\src\crtdefs.h suchen wir die Zeile 118

#include <crtassem.h>

und kommentieren danach bis einschließlich Zeile 173 alles aus. Bitte unbedingt auf die einzelnen #endif-Kommentare achten, die ein einfaches /* */ erschweren. Bei include\crtdefs.h erfolgt das gleiche noch einmal, hier zwischen den Zeilen 93 und 147. Analog erfolgen die Änderungen auch in crt\use_ansi.h (Zeilen 59 bis 113) und include\use_ansi.h (Zeilen 53 bis 107).

3. Vorbereitung der .DEF-Dateien

Die .def-Dateien für die nötigen Exporte sind bereits im crt\src-Verzeichnis vorhanden, allerdings mit etwas kryptischen Namen. Wir benennen die Dateien wie folgt um:

sample_m.def -> msvcmrt.def
sample_p.def -> msvcprt.def
sample_u.def -> msvcurt.def
sampld_m.def -> msvcmrtd.def
sampld_p.def -> msvcprtd.def
sampld_u.def -> msvcurtd.def

In den Verzeichnissen crt\src\intel und crt\src\amd64 befinden sich jeweils zwei weitere Dateien, die auch umbenannt werden müssen:

_sample_.def -> msvcrt.def
_sampld_.def -> msvcrtd.def

Nun müssen wir uns vernünftigen Namen für die Laufzeit-Dlls ausdenken. Ganz wichtig ist, dass wir hier einen eigenen Namen wählen, um Komplikationen mit den originalen (MsVcr90.dll) sowie anderen angepasste Dateien zu vermeiden. Als Beispiel verwenden wir MyVcr90.dll, die Modulnamen in den Definitionsdateien werden nun mit einem Texteditor wie folgt angepasst:

msvcmrt.def: MyVcm90
msvcmrtd.def: MyVcm90d
msvcprt.def: MyVcp90
msvcprtd.def: MyVcp90d
msvcurt.def: MyVcm90
msvcurtd.def: MyVcm90d

Nun noch die vier Dateien aus den intel\amd64-Verzeichnissen:

msvcrt.def: MyVcr90
msvcrtd.def: MyVcr90d

Damit das Kompilieren der MFC später nicht mit einem Fehler beendet wird, ergänzen wir die beiden msvcrtd.def-Dateien noch um diese vier Zeilen:

_strdup_dbg
_fullpath_dbg
_wcsdup_dbg
_wfullpath_dbg

MyVcr90.dll steht hier aber wirklich nur als Platzhalter, ihr solltet das nach dem ersten funktionierenden Testlauf durch euren Wunschnamen ersetzen.

4. Vorbereitung der Ressourcendateien

Nun müssen noch die Ressourcendateien in crt\src umbenannt

_sample_.rc -> MyVcr90.rc
sample_m.rc -> MyVcm90.rc
sample_p.rc -> MyVcp90.rc

und die Versionsinfos in diesen drei Dateien angepasst werden.

5. Anpassung des Makefiles

Jetzt fehlt eigentlich nur noch die Anpassung des Makefiles an unsere Modulnamen. Dazu öffnen wir die Datei crt\src\makefile mit einem Texteditor und ändern die Modulnamen wie folgt:

RETAIL_DLL_NAME=MyVcr90
RETAIL_LIB_NAME=msvcrt
RETAIL_DLLCPP_NAME=MyVcp90
RETAIL_LIBCPP_NAME=msvcprt
RETAIL_DLLMIXED_NAME=MyVcm90
RETAIL_LIBMIXED_NAME=msvcmrt
RETAIL_LIBPURE_NAME=msvcurt
RETAIL_PT_LIBMIXED_NAME=ptrustm
RETAIL_PT_LIBPURE_NAME=ptrustu
DEBUG_DLL_NAME=MyVcr90d
DEBUG_LIB_NAME=msvcrtd
DEBUG_DLLCPP_NAME=MyVcp90d
DEBUG_LIBCPP_NAME=msvcprtd
DEBUG_DLLMIXED_NAME=MyVcm90d
DEBUG_LIBMIXED_NAME=msvcmrtd
DEBUG_LIBPURE_NAME=msvcurtd
DEBUG_PT_LIBMIXED_NAME=ptrustmd
DEBUG_PT_LIBPURE_NAME=ptrustud
RC_NAME=MyVcr90
RCCPP_NAME=MyVcp90
RCMIXED_NAME=MyVcm90

In der Datei crt\src\makefile.sub ersetzen wir in den Zeilen 106, 111 und 116 die Option -Wp64 durch -MP-Wp64 wird seit Visual Studio 2008 nicht mehr unterstützt, bei aktiviertem Schalter wird das Kompilieren der CRT sonst abgebrochen. -MP sorgt bei Multicore-Prozessoren dafür, dass das Kompilieren wesentlich flotter abläuft.

5. Kompilieren

Jetzt sind endlich fast alle Vorbereitungen abgeschlossen und wir nähern uns langsam dem Kompilieren. Vorher müssen wir aber noch dafür sorgen, dass der Compiler auch alle Dateien findet. Dazu erstellen wir uns in crt\src zwei Batchdateien. Zuerst vcvars_x86.bat mit:

@ECHO OFF
@SET PSDKINC=E:\Visual Studio.9\VC\PlatformSDK\include
@SET PSDKLIB=E:\Visual Studio.9\VC\PlatformSDK\lib
@SET PSDKBIN=E:\Visual Studio.9\VC\PlatformSDK\bin
@SET VSCOMMON=E:\Visual Studio.9\Common7
@SET VCTOOLS=E:\Visual Studio.9\VC
@SET VCTOOLSINC=$(PSDKINC)
@SET LLP64=0

@echo Setting environment for using Microsoft Visual Studio 2008 x86 tools.

@set PATH=%VCTOOLS%\BIN;%VCTOOLS%\BIN;%PSDKBIN%;%VSCOMMON%\IDE;%PATH%;
@set INCLUDE=%VCTOOLS%\ATLMFC\INCLUDE;%VCTOOLS%\INCLUDE;%PSDKINC%;%INCLUDE%
@set LIB=%VCTOOLS%\ATLMFC\LIB;%VCTOOLS%\LIB;%PSDKLIB%;%LIB%

und anschließend vcvars_amd64.bat mit:

@ECHO OFF
@SET PSDKINC=E:\Visual Studio.9\VC\PlatformSDK\include
@SET PSDKLIB=E:\Visual Studio.9\VC\PlatformSDK\lib
@SET PSDKBIN=E:\Visual Studio.9\VC\PlatformSDK\bin
@SET VSCOMMON=E:\Visual Studio.9\Common7
@SET VCTOOLS=E:\Visual Studio.9\VC
@SET VCTOOLSINC=$(PSDKINC)
@SET LLP64=2

@echo Setting environment for using Microsoft Visual Studio 2008 x64 cross tools.

@set PATH=%VCTOOLS%\BIN\x86_amd64;%VCTOOLS%\BIN;%PSDKBIN%;%VSCOMMON%\IDE;%PATH%;
@set INCLUDE=%VCTOOLS%\ATLMFC\INCLUDE;%VCTOOLS%\INCLUDE;%PSDKINC%;%INCLUDE%
@set LIB=%VCTOOLS%\ATLMFC\LIB\amd64;%VCTOOLS%\LIB\amd64;%PSDKLIB%\x64;%LIB%

Die Pfade der Umgebungsvariablen müsst ihr an euer System anpassen. Der Übersichtlichkeit halber habe ich die Dateien aus dem Windows-SDK wie bei Visual Studio 2005 in das Unterverzeichnis PlatformSDK kopiert. Bei Visual Studio 2008 erfolgt die Installation der SDK-Headerdateien und Bibliotheksdateien normalerweise nach C:\Program Files\Microsoft SDKs\Windows\v6.0A.

Das war es auch schon mit den Vorbereitungen. Nun öffnen wir eine Eingabeaufforderung, wechseln in das Verzeichnis crt\src und geben zum Kompilieren der x86-Version

vcvars_x86.bat
nmake

und für die x64-Version

vcvars_amd64.bat
nmake

ein. Danach wird der Rechner jeweils ein wenig beschäftigt sein und die Laufzeitbibliotheken erstellen. Etwaige Warnungen können ignoriert werden, nur Fehler sollten keine auftreten. Wenn sich der Befehlsprompt wieder meldet, dann ist das Gröbste erledigt.

6. Kopieren der Lib-Dateien

Der letzte Schritt ist das Kopieren der erstellten Importbibliotheken aus den Verzeichnissen crt\src\build\intel bzw. crt\src\build\amd64 in das lib-bzw. lib\amd64-Verzeichnis. Da wir uns nur für die dynamischen Bibliotheken interessieren, reichen diese vollkommen aus:

msvcrt.lib
msvcrtd.lib
msvcprt.lib
msvcprtd.lib

In den Buildverzeichnissen finden wir auch die angepassten Dlls MyVcr90(d).dll für die C-Laufzeit sowie MyVcp90(d).dll für die C++-Laufzeit (STL). Die ebenfalls erstellten MyVcm(d).dll enthalten die Laufzeit für verwalteten Code. Die hier vorgestellte Vorgehensweise ist aber wirklich nur für rein nativen Code gedacht, daher können wir die Vcm-Dlls links liegen lassen.

Das war’s auch schon, mit der MFC geht es dann morgen weiter. Im Vergleich mit der C/C++-Laufzeit wird das aber eher ein Kindergeburtstag.

Pimp my autoexp.dat

By Sven on 29.11.2007 - 12:24 in Visual Studio 2005, Visual Studio 2008 with Keine Kommentare

Beim Debuggen in Visual Studio 2008 stört mich, dass bei CString-Objekten nicht mehr sofort die entsprechende Zeichenkette als InfoTip angezeigt wird. Stattdessen muss man den InfoTip erst erweitern, das gleiche gilt auch für die Anzeige der Variablen im Watch-Fenster:

Keine direkte Anzeige von CString

Das hat mich an die Existenz der autoexp.dat erinnert, die es schon seit Visual Studio 6 gibt. Diese kann man um eigene Ausdrücke ergänzen, so dass der Debugger die Werte von bestimmten Datentypen gleich anzeigt. Die autoexp.dat befindet sich unter <VSInstallDir\Common7\Packages\Debugger> und sie kann mit einem einfachen Texteditor bearbeitet werden. Fügt man in der Sektion [AutoExpand] die beiden Zeilen

ATL::CSimpleStringT<char,1> = m_pszData=<m_pszData,s>
ATL::CSimpleStringT<wchar_t,1> = m_pszData=<m_pszData,su>

hinzu, dann sieht die Anzeige im Debugger gleich viel besser aus:

Direkte Anzeige von CString

Beim Blättern in der autexp.dat sind mir auch die auskommentierten Zeilen

; see EEAddIn sample for how to use these
;_SYSTEMTIME=$ADDIN(EEAddIn.dll,AddIn_SystemTime)
;_FILETIME=$ADDIN(EEAddIn.dll,AddIn_FileTime)

aufgefallen. Google hat mich dann zum EEAddIn-Beispiel geführt, welches ich sogleich heruntergeladen und kompiliert habe. Der ersten Begeisterung folgte aber sogleich die Enttäuschung, denn es funktionierte nicht. Auch die explizite Angabe des Pfades oder das Anpassen der Funktionsnamen auf die wirklich exportierten Namen (_AddIn_SystemTime@28) wollte nicht helfen.

Wie debuggt man aber ein AddIn für den Debugger, welches nur geladen wird, wenn eine andere Anwendung gedebuggt wird? Ich habe mich für die universelle MessageBox-Methode entschieden, also an den wichtigen Stellen einfache MessageBox-Aufrufe eingebaut. Es zeigte sich, dass

// read system time from debuggee memory space
if (! pHelper->ReadDebuggeeMemoryEx(pHelper, pHelper->GetRealAddress(pHelper), sizeof(SysTime), &SysTime, &nGot) )
return E_FAIL;

fehlschlug. Mein Bauch sagte mir, dass ReadDebuggeeMemoryEx anstatt eines BOOL-Wertes möglicherweise einen HRESULT-Wert zurückgibt. Nach der Änderung dieser Zeilen auf

// read system time from debuggee memory space
if (FAILED(pHelper->ReadDebuggeeMemoryEx(pHelper, pHelper->GetRealAddress(pHelper), sizeof(SysTime), &SysTime, &nGot)))
return E_FAIL;

wurde der Wert einer SYSTEMTIME-Variablen plötzlich wunschgemäß angezeigt:

Direkte Anzeige von SYSTEMTIME

Auch die FILETIME-Variable sieht nun wesentlich informativer aus:

Direkte Anzeige von FILETIME

Bei der Entwicklung eines Dateimanagers kommt man ja öfters mit FILETIME-Variablen in Berührung. Dank dem EEAddIn sieht man nun sofort den formatierten Wert, ohne dass man erst ein paar Zeilen für die Formatierung einfügen muss. So gut bin ich nämlich auch nicht im Kopfrechnen, dass ich aus den beiden DWORD-Werten der FILETIME-Struktur sofort auf das richtige Datum schließen kann.

/strong

VS 2008: Deutsche Version im Januar

By Sven on 27.11.2007 - 17:47 in Visual Studio 2008 with 3 Kommentare

In seinem Weblog hat Somasegar die Pläne für die lokalisierten Versionen von Visual Studio 2008 und .NET Framework 3.5 bekanntgegeben:

  • Japanische Version im Dezember 2007
  • Deutsche und französische Version im Januar 2008
  • Weitere Versionen im Februar 2008

Neues aus dem digitalen Fuhrpark

By Sven on 22.11.2007 - 12:25 in Fuhrpark with 9 Kommentare

In den letzten Monaten habe ich immer wieder Ausschau nach einem neuen Notebook gehalten. Mein Sony VAIO GRX416G ist auch nach fünf Jahren immer noch ein feines Teil, nur die Performance unter Visual Studio 2008 lässt etwas zu wünschen übrig. Mit maximal 1 GB Arbeitsspeicher und einem Pentium 4M mit 1.8 GHz ist das auch nicht verwunderlich.

Meine Anforderungen lesen sich eigentlich recht einfach:

  • Gutes spiegelfreies Display mit möglichst hoher Auflösung, maximal 16 Zoll
  • Vernünftige Tastatur
  • Kein Radaubruder
  • Akkulaufzeit von 3h (oder höher)
  • Bezahlbar

Der erste Punkt zeigt sich in der Praxis aber schon als Ausschlusskriterium. Spiegelfreie Displays sind heute deutlich in der Unterzahl. Die Standardauflösung liegt zudem bei 1280×800 Punkten, wenn man aber an 1600×1200 Punkten gewöhnt ist, dann macht das nicht wirklich Spaß. Größere Auflösungen gibt es in der Regel erst ab 17 Zoll, aber das ist mir zu groß.

Ein Apfel hätte mich auch gereizt, aber die MacBooks sind mir zu klein und das 17″ MacBook Pro zu teuer. Außerdem bin ich ja hauptsächlich unter Windows unterwegs, da stellt sich dann die Frage der optimalen Tastatur- und Mausunterstützung. Mein langjähriger Favorit Sony fällt mittlerweile auch flach, weil es hier fast nur noch spiegelnde Display gibt. Die höheren Auflösungen sind auch nur mit einem BluRay-Laufwerk gebundelt, was sich dann wieder auf den Preis auswirkt.

In den letzten c’t-Tests haben die ThinkPads immer gut abgeschnitten, also habe ich mir die auch mal näher angeschaut. Mit 1680×1050 Punkten bei 15,4 Zoll Auflösung könnte ich gut leben, ansonsten genießen die ThinkPads auch einen ziemlich guten Ruf. Drei Jahre Garantie sind ebenfalls nicht zu verachten. Meine Wahl fiel schließlich auf das Modell NH38NGE. Der einzige Unterschied zum NH38SGE ist das Betriebssystem, statt Windows XP bekommt man Vista Business.

Die ersten Erfahrungen sind durchweg positiv. Mit 1680×1050 auf 15,4 Zoll lässt sich gut arbeiten, die bei dieser Größe ebenfalls angebotenen 1900×1200 wären wohl des Guten zuviel gewesen. Im Alltagsbetrieb hört man nur ein leises Rauschen der Festplatte, der CPU-Lüfter schlägt kaum an. Auch die Tastatur lässt keinen Raum für Kritik.

Der Infobereich neben der Taskbar vom vorinstallierten Vista Business reicht von hier bis nach Meppen. Das ist aber weniger tragisch, da ich sowieso keine Vorinstallationen mag und mir das System lieber selbst zumülle. Eigentlich hatte ich vor, Windows XP x64 und Vista Business nebeneinander zu installieren. Leider gibt es von Lenovo nur Treiber für Windows XP und Vista 32/64, so dass die Wahl dann auf Windows XP und Vista x64 fiel. Mit einem zusätzlichen Speicherriegel von 2 GB, den es heute schon für um die 60 Euro gibt, fühlt sich Vista x64 richtig wohl. Windows XP kann immerhin noch auf volle 3 GB zugreifen.

Von Lenovo gibt es einen System Updater, der automatisch alle benötigten Treiber installiert. Ist eigentlich eine gute Idee, wenn man denn nicht in den Taskmanager schaut und Wert darauf legt, möglichst wenig unnötige Anwendungen und Dienste im Hintergrund laufen zu haben. Ohne System Updater geht es auch, da die einzelnen Treiber auch separat zum Download angeboten werden. Unter Vista werden die meisten Treiber zudem durch Windows Update geliefert, lediglich das Speicherkarten-Lesegerät sowie das WLAN-Modul müssen manuell installiert werden.

Die nächsten Tage und Wochen werden dann zeigen, wie sich das ThinkPad in der Praxis schlägt. Spaß macht es bisher auf jeden Fall.

Download läuft

By Sven on 19.11.2007 - 19:48 in Visual Studio 2008 with 10 Kommentare

Seit heute vormittag ist Visual Studio 2008 verfügbar, der Weg zum Download war allerdings sehr schwierig. Am Nachmittag hatte ich arge Probleme, die Subscription Downloads zu Gesicht zu bekommen. Der MSDN-Server war wohl arg gestresst und lieferte immer den Fehler

Server Error in ‘/’ Application.
The file ‘/home.aspx’ has not been pre-compiled, and cannot be requested.

Am frühen Abend ging es dann wieder, allerdings tauchte Visual Studio 2008 Professional immer noch nicht in der Liste auf. Der Download kam mit dieser Adresse endlich näher (man muss sich hier vorher mit seiner LiveID anmelden), allerdings tat sich beim Klick auf die Links nicht viel. Der Grund war mein Popup-Blocker, aber darauf muss man auch erst mal kommen.

Nun lädt ein Akamai-Downloadmanager als ActiveX-Control das ISO-Image herunter. Den bisher gewohnten Weg über den FTM hätte ich mit Sicherheit besser gefunden.

Kontextmenü entschlackt

By Sven on 12.11.2007 - 22:29 in Visual Studio 2005, Visual Studio 2008 with 2 Kommentare

Dank dem genialen Tipp von Martin habe ich das Projekt-Kontextmenü von Visual Studio endlich mal ein wenig übersichtlicher gestalten können. Seit Visual Studio 2005 war mir dies mit knapp 30 Einträgen doch ein wenig zu voll, die Übersichtlichkeit leidet unter den vielen Einträgen enorm.

Nach dem Hinzufügen von zwei Untermenüs (“Source Safe” und “Advanced”) und dem Wegsortieren der entsprechenden Befehle sieht es nun bedeutend übersichtlicher aus. Hier das Untermenü mit der Quellcodeverwaltung:

Kontextmenü mit Quellcodeverwaltung

Und so schaut das Menü mit den weniger benötigten Befehlen aus:

Kontextmenü mit unnötigen Befehlen

Warme Farben

By Sven on 12.11.2007 - 20:11 in Visual Studio 2005, Visual Studio 2008 with Keine Kommentare

In 15 Jahren Windows-Entwicklung habe ich in der IDE immer mit den Standardfarben gearbeitet, also dunkler Text auf hellem Hintergrund. Der weiße Fensterhintergrund war mir aber immer zu grell, daher war das erste nach einer Windows-Installation die Anpassung auf RGB(255, 251, 240). Nebenbei hatte das den Vorteil, dass man bei Zeichenoperationen gleich bemerkte, wenn man es mal vergessen hatte, die korrekte Hintergrundfarbe zu setzen. Der Nachteil waren die vielen HTML-Seiten im weltweiten Netz, deren Programmierer es wohl als überflüssig ansahen, eine weiße Hintergrundfarbe anzugeben.

Bei Damien Guard habe ich neulich ein Farbschema gesehen, das sehr angenehm aussah. An die Envy Code R VS-Schrift konnte ich mich nicht gewöhnen, mir ist sie (genau wie Consolas) etwas zu dünn. Nach einigen kleinen Anpassungen sieht das bei mir nun so aus:

Farbschema Visual Studio

Wer das auch mal ausprobieren möchte, der kann sich das Farbschema hier herunterladen. Die Installation in Visual Studio erfolgt über das Importieren von Einstellungen im Menü Tools.

2.7 MiB mehr für nichts

By Sven on 12.11.2007 - 18:52 in MFC, Visual Studio 2008 with 1 Kommentar

Pat Brenner hat im VC-Blog meine schlimmsten Befürchtungen bestätigt: Die Erweiterungen von MFCnext werden komplett in die MFCxx.dll gepackt, was deren Größe mal eben von 1.1 MiB auf 3.8 MiB ansteigen lässt. Einer der Vorteile der MFCxx.dll war immer, dass sie über die Jahre hinweg relativ schlank geblieben ist. All das ist Geschichte, stattdessen wird die MFC jetzt mit Klassen vollgestopft, welche wohl die wenigsten benötigen. Und am allerwenigsten diejenigen, die schon eine eigene UI-Bibliothek einsetzen.

Ich hoffe immer noch inständig, dass sich das unnützte Zeug beim Erstellen einer angepassten MFC-Version recht einfach ausblenden lassen wird. Sollte Microsoft es aber schaffen, MFC und MFCnext untrennbar miteinander zu verquicken, dann wird die MFC 9.0 meine letzte MFC-Version sein. Ich hatte eigentlich gedacht, dass ich mit dem Umstieg von VC6 auf VS 2008 nun längere Zeit nichts mehr mit MFC-Anpassungen zu tun haben und automatisch immer in den Genuss der neuesten Version kommen werde. Aber so kann man sich täuschen.

Weitere Infos zum MFC UI-Update

By Sven on 08.11.2007 - 20:14 in MFC, Visual Studio 2008 with 7 Kommentare

Im Codejock-Forum hat Kirk Stowell (der Chef von Codejock) ein paar interessante Infos zur ganzen Geschichte veröffentlicht, die ich euch nicht vorenthalten möchte. Demnach hat Microsoft schon vor einigen Jahren Codejock kontaktiert, um die MFC für Visual Studio 2005 etwas aufzupeppen. Es gab ein paar Gespräche, zu mehr führte es aber nicht.

Im März dieses Jahres ist Microsoft erneut mit Codejock in Kontakt getreten und hat Interesse daran geäußert, Codejocks MFC-Komponenten in die MFC von Visual Studio 2008 aufzunehmen. Das Budget für mögliche Lizenzgebühren sei aber nicht gerade hoch.

Im August ließ Microsoft wieder von sich hören. Man wollte mit Codejock über Erweiterungspläne der MFC diskutieren, als auch über die möglichen Auswirkungen auf die MFC-Produkte von Codejock. In diesen Gesprächen kam herüber, dass Microsoft für wenig Geld die MFC-Komponenten von BCGSoft lizenzieren wird und diese somit Teil der MFC werden sollen.

Kirk gab zu bedenken, dass sich diese Entscheidung als großer Fehler herausstellen könnte. Aus Erfahrung gäbe es einige Probleme mit den BCG-Komponenten, angefangen von der Stabilität bis hin zur recht schwachen Performance. Er wies Microsoft auch darauf hin, dass sich gerade deshalb viele BCG-Anwender für einen Wechsel zu den Produkten von Codejock entschieden hätten und schlug vor, dass Microsoft doch die Meinung einiger dieser Kunden einholen könnte. Der Vertrag mit BCGSoft war aber schon unterschrieben und Microsoft sah keine Notwendigkeit mehr, diese Sache weiter zu verfolgen.

Genau wie Kirk glaube ich auch, dass Microsoft eine ziemlich unglückliche Entscheidung getroffen hat. Die Performance-Probleme waren damals auch einer der Gründe für mich, vor vier Jahren zu Codejock zu wechseln. Ich kann mich noch gut daran erinnern, dass die Einbindung der BCGControlBar in FileSearch (SpeedCommander 9) den Start der Anwendung um knapp zwei Sekunden verzögerte. Also verzichtete ich damals in FileSearch auf die anpassbaren Menüs, stattdessen zeigte sich FileSearch nur mit normalen Menüs.

Gemeinsam mit Rainer haben wir damals auch die Aufrufgeschwindigkeit der frei downloadbaren Beispieldateien von Codejock und BCGSoft miteinander verglichen. Die von BCGSoft starteten alle merklich langsamer. Auf Rainers Rechner, der damals auch nicht gerade der schnellste war, wurde dies besonders deutlich.

Microsoft wird also einiges an Mühe aufwenden müssen, damit die MFCnext ein stabiles und performantes Produkt wird. Es ist als Entwickler immer schwer, sich in eine so umfangreiche Bibliothek einzuarbeiten. Mal schauen, wie Microsoft das meistern wird.

The Next Generation

By Sven on 08.11.2007 - 01:49 in MFC, Visual Studio 2008 with 1 Kommentar

In Barcelona findet in dieser Woche die TechEd Developers 2007 statt, also der richtige Zeitpunkt, um Großes zu verkünden. Die erste wichtige Info ist, dass Visual Studio 2008 bis zum Ende dieses Monats verfügbar sein wird und damit wohl allen MSDN-Abonnenten zur Verfügung gestellt wird.

Schon seit einiger Zeit laufen einem im Web Hinweise über den Weg, dass auch für die MFC einige Überraschungen zu erwarten sind. Microsoft hat nun die Katze aus dem Sack gelassen, und diese Katze ist wirklich fett. Die MFC bekommt ein vollständiges UI-Toolkit spendiert (genannt MFCnext), unter anderem mit

  • Office 2007-Ribbon
  • Erweiterte Docking-Funktionen
  • Verschiedene Styles (Office 2003, Office 2007, …)
  • Etliche neue UI-Elemente (Eigenschaftsseiten, Maskierbares Editierfeld, Farbpicker, …)

Der erste Release Candidate soll schon im Dezember veröffentlicht werden, die endgültige Freigabe ist für März 2008 geplant.

Auf den ersten Blick sieht das auch alles Klasse aus, mit dem zweiten sieht man aber bekanntlich besser. Und man stellt fest, dass dies alles ja schon seit Jahren zur Verfügung steht. Zwar nicht mit der MFC selbst, wohl aber mit den Toolkits anderer Hersteller (Codejock oder BCGSoft). Hier stellt sich nun die Frage, wie der Vergleich zwischen den neuen MFC-Erweiterungen und den etablierten Bibliotheken ausschauen wird, sowohl vom Umfang als auch von der Performance und der Codequalität. Auch wird interessant, wie die beiden Hersteller mit der Situation klarkommen, dass die von ihnen verkauften Funktionen nun plötzlich Bestandteil von Visual Studio sind und damit für jeden MFC-Anwender auch kostenfrei zur Verfügung stehen. Wenn sich Microsoft einmal entschließen sollte, jedem Windows einen vernünftigen Dateimanager beizulegen, dann hätte ich wohl ein ähnliches Problem.

Dank Jochen Kalmbach brauchen wir mit der Beantwortung dieser Fragen aber wohl nicht bis zum Dezember warten. In seiner Information zum geplanten MFC-Update verrät er nämlich, dass die meisten Controls von BCGSoft “portiert” wurden. Wenn man sich mal die von ihm gemachten Fotos der Session anschaut und diese mal mit den Headerdateien der BCGControlBar Professional Edition vergleicht, dann entdeckt man auch erstaunlich viele Gemeinsamkeiten mit den BCG-Klassen. “Portiert” heißt dann vermutlich eher “aufgekauft und umbenannt”. Aus Raider wird also Twix, sonst ändert sich nichts.

Und genau das ist für mich der Punkt, auch in Zukunft weiter auf Codejock zu setzen. Bis einschließlich SpeedCommander 9 habe ich ja bereits mit der BCGControlBar gearbeitet, mit SpeedCommander 10 erfolgte der Wechsel auf das Xtreme Toolkit Pro. Und diesen Wechsel habe ich bisher keine einzige Sekunde bereut. Nach meiner Erfahrung ist die Codejock-Bibliothek nämlich um einiges performanter und auch übersichtlicher und moderner aufgebaut. Das Klassenlayout der aktuellen BCGControlBar-Version hat dagegen noch erstaunlich viel Gemeinsamkeiten mit den ganz frühen Versionen, die ich noch verwendet habe. Das mag gut für die Abwärtskompatibilität sein, so ein altes Fundament hat aber leider auch Nachteile. Neue Sachen werden nämlich immer nur angebaut und irgendwann schwindet die Übersichtlichkeit.

Wer also schon mal schauen will, wie sich die neuen UI-Elemente in der Praxis anfühlen, der muss sich einfach nur die Testversion der BCGControlBar Professional Edition herunterladen. Auf der gleichen Seite gibt es auch bereits kompilierte Beispielanwendungen. Spannend wird sicher sein, wie die Zukunft der BCGControlBar ausschaut. Ich glaube kaum, dass BCGSoft damit noch viel Umsatz machen wird. Aber vermutlich wird der Scheck von Microsoft groß genug gewesen sein, um die Schmerzen einigermaßen in Grenzen zu halten. Weitaus schwieriger wird es dagegen für Codejock werden. Ich hoffe wirklich, dass sich die Jungs durch diese Ankündigung nicht entmutigen lassen und auch in Zukunft gute Umsätze haben. Es wäre nämlich äußerst schade, wenn Codejock dadurch auf der Strecke bleiben würde.

Top