Komfortabler Dateimanager mit vielen Funktionen

Licht und Schatten

By Sven on 16.02.2010 - 12:40 in Visual Studio 2010

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:

Editor in VS 2010/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.

Es gibt 15 Kommentare zu diesem Beitrag

Trackback URL | RSS-Feed für Kommentare

  1. hanni sagt:

    Wie immer sehr interessant zu lesen wie es anderen mit VS ergeht. Hast MS schon angeschrieben? Vielleicht ist das auch nur einfach ein Fehler der RC?

  2. ujr sagt:

    Hallo,

    danke für diesen Erfahrungsbericht.
    Ich habe bisher nur Screenshots gesehen, aber mir kommt es so vor, als sei eine Menge Platz “verschwendet” an die dunkelblauen Rahmen. Oder ist es nur das ungewohnte Bild?
    Die verschwommene Schrift ist übrigens eine Eigenart von WPF, die schon oft kontrovers diskutiert wurde. Leider scheint es also mit WPF4 immer noch keine Abhilfe zu geben.

  3. Uwe sagt:

    Wie ist es denn mit der Performance, verglichen mit VS 2008? Schneller? Langsamer? Gleich?

  4. Sven sagt:

    @hanni: Ich denke, dass der RC schon ziemlich exakt der RTM entspricht. MS behebt deshalb sicher nur noch ganz böse Sachen.

    @ujr: Soviel überflüssigen Platz sehe ich gar nicht. Das Layout selbst und die neuen Farbkombinationen gefallen mir gut. Ich habe auch kein Problem damit, dass WPF ClearType verwendet, das macht VS2008 ja auch. Schlimm ist nur, dass schwarz eben nicht mehr schwarz ist. Möglicherweise hängt das auch mit meiner Hintergrundfarbe zusammen und es wirkt auf weißem Hintergrund nicht mehr ganz so extrem.

    @Uwe: Kann ich noch nicht viel dazu sagen. Bisher habe ich nur mit Samples herumgespielt und nicht mit richtigen Projekten.

  5. ujr sagt:

    Hallo Sven,
    WPF hat allerdings ein eigenes “ClearType” und verwendet nicht das des Betriebssystems (weil dies GDI basiert ist), s. z. B. http://social.msdn.microsoft.com/forums/en-US/wpf/thread/1c8d8627-a527-4d5e-8ae3-575867e7ea47/

  6. Andreas sagt:

    Kein WinSxS mehr? Super!!!

    Die Mergemodule waren auch echt grottig und diese bei jedem Update komplett neu zu erstellen, etwas aufwendig! Schön wäre es natürlich, wenn der BCGControlbar-Kram in einer eigenen DLL wäre (die man weglassen könnte).

    Über WPF muss man sich wohl selbst erst ein Bild machen, in der Beta war die ständige Größenänderung einiger “Fenster” etwas nervig. Werde es mir mal ansehen.

    Aber schon mal Danke für deinen ersten Eindruck.

  7. hanni sagt:

    Sven und wenn es mit dem SP1 oder in der 2012 Version kommt. Bin da der Ansicht das man ruhig mal informieren sollte weil dann wird es wenigstens zur Kenntnis genommen 😉

  8. Sven sagt:

    @ujr: Kann man das WPF-ClearType auch noch etwas anpassen? Beim Windows-ClearType geht dies ja.

    @hanni: Kann aber auch noch das eine oder andere Jahr dauern. Bei der ersten CTP von VS 2005 vor fast fünf Jahren habe ich MS über Connect mitgeteilt, dass sich im Eigenschaftsdialog eines Projekts auf einem deutschen System die Buttons für ‘Abbrechen’ und ‘Übernehmen’ überlappen. Gerade nochmal im VS 2010-RC nachgeschaut, jetzt passt der Abstand endlich.

    Wenn Du immer noch zweifelst, dann empfehle ich einen Eintrag aus Martins Blog:

    http://blog.m-ri.de/index.php/2007/05/03/fuer-was-ist-eigentlich-httpsconnectmicrosoftcomvisualstudiofeedback-noch-gut/

  9. ujr sagt:

    Hallo,

    im oben geposteten Link wird behauptet, dass WPF “ClearType” sich auf die selbe Weise konfigurieren lässt wie das OS-ClearType. Probiert habe ich das noch nicht.

    Was die Abbrechen/Übernehmen-Buttons angeht: den Fehler gibt’s in VS2008SP1 auch noch – scheint aber sehr vom Theme (XP mit Luna/Royal/Zune bzw. Vista) abhängig zu sein. Wahrscheinlich sind die Buttons nun aufgrund des Neudesigns “nebenbei” richtig positioniert worden.

  10. Sven sagt:

    Ich habe mal etwas mit den Windows-Einstellungen für ClearType gespielt. Diese haben in der Tat auch Einfluss auf die WPF-Einstellungen. Ein Seiteneffekt ist, dass die Erhöhung des Kontrasts in gleichem Maße auch außerhalb der WPF-Anwendungen sichtbar ist. Aber es ist auf jeden Fall schon mal eine Verbesserung. 🙂

    Bei den Buttons kann man sehen, dass der Übernehmen-Button in VS2010 nach rechts geschoben wurde. Die Position und Größe von OK/Abbrechen blieben unverändert.

  11. Deutschlehrer sagt:

    Gut zu wissen mit Cleartype. Danke für den Tip.

    Ach ja. Im deutschen gibt es keine Seiteneffekte. Nur Nebeneffekte.

  12. ujr sagt:

    Im Deutschen heißt es jetzt Tipp.

  13. Steve Holt! sagt:

    Bester Text den ich bisher zum neuen VS gelesen habe. Alles andere war irgendwie immer nur Marketing-Gefasel. Unschön, zu hören wie sie hier Programmierern unnötig Steine in den Weg werfen.

    Feedback kann schon ziemlich frustrierend sein. Windows 7 ist das erste Windows, wo ich tatsächlich Fehlerberichte abschicke. Ich habe irgendwie die Hoffnung noch nicht ganz aufgegeben. Aufhören mit Rückmeldungen würde ich aber dennoch nie. Damit was passiert braucht es eben immer die kritische Masse an Rückmeldungen. Oft stört eine Sache sehr viele Menschen, aber jeder davon denkt sich das sein alleiniges Feedback sowieso nichts bringt und lässt es. Deswegen gibt es, um beim Beispiel zu bleiben, bei Windows 7 auch mal einen Fix, weil sich dort eher genug Rückmeldungen ansammeln, dass Anwendung X abgestürzt ist. Aber wem erzähle ich das. 😉

    @ujr

    Exakt, genauso wie Stopp. 😀 Da lobe ich mir doch die original US-amerikanische Schreibweise. 😛

  14. Sascha sagt:

    > 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.

    Einfach die C++ / MFC Runtimes statisch ins Projekt linken und fertig. Somit brauchen keine DLLs mitgeliefert zu werden und die Anwendung ist portabel – was ist daran schwierig?
    Ein Nachteil des statischen Linkens besteht vielleicht, wenn ein Projekt aus mehreren EXE-Dateien besteht – da wird dann etwas Speicherplatz verschwendet, da der C++/MFC Runtime Code in jeder einzelnen EXE enthalten ist.

  15. Sven sagt:

    Und genau das wäre bei SpeedCommander der Fall. 34 von 43 Dateien im SC-Verzeichnis wären davon betroffen.

Top