VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
November 2001
[Inhaltsverzeichnis]
|
| Von Michal Necasek © November 2001, Übersetzung: Carsten Kettner |
Als IBM die OS/2 Version 2.0 im März 1992 veröffentlichte, geschah dies nicht ganz unerwartet. Tatsächlich wurde das 32-Bit OS/2 seit den frühesten Tagen von OS/2 versprochen und Gordon Letwin skizzierte deutlich in seiner Inside OS/2 (bedenken Sie, daß dieses Buch 1988 veröffentlicht wurde) die Merkmale von "OS/2 - 386". Die Arbeit am 32-Bit OS/2 - Codename Cruiser - begann wahrscheinlich irgendwann 1988, als IBM und Microsoft noch an einer anderen Front eifrig an OS/2 1.2 hackten. Während IBM (nun alleine) an OS/2 1.3 arbeitete, war die Entwicklung von Cruiser bereits gut fortgeschritten. Der führende Entwickler von OS/2 2.0 war Michael S. Kogan, Co-Autor des exzellenten (aber ziemlich technischen) Buches The Design of OS/2 (Das OS/2 Design - Anm.d.Übers.)
Dieses Mal springen wir direkt zu einigen Screenshots. OS/2 2.0 sah so aus:
Nun höre ich die OS/2-Oldtimer schreien "Gar nicht!" - aber seien Sie versichert, daß dies nicht mein Fehler ist. Der obige Screenshot stammt von OS/2 2.0 LA - das heißt "Limited Availability" (eingeschränkte Verfügbarkeit - Anm.d.Übers.) (ich nehme an, es ist heute ein Sammlerstück). Diese Ausgabe wurde nicht - wie der Name sagt - im Einzelhandel verkauft, sondern nur an Betatester und "spezielle" Kunden ausgegeben. OS/2 2.0 LA wurde irgendwann im November 1991 ausgeliefert - wahrscheinlich um Microsofts Steve Ballmer zu ärgern, der öffentlich verkündete, daß er eine Floppydiskette essen würde, wenn IBM es schaffen würde, OS/2 bis Ende 1991 auszuliefern. (Leider aß Mr. Ballmer die Floppydisk nicht in der Öffentlichkeit und böse Zungen behaupteten sofort, daß er nicht Wort halten würde. Einige machen eben vor nichts halt, um dem strahlenden Image von Microsoft den Glanz zu nehmen.) Ein anderer möglicher Grund für die LA-Ausgabe war die Tatsache, daß IBM seinen Kunden versprochen hatte, 1991 ein 32-Bit OS/2 auszuliefern, und IBM hält für gewöhnlich seine Versprechen, oder versucht es zumindest.
Die LA-Verison sah der GA-Ausgabe (General Availability; allgemeine Auslieferung - Anm.d.Übers.) sehr ähnlich, aber sie war offensichtlich unfertig und kam zusammen mit einer langen README-Datei heraus, in der all die Dinge, die noch nicht liefen, aufgelistet waren. Das schmerzlich vermißte Merkmal war die nahtlose Einbindung von Win-OS/2, also die Möglichkeit, Windows 3.0-Anwendungen auf dem OS/2-Desktop auszuführen. OS/2 2.0 LA unterstützte jedoch Windows-Anwendungen, wenn auch nur im Vollbildmodus. Interessanterweise war die in 2.0 LA eingebaute Windows-Version nicht als "IBM Win-OS/2" gekennzeichnet, sondern einfach als "Microsoft Windows 3.0a" und so weit ich es sagen kann, waren in der Tat die meisten Binaries identisch mit Windows 3.0a.
OS/2 2.0 LA hatte ein etwas anderes Aussehen - wie der Screenshot zeigt, waren die Mini-Icons im Fenster von der Titelleiste getrennt, anstatt den Systemmenübutton zu ersetzen. Dies geht auf die alte IBM CUI '91-Demo zurück, genauso wie die Bezeichnung Content auf dem offenen Verzeichnis.
OK, werfen wir mal einen Blick auf das "richtige Ding". OS/2 2.0 GA sah so aus:
Wie Sie sehen können, war der Unterschied nicht groß,
obwohl der GA-Desktop etwas dichter belegt war.
Es sollte niemanden überraschen, daß einige OS/2 2.0 Betatester
total gegen die WPS waren. Einige Jahre später behaupteten viele Leute
(wahrscheinlich sogar dieselben Leute), die WPS sei das Merkmal
von OS/2.
Intern war die 32-Bit-Geschichte ein wenig anders. Große Teile des Systems waren immer noch 16-bittig - hauptsächlich wegen des Zeitdrucks und der Kompatibilität. Zeitdruck führte auch dazu, daß das Grafiksubsystem (und folglich die PM-Treiber für Video und Drucker) in OS/2 2.0 noch 16-bittig waren (aber später in OS/2 2.1 wurden sie gegen 32-Bit-Versionen ausgetauscht). Die Kompatibilität diktierte die Verwendung von mit OS/2 1.3 kompatiblen, 16-bittigen physikalischen Gerätetreibern (PDD = Physical Device Driver) in OS/2 2.0. Ebenso waren große Bereiche des OS/2-Kernels 16-bittig, um die alten 16-Bit OS/2-Anwendungen zu unterstützen.
Aber die Hauptteile des Systems waren komplett neu und vollständig
32-bittig, wie beispielsweise die Multiple Virtual DOS Machine (MVDM)-Unterstützung
(zum Betrieb mehrerer getrennter DOS-Sitzungen - Anm.d.Übers.) oder der
Speicher-Manager mit der Seitenunterstützung. Der neue Code war größtenteils in C geschrieben und nicht im alten Assembler-Code wie in 1.x.
Die Windows-Anwendungsunterstützung war eine logische Erweiterung der DOS-Unterstützung. Vollbild-Win-OS/2-Sitzungen würden im wesentlichen unverändertes Windows 3.0 in einer virtuellen DOS-Umbebung laufen lassen. Nahtlos eingebundene Win-OS/2-Sitzungen waren ein bißchen kniffliger, weil sie mit PM/WPS-Anwendungen koordiniert werden mußten. Dies wurde durch spezielle Versionen der Win-OS/2-Bildschirmtreiber erreicht. Der Ansatz, den IBM verwendete, versprach zwar ein Maximum an Leistungsfähigkeit, aber er hatte leider auch einen großen Nachteil - er erschwerte deutlich die Herstellung von OS/2-Grafiktreibern (mit anderen Worten: es wurde teurer) und war zweifellos einer der Faktoren, die in der Folge zu einer begrenzten Verfügbarkeit von Treibern beitrugen. So mußten die Hardware-Hersteller einen volltauglichen OS/2-Treiber und eine für OS/2 spezifische Version eines Windowstreibers schreiben. Was IBM hätte tun können, wäre einen "überbrückenden" Treiber zu schreiben, der Win-OS/2- an PM-Aufrufe bindet, so daß die Hersteller nur noch einen OS/2-Treiber hätten schreiben müssen (diese Idee wurde später mit den GRADD-Treibern aufgegriffen).
Die DOS-Unterstützung in OS/2 war aber exzellent. Viele Anwender benutzen OS/2, obwohl sie in erster Linie nur DOS-Anwendungen laufen ließen, einfach aufgrund der zusätzlichen Multitasking-Fähigkeiten. Ich persönlich glaube, daß die DOS-Unterstützung von OS/2 die beste, übertroffen nur von echten DOS, aber besser als in Windows 9x (nicht zu reden von NT) ist.
Jetzt im nachhinein kann ich sicher sagen, daß dieses sehr gute
Niveau der Unterstützung von DOS- und Windows-Anwendungen ein zweischneidiges
Schwert war. Während es mehr Anwender anzog, indem es ihnen dabei half, ihre Investitionen in
DOS- und Windows-Software zu schützen, hielt es gleichzeitig die
Entwickler davon ab, native OS/2-Software zu schreiben, weil sie durch
die Entwicklung für DOS/Windows ja sowohl den DOS/Windows- als auch
den OS/2-Markt abdecken konnten. Ich glaube, daß der Endeffekt immer
noch positiv, aber nicht ganz so war, wie IBM es sich anfangs vorstellte.
Ich habe OS/2 2.0 auf meinem Privatrechner installiert, einem PIII-600 mit 256 MB RAM. Die Installation verlief nicht ganz glatt - das erste Hindernis war, daß auf einer der 21 Disketten über die Jahre kaputte Sektoren entstanden waren - eigentlich nicht allzu überraschend. Und genausowenig überraschte es mich, daß diese fehlerhafte Diskette die wichtigste war, nämlich die Installationsdiskette. Aber ich habe es dank eines hilfsbereiten OS/2-Veterans geschafft, ein Diskettenimage zu erstehen. Dann begann OS/2 meine Maschine neu zu starten, als es von den Disketten bootete. Daher spielte ich ein wenig an den BIOS-Einstellungen meines PC, schaltete die CPU-Caches aus und alles begann zu laufen - später fand ich heraus, daß dies sogar bei OS/2 2.1 ein bekanntes Phänomen war. Anschließend verlief die Installation ziemlich ereignislos.
Auf meiner Maschine läft diese uralte OS/2-Version wahnsinnig schnell
- der Bootvorgang vom Bootmanager bis zur komplett aufgebauten Arbeitsoberfläche
benötigt lediglich 9 Sekunden. Schade, daß die eComStation
nicht so schnell ist.
Ich habe ein paar Anwendungen von 1992 und 1993 mit besonderem Schwerpunkt auf Compiler zusammengestelltt (wissen Sie, Anwendungsentwicklung ist mein Job). Die erste Anwendung ist CorelDraw 2.5:
Vorher hatte Corel anscheinend eine 16-Bit OS/2-Version von CorelDraw 2.0 für OS/2 1.3. Version 2.5 war eine komplette Sammlung von Programmen wie Draw, Chart oder PhotoPaint.
Leider sah das Paket sehr zusammengeschustert aus; abgesehen von Draw und Mosaic waren alle anderen Programme Windows 3.x-Versionen! CorelDraw hatte nicht einmal eine native OS/2-Hilfe, nur eine große Windows-Hilfedatei.
Aber abgesehen davon war CorelDraw ein ganz brauchbares Vektorzeichen-Programm. Ich bin kein Grafikkünstler, aber ich habe CorelDraw mehrere Male erfolgreich eingesetzt, um Zeichnungen im EPS-Format zur Einbindung in TeX-Dokumente zu erstellen.
Und CorelDraw hatte sogar Konkurrenz - Micrografx Designer, entwickelt von Micrografx und ebenso wie CorelDraw als Windows-Version erhältlich.
Ich habe keines von beiden intensiv benutzt, aber Designer scheint mir vollständiger und mehr auf Hochglanz poliert gewesen zu sein. Es beinhaltete nicht die gleiche Menge an Werkzeugen wie PhotoPaint, aber es kam mit einer großen Sammlung von Cliparts und Fonts daher. Ein anderer Unterschied zwischen diesen beiden Programmen war, daß in CorelDraw das Vorschaufenster separat und nicht editierbar war, während es in Designer möglich war, den Vorschaumodus einzuschalten und direkt in der Zeichnung zu editieren oder man konnte einfach die Drahtgitterzeichnung verändern.
Micrografx Designer wurde mit der Micrografx-eigenen Mirrors-Software entwickelt:
Interessanterweise schien CorelDraw Micrografx Mirrors ebenfalls zu benutzen.
Micrografx entwickelte Mirrors ursprünglich für OS/2 1.x und arbeitete eng mit IBM zusammen an der Entwicklung einer 32-Bit-Version. Mirrors war vom Konzept her identisch mit IBMs Open32, in dem Source-Portabilität zwischen Windows und OS/2 implementiert war (aber anders als Open32, zielte es auf 16-Bit Windows ab). Es sollte erwähnt werden, daß die Herren Delimon und English Co-Autoren des gut bekannten Programmierbuches Real-World Programming for OS/2 2.11 waren.
Leider habe ich es nicht geschafft, eine OS/2-Textverarbeitung aus der
1992/1993-Ära an Land zu ziehen - aber eines Tages sollte es gelingen.
OS/2 1.x wurde ausschließlich mit Microsoft-Tools entwickelt. Ich habe den Verdacht, daß sogar die ersten Phasen der OS/2 2.0-Entwicklung auf Microsoft-Compiler zurückzuführen ist - dem Compiler, der als "Microsoft C 6.0 386 Compiler" bezeichnet wurde, der niemals in den Verkauf gelangte, aber immer noch auf dem OS/2 DDK (Driver Development Kit - Anm.d.Übers.) zu finden ist und für die Erstellung bestimmter Gerätetreiber (und vielleicht sogar für Teile des OS/2-Kernels) benutzt wird.
Aber nach der Trennung 1990 war es für IBM klar, daß sie sich bezüglich der Versorgen mit OS/2-Compilern nicht länger auf Microsoft verlassen konnten. Zudem hatte Microsoft 1992 auch noch nicht einmal einen 32-Bit-Compiler im Handel. Daher entwickelte das IBM Toronto-Labor einen 32-Bit OS/2 C-Compiler, der als CSet/2 bekannt ist. Leider habe ich CSet/2 nicht, aber ich habe den Nachfolger (eigentlich habe ich alle dessen Nachfolger), der Anfang 1993 als IBM CSet++ herauskam.
Gewöhnlich ist IBM ziemlich gut darin, seine Kunden durch Produktbezeichnungen und die komplizierten Beziehungen zwischen Produktenzu verwirren. CSet++ war da keine Ausnahme und bestand im Grunde aus drei mehr oder weniger eigenständigen Paketen:
C/C++-Tools 2.0 (so weit ich weiß, die erste Version des IBM-Compilers mit C++-Unterstützung) konnte WorkFrame 1.1 nutzen und das OS/2 Toolkit für OS/2 2.0 oder 2.1. Wie man auf dem folgenden Screenshot sehen kann, kamen die C/C++-Tools mit einem Debugger, einem Profiler (alias Execution Analyzer) und einem C++-Klassenbrowser sowie einer enormen C++-Klassenbibliothek und einer Online-Dokumentation.
Das vielleicht mächtigste Werkzeug im Paket war IBMs Debugger, IPMD:
IPMD war und ist immer noch der beste OS/2-Debugger und wahrscheinlich einer der besten für jede Plattform.
Wie ich bereits früher schon bemerkte, nutzten die C/C++-Tools IBM WorkFrame/2 als ihre IDE (Integrated Development Environment; Integrierte Entwicklungsumgebung - Anm.d.Übers.):
WorkFrame/2 1.1 selbst war sehr klein - es war eben ein Gerüst. Es sollte externe Editoren starten, Programme, Compiler, Debugger und so weiter.
Der nächste Compiler in der Reihe ist Borlands C/C++ für OS/2 Version 1.0, der ungefähr zur selben Zeit herauskam wie die C/C++-Tools 2.0 (in der ersten Hälfte 1993):
Borlands C++ motzte die berühmte IDE, die der Windows-Version der Borland-Compiler sehr ähnlich war, mit Syntax-Hervorhebung, integriertem Debugging und anderen netten anderen Sachen auf:
Von Borland gab es auch eine Standalone-Version des Turbo-Debuggers:
Der Turbo-Debugger GX war nicht so stark wie IPMD, aber durchaus brauchbar. Und Borland hatte noch was anderes, was kein anderer OS/2-Compiler mitbrachte - den Ressourcen-Workshop:
Viele Progammierer waren der Meinung, daß der Ressourcen-Workshop den Tools aus dem OS/2-Toolkit überlegen war. Das ist vielleicht nicht überraschend - ein Blick auf die Borland-Tools genügt, um zu zeigen, daß Borland sich viel mehr um das Aussehen ihrer Tools gekümmert hat als IBM.
Am wenigsten auf das Aussehen bedacht war der dritte Compiler, den ich mir angesehen habe, Watcom C/386 9.0. Der Vergleich mit den C/C++-Tools 2.0 and Borland C/C++ 1.0 ist vielleicht etwas unfair, weil Watcom C/386 9.0 vom Vorjahr war. Watcom war eines der ersten Unternehmen, die einen 32-Bit OS/2-Compiler anboten - sie hatten schon früher die 16-Bit OS/2-Entwicklung unterstützt und begannen 1991 mit der Arbeit an der 32-Bit OS/2-Unterstützung (laut dem OpenWatcom Quellcode).
Watcom C/386 9.0 unterschied sich von den anderen beiden Compilern sehr stark - vor allem unterstützte er nur C-Entwicklung. Er hatte absolut keine GUI-Tools. Er erstellte keine Verzeichnisse oder Icons auf dem Desktop und das einzige Tool, das nicht kommandozeilen-orientiert war, war der Debugger, WVIDEO:
Jedoch hatte Watcom, was andere Compiler nicht hatten - es war ein Cross-Compiler. Er unterstützte die Entwicklung von 32-Bit OS/2-, DOS- und Windows-Programmen (Watcom unterstützte 32-Bit-Entwicklung durch eine proprietäre Erweiterungstechnologie unter Windows 3.x lange vor Win32s) und zusätzlich die Entwicklung für Netware und AutoCAD ADS. Er wurde mit der allseits bekannten DOS/4GW-Erweiterung (Version 1.8) geliefert. Es ist vielleicht ganz nett zu wissen, daß Watcom 9.x für die Entwicklung solcher Spielehits wie DOOM eingesetzt wurde.
Watcom gab 1993 die Version 9.5 des Compilers heraus, der zusätzliche Unterstützung für C++ und zur Erstellung Windows NT-Zielen aufwies. Mit Ausnahme des C++-Supports, war die OS/2-Ausgabe von 9.5 nicht völllig verschieden von der 9.0 - immer noch kein GUI-Werkzeugen noch sonst irgendwas. Das mußte bis zur Version 10.0 warten, die 1994 herauskam. Aber das ist ein Thema für eine andere Geschichte.
Der Überblick über die OS/2-Entwicklungswerkzeuge kann nicht vollständig sein ohne emx gcc zu erwähnen. Ich glaube, emx steht für Eberhard Mattes EXtender. Eberhard Mattes ist ein unternehmungslustiger deutscher Programmierer, der das emx-Paket entwickelt hat, um die Portierung von Unix-Software nach OS/2 2.0 und DOS zu vereinfachen. Die mit emx (und etwas Voraussicht) erstellten Programme können genauso gut unter OS/2 wie unter DOS laufen, weil die EMX.EXE eine 386 DPMI-kompatible DOS-Erweiterung ist. Eberhard Mattes benutzte emx selber, um emTeX, die DOS- und OS/2-Version des exzellenten Textsatz-Paketes TeX, zu entwickeln.
Nach einem bißchen Herumstöbern fand ich eine uralte (0.8d) Version von emx gcc vom Mai 1992. Verglichen mit den Compilern von IBM, Borland oder Watcom war emx völlig ungeeignet, um OS/2- (insbesondere PM-) Programme zu erstellen, obwohl es die deutlich bessere Wahl zur Portierung von Unix-Programmen war. Die frühe Version von emx hatte keine Unterstützung für OMF.Objektdateien. Daher konnte es auch die für die anderen Compiler geschriebenen Bibliotheken nicht nutzen. Es konnte keine DLLs erstellen und alles in allem fühlte es sich sehr "fremd" an. Es war zwar gratis, aber die armselige Dokumentation und das Fehlen von OS/2-spezifischen Merkmalen machte es zu einer schlechten Wahl, um OS/2-Programme von Grund auf zu entwickeln. Anders als andere Compiler beinhaltete emx nicht das OS/2-Toolkit, was eine größere Einschränkung bedeutete. Aber die Einfachheit des Portierens von Unix-Programmen mit emx ist der Grund dafür, daß fast jeder OS/2-Anwender die EMX.DLL auf seiner oder ihrer Maschine hat.
Aber zurück von den Compilern zu OS/2. Die Freigabe von OS/2 2.0 war zweifellos ein wichtiger Abschnitt in der PC-Historie. Die erste 32-Bit-Ausgabe fühlte sich im Vergleich zu späteren Versionen etwas nackt an - zum Beispiel gab es keine eingebaute Netzwerk- oder Multimedia-Unterstützung. Aber es war eine solide Basis für neu geschaffene 32-Bit-Anwendungen und es war ein "besseres DOS als DOS".
OS/2 2.0 eroberte leider nicht die Welt. Aber es hat sicherlich gezeigt, was ein 386-basierter PC mit einem Betriebssystem machen kann, das nicht für eine zwei oder drei Generationen ältere Maschine entwickelt worden ist.
The Design of OS/2 (Das Design von OS/2) von H.M. Deitel und M.S. Kogan, 1992 veröffentlicht von Addison-Wesley, versorgte mich mit einigen interessanten Tatsachen, die sehr schwierig anderswo zu finden sind. Dieses Buch, das jeder OS/2-Programmierer lesen sollte, geht sehr stark in die Tiefe.
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org