Unter dem Titel Visual Studio Gallery betreibt Microsoft ein Repository für verschiedenste Tools, Controls und Templates, mit deren Hilfe man Visual Studio erweitern kann. Vielleicht ja kalter Kaffee für Sie, aber wenn Sie sich da noch nie umgeschaut haben, könnte es sich lohnen, das nachzuholen.

Die Vielfalt der angebotenen Dinge täuscht ein wenig: Wenn man links in der Sektion Visual Studio Versions diejenige Version anklickt, die man selbst konkret in Betrieb hat und die Anzeige damit filtert, fällt einiges weg. Und wenn man gleich darunter in der Sektion Cost Categories mit der Wahl von Free alles verschwinden lässt, was Geld kostet oder eine limitierte Probeversion darstellt, bleiben z.B. von total fast 500 Tools nur noch etwa 160 freie Tools für VS2008 übrig. Aber das ist allemal noch eine interessante Menge.

Als ich selbst heute diese Liste der kostenlosen Tools für VS2008 durchging, bin ich beim HyperAddin hängengeblieben. Damit ist es unter anderem möglich, in Kommentaren Links zu schreiben, die zu irgendeinem Symbol des Projekts führen, denen man folgen kann wie den „eingebauten“ URL-Links mit Hilfe von Ctrl + Mausklick.

Konkret sieht das so aus:

  public class HyperAddinDemo {
    public void Method1() {
    }

    public void Method2() {
      // Hinweis: macht nicht dasselbe wie code:HyperAddinDemo.Method1
    }
  }

Links zu beliebig setzbaren Ankerpunkten in irgendeinem File des Projekts statt zu Symbolen sind ebenso möglich.

Ich denke, ich werde das in Betrieb nehmen und schauen, ob solche Links wirklich so nützlich sind, wie ich nach ersten Tests vermute.

Eine Frage steht bei solchen Erweiterungen natürlich immer im Raum: Was passiert, wenn ich auf eine neue Version von Visual Studio wechsle? Wie die Visual Studio Gallery selbst demonstriert, können Addins durchaus spezifisch sein für bestimmte Versionen von Visual Studio; damit besteht die Gefahr, dass ich z.B. beim bevorstehenden Schritt auf VS2010 das gerade liebgewonnene HyperAddin bereits wieder verliere, falls der Autor nicht mitzieht.

Es muss wohl jeder selbst für sich entscheiden, wie er mit diesem Risiko umgehen will und wie er Nutzen jetzt gegen möglichen Verlust bei einem Wechsel von Visual Studio in der Zukunft gegeneinander verrechnet. Konkret bei diesem Addin hat mir in dieser Hinsicht gefallen, dass der Sourcecode zur Verfügung steht und ich mich damit wahrscheinlich selbst durchschlagen könnte bei einem Problem auf einer neuen Plattform.

Fast auf den Tag genau vor 1 Jahr habe ich in diesem Eintrag vom „unscharfen“ Text in WPF-basierten Applikationen geschrieben. Seither gehört das Wort unscharf zu den absoluten Top-Such-Begriffen, mit denen dieses Blog gefunden wird, was darauf schliessen lässt, dass die Sache einige Leute beschäftigt, wenn nicht sogar nervt.

Es sieht so aus, als wäre Microsoft unterwegs zu einer überraschenden Lösung für dieses Problem, die man als Bestandteil von Windows Vista und Windows 7 betrachten kann: Man macht einfach Text generell unscharf…

Windows 7 verwendet ClearType für Text per Default systemweit, mit nur wenigen Ausnahmen wie etwa der Shell, was eben zur angesprochenen leichten Unschärfe führt. Allerdings muss man sagen, dass Microsoft ClearType um einiges verbessert hat und auch ein eigenes Tuning-Tool dafür mitliefert, damit man auf seiner Hardware das Optimum betreffend Darstellung herausholen kann.

Es gibt in Windows 7 sogar eine etwas versteckte Option, mit der man ClearType ausschalten kann, die z.B. hier (für das englische Windows 7) beschrieben ist, aber so ganz will das nicht klappen: Vieles wird nach dem Ausschalten der Option Smooth edges of screen fonts zwar wieder pixel-scharf, aber Dinge wie die Anzeige der Uhrzeit, Tooltips oder gewisse Kolonnen-Überschriften im Explorer bleiben völlig unbeeindruckt bei der Verwendung von ClearType, und WPF-Applikationen wie etwa das neue Visual Studio 2010 sowieso.

Ich habe mich gefragt, ob die weitgehende Verwendung von ClearType auch damit zusammenhängt, dass Dinge wie der Explorer von Windows 7 als WPF-Applikationen neu geschrieben worden sind. Es ist häufig schwierig, Informationen darüber zu finden, wie genau Microsoft Windows-Interna implementiert; so auch in diesem Fall. Es scheint allerdings unter interessierten Leuten einen gewissen Konsens darüber zu geben, dass das Windows-7-GUI nicht in WPF implementiert sein kann, wie z.B. in einem Posting im Rahmen dieser Diskussion ausgeführt. WPF heisst managed code, der einen gewissen Geschwindigkeitsverlust mit sich bringen kann und für das Framework einiges an Speicher benötigt – beides Dinge, die Microsoft vermeiden musste, um Windows 7 gegenüber Vista deutlich abzuspecken und schneller zu machen, damit es z.B. Netbook-tauglich wird.

Ich denke nicht, dass man das als Votum gegen WPF deuten sollte, im Stile von „Ja, wenn nicht mal Microsoft selbst Dinge mit Hilfe von WPF implementiert…“. Normale Windows-Business-Applikationen sind nun mal nicht dasselbe wie Kern-Bestandteile von Betriebssystemen, wo ganz andere Bedingungen und Anforderungen die Wahl der Mittel erheblich einschränken.

In Word 2003 gibt es eine Dialogbox Dokumentvorlagen und Add-Ins, die noch nicht mitbekommen hat, dass Bildschirme heute mehr Auflösung bieten als VGA von Anno Domini 1987:

Dialogbox in Word 2003

So kommt es dann zum hier gezeigten Witz des „vollständigen Pfads“, der je nach Pfad eben gerade nicht vollständig angezeigt wird, weil schlicht der Platz dazu fehlt in der Breite der Dialogbox:

Vollständiger Pfad?

Auch wenn Word 2007 in dieser Hinsicht unterdessen dazugelernt hat, sehe ich heute mit Windows bzw. mit Windows-Programmen ein grosses Problem bei Forms aller Art, deren Grössen fix sind, mit recht kleinen Grössen notabene, um eben auch mit niedrigen Auflösungen klarzukommen. Ich schätze, dass selbst unter modernen Programmen nur etwa die Hälfte über Forms verfügt, deren Grösse man ändern kann und bei denen sich die Controls intelligent an eine neue Grösse anpassen.

Eine Zeit lang sah es ja so aus, als würde sich das Problem entschärfen, weil man als Programmierer bzw. als Designer von Forms im Laufe der Jahre von stetig grösseren Bildschirmen bei den Anwendern ausgehen durfte. So war es z.B. für die Megos sehr hilfreich, dass der Kanton Aargau um 2000 herum dafür sorgte, dass in allen Steuerämtern des Kantons Bildschirme mit mindestens 1024 mal 768 Pixeln zur Verfügung standen, so dass wir die Forms der Applikation VERANA (wie z.B. diese hier) mit dieser Annahme vergleichsweise grosszügig gestalten konnten, und deshalb irgendwelche komplexe Dynamik-Eigenschaften kein Thema waren.

Aber in letzter Zeit scheint sich das Problem wieder zu verschärfen, weil die Vielfalt unterschiedlicher Bildschirmgrössen zunimmt: Wohl ist der Trend zu grösseren Monitoren bei „normalen“ stationären PCs ungebrochen, aber mehr und mehr Leute arbeiten mit Notebooks, wo den Auflösungen natürliche Grenzen gesetzt sind. Günstige Netbooks kommen zudem zum Teil mit Auflösungen daher, die man schon fast als endgültig überwunden betrachtet hatte, und wer weiss, vielleicht gibt es bald für viele Applikationen die neue Anforderung, sie müssten auch auf Smartphones bedienbar sein, mit der erwähnten VGA-Auflösung aus der PC-Steinzeit!

Für mich stellt sich deshalb die Frage nach dynamischen Forms stärker denn je, was mich auch zu diesem Blog-Eintrag bewogen hat.

Es gibt in .NET bei den Windows Forms einige Unterstützung, die man als Programmierer nutzen kann, wenn man seine Forms „dynamisch“ betreffend Grösse machen will. Sie wissen, was ich meine: Eigenschaften wie Anchor, Dock und AutoSize bei Controls, und Container Controls wie z.B. das FlowLayoutPanel, welche ihre Kinder nach bestimmten Regeln neu anordnen können, wenn ihre Grösse ändert. Aber insgesamt würde ich sagen, dass man damit nicht allzu weit kommt, wenn Forms ein wenig komplexer werden.

Natürlich sind die Windows-Forms-Klassen flexibel genug, dass ich selber etwas programmieren kann, damit meine Forms dynamischer werden. Aber es ist doch eben gerade der Sinn eines Frameworks wie .NET, dass nicht jedermann ein so grundsätzliches Problem, mit dem man immer und überall konfrontiert ist, stets wieder neu selber lösen muss!

Als Microsoft begannt, WPF als ernstzunehmende Alternative zu Windows Forms zu positionieren, war ich deshalb sehr gespannt, ob sich die Firma in Bezug auf dynamische Forms etwas hat einfallen lassen, das deutlich über den Stand des mittlerweile 10 Jahre alten VB6 hinausgeht. So wie es aussieht, ist WPF in dieser Hinsicht eine Enttäuschung.

Wie sähe denn eine gute Standard-Lösung für dynamische Forms aus? Ich kann auch keine solche aus dem Hut zaubern, aber mir gehen Gedanken durch den Kopf, die auf einen beschreibenden Ansatz hinauslaufen. Wie wäre es, wenn man bei einem Control Bedingungen formulieren könnte, wie etwa die folgenden: „Control X in Höhe und Breite wachsen lassen, wenn die umgebenden Controls sich verschieben und das zulassen, aber nur bis zu einer Maximalbreite n, und auf alle Fälle nicht breiter als Control Y. Wenn sich unter Control Z mindestens m Millimeter Platz ergeben, dann Control X dorthin umplatzieren und an die Breite von Control Z angleichen.“

Interessant kann natürlich auch sein, was andere Leute machen, denn schliesslich bietet nicht nur Microsoft Werkzeuge an, mit denen man Forms designen kann. Insbesondere Qt scheint mir dabei einen Blick wert zu sein, weil Qt als Cross-Plattform-System von je her stärker als .NET mit Dingen wie unterschiedlichen System-Fonts und anders gezeichneten Controls konfrontiert war und damit klarkommen musste. Zudem kommen gerade jetzt zu den unterstützten Plattformen S60 für Smartphones und Maemo für Nokias „Surf Tabletts“ mit den erwähnten kleinen Auflösungen hinzu.

Ich habe erst begonnen, mich in Qt einzuarbeiten, um mich inspirieren zu lassen bei meiner Suche auf einer Lösung für dynamische Forms, aber etwas ist mir auf Anhieb ins Auge gestochen: die Spacer Controls, die man zwischen andere Controls setzen kann, die dort wie Federn wirken und die Controls soweit schieben, wie sie können:

Spacer Controls in Qt

Vielleicht bringt das gegenüber Docking plus Anchoring nur wenig mehr an grundsätzlich neuen Möglichkeiten, aber mir scheinen diese „Federn“ und ihr Verhalten etwas zu sein, mit dem ich intuitiv sofort klarkomme – für mich eine Eigenschaft eines wirklich guten Ansatzes.

Als ich vor einiger Zeit begann, mit der PowerShell zu arbeiten, vermisste ich eine Directory History, also eine Liste mit den zuletzt besuchten Directories und darauf basierend dann eine einfache Möglichkeit, wieder in eine dieser Directories zurückzukehren. Wie man bei Microsoft im Kapitel Managing Current Location der PowerShell-Doku sieht, gibt es zwar einen Stack mit Hilfe von Push-Location und Pop-Location, aber das ist weder automatisch noch besonders praktisch.

Per Google fand ich relativ schnell heraus, dass die PowerShell Community Extensions unter vielen anderen Dingen einen cd-Befehl enthalten, der eine History führt, aber alleine deswegen diese Extensions zu installieren erschien mir als Overkill.

Da cd nur ein Alias ist, kann man diesen Alias relativ leicht ersetzen und das Führen einer Liste besuchter Directories anhängen, wie man es z.B. hier sieht. Aber das gefiel mir auch nicht besonders, denn ich wollte mir nicht Sorgen darüber machen müssen, ob die aktuelle Directory irgendwie an dieser neuen cd-Funktion vorbei wechseln kann, z.B. durch direkte Verwendung von Set-Location in einem Script, und die History dann „Löcher“ bekommt.

Schliesslich hatte ich eine Idee, die zwar etwas hack-mässig ist, dafür aber einfach und zuverlässig funktioniert: Im Profile-Script gibt es eine Function Prompt, welche dazu da ist, wie der Name schon sagt, jeweils den Prompt am Anfang der Kommandozeile auszugeben. (Einige schöne Ideen, was man damit alles machen kann, findet man z.B. hier.) Aber wer sagt denn, dass man in diesem Script nur Ausgaben machen darf? Ebensogut kann man nebenbei beobachten, in welcher Directory man neuerdings gelandet ist, und so auf einfache Weise eine zuverlässige History führen!

Schon vor einiger Zeit hat Microsoft angekündigt, dass Visual Studio 2010 einen neuen, speziellen Debugger namens Historical Debugger enthalten wird. Man findet z.B. hier eine Ankündigung aus dem Oktober 2008:

Are you tired of constantly setting breakpoints to hone in on a pesky bug? How would you like to be able to step „back in time“ through your debugger? The Historical Debugger in Visual Studio Team System 2010 promises to revolutionize your debugging experience.

Ich sagte mir, na das ist doch mal was Interessantes: Irgendwie rückwärts durch ein Programm debuggen? Weil ich für Revolutionen immer zu haben bin und als „Systemprogrammierer“ einfach wissen muss, wie man einen Debugger implementiert, der so etwas leistet, bin ich der Sache heute auf den Grund gegangen und kann nun berichten, worum es geht.

Zunächst musste ich eine Hürde aus dem Weg räumen: Der Historical Debugger ist tatsächlich nur im Visual Studio Team System 2010 verfügbar, das „normale“ Visual Studio ohne TS, das ich mir zuerst testweise installiert hatte, enthält ihn nicht. Man findet die VS2010-TS-Preview als ISO-Download hier.

Der Witz an der Sache ist der folgende: Der Historical Debugger schreibt selbständig zu bestimmten Zeitpunkten während der Programmausführung ein Log mit Informationen über den Zustand des Programms zum jeweiligen Zeitpunkt. Der angepriesene „Schritt zurück in der Zeit“ besteht darin, nach einem Stopp des Programms aus der Debug History, d.h. der Liste der Zeitpunkte, einen Eintrag auszuwählen und sich im Debugger den Zustand des Programms anzuschauen, wie er damals war.

Das kann natürlich – im Prinzip – ganz nützlich sein: Hat man z.B. einen Breakpoint erreicht und stellt fest, dass eine Variable einen falschen Wert aufweist, muss man nun nicht mehr mit dem Debugging von vorne beginnen und sich vorsichtig an den Zeitpunkt heranpirschen, wo der falsche Wert zum ersten Mal auftaucht, sondern kann bequem und entspannt die Debug History verwenden, um den Zeitpunkt zu finden oder mindestens stark einzugrenzen, wo die Sache aus dem Ruder läuft.

Man kann in 2 Stufen wählen, wie die Zeitpunkte bestimmt werden sollen: Log schreiben entweder bei „wichtigen Systemereignissen“ oder bei solchen Ereignissen plus bei jedem Methoden-Aufruf. Man kann hier erahnen, dass die Sache Potential hat auszuufern, denn Methoden-Aufrufe können ja sehr zahlreich sein.

Ins Log geschrieben werden der Call Stack zum Zeitpunkt und Variablen-Werte zum Zeitpunkt, wobei man bei Objekten nur noch das Resultat von ToString sieht, aber keinen Zugriff mehr bekommt auf die einzelnen Komponenten.

Ein paar Screenshots hierzu findet man im Blog Dariusz quatscht hier.

Meiner Meinung nach ist das ganz hübsch, aber ob es für eine Revolution reicht, ist fraglich. Insbesondere die doch sehr eingeschränkte historische Sicht auf Variablen-Werte enttäuscht. Mir ist schon klar, dass es schlicht unmöglich ist, zu Hunderten von Zeitpunkten den gesamten Heap ins Log zu schreiben, damit ich auch nachträglich noch Objekte mit all ihren Details anschauen kann, aber hey, es hätte ja sein können, dass jemand mit Hilfe einer genialen Idee ein Log implementiert hat, das viele Details mit praktikablem Aufwand speichern kann, z.B. mit einer Heap-Differenzen-Methode…

Was haben andere so gemacht in Sachen Debugger mit Historie? Hier ist von einem experimentellen Java-Debugger die Rede, der vor ein paar Jahren implementiert wurde und der offenbar alle Variablen-Zuweisungen während eines Programmlaufs protokolliert, indem er sich in die Pseudocode-Ausführung der JVM einklinkt. Er nennt sich denn auch treffend Omniscient Debugger („allwissender Debugger“) und erlaubt offenbar die volle Sicht zu einem beliebigen Zeitpunkt.

In einer PDF-Datei, welche den Debugger genauer beschreibt, findet sich die Information, dass Apache Ant etwa 24 Millionen Variablen-Zuweisungen macht, während das Tool seine eigene Kompilation steuert. Das sind eine ganze Menge, aber nicht so viele, dass sie den Ansatz an sich gleich zu Fall bringen.

VMWare hat etwas im Angebot, das die Firma Replay Debugging nennt, beschrieben auf der Website hier. Unterstützt wird Debugging für C/C++, wie man im Artikel hier nachlesen kann. Das ganze funktioniert mit Hilfe der Virtual Machine, wo man natürlich wie bei der JVM eine zentrale Stelle hat, wo man sich einklinken kann, um zu protokollieren, was läuft. Das Debugging, sprich der Blick auf das Log findet statt in einem Visual Studio, das um ein VMWare-Plugin ergänzt wurde.

Anhand der Beschreibung vermute ich, dass komplett protokolliert wird und man so in einzelnen Schritten vorwärts und sogar rückwärts durch das Programm gehen kann. Die Suche nach dem Punkt im Programm, wo eine Datenstruktur „zerstört“ wird, finde man so: Zeitpunkt finden, wo sie falsch ist, dann Programm „rückwärts laufen lassen“ mit Daten-Breakpoint auf der Struktur und einfach auf den Break durch Veränderung warten.

Hier meldet sich natürlich wieder meine Neugier, die mich veranlasst hat, überhaupt erst den Historical Debugger von Microsoft anzuschauen und die sich nun fragt: Wie macht VMWare das? Ich vermute, dass die komplette Abfolge aller CPU-Befehle, welche das Programm ausführte, der zentrale Bestandteil des Logs ist, und dass das „Debugging“ darin besteht, mit Hilfe der Virtual Machine das Programm irgendwie entlang dieser Abfolge zu führen, vielleicht gestützt auf Komplett-Speicherabzüge in gewissen Zeitabständen.

Und ich vermute ebenfalls, dass die Sache derart auf die Ausführung direkter CPU-Anweisungen zentriert ist, dass die Ausdehnung des Prinzips auf C# mit seinem JIT-Compiler eine schwierige bis unmögliche Sache werden dürfte.

Die Programme der Megos sind heute im Prinzip sehr schnell, denn sie basieren auf C++-Code, arbeiten nicht exzessive mit dynamisch alloziertem Speicher und setzen direkt auf dem WIN32 API auf. Da stellt sich die Frage, wie es mit der Geschwindigkeit wohl aussehen wird, wenn wir dereinst diese Programme ablösen werden durch solche, die in C# geschrieben sind, wo schon der kleinste String ein volles Objekt ist und man in Form des .NET Frameworks eine ganze Menge Code zwischen sich und dem WIN32 API hat?

Um hier etwas Klarheit zu schaffen, habe ich mich heute erstmal schlau gemacht betreffend folgender vereinfachter Frage: Wenn man Code hat, der in etwa dasselbe tut, einmal in C++, und einmal in C#, ist dann der C#-Code per se langsamer, und wenn ja, um wieviel etwa?

Es hat sich herausgestellt, dass diese Frage nicht ganz einfach zu beantworten ist, denn Zeitmessungen haben so ihre Tücken. Ich habe z.B. in einem Forum Postings von jemandem gelesen, der versucht hat, die relative Geschwindigkeit dieser beiden Programmiersprachen (bzw. deren Implementationen auf Windows, wie sie heute sind) mit Hilfe kleiner Schleifen zu vergleichen, und zurückmeldete, die C++-Version sei 28000 Mal so schnell wie die C#-Version. Was war passiert? Der C++-Compiler war so schlau zu erkennen, dass eine zeitfressende Anweisung innerhalb der Schleife von der Schleife unabhängig war und hat sie als Optimierung aus der Schleife herausgenommen…

C#-Source-Code wird vom C#-Compiler übersetzt zu CIL (Common Intermediate Language), früher auch MSIL (Microsoft Intermediate Language) genannt, einem prozessorunabhängigen Bytecode, wie man z.B. in der Wikipedia hier nachlesen kann. Dieser wird dann üblicherweise bei der ersten Ausführung des Codes per JIT (Just in Time) Compiler quasi „fliegend“ in direkte Prozessoranweisungen übersetzt und so schliesslich ausgeführt. Ob diese Übersetzung flüchtig ist oder dauerhaft abgespeichert wird, so dass später bei einer erneuten Programmausführung der Übersetzungsschritt gespart werden kann, hängt von verschiedenen Faktoren ab.

Kann es hier unter Umständen Geschwindigkeitsprobleme geben? Interpretiert man Bytecode statt direkt Prozessoranweisungen auszuführen, ist das schliesslich zwangsweise um einige Faktoren langsamer. Hatte nicht Java, das ebenfalls auf einem Bytecode basiert, vor Jahren zum Teil arge Geschwindigkeitsprobleme, bevor die HotSpot-JVM mit einem JIT-Compiler eingeführt wurde? Bei meinen Abklärungen heute erlebte ich diesbezüglich eine kleine Überraschung: Die Microsoft CLR scheint gar keinen Interpreter für CIL zu beinhalten, es wird nie interpretiert, sondern vor der Ausführung immer alles JIT-compiliert! (Details hierzu z.B. hier.) Also kann es hier keinen prinzipiellen Geschwindigkeitsverlust geben.

Das heisst nicht, dass keine CIL-Interpreter existieren: Mono hat zumindest in der Anfangsphase mit einem Interpreter gearbeitet, bevor ein JIT-Compiler zur Verfügung stand, und es gibt Dinge wie Dot Net Anywhere, einem CIL-Interpreter für Kleinstcomputer. Aber zumindest auf Windows lauert kein solcher und wartet auf Gelegenheiten, Performance zu vernichten.

Geschwindigkeitsunterschiede können sich auch durch Laufzeitprüfungen ergeben: C# überwacht normalerweise jeden einzelnen Array-Zugriff auf einen gültigen Index, während C++ das normalerweise nicht tut. In einem kleinen, synthetischen Testprogramm mit einer Schleife um Array-Zugriffe herum können sich hier schon einmal signifikante Unterschiede ergeben, aber ehrlich, in welchem Programm aus dem richtigen Leben wird schon so ein grosser Teil der Rechenzeit verbracht, und wer wollte allen Ernstes heute noch auf Laufzeitprüfungen verzichten?

Interessanterweise gibt es auch in C# Ansätze für Optimierungen, wenn man denn einmal ein Programmstück hat, das von Array-Zugriffen absolut dominiert wird. Im bereits erwähnten Thread finden sich folgende informative Code-Schnippsel:

Code A:

int[] arry = new int[20000];
for (int index = 0; index < 20000; ++index) {
  total += arry[index];
}

Code B:

int[] arry = new int[20000];
for (int index = 0; index < arry.Length; ++index) {
   total += arry[index];
}

Code C:

int[] arry = new int[20000];
foreach (int element in arry) {
  total += element;
}

Code B sei 20% schneller als Code A, weil durch die Verwendung von arry.Length der Compiler mitbekommt, dass er auf Bereichsprüfungen verzichten darf (wozu er wohl im Beispiel A nicht schlau genug ist), und Code C sei sogar 50% schneller als Code A, weil es offenbar foreach schafft, einen internen Index schneller durchzuzählen als das ein Programm explizit kann, und weil natürlich ebenfalls Bereichsprüfungen wegfallen.

Solche Tipps und noch viele mehr findet man offenbar in einem schlauen Buch namens Effective C#. Microsofts C# Programming Guide hat ebenfalls Informationen über Optimierungen, zu finden hier, und generelle Informationen darüber, was in Managed Code wie teuer ist, hier. Und wer einmal ganz tief in die CLR und ihre Objekt-Verwaltung hineinschauen möchte, um Ansätze für Optimierungen zu finden, kann das mit Hilfe der Informationen hier tun.

Zusammenfassend kann ich sagen, nirgends Hinweise darauf gefunden zu haben, dass man sich schon alleine durch die Verwendung von C# als Sprache generelle Performance-Probleme einhandelt, weil C# eben „langsam“ ist. Schätzungen, die ich angetroffen habe, gehen davon aus, dass im allgemeinen C#-Code 80% bis 90% der Performance von C++-Code erreicht. Das dürfte zu verkraften sein!

Als ich vor einiger Zeit ernsthaft mit Visual Studio und .NET/C# zu arbeiten begann, verglich ich diese Programmierumgebung ganz automatisch mit dem vor über 10 Jahren erschienenen VB6, mit dem ich vor allem durch eine privat damit gebaute Shareware sehr gut vertraut war.

Bei diesen beiden Systemen sind nur wenige Dinge exakt gleich, schon alleine wegen C# anstelle von BASIC als Sprache. Aber trotzdem hatte ich immer das Gefühl einer grossen Vertrautheit, den Eindruck einer weitgehenden Übereinstimmung bezüglich der grundlegenden Philosophie: Überall sah ich quasi den „Geist“ von VB6 durchschimmern.

Was mich aber noch viel mehr beeindruckte, und auch immer stärker, je genauer ich Visual Studio und .NET kennenlernte, war die folgende Geschichte: Im Gegensatz zum Nachfolger ist VB6 geradezu ein Winzling, weist aber trotz seiner bescheidenen Grösse (und trotz seines Alters) eine erstaunliche Menge der wichtigsten technologischen „Errungenschaften“ bereits auf.

Dinge wie Garbage Collection, IntelliSense im Editor, grafischer Form-Designer, hervorragendes Laufzeit-Debugging inklusive Watches und Immediate-Fenster, Code-Änderungen während das Programm läuft, mächtige String-Klasse, Kompilieren zu Native Code, Klassen inklusive Late Binding beim Aufruf von Objekt-Methoden, alles schon drin in diesem System von 1998, in einem Laufzeitsystem von nicht mal 3 MB und einer IDE von absolut lächerlichen 15 MB.

Natürlich könnte ich problemlos eine noch längere Liste von Eigenschaften aufzählen, die VB6 nicht hatte, ohne die man aber im Jahre 2009 zum Entwickeln von Software gar nicht anzutreten braucht.

Es geht mir um etwas Anderes: Der Vergleich VB6 versus Visual Studio 2010, C# und .NET 3.5 ist für mich mittlerweile eines der besten Beispiele, die ich persönlich kenne, um die 80%/20%-Regel zu illustrieren: Ja, das moderne System kann mehr als das gute alte VB6, aber man sehe sich mal an, wieviele der wirklich wichtigen, zentralen Eigenschaften VB6 bereits aufweist (die „80%“ in besagter Regel), erreicht mit vergleichsweise bescheidenem Aufwand (den „20%“). Oder umgekehrt: Ja, das moderne System ist überlegen, aber man sehe sich mal an, mit welch gigantischen Aufwand gewisse Verbesserungen erkauft werden mussten.

Natürlich kann ich als reiner Anwender von Visual Studio und .NET das Resultat geniessen, denn Microsoft trieb ja quasi für mich den grossen Aufwand, nicht ich. Und einen modernen Rechner bringen auch grosse IDEs und Laufzeitsysteme nicht ins Schwitzen.

Aber wenn ich selber etwas baue, tue ich gut daran, immer mal wieder an die 80%/20%-Regel zu denken und diese zu beherzigen. Mir persönlich fällt das nicht schwer, mit einem etwas nostalgischen Blick zurück zu VB6 dann und wann, zu dem ich z.B. Gelegenheit habe, wenn mein PC die Visual-Studio-IDE mit viel Festplatten-Aktivität in den Speicher wuchtet und diese riesige Maschine anwirft…

Etwas über ein Jahr ist es her, seit ich mit einem Eintrag über die Microsoft TechDays 2008 diesen Blog eröffnen durfte. Letzte Woche war ich nun an den TechDays 2009, dieses Mal im Kursaal in Bern.

Es war eine gut besuchte, professionell durchgeführte und solide Veranstaltung. Wie schon letztes Jahr waren es für mich gut investierte 2 Tage, um zu erspüren, wo die Reise hingeht mit Microsoft und den Technologien dieser Firma.

Die für die Megos vielleicht wichtigste Information, die ich mitgenommen habe: WPF ist jetzt einsatzfähig. Dies wurde klar anhand der Preisverleihung für den .NET Swiss Innovation Award, wo eine WPF- und 2 Silverlight-Applikationen prämiert worden sind – alle 3 nicht-triviale, real existierende Applikationen, offenbar reif für den produktiven Einsatz. (Ein paar Details zum Award und den Gewinnern findet man in einem Infoweek-Artikle hier.) Auch der Stand von WPF plus entsprechender Tools ist mittlerweile um Längen besser als noch vor zwei Jahren oder so, wo Microsoft vorschlug, WPF-Applikationen ohne ein DataGrid-Control und ohne IntelliSense für XAML zu entwickeln…

Eine weitere interessante, in einem gut gemachten Vortrag präsentierte Sache sind die Parallel Extensions, mit deren Hilfe man für seine Programme unter .NET 4.0 auf relativ einfache Weise mehrere Cores bzw. Prozessoren wird nutzen können. Zunächst schien mir die Sache etwas überspitzt formuliert ein wenig paradox: Da baut man in der Form des .NET-Frameworks zuerst erst ein System, das mit seinem Pseudocode-basierten Ansatz, Garbage Collecting, aufwendigen Laufzeit-Informationen für Reflection usw. ziemlich gut geeignet ist, um Prozessorleistung abzufackeln, und dann geht man hin und baut eine Erweiterung, um das sogar noch mit mehr als einem Core gleichzeitig zu tun.

Aber es macht schon einen gewissen Sinn: Dank JIT-Compilierung und mächtigen Prozessoren spielt der .NET-Overhead mit der Zeit eine immer kleinere Rolle, aber wie man die laufend grösser werdende Zahl an Cores einfach und sinnvoll nutzen kann, wird wohl eine der grossen Fragen der Zukunft sein, und zwar eine, die sich als ziemlich harte Nuss erweisen dürfte.

Zudem sieht man, dass es auch klare Vorteile hat, sich mit dem .NET Framework auf einer relativ hohen Abstraktions-Ebene bewegen zu können: Microsoft hat es in der Hand, seine .NET-Sprachen geeignet um neue Sprachkonstrukte für paralleles Programmieren zu erweitern, und das .NET Framework ist ein geeignetes System, um möglichst viele der „schmutzigen“ Details vom Entwickler fernzuhalten und gewissermassen „hinter den Kulissen zu verstecken“.

Mehr zu diesem Thema find man auf der MSDN-Website hier.

Wie letztes Jahr besuchte ich mit grossem Genuss zwei Vorträge von Sascha P. Corti. Microsoft Schweiz soll gut Acht geben auf diesen Mann, den sollten sie unbedingt behalten.

Der für mich ganz persönlich absurdeste Moment dieser TechDays war, als stolz die Out of Browser genannte neue Fähigkeit der kommenden Version 3 von Silverlight präsentiert wurde: Damit ist es möglich, entsprechend vorbereitete Silverlight-3-Applikationen lokal zu installieren und dann komplett ausserhalb des Browsers laufen zu lassen. (Technische Details findet man z.B. hier).

Ohne Zweifel technisch gesehen eine beeindruckende Leistung, an der die Jungs und Mädels in Redmond wohl hart gearbeitet haben, um sie zu vollbringen. Aber warum fand ich das in gewisser Weise absurd? Lassen Sie es mich mit den Worten eines hypothetischen, fanatischen Web-2.0-Fans einmal so formulieren: „Wow! Ich dachte immer, man braucht einen Browser, um Applikationen laufen zu lassen. Jetzt geht das ja sogar ohne Browser!“. Ja, ja, wer hätte das gedacht, Applikationen, die lokal auf einem PC laufen.

Ich arbeite nun schon eine ganze Weile mit der Powershell in der 2.0 CTP Version. Ich bin ganz zufrieden damit und kann eigentlich jedem nur empfehlen, sie einmal auszuprobieren.

Lustig ist, was mir mittlerweile am besten daran gefällt und worauf ich nicht mehr verzichten möchte: Die Powershell erlaubt es mir, in Filenamen den normalen Slash „/“ anstelle des Backslash „\“ zu verwenden.

Hinter dem Backslash als Trennzeichen in Dateinamen in Windows steckt eine ganz interessante Geschichte, die ich hier erwähnen möchte für Leute, die sie noch nicht kennen, auch wenn sie wenig mit .NET zu tun hat:

DOS 1.0 war eigentlich ein von Microsoft eingekauftes Betriebssystem namens QDOS, das in vielen Aspekten grosse Ähnlichkeit hatte mit CP/M. CP/M war ein Betriebssystem, das nur Laufwerksbuchstaben und Dateinamen, aber keine Ordner bzw. Subdirectories kannte. Für die Schalter bzw. Switches seiner Tools verwendete es den normalen Slash „/“ als Einleitungszeichen – eine Konvention, welche DOS 1.0 übernahm.

Als dann DOS 2.0 eine anständige hierarchische Dateiverwaltung bekommen sollte, war die von UNIX her naheliegende Verwendung von „/“ für die Dateinamen durch eben diese Verwendung für Schalter gewissermassen blockiert, worauf Microsoft auf das Nächstbeste d.h. auf den Backslash auswich.

Rückblickend kann man wohl sagen, dass Microsoft damals in den sauren Apfel hätte beissen und trotzdem den Slash verwenden sollen, auch wenn dies bedeutet hätte, eine Menge eigener und fremder Kommandozeilen-basierter Programme anpassen zu müssen.

Es gibt bei der Geschichte vom Backslash jede Menge Details, wie etwa das folgende: Die Microsoft-Programmierer selbst waren durch die Verwendung von XENIX, der damaligen Microsoft’schen UNIX-Variante, bereits an den Slash gewohnt und fanden den Backslash gar nicht lustig. Sie programmierten deshalb eine „geheime“ Option namens SWITCHAR für die CONFIG.SYS, mit der man das Zeichen für Schalter auf ein anderes Zeichen als „/“ umdefinieren konnte, wonach der normale Slash in Dateinamen zulässig wurde.

(Ich bin schon so lange im Geschäft, dass ich diese Option selbst noch verwendet habe, auf einem WANG PC; ich frage mich jetzt nur, wie ich eigentlich davon erfahren hatte damals…)

Eine ausführliche Version der Geschichte findet man hier, die Geschichte des Zeichens „\“ selbst hier.

Windows akzeptiert übrigens in Filenamen bis heute sowohl Backslash wie auch Slash, auch wenn es bei Aufbereitungen und Abfragen von Dateinamen konsequent auf Backslash wandelt. Folgende .NET/C#-Zeile ist vollkommen ok und funktioniert:

      FileInfo f = new FileInfo("C:/Work/Backslash/Program.cs");

IntelliSense in Visual Studio ist eine wunderbare Sache, die das Programmieren ungemein erleichtert. Eigentlich sollte heutzutage niemand mehr in einer Umgebung programmieren müssen, wo kein in etwa gleichwertiges Feature zur Verfügung steht. Trotzdem sahen wir ein ernstzunehmendes Problem damit, als wir hier in der Megos ernsthaft damit begannen, unsere neues Programmierwerkzeug Triton in C# zu implementieren.

IntelliSense scheint seine Listen immer stur alphabetisch zu sortieren und immer alles aufzulisten, ohne Filtermöglichkeiten. Das kann dan zu einem Problem werden, wenn man Klassen erweitert, die bereits eine Menge Members haben, und dann in der IntelliSense-Liste seine „eigenen“ Members (d.h. diejenigen der Erweiterung) kaum mehr findet. Je nach Art der Klassen benötigt man beim Implementieren bevorzugt eben diese eigenen Members, was das Ganze dann etwas mühsam macht.

Unsere Überlegungen zeigten uns, dass sich die Sache zuspitzt, wenn man Klassen für den Datenbank-Zugriff generiert, wo für jede Kolonne in einer Tabelle eine Property definiert wird, die sich dann zu all den Members der Zugriffs-Basisklasse gesellt und unter diesen irgendwie unterzugehen droht, obwohl sie doch zum eigentlichen „Witz“ der generierten Klasse gehört.

Man kann das bereits bei Visual-Studio-eigenen typed datasets beobachten: Eine Tabellen-Zugriffs-Klasse wird von System.Data.TypedTableBase abgeleitet, einer Klasse mit geschätzten etwa 100 Members. Eine Kolonne TitelKurs wird zu einer Property namens TitelKursColumn und wird von IntelliSense unter T eingeordnet; eine Kolonne WährungsKurs wird zu WährungsKursColumn und taucht dann in der Liste unter W und damit an einem ganz anderen Ort auf. Dieses Verhalten verunmöglicht es praktisch, sich per IntelliSense einen schnellen Überblick über alle Kolonnen zu verschaffen – aber wo ausser da soll denn dieser Überblick herkommen?

Es war schnell klar, dass es bei Visual Studio und IntelliSense, so wie jetzt implementiert, nur ein einziges „Rädchen“ gibt, an dem man überhaupt drehen kann, wenn man dieses Problem irgendwie lösen will: Will man Members zusammen sehen in einer IntelliSense-Liste, so müssen sie eben entsprechend heissen, d.h. alle mit irgendeinem Präfix beginnen.

Sie werden als geneigter Leser vielleicht schon ahnen, dass dieser Blog-Eintrag hier geradewegs auf ein Dilemma zumarschiert: Von Namenspräfixen wird in .NET und C# eigentlich abgeraten; verwendet man sie trotzdem, stecken einen gewisse Leute schnell einmal in die Schublade „Ewiggestrige“, die reserviert ist für Leute, die von ihren alten Gewohnheiten nicht lassen können und auch nicht verstanden haben, dass man heutzutage nur noch „natürliche“ Namen vergibt, weil man – eben gerade durch Features moderner IDEs wie z.B. IntelliSense – nicht mehr darauf angewiesen ist, vom Namen eines Dings irgendwelche Meta-Information ablesen zu können.

Aber wie gesagt, hier geht es nicht darum, sondern um eine Lösung für ein kleines, aber sehr lästiges Problem mit IntelliSense.

Wir sahen das Ganze als Wahl zwischen zwei Übeln: 1) einen Teil der Namen mit Hilfe von Präfixen verunstalten, aber damit den Nutzen von IntelliSense aufwerten, oder 2) den Empfehlungen und der Mehrheit der C#-Programmierer folgen, aber sich mit Situationen abfinden, in denen IntelliSense wenig hilft, obwohl es gerade da sehr nützlich wäre.

Nach einigem Hin und Her entschieden wir uns für das Übel 1). Wir wählten z.B. für die Properties unserer eigenen Klassen in Triton den Einbuchstaben-Präfix z, weil eine Abklärung ergab, dass nur wenige .NET-Klassen bereits Properties haben, mit mit Z beginnen, und damit diese Properties nicht nur zusammen angezeigt werden in einer IntelliSense-Liste, sondern auch noch herausstechen.

Seit dieser Entscheidung haben wir eine rechte Menge Code gemäss diesen Präfix-Konventionen erzeugt, und es ist eine erste Beurteilung des Erreichten möglich. Der gewünschte Effekt bei IntelliSense hat sich eingestellt: Man behält so tatsächlich ohne Probleme den Überblick über die eigenen Dinge im Gegensatz zu den „fremden“ Dingen des Frameworks. Aber hübsch sieht es irgendwie nicht aus, und eine richtige Gewöhnung an unsere mit Präfixen dekorierten Namen will sich eigentlich auch nicht einstellen.

Für jemanden, der sich im .NET-Framework wirklich gut auskennt, gäbe es vielleicht eine Wahlmöglichkeit 3), welche das Dilemma umgeht: ein Add-In programmieren, welches neben der IntelliSense-Liste eine zweite, entsprechend eingeschränkte Liste implementiert. Aber ganz soweit sind wir in der Megos noch nicht…