Die Community zu .NET und Classic VB.
Menü

vbRichClient5, eine Zukunftsperspektive für VB-Entwickler?

 von 

Status quo 

Irgendwann um die Jahrtausendwende hat Microsoft entschieden, Visual Basic nicht mehr weiter zu entwickeln. Die Entwicklungsumgebung und die VB-Runtime wurden auf dem Stand von VB6 SP6 eingefroren.

Die VB6-Runtime wird zusammen mit aktuellen Windows-Betriebssystemen ausgeliefert. In einem "Support-Statement" vom November 2012 hat Microsoft die Kompatibilität der Runtime zu den aktuellen Betriebssystemen bekräftigt. Wörtlich heißt es:

The core Visual Basic 6.0 runtime will be supported for the full lifetime of Windows Vista, Windows Server 2008, Windows 7, and Windows 8, which is five years of mainstream support followed by five years of extended support.

Die VB6-IDE (Entwicklungsumgebung) wird zwar offiziell nicht mehr unterstützt, ist aber unter allen aktuellen Windows-Betriebsystemen noch installierbar und funktionsfähig.

VB-Programme können zu native-Exes kompiliert werden. Sofern keine zusätzlichen Komponenten verwendet werden, können diese Kompilate ohne Installation auf aktuellen Windows-PCs (zum Teil auch unter Linux / Wine) ausgeführt werden. VB-Programme starten schnell, auch die Ausführungs­geschwindigkeit lässt kaum Wünsche offen.

Anmerkung der Redaktion: Wir möchten an dieser Stelle auch auf die Fundraising-Kampagne für die Entwicklung eines freien Nachfolgers von VB6 hinweisen: A Replacement to Visual Basic 6 IDE and Compiler

vbRichClient  

Das vbRichClient-Framework wird vom Autor Olaf Schmidt frei zur Verfügung gestellt. Das Komponentenset wurde speziell für VB entwickelt und bietet neben einem modernen GUI-Framework einen einfachen DB-Zugriff auf SQLite und weitere Helper-Klassen für den Programmierer-Alltag. Als solches kann der RC5 (Kurzform für vbRichClient Version 5) als sehr nützliche Erweiterung für normale VB-Anwendungen eingesetzt werden. Hinter dem RC5 steckt aber mehr: Der Autor sieht mittelfristig sein Framework als Übergang zu einen freien plattform­unabhängigen VB-Nachfolger.

Ein Problem von VB.Net, dem offiziellen Nachfolger von VB, ist der harte Schnitt, den Microsoft den Entwicklern abverlangt. Der angebotene Migrationspfad ist nicht praxistauglich. Microsoft hat damit viel Vertrauen bei seiner größten Entwicklergemeinde eingebüßt. Der RC5 versucht an dieser Stelle einen weicheren Weg, einen Weg den VB-Entwickler mitgehen können, ohne dabei ihre jahrzehntelange Arbeit aus der Vergangenheit aufgeben zu müssen.

Was macht aber der vbRichClient anders? Das Framework integriert sich nahtlos in die VB6-Entwicklungsumgebung. Auf dem Entwicklungsrechner muss lediglich eine von insgesamt drei DLLs registriert werden. Die beiden anderen DLLs (vb_cairo_sqlite.dll und DirectCOM.dll) müssen im gleichen Ordner liegen wie die registrierte vbRichClient5.dll. Beim Anwender, der später die kompilierte Exe verwendet, ist die Registrierung nicht nötig, es reicht aus, wenn die drei DLLs im gleichen Ordner liegen wie die Exe, oder in einem Unterordner wie z.B. \bin\. Wichtig ist dabei, dass die zwei "Namespace-Klassen" des Frameworks (New_c und Cairo) zuvor regfree instantiiert wurden (per DirectCOM.dll API-Aufruf). Ein installationsloser Vertrieb Ihrer Anwendung ist also möglich. Wenn Sie hingegen Ihre Anwendung mittels Setup verteilen wollen, dann binden Sie die DLLs ganz normal in das Setup-Script ein. Am Beispiel von Inno-Setup wären das folgende drei Zeilen:

Source: "C:\rc5\vbRichClient5.dll"; DestDir: "{app}";
Source: "C:\rc5\DirectCOM.dll"; DestDir: "{app}";
Source: " C:\rc5\vb_cairo_sqlite.dll"; DestDir: "{app}";

Was leicht vergessen wird, ist eine vierte Datei, die license.txt. Eine Vorlage für diese Datei wird mit dem Framework mitgeliefert. Sie sollten diese Datei in Ihr Setup aufnehmen, weil hier sämtliche (in vb_cairo_sqlite.dll statisch gelinkten) Opensource-Bestandteile und deren Lizenzen aufgeführt sind. Wohlgemerkt, Sie bekommen diese Komponenten nicht direkt zu sehen, weil sie in die obige RC5-Begleit-DLL integriert sind. Dazu zählen:

  • Die Cairo-Grafikbibliothek, sie bietet eine vektorbasierte API und ist die Basis für das GUI-Framework aus dem RC5. Das CairoContext-Objekt kann aber auch in normalen VB-Formen verwendet werden. Dessen Grafik-Funktionen erlauben neben antialiased Vektor-Output über Pfad-Definitionen auch vielfältige Bild-Manipulation (z.B. alle Arten von alpha-transparentem Blending, Rotationen u. Scaling), das Arbeiten mit modernen Image-Resource-Formaten wie Alpha-Icons, PNGs, SVGs, JPGs, sowie das direkte Generieren von PDFs wird unterstützt. Erwähnenswert sind auch Klassen für die Druckausgabe und Druckvorschau, oder auch der Support für QRCode (in Lese- und Schreib-Richtung).

  • Die SQLite3-Engine bietet eine ADO-ähnliche Schnittstelle zu SQLite-Datenbanken. SQLite-DBs manifestieren sich in einem einzelnen File (ähnlich *.mdb) und haben sehr weite Verbreitung, die Features sind in etwa vergleichbar mit der JET-DB-Engine (bei besserer Performance). Auch wenn Ihre Anwendung eine andere Datenbasis verwendet, ist diese Bibliothek sehr praktisch, weil damit auch InMemory-DBs unterstützt werden. Das sind Datenbanken, die nur im Arbeitsspeicher existieren und entsprechend sehr schnell sind. Ihre Anwendung profitiert beim Ablegen umfangreicher und komplexer Datenstrukturen in einer InMemory-DB von den bequemen Abfragemöglichkeiten per SQL.

  • Diverse weitere Helfer-Klassen bieten Unterstützung für z.B. Multimedia, Datenkompression, Datenverschlüsselung, XML; auch Web-Technologien kommen nicht zu kurz, dank HTTP-Request- und schnellen JSON-Klassen. Eine prozessintern startbare WebServer-Klasse ist integriert, die in App-Remoting-Szenarien oder beim Benutzen von JavaScript-Frameworks in Verbindung mit anwendungsinternen Browser-Controls hilfreich ist.

Der Migrationspfad  

Phase 1

Das vbRichClient5 wird als Verweis in VB-Projekte eingebunden. Diverse Klassen erweitern damit die VBRuntime mit performanten Grafik-, Daten-, Betriebssystem- und Kommunikations-Funktionen. Ein integriertes RegFree-Konzept sorgt für das Einbinden von fremden ActiveX-DLLs ohne Registrierung auf dem Anwenderrechner. Im RC5 finden Sie ein verbessertes Collection-Objekt, FileSystem-Funktionen, Timer, Unterstützung für Gestensteuerung, Multimedia, einen schnellen String-Builder, TCP-Klassen, Bild- und Daten-Container und vieles mehr. Manches davon können Sie natürlich auch in VB selbst programmieren, manches vielleicht als Zusatzkomponente erwerben. Der Einsatz von RC5 bietet diese Funktionen jedoch kostenlos in einem gut getesteten Framework, das Sie problemlos an Ihre Anwender verteilen dürfen. In dieser Form ist der RC5 eine mächtige Erweiterung für Ihre bestehenden oder neuen VB-Projekte.

Phase 2

Das moderne GUI-Framework im RC5 basiert auf der Cairo-Bibliothek und arbeitet vektorbasiert. Unter der Oberfläche wird weder das Windows GDI / GDI+ noch DirectX verwendet. Im Prinzip ist die Bibliothek plattformunabhängig und bietet jetzt schon die Basis für einen ebenso plattform­unabhängigen VB-Nachfolger. Die neuen Steuerelemente sind ganz normale VB-Klassen (cls-Dateien), die von der cWidgetBase-Klasse abgeleitet werden (VB-übliche objektbasierte Vererbung). Die elementarste Implementierung eines solchen Controls ist:

Private WithEvents W As cWidgetBase

Private Sub Class_Initialize()
    Set W = Cairo.WidgetBase
End Sub

Private Sub W_Paint(CC As cCairoContext, ..., ...)
     CC.DrawText ...
End Sub

Wie Sie sehen, bekommt das Steuerelement im Paint-Event einen Kontext geliefert um sich selbst zeichnen zu können. Dieser Kontext ist ebenfalls ein RC5-Objekt und bietet moderne Methoden zur Grafik- oder zur Textausgabe. Damit können Sie Ihre Steuerelemente aussehen lassen wie Sie wollen. Die von W bereitgestellten Methoden und Events sind vergleichbar (bzw. gehen deutlich über das hinaus) was man von VB-Forms oder VB-UserControls bereits kennt. Aber keine Angst, Sie müssen jetzt nicht jede Textbox selbst programmieren. Auf GitHub finden Sie vbWidgets, eine RC5-basierte Steuerelement-Bibliothek inkl. Quellcode. Hier sind bereits die wichtigsten Steuerelemente enthalten. Sie können diese DLL in Ihrem Projekt verwenden (wohlgemerkt: ebenfalls ohne Registrierung) oder Sie nutzen die enthaltenen VB-Klassen und passen diese beliebig nach eigenem Gusto an. Natürlich können Sie sich auch ganz neue Controls auf Basis der vorhandenen Klassen ableiten.

Die so erstellten Steuerelemente erscheinen leider nicht in der Werkzeugsammlung von VB und können auch nicht wie die VB-Konsorten auf eine Form gezogen werden. Um ein Cairo-Control, in RC5-Lingo Widget genannt, auf eine VB-Form zu platzieren, braucht es ein VB-Benutzersteuerelement als Wrapper. Damit lassen sich auf einer Form VB-eigene Steuerelemente und Cairo-Widgets zusammen verwenden.

Phase 3

VB-Forms sind inzwischen ebenfalls durch voll Unicode-fähige WidgetForms ersetzbar. Genauso wie die Widgets sind auch diese CairoForms normale VB-Klassen. Die elementarste Ausprägung einer solchen enstprechenden Kapselung in einer eigenen (z.B. als cfTest benannten) Form-Klasse ist:

Private WithEvents Form As cWidgetForm

Private Sub Class_Initialize()
    Set Form = Cairo.WidgetForms.Create(vbSizable, "Mein Cairo-Fenster")
End Sub

Public Sub Show()
    Form.Show
End Sub

Das war's bereits hinsichtlich des in der kapselnden Klasse befindlichen Minimal-Codes. Um eine solche Form (z.B. zusammen mit einer existierenden VB-Form, namens frmMain) zur Anzeige zu bringen, reicht es aus, in einem *.bas Modul zu schreiben:

Public fTest As New cfTest
Sub Main()
    fTest.Show 
End Sub 

Damit können Sie in Ihrem VB-Projekt neben den VB-Formen auch Cairo-Formen einsetzen und ggf. vorhandene VB-Formen nach und nach migrieren. Das meinte ich oben mit dem weichen Migrationspfad. Eines gilt es jedoch zu berücksichtigen: Ein VB-Programm wird mit dem Entladen der letzten Form beendet. Was aber, wenn Sie in Ihrem Projekt ausschließlich Cairo-Forms verwenden möchten? Für diesen Zweck stellt Cairo eine eigene Message-Pump bereit. Am Ende der Sub-Main-Prozedur Ihres Projektes sollte dann folgende Anweisung stehen:

Cairo.WidgetForms.EnterMessageLoop

Dieser MessageLoop sorgt dafür, dass Ihr VB-Programm erst entladen wird, wenn die letzte Cairo-Form geschlossen wird. Sie könnten jedoch ein Cairo-Programm welches mehrere Forms anzeigt, auch ziemlich radikal mit folgender Anweisung beenden:

Cairo.WidgetForms.RemoveAll

In einem solchen Entwicklungs- bzw. Migrationsstadium besteht ihr Projekt nur noch aus Modulen und Klassenmodulen. Sie brauchen keine Zusatzsteuerelemente mehr, weil alles durch Cairo abgedeckt ist. Ihr fertiges Programm hat nur noch eine Microsoft-Abhängigkeit, das ist die VB-Laufzeitumgebung. Wie wir oben gelesen haben, hat uns Microsoft zugesichert, dass diese vorerst weiter unterstützt wird. Gemessen am Lebenszyklus von Windows 8 wäre dies das Jahr 2024. Genug Zeit also um die Phase 4 vorzubereiten.

Phase 4

Das was ab hier folgt ist Zukunftsmusik und mein Artikel wird ein bisschen spekulativ. Olaf Schmidt plant einen Compiler, der aus VB-Code C-Code emittiert. Dieser soll dann mit einem freien Compiler zu nativem Maschinencode übersetzt werden. Ziel hierbei ist, 100% Code-Kompatibilität beim Übersetzen von (zunächst ausschließlich) *.bas und *.cls Modulen. Wir schreiben also unseren Code weiter mit der VB-IDE und können ihn damit auch debuggen - unter Verwendung unseres geliebten Edit&Continue. Alles wie bisher. Wenn unser Programm fertig ist, wird dieses Programm mit dem neuen Compiler übersetzt. Dabei kann auch der (bereits nur aus *.bas und *.cls Modulen bestehende) Code der vbRichClient-DLL recompiliert und sogar statisch in die Exe eingebunden werden. Die Abhängigkeit von der VB-Runtime wäre somit eliminiert - 64Bit Kompilate sind möglich und hängen nur vom jeweils verwendeten C-Compiler-Backend ab. Kompilate werden in der Anfangs-Phase zunächst nur für die Win-Plattform möglich sein; da die Klassen der neuen (RC5-basierten) Runtime jedoch von Win-API-Calls abstrahieren (im Usercode ist äußerst selten die Benutzung von deklarierten Win-APIs nötig) ist damit auch der Weg offen für ein plattformunabhängiges Kompilat.

Hierzu muss die RC5-interne Implementierung der Runtime-Klassen - an den Stellen wo derzeit Windows-systemspezifische API-Declares Verwendung finden - auf entsprechende Aufrufe gegen das Flat-API des jeweiligen Ziel-OS angepasst werden. Die meiste Arbeit beim Portieren eines abstrahierenden (auch GUI unterstützenden) Klassen-Frameworks auf andere Plattformen machen normalerweise die Aufrufe in das Grafik-Subsystem des jeweiligen OS. Da hier jedoch mit Cairo bereits eine abstrahierende Bibliothek vorliegt, die auf allen wichtigen bekannten Plattformen verfügbar ist müssen im Prinzip nur die systemspezifischen Calls in das Dateisystem (z.B. hinter den Methoden der Klasse cFSO) oder auch die Calls zum Ansprechen des Socket-Layers (hinter den TCP und UDP-Klassen) angepasst werden.

Nach erfolgter (plattformspezifischer) Anpassung der RC5-Runtime-Klassen, könnten unsere Programme dann ohne größere Eingriffe auch für ein alternatives Betriebssystem, z.B. für Linux, kompiliert werden.

Zusammenfassung

Oben beschrieb ich einen Weg, bei dem (zunächst) die existierende VB6-IDE quasi als Host für das Bearbeiten der *.cls und *.bas Module Verwendung findet (die dann einfach vom neuen Compiler übersetzt werden).

Falls eine neue VB-IDE jedoch Priorität haben sollte, dann ginge es auch anders herum (bzw. parallel):

Die neue IDE könnte auch vor dem (bzw. gleichzeitig zum) neuen Compiler entwickelt werden - ganz normal mittels VB6, unter Einbeziehung der RC5-GUI-Klassen und -Controls. Um den Aufwand nur einmal zu betreiben wäre es gut, wenn der (noch VB6-basierte) Code dieses IDE-Projekts später vom neuen Compiler ohne irgendwelche Änderungen (z.B. in einer 64Bit-Version) neu kompilierbar wäre, um eine nicht nur codemäßig neue, sondern auch in Binärform neue, von der alten VB-Runtime abkoppelnde Entwicklungsumgebung zu übersetzen. Und das wäre dann gegeben, wenn der neue Compiler seine Zielvorgabe (zumindest zu *.bas und *.cls vollständig kompatibel zu sein) einhält und im neuen IDE-Projekt auch nur diese Code-Modul-Typen Verwendung finden. Und Letzteres ist ohne Probleme schon heute mit den RC5-Klassen machbar (und ist RC5-intern bereits gegeben).

Bis beide Projekte (neue IDE + Compiler) in den wichtigsten Teilen vollständig implementiert sind und benutzbar werden, ist es sicher noch ein langer und schwieriger Weg. Wenn ich mir jedoch die Alternativen ansehe, stimmen die mich auch nicht wesentlich optimistischer. Die Perspektive die uns Olaf Schmidt mit dem vbRichClient bietet ist realistisch, zumal der Beweis, dass es funktionieren kann, bereits mit RC5 erbracht ist. Auch in der aktuellen Form ist das Framework eine bemerkenswerte VB-Erweiterung.

Im Internet findet sich viel guter VB-Code, der in der neuen Umgebung teils unverändert teils mit kleinen Anpassungen verwendet werden kann. Gleiches gilt für unseren eigenen Code und ebenso für die Erfahrung die wir in unserem Programmiererleben mit VB gesammelt haben. VB war und ist eine der beliebtesten Programmier-Sprachen, gerade auch bei Einsteigern. Ich könnte mir vorstellen, dass dieses VB-Samenkorn wie eine Wüstenblume neu aufblüht, wenn es nach langer Zeit wieder Wasser bekommt.

Quellen und Links

Ihre Meinung  

Falls Sie Fragen zu diesem Artikel haben oder Ihre Erfahrung mit anderen Nutzern austauschen möchten, dann teilen Sie uns diese bitte in einem der unten vorhandenen Themen oder über einen neuen Beitrag mit. Hierzu können sie einfach einen Beitrag in einem zum Thema passenden Forum anlegen, welcher automatisch mit dieser Seite verknüpft wird.