VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
September 2003
[Inhaltsverzeichnis]
|
| Von Christian Langanke © September 2003 |
Es ist etwa zwölf Jahre her, seit ich damit begann, für OS/2 zu programmieren. Inzwischen ist meine Homepage voll von kleinen flotten Hilfsprogrammen, und es werden wohl noch mehr werden, denn da sind noch einige, die ich noch gar nicht veröffentlicht habe. Außerdem beherbergt netlabs.org mittlerweile CVS-Quelldateibäume von drei grösseren Projekten, von denen ich zwei initiiert habe und beim dritten an der Entstehung beteiligt gewesen bin. netlabs.org hält alle seine Softwarearchive mit Hilfe meines Netlabs Open Source Archive Administrators, der die Komplexität von CVS hinter einer Handvoll von leicht zu bedienenden REXX-Skripten versteckt, welche neben weiteren Funktionen das einfache Aufsetzen neuer Archive, die leichte Pflege derselben wie auch automatisches Backup anbieten. Mein gegenwärtig größtes Projekt, der Internet Assistent für OS/2 und eComStation, wird Bestandteil der eComStation V1.1 sein.
Also kann ich wohl sagen, dass ich eine Menge für OS/2 entwickelt und darüberhinaus eine Menge für die Entwicklung von freier OS/2-Software getan habe. Aber was bleibt für mich nach einer Dekade Programmierung in meiner Freizeit davon übrig? Was waren und sind die Gründe für mich, mit der Programmentwicklung für OS/2 und nun für eComStation anzufangen und auch dabei zu bleiben?
Sehr ähnliche Fragen sind schon oft an Endanwender gestellt worden, aber was ist mit der Perspektive von Entwicklern? In welche Richtung kann ich - als ein Beispiel eines OS/2- und eComStation-Freeware-Entwicklers - mich bewegen? Habe ich alles Notwendige zur Verfügung, um meine Projekte weiter programmieren und debuggen (testen) zu können? Und warum könnten diese Fragen überhaupt für einen Endanwender von Interesse sein?
Das sind viele Fragen, und dieser Artikel versucht, darauf einige Antworten zu geben, natürlich von meinem sehr subjektiven Standpunkt aus gesehen. Nun mögen Sie sich fragen, warum ich so etwas in einem Medium veröffentliche, von dem man erwarten würde, dass es zumeist eher von Endanwendern gelesen würde. Die Antwort darauf ist, dass ich in letzter Zeit den Eindruck gewonnen habe, dass es für Endanwender sehr wohl sinnvoll sein könnte, einen Einblick in die Welt der Programmierer zu erhalten, um zu erfahren, wie gut oder schlecht die Dinge dort liegen. Und es könnte auch klar machen, dass dies den Endanwender auch voll betrifft, wenn auch nicht in Fragen der Programmierung, aber dann in Art, Qualität und Menge der Anwendungen, die von Programmierern für ihre Plattform bereitgestellt werden. In der Tat gibt es ja konkrete Gründe für die Anzahl der verfügbaren Freeware/Shareware-Anwendungen für eine bestimmte Plattform, und dieser Artikel mag Ihnen einige davon offenbaren. Gleichzeitig gibt dieser Artikel aber auch Programmierern, oder Menschen, die es werden wollen, vielleicht ein paar Anregungen mit.
Natürlich möchte ich hier nicht von einem zu technischen Standpunkt her an das Thema herangehen, so dass nicht nur Programmierer, sondern auch Endanwender mit dem Text klar kommen sollten. Die Verwendung von einigen Abkürzungen ist jedoch erforderlich, um präzise bleiben zu können. Wenn Sie etwas davon nicht verstehen, fragen Sie bitte per E-Mail zurück, ich erkläre jederzeit und gerne offene Fragen.
In der Vergangenheit beeindruckte OS/2 mich mit einem eleganten API und großartigen Programmierkonzepten, und das ist immer noch so. Aber was ist vom Glanz vergangener Jahre geblieben? Und was könnte heute neue Herausforderungen und neuen Programmierspass bringen?
Also, was brauche ich nun zum ernsthaften Programmieren? Um ganz klar zu sagen, was ich meine: Es geht um C/C++ und vielleicht auch Pascal-Programmierung, wobei im folgenden nur C/C++-Kompiler betrachtet werden. Es gibt einige Kompiler für OS/2, die weitere Programmiersprachen übersetzen können, aber die sind nur wenig verbreitet und spielen daher hier keine Rolle. Ich zähle außerdem ganz sicher auch REXX und weitere Skriptsprachen nicht in diese Kategorie, obwohl ich ein grosser REXX-Fan bin. Aber Skriptsprachen wie REXX sind besser geeignet, um benutzerspezifische Erweiterungen für "richtige" Anwendungen zu erstellen, wobei diese Erweiterungen dann sogar vom erfahrenen Endanwender erstellt werden können. Wenn noch nicht klar ist, was ich genau meine: Sie werden niemals einen Apache-Webserver oder einen Mozilla-Webbrowser in REXX sehen, aus ganz offensichtlichen Gründen...
Nun, um ein paar nette OS/2-Programme zu erstellen, brauchen Sie nicht viel, nur einen Kompiler und das Developers Toolkit für OS/2. Vorbei sind die Zeiten der ersten OS/2-Versionen, wo Microsoft das Developers Toolkit für OS/2 für rund 2.500 Dollar verkaufen wollte, heute ist es frei verfügbar. Bezüglich Kompilern gibt es gute Alternativen zu den noch existierenden IBM-Kompilern. Diese Alternativen werden auch immer wichtiger, da die IBM-Kompiler seit mehreren Jahren nicht mehr erhältlich sind und nicht mehr unterstützt bzw. gepflegt werden. Dennoch werden sie noch von vielen OS/2-Projekten benutzt, da einige Funktionen noch immer nicht in den Alternativen enthalten sind.
Als eine wichtige Alternative ist zu allererst der OS/2-Port des freien GNU-Kompilers zu nennen, den es bereits seit langer Zeit gibt. Er ist besonders wichtig, wenn es darum geht, Linux-Programme nach OS/2 zu portieren. Unglücklicherweise lässt der GNU-Kompiler aber einige wichtige Eigenschaften vermissen, zum Beispiel und an erster Stelle fehlt ein wirklich guter Debugger, was die Verwendbarkeit des Kompilers um einiges einschränkt, besonders für grössere Projekte. Zweitens muss hier der Open-Watcom-Kompiler genannt werden, der zwar immer noch eine gewisse Überarbeitung gebrauchen könnte, aber zusammen mit dem GNU-Kompiler letztlich ein verfügbarer C/C++-Kompiler für OS/2 ist, der noch unter Entwicklung steht. Lassen Sie uns hoffen, dass beide Kompiler sich gut auf der OS/2- und eComStation-Plattform weiterentwickeln, denn wie wir weiter unten sehen werden, wird dies mehr und mehr wichtig.
Als ein Endanwender mögen Sie sich vielleicht fragen, warum dies für Sie von Interesse sein sollte. Nun, der Kompiler ist für Programmierer etwa so wichtig wie die Office Suite für den Endanwender. Bezüglich Firmen, die OS/2 verwenden, habe ich mehr als eine Firma gesehen, die weg von OS/2 gegangen ist, nicht etwa, weil zuwenig Endanwendungen verfügbar gewesen wären, sondern weil zuwenige oder keine passenden Kompiler, Projektmanagement-Software, Problemverfolgungs-Software usw. verfügbar waren, mit denen sie ihre Inhouse-Entwicklung von Anwendungen hätten bestreiten können.
Genau dasselbe trifft auch für die Freeware- und Shareware-Entwicklergemeinde zu. Um es für jeden verständlich auf den Punkt zu bringen: Wenn keine Kompiler mehr für OS/2 zur Verfügung stehen, die den Quellkode von grossen Projekten mit aktuellen Sprachkonstrukten übersetzen können, wird es keine weitere OS/2-Versionen von Programmen geben, selbst von denen nicht, an die Sie sich vielleicht bereits gewöhnt haben.
Lassen Sie mich zwei Beispiele nennen: die letzte OS/2-Version von StarOffice war V5.1, danach wurde die OS/2-Linie eingestellt. Als ersten Grund für die Einstellung wurden Probleme und Fehler mit dem Kompiler IBM Visual Age V4 genannt, der, so hörte man es allenthalben, zu dieser Zeit angeblich schlecht unterstützt wurde. Der zweite Grund war, dass eine Umstellung auf den freien GNU-Kompiler nicht möglich war wegen des fehlenden Debuggers, der ja tatsächlich bei einen solchen grossen Projekt unbedingt erforderlich ist, um Fehler zu finden.
Am Ende konnte der Endanwender weiterhin mit der alten V5.1 vorlieb nehmen (was ich immer noch tue) oder OpenOffice V6.0 unter VirtualPC verwenden. Die Tatsache, dass Drucken gegenwärtig unter Odin nicht unterstützt wird, schliesst diese zunächst offensichtliche Option leider aus.
Ein weiteres gutes Beispiel ist Mozilla. Nein, keine Panik, der OS/2-Port von Mozilla wird nicht eingestellt, aber laut Mike Kaply, dem Besitzer des OS/2-Ports, werden neuere Versionen von Mozilla für OS/2 nicht länger mit dem Visual-Age-Kompiler übersetzt werden. (Sie errinnern sich: der seit Jahren nicht mehr unterstützt wird!). Stattdessen soll für den OS/2-Port nun der GNU-Kompiler verwendet werden.
Aber ist das nicht eine kleine Überraschung? Ich wäre sehr interessiert zu erfahren, wie die Entwickler des Mozilla für OS/2 das Debugger-Problem gelöst haben, da ich voraussetze, dass auch für die Pflege eines Mozilla-Ports ein funktionierender Debugger zur Fehlersuche unabdingbar ist. Ich erinnere mich, mal ein Gerücht gehört zu haben, dass es eine Lösung derart gegeben hat, dass man Programme, die mit dem GNU-Kompiler erstellt wurden, mit dem immer noch recht guten Debugger des Visual-Age-Kompilers testen kann, obwohl das wegen Inkompatibilitäten zwischen den Kompilern eigentlich nicht geht. Und das übrigens zu einer Zeit, als StarOffice für OS/2 eingestellt wurde, weil man ja keine Möglichkeit gehabt habe, Programme zu debuggen, die mit dem GNU-Compiler erstellt wurden...
Als Schlussfolgerung bleibt, dass eine gegenwärtig grosse Gefahr für die OS/2- und eComStation-Plattform tatsächlich darin besteht, dass zu irgendeinem Zeitpunkt (in nächster Zukunft?) das grösste Problem nicht etwa ist, dass Software-Hersteller und Freeware-/Shareware-Entwickler die OS/2-Plattform einfach verlassen, sondern dass selbst diejenigen, die bleiben wollen, dies nicht länger können, weil grundlegende (!) Entwicklungswerkzeuge fehlen. Bereits jetzt, oder genauer, bereits seit einiger Zeit sehen sich Entwickler und Pfleger von grossen Softwareprojekten für OS/2 und eComStation massiven Problemen gegenüber, die nur schwer zu lösen sind.
Nette Technologien und Konzepte zur Verfügung zu haben ist nicht die einzige, aber immer noch die wichtigste Motivationsquelle für Programmierer, besonders für die, die freie Programme erstellen. Hier muss Programmierung Spass machen, oder es ist weniger wahrscheinlich, dass überhaupt programmiert wird. Und obwohl ein Konzept und ein Werkzeug nur so gut ist wie derjenige, der es einsetzt, sind gute Konzepte eine Basis für die Erstellung von qualitativ guten und einfach zu bedienenden Benutzerschnittstellen. Wenn ein Konzept oder ein Werkzeug nicht gut ist, wird die Aufgabe, eine gut durchdachte Benutzerschnittstelle zu implementieren, wahrscheinlich mehr Aufwand erfordern und weniger wahrscheinlich zum Erfolg kommen. So sind auch Programmierschnittstellen ein Thema, das indirekt auch wichtig für den Endanwender ist, denn je besser die Programmierkonzepte sind, desto wahrscheinlicher werden Programme verfügbar werden, die eine einheitliche Benutzerschnittstelle haben, so wie sie die Arbeitsoberfläche selbst anbietet.
Ein gutes Beispiel, wo eine konsistente Benutzerschnittstelle mit demselben "Look and Feel" nicht über alle Anwendungen gegeben ist, ist Linux. Als nur ein Beispiel hierfür sind Anwendungen zu nennen, die in Tcl geschrieben sind und die TclTk-Laufzeitbibliothek verwenden, wodurch sie signifikant anders aussehen und sich in der Bedienung anders verhalten als zum Beispiel Programme, die die QtLib-Laufzeitbibliothek verwenden. Wenn Sie nun die Situation mit Dutzenden von Benutzerschnittstellen und deren "Look and Feel" unter Linux mit der Situation unter OS/2 und eComStation vergleichen, wo solche Unterschiede nur selten anzutreffen sind, wird es klar, was für sichere Häfen OS/2 und eComStation im Bezug auf eine einheitliche Benutzerschnittstelle sind.
Aber lassen Sie mich an den Punkt zurückkommen, an dem ich mit OS/2-Programmierung angefangen habe, und gelernt habe, die Programmierschnittstellen von OS/2 zu schätzen. Ich erinnere mich sehr gut an meine ersten Programme für den OS/2 Presentation Manager. Kurz danach startete diese unsägliche "OS/2 ist tot"-Diskussion bereits, was mich veranlasste, mal einen Einblick in das Chaos der verschiedenen Win32-APIs zu nehmen (Gab es davon nicht vier oder fünf unterschiedliche?). Dies liess mich schaudern...
Ich war so froh, dass es ein klar strukturiertes OS/2-API gab, an dem ich mich festhalten konnte - man sah in einen Quellcode von jemandem anderen und konnte selbst als Anfänger, ohne tiefgreifende Kenntnis aller Funktionsnamen des Betriebssystems sofort sagen, welche Funktionsaufrufe z.B. vom Betriebssystemkern oder vom grafischen Subsystem abgehandelt würden, und welche Aufrufe offensichtlich von der Anwendung selbst implementiert würden. All dies ist einfach möglich, weil alle Funktionsnamen des OS/2-APIs immer mit einem Präfix aus drei Buchstaben versehen sind. Wenn ich im Gegensatz dazu einen Blick in Win32-Quellcode wagte, wo die APIs nicht solchen Regeln folgen, musste ich entweder ausdrücklich wissen, dass eine bestimmte Funktion Teil des Betriebssystems ist, oder ich musste den Namen zunächst in der Online-Hilfe suchen - mit einem Wort: Albtraum. Tatsächlich ist der einzige Teil des Windows-APIs, der gut strukturiert war, das 16-Bit API von OS/2, das von Microsoft bis zu und inklusive Windows NT für die Unterstützung ihrer LAN-Manager-Anwendungen (OS/2-Vollbildschirm) im Textmodus mitgeführt wurde.
Aber der eigentliche Meilenstein für Betriebssysteme und der entscheidende Pluspunkt auf Seiten von OS/2 war und ist die Workplace Shell, die zuerst mit OS/2 V2.0 kam. Diese aussergewöhnliche Software gewann einen Preis für die beste Software (war es im Jahre '92 oder '93) und wird von vielen Seiten immer noch für die innovativste und intuitivste Benutzerschnittstelle gehalten, die jemals im Betriebsystemmarkt verfügbar gewesen ist. Zwei Jahre später begann ich selbst, einige Workplace-Shell-Klassen zu programmieren, die in meiner Veröffentlichung einer recht bekannten Workplace-Shell-Erweiterung im Jahre 1997 resultierte, nämlich der "Animierten Mauszeiger für OS/2".
Mit diesem Paket hatte es durchaus etwas besonderes auf sich: während es für den Endanwender einfach mehr Spass mit OS/2 bedeutete, war es für mich als Programmierer noch viel interesanter. Viele Endanwender wissen nicht, dass die Workplace Shell auch eine brilliante Programmierschnittstelle bietet, denn unter der Oberfläche besteht sie aus einer echten objekt-orientierten Klassenbibliothek. Nein, ich werde jetzt nicht so sehr ins Detail darüber gehen, was das genau bedeutet, nur soviel dazu: Dank dieser wunderbaren Programmierschnittstelle konnte ich einfach die Mauszeigerseite im Mausobjekt ersetzen und die Animation als eine völlig neue Funktion hinzufügen, ohne etwa das ganze Mausobjekt neu programmieren oder Original-Quellcode verändern zu müssen (was ja ohnehin nicht möglich gewesen wäre...).
Aber was war neben der neuen Funktionalität der zusätzliche Nutzen für den Endanwender? Es war und ist die Tatsache, dass das veränderte Mausobjekt exakt genauso benutzt werden kann wie das alte, bis zur letzten Funktion, so dass es keine Verwirrung um eine veränderte Benutzerschnittstelle gibt. Die neue Mauszeigerseite sieht sogar exakt so aus wie die alte, bis auf eine Textstelle im Dialog. Dennoch bietet sie zur gleichen Zeit völlig neue Funktionen, nicht nur die Animation, sondern auch komplette Unterstützung für Drag&Drop (Ziehen und Übergeben) und Kontextmenüs für den Mauszeiger-Container auf dieser Seite.
Den schönsten Kommentar, den ich zu diesem Paket erhalten habe, und auf den meiner Meinung nach jeder Programmierer einer Erweiterung für die Workplace Shell stolz sein kann, war: "Wenn ich nicht gewusst hätte, dass es ein extra Paket ist, hätte ich gedacht, es wäre ein Bestandteil von OS/2 Warp selbst". Ich meine, besser kann keine Integration von neuer Funktionalität nicht gelingen, und ich schulde einen grossen Teil dieses Kompliments der eleganten Programmierschnittstelle der Workplace Shell. Und diese Fähigkeit zur eleganten und nahtlosen Integration neuer Funktionalität ist sicherlich auch das, was ich am meisten an ihr mag.
Neben viel Spass mit diesem Programm bedeutete es auch einen "proof of concept", also einen Machbarkeits- und/oder Tauglichkeitsbeweis, und ich hoffte darauf, dass es dasselbe für die ganze OS/2-Freeware und -Shareware-Entwicklergemeinde bedeuten würde. Ich hatte ja Grund genug, mich wie ein Pionier in Sachen Workplace-Shell-Programmierung zu fühlen, schliesslich war 1997 meine Mauszeiger-Erweiterung das erste grössere, aber dennoch nicht kommerzielle verfügbare Erweiterungspaket für die Workplace Shell, mit engster Integration von neuer Funktionalität in die existierende Benutzerschnittstelle der Arbeitsoberfläche, kompletter Online-Hilfe und Konfiguration über Einstellungsbefehle (settings strings). Ich hoffte also, dass wesentlich mehr Programmierer dem Beispiel folgen und direkt für die Workplace Shell programmieren würden.
Bald folgen andere, und einige Zeit später erschien das Paket XFolder von Ulrich Möller, welches mittlerweise zum unglaublichen und sehr bekannten XWorpklace-Paket angewachsen ist und unzählige grossartige Funktionen enthält. Dieses Paket definiert wahrlich eine neue Dimension, wenn nicht gar einen neuen Standard von Bedienbarkeit für die Workplace Shell unter OS/2 und eComStation, und macht sich selbst damit zu einem der wichtigsten Software-Pakete für diese Plattform. Nur folgerichtig ist, dass eine vereinfachte Version, genannt eWorkplace, integraler Bestandteil der eComStation V1.1 geworden ist (die sich aber problemlos durch die volle XWorkplace-Version ersetzen lässt).
Vielleicht verstehen Sie daher den Enthusiasmus, den ich in diesen Tagen hatte, und ich meine, die Gründe, über die Workplace Shell als Benutzerschnittstelle sowie auch als Programmierschnittstelle enthusiastisch zu sein, haben nicht an Bedeutung verloren. Aber wie immer gibt es zwei Seiten einer Medaille.
Man könnte nun sagen: "Die Workplace Shell sieht nun mittlerweile alt aus, verglichen mit den Benutzerschnittstellen auf anderen Plattformen". Stimmt nicht, würde ich antworten, da es auch unter eComStation eine Unterstützung für Themen gibt, so dass Sie es auch hier viel farbiger, wenn nicht sogar viel zu farbig machen können, genau wie auf anderen Systemen.
Na gut, ein Endanwender mag sich damit zufrieden geben, das hängt von seinem Geschmack und anderen Gründen ab. Aber was ist an dieser Stelle mit dem Programmierern? Die Workplace Shell ist nur ein weiterer Teil von OS/2, an dem vom Hersteller weder weitergearbeitet noch Fehler gefixt werden, und es gibt mehr als ein Problem in der Implementation, das der Endanwender nie bemerken wird, Workplace-Shell-Programmierer aber wieder und wieder umgehen müssen. Aber auch, wenn dies alles stimmt, bin ich ziemlich sicher, dass das Potenzial der Workplace Shell und das der direkten Programmierung für sie nicht annähernd ausgeschöpft ist, gleichgültig jedweder Einschränkung, die aus nicht korrigierten Fehlern oder teilweise merkwürdigem Design herrührt.
Für meine Einstellung gibt es Gründe: Obwohl die Workplace Shell nicht perfekt ist, kann ich immer noch Erweiterungen für sie erstellen. Obwohl sie nicht weiter entwickelt wird, kann ich immer noch Erweiterungen für sie erstellen. Obwohl Fehler nicht behoben werden, kann ich immer noch Erweiterungen für sie erstellen. Obwohl XWorkplace einige Implementierungsgrenzen erreicht haben mag, weil die Workplace Shell hinter ihrer Programmierschnittstelle unglücklicherweise teilweise merkwürdig, wenn nicht gar fehlerhaft entworfen wurde, kann ich XWorkplace mit den heute verfügbaren Funktionen und Erweiterungen nutzen, und es gibt keinen Grund, warum gar keine neuen Funktionen hinzugefügt werden können. Ja, es mag Einschränkungen geben, aber ich bezweifle, dass sie uns sehr beeinträchtigen werden, wenn Programmierer sich mehr darauf konzentrieren, was dennoch möglich ist, und das scheint immer noch eine Menge zu sein.
Aber ist das die einzige Frage, die wir uns stellen müssen? Wir erinnern uns, Programmieren muss Spass machen. Dies ist eine wichtige Motivationsquelle. Damit ist es eine Entscheidung eines jeden einzelnen Programmierers, ob er oder sie dabei bleiben möchte bei der Programmierung für die Workplace Shell, trotz ihrer Einschränkungen. Alles, was ich dazu sagen kann ist, dass es wirklich Spass macht, die Eleganz des Konzepts zu erfahren, und inzwischen gibt es genug Erfahrungswerte in der Entwicklergemeinde, um etwaige Probleme zu umschiffen.
So bleibe ich als Endanwender und Programmierer gerne bei der Workplace Shell und würde ihre Konzepte und Schnittstellen unter jeder anderen Plattform schmerzlich vermissen. Aber die Workplace Shell ist nicht die einzige Technologie, an die wir denken sollten. Was ist mit den anderen Technologien, die wir in OS/2 und nun eComStation finden? Wie passen sie in das Bild? Diese und weitere Fragen werden im zweiten Teil dieses Artikels beleuchtet.
Daten und Quellen:
|
Heimseite von Christian Langanke: http://www.clanganke.de/
Internet Assistent für OS/2 und eComStation: http://www.teamruhr.de/iaos2
Heimseite des Workplace Shell Toolkit: http://wpstk.netlabs.org
Dynamic Windows GUI Bibliothek: http://dwindows.netlabs.org
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org