Endlich da
Im heise-Newsticker ist mir gestern diese brandaktuelle Flash-Werbung über den Weg gelaufen:
VS 2008: MFC selbst kompilieren
Gestern hatte ich darüber berichtet, wie man der WinSxS-Hölle entkommt und eine eigene Version der C/C++-Laufzeit kompiliert. Nun kompilieren wir uns noch eine MFC ohne Manifest und können in Zukunft die C/C++-Laufzeit sowie die MFC unseren Anwendungen beilegen, ohne uns mit Manifestproblemen herumquälen zu müssen.
1. Anpassen der Dateien
Die nötigen Änderungen an den MFC-Dateien halten sich in Grenzen. Zuerst schnappen wir uns die Datei atlmfc\include\MFCassem.h und kommentieren das Manifest ab Zeile 25 bis zum Ende aus. In atlmfc\include\afx.h ersetzen wir die Zeilen 81 bis 97 durch folgende:
#ifndef _UNICODE #ifdef _DEBUG #pragma comment(lib, "MyMfc90d.lib") #pragma comment(lib, "MyMfc90sd.lib") #else #pragma comment(lib, "MyMfc90.lib") #pragma comment(lib, "MyMfc90s.lib") #endif #else #ifdef _DEBUG #pragma comment(lib, "MyMfc90ud.lib") #pragma comment(lib, "MyMfc90sud.lib") #else #pragma comment(lib, "MyMfc90u.lib") #pragma comment(lib, "MyMfc90su.lib") #endif #endif
Damit legen wir fest, dass unsere Anwendungen dynamisch gegen die MyMfc90(u).dll gelinkt werden.
2. Vorbereitung der .DEF-Dateien
In atlmfc\src\mfc\intel und atlmfc\src\mfc\intel befinden sich jeweils vier .DEF-Dateien, deren Modulnamen ebenfalls angepasst werden müssen:
mfc90.def -> MyMfc90 mfc90d.def -> MyMfc90d mfc90u.def -> MyMfc90u mfc90ud.def -> MyMfc90ud
Im Gegensatz zur C/C++-Laufzeit werden aber nur die Modulnamen in den .def-Dateien angepasst, die Dateinamen selbst dürfen nicht geändert werden.
3. Anpassung des Makefiles
Die Änderung in der Datei atlmfc\src\atlmfc.mak beschränkt sich darauf, die Erstellung der statischen MFC sowie der WinForms-Komponenten auszuklammern. Dazu löschen wir in Zeile 123 die Einträge MFC_STATIC und MFCM_DLL.
4. Kompilieren
Nun kopieren wir unsere bereits erstellten Batchdateien mit den Umgebungsvariablen aus dem Ordner crt in den Ordner atlmfc\src. Zusätzlich erstellen wir in diesem Verzeichnis eine Datei makemfc_x86.bat mit dem Inhalt
nmake -f atlmfc.mak MFC LIBNAME=MyMfc90 PLATFORM=INTEL MP_BUILD=1
sowie makemfc_amd64.bat mit
nmake -f atlmfc.mak MFC LIBNAME=MyMfc90 PLATFORM=AMD64 MP_BUILD=1
Anschließend öffnen wir eine Eingabeaufforderung und starten
vcvars_x86.bat makemfc_x86.bat
sowie anschließend
vcvars_amd64.bat makemfc_amd64.bat
Nach ein paar Minuten sollte der Compiler seine Arbeit erledigt haben und wieder das Befehlsprompt erscheinen.
5. Kopieren der Lib-Dateien
Der letzte Schritt ist das Kopieren der lib-Dateien nach atlmfc\lib, damit der Linker diese später auch findet. Die Lib-Dateien für die 32-bit Version werden bei der MFC-Erstellung in atlmfc\lib\Intel abgelegt und müssen deshalb manuell nach atlmfc\lib kopiert werden. Die Lib-Dateien für die x64-Version landen dagegen direkt im richtigen Verzeichnis (atlmfc\lib\amd64).
Die MFC-Dlls finden wir in atlmfc\src\mfc\intel bzw. atlmfc\src\mfc\amd64. Zusammen mit den Dlls der C/C++-Laufzeit sowie den jeweiligen PDB-Dateien kopieren wir sie in einen Ordner, der in die PATH-Umgebungsvariable eingetragen wird. Somit ist sichergestellt, dass Visual Studio 2008 beim Debuggen auch alle nötigen Dateien findet.
6. Kontrolle
Zur Kontrolle erstellen wir uns ein Testprojekt und prüfen, ob gegen die richtigen Dateien gelinkt wird. Dazu lassen wir uns vom AppWizard eine einfache MFC-Anwendung erstellen und kompilieren diese. Mit Hilfe der Schnellansicht von SpeedCommander lässt sich leicht ermitteln, ob die Programmdatei an die richtigen Module gebunden wurden. Wenn es so ausschaut, dann ist alles in bester Ordnung:
Die gleiche Aktion führen wir noch einmal für die MyMfc90(ud).dll durch, diese sollten ebenfalls gegen die MyVcr90(d).dll gelinkt sein.
7. Letzte Worte
Zum Abschluss sei nochmals erwähnt, dass sich diese beiden Artikel wirklich nur an den nativen Entwickler richten, der vollständigen Einfluss auf die von ihm verwendeten Komponenten hat. Dazu gehört, dass alle Fremdkomponenten im Quellcode vorliegen und somit gegen die angepasste C/C++-Laufzeit bzw. die MFC kompiliert werden können. Verwendet man dagegen zusätzliche Managed Code-Erweiterungen oder fertige Libs/Dlls, die bereits gegen die originale MsVcr90.dll gelinkt sind, dann sollte man um die manifestlose Lösung einen großen Bogen machen.
VS 2008: C/C++-Laufzeit selbst kompilieren
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.
6. 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.
7. 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
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:
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:
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:
Auch die FILETIME-Variable sieht nun wesentlich informativer aus:
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.
VS 2008: Deutsche Version im Januar
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
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
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
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:
Und so schaut das Menü mit den weniger benötigten Befehlen aus:
Warme Farben
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:
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
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.