Zoologie

Wer unter OS/2 Share- oder Freeware in C entwickeln will, kann bedenkenlos zur emx-Distribution des GNU C/C++-Compilers greifen. Für den C++-Programmierer war das Paket aber bislang weniger attraktiv, denn ihm fehlte das entscheidende Zubehör: eine Bibliothek für die PM-Programmierung. Da hieß es, sich mit dem verhaltenen Esprit einer IBM Open Class Library anzufreunden, die nur im Bundle mit Visual Age zu bekommen ist, oder aber sich in der Shareware nach dünn gesäten Alternativen umzusehen.

Die Cubus OS/2 Class Library (OCL) bietet in der Version 1.50 zwar viele der dringend benötigten Klassen. Sie arbeitet aber mit C++-Exception-Handling, einem Feature, das der gcc gerade erst gelernt hat und noch keineswegs gut beherrscht. Mit der Open Objects Library (OOL) macht nun eine weitere Freeware-Bibliothek für OS/2 auf sich aufmerksam. Sie ist der emx-Distribution auf den Leib programmiert. Doch das ist bei weitem nicht das einzige, was sie auszeichnet.

Wildwuchs contra Zucht

Der entscheidende Unterschied zwischen der OCL und der OOL ist ihre Entstehungsgeschichte. Während die OCL relativ unkoordiniert von der System- zur GUI-Bibliothek gewachsen ist, haben die Autoren der OOL (Stefan von Brauk und Jens von Pilgrim) von Anfang an ganze Arbeit geleistet. Die derzeit verfügbare Alpha-Release 2 der OOL kommt mit etwa 100 Klassen vorwiegend für die GUI-Behandlung, sechs Beispielapplikationen - und einer beeindruckenden Dokumentation im HTML-Format.

Das Klassengebäude wirkt - zumindest was die GUI-Behandlung betrifft - bereits nahezu vollständig. Selbst Multimedia-Klassen für die Wiedergabe von Videos und Sound-Dateien und Dialogklassen für Farb-, Font- und Dateidialoge fehlen nicht. Ist die Bezeichnung als Alpha-Release tiefgestapelt? Nicht ganz. Ein Blick ins Innere der Bibliothek zeigt, daß hier zwei Leute am Programmieren sind, die ihr Handwerk bestens verstehen und sehr genaue Vorstellungen davon haben, wohin es mit der Bibliothek gehen soll. Er zeigt aber auch, daß dem Skelett noch das Fleisch fehlt. Einige Klassen, die bereits in der Hierarchie auftauchen, sind noch nicht implementiert. Die anderen verfügen - noch - über zu wenige Methoden. Doch wie die OCL hofft auch die Open Objects Library auf Erweiterungen durch Dritte - die Benutzer der Bibliothek. Und da die OOL bereits in diesem frühen Stadium gut dokumentiert ist, stehen ihre Chance, schnell an Funktionalität zuzulegen, nicht schlecht.

Die Struktur der Bibliothek ist an die der Open Class Library angelehnt. Wie das IBM-Produkt setzt die OOL für die GUI-Klassen Events und Event Handler ein. Dabei können Fenster-Objekte ein oder mehrere Event Handler für eine bestimmte Art von Events registrieren. Die Standard-Window-Prozedur der OOL, die allen Fensterklassen als Interface zum PM dient, setzt bestimmte Nachrichtengruppen in korrespondierende Events um und stellt sie an alle registrierten Handler zu. Gegenüber der OCL, die PM-Window-Prozeduren auf eine virtuelle Command-Methode der Fensterklassen umleitet, bringt dieser Mechanismus einen Overhead mit sich. Er bedeutet im Gegenzug jedoch auch mehr Komfort und Flexibilität.

Post Office

Wegen der Schwierigkeiten des gcc mit dem Exception Handling arbeitet die OOL mit Return Codes anstelle von Exceptions. Die Autoren stellen Exception-Klassen und eine entsprechende Anpassung für spätere gcc-Versionen zwar in Aussicht, unterschätzen aber wohl die Problematik, eine komplette Bibliothek im nachhinein auf eine andere Art der Fehlerbehandlung umzustellen. Die wichtigsten Vorkehrungen - etwa die konsequente Ableitung von einer zentralen Basisklasse - sind aber bereits getroffen. Da die OOL nur in dynamisch gelinkter Version frei verwendet werden darf, muß der Programmierer auch innerhalb des Applikationscodes auf Exception Handling verzichten, denn bei der Verwendung von C++-DLLs quittiert der gcc bislang Exceptions noch mit dem Systemfehler SYS3175.

Der Entwicklungsschwerpunkt lag bislang eindeutig bei den GUI-Klassen. Im Bereich der Interprozeß-Kommunikation und anderen Systemfunktionen klafft eine große Lücke. Auch für die Landessprachenunterstützung fehlt noch eine Lösung. Die Erklärung für diese Aussparungen in der Klassenplanung scheint die spätere Portierbarkeit zu sein. Sie ist für die Autoren das wichtigere Kriterium als eine vollständige Klassenabdeckung der OS/2- und PM-Funktionen. Hoffentlich verlieren sie dabei eines nicht aus dem Blick: Das OOL-Projekt ist auf längere Sicht stark auf die Mithilfe anderer OS/2-Entwickler angewiesen. Wer ist schon in GUI-, Netzwerk-, OpenGL- und DIVE-Entwicklung gleich fit?

Eine Anpassung auf die Compiler von Borland, IBM und Watcom wäre darüber hinaus wünschenswert. Der OWL/PM von Borland kauft die Open Objects Library jedenfalls im Handstreich den Schneid ab. Mit der IBM-Bibliothek kann sie zwar in puncto Funktionalität nicht konkurrieren. Dafür ist sie wesentlich schneller und mit gerade einmal 135 KB für die Runtime-DLL auch deutlich schlanker. (jk)