Vor einer Woche hat Microsoft den Veröffentlichungskandidaten von Visual Studio 2010 zum Download freigegeben. Ursprünglich war ja für Mitte Februar schon die finale Version angekündigt. Aufgrund der doch recht schwachen Performance der Beta 2 hat man sich aber für eine kurze Verschiebung entschieden und möchte mit einer RC-Version sicherstellen, dass alle Probleme behoben sind.

IDE und Editor

Alle bisherigen Visual Studio-Entwicklungsumgebungen waren weitgehend in nativem Code geschrieben. Mit Visual Studio 2010 ändert sich das jetzt grundlegend, die neue IDE setzt größtenteils auf Windows Presentation Foundation (auch bekannt unter WPF) auf. Das schließt auch den Texteditor ein.

Beim ersten Bearbeiten einer Quellcodedatei kam mir die Schrift etwas blass vor. Die Farbeinstellungen von Visual Studio 2008 wurden beim ersten Start übernommen, so dass es eigentlich keine Unterschiede geben sollte. Auch ein Vergleich der Farbeinstellung im Einstellungsdialog zeigte, dass die Werte für die Textfarbe gleich sind (schwarz). Hier mal ein Screenshot mit beiden Darstellungen, die obere Hälfte zeigt VS 2010 und die untere VS 2008:

Ich weiß nicht, wie das andere empfinden – mir geht es auf die Augen.

Durch die Umstellung auf WPF ändert sich auch die gesamte Fensterstruktur in der IDE, da eine WPF-Anwendung weitgehend fensterlos daherkommt. Das werden einige AddIn-Entwickler zu spüren bekommen. Einer davon bin ich, mein geliebtes EasyTabs funktioniert nicht mehr und müsste neu geschrieben werden.

Class Wizard

Mit der neuen Version feiert ein Urgestein der VC-IDEs seine Auferstehung – der Class Wizard ist zurück. Die Umsetzung des Assistenten ist auf den ersten Blick gut gelungen, sie kommt für mich aber um einige Jahre zu spät. Mittlerweile habe ich mich nämlich daran gewöhnt, Überschreibungen und Bearbeitungsfunktionen für Nachrichten selbst im Editor einzugeben. So kann man die Funktionen gleich an der richtigen Stelle eintragen, wenn man eine gewisse Übersicht bevorzugt. Der Class Wizard hängt dagegen alles nacheinander als öffentliche Funktionen am Ende der Klassendefinition an. Hut ab, wer da am Ende noch den Überblick über die Klasse hat.

Sprache und Bibliotheken

An der C++-Sprachfront hat sich einiges getan. Der neue Compiler kann mit Lambda Expressions umgehen und  kennt Rvalue-Referenzen. Mit dem auto-Schlüsselwort erspart man sich die eine oder andere Typendeklaration. Im Moment habe ich noch keine Ahnung, was sich damit alles anstellen lässt. Bisher habe ich mich bei der Verwendung der C++-Standardbibliothek (STL) immer sehr zurückgehalten.

Auch bei der C/C++-Laufzeit und der ATL/MFC gibt es eine Menge Neuerungen. Die wohl wichtigste in der C++-Laufzeit ist die Concurrency Runtime, eine Klassenbibliothek, die das Erstellen von Multicore-Anwendungen erleichtern soll. Die neue MFC bietet direkte Unterstützung der Taskbar von Windows 7, inklusive Taskbar-Miniaturansichten für MDI-Anwendungen. Der schon in Windows Vista eingeführte Restart-Manager zieht endlich in die MFC ein. Eingebaut ist auch eine Unterstützung für Windows 7 Multitouch.

Verteilung der Dlls

Eine wesentliche Änderung betrifft die Verteilung der C/C++-Laufzeit und der MFC. Bis einschließlich Visual Studio 2003 wurden die Dlls immer nur in das Systemverzeichnis kopiert. Ab und zu sorgte das für Ärger, weil einige Softwareanbieter nicht mit Versionsinformationen umgehen konnten und bei der Installation auch mal eine neuere Version einer Dll mit ihren alten Version überschrieben. Das alles ist auch unter dem Namen Dll-Hölle bekannt.

Windows XP versprach Abhilfe und führte die Side-by-Side Manifeste ein. Jede Dll-Version wurde nun mit einem Manifest versehen und im WinSxS-Verzeichnis abgelegt. Der Anwendung wurde bei der Erstellung die benötigten Dlls eingeimpft. Ab Visual Studio 2005 wurden nun auch die C/C++-Laufzeit und die MFC nach diesem Schema verteilt. Doch die Praxis war nicht so gut wie die Theorie. Die Dlls mussten zwingend in das WinSxS-Verzeichnis installiert werden, portable Anwendungen waren nur unter erschwerten Bedingungen möglich. Besonders kritisch war es auch, wenn man versehentlich ein im DEBUG-Modus kompiliertes Modul in eine Release-Anwendung aufgenommen hatte. Der Windows-Programmlader beschwerte sich dann über eine fehlerhafte Anwendungskonfiguration und meinte damit eigentlich die fehlende C/C++-Laufzeit in der Debug-Version.

Diese Probleme sind anscheinend auch bei Microsoft nicht spurlos vorbeigegangen. Mit Visual Studio 2010 lässt man die Side-by-Side Manifeste wieder links liegen und kehrt in die Dll-Hölle zurück. Vermutlich ist dies das kleinere Übel, mir kann es nur recht sein.

Erstellung der MFC

Seit Visual C++ 1.5 waren die Makefiles für die MFC im Lieferumfang enthalten und man konnte sich die MFC so selbst kompilieren. Das war insbesondere bei Visual C++ 6 eine große Hilfe, weil die damalige MFC gerade mal Windows 98 unterstützte und mit den neuen Datei öffnen/speichern-Dialogen von Windows 2000 und Dateigrößen von mehr als 4 GiB ein wenig überfordert war. Als Visual Studio 2005 aktuell war und ich Visual C++ 6 immer noch bevorzugte, habe ich die MFC8 so angepasst, dass sie auch mit Visual C++ 6 verwendet werden konnten. Nicht zu vergessen auch die WinSxS-Hölle, der man durch eine Neukompilierung entrinnen konnte und die Möglichkeit, die für mich überflüssigen Erweiterungen der BCGControlbar loszuwerden.

Abgesehen davon habe ich die MFC intern auch etwas erweitert, um dem Anwender eine gezielte Sprachauswahl zu ermöglichen. Dazu kommt noch der eine oder andere Fix, z.B. um die Datei öffnen/speichern-Dialoge generell größenveränderbar zu machen. Dies alles ist Geschichte, wenn es nach Microsoft geht. Die MFC ist bei Visual Studio 2010 zwar weiter im Quellcode dabei, aber es fehlen die wichtigen Makefiles für die Erstellung und die .DEF-Dateien für die Exporte. Möglicherweise werden die MSBuild-Optionen später im Visual C++ Team-Blog veröffentlicht. Das gleiche gilt auch für die C/C++-Laufzeit, wobei hier neben den Makefiles noch viele Dateien fehlen, die früher nur als .obj-Dateien ausgeliefert wurden.

Fazit

Es fällt nicht leicht, ein Fazit zu ziehen. Die blasse Schrift und das in Zukunft fehlende EasyTabs machen es mir ziemlich schwer, mich in Visual Studio 2010 wohlzufühlen. Die neuen Möglichkeiten der C/C++-Laufzeit und der MFC locken natürlich, obwohl die fehlenden Makefiles der MFC schon ein ziemlicher Showstopper sind. Aber mal schauen, vielleicht kann man ja die Makefiles von Visual Studio 2008 recyclen.