Visual Basic 6 im Jahr 2026: Ein Aufruf an Microsoft

C# als Programmiersprache ist keineswegs schlechter als VB6, auch nicht VB.NET.

Aber: die .NET-Entwicklungsumgebung fühlt sich für einen VB6-Entwickler wie ein Rückschritt in die Steinzeit an:

1. Es fehlen die magischen Debugging-Fähigkeiten die das "Live-Programming" in VB6 zu einem realen Booster für das Programmieren machten: Du startest mit einem Draft, und optimierst diesen zur Laufzeit.
2. .NET vereint gefühlt hunderte Technologien unter einem Dach, aber die überladene Oberfläche schrecken jeden Ein- oder Umsteiger von Anfang an ab und die Lernkurve für die Einarbeitung in die IDE ist riesig.
3. Die .NET-IDE fühlt sich deutlich weniger responsiv an und für den Start einer kleinen Hello World-App braucht man gerne mal 10 Sekunden Kompilierzeit bis ein einfaches Programm überhaupt erstmal startet...
4. Die .NET-IDE scheint extrem Ressourcen-Hungrig zu sein. Eben mal schnell auf einem Surface Laptop mit 250GB Festplattenspeicher eine .NET-Entwicklungsumgebung zu installieren, gleicht damit schnell einem Spiessroutenlauf wenn es darum geht, die benötigten Ressourcen frei zu machen.

Mein Aufruf an Microsoft: VB6 muss OpenSource werden, damit es von der Community weiter entwickelt und ins Jahr 2026 überführt werden kann.

VB6 lebt im Jahr 2026 weiter

Die Community hat Visual Basic 6 nie aufgegeben. Kr00l führte die in VB6 oft verwendeten Microsoft Common Controls ins Jahr 2026 über und erstellte dieselben Komponenten komplett DPI-Aware und Unicode/UTF-8-fähig.

TwinBasic entwickelt sich zum startfähigen 64Bit-Kompilierer selbst für bereits bestehende Programme. Der Ansatz der Community ist lobenswert und überaus ambitiös, vor allem weil niemand Zugang zum Sourcecode von VB6 hat und die Community alles neu entwickeln muss.

Leider ist der Ansatz auch tatsächlich so ambitiös, dass es sich lohnt zu fragen: welche Alternativen hätten wir denn eigentlich noch?

Viele Schwächen von VB6 wie beispielsweise echtes Multithreading könnte im Jahr 2026 mit zusätzlichen Rust-Komponenten gelöst werden, die sich bei Bedarf andocken liessen.

Der Grad an OOP in Visual Basic ist ein genialer Kompromiss zwischen Reduktion von Komplexität und der optionalen Verwendung von Klassen als Behälter von Methoden und Daten da, wo es wirklich die Effizienz bei der Programmierung förderte. Dieser Ansatz sollte überhaupt nicht verändert werden.

Der Installer für die VB6-IDE könnte und müsste komplett neu gebaut werden, zum Beispiel mit Inno Setup.

Vollständige DPIAwareness, durchgängige UTF8-Fähigkeit und sogar ein 64Bit-Compiler könnten direkt in den VB6-Sourcecode eingebaut werden.

Da wo VB6 noch Ansi-Methoden in der Win32-API aufruft (z.B. WriteTextA), könnten wir diese durch UTF8-fähige W-Methoden (WriteTextW) ersetzen.

Wir, die Community würden diesen Task übernehmen und den genialen Ansatz von Visual Basic 6 ins Jahr 2026 befördern. Denn niemand von den ehemaligen VB6-Fans nutzt aktuell Visual Basic .NET wirklich mit Herzblut.

Und das muss für Microsoft ein Eingeständnis sein: die Entscheidung, VB6 einzustellen, und .NET als Nachfolger zu positionieren, ist gescheitert.

Viele der verbleibenden VB6-Entwickler müssen sich langsam umorientieren, verlieren die Geduld und gehen dann langsam aber sicher zu Linux und Rust über.

Oder Microsoft stellt den Visual Basic 6-Sourcecode offen, und wir, die Commity, holen uns diese geniale Entwicklungsumgebung für Windows ins Jahr 2026.

Das letztere wäre ein grosser Gewinn für die Community, für die Entwicklerschaft, die Anwender und sogar für die ganze Technologie-Branche.

Und nicht zuletzt wäre es ein grosses Plus für Microsoft, da die Entscheidung, den Source-Code zu Visual Basic 6 als Open Source bereitzustellen, auch den Ruf von Microsoft fördert und viele Fans & Entwickler zurückholen wird, und diese an das Microsoft-Ökosystem binden wird.

Das wäre ein ernst zu nehmender Gewinn für Microsoft würde ich sagen.