Ein etwas nostalgischer Blick zurück

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…

Und wieder mal TechDays

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.

Die vielen Implementationen von .NET

Hat man sich erst mal mit Hilfe einer virtuellen Maschine im Prinzip von Betriebssystem und CPU-Architektur gelöst, wie das ja bei .NET und der CLR der Fall ist, ist man frei, diese virtuelle Maschine für ganz unterschiedliche Umgebungen zu implementieren. Und obwohl .NET noch ziemlich jung ist, kommen schon eine ganze Reihe von Implementationen zusammen. Ich habe mir für dieses Posting einmal einen aktuellen Überblick verschafft (allerdings ohne aufzuführen, welche Komponenten aus dem umfangreichen .NET-Technologie-“Baukasten“ denn genau wo zur Verfügung stehen):

Die allseits bekannte „Mutter“ aller .NET-Implementationen und dementsprechend relativ uninteressant für diese Auflistung ist diejenige von Microsoft selbst für die verschiedenen Windows-Varianten, die hier zu Hause ist.

Eine Spur interessanter ist das .NET Compact Framework, ebenfalls von Microsoft selbst, das auf PDAs und Smartphones mit Windows Mobile läuft. Interessant, wie viel vom „grossen“ Bruder es in die Kompakt-Variante schafft.

Es geht aber noch kleiner als Smartphones: Mit dem .NET Micro Framework versucht Microsoft, selbst Geräte mit stark limitiertem Speicher abzudecken, wie z.B. ihre experimentelle SPOT Armbanduhr zeigt.

Es ist mir nicht klar, ob die Shared Source Common Language Infrastructure, früher mit Rotor als Codename und in der Wikipedia hier beschrieben, eine zweite .NET-Implementation von Microsoft darstellt, oder nur eine neue Zusammenstellung einer einzigen Implementation, oder etwas dazwischen, aber interessant ist, dass frühe Versionen offenbar neben Windows auch auf FreeBSD und Mac OS X lauffähig waren.

Wer sich auch nur ein wenig dafür interessiert, wie die Welt ausserhalb von Microsoft aussieht, kennt sicher mittlerweile Mono, ein sehr erfolgreiches Projekt, welches es einem ermöglicht, seine .NET-Programme auch auf Linux und Mac OS X laufen zu lassen. Man kann offenbar, wie hier beschrieben, dank einem Hack Mono sogar verwenden, um Programme für das Compact Framework herzustellen, muss aber selbst aufpassen, nichts zu verwenden, was da nicht vorhanden ist.

Schon weniger bekannt dürfte sein, dass Mono im Bereich Open Source Konkurrenz hat in Form des DotGNU-Projekts. Ohne das Projekt im Detail zu kennen, bekam ich beim Studium der Website allerdings den Eindruck, dass hier im Moment um einiges kleinere Brötchen gebacken werden als bei Mono, und es scheint mit einem Motto GNU Freedom for the Net und Statements wie etwa Don’t get caught in a .Net auch stärker um ideologische Fragen zu gehen als bei der Konkurrenz.

Einen grossen Schub in Sachen Verbreitung könnte .NET erfahren, wenn es als Basistechnologie für Silverlight in der Version 2 den Weg in die Internet-Browser dieser Welt schafft. Microsoft will mit Silverlight 2 bereits selber eine Reihe von Plattformen abdecken, und das Mono-Pendant Moonlight will für eine nochmals grössere Reichweite sorgen. Wie erfolgreich die Sache wirklich wird, scheint mir im Moment noch etwas in den Sternen zu stehen, aber zumindest die Technologie sieht sehr solide aus.

Und jetzt wird es etwas exotisch: Die Firma Red Five Labs aus Südafrika hat, soweit erkennbar vollständig aus eigener Kraft, das .NET Compact Framework für Symbian/S60-basierte Smartphones implementiert. Wenn jetzt nur noch das Geld da wäre für eine ordentliche Werbekampagne, um dieses Produkt unter den Entwicklern auch bekannt zu machen… Und wie es damit weitergeht, wenn Silverlight 2 wie geplant ebenfalls auf S60 ankommt, ist eine offene Frage.

Wenn man mehr spielerisch veranlangt ist, kann man seine C#- und .NET-Kenntnisse auch dadurch erwerben, dass man mit Hilfe von XNA Spiele für die Xbox 360 programmiert. Sogar eine Unterstützung von Zune Players ist offenbar in der Pipeline.

Und zum Schluss noch dies: Unter dem Namen CrossNet hat offenbar jemand einen sehr speziellen CIL-Decompiler geschrieben, der Standard-C++-Code auswirft, den man dann fast überall kompilieren kann. Das ist für den eigenen Code ganz schön; das grosse und offenbar weitgehend ungelöste Problem scheint zu sein, wie man am „neuen Ort“ zu einer .NET Base Class Library, sprich zu einem „Framework“, kommt.

Framework Studio

Als die Megos vor einiger Zeit vor der wichtigen Frage stand, womit sie in Zukunft ihre Software entwickeln will, haben wir uns ein Produkt der deutschen Firma Framework Systems näher angeschaut, das sich Framework Studio nennt.

Ich war überrascht, was ich da zu sehen bekam, denn dieses System hat eine sehr interessante Architektur. Es läuft für mich quasi unter dem Motto „Erstaunlich, was man mit .NET alles machen kann“.

Beim Framework Studio handelt es sich um ein Software-Entwicklungssystem. Es entstehen Web-Applikationen, die man mit Hilfe einer Java-basierten Client-Komponente und einer C#/.NET-basierten Server-Komponente ausführt, zwischen denen via SOAP kommuniziert wird. Applikationen entstehen einerseits durch stark Tool-unterstützes Spezifizieren von Forms, Datenbank-Strukturen und Verarbeitungs-Logik, und andererseits durch Programmieren spezieller Logik direkt in C#.

Wie ein ausführlicher Artikel (Teil 1, Teil 2) erläutert, erlauben die Architektur des Systems und die Struktur der damit geschaffenen Applikationen eine ziemlich weit gehende Anpassbarkeit von Standard-Software.

Die Firma Nissen & Velten Software GmbH hat offenbar eine ERP-Lösung namens NVinity mit Hilfe des Framework Studio realisiert.

Trotz aller Faszination über das, was Framework Systems hier geleistet hat, haben wir auf den Einsatz von Framework Studio verzichtet. Ein Hauptgrund war unsere Entscheidung, nicht oder zumindest nicht ausschliesslich auf Web-Applikationen zu setzen, wie das hier nötig gewesen wäre. Jemandem, der hierin kein Problem sieht, kann ich aber durchaus empfehlen, sich die kostenlose Probeversion des Produkts mal anzuschauen. Selbst wenn es am Schluss nicht zu einem tatsächlichen Einsatz reicht, kann man als Software-Architekt mindestens die eine oder andere Idee mitnehmen und in seine „konventionelle“ C#-Applikation einbauen.

Wenn dies nun etwas gar nach Werbung klingt: Nein, ist es nicht, aber ich kann eben meine Sympathie für eine Firma nicht verhehlen, die wie die Megos gegen Ende der 1980er-Jahre mit EMBASSY den Mut hat, Neues in einer Art zu versuchen, die man eher bei viel grösseren Firmen erwarten würde.

Etwas beunruhigend, dass offenbar NVinity immer noch die einzige vorzeigbare in Framework Studio realisierte Applikation ist. Da liegt noch viel Arbeit vor der Firma Framework Systems; Innovationen haben es eben oft schwer…

.NET als Nachfolger von Win32

Kürzlich kam mir Petzolds Original-“Hello World“ für Windows in C wieder mal in die Hände. Als ich so am Staunen war über die Schönheit des Win32-API in seiner unverfälschten, puren Form, erinnerte ich mich daran, dass vor nicht allzu langer Zeit ziemlich heftig darüber spekuliert worden ist. Man fragte sich, ob Microsoft .NET nicht nur baut, damit wir Applikationsprogrammierer etwas produktiver werden, sondern um mittelfristig Win32 abzulösen und damit die gesamte Windows-Programmierung auf das nächste Level zu heben: das .NET-Framework als das neue Windows, zumindest was das API angeht.

Das hat meine Neugierde geweckt, und ich habe etwas recherchiert, wie es unterdessen um diese Spekulationen steht.

Per Google findet man relativ leicht heraus, dass der Höhepunkt dieses „Memes“ so um 2003/2004 herum gewesen sein muss, als die Gerüchte ins Kraut schossen, wie wohl das neue Windows Code-Name Longhorn aussehen würde. Von grossen, in .NET implementierten Betriebssystem-Teilen war die Rede. Und in diesem Longhorn FAQ, das offenbar als seriös genommen werden will, findet man folgende Aussage: „In the technology generations leading up to Longhorn, Microsoft has been moving to a .NET-based managed code environment dubbed WinFX, and the Longhorn generation will finally mark a clean split with the Win32 APIs of the past.“

Es ist mir hingegen nicht gelungen, unter Stichworten wie future windows API interessante aktuelle Informationen zu finden. Vielleicht hat ja Microsofts lange und schmerzreiche Schwangerschaft mit Windows Vista zu einer gewissen Ernüchterung geführt, wie schnell man Win32 ablösen könnte und wie gross der Aufwand dafür wirklich wäre.

In einer Diskussion aus dem Jahre 2004 stiess ich noch auf folgendes Argument, das mir heute noch relevant scheint und das ich ganz interessant fand: Microsoft verdient bekanntermassen nur mit 2 Dingen richtig massig Geld, einerseits mit Windows selbst, und andererseits mit Office. Die Office-Programme basieren auf Win32. Wenn also Microsoft mit .NET als Win32-Ablösung wirklich ernst machen will, ohne eine der beiden „cash cows“ zu verlieren, müsste sie einen kompletten Rewrite der Office-Programme ins Auge fassen. Von einem solchen ist nichts bekannt.

Aber wie dem auch sei, ob nun Microsoft etwas zu hoch gezielt hat ursprünglich oder nicht, gedeiht das .NET-Framework prächtig, und es kommt wohl kaum mehr jemandem in den Sinn, ein normales Applikationsprogramm auf Win32 aufzusetzen.

Dass das Framework unterdessen durchaus das Zeug hätte, als Windows-Programmieroberfläche zu fungieren, sieht man übrigens an der PowerShell, die ja mit Hilfe von .NET implementiert worden ist.

Zu guter letzt noch ein paar Links: ein Artikel von Joel Spolsky aus dem Jahre 2004 (immer noch lesenswert, falls man ihn nicht schon kennt), und die Website The Old New Thing mit manchmal geradezu abenteuerlichen Geschichten über die Entstehung gewisser Dinge rund um Win32, etwa diese Story mit dem Titel What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?.

Klicks auf Objekte zur Design-Zeit

Der im Visual Studio enthaltene Designer für Windows Forms ist ein grosser Fortschritt gegenüber früheren Programmen, z.B. dem Designer in Visual Basic 6. Und doch: Wenn es darum geht, Forms zu entwerfen, die eine Menge Controls haben, würde man sich viele Dinge einfacher wünschen, mit weniger Eingaben, und mit weniger Mausklicks.

Als ich kürzlich eben eine solche komplexe Form entwerfen musste, kam mir das Label-Control als besonders schlechtes Beispiel in dieser Beziehung vor: Jede Menge Eigenschaften, so viele, dass es häufig ein paar Klicks braucht, bis man sich bis zur einzigen Eigenschaft „durchgekämpft“ hat, die man wirklich routinemässig ändern möchte: den Text des Labels.

Mit der Zeit sagte ich mir, wie wunderbar es doch wäre, einfach ein Label im Designer anklicken zu können, um eine Dialogbox hervorzuholen mit einem Eingabefeld für das Ändern des Label-Textes!

Es gibt da nur ein kleines, aber entscheidendes Problem: Wie schafft man es, zur Design-Zeit an diesen Klick heranzukommen, um eigenen Code für die Anzeige besagter Eingabebox anhängen zu können? Es ist ja so, dass das Ereignis OnMouseClick eines Labels normalerweise im Designer nicht feuert, denn damit wäre ja das normale Funktionieren des Designers nicht mehr gewährleistet.

Hierzu ein verwandtes Beispiel, das noch viel klarer mögliche Probleme mit solchen Ereignissen illustriert: Stellen Sie sich vor, Sie haben für ein Control Drag-und-Drop-Logik implementiert, die plötzlich triggert, wenn Sie das Control im Designer verschieben…

Aber es geht trotzdem, und ein bisschen Suchen via Google und Ausprobieren hat folgende Lösung zu Tage gebracht: Man leitet eine eigene Klasse ab von Windows.Forms.Label und stattet diese mit einem sogenannten Designer aus, der nur gerade 1 Methode GetHitTest zu implementieren braucht. Damit kann man erreichen, dass selbst zur Design-Zeit unter bestimmten Umständen, die man frei selbst bestimmen kann, die Methode OnMouseClick des Labels aufgerufen wird.

In diese Methode baut man dann z.B. die Anzeige einer Dialogbox für die Abfrage eines neuen Textes ein, natürlich noch geschützt durch eine Abfrage von DesignMode, damit man nicht umgekehrt zur Laufzeit des Programms Ärger bekommt, wenn jemand den Label anklicken sollte.

Ich habe die Sache experimentell mal so geregelt, dass ein Klick auf die linke Hälfte des Labels wie gehabt an den Designer geht und ein Klick in die rechte Hälfte des Labels selbst zum Ändern des Textes. Das hat sich bisher als recht brauchbar erwiesen.

Im Code sieht das ganze so aus:

  class TritonLabelDesigner : System.Windows.Forms.Design.ControlDesigner {

    protected override bool GetHitTest(Point point) {
      TritonLabel hitLabel = (TritonLabel)Component;
      Point localPoint = hitLabel.PointToClient(point);
      if (localPoint.X > (hitLabel.Width / 2)) {
        return true;
      }
      else {
        return false;
      }
    }
  }

  [DesignerAttribute(typeof(TritonLabelDesigner))]
  public partial class TritonLabel : Label {
    public TritonLabel() {
      InitializeComponent();
    }

    protected override void OnMouseClick(MouseEventArgs e) {
      base.OnMouseClick(e);
      if (DesignMode) {
        // gewünschte DesignTime-Verarbeitung
      }
    }
  }

Reflektionen über die Reflection

Woran merkt man, dass jemand schon etwas länger programmiert? Z.B. daran, dass er oder sie bei der ersten Begegnung mit der Reflection im .NET-Framework sich darüber Gedanken macht, ob es wirklich eine gute Idee ist, dieses Feature zu verwenden.

Ich habe viele Jahre lang mit Compiler-basierten Sprachen wie Modula-2 und C++ gearbeitet, wo der Compiler so ziemlich jede Information über das Programm selbst vernichtet und dieses zur Laufzeit über keinerlei „Selbstbewusstsein“ mehr verfügt. Und just als ich unbewusst irgendwie fast das Gefühl bekommen hatte, dass müsse so sein, und ich die fehlende oder mangelhafte Umsetzung von Standards wie RTTI in den gängigen Compilern für C++ mit Gedanken quittierte wie z.B. „konnte ja nicht klappen“, dann kommt das .NET-Framework daher, wo ein Programm so ziemlich alles über sich selbst zur Laufzeit abfragen kann, obwohl natürlich mit Compilern gearbeitet wird.

Meine spontane Reaktion: Zuerst Erstaunen. Dann Skepsis: Hat das wirklich keine Nachteile? Geht nicht die Performance meines Programms in den Keller, wenn ich Reflection einsetze? Blasen all die Meta-Informationen, die ja irgendwo gespeichert sein müssen, nicht die Assemblies zu unanständigen Grössen auf? Besteht nicht sogar eine gewisse Gefahr, dass irgendwann einmal Microsoft hingeht, mir dieses schöne neue Spielzeug namens Reflection wieder wegnimmt und ich dann mit meinem Programm, das ohne nicht mehr auskommt, ganz bös im Regen stehe?

Ich kann vermelden, dass sich meine Skepsis gelegt hat. Der Hauptgrund dafür ist, dass ich mittlerweile einen Überblick habe, wo überall im .NET-Framework selbst Reflection eingesetzt wird. Die Nutzung dieses Mechanismus durchdringt das Framework mehr oder weniger von oben bis unten. Wenn da irgendwelche Haken wären, hätte man das schon längst gemerkt bzw. Microsoft wäre gezwungen gewesen, Probleme schleunigst auszuräumen.

Und wenn man sieht, dass schon beim einfachsten Data Binding eines DataGridView und dem automatischen Generieren von Kolonnen Reflection zum Einsatz kommt, weiss man, dass man die Anwesenheit der Reflection als Selbstverständlichkeit nehmen und ohne Bedenken darauf bauen kann.

Man kann wirklich einige faszinierende Dinge machen mit Reflection, und ich empfehle jedem, der ernsthaft mit dem .NET-Framework arbeiten will, sich die Sache mindestens einmal anzusehen.