VS.NET 2003 Legacy Platform Extensions

Veröffentlicht: 26. Mrz 2003 | Aktualisiert: 11. Nov 2004

Von Peter Salz

Totgesagte leben länger, heißt es im Sprichwort. So ist es nicht verwunderlich, der lange totgesagten Entwicklungsplattform Visual Basic 3.0 jetzt im Zusammenhang mit dem .NET Framework wieder zu begegnen. Eine Spezialedition von VB3 für den .NET Framework 1.1 schlägt die Brücke zu einer großen Zahl alter Anwendungen.

* * *

Auf dieser Seite

Legacy Platform Extensions Legacy Platform Extensions
Technologie Technologie
VBRetro .NET Projekte bearbeiten VBRetro .NET Projekte bearbeiten
Fazit Fazit
Ressourcen Ressourcen

Ein Aufschrei ging durch die Visual Basic 6.0 (VB6)-Gemeinde anlässlich der Vorstellung der ersten Beta-Versionen des .NET Framework. Die 1:1 Übernahme von nicht trivialen VB6-Projekten nach VB .NET war und ist nicht möglich. Auch die neueste Version des Migration Wizard in VS.NET 2003 hat Lücken. Zu verschieden sind die COM-Welt, in der VB6 tief verwurzelt ist, und die Welt des .NET Framework. Inzwischen ist es allerdings etwas ruhiger an der VB6-Migrationsfront geworden; das Gefühl der persönlichen Verletzung bei den Entwicklern scheint einer pragmatischeren, realistischeren Sichtweise gewichen zu sein.

In der entstandenen Ruhe der letzten Monaten ließ sich daher ein leiseres, jedoch konstantes Rumoren vernehmen: Visual Basic 3.0 (VB3), lange totgesagt, bewegte sich in seinem Grab. Eine erstarkende Stimme von Entwicklern, die aus den verschiedensten Gründen immer noch VB3 einsetzen müssen oder wollen, hat einer berechtigten Angst (vgl. [Bondeson]) Ausdruck verliehen, ganz in Vergessenheit zu geraten. Anhand neuester Erhebungen konnten sie belegen, dass eine signifikante Zahl von Applikationen immer noch unter VB3 gewartet, weiterentwickelt und in Einsatz gebracht wird. Diese Anwendungen nach VB6 oder VB .NET zu migrieren, so Oluf Asmusen, Sprecher von VB3 Programmers United (VB3PU), sei völlig illusorisch. Die Alternative, VB3 wie seit Release von VB5/6 weiterhin totzusagen bzw. zu ignorieren, würde zunehmend allerdings ein "politisches" Problem, denn VB3PU habe festgestellt, ein überproportionaler Prozentsatz heutiger VB3-Entwickler tendiere zu Ruby [URL:Ruby] als Ersatz für VB3, wenn es darum ginge, ein Projekt zu migrieren.

In Anerkenntnis dieser unerwarteten Realität wurde bei Microsoft im Oktober 2002 eine Task Force aus Mitgliedern des VB .NET Entwicklungsteams zusammengestellt, die kurzfristig eine Lösung für diese Situation herbeiführen sollte. Nach knapp sechs Monaten Arbeit hinter verschlossenen Türen ist nun eine erste Version der Lösung zum Greifen nah: Unter dem Codenamen "Drizzle" wurde ein umfangreiches Add-in für die nächste Version von Visual Studio .NET (VS.NET) implementiert, mit dem VB3-Projekte auf der .NET Platform weitergepflegt werden können (Abbildung 1).

legacy_platform_extensions

Abbildung 1: Bearbeitung eines VB3-Formulars in VS.NET 2003 mit "Drizzle". Links zu sehen: der Toolbar mit VB3-Steuerelementen für Windows Forms. Das Fensterdesign ist Windows 3.11 nachempfunden, um einen visuellen Hinweis auf die Zielplattformen des Add-in zu geben.

Legacy Platform Extensions

Der offizielle Name für "Drizzle" ist Legacy Platform Extensions (LPE). Als Legacy Platforms bezeichnet Microsoft VB3 und die Betriebssysteme vor Windows 98: Windows 95 (Win95), Windows 3.11 (Win311). Das Add-in ist also nicht nur als Mirgrationswerkzeug für VB3-Entwickler positioniert, sondern als ausgestreckte Hand in Richtung einer großen Zahl Win95- und Win311-Anwender zu verstehen. Die Ähnlichkeit der Bezeichnung zu den Smart Device Extensions (s. [Wechsler]) ist dabei gewollt: VS.NET 2003 wird nun zur alles vereinenden Entwicklungsoberfläche nicht nur für heutige Windows NT/2000/XP/2003 Systeme, embedded Devices mit Windows CE/XP embedded, unterschiedlichste Form Factors der Pocket PC-Linie und eine breite Palette von Web-Clients (vom IE 6.0 bis zum WAP-Handy) - sondern nun auch für alte Windows-Versionen.

Diese Positionierung hat eine neue Sichtweise auf VB3 zur Folge: VB3 ist nicht länger eine obsolete Sprache, von der es sich zu lösen gilt, sondern eine eigenständige .NET Programmiersprache. Um das zu unterstreichen, hat sie in der Legacy Platform Extensions Beta-Version auch einen eigenen vorläufigen Namen: VBRetro .NET.

 

Technologie

Geschuldet ist die wirklich nahtlose Integration von VB3 in VS.NET 2003 zwei Umständen:

Zum einen ist VB3 (bzw. VBRetro .NET) nicht wirklich objektorientiert. VB3 erlaubte es Ihnen nicht, eigene Klassen zu definieren oder gar Komponenten zu erzeugen. VB3 basierte noch nicht auf COM und kennt daher nur ein rudimentäres Objektkonzept. (Erst VB4 hat Visual Basic mit COM verheiratet und VB zu einer Win32 API Entwicklungsumgebung gemacht.) Insofern existiert für VB3-Programme im Allgemeinen kein Problem durch die indeterministische Zerstörung von Objekten im .NET Framework. Wo es keine Objekte gibt, ist es unerheblich, ob ihre Lebenszeit durch Referenzzählung oder Garbage Collection bestimmt ist.

Im Speziellen müssen Sie allerdings doch an zwei Punkten auf diese semantische Kluft zwischen den beiden Welten achten. VB3 kannte ein Objektkonzept schon für Formulare und Datenbanken. Das LPE-Team setzt hier jedoch auf Ihre Programmierdisziplin und erwartet, dass Ihre VB3-Anwendungen den langjährigen Empfehlungen folgen, Formulare immer mit Unload nach Gebrauch zu schließen und Datenbankverbindungen mit Close() explizit freizugeben. So vermeiden Sie, dass Ressourcen erst zu unbestimmter Zeit bei der Garbage Collection freigegeben werden. Um Sie daran zu erinnern, fügen die LPE beim ersten Öffnen Ihrem VBRetro .NET Projekt zwei diesbezügliche Aufgaben in der Task-Liste hinzu.

Zum anderen muss VBRetro .NET gar nicht versuchen, den .NET Framework zu bedienen. Während VB .NET und C# Sprachen für dieselbe "ausgewachsene" CLI-Implementierung sein sollten - mit allen Vor- und Nachteilen -, hat Microsoft für die LPE den Weg der Smart Device Extensions eingeschlagen und eine eigene CLI-Implementation für den Win16 und Win32 API entwickelt. Der sog. .NET Legacy Framework ist auf Windows 3.11 und Windows 95 lauffähig, enthält daher selbstverständlich aber nicht alle Leistungsmerkmale seines "großen Bruders", dem .NET Framework. Konzessionen mussten insbesondere in den Bereichen Multithreading, .NET Remoting, Windows Forms, Grafik- und Datenbankprogrammierung gemacht werden:

  • Zugunsten der Einfachheit hat man auf Multithreading (Namespace: System.Threading) ganz verzichtet, da der Win16 API keine Parallelverarbeitung bietet.

  • Aus dem Verzicht auf Mulithreading ergeben sich Limitationen bei asynchronen Methodenaufrufen für Delegates und auch für .NET Remoting im Bereich Ereignismeldungen über Prozessgrenzen hinweg. Grundsätzlich sind VBRetro .NET-Anwendungen aber fähig, z.B. XML Web Services aufzurufen.

  • Die GDI+ Leistungspalette kann von Win95 und Win311 nicht geboten werden. Die Grafikbibliothek GDI- bietet daher kein objektorientiertes Programmiermodell, sondern nur eine ganz grobe Kapselung von GDI, um die Unterschiede zwischen Win16 und Win32 API vor Ihnen zu verbergen.

  • Auf eine Integration von ADO.NET wurde ganz verzichtet. Der .NET Legacy Framework ist (zunächst) auf die Programmierung mit VBRetro .NET ausgerichtet und bietet daher nur die von VB3 her bekannte Datenbankprogrammierschnittstelle basierend auf der Jet Engine.

Ansonsten ist der .NET Legacy Framework jedoch eine CLI standardkonforme Implementation, die sogar IL-kompatibel mit dem .NET Framework ist. Sie können insofern jetzt auch mit VB3 Komponenten entwickeln - allerdings sind Sie dabei auf Klassen mit statischen Methoden beschränkt.

Bei der Nutzung von .NET Framework-Komponenten gilt diese Beschränkung aber nicht. Wie ein Formular können Klassen aus Managed Code Assemblies instanziert werden. Die so erzeugten Objekte unterliegen aber natürlich dann auch der Garbage Collection. Die Einbindung von Assemblies geschieht in VBRetro .NET über ein Attribut:

<Assembly: AssemblyReference("MyAssm.dll")>

Gleiches gilt auch für VBX-Komponenten. Beim ersten Öffnen eines VB3-Projektes konvertiert VS.NET 2003 evtl. Abhängigkeiten von VBX-Komponenten in diese Notation.

Ebenfalls konvertiert werden FRM/FRX-Dateien. Das Ergebnis sind wie beim VB6 Migration Wizard explizite Anweisungen zur Erzeugung von Windows Forms-Objekten. Unterstützt werden jedoch nur die VB3-Standardsteuerelemente (s. Toolbox in Abbildung 1).

So standardkonform der .NET Legacy Framework ist, in einem Punkt war eine Abweichung bzw. Erweiterung unumgänglich. Um die VB3-Anweisungen On Error und Gosub zu unterstützen, waren zwei neue IL-Opcodes für einen intra-prozeduralen Unterprogrammaufruf nötig. Damit lässt sich VB3-Code wie dieser:

Sub MySubroutine()<p>
Sub MySubroutine()
    Dim i As Integer
    i = 1
    Gosub MyGosub
    .
    Exit Sub
MyGosub:
    i = i + 1
    Return
End Sub

übersetzen nach:

IL_0001:  ldc.i4.1
IL_0002:  stloc.0
IL_0003:  callLoc.s IL_0012
...
IL_0011:  ret
IL_0012:  ldloc.0
IL_0013:  ldc.i4.1
IL_0014:  add.ovf
IL_0015:  stloc.0
IL_0016:  retLoc

callLoc ruft den Code ab der angegebenen Adresse auf, ohne den internen Stackframe für die eigentlich laufende Prozedur zu verändern. Und retLoc kehrt aus einem solchen Aufruf an die Aufrufstelle zurück.

Es bleibt abzuwarten, ob diese IL-Erweiterung Eingang in den .NET Framework findet und lieb gewonnene Anweisungen auch in einer späteren Version von VB .NET wieder auferstehen lässt.

In diesem Zusammenhang ist nicht uninteressant, dass der .NET Legacy Framework SDK ein Tool enthält, mit dem Sie VB3 P-Code nach IL-Code übersetzen können. Sollten Sie also noch alte VB3-Projekte ohne Sourcecode einsetzen, können Sie auch diese in den Genuss des .NET Legacy Framework kommen lassen - und erhalten damit sogar eine Chance auf Zurückgewinnung des (bzw. eines) Sourcecodes durch IL-Decompiler wie Anakrino [URL:Anakrino].

 

VBRetro .NET Projekte bearbeiten

Im Normalfall werden Sie im Quellcode existierende VB3-Projekte auf den .NET Legacy Framework bringen wollen. Die komplette 1:1 Übernahme von VB3-Sourcen inkl. aller Sprachkonstrukte und VBX-Nutzung macht das sehr simpel. Im einfachsten Fall öffnen Sie also ein VB3-Projekt in VS.NET 2003 und lassen es sofort mit F5 ablaufen. Dass das Projekt dann in etwas "modernerer" Form gespeichert wird, ist für Sie unerheblich - versperrt Ihnen allerdings den Weg zurück in die VB3-Entwicklungsumgebung. Deren Wert sinkt mit den LPE endgültig auf Null, da VBRetro .NET 100% kompatibel zu VB3 ist und sogar eine funktionale Obermenge implementiert.

Sinn und Zweck einer Übernahme von VB3 nach VBRetro .NET ist aber natürlich nicht nur eine simple Neuübersetzung für den .NET Legacy Framework, sondern die Pflege Ihrer VB3 Sourcen. Das tun Sie, wie von VB .NET her gewohnt, im Codeeditor oder im Windows Forms Editor.

Der Codeeditor bietet alle Annehmlichkeiten von Intellisense und automatischer Anweisungsvervollständigung. Für Gosub- und On Error-Befehle zeigt er sogar eine Liste möglicher Ziele innerhalb einer Routine an.

Auch die Liste der VB3-Typen steht Ihnen natürlich komplett zur Verfügung. Obacht jedoch bei den Zahlentypen: Wie viele Bytes z.B. ein Integer belegt hängt vom Typ Ihres VBRetro .NET Projektes ab. Für Win16 Applikationen sind es 16 Bit, für Win32 Applikationen 32 Bit. Der Default beim ersten Öffnen eines VB3-Projektes sind 16 Bit. In den Projekteigenschaften können Sie jedoch jederzeit auf 32 Bit umschalten. Einen solchen Wechsel sollten Sie jedoch mit Vorsicht durchführen, denn User Defined Types verändern damit unter Umständen ihre Größe!

Die Wartung Ihrer Formulare mit dem Windows Forms Editor entspricht der von VB .NET. Allerdings stehen Ihnen nur spezielle Legacy Controls (s. Toolbar in Abbildung 1) zur Verfügung und die Möglichkeit, VBX-Steuerelemente einzubinden. Weder ActiveX-Controls noch .NET Framework-Komponenten können auf VBRetro .NET Formularen platziert werden. Grund dafür ist zum einen, dass der .NET Legacy Framework keine Verbindung zur COM-Welt aufnehmen kann (COM-Interop wurde nicht integriert), zum anderen hängen .NET Framework Windows Forms Steuerelemente von GDI+ ab, das der .NET Legacy Framework nicht unterstützt.

Um Ihnen einen visuellen Hinweis auf die Legacy Platforms zu geben, für die Sie mit dem LPE entwickeln, hat Microsoft sich übrigens entschieden, VBRetro .NET Formulare mit dem Win311 Look&Feel auszustatten (s. Abbildung 1). Wie bei den Smart Device Extensions ist Ihnen also immer klar, für welche Umgebung Sie arbeiten und dass mit Limitationen zu rechnen ist.

Wenn Sie ein VBRetro .NET Projekt übersetzen, erzeugt VS.NET 2003 wie gewohnt eine EXE-Datei. Sie enthält einen kleinen Header mit Maschinencode zum Start des .NET Legacy Framework und ansonsten IL-Code. Im Normalfall liefern Sie diese EXE-Datei (inkl. eventuell notwendiger VBX-Bibliotheken) an einen Anwender aus, auf dessen System Sie den .NET Legacy Framework erwarten. Alternativ erzeugen Sie ein Setup-Projekt, das den .NET Legacy Framework auf dem Zielsystem im System-Verzeichnis installiert. DLLs und VBX-Dateien werden ansonsten wie bei Windows üblich gesucht: im Anwendungsverzeichnis bzw. im Windows-Verzeichnis. Wo Sie sie installieren, bleibt also Ihnen überlassen.

Aber der .NET Legacy Framework bietet noch eine weitere Deployment-Option: Xcopy-Deployment für den Framework selbst! Sie können alle für Ihr Projekt relevanten Systemkomponenten (mindestens mscoreel.dll) auch einfach in einem Verzeichnis ablegen. Beim Start Ihrer EXE-Datei wird dann der lokale Framework geladen. VBRetro .NET Anwendungen sind damit komplett von CD-ROM lauffähig, selbst ohne Vorinstallation des .NET Legacy Framework. Für diese Art des Deployment bieten die LPE sogar einen Wizard, der Ihnen die Suche nach den Systembibliotheken abnimmt und sie in ein Setup-Verzeichnis kopiert. Da ihre Namen wegen der Beschränkung auf 8.3 Dateinamen sehr kryptisch sind (z.B. sys2399.dll für System.Runtime.Remoting.dll), werden Sie dieses Feature zu schätzen wissen.

 

Fazit

Während Sie normalerweise gut daran tun, bei einem Todesfall die Spiegel zu verhängen, um Widergänger aus dem Haus zu halten, lohnt es sich, von dieser magischen Handlung bei VB3 abzusehen. VB3 in Form von VBRetro .NET ist ein gern gesehener Gast aus dem Reich der Toten, mit dem nach all diesen Jahren niemand mehr gerechnet hätte.

Besonders interessant ist dabei die Sichtweise auf VBRetro .NET gar nicht mal als Migrationstool, um VB3-Projekte doch noch auf den .NET Framework zu bringen. Viel entscheidender scheint das Potenzial für echte Cross Platform-Entwicklungen, die vom Server bis zum PDA und von Win16 bis zu Win64 API reichen.

In diesem Sinne bleibt abzuwarten, ob der .NET Legacy Framework vielleicht in der Beta 2 auch noch MS-DOS unterstützen wird.

Ein Download der ersten Beta-Version der Legacy Platform Extensions ist für den 1. April 2003 angekündigt. Gönnen Sie sich diese Erinnerung an vergangene Tage. Vielleicht ergeben sich daraus Impulse für zukünftige Projekte, die Sie einem noch größeren Kundenkreis zugänglich machen können.

 

Ressourcen

[Bondeson] Jan Bondeson, Lebendig begraben. Geschichte einer Urangst, Hoffmann & Campe 2002

[Wechsler] Alexander Wechsler, Entwickeln Sie Anwendungen für Nicht-PC-Systeme, MSDN Online 2003

www.saurik.com/net/exemplar/

www.ruby-lang.org/en/

April, April

Ja, ja, es wäre so schön gewesen. Und unser Screenshot mit einem Windows-3.11-Fenster in Visual Studio .NET sieht doch auch wirklich beeindruckend aus. Trotzdem handelt es sich um eine Flunkerei, die zum 1. April üblich ist. Die beschriebene VS.NET-Erweiterung wird Microsoft nicht entwickeln.

Ihr MSDN Online Team