Komfortabler Dateimanager mit vielen Funktionen

Endlich da

By Sven on 03.12.2007 - 10:22 in Visual Studio 2008 with 3 Kommentare

Im heise-Newsticker ist mir gestern diese brandaktuelle Flash-Werbung über den Weg gelaufen:

Visual Studio 2008 Beta 2

VS 2008: MFC selbst kompilieren

By Sven on 01.12.2007 - 11:02 in MFC, Visual Studio 2008 with 5 Kommentare

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:

Importe von Test.exe

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

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.

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

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.

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.

Top