Als der IBM PC auf den Markt kam, waren die meisten Software-Entwickler enttäuscht: man hatte sich einen Motorola-Chip und ein vernünftiges Multitasking-System erhofft. Der Macintosh brachte dann den richtigen Prozessor und der Amiga die richtige Betriebssystem-Architektur. Trotzdem entwickle ich wie viele anderen europäischen Software-Hersteller meine Programme auf dem IBM PC. Woran liegt das? Wenn man als Begründung aufführt, dass die Intel-Architektur weiter verbreitet ist, als ihre Konkurrenten, erklärt das nichts, sondern beschreibt nur das Symptom auf andere Weise.

Der wichtigste Grund für den Erfolg der in vieler Hinsicht technisch überholten PC-Architektur dürfte in der Offenheit des Systems liegen. Nicht nur lieferte IBM mit dem ersten XT ein technisches Handbuch aus mit Schaltkreisen und Nachbauanleitung für PC-Hersteller in der dritten Welt, sondern sowohl die Hardware-Schnittstelle des AT-Bus für Einsteckkarten verschiedenster Art als auch die BIOS- und DOS-Dokumentationen luden ein zur kreativen Beteiligung ohne institutionelle Hemmnisse.

Als Spezialisten für Bildverarbeitung stürzten wir uns deshalb vor zwei Jahren auf den Mode 13H des damals neu angekündigten VGA-Adapters, der uns endlich die Möglichkeit bot, fotorealistische Farbbilder (wenn auch in der bescheidenen Auflösung 320x200 Punkte) auf dem PC darzustellen. Nun sind 256 Palettenfarben aus einem Spektrum von 16 Millionen Farben immer noch eine recht einschneidende Einschränkung für die Wiedergabe von Farbbildern. Es gelang uns aber mit einem speziell für diesen Zweck entwickelten Farbreduktions-Algorithmus erfreulich gute Bilder auf dem VGA zu produzieren. (Der Algorithmus basiert auf der Idee, dass die Palettenpunktdichte im Farbraum proportional zur Dichte des Farbvorkommens im Bild gewählt werden sollte.) Dank dem Aufkommen der verschiedenen VGA+ und SuperVGA-Karten konnten wir auch Fotos in vernünftiger Auflösung (640x480 Punkte) auf den meisten Adaptern (Video 7, Karten mit Tseng-Lab-Chips, 8514/A mit 512 KB...) hervorzaubern.

Der Macintosh stellte für unsere Multimedia-Bemühungen immer ein Problem dar. Einerseits hatte Apple sich von der früher praktizierten Philosophie der offenen Architektur abgewendet. IBM hatte diese als Grund für den grossen Erfolg der kleinen Apple Heimcomputer erkannt und für den PC mit Erfolg kopiert. Die Geschlossenheit der Architektur, die Verschlossenheit der Apple-Vertreter gegenüber europäischen Software-Entwicklern und die mangelnde Verbreitung des Geräts sprachen gegen Entwicklungen auf dieser Plattform. Die Realität der besser standardisierten Multimedia-Fähigkeiten des Macintosh (Sound, Graphikstandards) und (fast mehr noch) die Mythologie der Macintosh als einzig denkbare Maschine für kreative Arbeit wären allerdings Gründe für Bildverarbeitung auf dem Macintosh gewesen.

Die Attraktion dieses Mythos mag mitgespielt haben, beim Entscheid der Stiftung NeoCortex an der Universität Basel auf dieser Plattform ihre originelle Software für die Benutzung von Multimedia-CD-ROM-Anwendungen zu entwickeln. Die Stiftung geht von der Fundamentalität des vernetzten Denkens aus. Mit Ted Nelson, dem Erfinder des Hypertext- und Hypermedia-Konzepts, stellt man in Basel die Konzepte der komplexen Navigation im interaktiven Medium unter das Motto "Everything is deeply intertwingled"¹. Der erste Versuch, das auf Nelsons Ideen beruhende Hypercard für die NeoCortex-Anwendungen einzusetzen, scheiterte, da sich diese Software als ungeeignet erwies, mehr als ein paar einfache Demobilder zu managen. Für CD-ROM-Applikationen sah man sich gezwungen, grössere Systeme selber zu implementieren.

Das neueste Projekt der NeoCortex-Stiftung ist eine CD-ROM mit Information über das Leben in und um Feuchtgebiete. Eine grosse Anzahl von Farbfotos und eine Reihe von Graphiken ermöglichen dem Benutzer, sich über das Ökosystem "Feuchtgebiet" zu informieren. Lehrer können das Material der Platte für eigene Programme zusammenstellen.

Erneut stellte sich für die verschiedenen Verwendungszwecke die Frage nach der Plattform. Es wäre schön, wenn man eine CD-ROM für Macintosh und PC-Benutzer gleichzeitig herausbringen könnte...

Mitten in die Entwicklungsarbeit fiel das Erscheinen von Windows 3.0. Die Oberflächen auf dem Macintosh und dem PC waren merklich näher gerückt. Es wurde beschlossen, das NeoCortex-System parallel auf dem PC zu entwickeln. Da beim Design von Windows 3.0 geräteunabhängige Bildformat in beliebiger Grösse und mit beliebig vielen Farben vorgesehen wurden und für einige VGA+-Karten (etwa die Video 7) sogar Graphik-Treiber beilagen, welche die Darstellung von 256 Farben in einer Auflösung von 640x480 Punkten erlauben, konnten wir unsern Farbreduktions-Algorithmus einsetzen. Die Einbindung der Bilder unter Windows hatte den wesentlichen Vorteil, dass wir so mit anderen Anwendungen unter Windows kommunizieren konnten (Omnis-Datenbank, Clipboard ...). Unsere Stand-Alone Bilddarstellungsprogramme konnte man zwar zu einer schönen Dia-Schau verwenden, zusammen mit Fremdprogrammen waren sie jedoch kaum verwendbar. Um die NeoCortex-CD-ROM auch vom PC aus zu betreiben, brauchten wir also nur die Darstellung von

Palettenbildern als Windows-Applikation zu programmieren.

Vorläufig ist die Anschaffung des "Software Development Kit" (SDK) von Microsoft eine notwendige Voraussetzung für die Entwicklung von Windows-Anwendungen. Dies bedingt eigentlich auch die Verwendung von Microsoft C (Version 6.0). Zwar kann man gemäss Angaben im Handbuch des Stonybrook-Modula auch mit diesem Compiler Windows-Applikationen zusammensetzen, man braucht aber ebenfalls den Microsoft SDK dazu und für ein erstes Kennenlernen wollte ich mich noch nicht auf irgendwelche Äste hinauslassen.

Beim Durchlesen des einigermassen brauchbaren "Guide to Programming" stellt man mit Bedauern fest, dass sich die Windows-Library nicht als Kollektion von ereignisgesteuerten C++-Objekten präsentiert. Die Programmiermöglichkeiten sind wenig flexibel, die Menge des Stoffs ist ziemlich gross (tausende von Seiten und tausende von neuen Begriffen, Schlagworten und Funktionen, die man so ziemlich alle präsent haben sollte, um effizient programmieren zu können). Das schöne Help-System unter Windows kann nicht eingesetzt werden, da der SDK selber nicht unter Windows läuft.

Beim Installieren wählte ich das "Large" Memory Model, weil mir dieses in der Vergangenheit schon oft gute Dienste geleistet hatte. Ich verzichtete auf das Auspacken der anderen Libraries, da ich auch so schon für C-Compiler und SDK rund 20 MegaByte Festplatte aufgewendet hatte. Daneben wollte ich noch gern irgendwo meine Programme auf der Platte unterbringen. Erst drei Wochen später ziemlich tief in der Dokumentation verstand ich, warum alle Beispiele des SDK das "Small" Memory Model voraussetzen: Da sämtliche grossen Datenmengen dem Windows zur Verwaltung übergeben werden, braucht das eigene Programm keine grossen Pointer. In der Kommunikation mit Windows muss man zwar ziemlich viele Pointer auf "FAR" konvertieren, aber alle lokalen Programmdaten sollten in einem Segment Platz haben. Dieses Datensegment und die diversen Code-Segmente (möglichst viele kleine) kann man dann Windows zur vernünftigen Verwaltung anvertrauen. Heute benütze ich das "Medium" Memory Model und werde wohl in Zukunft kaum je ein anderes für Windows-Anwendungen brauchen.

Nachdem ich noch über die unterschiedliche Pointer-Arithmetik von "FAR"- und "huge"-Pointern gestolpert war (unsere Farbbilder sind sehr grosse Datenstrukturen auf dem globalen Heap, für welche man unbedingt "huge" Pointer verwende muss, damit die segmentüberschreitende Pointer-Arithmetik aufgeht), mich über die Notwendigkeit zweier Monitore für den Einsatz des CodeView-Debuggers geärgert hatte und während jedem 5-10-minütigen Compile-Schritt ein Stossgebet an Borland verschickt hatte, uns doch möglichst sofort eine brauchbare objekt-orientierte Windows-Entwicklungsumgebung in C++ oder Turbo Pascal zu bescheren, erschienen dann endlich fotorealistische Farbbilder hoher Qualität auf meinem Video7-VGA+-gesteuerten Farbbildschirm.

Nach einer Woche Microsoft C hatte ich während der Compilierpausen fast das ganze "Undocumented DOS"² durchgelesen und eine Reihe von Farbbild-Dateiformaten integriert. Das Darstellungsprogramm und einige Beispielbilder versammelten wir auf einer Public-Domain-Diskette. Sie kann für 5 DM (Diskette, Porto, Verpackung) bei der Redaktion [oder bei der Enter AG, Fabrikstrasse 30, 8005 Zürich, Schweiz] bezogen werden.

In Basel bei der NeoCortex-Stiftung brach man nicht in Begeisterungsstürme aus, nachdem wir das Programm und die Bilder dorthin verschickt hatten. Einige Wochen später konnte ich mich mit eigenen Augen davon überzeugen, dass dieser Mangel an Reaktion darauf zurückzuführen war, dass man dort auf den PS/2-Rechnern der Stiftung nur den 16-Farben VGA-Treiber für Windows installiert hatte. Mit unserem Stand-Alone-Programm konnten wir zwar die Video-Modes des 8514/A-Adapters ausnützen und 256 Farben in einer Auflösung von 640x480 Punkten darstellen, unter Windows wollte dies hingegen nicht einmal gelingen, nachdem wir den speziellen 8514-Bildschirmtreiber installiert hatten, den Microsoft mit ihrem originalen Windows 3.0 mitliefert. Wir standen vor der kuriosen Situation, dass das Farbbildprogramm auf einem fernöstlichen Clone entwickelt auf einer fernöstlichen VGA+-Karte (Video7) wunderbare Bilder anzeigt, dass aber auf originalen IBM-Rechnern der Marke PS/2 mit dem originalen IBM-Bildschirmadapter 8514/A unter Windows nicht mehr als 16 Farben zu haben sind. Die Macintosh-Fans in Basel rieben sich die Hände und lehnten sich beruhigt zurück, im Bewusstsein die einzige brauchbare Multimedia-Maschine zu besitzen.

Das Problem wäre ja leicht behoben, wenn man in den PS/2 einfach eine taiwanesische VGA+-Karte einschieben könnte, aber diese sind natürlich für den AT-Bus erhältlich, nicht für den Microchannel des PS/2.

Da wir uns nicht vorstellen konnten, dass kein für uns brauchbarer Windows-Bildschirmtreiber existieren sollte, beschlossen wir, nach einem solchen zu fahnden. Schliesslich hatten es alle taiwanesischen VGA-Karten-Hersteller innerhalb von Monaten geschafft, eine grosse Vielfalt von Bildschirmtreibern mit ihrer Hardware mitzuliefern, die sowohl hohe Auflösungen als auch 256 Farben unterstützen. Vielleicht gab es bei Microsoft oder IBM schon einen Treiber für 256 Farben auf dem 8514/A.

Die Abklärung blieb an mir hängen, weil die Besitzer der PS/2 sich nicht genügend technische und Sprachkenntnisse zutrauten, um zum Ziel zu kommen.

Die Nummer der Microsoft-Hotline war schnell gefunden. Auch dass für Windows-Fragen eine separate Nummer existiert, leuchtet ein. Dann die Frage: Welche Seriennummer hat Ihr Windows. Ein schnelles Fummeln in der Schachtel mit den Originaldisketten bringt nichts zu Tage: zwar befinden sich verschiedene kleingedruckte Nummern auf dem Label, aber von denen will man auf der anderen Seite nichts wissen. Auf der Registrationskarte wäre die Nummer gewesen. Die hätte ich abschreiben sollen, bevor ich sie abschickte. Dem deutschen Microsoft-Service war vielleicht nicht klar, dass auch die Schweizer Anrufe nach München durchgeschaltet werden. Jedenfalls hat mich niemand gewarnt, die Registrationskarte nicht einzuschicken. Eine Antwort auf meine Registration (Assembler, Pascal, C, Quick-Pascal, Windows, SDK...) habe ich in den letzten sieben Jahren noch nie von Microsoft erhalten.

Der Microsoft-Vertreter wollte nicht warten, bis ich irgend eine Registrationsnummer von etwas Windows-ähnlichem aufgetrieben hatte. Als ich wieder anrief zeigte meine Uhr auf 16:58. Aber schon erzählte eine freundliche Tonbandstimme, ich könne es morgen wieder versuchen.

Am nächsten Tag war jemand am Draht, der keine Registrationsnummer wollte. Ich erklärte mein Problem: ich habe da ein Windows-Programm, das auf der Video-7-Karte läuft, auf dem 8514/A-Adapter aber nicht. Der freundliche Helfer meinte, ich hätte zuwenig Speicher auf der 8514/A um ein ganzes 640x480-Punkte-Bild mit 8 Bit pro Punkt aufzunehmen, wollte sich dann aber nicht zur Erklärung herbeilassen, warum dasselbe Bild im Adapter Platz fand, wenn wir unser Stand-Alone-Programm verwendeten. Er spekulierte auch, es liege am Bildschirm, beziehungsweise an der Synchronisation des RGB-Signals. Mein imständiges Bitten, mit einem Software- und Gerätetreiber-Spezialisten verbunden zu werden, stiess auf taube Ohren. Er meinte, ich könne ja mit dem "Device Development Kit" der Microsoft selber etwas entwickeln. Dieses sei ja Bestandteil des SDK.

Der dritte Microsoft-Vertreter wollte wieder die Seriennummer. Er liess sich allerdings widerwillig überzeugen, dass ich ohne Seriennummer etwas für einen meiner Kunden recherchiere. Er hatte immerhin eine Liste aller unterstützten Hardware-Komponenten und aller bekannten Gerätetreiber zur Hand. Nein, ausser dem Standard-8514-Treiber, der mit Windows mitgeliefert werde, gebe es keinen andern. Auch einen Treiber für Normal-VGA mit 256 Farben und schlechter Auflösung (320x200-Punkte) gebe es nicht. Der "Device Development Kit" (DDK) sei nicht Bestandteil des SDK, werde aber von Microsoft den Hardware-Herstellern zur Verfügung gestellt. Er würde allerdings zuerst den Hersteller des Adapters fragen, da dieser eigentlich dafür verantwortlich sei, einen entsprechenden Windows-Treiber zu liefern.

Der Hersteller der Hardware hiess in diesem Fall IBM. Nach ein bisschen Rumfragen, stosse ich zum technischen Auskunftsdienst vor. Dort will man wissen, welches meine Kundennummer sei. Geduldig (noch!) erkläre ich, dass ich für Kunden von mir abzuklären suche, ob es einen Windows-Bildschirmtreiber gibt, der 256 Farben unterstützt. Mir wird bedeutet, ich müsse mich da an den Lieferanten wenden. Nach meiner Richtigstellung, dass ich der Lieferant des Programms bin, meint man, ich müsse den Hardware-Lieferanten fragen. Auf meine Frage, was der Hardware-Lieferant von Windows wisse, verweist man mich schliesslich erleichtert an die Microsoft. Als ich deutlich mache, dass ich gerade "von dort" komme, versteift man sich wieder auf die Kundennummer. Es ist unwichtig, ob der Chef des NeoCortex in Basel zuwenig von Technik versteht, ob sein Windows-Programmierer als Jugoslawe nicht sehr flüssig deutsch kann. Ohne Kundennummer, die in einem Uni-Institut wohl nach ein paar Tage suchen aufzutreiben wäre, läuft nichts.

Immer noch mittelmässig freundlich, erkläre ich meinem Gesprächsgegner, dass ich ja verstehe, dass er mit solchen spezialisierten Software-Details nichts zu tun haben möchte, dass es mir ja nur darum geht, innerhalb der IBM jemanden ausfindig zu machen, der versteht, wovon ich rede. Wenn es sich nicht um eine originale IBM-Maschine mit originalem IBM-Adapter handeln würde, für welche sicher auch irgendwo eine originale IBM-Kundennummer existiert, dann würde ich nicht meinen Vormittag damit verblödeln, um den technischen Auskunftsdiensten von IBM oder Microsoft ihre wertvolle Zeit zu stehlen.

Die IBM ist bekannt als Firma mit dem seriösen Service. Für den Preis eines 8514/A-Adapters wünscht man sich die gewiss bescheidene Kulanz, mit einem Fachmann auf dem Problemgebiet in Verbindung gebracht zu werden. Schliesslich handelt es sich um eine Fehlfunktion, wo der angebliche 8514/A-Treiber für Windows nicht das liefert, was etwa der Video-7-Treiber kann.

Alle meine Appelle an die (vergangene?) Kultur des IBM-Kundendienstes nützen nichts. Ich bin selber kein PS/2-Kunde, da ich mir so teure Maschinen nicht leisten kann. Darum habe ich keine Kundennummer. Darum kann man mir keine Auskunft geben.

Die Recherche nach der Kundennummer überliess ich der Uni Basel. Mein Budget an Geduld und an Zeit war nach diesem Telefonvormittag aufgebraucht. Natürlich wissen wir heute noch nicht, ob es einen Windows-Treiber für den 8514/A-Adapter gibt. Den Assistenten von NeoCortex hat ein anderer Händler damit abgespiesen, es liege an der Synchronisation des Bildschirms. Die NeoCortex-Stiftung wird auf ATs umsatteln müssen, die nicht von IBM stammen.

Meine erste Reaktion auf eine solche geballte Ladung von Stumpfsinn war natürlich Ärger. Nachdem dieser verraucht war, versuchte ich die Ursachen zu ergründen, die zu solch einem Karussell führen. Offensichtlich waren wir mit Windows einerseits und PS/2 und 8514/A andererseits gerade auf ein empfindliches Gebiet zwischen Microsoft-DOS-Windows und IBM-OS/2-Presentation Manager geraten. Man hat mir glaubwürdig versichert, es gebe 256-Farben-PM-Treiber für den 8514/A-Adapter. In Basel wollte man allerdings ein populäres Produkt herstellen, das von der grossen Mehrheit der PC-Besitzer genutzt werden kann. Darum läuft auf den PS/2 nur DOS und kein OS/2. Wenn "OS-halbe" einmal zu "OS-viertel" wird, hat es vielleicht auch auf meiner Maschine Platz.

Neben dem Titanenkampf Microsoft-IBM, wo jeder hämisch grinsend auf den andern verweist, steckt das Problem der verlorengegangenen Firmenkultur vielleicht etwas tiefer. Der technische Auskunfter am Telefon klang sehr defensiv. IBM scheint schwer unter der laufend zunehmenden Komplexität der eigenen Produkte zu leiden. Gerade weil man dort den Kundendienst nicht auf eine so leichte Schulter nimmt, wie fast alle anderen PC-Hersteller, sieht man sich gezwungen, sich mit Hilfe von Kundennummern abzuschotten, um nicht in der betriebseigenen Komplexität zu ersticken.

Diese zunehmende Tendenz der Abkapselung ist auch bei vielen neuen Produkten von IBM feststellbar. Das ursprüngliche Erfolgsrezept des IBM PC, die Offenheit der Architektur, des Betriebssystems, der Information, nimmt täglich etwas ab, während die Konkurrenten die Früchte der vergangenen vorbildlichen Strategie des Marktleaders geniessen.

März 1991 Hartwig Thomas

¹ Zu deutsch etwa: "Alles ist durch und durch miteinander verquixt". Diese Technik der Wortbildung dürfte Nelson von Lewis Carroll haben, der im Vorwort zu seinem "The Hunting of the Snark" solche "Portmanteau"-Wörter ausführlich erklärt. Wie eine tragbare Garderobe mehrere Kleidungsstücke enthält, kann man nach Carroll in ein Wort mehrere andere Wörter "verpacken" (in seinem Gedicht findet sich etwa "galumphieren" für "galoppieren" und "triumphieren"). Bei "intertwingled" suche man daher im Lexikon unter "intertwined" und "intermingled".

² Andrew Schulmann, Raymond J. Michels, Jim Kyle, Tim Paterson, David Maxey, and Ralf Brown: Undocumented DOS, a Programmers Guide to Reserved MS-DOS Functions and Data Structures, Addison-Wesley Publishing Company, Inc. 1990. Ein MUSS für jeden ernsthaften DOS-Programmierer mit dem neuesten Update von Ralf Browns phantastischer Interrupt-Liste auf Diskette. ca. 700 Seiten