Die Zukunft von IBM VisualAge C++ für OS/2
Wie steht es eigentlich mit IBM VisualAge C++ für OS/2? Braucht es für OS/2 überhaupt einen "offiziellen" C/C++-Compiler mit Entwicklungs-Umgebung von IBM? Oder wäre es vielleicht sogar wünschbar, dass dieser Bereich ganz auf "Open Source" übergehen würde??
Angesichts gewisser IBM-Verlautbarungen mit anschliessenden Diskussionen in verschiedenen Foren stellen sich diese Fragen zur Zeit ganz aktuell. Dieser Beitrag soll einige Aspekte dazu erläutern und diskutieren; alle geäusserten Ansichten und Meinungen sind natürlich nur meine eigenen und nicht etwa "offizielle Statements" von wem auch immer!
Stand der Dinge
Am 18.7.2000 wurde unter dem Titel "Reminder of End of Service Dates for Compiler Products" ("Erinnerung End-Of-Service-Daten für Compiler-Produkte") auf verschiedene IBM-Newsgruppen (z.B. auf ibm.software.vacpp.misc, erreichbar über den news.software.ibm.com) die folgende lakonische Meldung gepostet (in deutscher Übersetzung):=== =============================
Wir möchten daran erinnern, dass das "Program Services"-End-Datum für die folgenden Compiler-Produkte für OS/2 und Windows NT am 31.Januar 2001 erreicht ist:- IBM VisualAge C++ for OS/2, Version 3.0
- IBM VisualAge C++ for Windows, Version 3.5
- IBM VisualAge C++ Professional for OS/2 and for Windows NT, Version 4.0
Dies bezieht sich auf den "Announcement letter" 298-239 unter dieser URL für VisualAge C++ for OS/2, Version 3.0 und VisualAge C++ for Windows, Version 3.5.
bzw. "Announcement letter" 298-473 unter dieser URL für IBM VisualAge C++ Professional for OS/2 and for Windows NT,Version 4.0.
Dwayne Moore VisualAge C++ Service & Support
================================ Die letzte Version für die beiden erwähnten Plattformen (Version 4.0) ist im Jahr 1998 herausgekommen und keine neue ist angekündigt. Zur gleichen Zeit ist für AIX - die dritte unterstützte Plattform - vor ein paar Monaten eine neue Version (5.0) erschienen. Auch die NT-Version scheint einen Schritt "weiter" zu sein als die OS/2-Version, indem dort im vergangenen Frühjahr das Fixpak #2 erschienen ist (Stand OS/2: Fixpak #1), aber der Grund dafür war vermutlich nur Windows2000, auf dem die alte Version nicht mehr richtig lief.
IBM hat also *nicht* offiziell gesagt, dass VAC++ für OS/2 und NT *nicht* mehr weiterentwickelt werden. Sie haben diesbezüglich aber auch keine positive Aussage gemacht: Wenn man will, darf man also weiterhin hoffen! Mir will allerdings scheinen, dass wir realistischerweise mit einer Produkteinstellung rechnen müssen.
Hiesse das dann, dass wir ab nächsten Januar keine OS/2-Programme mehr schreiben können? Natürlich nicht - und doch wäre die Einstellung ein *echter* Verlust für OS/2! Zugegeben: Es gibt andere gute Compiler, z.B. GNU C/C++ (EMX) - und das ist erst noch Open Source! VAC++ ist aber mehr als nur ein Compiler. Um die Situation zu verstehen, muss man die wichtigsten Teile von VAC++ einzeln betrachten: Dies ist die Absicht dieses Editorials. Da nicht alle Leser hier Programmierer sind, werde ich auch jeweils kurz charakterisieren, worum es sich bei den Teilen jeweils handelt.
Der Compiler
VAC++ bringt einen gut optimierenden, schnellen Compiler mit.Seit Version 4 ist er völlig neu geschrieben und unterstützt jetzt den vollen ANSI-C++-Standard sowie einige VAC++-spezifische, "revolutionäre" Extras: "Header-Dateien" und "Object-Dateien" werden weitgehend überflüssig, indem der übersetzte Code in einer "Codestore" genannten Datenbank gespeichert wird. Das bedeutet, dass nach einer kleinen Änderung wirklich nur der betroffene Code neu übersetzt werden muss, was einen grossen Zeitgewinn bedeutet.
Leider hat Version 4.01 (d.h. Version 4.0 mit Fixpak #1) mit allen diesen Features noch nicht die "Reife" der älteren Version 3.08 (Version 3.0 mit Fixpak #8) erreicht, sodass viele Entwickler die alte Version vorziehen: Ein solider und schneller C/C++-Compiler, der aber wiederum noch nicht alle neuen Konstrukte des ANSI-C++-Standards unterstützt. Dies ist besonders lästig, wenn man bestehenden Code aus irgendwelchen Quellen für OS/2 neu übersetzen (d.h. portieren) will.
Würde nun die Weiterentwicklung von VAC++ eingestellt, müsste man sich in Zukunft also weiterhin entscheiden, ob man "aktuellen Features" (Version 4.01) oder "solidem Handwerk" (Version 3.08) den Vorzug gibt: Auf eine Version, die beides zusammen bringt, müssten wir dann vergeblich hoffen!
Im reinen C/C++-Compiler-Bereich gibt es zu VAC++ auch noch Alternativen. Vielleicht die zwei wichtigsten:- GNU C/C++, mit EMX von Eberhard Matthes als der besten OS/2-Version: Für Anhänger von Open Source ist das bestimmt eine gute Wahl. (Die dazugehörige Laufzeitbibliothek emx.dll dürfte auf praktisch jedem OS/2-System schon fast zum Standard gehören.)
- Watcom C/C++, was in naher Zukunft ebenfalls als Open Source freigegeben werden soll und auch eine IDE mitbringt (siehe unten).
Beides sind (bzw. werden sein) gute und brauchbare Alternativen, die auch schon viel eingesetzt werden.
IDE - die Entwicklungsumgebung
Hier unterscheiden sich Version 3.0 und 4.0 gewaltig: Es handelt sich eher um zwei verschiedene Produkte als um zwei Versionen. Beide sind auf ihre Weise sehr mächtig, gut konzipiert, aber "gewöhnungsbedürftig", d.h. sie haben ihre festen Anhänger und entschiedenen Gegner. Sie unterscheiden sich beide stark von anderen IDE's (wie MS Visual-Studio oder Delphi). Der grosse Vorzug von Version 3.0 ist ein hohes Mass an "Objektorientiertheit", indem sie sich vorzüglich in die WPS einklinkt und sehr modular aufgebaut ist: Neue Tools lassen sich ebenso einbinden wie sich die mitgebrachten durch andere ersetzen lassen (Man könnte also im Prinzip auch den EMX-Compiler einbinden...). Die Stärke von Version 4.0 liegt dagegen in den fast unglaublichen Möglichkeiten, im Code auch eines sehr komplexen Projekts "herumzubrowsen", dank der "Codestore"-Datenbank.
Die Suche nach Alternativen zu diesen Tools ist viel schwieriger als die Suche nach anderen Compilern. Wer sich einmal speziell mit der Arbeitsweise von entweder Version 3.0 oder Version 4.0 angefreundet hat, wird fast alles andere nur noch als "Abstieg" empfinden können. Am leichtesten, und auch als Freeware oder Open Source, sind noch "Power-Editoren" zu finden, die neben Syntax-Highlighting und anderen "Goodies" auch den direkten Start von Compiler, Debugger usw. erlauben.(Aber auch einen guten Debugger, der den von VAC++ ersetzt, muss man wohl lange suchen...).
OCL - die Klassenbibliothek
Praktisch niemand schreibt C++-Programme, ohne sich die Arbeit mit zumindest einer Klassen-Bibliothek zu erleichtern. Dies gilt besonders für die Programmierung grafischer Oberflächen wie die des Presentation Managers. VAC++ die OCL oder "Open Class Library" mit. Diese ist insgesamt sehr gut durchdacht und mächtig und umfasst allgemeine Datenstrukturen (Strings, komplexe Zahlen, "Container" usw.) sowie alle Aspekte der graphischen Benutzeroberfläche. Daneben gibt es auch Bereiche, die nicht abgedeckt werden, z.B. Internet-Funktionen, für die man andere Bibliotheken suchen muss.
Alternative Klassenbibliotheken gibt es massenweise, zumal für Dinge, die nicht vom Betriebssystem abhängig und folglich leicht portierbar (Datenstrukturen usw.) sind. Für die PM-Programmierung ist die Situation schon etwas schwieriger. Hier dürfte die OCL wohl die Klassenbibliothek sein, die die PM-Architektur am "natürlichsten" einbindet, d.h. ohne sie in ein Windows- oder Unix-Korsett zu pressen. Trotzdem bietet sie auch eine gute Portierbarkeit nach Windows oder AIX - aber leider nicht Linux.
Ein weiteres gutes konzeptionelles Element der OCL ist die Trennung von Darstellung der Controls und Behandlung von zugehörigen "Ereignisse" (z.B. Mausklicks) in jeweils eigenen Klassen. Das erweist sich als wesentlich eleganter und mächtiger als andere Lösungen (z.B. "Microsoft Foundation Classes", wo mit einem Unmass an Macros gearbeitet wird). So etwas wie das "Notification framework" (mit Hilfe dessen sich verschiedene C++-Objekte "Nachrichten" schicken können) kommt in anderen Bibliotheken meist gar nicht erst vor.
Direkt ersetzbar ist die OCL also nicht: Eine Portierung von Code, der die OCL benutzt, auf irgendeine andere Klassenbibliothek kommt einer Neuentwicklung gleich. In den erwähnten IBM-Diskussionsforen wird darum auch schon vielfach gefragt, ob nicht die OCL einfach von IBM als "Open Source" freigegeben werden könnte. Es wurde sogar schon die Möglichkeit diskutiert, einen OCL-Clone für Linux neu zu schreiben: Tatsächlich wäre das eine wie das andere eine grossartige Sache: Es würde z.B. gute Möglichkeiten eröffnen, portablen Code für OS/2, Windows und Linux zu schreiben. Leider sind beides bisher nur Wunschträume oder gute Ideen...
"Visual Builder"
Der "Visual Builder" (VB) ist ein absolut einmaliges Werkzeug zur visuellen Programmierung, für welches es auch nicht im Entferntesten Alternativen gibt. Wäre es besser im Markt verankert, würde es ohne Zweifel das "visuelle Zeitalter" (= "visual age") der Programmierung einläuten. Das Marketing von Microsoft wusste sehr gut, warum es seiner Entwicklungsumgebung einen möglichst ähnlichen Namen gab ("Visual C/C++" statt "VisualAge C/C++"), aber das ist reiner Etikettenschwindel: Das MS-Produkt enthält keinerlei mit dem "Visual Builder" vergleichbares Programmier-Werkzeug - aber wer ausser ein paar Entwicklern merkt das schon?!?
Der VB erlaubt es nicht nur, Controls "visuell" in Dialogen zu platzieren, sondern er ermöglicht darüber hinaus, auch noch die Logik gleich mit zu "zeichnen". Auch nicht-visuelle Elemente (z.B. Listen, Variablen oder "Factorys", d.h. "Daten-Erzeuger") können verwendet werden. Aus diesen diagrammartigen Zeichnungen erzeugt der VB dann C++-Code, der auch noch durch eigenen Code ergänzt werden kann. Zwischen selber geschriebenem und grafisch erzeugtem Code ist jede beliebige Interaktion möglich, und es kann auch beliebig zwischen den beiden Arbeitsweisen hin und her gewechselt werden. Die so erzeugten "Parts" lassen sich dann wiederum in andere "Parts" einbetten und es ist auch möglich, andere "Parts" davon abzuleiten (d.h. das Konzept ist "objektorientiert").
Trotz diesen Möglichkeiten scheinen viele VAC++-Programmierer den VB nicht zu nutzen. Ein wichtiger Grund dürfte sein, dass er trotz seiner "Einfachheit" doch auch eine rechte Einarbeitung erfordert, bis man damit einigermassen produktiv wird. Besonders das Hin- und Herschalten zwischen "Handcodierung" und "grafischer Codierung" ist in der Dokumentation nicht gerade gut abgehandelt; Vieles bekommt man leider erst durch Herumprobieren heraus - und das wirkt natürlich (leider) eher abschreckend...
Fazit
Eine Einstellung der Weiterentwicklung von VAC++ würde die OS/2-"Gemeinde" sehr wohl schmerzlich treffen, auch wenn es für wesentliche Teile davon (Compiler, Klassenbibliotheken) Alternativen gibt. Wer die Zukunft von OS/2 in erster Linie im "Open-Source"-Bereich sieht (wie z.B. ich selber), könnte sogar versucht sein, den Verlust zu begrüssen, aber das schiene mir doch etwas kurzsichtig: EMX-C/C++ ist zwar ein guter Compiler, aber doch bei Weitem kein VAC++!
Wenn dann VAC++ allerdings doch eingestellt werden sollte, so würde ich mir ganz besonders die Freigabe von OCL unter einer "Open Source"-Lizenz wünschen - auch wenn ich mir diesbezüglich keine Illusionen mache. Aber wenn man so sieht, was in letzter Zeit sonst noch alles plötzlich freigegeben wurde!?!...
Selbstverständlich können auch die bestehenden Programm-Versionen weiterhin verwendet werden, zumal Oberfläche und API-Schnittstellen seit OS/2 2.0 ja in hohem Masse kompatibel geblieben sind und wohl auch bleiben werden. Am schmerzlichsten ist dabei dann nur die Aussicht, dass Version 4.0 nicht mehr den Grad an Solidität und relativer Fehlerfreiheit der Version 3.08 erreichen würde, was für ein Entwicklungs-Werkzeug besonders stört: Es reicht dem Entwickler meist vollkommen, den Fehlern und Abstürzen in den eigenen, halbfertigen Produkten nachzugehen ;-)
Bis jetzt konnte man sich als OS/2-Entwickler sagen: Ist auch die Auswahl an OS/2-Anwendungen in manchen Bereichen inzwischen etwas dünn, so haben wir doch immer noch eines der besten Entwicklungs-Systeme, wenn nicht *das* beste überhaupt! Dies immer mit einer leichten Einschränkung: *Wenn* IBM einmal die Version 4.0 richtig fertig und stabil bekommt...
Damit ist die Lage für VAC++ also ein wenig ähnlich der von OS/2 selber: Keine Illusionen, aber hoffen wir das Beste!
Cornelis Bockemühl, 2000-10-01
Kommentare: 23
|
![[Forum]](../../../images.os2.org/de/forum.gif){kind=small}
![[Forum]](../../../images.os2.org/de/forum2.gif){kind=small}
