Visual Studio 2008

Heute gibt es einen Rezeptvorschlag für Visual Studio 2008 R2. Folgende Zutaten werden benötigt:

• 1x installiertes Visual Studio 2008 (System 1)
• 1x installiertes Visual Studio 2010 (System 2, vorzugsweise in einer VM)

Vorgehensweise:

• Installation von .NET 4.0 auf System 1 (befindet sich auf der VS2010-ISO unter WCU\dotNetFramework)
• Kopieren der Release/Debug-Laufzeitbibliotheken (CRT/MFC) in die 32/64-bit Systemverzeichnisse auf System 1 (zu finden unter %VS2010DIR%\VC\redist)
• Kopieren der Symboldateien für CRT/MFC von System 2 nach System 1 (zu finden im Windows-Verzeichnis unter symbols\dll)
• Verschieben der Ordner atlmfc, bin, crt, include und lib aus %VS2008DIR%\VC nach %VS2008DIR%\VC\!VC9
• Kopieren der Ordner atlmfc, bin, crt, include und lib aus %VS2010DIR%\VC nach %VS2008DIR%\VC
• Kopieren der Dateien mspdbsrv.exe, mspdb100.dll, mspdbcore.dll und msobj100.dll aus %VS2010DIR%\Common7\IDE nach %VS2008DIR%\VC\bin

Das Ergebnis ist ein Visual Studio 2008 mit neuem Compiler/Linker sowie den aktuellen Versionen von CRT/MFC. Durch Austauschen der Ordner atlmfc, bin, crt, include und lib kann man jederzeit zwischen originaler und angepasster Version wechseln. Zu beachten ist noch, dass man die Header-/Bibliotheksdateien aus dem Windows 7-SDK verwendet (bzw. die Dateien, die von Visual Studio 2010 installiert wurden).

Eine Gewährleistung für die fehlerfreie Funktionalität wird selbstverständlich ausgeschlossen. Bisher konnte ich aber noch keine Einschränkungen feststellen.

Der eine oder andere kennt vielleicht die vielen kleinen (insgesamt 382) Tips zu Visual Studio, die Sara Ford täglich in ihrem Weblog veröffentlicht hat. Im letzten Herbst hat sie 250 davon in einem Buch zusammengestellt, die deutsche Ausgabe ist mittlerweile auch erhältlich. Ich habe mir das Buch gerade bestellt. Auf der Couch macht das Lesen halt mehr Spaß als vor dem Rechner.

Erwähnenswert ist vielleicht noch, dass Sara Ford alle ihre Einkünfte aus dem Buchverkauf einem Stipendienfond zur Verfügung stellt, um Betroffene vom Wirbelsturm Katrina den Collegebesuch zu ermöglichen.

Beim Debuggen von Memory-Dumps hat man meistens das Problem, dass die entsprechenden Windows-Symboldateien zum Snapshot des Anwenders nicht vorhanden sind. Letztlich muss eine Symboldatei immer genau zur jeweiligen Dll passen, damit der Debugger den Aufrufstack vernünftig anzeigen kann. Dank dem Microsoft-Symbolserver ist das aber kein großes Problem, der Debugger kann sich die passenden Symboldateien automatisch herunterladen.

Nachteilig ist, dass man keine Möglichkeit hat, die gewünschten Symboldateien auszuwählen. Startet man einen Dump mit aktiviertem Symbolserver, dann werden automatisch alle Symboldateien heruntergeladen, die zum jeweiligen Snapshot passen. Zudem lädt der Debugger auch noch die entsprechenden System-Dlls herunter, was natürlich entsprechend dauert.

Mit VS 2008 SP1 scheint Microsoft das Laden von Symboldateien erheblich vereinfacht zu haben. Gestern habe ich ein Kontextmenü entdeckt, das ich bisher noch nie gesehen hatte. Ich bin mir sicher, dass dieses Menü in der RTM-Version noch nicht enthalten war:

Nach Auswahl des Befehls wurde die passende Symboldatei für „kernel32.dll“ heruntergeladen und der Aufrufliste aktualisiert. Genial!

Letzte Woche habe ich eher zufällig entdeckt, dass man in den Projekteigenschaften auf der Debugging-Seite auch zusätzliche Umgebungsvariablen definieren kann:

Die Option Zusammenführungsumgebung legt fest, ob die neuen Umgebungsvariablen mit den bestehenden zusammengeführt oder ob die aktuellen Umgebungsvariablen ersetzt werden sollen.

Das macht es bedeutend einfacher, entsprechend der gewählten Konfiguration (Win32 oder x64) mit dem jeweils passenden Bibliotheksverzeichnis zu arbeiten. Bisher hatte ich mir immer mit einem kleinen Programm geholfen, das die Umgebungsvariablen vor dem Start der IDE anpasste. Damit war allerdings kein spontanes Umschalten zwischen der Win32-Version und der x64-Version möglich.

Das Anfang der letzten Woche zum Download freigegebene Feature Pack für Visual Studio 2008 steht unter keinem guten Stern. Nachdem sich schon die Betaversion vom Ende des letzten Jahres unter bestimmten Konfigurationen nicht installieren ließ, bringt die finale Version nun neue Installationsprobleme mit sich. Auf nicht-englischen Systemen bzw. auf englischen Systemen mit deutscher Regions- und Spracheinstellung lässt sich das Feature Pack nur installieren, wenn man die Regions- und Spracheinstellung vorher auf Englisch (USA) stellt.

Das 32-bittige Laufzeit-Installationspaket lässt sich auf Windows Vista und Windows Server 2008 erst gar nicht installieren, während der Installation wird folgende Fehlermeldung angezeigt:

Auf Systemen, auf denen die Installation funktioniert, werden die Assemblies für ATL und OpenMP für eine falsche Prozessorarchitektur installiert, so dass Anwendungen, welche diese Module verwenden, nicht funktionieren.

Es ist schon verwunderlich, dass diese Probleme beim internen Test nicht aufgefallen sind. Man kann nur hoffen, dass der eigentliche Quellcode besser getestet wurde. Auf meine Arbeit hat das aber alles keine Auswirkungen, weil ich das Feature Pack auf meinem Entwicklungssystem nicht installieren werde.

Die Windows-Programmierer unter euch werden sicher auch festgestellt haben, dass sich Funktionsdefinitionen in den Header-Dateien vom Platform Windows SDK in den letzten Versionen etwas verändert haben. Hieß es bei Windows XP noch

WINBASEAPI
UINT
WINAPI
GetTempFileNameW(
    IN LPCWSTR lpPathName,
    IN LPCWSTR lpPrefixString,
    IN UINT uUnique,
    OUT LPWSTR lpTempFileName
    );

so schaut die Definition im Windows SDK für Server 2008 so aus:

WINBASEAPI
UINT
WINAPI
GetTempFileNameW(
    __in LPCWSTR lpPathName,
    __in LPCWSTR lpPrefixString,
    __in UINT uUnique,
    __out_ecount(MAX_PATH) LPWSTR lpTempFileName
    );

An den Funktionsparametern selbst hat sich natürlich nichts verändert, aber die neuen Präfixe fallen doch ins Auge. Anfangs habe ich mir dabei nicht viel gedacht, aber mittlerweile hat sich mir der tiefere Sinn der Änderungen erschlossen.

Alles hängt mit der Standard Annotation Language (SAL) zusammen. In Verbindung mit einem statischen Codeanalyse-Tool lassen sich so mögliche Programmierfehler schon beim Kompilieren ermitteln. Auch wenn sich ein Projekt unter höchster Warnstufe ohne Warnungen kompilieren lässt, so heißt dies noch lange nicht, dass alles sauber ablaufen muss.

Leider ist das statischen Codeanalyse-Tool den höherpreisigen Visual Studio-Versionen Team System und Team Edition for Developers vorbehalten. Die Team Edition for Developers kostet aber locker 5000 Euro mehr als die Professional Edition, was für den normalen Entwickler ziemlich unerschwinglich sein dürfte.

Abhilfe schafft hier das Windows SDK für Vista sowie das für Server 2008. Beide enthalten die vollständige Compilersammlung von Visual Studio 2005 bzw. Visual Studio 2008 samt Codeanalyse-Tool. Für die Codeanalyse sind die Dateien c1ast.dll, c1xxast.dll, mspft80.dll und mspft80ui.dll zuständig. Die ersten drei Dateien befinden sich unter VC\bin, die letzte enthält die englischsprachigen Ressourcen und ist unter VC\bin\1033 zu Hause.

Nachdem man die vier Dateien an den entsprechenden Ort kopiert hat, muss die Codeanalyse nur noch aktiviert werden. In der Team Edition for Developers gibt es dafür eine Seite in den Projekteigenschaften, in der Professional Edition muss man den Kommandoschalter /analyze unter Configuration Properties – C/C++ – Command Line manuell eintragen.

Was macht die Codeanalyse nun so interessant? Nehmen wir einfach mal die oben angesprochene Funktion GetTempFileNameW. Die Verwendung könnte so aussehen:

29: WCHAR szTempFileName[240];
30: GetTempFileNameW(L"C:\\", NULL, 1, szTempFileName);

Der Compiler hat hier nichts auszusetzen, selbst bei /W4 gibt es keine Warnungen. Aktiviert man aber die Codeanalyse, dann sieht man plötzlich folgende Warnhinweise:

: warning C6202: Buffer overrun for ’szTempFileName‘, which is possibly stack allocated, in call to ‚GetTempFileNameW‘: length ‚520‘ exceeds buffer size ‚480‘
:warning C6309: Argument ‚2‘ is null: this does not adhere to function specification of ‚GetTempFileNameW‘
: warning C6386: Buffer overrun: accessing ‚argument 4‘, the writable size is ‚480‘ bytes, but ‚520‘ bytes might be written: Lines: 29, 30
: warning C6387: ‚argument 2‘ might be ‚0‘: this does not adhere to the specification for the function ‚GetTempFileNameW‘: Lines: 29, 30

Anhand der Definition von GetTempFileNameW erkennt der Compiler, dass die Funktion als vierten Parameter einen Puffer von mindestens 260 Zeichen erwartet, der Programmierer aber aus unerklärlichen Gründen nur einen Puffer von 240 Zeichen bereitgestellt hat. Ist der gewünschte temporäre Dateiname nun länger als die zur Verfügung stehenden 240 Zeichen, dann führt dies zu einem sicheren Pufferüberlauf.

Der Grund für die zweite Warnung ist der zweite Funktionsparameter. __in legt fest, dass lpPrefixString ein gültiger und initialisierter Zeiger sein muss. Der Compiler erkennt, dass NULL nicht in diese Kategorie passt und weist uns darauf hin. NULL wäre nur gültig, wenn lpPrefixString stattdessen mit __in_opt gekennzeichnet sein würde.

Insgesamt hat die statische Codeanalyse über 130 verschiedene Warnhinweise in petto. Sie erkennt z.B., wenn HRESULT-Werte in booleschen Vergleichen verwendet werden:

CAtlFile file;
if (!file.Create(L"C:\\test.txt", GENERIC_READ, FILE_SHARE_READ, CREATE_ALWAYS))
{
//
}

oder wenn eine Funktion Variablen enthält, die unverhältnismäßig viel Platz auf dem Stack belegen:

WCHAR szTempFileName[32768];
GetTempFileNameW(L"C:\\", L"123", 1, szTempFileName);

Mich selbst haben die Möglichkeiten der statischen Codeanalyse mehr als begeistert. Wenn man sich die möglichen 138 Warnungen so anschaut, dann entdeckt man viele Sachen, die man gerne mal falsch macht und über die man auch schon das eine oder andere Mal gestolpert ist. In der nächsten Zeit werde ich daher meine Projekte Stück für Stück mit /analyze kompilieren und die angezeigten Warnungen abarbeiten. Im zweiten Schritt werden dann die eigenen Funktionen mit den SAL-Parametern versehen.

Ich musste gerade feststellen, dass sich das Windows SDK für Windows Server 2008 bei der Installation anders verhält als frühere Versionen und damit auch anders als erwartet. Bisher wurden die Compiler-Dateien immer in ein Verzeichnis unterhalb des SDK-Installationsordners installiert und das Visual Studio-Verzeichnis blieb unverändert.

Doch die Suche nach dem Compiler-Verzeichnis blieb diesmal erfolglos, obwohl ich die entsprechende Option beim Installationsdialog angekreuzt hatte. Auch eine Reparaturinstallation brachte das Verzeichnis nicht zum Erscheinen.

Aufklärung brachte ein Blick in das Visual Studio 2008-Verzeichnis. In diesem befanden sich plötzlich auch die IA64-Compiler, welche eigentlich kein Bestandteil von VS 2008 Professional sind. Ärgerlicherweise wurden aber auch alle von mir angepassten include- und lib-Dateien überschrieben, die für die angepasste Laufzeit benötigt werden. Zum Glück hatte ich noch eine Spiegelinstallation auf dem Laptop.

Also: Vorsicht bei der Installation des Windows SDK für Windows Server 2008, sofern man angepasste Dateien verwendet!

Am Wochenende hat Microsoft die deutschen Testversionen von Visual Studio 2008 veröffentlicht. Der Download der Professional-Version ist 3674 MiB groß, bei der Team Suite fließen 4158 MiB durch die Leitung. Beide Testversionen funktionieren 90 Tage.

Seit heute früh können sich MSDN-Abonnenten auch die deutsche Vollversion herunterladen. Angeboten werden die Professional mit 3674 MiB sowie die gesammelten Express-Versionen mit 3061 MiB. Vermutlich ist auch die Team Suite-Version verfügbar, das kann ich mangels Abo aber nicht überprüfen.