Impressum und Hinweise zur Weiterverwendung

Interface Evolution

Die Geschichte des Computers als Geschichte seiner Nutzungsschnittstelle

Zweite Auflage

Text: Felix Winkelnkemper

Lektorat: Maria Scherzog (Kapitel 1-3), Carmen Buschmeyer (Kapitel 4)

Ich danke allen, die mit Hinweisen und Tipps zum Gelingen dieses Buches beigetragen haben!

Der Text dieses Buchs kann gerne unter den Bedingungen der Creative-Commons-Share-Alike-Lizenz (CC BY-SA 2.0) weiterverwendet werden. Beachten Sie bitte, dass nicht alle Abbildungen dieser Lizenz unterliegen!

Die Rechte an den Abbildungen liegen bei den jeweiligen angegebenen Urhebern. Abbildungen ohne Angabe unterliegen einer Creative-Commons-Share-Alike-Lizenz (CC BY-SA 2.0) mit Urheber Felix Winkelnkemper.

Wenn Sie Teile dieses Werkes weiterverwenden wollen, würde ich mich über eine E-Mail an winkelnkemper@googlemail.com sehr freuen!

Besuchen Sie die Website zum Buch!

Unter www.computergeschichte.net finden Sie zusätzliche Inhalte, darunter alle Verweise zu Videos und Emulatoren aus diesem Buch – und noch einige mehr.

Vorwort

Es freut mich, dass Sie sich für dieses Buch und damit für meine Sicht auf die Computergeschichte interessieren. Vielleicht ist dies Ihr erster Zugang zur Geschichte der Computer, vielleicht sind Sie aber auch bereits ein richtiger Kenner und fragen sich nun, warum es denn noch ein Buch darüber braucht. Gibt es nicht schon genügend davon? Lassen Sie mich zur Beantwortung dieser Frage ein wenig über die Beweggründe hinter diesem Buch sprechen.

Die Idee für dieses Buch entstand im Rahmen von Seminaren und Vorlesungen zu den Themen digitale Medien, Geschichte interaktiver Systeme und Software-Ergonomie, die ich in den letzten Jahren an der Universität Paderborn gehalten habe. Ich hatte es dort mit wissbegierigen, interessierten Studierenden zu tun, die aber, wie es bei Studenten und Studentinnen nun mal so ist, alle ziemlich jung waren. Die Studierenden des Jahres 2021 sind um das Jahr 2000 herum auf die Welt gekommen und haben nie eine Zeit ohne allgegenwärtige Computer erlebt. In ihrer Welt gab es immer PCs, Laptops und wahrscheinlich auch immer schon Handys und Smartphones. Für diese jungen Menschen ist es ganz normal, dass diese Geräte über aufwändige grafische Nutzungsoberflächen verfügen, die die ihnen zu Grunde liegende Technik weitgehend vor ihnen versteckt. Wenn ein Computer nach dem Starten nur weißen Text auf schwarzem Grund zeigt, dann heißt das für sie, dass mit dem Computer wohl etwas nicht in Ordnung sein muss. Nun will ich unsere Studierenden nicht falsch darstellen und mich lustig machen. Natürlich wissen sie, dass es die heutigen Nutzungsschnittstellen nicht immer gab. Die meisten von ihnen haben sogar auch schon mal von so etwas wie Lochkarten gehört, aber wann man mit gelochten Karten gearbeitet hat und was das Programmieren mit Lochkarten bedeutete, wie umständlich das war, das haben sie sich meist nicht klargemacht.

Es gibt – nicht nur für unsere Studierenden – viele Argumente, die dafür sprechen, einen Blick in die Computergeschichte zu werfen. Es ist nahezu immer hilfreich, zu wissen, warum die Dinge so geworden sind, wie sie heute sind. Nicht nur weiß man dann die Leistung derer, die an der Entwicklung und Verbesserung moderner Computertechnik maßgeblich beteiligt waren, zu schätzen. Man kann bei aktuellen Nutzungsschnittstellen dann auch einschätzen, ob die Potenziale, die aktuelle Schnittstellen bieten, auch ausgenutzt werden oder ob sie hinter den Möglichkeiten zurückbleiben. Sich für Computergeschichte zu interessieren ist also eine lohnenswerte Sache. Doch wo soll man beginnen und worauf sollte man seinen Blick richten?

Unter der großen Menge an Büchern über Computergeschichte findet sich eines von Sean Mahoney mit dem spannenden Titel „Histories of Computing“¹. Das ist kein Vertipper. Mahoney verwendet hier bewusst das Wort „Histories“ in der Mehrzahl. In der Tat gibt es nicht die eine kohärente Computergeschichte, die man erzählen könnte, sondern ganz unterschiedliche Aspekte, die man betrachten kann. Ein Ansatz kann zum Beispiel das Erzählen von Firmengeschichten sein, etwa die Geschichten von IBM, von Apple oder auch von Microsoft. Ein anderer Ansatz ist die Beleuchtung der Geschichte der Protagonisten der Computergeschichte, etwa von Konrad Zuse, Bill Gates oder Linus Torvalds, um einmal relativ beliebig drei Protagonisten herauszugreifen. Man kann bei der Betrachtung der Computergeschichte natürlich auch eine rein technische Perspektive einnehmen und die Geschichte der Geräte, die Entwicklung der Speichertechnik, der Prozessortechnik und der Softwaretechnik erzählen. Für all diese Ansätze finden Sie auf dem Markt viele Beispiele. Betrachtenswert und meiner Meinung nach sehr interessant wäre auch ein Blick auf die Visionen und Hoffnungen, die mit der Computertechnik verbunden waren. Wieso zum Beispiel sprach man in den 1960er Jahren noch vom Elektronengehirn, heute jedoch nicht mehr? Diese durchaus bemerkenswerte Perspektive findet man in heutiger Computergeschichtsliteratur allerdings leider recht selten.

Viele populäre Dokumentationen der Computergeschichte, sei es in Buchform, als Fernseh-Dokumentation oder als Internetvideo, sind nicht nur nüchterne, wissenschaftliche Blicke auf die Vergangenheit, sondern oft sehr subjektive Sammlungen von Geschichten. Es werden manche Erzählungen und Legenden rund um die historischen Ereignisse aufgegriffen, nacherzählt und mit belegbaren historischen Fakten versponnen. Viele dieser oft spannenden Erzählungen wurden von den Protagonisten der Entwicklungen selbst in die Welt gesetzt, andere entstammen den Marketingabteilungen der Computer- und Software-Hersteller.

Schaut man sich auf dem Markt der Dokumentationen über Computergeschichte um, kann man grob drei Gattungen ausmachen:

Historische Überblicke versuchen, viele der genannten Geschichtsperspektiven gleichzeitig zu betrachten, im Versuch, einen möglichst guten Gesamtüberblick zu geben. Vollständig können diese Überblicke natürlich nie sein, sind aber durchaus ein guter Einstieg. Lesenswert sind hier die Geschichtsbetrachtungen, die es hinbekommen, neben dem Geschichtenerzählen auch größere Entwicklungsstränge und deren Hintergründe darzulegen. Empfehlenswert sind zum Beispiel die Bücher von Paul Ceruzzi („A History of Modern Computing“ und „Computing: A Concise History“) und die ZDF-Dokumentation „Geheimnisse der digitalen Revolution“, die Sie auch online bei YouTube finden können.

In Detail-Dokumentationen werden einzelne Computer oder spezielle Entwicklungen punktuell und sehr detailliert betrachtet. Beispiele sind Bücher über den ENIAC² oder über die Frühgeschichte des Internets³. Derartige Dokumentationen sind oft sehr lesens- und sehenswert, da sie häufig mit beliebten Vorurteilen aufräumen. Mein persönlicher Tipp bei solchen Dokumentationen ist es, Bücher aus der Feder unmittelbar beteiligter Protagonisten zu meiden oder beim Lesen zumindest zu bedenken, dass hier jemand auf seine eigenen Heldentaten zurückblickt.

Ein Großteil der am Markt verfügbaren populären Bücher und Videodokumentationen gehört zu den nostalgischen Rückblicken. Sie beschäftigen sich zumeist mit den Heimcomputern der 1980er und 1990er Jahre. Oft liegt der Fokus der Betrachtung auf der Eignung der Geräte als Spieleplattform und auf den eigenen Erfahrungen der Autoren, die sie in ihrer Jugend mit den Rechnern gemacht haben.

Mein Ansatz in diesem Buch ist eine weitere Perspektive, über die ich in dieser Form noch kein Werk gefunden habe. Ich betrachte nicht die Protagonisten oder die Firmen und auch nicht in erster Linie die technischen Fortschritte in der Rechentechnik, sondern konzentriere mich auf die Evolution der Interfaces, also auf die Nutzungsschnittstellen. Allgemeiner formuliert interessiert mich in diesem Buch, wie sich die Art und Weise, Computer zu bedienen, im Laufe der Zeit entwickelt hat und was hinter den Entwicklungen stand. Der Begriff „Evolution“ im Titel ist dabei nicht leichtfertig gewählt. Evolution ist in der Biologie nicht einfach eine beliebige Entwicklung, sondern eine zusehends bessere Anpassung einer Lebensform an die Umweltbedingungen und die sich aus ihnen ergebenden Gefahren. Will man die Evolution einer Spezies erklären, muss man immer auch deren Umwelt mitbetrachten. Natürlich muss klar sein, dass es sich bei der hier beschriebenen Evolution nicht ganz so verhalten kann, wie in der Biologie, denn technische Geräte leben ja nicht und verändern sich nicht aus sich heraus, sondern werden von ihren Nutzern und Erzeugern weiterentwickelt oder den Nutzerbedürfnissen entsprechend angepasst. Ich halte den Begriff Evolution trotzdem für passend, denn was die Entwicklung der Nutzungsschnittstellen der Computer mit der biologischen Entwicklung gemein hat, ist ihre Wechselwirkung mit der Umwelt. Bei der biologischen Evolution ist es die natürliche Umgebung einer Spezies, die betrachtet werden muss, und bei der Evolution der Nutzungsschnittstellen sind es der Stand der Rechentechnik auf der einen und die Nutzungsanforderungen, die an den Computer und seine Bedienung gestellt werden, auf der anderen Seite.

Vollständig unvollständig

Ich gebe Ihnen in diesem Buch aus meiner spezifischen informatisch-technischen Perspektive der Nutzungsschnittstelle einen historischen Überblick über die Computergeschichte. Das versuche ich möglichst korrekt zu machen. Auf Fehler und Irrtümer möge man mich bitte hinweisen. Ein Anspruch, den ich hier nicht erfüllen kann, ist der an die Vollständigkeit. Nicht jedes wichtige Gerät der Computergeschichte und nicht jede wichtige Software ist auch für meine Blickweise interessant und daher in diesem Buch erwähnenswert. Seien Sie mir also bitte nicht böse, wenn Ihr Lieblingsgerät oder Ihre Lieblings-Software keine Erwähnung findet. Einige prominente Beispiele, die hier nicht oder allenfalls ganz am Rande betrachtet werden, sind:

• Das Betriebssystem OS/2 wurde zunächst von Microsoft und IBM zusammen und später von IBM allein als Nachfolger für MS-DOS und Windows entwickelt. Späte Versionen haben eine sehr interessante Nutzungsschnittstelle, allerdings war die Zahl der Nutzer im Vergleich zu Windows verschwindend gering.
• Märkte außerhalb der USA und Deutschland. Großbritannien hatte in den 1980ern und 1990ern sein ganz eigenes Ökosystem von Computern mit Firmen wie Sinclair, Amstrad und Acorn. Das nachhaltigste Produkt dieser zuletzt genannten Firma ist nicht etwa eine Nutzungsschnittstelle, sondern eine Prozessorarchitektur. Eine Acorn RISC Machine (ARM) befindet sich heute in nahezu jedem Smartphone. Auch Japan verfügte über eine interessante eigene Computerszene.

Es gibt noch etwas, was ich hier ganz explizit nicht mache: Viele an der Computergeschichte Interessierte scheint die Frage umzutreiben, zu klären, welcher Rechner der erste war oder wer eine bestimmte Idee als erster oder als erste hatte. Diese Fragen erscheinen mir unsinnig, denn Geschichte ist kein Wettbewerb! Im Bestreben, den Ersten zu finden, gerät das, was die Geräte, die technischen Innovationen oder die Interface-Ideen ausgemacht hat, schnell aus dem Blick. Damit nicht genug: Den Ersten, die oder das Erste zu finden, funktioniert meist schlichtweg gar nicht. In einer Nachbetrachtung ist es nahezu immer möglich, noch ein Gerät ans Tageslicht zu befördern, das man unter bestimmten Umständen als noch früheres bezeichnen kann, ein Schriftstück zu finden, indem jemand eine Idee schon Jahre vor ihrer Umsetzung angedeutet hat oder gar einen Visionär ausfindig zu machen, der Jahrzehnte vor einer Entwicklung, meist neben viel Unsinn, genau das vorausgesagt hat, was dann eingetreten ist. Man findet zu jedem Ersten immer noch einen Vorgänger oder Vorläufer. Schlimmer noch: Die Suche nach einem Ersten suggeriert eine Art Singularität. Das erste Exemplar erscheint als Geniestreich, als hätte jemand etwas geradezu Undenkbares nun doch gedacht und umgesetzt. So komplexe Entwicklungen wie der Computer haben aber immer eine ebenso komplexe Vorgeschichte und erstehen nicht als Gedankenblitz einfach so aus dem Nichts. Ich kann Ihnen an dieser Stelle einen Besuch im Heinz Nixdorf MuseumsForum in Paderborn empfehlen. Das Museum bezeichnet sich selbst als das größte Computermuseum der Welt. Das wirklich Spannende an dem Museum ist aber nicht seine schiere Größe oder die Anzahl der ausgestellten Exponate, sondern dass mindestens die Hälfte der Ausstellung die Computergeschichte vor dem Erscheinen der ersten Computer erzählt und so den Computer in die Jahrtausende umfassende Geschichte des Rechnens, des Schreibens, der technischen Kommunikationsunterstützung und vieler weiterer Aspekte einbettet.

Was ist eigentlich eine Nutzungsschnittstelle?

Ich beschreibe Ihnen in diesem Buch die Evolution der Nutzungsschnittstelle, aber was ist eigentlich eine Nutzungsschnittstelle? Beim Versuch, sie zu definieren, kommt uns Friedrich Nietzsche in die Quere, der in seiner „Genealogie der Moral“ ganz richtig feststellte:

Alle Begriffe, in denen sich ein ganzer Prozess semiotisch zusammenfasst, entziehen sich der Definition; definierbar ist nur das, was keine Geschichte hat.

Begriffe wie „Nutzungsschnittstelle“ und „User Interface“ haben Geschichte. Sie eindeutig zu definieren, wird mir also wohl nicht gelingen. Verschiedene Entwickler, Wissenschaftler, Journalisten und Nutzer haben ganz Verschiedenes in die Begriffe hineingelegt. Ich kann und möchte Ihnen an dieser Stelle daher nicht die ultimativen Definitionen vermitteln, sondern in aller Kürze meine Sichtweise auf das Konzept „Nutzungsschnittstelle“ erläutern.

Bruce Tognazzini beschreibt in seinem Buch „Tog on Interface“ von 1992⁴ die Nutzungsschnittstelle des Apple Macintosh als eine „fanciful illusion“. Er schreibt, dass die Welt der Schnittstelle des Macintosh ganz anders sei als die der Architektur des darunterliegenden Betriebssystems. Was Tognazzini hier für den Macintosh erläuterte, ist keineswegs nur für diesen gültig. Sein Gedanke gilt für interaktive Nutzungsschnittstellen ganz generell. Werfen wir einen kurzen Blick auf diese „fanciful illusion“. Worum geht es? Wenn Sie sich die Nutzungsschnittstelle eines Computers ansehen, haben Sie es nicht mit einer Schnittstelle für die technische Architektur des Computers zu tun. Sie sehen keine Visualisierung der Prozessor-Operationen, haben keinen direkten Einblick in den Arbeitsspeicher und können auch keine Befehle direkt an angeschlossene Geräte schicken. Was Sie am Bildschirm sehen, wenn Sie etwa einen Dateimanager wie einen Windows Explorer oder einen Finder am Mac bedienen, ist ganz etwas anderes als diese technische Realität des Geräts. Der Computer erzeugt für Sie durch seine Programmierung eine eigene Welt am Bildschirm. In dieser Welt, der Nutzungswelt, gibt es beispielsweise Dateien, die in Form kleiner Bilder auf dem Bildschirm dargestellt werden. Sie können diese Objekte am Bildschirm selektieren und manipulieren, also etwa umbenennen oder gar löschen. Die Dateien im Explorer- oder Finder-Fenster sind Objekte, die nur durch die Nutzungsschnittstelle existieren. Wenn Sie den Computer auseinander nehmen würden, würden Sie keine Dateien finden, selbst wenn es Ihnen möglich wäre, die Magnetisierungen auf einer Festplatte oder die Zustände des Flash-Speichers einer SSD direkt wahrzunehmen.

Das Betriebssystem und die Dateimanager-Software liegt als Zwischenschicht zwischen dem Nutzer und der technischen Realität der Maschine. Diese Zwischenschicht, die Nutzungsschnittstelle, sorgt dafür, dass sich Nutzer nicht um so etwas wie die Steuerung der Festplatte kümmern müssen und dass gespeicherte Texte nicht etwa durch Angabe einer kryptischen Adresse angesprochen werden, sondern mit lesbaren Namen benannt und im geschilderten Fall sogar räumlich auswählbar sind. Die Nutzungsschnittstelle sorgt auch dafür, dass ein solches Textobjekt betrachtet werden kann, indem es am Bildschirm geöffnet wird. Der Nutzer muss dafür nicht erst ein Programm bitweise in den Arbeitsspeicher eingeben oder von der Festplatte in den Speicher kopieren. Auch muss man keinen Programmzähler auf die Startadresse des Programms setzen und dieses manuell starten. All diese Handlungen sind kein Teil der Nutzungswelt und daher dem Nutzer nicht (mehr) zugänglich. Auf der einen Seite der Schnittstelle, nach außen hin, gibt es nur die Objekte der Nutzungswelt und auf der nach innen gerichteten Seite nur die physikalischen Gegebenheiten der technischen Welt. Die erzeugte Nutzungswelt ist Tognazzinis „fanciful illusion“, also, wenn man so will, eine Scheinwelt, die aber für den Nutzer die Welt ist, mit der sich ihm sich der Computer präsentiert, also die einzig wahre Welt. Um derartige „Scheinwelten“ der verschiedenen Nutzungsschnittstellen geht es mir in diesem Buch. Wie sind sie entstanden? Welche Nutzungsanforderungen standen hinter ihrer Ausgestaltung? Welche technischen Probleme waren zu lösen? Was waren die Hintergründe hinter Nutzungsschnittstellen, die heute kurios wirken, und inwiefern haben Designentscheidungen aus vergangenen Jahrzehnten noch heute Auswirkungen auf die Art und Weise, wie wir unsere Computer bedienen? Fragen dieser Art will ich in den kommenden Kapiteln nachgehen. Ich hoffe, Sie folgen mir dabei!

Vom ENIAC zum Minicomputer

Im Vergleich mit anderen technischen Einrichtungen, die wir im Alltag nutzen, etwa Aufzügen, Autos, Taschenlampen oder Kugelschreibern, sind Computer eine sehr neue Erscheinung. Die ersten elektrischen und elektronischen Computer wurden Ende der 1930er und in den 1940er Jahren gebaut. Bis Computer in jedem Büro und in vielen Haushalten zu finden waren, dauerte es noch weitere vierzig Jahre. Dieser erste Abschnitt des Buches betrachtet die Entwicklung des Computers und seiner Nutzungsschnittstelle von den Anfängen bis zum Aufkommen der Personal Computer Ende der 1970er Jahre. Sie werden sehen, dass der Personal Computer nicht etwa eine völlig aus dem Nichts entstandene Revolution war, wie es so manche Computergeschichte suggeriert, sondern dass PCs und deren Nutzungsschnittstellen in der Tradition einer zunehmenden Miniaturisierung der Rechen- und Speichertechnik und einer zunehmend direkten Interaktion des Nutzers mit von der Nutzungsschnittstelle erzeugten virtuellen Objekten stehen.

Die frühen Computer

Wenn Technikgeschichten erzählt werden, gibt es, wie ich in der Einleitung schon angedeutet habe, offenbar ein Bedürfnis, das erste Exemplar eines bestimmten Gerätes herauszufinden. Auch in der Welt der Computer und Rechenmaschinen ist dieser Wunsch nicht unbekannt. In einer Gesellschaft, die vom Wettbewerb gekennzeichnet ist, scheint es wichtig, herauszufinden, welcher Computer von allen der erste war. Leider ist diese Frage gar nicht ohne Weiteres zu beantworten, denn man müsste zunächst einmal wissen, was überhaupt ein Computer ist. Darauf, dass ein Computer etwas ist, mit dem man rechnen kann, kann man sich vielleicht noch recht schnell einigen. Diese Beschreibung gilt aber auch für einen Abakus, einen Rechenschieber oder eine alte mechanische Registrierkasse aus dem Museum. Diese Gegenstände und Geräte werden aber üblicherweise nicht Computer genannt. Welche Eigenschaften muss ein Gerät also haben, damit man es einen Computer nennen kann und mit ins Rennen um den ersten Computer schickt? Je nachdem, wie man diese Frage beantwortet, kann man ein anderes Gerät als den ersten Computer identifizieren. Es ist zum Beispiel durchaus verständlich, den amerikanischen ENIAC (Electronic Numerical Integrator and Computer) aus dem Jahr 1945 als ersten Computer anzusehen. Der deutsche Ingenieur Konrad Zuse hat allerdings schon Jahre vorher automatische Rechengeräte konzipiert und gebaut. Wenn wir seine mechanischen Rechner außen vor lassen, die noch nicht wirklich einsatzfähig waren, kann man Zuses Computer Z3 von 1941 genauso gut als ersten Computer betrachten. Die Z3 war allerdings im Gegensatz zum ENIAC nicht elektronisch, sondern elektrisch bzw. elektromechanisch¹, denn sie arbeitete mit Telefonrelais. Auch war die Z3 nicht als turingmächtige Maschine konzipiert. „Turingmächtig“ ist ein Begriff aus der theoretischen Informatik. Er bedeutet, vereinfacht gesagt, dass Sie mit dem Computer, wenn er denn nur über genug Speicher verfügt und Sie hinreichend Zeit haben, all das zu berechnen imstande sind, was Sie auch mit einem heutigen PC berechnen können. Mit Computern, die nicht turingmächtig sind, können Sie einige Berechnungen nicht durchführen. Die Zuse Z3 hatte etwa keine bedingte Befehlsausführung. Sie konnten mit ihr also nichts automatisch berechnen, was einer Fallunterscheidung bedürfte.

Die Z3 war in gewisser Weise wirklich der erste, aber eben (nur) der erste elektromechanische, programmierbare, vollautomatische Computer, während der ENIAC auch der erste, aber eben der erste elektronische, universell programmierbare Computer war. Auch andere Rechengeräte kommen für das Rennen um den ersten Computer infrage, so etwa der britische Colossus von 1943, der wie der ENIAC mit Röhren arbeitete und somit elektronisch war. Es handelte sich bei dieser Maschine aber nicht um einen universellen Rechner, sondern um einen Spezialrechner zum Knacken verschlüsselter Textnachrichten. Er wurde im Zweiten Weltkrieg genutzt, um Nachrichten der deutschen Admiralität zu entschlüsseln. Seine Programmiermöglichkeiten waren sehr beschränkt. Dennoch war der Colossus der erste Computer, nämlich der erste elektronische, teilprogrammierbare, digitale Spezialrechner.

Welcher Computer nun, mit den jeweiligen Attributen versehen, als erster Computer beschrieben wird, hängt – absurderweise – oft davon ab, aus welchem Land derjenige kommt, der die Zuschreibung macht. In den USA wurde lange Zeit nur der ENIAC als erster Computer betrachtet, in Deutschland wurde eher die Zuse Z3 als erster Computer angesehen und in England feierte man seit dem Ende der Geheimhaltung über das Knacken der deutschen Codes während des Zweiten Weltkriegs den Colossus als den ersten Computer. Ich möchte in dieser Frage nicht den Schiedsrichter spielen und einen ersten Computer küren, denn letztlich ist es ziemlich belanglos, welchem Gerät Sie den Titel geben, und die offenbare Verbindung der Suche nach dem Ersten mit Nationalstolz macht mir die Frage gänzlich unsympathisch. Aus dem Wettstreit darum, wer nun der Erste war, können wir eine vielleicht versöhnliche Konsequenz ziehen: Ende der 1930er bis Anfang der 1940er Jahre wurden an mehreren Orten auf der Erde unabhängig voneinander Anstrengungen unternommen, vollautomatische, elektronische Rechenanlagen zu bauen. Der Zweite Weltkrieg spielte bei der Entwicklung zwar eine zentrale Rolle, doch offenbar war auch – unabhängig davon – die Zeit einfach reif für die Erfindung des Computers.

Programmierung durch Verkabelung

Wenn Sie einmal etwas über die Bedienung früher Computer gesehen oder gelesen haben, haben Sie vielleicht ein Bild des amerikanischen ENIAC gesehen. Der Rechner wurde von 1943 bis 1945 für das amerikanische Militär gebaut und unter anderem dafür eingesetzt, komplexe Berechnungen für ballistische Flugbahnen durchzuführen. Der Rechner war dreißig Tonnen schwer, füllte eine ganze Halle und hatte eine Leistungsaufnahme von sage und schreibe 150 kW. Seine auffälligste Eigenheit war aber wohl, dass er per Verkabelung programmiert wurde und dass Eingabewerte für die Berechnungen unter anderem durch das Stellen von Drehschaltern eingegeben wurden.

Oben sehen Sie eine typische Ansicht des ENIAC. Auf der linken Seite sehen Sie das Programm in Form der Verkabelung der Module des Rechners. Auf der rechten Seite sind auf fahrbaren Gestellen angebrachte Anordnungen von Drehschaltern zu sehen, mit denen Zahlenwerte eingestellt werden konnten. Programmieren bedeutete beim ENIAC in seiner ursprünglichen, hier abgebildeten Konfiguration, etwas ganz anderes, als das, was man sich heute darunter vorstellt. Selbst das „Programm“ war beim ENIAC überhaupt nicht mit dem zu vergleichen, was später als Programm bezeichnet wurde und auch heute noch so bezeichnet wird. Der ENIAC war nur Hardware und auch das Programm war Teil dieser Hardware. Ohne die gesteckten Kabel war der ENIAC einfach nur eine Sammlung von Modulen wie etwa Akkumulatoren (Addierern), Multiplikatoren, Dividierern, Einstellfeldern sowie Druckern, Lochkartenlesern und entsprechenden Stanzern für die Ein- und Ausgabe. Die Verbindungen zwischen den Modulen bildeten das Programm. Den ENIAC zu programmieren, bedeutete, die Module entsprechend dem, was man berechnen wollte, miteinander zu verbinden. Heutzutage wird unter einem Programm im Allgemeinen eine Folge von Anweisungen verstanden, die dazu dienen, den Computer zu steuern. Dabei wird das Programm vom Computer Anweisung für Anweisung verarbeitet. Beim ENIAC konnte man das so nicht sagen. Der Rechner verarbeitete das Programm nicht und das Programm steuerte den Rechner auch nicht, sondern war ein Teil des Computers. Es handelte sich beim ENIAC um eine Art raumfüllenden Bausatz, aus dem sich der Programmierer für jedes zu lösende Problem einen neuen Computer zusammensetzte. Der ENIAC, der das Problem A lösen konnte, war, genau genommen, nicht der gleiche Computer, wie der, der das Problem B zu lösen imstande war.

Ein Programm für den ENIAC, also seine Verkabelung zum Lösen einer speziellen, meist komplexen, Rechenaufgabe, wurde auf Papier geplant. Oben ist ein Ausschnitt aus einem solchen „Panel Diagram“ abgebildet. Das Erstellen solcher Pläne dauerte oft Wochen und das anschließende Programmieren des Rechners durch das Stecken von Kabeln dann nochmals mehrere Tage. Die eigentliche Berechnung war dann, insofern der Rechner richtig funktionierte und bei der Planung und Verkabelung keine Fehler gemacht wurden, innerhalb weniger Minuten oder allenfalls Stunden erledigt.

Bilder des ENIAC werden gerne gezeigt, um darzustellen, wie weit die Computertechnik inzwischen fortgeschritten ist, schließlich sieht der ENIAC so schön primitiv und ungewöhnlich aus. Diese etwas verächtliche Sicht wird aber weder dem ENIAC noch den Computern danach wirklich gerecht. Die Art, wie der ENIAC programmiert wurde, hatte nämlich durchaus einen Vorteil, nämlich den der vergleichsweise hohen Rechengeschwindigkeit. Große Teile des Rechenprozesses liefen beim ENIAC parallel ab. Zudem konnte der Rechner sofort nach dem Start mit der Berechnung beginnen, denn das Programm lag ja in Form der Verkabelung und der Stellungen der Einstellglieder komplett vor. Es musste nicht erst langwierig eingelesen werden, wie es bei vielen Rechnern danach nötig war. Beides machte den ENIAC für die damalige Zeit extrem schnell. Diesem Vorteil stand allerdings die sehr schwierige Programmierung gegenüber. Es zeigte sich schnell, dass eine serialisierte und dadurch langsamere Arbeitsweise zugunsten einer besseren Programmierbarkeit gut in Kauf genommen werden konnte.

Programme als eigenständige Artefakte

Ein Programm des ENIAC war nicht im heutigen Sinne eine Abfolge von Anweisungen an den Computer, sondern der aktuelle Hardware-Zustand des Rechners, also die aktuellen Verkabelungen und Einstellungen. Es war kein eigenständiges physikalisches Artefakt, das dem Computer von außen zugeführt werden konnte. Den ENIAC neu zu programmieren, bedeutete, ihn komplett neu zu konfigurieren und zu verkabeln. Meines Wissens nach steht der ENIAC mit dieser Art und Weise der Programmierung ziemlich allein auf weiter Flur. Alle mir bekannten späteren, aber auch früheren Computer, wie die von Konrad Zuse, mussten zum Programmieren nicht komplett neu verkabelt werden. Programme lagen stattdessen als ein eigenes Artefakt vor, das dem Computer von außen als Eingabe zugeführt wurde. Die eigentliche Hardware des Computers blieb beim Programmwechsel unverändert. Als Grenzfall kann man hier einige IBM-Geräte ansehen, die durchaus über Programme auf Stecktafeln und damit als Verkabelung verfügten. IBM knüpfte hier an die Tradition seiner Maschinen an, mit denen Daten von Lochkarten tabelliert und verarbeitet werden konnten. Diese Geräte wurden durch Stecken von Kabeln konfiguriert. Kabelverbindungen legten etwa fest, welche Spalte eines Datensatzes addiert und was mit dem Ergebnis am Ende geschehen sollte. Frühe IBM-Rechner übernahmen diese Konfigurationsmöglichkeit zum Teil, waren aber nicht darauf festgelegt, dass Programme zwangsläufig auf diese Art und Weise spezifiziert werden mussten.

Betrachten wir einen Computer, der fast gleichzeitig mit dem ENIAC entwickelt wurde: Unten abgebildet ist der Rechner Z4 von Konrad Zuse. Die Entwicklung an diesem Rechner begann 1942 und war 1945 abgeschlossen. Vorher hatte Zuse den bereits kurz erwähnten Rechner Z3 gebaut, der 1941 fertiggestellt wurde. Die Z3 war aber für heutige Maßstäbe ziemlich eingeschränkt. Sie war, obwohl sie natürlich ziemlich groß war, eher vergleichbar mit einer Art automatisierbarem Taschenrechner als ein Computer im modernen Sinne, denn dem Rechner fehlte etwas ganz Grundlegendes, ohne das wir uns heute Computer und Programmierung gar nicht mehr vorstellen können. Der Befehlssatz der Z3 enthielt, wie oben schon angedeutet, keine bedingten Befehlsausführungen. Die Konsequenz: Die Programme der Z3, von Zuse „Rechenpläne“ genannt, konnten zwar die gleichen Rechenschritte für verschiedene Eingaben durchführen, aber nicht anhand von Zwischenergebnissen verschiedene Rechenwege wählen. Die Z4 war der Z3 von der grundsätzlichen Arbeitsweise her zwar sehr ähnlich, verfügte aber im Gegensatz zu ihrer Vorgängerin über ebendiese bedingten Befehlsausführungen.

Programme lagen bei Zuses Rechnern Z3 bis Z11 als Lochstreifen² vor. Auf der Abbildung rechts ist ein kurzer Lochstreifen zu sehen. Lochstreifen dieser Art wurden bei Computern bis in die 1970er Jahre hinein als Eingabemedium genutzt. Es handelt sich um einen einfachen Papierstreifen. Auf diese Streifen wurden Reihen von Löchern gestanzt. Eine solche Reihe war jeweils eine binäre Codierung eines Zeichens oder einer Zahl. Binär bedeutet, dass es sich um eine Codierung mit zwei Zuständen handelt. Jede Zahl entspricht also einer Folge aus Ja und Nein, 1 und 0 oder hier Loch und Nicht-Loch. Typische Lochstreifen enthielten pro Zeile meist entweder 5 oder 8 Löcher, der Code entsprechend 5 oder 8 Bit.

Diese Lochstreifen wurden nicht für den Computer erfunden, sondern fanden schon lange vorher in der Nachrichtentechnik für Fernschreiber Verwendung. Ein Fernschreiber war im Prinzip nichts anderes als eine Schreibmaschine, die mit einer anderen Schreibmaschine – einem anderen Fernschreiber – verbunden werden konnte. Diese Verbindung konnte über explizite Telegrafenleitungen oder auch über eine Telefonleitung per Modem erfolgen. Sobald zwei Fernschreiber miteinander verbunden waren, erschien alles, was auf einem der Fernschreiber geschrieben wurde, auch auf dem anderen Gerät. Fernschreiber erlaubten also das simultane Übermitteln von Textnachrichten über große Entfernungen – also etwa das, was wir heute „Chatten“ nennen. Viele Fernschreibgeräte verfügten über Lochstreifenleser und Lochstreifenstanzer. War ein Stanzer beim Empfang einer Nachricht eingeschaltet, wurden die empfangenen und eingegebenen Zeichen nicht nur auf Papier gedruckt, sondern zusätzlich entsprechend codiert auf den Streifen gestanzt. Über einen Leser konnte ein Fernschreiber einen Lochstreifen elektronisch einlesen und verhielt sich dann so, als würden die codierten Zeichen gerade in diesem Moment eingetippt. Lochstreifen dienten also dazu, Texte zwischenzuspeichern, um sie mehrfach senden oder um einen von einer Gegenstelle empfangenen Text an eine andere Stelle weitergeben zu können. Fernschreiber werden uns im Kapitel Time-Sharing wieder begegnen. Im Moment reicht uns ihr Speichermedium, der Lochstreifen.

Zuse verwendete die Lochstreifen nicht zur Speicherung von natürlichsprachlichen Texten, sondern zur Speicherung eines „Rechenplans“, also dessen, was wir heute „Programm“ nennen würden. Ein Rechenplan bestand aus einer Reihe von recht simplen Befehlen, die dann, eventuell um Zahlenwerte angereichert, in Bit-Folgen umgewandelt auf dem Lochstreifen abgelegt waren. Ich möchte hier, was diese Befehle angeht, nicht zu sehr ins Detail gehen. Es reicht an dieser Stelle, wenn Sie wissen, dass die Befehle größtenteils aus einfachen Rechenoperationen, also Addieren, Subtrahieren, Multiplizieren, Dividieren, Wurzelziehen etc. bestanden. Hinzu kamen Befehle, um Zahlen im Speicher des Computers abzulegen oder aus dem Speicher zu laden. Der Computer verfügte über zwei sogenannte „Register“. Diese Register waren spezielle Speicher, die die Recheneinheit in direktem Zugriff hatte. Es standen also stets nur zwei Zahlen direkt für Berechnungen zur Verfügung. Brauchte man im Programmverlauf eine berechnete Zahl später erneut, musste man sie im Arbeitsspeicher ablegen und danach wieder in ein Register laden. Einer der wichtigsten Befehle im Befehlssatz des Z4 und seiner Nachfolger war die bedingte Befehlsausführung. Sie prüfte zum Beispiel, ob das aktuelle Zwischenergebnis in einem der Register größer als Null war. War dies der Fall, wurde der darauffolgende Befehl auf dem Lochstreifen ausgeführt, andernfalls wurde er ignoriert.

Zuses Rechner lasen das Programm von einem Lochstreifenleser Befehl für Befehl ein und führten es direkt aus. Die Z3 hatte nur einen derartigen Programmleser. Die Rechner ab der Z4 besaßen zwei Lochstreifenleser. Mittels eines speziellen Programmbefehls konnte ein Programm den Rechner dazu veranlassen, zwischen beiden Lochstreifenlesern umzuschalten. Das Hinzufügen des zweiten Lochstreifenlesers erlaubte es den Programmierern, sogenannte Schleifen zu programmieren. Schleifen sind eine sehr grundlegende Technik in der Programmierung. Man braucht sie immer dann, wenn man es mit einer großen Menge an Informationen, etwa einer Liste, zu tun hat, die abgearbeitet werden muss, oder allgemeiner, wenn man etwas so lange wiederholen muss, bis eine bestimmte Bedingung erfüllt ist. Das Programm muss in solchen Fällen einen ganzen Satz von Befehlen immer wieder durchführen, bis alle Daten verarbeitet sind oder die gewünschte Bedingung eingetreten ist. Den Ausdruck „Schleife“ konnte man bei der Z4 ziemlich wörtlich nehmen. Es wurde zum Erzeugen einer Schleife nämlich schlicht und ergreifend der in den zweiten Leser eingelegte Lochstreifen zu einer Schleife (bzw. eigentlich zu einem Ring) gebunden, sodass die gleichen Programmbefehle immer wieder von vorne gelesen wurden. Im vom ersten Lochstreifenleser gelesenen Programm konnte auf den zweiten Lochstreifenleser umgeschaltet werden. Auf diesem lief die Schleife ab. Damit der Rechner nun nicht bis in alle Ewigkeit diese Schleife abarbeitete, musste der in Schleife gebundene Programmteil einen bedingten Befehl enthalten, der irgendwann wieder auf den ersten Lochstreifen zurückschaltete oder den Programmablauf ganz beendete.

In der Architektur von Zuses Rechnern kann man die Charakteristik der Probleme erkennen, die Zuse lösen wollte. Zuse musste in seiner früheren Arbeit als Ingenieur im Bereich der Luftfahrt feststellen, dass immer gleiche Berechnungen immer wieder mit verschiedenen Werten durchgeführt werden mussten. Um diese mühselige und sich stets wiederholende Arbeit zu vereinfachen, wollte er eine Maschine entwickeln. Diese Grundcharakteristik – gleiche Rechenschritte, verschiedene Werte – spiegelte sich in der Nutzungsschnittstelle seiner Maschinen wider. An einem Zuse-Rechner, und hier unterscheiden sich die Rechner von Z3 bis Z11 überhaupt nicht, wurde stets grundsätzlich folgendermaßen gearbeitet:

• Die Lochstreifen, auf denen „der Rechenplan“ gespeichert war, wurden in die Lochstreifenleser eingefädelt.
• In den ersten Schritten des Rechenplanes wurden die initialen Werte per Tastatur „eingetastet“ und im Speicher abgelegt. Obwohl Zuses Rechner intern im Binärsystem arbeiteten, also mit 0 und 1, erfolgte die Eingabe im ingenieurfreundlichen Dezimalsystem. Die Konvertierung fand direkt nach der Eingabe statt.
• Waren alle Werte eingegeben, startete die eigentliche Berechnung. Der Rechner arbeitete nun die auf dem Lochstreifen gespeicherten Befehle einen nach dem anderen ab. Ausgaben des Programms erfolgten auf einer elektrischen Schreibmaschine.

Die Bedienung der Zuse Z4

Zuses Z4 war ein Rechner für Ingenieure. Diese Ingenieure saßen in der Regel selbst am Rechner und führten ihre Berechnungen durch. Wichtig ist dabei – wir werden gleich sehen, dass es auch ganz anders sein kann – dass Eingaben direkt am Rechner und direkt vor der Programmausführung gemacht wurden. Der Nutzer war bei der Rechnung anwesend und konnte den Programmablauf an der Steuerkonsole des Rechners kontrollieren, im Fehlerfall unterbrechen und Befehle manuell, vom Programm unabhängig, ausführen. Zahlen konnte die Z4 sowohl von einer Tastatur als auch von einem speziellen Lochstreifen – Zahlenstreifen genannt – einlesen, wobei gerade der Eingabe per Tastatur in Sachen Nutzungsschnittstelle viele Überlegungen zukamen. Eine Bedienungsanleitung des Rechners von 1953³ etwa beschreibt:

Die eingetastete Zahl erscheint zur Kontrolle im Lampenfeld. Wenn
diese Kontrolle nicht stimmt: Taste "Irrtum" drücken und korrigieren.
Stimmt die Kontrolle: Taste "Fertig" drücken; dies bewirkt Überfüh-
rung der Zahl ins Rechenwerk und verunmöglicht jede Korrektur.

[...]

Die Aufforderung an die Bedienungsperson zum Eintasten (beim Rechnen
mit eingelegtem Rechnenplan) ist ein rotes Blinksignal, oder das
Aufleuchten einer Protokoll-Lampe.

Die besagte Protokoll-Lampe unterstützte den Ingenieur am Rechner bei der Eingabe vieler Werte für seine Berechnung. Sie war Teil des sogenannten Protokollfeldes, das darauf hinwies, welcher Wert zur Eingabe erwartetet wurde. Die Bedienungsanleitung beschreibt:

     Das Prokollfeld dient zur Erleichterung des Eingebens vieler
Zahlen in bestimmter Anordnung (Matrix). Es ist jeweils die Zahl
des Protokolls einzugeben, unter der das Licht aufleuchtet. Dazu
müssen die Zahlen auf einem Protokollformular notiert werden, das
auf die Mattscheibe aufgelegt wird. Ein Protokollformular kann
natürlich nur zusammen mit einem bestimmten Rechenplan verwendet werden.

Für einen Rechenplan, bei dem eine ganze Reihe von Eingabewerten gemacht wurden, wurde also in gewisser Weise eine Art Eingabeformular mitgeliefert. Der Rechner konnte so jeweils anzeigen, welcher Wert nun eingegeben werden sollte.

Da die Eingabebefehle der Z4 die Recheneinheit anhielten und der Rechner außerdem über eine bedingte Befehlsausführung verfügte, wäre mit der Z4 grundsätzlich eine interaktive Arbeitsweise möglich gewesen, bei der die Nutzer während des Programmablaufs dazu aufgefordert worden wären, weitere Werte einzugeben, auf die das Programm dann hätte reagieren können. Diese Arbeitsweise war allerdings nicht üblich. Alle Erklärungen und Programmbeispiele für die Z4, die sich finden lassen, sehen vor, zu Beginn alle Daten eingeben zu lassen und diese danach ohne weitere Eingabenotwendigkeiten zu verarbeiten. Eine Programmieranleitung von Zuse aus dem Jahr 1945⁴ empfiehlt etwa explizit:

Bei längeren Rechenplänen speichert man nicht nur diejenigen 
Werte, deren Speicherung unbedingt nötig ist, um das Rechenwerk 
frei zu machen, sondern es werden zunächst einmal sämtliche 
Ausgangswerte ins Speicherwerk eingegeben und daraufhin die 
eigentlich Rechnung durchgeführt. Dies hat folgende Vorteile:

1.) Der Aufbau des Rechenplanes ist einfacher.
2.) Bei der praktischen Durchrechnung erfolgt die Eintastung 
    der Ausgangswerte zügig am Anfang hintereinander. Darauf-
    hin kann man die Maschine sich selbst überlassen.
3.) Die Werte können in der logischen Reihenfolge eingetastet 
    werden.
4.) Es kann nachträglich kontrolliert werden, ob die Maschine 
    mit den richtigen Werten gerechnet hat.

Dass eine interaktive Nutzung nicht das war, was Zuse für seinen Rechner im Sinne hatte, wurde im Übrigen schon durch die Aufteilung der Ein- und Ausgabgeräte (in der Anleitung Eingang und Ausgang genannt) klar. Protokollfelder, Tastatur und Zahlenfeld, also die Elemente für die komfortable Dateneingabe, befanden sich in unmittelbarer Nähe zueinander, die Schreibmaschine zur Ausgabe in einiger Entfernung davon. Zwar hatte diese Schreibmaschine auch eine Tastatur. Diese diente aber nicht der Eingabe für den Rechner.

Die angenehme Möglichkeit der Eingabe von Daten kann durchaus als ein Vorteil der Z4 angesehen werden. Ihr größter Nachteil, den sie mit allen frühen Rechnern von Zuse bis einschließlich Z11 teilte, war ihre geringe Verarbeitungsgeschwindigkeit. Die Computer arbeiteten mit Telefonrelais, die in ihrer Geschwindigkeit aufgrund der elektromechanischen Arbeitsweise natürlich eingeschränkt waren. Vor allem aber begrenzte die Art und Weise der Programmausführung, bei der das Programm während seiner Verarbeitung Befehl für Befehl vom Computer eingelesen wurde, die Geschwindigkeit. Zwar konnte man das Einlesen von Lochstreifen in gewissem Rahmen beschleunigen, doch hier gab es eine Obergrenze dessen, was möglich war, denn schließlich musste ja ein Papierstreifen von einer Rolle abgerollt werden. Das Papier durfte dabei nicht reißen oder zerknittern. Selbst wenn man hiervon einmal absah, gab es ein grundlegendes Problem: Ein Programm, das sequenziell eingelesen wurde, konnte natürlich auch nur sequenziell abgearbeitet werden. Es gab keine Möglichkeit, in einem Schritt an eine andere Stelle auf dem Lochstreifen zu springen und das Programm dort fortzusetzen. Ein Sprung an Stellen im Programm ist aber für komplexere Programme unbedingt notwendig. Zuses Rechner hatten, im Gegensatz zu den Computern, die ich Ihnen im weiteren Verlauf des Buches vorstellen werde, keinen Sprungbefehl, sondern einen Übersprungbefehl, der während des Einlesens des Programms alle Befehle überging, bis ein bestimmter Code eingelesen wurde. Durch die trickreiche Kombination dieses Übersprungbefehls mit der zuvor erläuterten Technik der Schleife war es so möglich, Programme mit mehreren Unterprogrammen zu erzeugen.

Ein Unterprogramm verwendet man in der Programmierung, wenn bestimmte Befehlsfolgen in einem Programm an verschiedenen Stellen immer wieder genutzt werden. Statt sie jedes mal zu wiederholen, lässt man den Computer an die Stelle im Programm springen, an der diese Befehle notiert sind, und springt hinterher wieder zurück ins eigentliche „Hauptprogramm“. Die Verwendung von Unterprogrammen macht die Programme nicht nur kürzer, sondern auch besser wartbar, denn Verbesserungen müssen nun nicht mehrfach sondern nur noch an einer Stelle vorgenommen werden. Da die Zuse-Rechner keinen Sprungbefehl hatten, war das Anspringen eines solchen Unterprogramms stets mit dem Überspringen vieler Programmbefehle verbunden, die dennoch eingelesen werden mussten⁵. Die Recheneinheit musste in dieser Zeit warten, bis es weitergehen konnte. Diese Arbeitsweise war weder schnell noch in der Programmierung besonders praktisch.

Stored Program – Das Programm im Computer

Eine viel schnellere Programmausführung und ein einfacheres Springen innerhalb eines Programms wurde dadurch möglich, dass das Programm während der Ausführung nicht Befehl für Befehl eingelesen wird, sondern bereits vollständig im Speicher vorliegt. Ein Rechner, der dies ermöglicht, wird „Stored Program Computer“ genannt. Im Deutschen wird hierfür oft der Begriff „speicherprogrammierbar“ verwendet, der aber, genau genommen, nicht ganz das Gleiche bezeichnet, legt er doch nicht nur nahe, dass sich das Programm im Speicher befindet, sondern auch, dass es im Speicher erstellt und bearbeitet werden kann. Auf diese Möglichkeit will ich an dieser Stelle aber (noch) nicht hinaus.

Einen Stored Program Computer zu betreiben, bedeutete natürlich, das Programm zunächst vollständig einlesen zu müssen. Wie lag so ein Programm vor? Was war das Speichermedium? Lochstreifen als Eingabemedium haben Sie schon kennengelernt. Auch ein Stored Program Computer konnte grundsätzlich mit Lochstreifen gefüttert werden. Der britische EDSAC von 1949, einer der ersten nennenswerten Computer, die nach dem Stored-Program-Konzept arbeiteten, verwendete zum Beispiel dieses einfache Eingabemedium – sowohl für das Programm als auch für die Daten.

Ein weiteres verbreitetes Speichermedium für Computer der damaligen Zeit waren Lochkarten. Die Geschichte der Lochkarten ist, wie auch schon die der Lochstreifen, weit älter als die Geschichte digitaler Computer. Die ersten Lochkarten wurden schon 1890 für die teilautomatische Auswertung der US-amerikanischen Volkszählung verwendet. Die Daten der einzelnen Bürger wurden dazu mit einem speziellen Gerät auf Karten gelocht. Ein Loch an einer bestimmten Stelle stand für das Geschlecht des Bürgers, ein anderes für die Religionszugehörigkeit, ein drittes gab den Beruf an. Die so erzeugten gelochten Karten konnten in Zählgeräte eingegeben werden. Je nach Lochung wurden dann Zähluhren einen Schritt weiter geschaltet. Herman Hollerith, der die Lochkartentechnik für die Volkszählung erfand, gründete Firmen auf Grundlage dieser Technologie. Seine Firmen bauten sowohl Eingabegeräte, um Lochkarten mit Daten zu füllen, als auch Verarbeitungsgeräte, die etwa die Daten eines Lochkartensatzes aggregieren und tabellarisch darstellen konnten. Holleriths Firmen gingen 1911 in der Computing Tabulating Recording Company auf, die in den 1920er Jahren in International Business Machines umbenannt wurde. Von dieser Firma IBM sollte in den folgenden Jahren der Computergeschichte noch häufig die Rede sein.

Die Standard-Lochkarten von IBM wurden nun auch für Computerprogramme und zur Dateneingabe in einen Computer verwendet. Das Prinzip einer Lochkarte war dem eines Lochstreifens dabei grundsätzlich sehr ähnlich. Ein Lochkartenleser las einen Lochkartenstapel Karte für Karte ein. Beschrieben werden konnten Lochkarten auf Lochkartenstanzern wie dem oben abgebildeten. Eine einzelne Karte entsprach in der Regel einem Datensatz oder, im Falle der Programmierung, einem Programmbefehl.

Nahezu alle Computer, die nach dem ENIAC gebaut und entwickelt wurden, waren Stored Program Computer. Auch der ENIAC wurde so umgebaut, dass man ihn als Stored Program Computer bezeichnen konnte⁶. Er lief dann zwar, je nach Berechnung, nur noch mit einem Sechstel der vorherigen Geschwindigkeit, da die Parallelität nicht mehr so gut ausgenutzt werden konnte, doch wurde dieser Performance-Verlust während der Berechnungen durch die erheblich einfachere Programmierbarkeit mehr als ausgeglichen. Als dritte Möglichkeit konnte der ENIAC nach dem Umbau auch das Programm direkt von Lochkarten einlesen. Das war natürlich noch langsamer und schränkte die Programmierbarkeit ein, da das Programm nicht im Speicher abgelegt, sondern Schritt für Schritt abgearbeitet wurde. Es hatte aber den Vorteil, dass keine Hardware-Änderungen mehr vorgenommen werden mussten und Programme leicht austauschbar und damit auch verbesserbar wurden.

Wie nutzt man einen Stored Program Computer wie den EDSAC?

Um einen typischen Stored Program Computer nutzen zu können, mussten sowohl das Programm als auch alle Eingabedaten vor dem Programmablauf vorliegen. Es mussten also zumindest alle Daten auf Lochkarten oder Lochstreifen vorbereitet werden. Wenn ein neues Programm geschrieben und ausgeführt werden musste, geschah dies in einem langwierigen Prozess:

• Das Programm wurde auf Papier in einem Code aufgeschrieben, der dem Befehlssatz des Computers entsprach. Diese Art des Programmcodes wird Assembler-Sprache⁷ genannt. In Assembler-Sprache entsprechen die Befehle direkt denen der Computerarchitektur. Befehle müssen aber nicht als Bitmuster oder Zahlen eingegeben werden, sondern werden durch leichter verstehbare Kürzel, sogenannte „Mnemonics“, notiert. Statt 01001011 notiert man in Assembler-Sprache zum Beispiel ADD für den Addierbefehl. Auch höhere Programmiersprachen waren möglich, kamen aber erst Anfang der 1960er Jahre auf. Mehr dazu daher im folgenden Kapitel.
• Aus dem Assembler-Code musste das Programm in die Maschinensprache umcodiert werden. Aus Befehlen, die aus kurzen Buchstabenfolgen bestehen, etwa JMP für den Sprungbefehl, wurden so wieder Zahlenwerte, die der Computer direkt verarbeiten konnte.
• Dieses Maschinensprachenprogramm musste nun auf Lochkarten oder Lochstreifen gestanzt werden.
• Die Lochkarten oder Lochstreifen mit dem Programm und allen Eingabedaten wurden einem Operator übergeben. Der Operator verwaltete eine Warteschlange von Programmen, die noch vor dem abgegebenen abzuarbeiten waren.
• Wenn das Programm an der Reihe war, ließ der Operator das Programm einlesen, legte die Eingabedaten in den Lochstreifen- oder Lochkartenleser und startete das Programm.
• Ausgaben des Programms wurden auf einem Drucker ausgeführt.
• Der Operator legte das Programm, die Eingabedaten und die ausgedruckten Ausgaben des Programms in einem Ausgabefach bereit, wo sie vom Nutzer abgeholt werden konnten.

Ganz schön kompliziert, etwas mit einem solchen Computer zu programmieren und das Programm dann auszuführen! Charakteristisch für die skizzierte Arbeitsweise war, dass Nutzer oder Programmierer – in den meisten Fällen wohl ein und dieselbe Person – mit dem Computer selbst gar nicht in Berührung kamen. Wie hoch, meinen Sie, war wohl die Wahrscheinlichkeit, dass ein so erstelltes Programm beim ersten Versuch komplett korrekt war? Es musste korrekt in Assembler-Sprache auf Papier programmiert, fehlerfrei in Maschinencode übertragen und dann ebenso richtig abgelocht worden sein. Ich möchte nicht für alle sprechen, aber ich zumindest würde sicher stets etliche Durchläufe brauchen, bis mein Programm korrekt wäre. Dieses Programmierproblem war nicht die einzige Konsequenz der Abgekoppeltheit zwischen der Bereitstellung von Programm und Daten und der Verarbeitung des Programms durch den Computer. Problematisch war auch die fehlende Interaktivität. Es war bei dieser Nutzungsweise gar nicht möglich, ein Programm zu schreiben, das dem Nutzer während des Programmablaufs eine Entscheidung abverlangte. Auch konnte der Nutzer nicht eingreifen, wenn das Programm „Amok lief“, also sinnlos lange rechnete, in eine Dauerschleife geriet oder massenweise unsinnige Ausgaben produzierte. Der Nutzer war ja überhaupt nicht anwesend. Alle Eventualitäten mussten vorher bedacht werden. Explizit formuliert wird dies in einem unter Informatikern recht berühmten Paper, das unter dem Namen John von Neumanns veröffentlicht wurde. In diesem „First Draft Report on the EDVAC“⁸ von 1945 wird ausgeführt:

An automatic computing system is a (usually highly composite) device, which can carry out instructions to perform calculations of a considerable order of complexity—e.g. to solve a non-linear partial differential equation in 2 or 3 independent variables numerically. The instructions which govern this operation must be given to the device in absolutely exhaustive detail. They include all numerical information which is required to solve the problem under consideration: Initial and boundary values of the dependent variables, values of fixed parameters (constants), tables of fixed functions which occur in the statement of the problem. These instructions must be given in some form which the device can sense: Punched into a system of punchcards or on teletype tape, magnetically impressed on steel tape or wire, photographically impressed on motion picture film, wired into one or more fixed or exchangeable plugboards—this list being by no means necessarily complete. All these procedures require the use of some code to express the logical and the algebraical definition of the problem under consideration, as well as the necessary numerical material.

Once these instructions are given to the device, it must be able to carry them out completely and without any need for further intelligent human intervention. At the end of the required operations the device must record the results again in one of the forms referred to above. The results are numerical data; they are a specified part of the numerical material produced by the device in the process of carrying out the instructions referred to above. (Hervorhebung nicht im Original)

Von Neumann beschreibt hier also einen Computer, bei dem Programme „without any need for further intelligent human intervention“ ablaufen. Nimmt man diese Definition so hin, kann man daraus ableiten, dass Computer für Nutzer und Programmierer überhaupt keine Nutzungsschnittstelle brauchen. Natürlich war auch von Neumann klar, dass tatsächliche Computer durchaus einige Bedienelemente brauchten, denn schließlich handelte es sich um Maschinen und Maschinen mussten gesteuert werden. Es brauchte zum Beispiel mindestens Knöpfe zum Ein- und Ausschalten, zum Starten und Unterbrechen der Operation und zum Einlesen des Programms und der Daten vom Lochkarten- oder Lochstreifenleser. Außerdem mussten sie natürlich auch über irgendeine Art Ausgabegerät, wie zum Beispiel einen Fernschreiber oder eine elektrische Schreibmaschine, verfügen. Diese Schnittstelle wäre das absolute Minimum. Die Kontrollpulte der Computer der damaligen Zeit hatten meist deutlich mehr Anzeigen und Knöpfe. Das reichte von der Anzeige der Aktivität einzelner Komponenten über die umfangreichen Darstellungen des Speicherinhalts bis hin zu Lampen zur Anzeige von Alarmzuständen. In der Tat gab es aber für das Programm selbst keinerlei Nutzungsschnittstelle. Das Programm lief, ganz von Neumann entsprechend, völlig ohne menschliche Intervention ab.

Diese Arbeitsweise mag Ihnen unpraktisch und unhaltbar vorkommen. Tatsächlich aber war diese Operationsart in vielen Bereichen bis weit in die 1970er Jahre der Standard. Die Trennung von Nutzer und Maschine wurde sogar, wie Sie im nächsten Kapitel sehen werden, noch weiter verstärkt.

Jobs und Batches

Große Computeranlagen, wie sie sich in Universitäten, Forschungseinrichtungen und manchen Firmen seit den 1960er Jahren fanden, waren im Vergleich zu den frühen Rechnern wie einem ENIAC oder einer Z4 sehr leistungsfähig, aber auch sehr teuer, sowohl in der Anschaffung als auch im Unterhalt. Die Bedienung der Rechner selbst erforderte Fachwissen, eine umfangreiche Einweisung und eine Menge Erfahrung. Den wenigen Menschen, die über dieses Wissen verfügten, meist Operator genannt, standen viele Nutzer gegenüber, die ein Interesse daran hatten, den Computer für ihre Berechnungen und für andere Formen der Datenverarbeitung zu verwenden. Der hohe Bedarf an Rechnernutzung und die Notwendigkeit, den teuren, leistungsstarken Rechner möglichst ideal auszunutzen, führte zur bereits im vorherigen Kapitel erläuterten Arbeitsweise, bei der die Computernutzer gar keinen Kontakt zur rechnenden Maschine hatten.

• Die Nutzer erstellten das Programm und hatten alle notwendigen Daten in Form von Lochstreifen oder Lochkarten zur Verfügung. Programm und Daten bildeten zusammen einen Rechenauftrag, einen sogenannten „Job“.
• Die Lochkarten oder Lochstreifen wurden im Rechenzentrum abgegeben. Dort wurden sie in eine Art Warteschlange einsortiert, während der Computer noch die Jobs anderer Nutzer verarbeitete.
• Wenn der entsprechende Job an der Reihe war, wurde zunächst das Programm von den Lochkarten oder vom Lochstreifen eingelesen und Befehl für Befehl in den Speicher kopiert. Es lag dann als Stored Program vor und konnte nun gestartet werden.
• Das Programm las im Laufe seiner Verarbeitung die Eingabe von den Lochkarten oder Lochstreifen ein. Dass das Programm die Daten zunächst vollständig las und in den Speicher übertrug, war möglich, beschränkte aber die mögliche Datenmenge aufgrund des limitierten Arbeitsspeichers.
• Während der Verarbeitung erzeugte das Programm Ausgaben in Form von Ausdrucken mittels Schnelldrucker oder elektrischer Schreibmaschine oder in Form neuer Lochkarten oder Lochstreifen.
• Nach Durchlauf des Programms wurden die Lochstreifen oder Lochkarten, die man eingereicht hatte, zusammen mit den erzeugten Ausgaben in ein Rückgabefach gelegt, aus dem sie vom Nutzer bei Gelegenheit abgeholt werden konnten.

Diese Arbeitsweise, die man job-basiert nennt, blieb aus Nutzersicht bei großen Rechnern in Universitäten, Forschungsinstituten und den meisten Firmen über viele Jahre hinweg gleich. Hinter den Kulissen wurden allerdings Optimierungen durchgeführt, denn die oben beschriebene Arbeitsweise verschwendete wertvolle Ressourcen des Computers, insbesondere dann, wenn es sich um einen Computer handelte, der über ein schnelles Rechenwerk verfügte. Idealerweise sollte die Recheneinheit des Computers nämlich während der kompletten Betriebszeit des Rechners ohne Unterbrechung rechnen. Betrieb man den Computer indes wie oben beschrieben, musste der Rechner sehr oft ziemlich lange warten und konnte nicht weitermachen. Der Hauptgrund hierfür war das Einlesen von Lochstreifen oder Lochkarten. Selbst wenn hierfür sogenannte „Schnellleser“ eingesetzt wurden, waren diese im Vergleich zur Recheneinheit eines großen Universitätsrechners langsam wie eine Schnecke. Wertvolle Prozessorzeit wurde also mit Warten auf das Einlesen des Programms verschwendet. Das gleiche Problem ergab sich beim Einlesen der Daten während der Laufzeit des Programms und auch bei der Erzeugung der Ausgaben. Hier wurden zwar in großen Organisationen Schnelldrucker eingesetzt, aber natürlich war auch so ein Schnelldrucker um ein Vielfaches langsamer als die Recheneinheit eines Großrechners.

Eine Abmilderung dieses Problems erreichte man dadurch, dass Eingaben nicht von langsamen Eingabegeräten wie Lochkartenlesern oder Lochstreifenlesern und Ausgaben entsprechend nicht auf Druckern und Stanzern gemacht wurden, sondern indem ein erheblich schnelleres Medium genutzt wurde. Das Medium der Wahl waren hier zunächst Magnetbänder, die bedeutend rascher gelesen und auch beschrieben werden konnten. Computer, die nur von Magnetbändern lasen und nur auf Magnetbänder schrieben, mussten viel weniger auf die Lese- und Schreiboperationen warten. Die Recheneinheit wurde also bedeutend besser ausgenutzt. Die oben abgebildete UNIVAC I von 1951 war ein Rechner, der ausschließlich auf Magnetbänder als Ein- und Ausgabeformat setzte. Nun ergab sich aber ein neues Problem. Wie kommen Programm und Daten auf das Band? Und wie kommen die Ergebnisdaten vom Band wieder herunter? Da die Nutzer eines solchen Computers die Bänder weder selbst beschreiben noch die auf den Bändern gespeicherten Ausgaben lesen konnten, musste eine Reihe von externen Zusatzgeräten genutzt werden. Es gab dementsprechende Einheiten zum Kopieren von Lochkartenstapeln auf Magnetband und entsprechend solche zum Ausstanzen von auf Magnetband gespeicherten Daten auf Lochkarten oder zur Ausgabe auf einen Drucker.

Stapelverarbeitung

Ein wirklicher Vorteil für die Auslastung des Rechners ergab sich durch den Einsatz der Magnetbandtechnik natürlich nur dann, wenn möglichst wenig Zeit dadurch verschwendet wurde, Bänder zu wechseln. Jeden einzelnen Job erst auf ein Magnetband zu kopieren, dieses dann in den Computer einzulegen, die Ausgaben abzuwarten, das Ausgabe-Magnetband zu entnehmen und die Ergebnisse auszudrucken oder auszustanzen, ergab keinen wirklichen Sinn, denn es entstanden dann ja nach wie vor lange Wartezeiten durch das Wechseln der Bänder. Ihren wirklichen Vorteil spielte die Magnetbandtechnik erst dann aus, wenn der Computer ohne Bandwechsel einen Job nach dem anderen abarbeiten konnte. Genau in diese Richtung wurden dann auch Optimierungen vorgenommen. Jobs wurden nicht mehr einer nach dem anderen, sondern in sogenannten „Batches“ dem Computer zugeführt.

Bei der „Batch-Verarbeitung“ oder auf deutsch auch „Stapelverarbeitung“ wurden die Job-Daten, also die Programme und Daten der Computernutzer, von Lochkarten und Lochstreifen auf ein Magnetband kopiert. Auf ein Band kam nicht nur ein einzelner Job, sondern eine Vielzahl. Eine solche Jobsammlung wurde als „Stapel“ (englisch: batch) bezeichnet. Ein Stapel wurde als Ganzes dem Computer zugeführt. Wenn der Computer etwa zwei Magnetbandlaufwerke für das Einlesen der Jobs hatte, konnten so, vorausgesetzt es gab genügend Jobs, Wartezeiten durch Bandwechsel fast vollständig vermieden werden. Der Computer im Batch-Betriebsmodus arbeitete die Programme eines nach dem anderen ab. Die Ausgaben wurden in gleicher Art und Weise wie die Job-Daten nacheinander auf ein Ausgabe-Magnetband geschrieben. Dieses wurde, wenn es voll war, dem Computer entnommen und in eine Zusatzmaschine gegeben, mit der die erzeugten Ausgaben entsprechend den Wünschen des Nutzers ausgedruckt oder ausgestanzt wurden. Alle langsamen Ein- und Ausgabeoperationen wurden so vom Hauptcomputer abgekoppelt und beanspruchten ihn nicht mehr.

Mit der Einführung der Batch-Verarbeitung dieser Art ging eine der letzten Eingriffsmöglichkeiten verloren, die es vorher durch die menschlichen Operateure noch gab. Ein menschlicher Operator konnte die Reihenfolge der Rechenaufträge leicht abändern, sie somit priorisieren und konnte sogar die Verarbeitung eines Jobs abbrechen, wenn ein wichtigerer Job hereinkam, der eine umgehende Bearbeitung verlangte. Das klappte in dieser Form nun nicht mehr, da die Programme nacheinander vom Magnetband kamen und gar kein Mensch mehr da war, der eine Entscheidung hätte treffen können. Dieser Missstand wurde natürlich erkannt und im Laufe der Zeit beseitigt. Die Rechenanlagen wurden so weiterentwickelt, dass sie die Rechenzeiten der Rechnernutzer verwalten und nach Prioritätenlisten entscheiden konnten, welches Programm wann ausgeführt werden sollte. Das Verwaltungssystem beendete automatisch die Programme, die zu lange rechneten oder andere Ressourcen über Maß in Anspruch nahmen. Es war nun sogar möglich, bei Eintreffen eines Jobs mit hoher Priorität ein gerade laufendes Programm zu unterbrechen, das wichtige Programm vorzuziehen und das unterbrochene Programm an der Stelle fortzusetzen, an der es unterbrochen wurde. Damit all dies so funktionieren konnte, brauchte es aber ein paar technische und organisatorische Voraussetzungen.

Für jedes Programm musste fortan im Voraus angegeben werden, welche Priorität es hat und wie viele Ressourcen es für sich beansprucht. Diese Informationen mussten dem Computersystem für alle anstehenden Jobs eines Batches zur Verfügung stehen, damit es einen der Jobs zur Ausführung auswählen konnte. Das klappte natürlich nicht, wenn diese Daten immer am Anfang eines Jobs auf einem Magnetband standen, das nach und nach eingelesen wurde. Entweder mussten diese Job-Informationen am Beginn des Bandes zusätzlich bereitgestellt werden oder die kompletten Job-Daten mussten vom Computer in einen Speicher kopiert werden, auf den ohne große Zeitverzögerung und ohne größeres Spulen zugegriffen werden konnte. Solche Speichersysteme mit sogenanntem wahlfreien Zugriff (meist Festplatten) kamen Mitte der 1950er Jahre auf den Markt.

Neben dieser Hardware-Voraussetzung gab es aber natürlich eine sehr wichtige Software-Voraussetzung: Statt eines Operators mussten viele Aufgaben nun von der Maschine durchgeführt werden können. Das erledigte eine Software, ein sogenanntes Monitoring System oder Operating System, zu Deutsch also ein Betriebssystem. Dieses System sorgte von nun an statt eines menschlichen Operators unter anderem für das Laden von Job-Daten und das Bereitstellen und Zuordnen von Ausgabedaten. Eine weitere wichtige Aufgabe der Betriebssysteme war (und ist immer noch) das Behandeln von Fehlern in den Programmen. Wenn ein Programm bei seiner Ausführung in eine Fehlersituation kam, durfte das den Computer nicht etwa, wie vorher noch üblich, in einen Alarmzustand versetzen und alle weiteren Operationen anhalten, denn schließlich gab es noch eine lange Warteschlange anderer Jobs, die auch abgearbeitet werden sollten. Stattdessen mussten entsprechende Ausgaben generiert und die Abarbeitung des Batches mit einem anderen Job fortgesetzt werden. Eine weitere wichtige Aufgabe der Betriebssysteme war das Verwalten von Prioritäten und Laufzeitkonten. Studentische Jobs an Universitäten bekamen zum Beispiel geringere Priorität und nur wenig Rechenzeit zugewiesen. Wurde diese Rechenzeit erreicht, wurde die Verarbeitung automatisch abgebrochen. Kam während der Verarbeitung von Jobs mit niedriger Priorität einer mit höchstem Stellenwert herein, wurde die aktuelle Verarbeitung gegebenenfalls unterbrochen und der wichtigere Job vorgezogen.

Selbst beim Einlesen von Daten von Bandlaufwerken und Festplatten gab es noch immer verschenkte Rechenzeit. Zwar ging es natürlich viel schneller als das Einlesen von einem Lochstreifen oder von Lochkarten, doch der Geschwindigkeitsunterschied zu einer schnellen Recheneinheit war immer noch vorhanden. Mehr und mehr technische Kniffe erreichten aber eine immer bessere Auslastung des Rechners. Rechenanlagen von IBM konnten zum Beispiel mehrere Programme gleichzeitig im Arbeitsspeicher halten. Dadurch konnte, während der Computer mit vergleichsweise langsamen Ein-/Ausgabe-Operationen beschäftigt war, das Betriebssystem zu einem anderen Programm wechseln und dieses weiterlaufen lassen. Diese frühe Form des Multitaskings nannte sich „Multi Programming“. Der Preis für den erhöhten Durchsatz durch diese Technik war natürlich ein System, das über viel Arbeitsspeicher verfügen musste und dementsprechend sehr teuer war.

Alle hier genannten Optimierungen durch Magnetbänder, Festplatten und Betriebssysteme spielten sich für den Nutzer eines Computers im Verborgenen ab, denn die Nutzer hatten nach wie vor mit den Vorgängen im Rechenzentrum nichts direkt zu tun und bekamen den Computer selbst überhaupt nicht zu sehen.

Der komplette Programmierprozess war nach wie vor vorgelagert und fand nur mit analogen, sprich mit mechanischen Mitteln statt. Programmiert wurde zunächst mit einem Stift auf Papier, auf sogenannten „Codierbögen“. Oben ist ein Codierbogen für eine IBM-Computeranlage abgebildet. Wenn diese Phase des Programmierens beendet war, musste der Code auf Lochkarten übertragen werden. Bei der Programmierung mit Lochkarten entsprach eine Karte in der Regel einer Programmzeile. Dazu kamen noch Datenkarten, die man entweder auf die gleiche Art und Weise erstellte oder von einem vorherigen Programm als Ausgabe erhalten hatte. Als Anweisung für das Betriebssystem gehörte zu jedem Job noch eine Job-Steuerkarte, die all dem vorangestellt wurde. Sie diente zum einen der Job-Separierung, aber auch der Spezifikation der Programmiersprache – dazu gleich mehr – sowie weiteren Ablaufdetails wie etwa der Priorität und der erlaubten maximalen Laufzeit. Diesen Satz an Lochkarten versuchte der Programmierer – tunlichst ohne ihn vorher fallen zu lassen – im Rechenzentrum abzugeben. Alles, was nun passierte, entzog sich dem Benutzer. Die Zeit von der Abgabe des Programms bis zum Erhalten des Ergebnisses, die sogenannte „Turnaround-Time“ oder „Jobverweilzeit“, konnte unter Umständen sehr lang sein. Die Universität Münster beschrieb dies eindrucksvoll im Newsletter „inforum“ des Hochschulrechenzentrums ⁹:

Jeder Auftrag zur Ausführung von Programmen (kurz: Job), der dem Rechner übergeben wird, muß vom Betriebssystem verwaltet werden. Diese Aufgabe übernimmt bei uns die Betriebssystemkomponente HASP (Houston Automatic Spooling Priority System). HASP liest die Jobs von den Kartenlesern im Rechenzentrum und an den Terminals. […] Jeder Job wird in eine der folgenden Warteschlangen nach CPU-Zeit und Speicherplatz-Bedarf einsortiert:

[…]

Der Benutzer kann Zeit- und Speicherplatzbedarf seines Jobs auf der JOB-Karte angeben. Die Job-Karte //ABC99XY JOB (ABC99,0020,Z23),A,USER,REGION=155K z.B. fordert 20 Minuten CPU-Zeit in 155 KBytes Hauptspeicher an. HASP sortiert den Job demnach in Warteschlange H ein. Die gleiche Wirkung hat CLASS=H anstatt REGION=155K.

Die durchschnittliche Zeit, die ein Job vom Einlesen bis zum Drucken entsprechend seiner Klasse und Einlesezeit in der Maschine ist (Jobverweilzeit), kann für den derzeitigen Rechnerbetrieb der nachfolgenden Tabelle entnommen werden.¹⁰

Die Ausführung des im Beispiel der Uni Münster angegebenen Jobs mit zwanzig Minuten Rechenzeit und 155 KB benötigtem Hauptspeicher dauerte im März 1977 also im Durchschnitt mehr als einen Tag. Diese lange Zeit konnte natürlich mehr oder weniger kritisch sein. Wenn man ein bereits ausgefeiltes Programm hatte, das man immer wieder verwendete und bei dem man nur die Daten anpasste, konnte man sich mit der langen Zeit bis zum Erhalten des Ergebnisses eventuell arrangieren. Gerade im Wissenschaftsbetrieb war es jedoch so, dass oft neue, recht spezielle Berechnungen anzufertigen waren. Man musste für die meisten Aufgaben also stets neue Programme schreiben. Diese Programme wurden nicht oft wiederverwendet, sondern dienten eben der Lösung genau eines Problems. Wenn es gelöst war, standen andere Aufgaben an, die andere Programme verlangten, die dann wieder explizit programmiert werden mussten.

Gerade während der Entwicklungszeit eines solchen Programms stellte die lange Turnaround-Zeit ein großes Problem dar. Das kann sich jeder leicht klarmachen, der schon mal programmiert hat. Allen anderen sei versichert: Ein Programm ist so gut wie nie auf Anhieb korrekt. Fast immer gibt es bei den ersten Versuchen der Ausführung eine Reihe von Fehlermeldungen oder man stellt fest, dass das Programm zwar syntaktisch korrekt ist, also korrekt in der Programmiersprache verfasst wurde, aber leider nicht das tut, was man sich vorgestellt hat. Es braucht also nahezu immer mehrere Korrekturschritte, bis ein Programm korrekt arbeitet. Stellen Sie sich das nun bei einer Programmierung auf Papier, bei manueller Übertragung auf Lochkarten und vor allem bei einer Antwort, die es erst Stunden später oder am nächsten Tag gibt, vor. Eine Fehlerkorrektur oder Programmieren durch schrittweises Optimieren, wie heute üblich, dauerte so Stunden bis Tage. Die einzige Abhilfe, die das Programmieren von Rechnern im Batch-Betrieb zumindest etwas komfortabler machte, war das Aufkommen sogenannter „höherer Programmiersprachen“.

Höhere Programmiersprachen

Das Nutzen eines Computers bedeutete in den 1950er, 1960er und 1970er Jahren in der Regel, dass die Nutzer zum Lösen eines Problems, also etwa zur Durchführung einer Berechnung, ein eigenes Programm schreiben mussten. Da der Computer selbst seinen Nutzern nicht zugänglich war, war die Programmiersprache, mit der ein Computer programmiert werden konnte, daher das einzige, was einer Nutzungsschnittstelle irgendwie nahekam. Bis Ende der der 1950er Jahre konnten Computer nur in Maschinencode bzw. im sehr maschinennahen Assembler-Code programmiert werden. Programmierer, die eine Aufgabe mit einem Computer lösen wollten, mussten die Architektur der Maschine dabei ziemlich genau kennen. Sie mussten zum Beispiel wissen, wie viele Register eine Maschine hatte, wie der Speicher organisiert und mit welchem Befehlssatz die Maschine zu programmieren war. Programmieren auf diese Art ist auch heute noch möglich und wird dann und wann auch durchgeführt, wenn es auf höchste Performance ankommt. Der größte Teil der Programmierung wird jedoch schon lange nicht mehr so maschinennah, sondern in sogenannten „höheren Programmiersprachen“ erledigt. Die ersten dieser Sprachen kamen Ende der 1950er Jahre auf.

Betrachten wir an einem einfachen Beispiel zunächst die maschinennahe Programmierung eines Computers: Der Prozess des Programmierens in einer maschinennahen Programmiersprache geht immer mit einer Dekontextualisierung des Problems einher. Alle Hinweise auf die Bedeutung dessen, was dort programmiert wird, gehen in diesem Prozess verloren. Eine Lösung eines Problems als Computerprogramm ist dadurch stets sehr schwer zu verstehen. Das Beispiel, das ich Ihnen hier erläutern möchte, ist ein kleines Programmfragment, das bestimmt, ob jemand „pleite ist“. In natürlicher Sprache wollen wir, leicht vereinfachend, „pleite sein“ definieren als: „Wenn jemand mehr ausgibt, als er einnimmt, dann ist er pleite“. Mathematisch formuliert könnte man das als "pleite: a > e" aufschreiben. Diese Definition sieht sehr formal aus und ist es auch. Es haben sich aber einige Hinweise auf menschenverstehbare Semantik erhalten. Die Wahl des Wortes pleite und die Wahl der Variablennamen a für Ausgaben und e für Einnahmen sind nicht Teil des mathematischen Formalismus, sondern verweisen auf die Problemdomäne. Man könnte auch ganz andere Bezeichner wählen, ohne an der formalen Spezifikation etwas zu ändern. Die Verstehbarkeit durch den Menschen würde aber leiden, wenn wir diese Hinweise auf die Bedeutung wegließen. Leider müssen wir genau das tun, wenn wir das Problem als Maschinenprogramm aufschreiben. Es entsteht dann ein Programm wie das folgende¹¹:

0: LOAD 2 
1: SUB 1 
2: JGTZ 5 
3: LOAD=1
4: JUMP 6
5: LOAD=0
6: STORE 3
7: HALT

Das zu lösende „Problem“ wurde bei der Übertragung in das Computerprogramm in eine Reihe von Anweisungen heruntergebrochen, die Zeile für Zeile aufgeschrieben wurden. Die Werte für Einnahmen und Ausgaben werden in zwei Registern der Maschine erwartet. Ein Register kann man sich als Speicherstelle für genau einen Wert vorstellen. Der Wert für die Ausgaben ist in Register 1, der für die Einnahmen in Register 2 als Zahl gespeichert. Register 3 enthält am Ende dieses Mini-Programms eine 1 im Falle einer Pleite. Andernfalls wird dort eine 0 gespeichert. Unsere Maschine, für die hier programmiert wird, verfügt eine besondere Speicherstelle, die „Akkumulator“ genannt wird. Alle Rechenoperationen der Maschine werden auf diesen Akkumulator angewandt. Das Programm startet in Zeile 0 und läuft dann folgendermaßen ab:

• In Zeile 0 wird der Wert des Registers 2 in den Akkumulator geladen. „Laden“ bedeutet dabei nichts anderes, als dass der Wert dorthin kopiert wird. Der Wert im Akkumulator ist nun der gleiche wie der in Register 2, also der Wert der Einnahmen.
• In Zeile 1 wird der Wert aus Register 1 – die Ausgaben – vom Wert im Akkumulator abgezogen. Im Akkumulator befindet sich dann das Resultat dieser Rechnung, der Wert der Einnahmen abzüglich des Wertes der Ausgaben.
• Zeile 2 ist ein bedingter Sprung. Der Wert im Akkumulator wird darauf überprüft, ob er größer als 0 ist (JGTZ für Jump if Greater Than Zero). Wenn dies der Fall ist, wird in Zeile 5 fortgefahren.
• Nehmen wir an, dass der Wert im Akkumulator kleiner ist als 0, die Person also pleite ist. In diesem Fall trifft die Bedingung nicht zu. Der Sprung wird also nicht ausgeführt, sondern es wird in Zeile 3 fortgefahren. In dieser Zeile wird der Wert 1 in den Akkumulator geschrieben.
• Zeile 4 ist wieder ein Sprungbefehl, in diesem Fall jedoch ein Sprung ohne Bedingung. Es geht also in Zeile 6 weiter.
• Wenn die Überprüfung in Zeile 2 anders abgelaufen wäre, wäre das Programm nicht in Zeile 3, sondern in Zeile 5 weitergegangen. Auch hier wäre ein Wert in den Akkumulator geladen worden, allerdings wäre es hier eine 0 gewesen.
• In Zeile 6 wird der Wert aus dem Akkumulator, also eine 1 oder eine 0, im Register 3 gespeichert.
• In Zeile 7 endet das Programm.

Sicher haben Sie es gemerkt: Um dieses Programm überhaupt schreiben zu können, muss man sehr viel über die Architektur des Rechners wissen. Man muss etwa wissen, was Register sind und dass der Rechner über einen Akkumulator verfügt. Auch die Befehle müssen bekannt sein. Man muss sich darüber hinaus vieles merken, etwa, welcher Wert in welchem Register gespeichert ist. Vor allem muss man es hinbekommen, zu programmieren, ohne dass es Hinweise auf eine menschenverstehbare Semantik gibt. In der Praxis konnte man sich mit Kommentaren behelfen, die man zusätzlich zu den Programmbefehlen notierte. Dies änderte aber nichts daran, dass das Programm selbst komplett ohne Hinweise auf die Bedeutung auskommen musste.

Bei der Programmierung stehen sich unterschiedliche Arbeitsweisen scheinbar unversöhnlich gegenüber. In der Sphäre des Nutzers spielt die Bedeutung dessen, was gelöst werden soll, eine große Rolle. Es ist wichtig, wofür die Zahlen stehen, mit denen gerechnet wird, und was das Ergebnis bedeutet. Die Arbeitsweise des Computers hingegen ist völlig frei von Bedeutungen und basiert rein auf der Form und der Anordnung von Zeichen. Diese Zeichen steuern den Computer, der dann entsprechend addiert, vergleicht, lädt oder im Programm an eine andere Stelle springt. Der Computer tut dies völlig unabhängig davon, was das Programm für den Menschen bedeutet, der es verwendet. Höhere Programmiersprachen versuchen, genau diesen Gegensatz zu überbrücken. Zum einen abstrahieren sie von der internen Struktur der Maschine, was den Programmierer schon mal von der Notwendigkeit der Kenntnis allzu spezifischer technischer Details entbindet, die ja nichts mit dem von ihm zu lösenden Problem, sondern ausschließlich mit dem Gerät zu tun haben. Das ist bereits eine große Hilfe. Es sind aber vielleicht die sprachlichen Aspekte der Programmiersprachen, die noch wichtiger für eine gute Programmierbarkeit sind.

Höhere Programmiersprachen erfüllen nämlich zwei Rollen gleichzeitig: Es handelt sich zum einen um Sprachen, die im Gegensatz zu natürlichen Sprachen vollständig formal spezifiziert sind. Nur deshalb können sie zur Steuerung der Operationen eines Computers verwendet werden. Trotzdem bieten sie aber Grundstrukturen natürlicher Sprache, sodass ein „Text“ entsteht, der auch für den Menschen einigermaßen verständlich ist. Diese Natürlichsprachlichkeit fängt bei den Schlüsselworten und Konstrukten der Sprache selbst an. Statt wirre Sprünge an Programmzeilen gibt es etwa Konstrukte wie if, then, else und eine an die Mathematik angelegte Funktionssemantik mit Übergabeparametern und Rückgabewerten. Eine extreme Erleichterung bei der Programmierung bringt darüber hinaus vor allem die Möglichkeit, Programmkonstrukte mit eigenen Namen versehen zu können. Für die automatische Verarbeitung eines Programms durch einen Computer ist der Name einer Variablen (eines gespeicherten Wertes) oder eines Unterprogramms irrelevant. Dem Programmierer hilft sie jedoch, die inhaltliche Bedeutung dessen, was ein Programmkonstrukt tut, verstehen zu können. Es macht für das Verständnis einen beträchtlichen Unterschied, ob man sich auf so etwas abstraktes wie „Register 2“ oder „x“ beziehen muss, oder ob im Programm das verstehbare Wort ausgaben auftaucht.

Die ersten höheren Programmiersprachen mit diesen Eigenschaften kamen Ende der 1950er Jahre auf und fanden in den 1960ern zunehmend Einsatz. Die neuen Sprachen verfügten über unterschiedliche Charakteristika je nach ihrem intendierten Einsatzgebiet; von Fortran (Formula Translation) und Algol (Algorithmic Language) für wissenschaftliche Berechnungen bis hin zu COBOL (Common Business Oriented Language) für Business-Datenverarbeitung. Das oben maschinennah erläuterte Programm stellte sich in COBOL und Fortran wie folgt dar:

COBOL:

IF ausgaben GREATER einnahmen 
    MOVE 1 TO pleite 
ELSE 
    MOVE 0 TO pleite 
.

Fortran 66¹²:

 IF (ausgaben > einnahmen) THEN
   pleite = 1
 ELSE
   pleite = 0
 END IF

Programme in einer höheren Programmiersprache können von einem Computer nicht direkt ausgeführt werden. Spezielle Programme, „Compiler“ genannt, übersetzen zunächst den Programmcode in den systemeigenen Maschinencode, der dann ausführbar ist. Aus diesem Grund mussten Programmierer bei der Benutzung eines Computers im Batch-Betrieb die genutzte Programmiersprache auf der Job-Control-Karte ihrer Jobs angeben. Das Betriebssystem führte dann automatisch erst den entsprechenden Compiler und dann das von diesem erzeugte Programm in Maschinensprache aus.

Programmiersprachen werden üblicherweise nicht in den Zusammenhang mit Nutzungsschnittstellen gebracht. Gerade im Kontext heutiger Systeme ist das sicher auch richtig so, denn kaum ein Nutzer muss seinen Computer heute selbst programmieren, und wenn es doch passieren sollte, sieht man das als etwas anderes als die Nutzung des Geräts an. Es wird relativ klar zwischen Nutzung und Programmierung unterschieden. Zur damaligen Zeit jedoch, in der ein Computernutzer stets gleichzeitig ein Computerprogrammierer war, war die Beschaffenheit einer Programmiersprache von essenzieller Bedeutung dafür, wie effizient der Computer genutzt werden konnte. Die Charakteristiken der höheren Programmiersprachen nahmen dabei etwas vorweg, was wir im weiteren Verlauf der Nutzungsschnittstellen-Entwicklung weiter beobachten werden. Sie ermöglichten dem Nutzer des Computers eine Denkweise, die sich von der technischen Realität der Maschine stark unterscheidet. Nutzer haben es in der höheren Programmiersprache mit namentlich ansprechbaren Variablen und Funktionen statt mit Registern und Sprungbefehlen zu tun. Die Strukturen im Rechner bleiben ihnen verborgen. Dieses Schaffen einer Nutzungswelt durch das Computersystem, die ganz andere Eigenschaften als die technische Struktur hat, ist eine Grundeigenschaft interaktiver Nutzungsschnittstellen, auf die ich später intensiv zu sprechen komme. Zunächst will ich Ihnen aber erläutern, dass die hier beschriebene Batch-Nutzung mit ihrer großen Distanz zwischen Mensch und Maschine keineswegs alternativlos war.

Frühe Echtzeitsysteme

Im vorherigen Kapitel haben Sie erfahren, wie Computer im Batch-Betrieb funktionieren. Dabei wurden Probleme offenbar, die durch die sehr langen Wartezeiten zwischen Programmabgabe und Aushändigung des Ergebnisses und durch die Notwendigkeit entstanden, ohne Computerkontakt auf Papier mit Lochkarten und Lochstreifen programmieren zu müssen. Wenn eine Geschichte des Computers erzählt wird, wird es oft so dargestellt, als sei der Batch-Betrieb regelrecht alternativlos gewesen und eine direktere Computernutzung erst relativ spät, irgendwann in den 1970ern, erfunden worden. Das ist in dieser Absolutheit so allerdings nicht wahr. Zwar war der Batch-Betrieb sicher dominant, doch hat man schon damals Computer im sogenannten „Echtzeitbetrieb“ betreiben können. Verbreitet war seinerzeit auch der Begriff „On-Line-Betrieb“ oder „Dialogbetrieb“.

Gerade in Universitäten und Forschungsinstituten dominierten ziemlich lange Rechenanlagen, die im Batch-Betrieb arbeiteten. Diese Art der Computernutzung war hier vor allem deshalb so verbreitet, weil es eine sehr große Zahl an Nutzern gab, die Computerdienste nutzen wollten. Aufgrund der Anforderungen an wissenschaftliche Berechnungen kam zudem nur ein gut ausgestatteter Computer infrage, der über viel Speicher verfügte und der schnell rechnen konnte. Da solche Computer Großanschaffungen und damit teuer waren, musste ein einzelner Rechner ausreichen, um eine große Menge Aufträge von einer Vielzahl von Nutzern abzuarbeiten. Der Batch-Betrieb war hier, trotz der beschriebenen Nachteile, am besten geeignet. Es gab allerdings auch damals bereits Nutzungsszenarien, in denen hohe Rechenleistung nicht das Wichtigste war, in denen es nur wenige Nutzer gab, die einen Computer nutzen wollten, oder in denen eine nur kleine Anzahl von selten geänderten Programmen genutzt wurden. Für diese Einsatzbereiche standen schon früh, man könnte fast sagen von Anfang an, Rechner zur Verfügung, die im Echtzeitbetrieb verwendet wurden. Schauen wir uns im Folgenden einige solcher Systeme mit ganz verschiedenen Charakteristiken an.

Flurbereinigung: Zuse Z11

Schon im ersten Kapitel haben Sie etwas über die Rechner von Konrad Zuse erfahren. Der Fokus lag dabei auf der Z4. Wir schauen uns nun einen etwas späteren Rechner, die Z11, an. Diese Z11 war der erste Computer der Zuse KG, der in Serie gefertigt wurde. Die Idee hinter der Computerentwicklung von Konrad Zuse war, wie bereits erläutert, seine Erfahrung, dass Ingenieure immer wieder gleiche Berechnungen mit verschiedenen Werten durchführen müssen. Aus diesem Gedanken folgt ziemlich direkt, dass Zuse keine Maschinen im Sinn hatte, die laufend mit neuen Programmen bestückt wurden. Er ging eher davon aus, dass es einige wenige „Rechenpläne“ gab, die immer wieder für neue Berechnungen mit anderen Startwerten genutzt, selbst aber eher selten geändert werden.

Hier abgebildet sehen Sie einen Teil der Bedienkonsole der Z11. Zentral ist eine Tastatur für Dezimalzahlen. Diese Tastatur wurde vom Ingenieur genutzt, um die Werte seiner Berechnung einzugeben. Danach wurde mittels eines Knopfes an der Konsole die Berechnung gestartet. Auf einer angeschlossenen elektrischen Schreibmaschine wurden die Ergebnisse der Berechnung ausgegeben. Ein typisches Einsatzszenario für die Z11 war die Flurbereinigung¹³. Um diese durchzuführen, bedurfte es einer Reihe von Berechnungen, die immer wieder für verschiedene Fälle durchgeführt werden mussten. Für die Aufgaben der Flurbereinigung wurde also nur eine kleine Zahl von Programmen gebraucht, die sehr häufig verwendet wurden. Da die Programme für den Einsatzzweck so typisch waren und es so wenig Variation bedurfte, waren die wichtigsten von ihnen sogar fest eingebaut, mussten also gar nicht mehr von Lochstreifen eingelesen werden. Der Lochstreifen erlaubte aber natürlich weitergehende Berechnungen und den Einsatz des Rechners in anderen Einsatzfeldern.

Die Z11 war gerade für die Angestellten in den Vermessungsämtern ein sehr angenehmer Rechner, da er den Nutzern wenig Wissen über Computertechnik abverlangte und zudem schnell Ergebnisse lieferte. Die Programme konnten an der Bedienkonsole per Knopfdruck gestartet werden. Dann mussten nur noch die Zahlen auf festgelegte Art und Weise „eingetastet“ werden und schon startete die Berechnung. Direkt nach dem Erhalt der Ergebnisse stand die Maschine für die nächste Berechnung wieder zur Verfügung. Es gab bei dieser Nutzungsweise keine Notwendigkeit, sich mit Computerinterna wie Zahlencodierung, Registern oder Sprungbefehlen zu belasten.

Die Zuse Z11 war, auch schon für die damalige Zeit Mitte der 1950er Jahre, ein ziemlich langsamer Rechner. Sie arbeitete, genau wie die Z3 und die Z4, mit Telefonrelais und verfügte ebenso wie diese nicht über ein Stored Program im Sinne eines Programms, in dem beliebige Stellen im Programm angesprungen werden können. In Szenarien wie der Flurbereinigung war das allerdings nicht schlimm. Die Geschwindigkeit war bei diesem Rechner nicht das entscheidende Kriterium. Es war weder das Ziel, den Rechner dauerhaft laufen zu lassen noch die Rechengeschwindigkeit und den Durchsatz zu optimieren. Der Vorteil des Rechners bestand vielmehr darin, für die Anwender jederzeit zur Verfügung zu stehen. Obwohl der Rechner als solcher langsam war, lieferte er den Nutzern doch viel schneller Ergebnisse, als wenn diese einen schnellen Computer im Batch-Betrieb hätten nutzen und dann auf die Ergebnisse immer lange warten müssen.

Buchhaltung: IBM 305 RAMAC und IBM 1401

Weitere typische Bereiche, bei denen die Anforderung an schnelles Einlesen vieler verschiedener Programme und das Befriedigen vielseitiger Bedürfnisse unterschiedlicher Nutzer nicht im Vordergrund standen, waren Buchhaltung, Lagerhaltung und vergleichbare Verwaltungsvorgänge. Solche Vorgänge sind dadurch gekennzeichnet, dass es große Datenmengen gibt, die verarbeitet werden müssen. Jedes Ein- und Auslagern in einem Hochregal etwa ist ein eigenes Datum und entsprach damals daher im Prinzip einer eigenen Lochkarte, die verarbeitet werden musste. In diesem Einsatzkontext ist es auch heute noch so, dass sich die Anzahl verschiedener Programme in Grenzen hält, und die bestehenden Programme sehr stabil sind, was heißt, dass sie nur sehr selten geändert werden müssen. Schon vor dem Beginn des Computerzeitalters im engeren Sinne wurden für Verwaltungszwecke dieser Art Maschinen benutzt, die Lochkarten verarbeiteten. Die Firma IBM bot zum Beispiel Geräte an, die auf Lochkarten gespeicherte Daten verrechnen oder als Tabelle ausgeben konnten. In der Tradition dieser Lochkarten-Verarbeitungs-Systeme standen dann auch die auf diesen Bereich der Datenverarbeitung optimierten Computer von IBM, von denen wir uns hier zwei anschauen wollen:

IBM 305 RAMAC

1956 brachte IBM das System IBM 305 RAMAC auf den Markt. Die Abkürzung RAMAC steht für Random Access Method of Accounting and Control. „Random Access“ bedeutet, dass auf die gespeicherten Daten wahlfrei zugegriffen werden kann, ohne dass Lochkartenstapel durchlaufen werden müssten oder auf Bändern sequenziell nach den Daten gesucht werden müsste. Für diesen wahlfreien Zugriff wurde von der Firma IBM eigens ein neuer Datenspeicher, die Festplatte, entwickelt. Sie sehen diese Festplatte auf dem Bild als Stapel von Magnetscheiben hinter der Dame schräg links unter dem Schriftzug „RAMAC“. Die Zielgruppe der 305 RAMAC waren nicht Wissenschaftler oder andere Nutzer mit komplexem Rechenbedarf, sondern die Unternehmen, die bisher Lochkartenverarbeitungsmaschinen und Drucker von IBM zum Sortieren, Tabellieren und Akkumulieren von Daten genutzt hatten.

Nutzer der IBM 305 RAMAC konnten, ganz ähnlich wie bei der Zuse Z11, über ein Programmwahlrad ein Programm auswählen und laufen lassen. Das Programm war entweder per Kabelverbindungen fest im Rechner verdrahtet oder befand sich auf dem Trommelspeicher der Maschine. So ein Trommelspeicher war vom Prinzip her einer Festplatte nicht unähnlich. Es handelte sich um eine schnell rotierende Walze, die mit einer magnetisierbaren Schicht versehen wurde. Mehrere fest eingebaute Schreib-Lese-Köpfe waren über die Länge der Trommel verteilt. Sie befinden sich auf der Abbildung hinter den gut sichtbaren Anschlusskabeln, die nach vorne herausgeführt sind. Die gespeicherten Daten rotierten unter den Schreib-Lese-Köpfen hinweg. Der Speicherplatz auf einer solchen Trommel war relativ beschränkt. Der Trommelspeicher der RAMAC konnte auf 32 Spuren insgesamt 3200 Zeichen abspeichern. Die Magnettrommel bildete den Programm- und Arbeitsspeicher des Rechners. Ein großer Vorteil dieser Technologie verglichen mit heutigen Speicher-Modulen war ihre Persistenz. Moderne RAM-Module verlieren ihren Speicherinhalt, sobald sie nicht mehr mit Strom versorgt werden. Wurde ein Rechner mit Magnettrommelspeicher ausgeschaltet, blieben die Speicherinhalte hingegen erhalten. Bei der nächsten Verwendung des Geräts konnten die vorher geladenen Programme also direkt wieder gestartet und mussten nicht neu eingelesen werden. Auch alle auf der Trommel gespeicherten Variablen und Konfigurationen blieben erhalten.

Die Programme der RAMAC verarbeiteten Eingabedaten in Form von Lochkarten, hatten aber auch Zugriff auf die Daten der Festplatte und die des Magnettrommelspeichers. Ausgaben konnten auf einem Drucker, mittels eines Lochkartenstanzers oder auf einer Konsolen-Schreibmaschine getätigt werden, die eigentlich nichts anderes war als eine elektrische Schreibmaschine mit Computeranschluss. Im Gegensatz zu den Großcomputern von Universitäten verarbeitete ein RAMAC-System nicht dauerhaft Daten. Der Clou des Systems war vielmehr, Daten in Form von Lochkarten direkt dann zu verarbeiten, wenn sie eintrafen, statt dies in einem großen Programmlauf nur einmal am Tag zu erledigen. Der aktuelle Gesamtstand der Daten befand sich persistent, also dauerhaft zugreifbar, auf dem Plattenstapel. Sollten beispielsweise aktuelle Informationen über den Lagerbestand bezogen werden, konnte das entsprechende Programm ausgewählt oder gegebenenfalls per Lochkarte eingelesen werden. Das Programm erzeugte dann den Bericht anhand der Daten auf dem Plattenstapel, ohne dass es nötig war, hierfür nochmals große Mengen Eingabedaten per Lochkarte bereitstellen zu müssen. Daten-Lochkarten waren somit nicht mehr die Grundlage aller Datenverarbeitung, sondern dienten nur noch der Erfassung von Änderungen am Datenstand, der auf der Festplatte gespeichert und damit dauerhaft im Zugriff war.

Die Verbesserungen in der Datenhaltung sind durchaus interessant und sicher auch ein Fortschritt in der Computertechnik, aber für sich genommen nicht der Grund, aus dem ich mich an dieser Stelle damit beschäftige. Das Spannende an diesem Computersystem ist, zumindest aus meiner Perspektive, die Konsole (im deutschen IBM-Sprech „das Konsol“ genannt) bestehend aus einer Tastatur und gegebenenfalls zusätzlich einer angeschlossenen Schreibmaschine. Auf dem Bild oben sitzt die Dame an dieser Konsole. Die Konsole erlaubte eine gewisse Form von Interaktivität. Zwar gab es keine interaktiven Programme, bei denen Nutzer Eingaben machen und so den Programmablauf steuern konnten – Programme liefen ganz klassisch ohne menschliche Interventionen ab. Was aber möglich war, war das Auslesen und Manipulieren von auf dem Trommelspeicher gespeicherten Daten. Diese Funktionalität war vor allem zur Fehlersuche und für Korrekturen von Interesse. Noch interessanter war die Funktion, sich auch Datensätze von der Festplatte abrufen und direkt ausgeben lassen zu können. Diese Ausgabe war allerdings noch unabhängig von einer programmierten Nutzungsschnittstelle und musste daher sehr maschinennah erfolgen. Dem Nutzer musste der physikalische Ort der gespeicherten Daten auf der Platte bekannt sein. Durch Angabe dieses Ortes konnten die Daten dann auf die Konsolenschreibmaschine ausgegeben werden.

Die 305 RAMAC war kein besonders rechenstarker Computer. Komplexe Berechnungen wären mit dem Rechner sicher möglich gewesen, wären aber recht langsam abgelaufen. Auch die Nutzung einer Magnettrommel als Arbeitsspeicher war ziemlich langsam. Das machte aber nichts, denn Geschwindigkeit und Rechenleistung standen auch bei dieser Maschine nicht im Fokus. Typische Buchhaltungs- und Verwaltungsprogramme führten keine komplexen Berechnungen durch, und da der Rechner nicht unter Vollauslastung betrieben wurde, war die Arbeitsgeschwindigkeit kein limitierender Faktor.

IBM 1401

Der IBM-Rechner 1401 erschien nur drei Jahre nach der 305 RAMAC. Die 1959 eingeführte 1400er-Serie von IBM konnte in einer Vielzahl von Konfigurationen bestellt und verwendet werden. Sie konnte zum Beispiel, ganz klassisch, im Batch-Betrieb genutzt werden. In vielen Universitäten wurden 1401-Rechner dafür verwendet, die Magnetbänder größerer Rechenanlagen vorzubereiten und auszulesen, also Daten von Lochkarten auf die Bänder zu kopieren und vorhandene Daten von den Bändern auszustanzen und auszudrucken. Neben diesen Betriebsmöglichkeiten ließen die Rechner aber auch eine Arbeitsweise ähnlich der 305 RAMAC zu, gingen aber an entscheidender Stelle noch darüber hinaus. Über eine spezielle Konsole erlaubten die Rechner der 1400er Serie nämlich die Eingabe von Daten, die dann vom laufenden Programm verarbeitet werden. Die Bedienungsanleitung der IBM 1401¹⁴ beschreibt das Arbeiten mit der Konsole (mit der internen Bezeichnung 1407) wie folgt:

When an inquiry is to be made, the operator presses the request enter key-light. As soon as the system is free to act on the request, the enter light comes ON and the operator can type the message and enter it into 1401 core storage.

When the system completes the processing of the inquiry, it is transferred to the inquiry station by the stored program. The message is typed, and the operator may act on the reply.

Auch der Vorteil dieser Arbeitsweise wird herausgestellt:

An account record or stock-status record needed by management can be requested by the operator and made available in a short time. Thus, management can, at a moment’s notice, request information from the 1401 system and have an answer almost instantaneously.

Um bei der 1401 Daten abzurufen, bedurfte es nicht mehr der Angabe von physikalischen Speicheradressen. Der Rechner erlaubte es vielmehr in einem speziellen Modus, „messages“, also Nachrichten, einzugeben. Bei den Nachrichten, wir würden heute vielleicht eher „Befehl“ oder „Kommando“ sagen, konnte es sich um alles Mögliche handeln. Gehen wir von einer Lagerhaltung aus, lagen zum Beispiel Nachrichten zum Anfragen von Lagerbeständen oder Änderungen der Bestandsdaten nahe. Die IBM 1401 ermöglichte also eine Art Kommandomodus und damit eine ziemlich interaktive Arbeitsweise. Es handelte sich allerdings noch nicht um einen interaktiven Programmablauf, wie wir ihn uns heute vorstellen. Ein Programm forderte nicht etwa den Nutzer zu einer Eingabe auf. Stattdessen hatte der Nutzer die Möglichkeit, das laufende Programm zu unterbrechen, um einen „request“ zu stellen. Diese Eingabe wurde in einen festen Bereich des Speichers des Rechners geschrieben, von wo aus das Programm sie auslesen und verarbeiten konnte. Das mag uns heute von der Nutzung und Programmierung her etwas umständlich erscheinen, doch erfüllte das System so bereits das wichtigste Potenzial interaktiver Schnittstellen, nämlich die Responsivität, ermöglichte also eine umgehende Reaktion auf eine Nutzeranfrage. In der Anleitung wird das deutlich. Eine Anfrage kann „at a moment’s notice“ getätigt werden, die Antwort kommt „almost instantaneously“.

Flugbuchung: SABRE

Ein weiteres wichtiges Beispiel für frühe Echtzeit-Anwendungen ist das SABRE-System (Semi-automated Business Research Environment) von American Airlines. Besonders interessant ist an diesem System die US-weite Vernetzung von Eingabeterminals mit einem zentralen Computer. Prototypisch ab 1961 und im vollen Einsatz ab 1964 verwaltete dieses System alle Buchungen der Fluggesellschaft American Airlines. Wenn ein Kunde der Airline telefonisch einen Flug buchte oder in eine der Service-Stellen der Fluglinie kam, konnten Kundendienstmitarbeiter über spezielle Terminals Kontakt mit einem Zentralcomputer aufnehmen, der die Anfragen in Echtzeit annahm und verarbeitete. Es gab über tausend dieser im ganzen Land verteilten Terminal-Stationen. Die Terminals waren mit dem zentralen Computer per Telefonleitung verbunden. Sie konnten genutzt werden, um direkt einen Flug zu buchen. Das System gab dem Service-Mitarbeiter der Airline ohne nennenswerte Verzögerungen Informationen über verfügbare Plätze und verarbeitete die Fluggastdaten des Kunden. Noch fehlende Informationen zu einer Buchung wurden vom System umgehend moniert. Die Terminals konnten auch genutzt werden, um vorhandene Buchungen zu ändern oder zu stornieren. Über den Namen des Kunden und die Angabe des gebuchten Fluges konnte eine frühere Buchung wiedergefunden und dann abgeändert werden. Da es sich um ein vernetztes System handelte, wo alle Terminals Zugriff auf den gleichen Datenbestand hatten, musste eine Änderung nicht am gleichen Terminal erfolgen, sondern konnte zum Beispiel auch in einer ganz anderen Stadt durchgeführt werden, etwa wenn ein Reisender am Zielort den Rückflug umbuchen wollte.

Die Abbildung oben zeigt ein Terminal, mittels dessen Servicemitarbeiter die Flugbuchungen durchführen konnten. Zentrales Element war eine elektrische Schreibmaschine. Links neben der Maschine befand sich eine Einlassung im Tisch für sogenannte „Air Information Cards“. Diese Karten enthielten sowohl lesbare Informationen für den Service-Mitarbeiter, als auch maschinenlesbare Lochungen, sodass das Terminal eine Karte identifizieren konnte. Die Karten wurden in einen Halter oberhalb der Schreibmaschine eingelegt. Mit Knöpfen links und oben konnten Felder (Zeilen und Spalten) auf der Karte ausgewählt werden. Rechts neben der Schreibmaschine befand sich neben einer Wählscheibe für Telefonanrufe der sogenannte „Director“. Hiermit konnten Befehle für Buchung, Stornierung und für die Angabe von Sitzwünschen etc. direkt ausgeführt werden. Die Schreibmaschine selbst diente zur Ausgabe von Nachrichten des Zentralrechners und zur Eingabe von textuellen Daten wie Namen, Adressen und Telefonnummern.

Auch das SABRE-Szenario hat eine ganz andere Charakteristik als der universitäre und wissenschaftliche Computereinsatz, ist aber auch anders als das Buchhaltungsszenario. Bei SABRE arbeiten alle Nutzer mit dem gleichen Programm, dem Flugbuchungsprogramm. Das Programm ist ihnen fest vorgegeben. Sie müssen es nicht erst programmieren oder laden und können es auch nicht verändern. Das Programm wird eher selten, und wenn, dann von anderen Personen als den Kundendienstmitarbeitern, verändert. Ganz anders war es im wissenschaftlichen Bereich: Jeder Nutzer kam hier mit einem eigenen Programm daher, das ganz verschieden geartete Daten verarbeiten sollte. Auch handelte es sich bei SABRE um kein System, das hohe Rechenleistung brauchte, denn bei einer Flugbuchung wurde kaum nennenswert etwas berechnet, was über das Zählen freier Plätze hinausgegangen wäre.

Wissenschaft und Technik: LGP-30

Auch in den Bereichen Wissenschaft und Technik konnte es natürlich sehr von Vorteil sein, einen Computer vor Ort zu haben und ihn ohne Wartezeiten und ohne den administrativen Aufwand eines Großrechners mit Batch-Verarbeitung betreiben zu können. Die Vorteile konnten Abstriche in der Rechengeschwindigkeit durchaus aufwiegen.

Rechner, die dieser Charakteristik entsprachen, waren der LGP-30 der Firma Librascope von 1956 und sein Nachfolger LGP-21 von Mitte der 1960er Jahre. In Deutschland wurden die Maschinen in Lizenz von der Firma Schoppe & Faeser gebaut. Der oben abgebildete, funktionstüchtige Rechner steht im Computermuseum der Informatik der Universität Stuttgart. Der eigentliche Rechner ist der rechte der beiden Kästen. Er ist für die damaligen Verhältnisse relativ kompakt, hat etwa das Volumen einer kleineren Kühltruhe.

Wie bei der IBM 305 RAMAC handelte es sich beim LGP-30 um einen Rechner mit Trommelspeicher, der bei diesem Rechner das zentrale Element war, da es keine anderen Massenspeicher gab. Da die Trommel magnetisch war, blieb der Speicherinhalt nach dem Ausschalten erhalten. Wenn man also ein Programm einmal auf die Trommel geladen hatte, musste man es nach dem Ausschalten nicht neu laden. Es konnte nach dem Wiedereinschalten des Rechners gleich wieder ausgeführt werden. Die Trommel konnte 4.096 Wörter à 31 Bit speichern. Wenn Ihnen der Begriff „Wort“ in diesem Zusammenhang nichts sagt, macht das nichts. Ich möchte an dieser Stelle nicht allzu sehr in die technischen Details einsteigen, gebe Ihnen hier daher einen groben Überschlag, der Ihnen einen Eindruck vermitteln soll: Würden Sie die Trommel komplett mit Textzeichen vollschreiben wollen und pro Textzeichen sechs Bit veranschlagen, würden etwa 20.500 bis 21.000 Zeichen Platz finden. Das sind etwa zwölf DIN-A4-Seiten. Sie können es sich also ungefähr so vorstellen, als hätten Sie einen Computer mit einem Arbeitsspeicher von zwanzig Kilobyte – nicht Gigabyte, nicht Megabyte, sondern Kilobyte – und diese zwanzig Kilobyte Arbeitsspeicher sind gleichzeitig auch die Festplatte Ihres Rechners.

Zentrales Ein- und Ausgabegerät des LGP-30 war eine umgebaute Schreibmaschine vom Typ Friden Flexowriter, ihrerseits eine umgebaute IBM-Schreibmaschine, die um einen Lochstreifenleser und -stanzer erweitert wurde. Die wichtigste Erweiterung dieser Maschine war eine Schnittstelle, die eingegebene oder vom Lochstreifenleser gelesene Zeichen an den Computer weitergab und von dort kommende Zeichen so ausgab, als wären sie an der Maschine direkt eingegeben worden. Hinzu kamen Kontrolltasten, mittels derer der Computer in Gang gesetzt und mit denen zwischen manueller Eingabe und Eingabe vom Lochstreifen umgeschaltet werden konnte. Eine Lampe in der Mitte der Maschine oberhalb der Tastatur diente der Anzeige, dass der Computer eine Eingabe vom Nutzer erwartete. Schlussendlich wurden einige Tasten der Maschine durch helle Tasten ausgetauscht. Diese hellen Tasten entsprechen den Befehlen des Maschinencodes und sind hier optisch abgesetzt worden.

Mittels Eingaben von der Schreibmaschine konnten Werte direkt in den Speicher des Computers geschrieben werden. Auf diese Weise war es möglich, den Rechner direkt zu programmieren oder zumindest ein bereits auf der Magnettrommel vorhandenes Programm zu starten. Hierzu musste ein Sprungbefehl zur Startadresse des entsprechenden Programms eingegeben, dieser Befehl ausgeführt und der Rechner dann auf automatischen Betrieb umgeschaltet werden. Neue Programme konnten per Handeingabe oder per Lochstreifen auf die Trommel gebracht werden. Ein einfaches Betriebssystem verfügte über Routinen, mit denen das Laden von Programmen auf die Trommel und auch das Ausführen von Programmen ab einer angegebenen Speicheradresse relativ einfach möglich war. Mittels eines Compilers für die einfache Hochsprache ACT-III ließen sich komplexere Programme entwickeln, ohne auf die Maschinensprache des Rechners zurückgreifen zu müssen.

Interessant in Bezug auf die Nutzungsschnittstelle war die Einstellung „Eingabe von Hand“ an der Konsolen-Schreibmaschine. War diese Taste gedrückt, las der Computer Eingaben nicht vom Lochstreifenleser, sondern direkt von der Tastatur der Schreibmaschine. Der Computer ermöglichte hierdurch Programme, die während ihrer Ausführung die Eingabe von Werten über die Tastatur verlangten und damit auch die Steuerung des Fortgangs des Programms durch Nutzereingaben ermöglichten. Der Computer ließ sich also in einem ganz modernen Sinne interaktiv nutzen. Selbst einfache Spiele waren so möglich. Noch nicht umgesetzt war der Betrieb eines interaktiven Editors, also eines Programms, das es ermöglicht hätte, den Quellcode eines Hochsprachenprogramms im Speicher zu halten und direkt am Computer zu bearbeiten. Obwohl dies grundsätzlich mit dem Rechner hätte gehen müssen, hat wohl vor allem der geringe Speicher des Rechners einen praktischen Einsatz unmöglich gemacht, denn es hätte auf der Trommel dann ja Platz für den Editor, den zu bearbeiteten Programmcode, den Compiler und das Kompilat in Maschinensprache geben müssen, von eventuellen Daten des Programms ganz zu schweigen. Programmiert wurde also auch bei diesem Computer daher in der schon etliche Male beschriebenen Art und Weise, also zunächst mit dem Stift auf einem Codierbogen und dann durch Ablochen auf Lochstreifen. Da es sich um einen Rechner handelte, der lokal genutzt wurde und nicht im Batch-Betrieb arbeitete, war es aber immerhin möglich, die Programme oft abzuändern und dann immer wieder auszuprobieren. Im Batch-Betrieb hätte das mehrere Tage gedauert.

Der LGP-30 war ein Rechner mit relativ geringer Rechen- und Speichergeschwindigkeit und nur geringer Speichergröße. Er war dafür relativ günstig. 1956 kostete er 47.000 Dollar, was inflationsbereinigt heute fast einer halben Million Dollar entspricht. Natürlich ist das viel Geld. Ein typischer Computer der Zeit, wie etwa die UNIVAC I, die von 1951 bis 1954 gebaut wurde, kostete jedoch mit 1,25 bis 1,5 Millionen Dollar fast dreißig mal so viel.

Interaktivität an großen Computern – UNIVAC I

Sie haben die UNIVAC im vorherigen Kapitel kurz im Zusammenhang mit Bandlaufwerken kennengelernt. Dort ging es um eine Verbesserung der Auslastung von teuren Rechnern durch das Lesen und Speichern von Programmen und Daten auf Magnetbändern. Die Dateneingabe mittels Tastatur läuft dieser Art der Optimierung natürlich total entgegen. Interessant ist aber, dass sich eine UNIVAC grundsätzlich auf ähnliche Art bedienen ließ wie eine LGP-30, denn die Bedienkonsole des Rechners ermöglichte die Eingabe von Werten in das Programm und der Befehlssatz des Rechners gab es her, Werte von der Konsole abzufragen oder auf ihr auszugeben. Die Bedienungsanleitung des Rechners beschreibt¹⁵:

The programmer may arrange to use the Supervisory Control as an input-output device. When this is done certain options are available depending on the switch settings. These options are explained in “Supervisory Control Operations”. The two programmed instructions which may be used for input or output in connection with the Supervisory Control are listed.

INSTRUCTIONS

10m: Stop UNIVAC operations and produce a visual signal. Call for one word to be typed from the Supervisory Control keyboard into memory location m. UNIVAC operations are resumed after the “word release button” on the Supervisory Control has been actuated.

50m: Print one word from memory location, m, onto the printer associated with the Supervisory Control. UNIVAC operations are resumed automatically after m has been transferred to an intermediate output storage location prior to printing.

Diese Art der Bedienung der UNIVAC war zwar möglich, allerdings wurde damit der Computer in seiner Verarbeitung oft angehalten und somit wertvolle Rechenzeit verschenkt. Im Gegensatz zur Bedienungsanleitung von IBMs 1401 wird daher für eine solche Nutzungsform auch nicht geworben, sondern explizit auf die Nachteile hingewiesen:

The ability to type into or print out of any desired memory location during the processing of a problem permits a very flexible control of that problem. However, it is well for the programmer to remember that the time required to execute these instructions is relatively great especially for a type-in instruction which is a human operation and an added source of error.

Beachtenswert ist, dass hier nicht nur darauf hingewiesen wird, dass der Mensch bei der Ausführung der Eingaben sehr langsam ist; problematisiert wird vielmehr auch, dass es sich bei Eingaben durch Menschen um eine zusätzliche Fehlerquelle handelt. Bei der UNIVAC mag dieser Hinweis dahingehend gedeutet werden, diese Betriebsart doch lieber zu meiden. In der Tat ergibt sich durch interaktive Nutzung eines Computers eine wichtige Änderung in der Programmierung. Konnte vorher davon ausgegangen werden, dass Eingabedaten im Großen und Ganzen korrekt und wohlformatiert waren, musste nun ein gehöriges Maß an Programmieraufwand in die Eingabebehandlung und die Verarbeitung von Eingabefehlern gelegt werden. Der Hauptaufwand bei der Programmierung verschob sich. Auf einmal entstand ein großer Programmieraufwand nicht für die eigentliche Programmlogik, sondern für seine Nutzungsschnittstelle.

Geteilte Zeit: Time-Sharing

In den im vorhergehenden Kapitel vorgestellten Einsatzszenarien etwa des RAMAC-Computers und des LGP-30 überwogen die Vorteile der Echtzeitverarbeitung die Nachteile eines nicht vollständig ausgelasteten und zudem recht langsamen Computers. Die Echtzeitnutzung kam hier deswegen infrage, weil wenige Nutzer den Rechner gebrauchten und die mit dem Rechner zu lösenden Probleme übersichtlich waren. Es gab somit keinen Bedarf an besonders gut ausgestatteten, schnellen Rechnern. Wollten jedoch viele Nutzer Rechendienste beanspruchen und brachten diese Nutzer eine Vielzahl verschiedener Programme mit, deren Erledigung eine gut ausgebaute Rechenanlage voraussetzte, kamen die genannten Geräte und eine Bedienung des Computers durch den Nutzer selbst nicht mehr infrage. Ärgerlicherweise war aber gerade für diese Nutzer, die ja häufig neue, umfangreiche Programme für komplexe Berechnungen erstellen mussten, die Batch-Betriebsart besonders lästig, denn sie machte das Programmieren sehr umständlich, zeitaufwändig und fehlerträchtig. Programme mussten handcodiert und abgelocht werden und die Rückmeldung zu nahezu unausweichlichen Programmierfehlern kamen erst nach Stunden oder gar Tagen. Den Ausweg aus der Batch-Nutzung für große, leistungsfähige Rechner brachte die Erfindung des „Time-Sharing“. Erste konzeptuelle und theoretische Vorarbeiten hierzu begannen bereits in den 1950er Jahren, die ersten nicht-rein-experimentellen Systeme wurden jedoch erst Mitte der 1960er in Betrieb genommen.

Beim Batch-Computing wurde eine hohe Auslastung des Computers dadurch erreicht, dass ein Computer sich nahezu nie im Wartezustand befand, sondern immer ein Programm vorlag, an dem gerechnet wurde. Auch beim Time-Sharing war es das Ziel, den Computer möglichst gut auszulasten. Das wurde allerdings nicht mehr dadurch gewährleistet, dass dem Computer in hoher Taktung Jobs zugeführt wurden, die dann nacheinander abgearbeitet werden konnten. Beim Time-Sharing teilten sich vielmehr die Programme vieler Nutzer die Rechenzeit des Computers. Sie liefen quasi gleichzeitig, bzw. so schnell abwechselnd, dass es so erschien, als sei dies der Fall. Mit dem Time-Sharing kam der Nutzer nun auch mit dem Rechner selbst in Kontakt. Dies geschah allerdings nicht direkt im Rechnerraum, der nach wie vor tabu war, sondern mittels sogenannter „Terminals“, die mit dem Rechner verbunden waren. Typische Terminals für frühe Time-Sharing-Systeme waren einfache Fernschreiber wie der rechts abgebildete. Nutzer konnten an Fernschreibern Eingaben machen und bekamen Ausgaben ihres Programms während des Programmablaufs direkt ausgedruckt. Ein Nutzer eines Time-Sharing-Systems musste an seinem Fernschreiber nicht warten, bis ein Programm eines anderen Nutzers zum Ende gekommen war, denn Time-Sharing-Systeme arbeiteten die Programme der Nutzer ja im Rundumverfahren ab. Es wurde in so schneller Folge zwischen den Programmen hin- und hergewechselt, dass für jeden einzelnen Nutzer die Illusion entstand, den Computer ganz für sich zu haben.

Das Nutzererlebnis eines Time-Sharing-Systems mit Fernschreiber war fundamental anders als das der Nutzung eines Computers im Batch-Betrieb. Statt Lochkartenstapel abzugeben und Stunden später Lochkarten und Ausdrucke zurückzuerhalten, wurden nun Befehle per Texteingabe über den Fernschreiber an den Computer gegeben. Dieser reagierte wiederum durch die Ausgabe von Texten, die vom Fernschreiber auf Endlospapier gedruckt wurden. Statt wie bisher stundenlang auf Ergebnisse zu warten, erschienen die Ergebnisse innerhalb von Minuten oder gar wenigen Sekunden. Die Arbeitsweise ist der des SABRE-Systems ganz ähnlich, bei der ja auch Terminals mit einem Computer verbunden wurden und Eingaben gemacht werden konnten, auf die der Zentralrechner umgehend antwortete. Beim SABRE-System gab es jedoch nur ein einziges laufendes Programm, das alle Terminals mit der gleichen Funktionalität bediente. Time-Sharing-Systeme hingegen waren so ausgelegt, dass sie die volle Flexibilität der individuellen Programmierung verfügbar machten. Jeder Computernutzer konnte seine eigenen Programme erstellen, auf dem Time-Sharing-System laufen lassen und zeitnah ein Ergebnis erhalten.

Für die Performance und Auslastung einer Rechenanlage hatte Time-Sharing natürlich seinen Preis:

Arbeitsspeicherbedarf: Da sich viele Programme gleichzeitig im Speicher befanden und zusätzliche Daten für die Verwaltung der angemeldeten Nutzer und der laufenden Programme notwendig waren, mussten Time-Sharing-Systeme mit mehr Arbeitsspeicher ausgestattet werden als für die Durchführung der gleichen Berechnungen im Batch-Betrieb notwendig gewesen wäre.

Performance: Die Organisation des Time-Sharing-Betriebs selbst verursachte einen sogenannten „Overhead“. Wenn zwanzig Nutzer gleichzeitig angemeldet waren und ein Programm laufen ließen, dann dauerte es insgesamt länger, als wenn man die zwanzig Programme hintereinander ablaufen lassen hätte, denn für das Wechseln zwischen den Programmen ging stetig Rechenzeit verloren. Diese verschenkte Zeit wurde umso größer, je mehr Nutzer das System benutzten. Die Verzögerung in der Bearbeitung war aber in der Regel zu verschmerzen, denn da das für den Nutzer ja so besonders unpraktische Job-Handling, das Ablochen und das lange Warten auf ein Ergebnis entfielen, wurde es für jeden einzelnen Nutzer trotz insgesamt langsamerer Verarbeitung doch signifikant schneller.

Auslastung: Der Batch-Betrieb sorgte für eine gleichmäßige Auslastung des Rechners auch in Zeiten, in denen wenige neue Jobs eingingen. Während der Stoßzeiten häuften sich die Jobs und landeten in einer Warteschlange. Diese Warteschlange konnte in Zeiten mit wenig Andrang abgearbeitet werden. Beim Time-Sharing hingegen wurde die Bearbeitung sehr langsam, wenn viele Nutzer das System nutzen, während Rechenzeit im großen Stile verschwendet wurde, wenn nur wenige Nutzer Programme laufen ließen. Um dennoch für eine gute Auslastung zu sorgen, wurden Time-Sharing- und Batch-Betrieb häufig kombiniert. Das Betriebssystem des Rechners bediente Nutzer an ihren Fernschreibern im interaktiven Betrieb, arbeitete aber gleichzeitig auch klassische Jobs ab. In Zeiten, in denen wenig interaktive Nutzung zu verzeichnen war, konnte dem Batch-Betrieb entsprechend mehr Priorität eingeräumt werden. Manche Time-Sharing-Systeme verbanden die beiden Betriebsarten sogar noch geschickter. Sie erlaubten etwa den Nutzern das Bearbeiten und Testen ihres Programms im Echtzeitbetrieb und ermöglichten es dann, die Ausführung des Programms, eventuell mit einer großen Datenmenge, in eine Batch-Warteschlange einreihen zu lassen, die dann bei Gelegenheit abgearbeitet wurde. M. V. Wilkes beschreibt dies¹⁶ für das Cambridge Time-Sharing System. Dort konnten Programmdateien per Editor vorbereitet werden und dann durch die Eingabe von RUNJOB und dem Dateinamen in eine klassische Job-Queue eingereiht werden. Die Ausgaben dieser Programme wurden entweder klassisch ausgedruckt oder aber wiederum als Datei zur Verfügung gestellt.

Mit dem Time-Sharing änderte sich die Art und Weise, wie Programme erzeugt und bearbeitet wurden. Es war nun nicht mehr nötig, diese Aufgabe auf Papier zu erledigen und das Programm dann manuell abzulochen. Der Computer konnte nun endlich selbst zum Programmieren genutzt werden. Damit das ging, brauchte es aber ein spezielles Programm zum Bearbeiten des Programmcodes, also einen Editor. Diesem Editor werden wir uns gleich widmen. Vorher sollten Sie sich jedoch einige Konsequenzen des Time-Sharings für die Nutzungsschnittstelle bewusst machen.

Virtuelle Objekte

Mit dem Aufkommen von Time-Sharing ging auch der Übergang von Konsolen zur Steuerung und Überwachung der Maschine zu für den Nutzer geschaffenen Nutzungsschnittstellen einher. Bisherige Computer brauchten keine Schnittstelle für den Nutzer des Rechners, denn Rechner und Nutzer kamen schon physisch gar nicht miteinander in Kontakt. Das wurde nun anders: Ein Nutzer, der am Fernschreiber saß, stand direkt mit dem Computer in Verbindung, auf dem seine Programme liefen. Er musste also eine Möglichkeit haben, die Programme auszuwählen und zu starten, sie zu erstellen oder sie gegebenenfalls zu löschen. Hierfür reichte es nicht, einfach eine textuelle Umsetzung dessen bereitzustellen, was bisher mit den Operator-Konsolen möglich war. Diese Konsolen waren sehr komplex und boten direkten Zugriff auf die Hardware des Rechners, auf interne Zustände und Speicherregister. Ein Nutzer an einem Fernschreiber war aber an Maschinenzuständen und Speicheradressierungen nicht interessiert, sondern benötigte eine Schnittstelle, die sich auf die von ihm verarbeiteten Daten und Programme bezog. Die vom Computer bereitgestellte Schnittstelle musste dem Nutzer die Programme und die Daten als etwas anbieten, auf das er sich beziehen konnte. Das begann schon bei dem Grundsystem des Time-Sharing-Systems, dem Kommando-Interpreter, mit dem etwa Programme gestartet werden konnten.

Eines der ersten Time-Sharing-Systeme, das nicht nur rein experimentell war, war das Dartmouth Time Sharing System (DTSS) am Dartmouth College in den USA. Es wurde 1964 in Betrieb genommen. Meldete man sich beim System an, musste man sich zunächst mit einer Nutzernummer identifizieren. War dies geschehen, konnte man entweder direkt mit der Programmierung eines Programms beginnen – dazu später mehr – oder aber auch bereits existierende Programme verwalten. Dazu stand eine Reihe von Befehlen zur Verfügung:

• LIST gab das Listing des aktuell geladenen Programms aus.
• NEW erzeugte ein neues Programm. Ein Programmname wurde nach der Eingabe von NEW abgefragt.
• OLD ermöglichte, ein früheres Programm wieder zu laden. Nach Eingabe von OLD wurde der Programmname des gespeicherten Programms abgefragt.
• SAVE speicherte das Programm unter dem aktuellen Programmnamen ab.
• UNSAVE löschte das Programm mit dem aktuellen Programmnamen.
• SCRATCH löschte das Programm, behielt aber den Programmnamen bei. Der Nutzer konnte also von vorne beginnen.
• CATALOG gab eine Liste aller für den angemeldeten Nutzer gespeicherten Programme aus.

Worauf bezogen sich diese Befehle? Es ging nun nicht mehr wie bei klassischer Programmierung um Register, Speicherstellen oder Sektoren auf Massenspeichern. Die Befehle bezogen sich zwar auf Programme, aber nicht im Sinne der einzelnen Anweisungen einer Programmiersprache, sondern auf Programme als Ganzes, auf etwas, das der Nutzer mit einem Namen ansprechen konnte. Ich nenne derartige Entitäten, auf die sich ein Nutzer in einer interaktiven Nutzungsschnittstelle beziehen kann und die von dieser Schnittstelle für den Nutzer erzeugt und zugreifbar gemacht werden, virtuelle Objekte.

Das Wort „virtuell“ wird in der deutschen Wikipedia meiner Meinung nach sehr bestechend definiert:

Virtualität ist die Eigenschaft einer Sache, nicht in der Form zu existieren, in der sie zu existieren scheint, aber in ihrem Wesen oder ihrer Wirkung einer in dieser Form existierenden Sache zu gleichen. Virtualität meint also eine gedachte Entität, die in ihrer Funktionalität oder Wirkung vorhanden ist.

Das, was ich hier „virtuelle Objekte“ nenne, existiert nicht realweltlich als Objekt im Sinne eines Gegenstandes. Für den Umgang mit dem Computer haben die virtuellen Objekte aber die Eigenschaften von tatsächlichen Objekten. Man kann sich also auf sie beziehen, sie erzeugen, vernichten und natürlich manipulieren.

In diesem Zusammenhang den Begriff „Objekt“ zu verwenden, ist übrigens meine Wortwahl entsprechend der Perspektive, die ich Ihnen in diesem Buch darlegen will. Auch in älteren Beschreibungen und Anleitungen von Computersystemen und Programmiersprachen findet man den Objekt-Begriff mitunter in dieser Verwendung. Mit dem Aufkommen der sogenannten „objektorientierten Programmierung“ wurde der Objektbegriff in der Informatik mit einem gewissen Programmierparadigma belegt. Der Begriff wurde regelrecht annektiert. Es geht mir hier aber nicht um die Programmierung, sondern auf die von der Nutzungsschnittstelle erzeugte Welt für den Nutzer. Das, was ich hier „Objekt“ nenne, ist für den Nutzer ein ansprechbares und manipulierbares Gebilde. Wie ein Programmierer hinter den Kulissen dieses Objekt realisiert, ob es auch da etwas gibt, was das Objekt als eine Einheit erscheinen lässt, oder ob es sich um eine Ansammlung von Variablen oder gar Datenströmen handelt, ist aus der Perspektive der Nutzungsschnittstelle nicht von Belang.

Die Time-Sharing-Applikation schlechthin: Der Editor

Die Möglichkeit, Programme unter direkter Nutzung des Computers zu bearbeiten und so die Misslichkeiten der Programmierung mit Lochkarten und Lochstreifen hinter sich zu lassen, war eine der Haupt-Triebkräfte hinter der Entwicklung von Time-Sharing-Systemen. Dass mit diesen Systemen dann auch Programme möglich waren, die interaktiv gesteuert werden können, wurde zwar gesehen, stand aber nicht unbedingt im Vordergrund und war, wie Sie gleich sehen werden, auch nicht in jedem Time-Sharing-System von Beginn an möglich. Haupt-Anwendung war in der Regel die Editor-Funktionalität.

Wenn Sie sich unter einem Editor ein Programm vorstellen, dass in etwa so aussieht wie ein Texteditor unter Windows oder MacOS oder gar wie eine moderne Programmierumgebung, dann haben Sie eine falsche Vorstellung. Die Bedienung eines Editors der damaligen Zeit war ganz anders als die Verwendung moderner Editoren. Begründet liegt dies in den Eigenschaften des Fernschreibers als Ein- und Ausgabegerät, die nicht recht zur Aufgabe eines Editors passten. Da Fernschreiber ganz analog etwas auf ein Blatt schrieben, kann man mit einem Fernschreiber wie mit einer Schreibmaschine immer nur etwas hinzufügen, also etwas Neues dazuschreiben. Die Aufgabe eines Editors ist es jedoch, einen im Computer befindlichen Text, etwa einen Programm-Quelltext, zu bearbeiten, also zu ändern. Was schon auf einem Blatt Papier steht, kann man aber nicht ändern. Es gab bei einem Fernschreiber kein Löschen und kein Backspace im heutigen Sinne. Fernschreiber wie der zuvor abgebildete ASR-33 verfügten zwar über eine „Rubout“-Taste, die gedrückt werden konnte, um durchzugeben, dass das vorher gesendete Zeichen „ausgewischt“ werden sollte. Natürlich wurde aber auch hier das vorherige Zeichen nicht vom Papier des Empfängers getilgt. Wurde einem Computer ein solches Zeichen geschickt, löschte er die Eingabe intern und schickte zur Bestätigung ein neues Zeichen zurück – häufig das Dollarzeichen – um darzustellen, dass die Eingabe akzeptiert wurde. Diese Art der Ein- und Ausgabe mag für das Löschen eines gerade eingegebenen falschen Zeichens noch hinreichend sein, stieß aber spätestens beim Versuch, Text zwischen vorhandene Worte einzufügen, an ihre Grenzen. Komplexere Aufgaben wie das Einfügen von Text konnten nur durchgeführt werden, indem dem Editor Befehle eingegeben wurden, die beschrieben, wie der Text angepasst werden konnte.

Wenn Sie Zugriff auf ein Linux- oder Unix-System (inklusive MacOS) haben, können Sie diese Funktionsweise früher Editoren noch heute nachvollziehen. Der in diesen Systemen verfügbare Zeileneditor „ed“ stammt aus der Anfangszeit des Betriebssystems Unix von Anfang der 1970er Jahre, aus einer Zeit also, als viele Computer noch per Fernschreiber bedient wurden.

Wird der Editor durch die Eingabe von ed in der Kommandozeile gestartet, passiert zunächst einmal gar nichts, außer dass ein Zeilenvorschub ausgelöst wird oder im modernen Bildschirm-Terminal der Cursor (die Schreibmarke) in die nächste Zeile wandert. Schreiben Sie nun nacheinander H und P jeweils gefolgt von Enter. Diese beiden Befehle sorgen dafür, dass Meldungen ausgegeben werden, wenn Fehler auftreten, und dass mit einem * angezeigt wird, wenn Sie eine Befehlseingabe machen können. Als ersten Schritt laden Sie eine Datei. Nehmen wir an, dass eine Datei „textfile.txt“ bereits existiert. Mit der Eingabe von r textfile.txt wird, nach der Bestätigung mit Enter, die Datei eingelesen. Der Editor antwortet mit der Anzahl der gelesenen Bytes, in unserem Beispiel 86. Da die Datei nicht groß ist, können Sie sie in ganzer Länge ausgeben. Dies geschieht durch eine Eingabe des Befehls ,l (hierbei handelt es sich um ein kleines L und nicht um die Zahl 1).

$ed
H
P
*r textfile.txt
86
*,l
This is the heading.$
The text starts hree. There may be many important things to say.$

Wie Sie sehen, handelt es sich hier um einen einfachen Text bestehend aus zwei Zeilen. Das Dollarzeichen steht jeweils für das Zeilenende. Sie können diesen Text nun bearbeiten, indem Sie Befehle eingeben. Im Beispiel werden wir zum einen unterhalb der Überschrift eine Zeile mit Plus-Zeichen einfügen, um sie besser abzusetzen, und zum anderen das Wort „hree“, wohl ein Tippfehler, durch das korrekte Wort „here“ ersetzen.

Um die Pluszeichen einzugeben, müssen Sie dem Editor mitteilen, dass Sie in Zeile 2 etwas einfügen wollen. Dies geschieht durch den Befehl 2i. Nun können Sie den neuen Text eingeben. Um die Eingabe abzuschließen, schreiben Sie einen einzelnen Punkt in eine Zeile und beenden Sie mit Enter:

*2i
+++++++++++++++++++++
.

Die ehemalige Zeile 2 müsste durch das Einfügen einer weiteren Zeile jetzt zur Zeile 3 geworden sein. Sie können das überprüfen, indem Sie die Zeile 3 mit dem Befehl ,3 ausgeben lassen.

*,3
The text starts hree. There may be many important things to say.$ 

Nun geben Sie einen Befehl ein, um in Zeile 3 das erste Vorkommen von „hree“ durch „here“ zu ersetzen und geben anschließend den kompletten berichtigten Text mit ,l nochmals aus.

*3s/hree/here/
*,l
This is the heading.$
+++++++++++++++++++++$
The text starts here. There may be many important things to say.$

Hiermit sind die beabsichtigten Änderungen abgeschlossen. Abschließend können Sie den verbesserten Text mit w besser.txt als „besser.txt“ abspeichern. Der Editor quittiert das wiederum durch die Angabe der geschriebenen Bytes. Die Eingabe des Befehls q beendet dann den Editor.

*w besser.txt
108
*q 

Konnten Sie beim Nachvollziehen dieses Beispiels das Hin und Her an einem Fernschreiber nachempfinden? Das Bearbeiten eines Textes ist auf diese Art und Weise sehr umständlich, denn man bearbeitet den Text nur indirekt. Der Text liegt im Computer zwar als bearbeitbares Objekt vor, aber man kann ihn nicht als Text sehen und an Ort und Stelle bearbeiten. Man muss stattdessen Befehle zur Bearbeitung geben und den aktuellen Zustand des Textes immer wieder ganz oder in Ausschnitten anfragen. Man kann diese Arbeitsweise in etwa damit vergleichen, als würde man jemanden anrufen, der einen Text vor sich liegen hat und diesen immer in Teilen durchgibt. Dieser Person könnten sie nun die Änderungen, die Sie machen wollen, durchgeben und dann immer wieder erfragen, wie jetzt der aktuelle Zustand des Texts ist.

Virtuelle Objekte: Interaktive Objektmanipulation

Im Editor erscheint der Text nicht etwa als Bitstrom oder als lange Zeichenkette, die er ja faktisch ist. Würde „ed“ kein Konzept von Zeilen als ansprechbare Objekte haben, wäre es noch viel umständlicher, den Editor zu nutzen, denn dann könnte man sich nicht auf Zeilen beziehen, sondern müsste Bytes innerhalb eines Datenstroms adressieren, sich also noch viel stärker auf die Ebene der Rechnerarchitektur hinunterbegeben. „Ed“ erzeugt hingegen durch seine Nutzungsschnittstelle für den Nutzer verstehbare, adressierbare, wahrnehmbar-machbare und manipulierbare Objekte. Jede sinnvolle Schnittstelle für Echtzeitsysteme erzeugt derartige virtuelle Objekte, auf die sich der Nutzer beziehen kann. Bei „ed“ waren es hier Zeilen und Zeichen. Auf der Ebene des Kontrollprogramms, des Kommandozeilen-Interpreters, sind es Programme und Dateien. Verwenden Sie ein Programm zur Verwaltung von Terminen, sind es Kalendereinträge. In all diesen Fällen beziehen Sie sich auf ein Objekt der Welt der Nutzungsschnittstelle statt auf Adressbereiche und Maschinenoperationen. Es handelt sich in all diesen Fällen, so einfach die Umsetzung der Nutzungsschnittstellen noch sein mag, um Nutzungsschnittstellen, die durch den Computer erzeugt werden, anstatt nur die Schnittstelle für den Computer zu sein. Programme für den Echtzeitbetrieb erzeugen sowohl die Bedienelemente, mit Hilfe derer sie bedient werden können, als auch die Objekte, wegen derer die Software überhaupt existiert. Was auf der anderen Seite der Nutzungsschnittstelle steckt, also die technische Implementierung der Software, ist für den Nutzer – zumindest in dieser Sichtweise – nicht von Belang und bleibt für ihn unsichtbar.

Das folgende Bild zeigt Studenten des Dartmouth College samt dem Mathematikprofessor John G. Kemeny. Sie sitzen rund um eine Reihe von Fernschreibern, die mit einem zentralen Computer verbunden sind. Am Dartmouth College wurde eines der ersten Time-Sharing-Betriebssysteme in Betrieb genommen. Von diesem Dartmouth Time-Sharing System war oben bereits einmal die Rede. Das System ging am 1. Mai 1964 in Betrieb.

Für das System wurde von besagtem John G. Kemeny zusammen mit Thomas E. Kurtz und Mary Kenneth Keller eine Programmiersprache namens BASIC (Beginner’s All-purpose Symbolic Instruction Code) entwickelt. BASIC zielte, wie der Name es sagt, auf den Einsatz als Anfängersprache, gerade in Bildungsinstitutionen, ab. Ziel war es, nicht nur angehenden Technikern und Ingenieuren, sondern allen Studierenden und Mitarbeitern des College und darüber hinaus das Programmieren zu ermöglichen. Die Sprache wurde etwa fünfzehn Jahre später zu einer der weitestverbreiteten Programmiersprachen. Quasi alle Heim- und Personal-Computer der 1980er Jahre waren mit einem BASIC-Interpreter ausgestattet. Betrachten Sie einmal das folgende kleine Programm, das die Zahlen von 1 bis 10 ausgibt.

10 FOR I=1 TO 10
20 PRINT I
30 NEXT I
40 END

Wie Sie sehen, beginnt jede Zeile mit einer Zeilennummer. Die Zeilennummern gehören fest zur Sprache BASIC. Sie dienen zwei ganz unterschiedlichen Funktionen. Rein funktional werden die Zeilennummern gebraucht, um im Programm springen zu können. Ein GO TO 100 (in späteren BASIC-Dialekten meist ohne Leerzeichen, also GOTO 100, geschrieben) etwa setzt den Programmablauf in Zeile 100 fort. Die Zeilennummern haben aber auch eine Funktion in der Nutzungsschnittstelle, erlauben sie es doch, Zeilen neu zu definieren und neue Zeilen zwischen den schon vorhandenen einzufügen. Wollen Sie das obige Programm etwa so abändern, dass es nicht die Zahlen von 1 bis 10, sondern von 2 bis 20 in Zweierschritten ausgibt, können Sie Zeile 20 einfach neu definieren:

20 PRINT 2*I

Wenn Sie geschickterweise zwischen den Zeilennummern größere Abstände gelassen haben, können Sie auch leicht Zeilen zwischenfügen, indem Sie einfach Zeilennummern zwischen den vorhandenen verwenden, also etwa:

15 PRINT "EINE ZAHL",
35 PRINT "FERTIG!"

Die erste Version des Dartmouth BASIC verfügte zwar durch das DTSS über einen interaktiven Editor, man konnte mit der Sprache allerdings keine Programme schreiben, die selbst interaktiv waren, denn es gab keine Möglichkeit, den Nutzer zu Eingaben aufzufordern. Alle Eingabedaten mussten, wie bei der Batch-Verarbeitung, im Vorfeld bekannt sein. BASIC fehlte auch eine Möglichkeit, Daten aus Dateien zu lesen, denn DTSS unterstützte keinerlei Daten-Dateien. Alle Daten mussten also im Programm selbst angegeben werden. Im folgenden Beispiel sehen Sie, dass dabei die frühere Batch-Denkweise mit Programm-Lochkarten und Daten-Lochkarten durchaus noch durchscheint.

100 PRINT "RECHNUNG"
200 PRINT
300 PRINT "MENGE","PREIS"
400 PRINT "------------------------------------"
500 LET SUMME=0
600 READ MENGE
700 IF MENGE=0 THEN 1100
800 READ PREIS
850 PRINT MENGE, PREIS
900 LET SUMME = SUMME + MENGE * PREIS
1000 GO TO 600
1100 PRINT
1200 PRINT "SUMME:"; SUMME 
1300 REM
1400 REM RECHNUNGSDATEN
1500 REM
1600 DATA 5,1.90
1700 DATA 1,2.70
1800 DATA 2,1.39
1900 DATA 7,0.99
2000 DATA 0
9000 END

Dieses Programm gibt eine Rechnung aus. Hierzu werden in Zeile 600 und 800 Daten eingelesen. Diese Daten sind im unteren Bereich des Programms ab Zeile 1600 angegeben. Der Ort dieser DATA-Zeilen ist ohne Belang. Sie könnten genauso gut auch am Anfang des Programms oder verteilt im Programm auftauchen. Die Daten wurden hier, dem Programm entsprechend, in Zweiergruppen aus einer Menge und einem Preis angegeben. Für BASIC ist diese Gruppierung allerdings unwichtig. Nur die Reihenfolge entscheidet. Es könnten etwa alle Daten mit Komma getrennt innerhalb einer Zeile definiert werden. In Zeile 2000 steht eine 0 als Datum. Diese Null wird in der Programmlogik als Indikator dafür genutzt, dass keine weiteren Daten folgen. Wird diese Null in Zeile 600 gelesen, springt das Programm von Zeile 700 in Zeile 1100 und setzt mit der Ausgabe der Gesamtsumme fort. Würde man die Null weglassen, würde das Programm versuchen, weiter Daten einzulesen und mit einer Fehlermeldung abbrechen. Startete man das Programm, erhielt man eine Ausgabe folgender Art:

USER NO. 163405    PROBLEM NAME: RECHNUNG   6 SEPT. 1963    TIME: 19:34

RECHNUNG

MENGE              PREIS
------------------------------------
5                  1.9
1                  2.7
2                  1.39
7                  0.99

SUMME: 21.91


TIME:   1 SECS.

BASIC wurde – unter anderem von Studenten des College – intensiv weiterentwickelt. In der dritten Iteration im Jahre 1966 wurde der INPUT-Befehl eingeführt, der nun interaktive Programme ermöglichte. Wurde der Befehl ausgeführt, gab das System ein Fragezeichen aus. Der Nutzer konnte nun eine Eingabe machen. Mit einem Zeilenvorschub wurde die Eingabe beendet. Mit diesem INPUT-Befehl wurden nun Programme wie das folgende möglich:

100 PRINT "RATE EINE ZAHL ZWISCHEN 1 UND 100."
110 LET X = INT(100*RND(0)+1)
120 LET N = 0
150 PRINT "DEIN TIPP";
160 INPUT G
170 LET N = N+1
180 IF G = X THEN 400
190 IF G < X THEN 250
200 PRINT "ZU GROSS!"
210 GO TO 150
250 PRINT "ZU KLEIN!"
260 GO TO 150
400 PRINT "RICHTIG GERATEN!"
410 PRINT "DU HAST"; N; "ZUEGE GEBRAUCHT"
420 END

Bei diesem Programm handelt es sich um ein einfaches Spiel. Die Aufgabe des Spielers ist es, eine Zahl zwischen 1 und 100 zu erraten. Der Computer gibt nach jedem Raten an, ob die geratene Zahl zu groß oder zu klein ist, bis die Zahl schlussendlich geraten wird. An einigen Merkmalen dieses Listings sehen Sie, wie sehr BASIC ganz auf fernschreiberbasierte Time-Sharing-Systeme ausgelegt ist. Das beginnt bereits bei der Wahl der Worte für die Befehle. PRINT bedeutet nicht neutral „Schreiben“, sondern eben das, was ein Fernschreiber tut, nämlich Drucken. Der Befehl INPUT erzeugt eine für Fernschreiberbedienung typische Eingabemöglichkeit. Ein Hinweiszeichen wird ausgegeben, das dem Nutzer anzeigt, dass eine Eingabe erwartet wird. Der Computer verarbeitet vorhandene Eingaben auf Zeilenbasis. Der Zeilenvorschub wird also zur Freigabe der Eingabe. Ebenfalls gut optimiert ist die Funktionsweise des Editors. Programmteile können durch das Definieren neuer Zeilen und das Überschreiben bestehender Zeilen verändert werden. Einblick in das Programm kann ganz oder auch in Teilen durch den Befehl LIST genommen werden. Diese Art, das Programm zu verbessern und zu ergänzen, ist einer Bedienung per Fernschreiber und der mit ihm verbundenen Nachteile sehr angemessen. Das Problem bleibt, ähnlich wie bei „ed“ oben, dass man das Programm nur im Überblick sieht, wenn man es „auslistet“. Wenn man es dann bearbeitet, ist diese Änderung natürlich nicht im vorher gedruckten Listing zu sehen. Man muss als Programmierer den aktuellen Zustand des Programmcodes also im Kopf haben oder häufig neue Listings anfordern.

Was ist geblieben?

Das Time-Sharing-System DTSS ist von seinem Funktionsumfang her ziemlich eingeschränkt. Es stellt seinen Nutzern lediglich eine Programmierumgebung bereit. Neben BASIC konnte auch in den wissenschaftlichen Programmiersprachen ALGOL und FORTRAN mit dem System programmiert werden. Spätere Time-Sharing-Systeme, die im Laufe der Jahre entstanden, waren weit umfangreicher. Sie boten dem Nutzer Zugriff auf eine Vielzahl von Systemprogrammen, verfügten über ausgefeilte Editoren und Compiler für eine Vielzahl von Programmiersprachen. Hinzu kamen Verwaltungsfunktionen für die Nutzer des Systems. Für jeden Nutzer mussten eigene Bereiche für das Speichern von Programmen und Daten vorgesehen und vor dem Zugriff durch andere Nutzer geschützt werden. Time-Sharing-Systeme in großen Organisationen wie Universitäten verfügten zudem oft über Einrichtungen zu Rechenzeit- und Plattenplatzbeschränkung (sogenannte „Quotas“), um einen Betrieb mit vielen Nutzern gewährleisten zu können.

Was ist geblieben von den Time-Sharing-Systemen der frühen Zeit, die doch heute einigermaßen altertümlich wirken? Es mag Sie vielleicht wundern, aber tatsächlich können viele der Eigenheiten heutiger Betriebssysteme auf die frühen Time-Sharing-Systeme zurückgeführt werden. Es lassen sich hier sehr klare Entwicklungslinien erkennen. Großen Einfluss hatte zum Beispiel das ab 1963 entwickelte Multics (Multiplexed Information and Computing Service). Viele der Innovationen dieses Betriebssystems, etwa ein hierarchisches Dateisystem, fanden Eingang in das Betriebssystem UNIX, das beim amerikanischen Telefonmonopolisten AT&T ab 1969 entwickelt wurde. UNIX, ebenfalls ein Time-Sharing-System, hatte starken Einfluss auf das PC-Betriebssystem MS-DOS und damit auch auf Windows. Schlussendlich basiert das freie Betriebssystem Linux ebenfalls auf den Konzepten von UNIX.

Ein weiteres einflussreiches frühes Time-Sharing-System war das System TOPS-10 von 1967, das auf Großrechnern der Digital Equipment Corporation, kurz DEC, lief. Die für die damalige Zeit sehr benutzerfreundliche Arbeitsweise dieses Systems war Grundlage für das Betriebssystem OS/8 für die Minicomputer von DEC. Dieses OS/8 wiederum inspirierte Gary Kildall bei der Entwicklung des Betriebssystems CP/M, das auf frühen Microcomputern sehr große Verbreitung fand. CP/M wiederum war die Vorlage für Microsofts MS-DOS und MS-DOS blieb lange Zeit die technische Basis von Windows. Noch heute entspricht der Kommandozeilen-Interpreter von Windows, die „Eingabeaufforderung“, der Funktionsweise der MS-DOS-Kommandozeile. In dieser Eingabeaufforderung können Sie zum Auflisten von Dateien den Befehl dir eingeben. Diesen können Sie durch die ganze Kette über MS-DOS, CP/M, und OS/8 bis zu TOPS-10 zurückverfolgen.

Auch wenn Sie diese konkreten Befehle einmal außer Acht lassen, sind die Kommandozeilen heutiger Betriebssysteme Werkzeuge, die ihren Großvätern und Urgroßvätern aus der Time-Sharing-Ära sehr ähneln. Öffnen Sie doch einmal die Eingabeaufforderung von Windows oder ein Terminal unter MacOS oder Linux und probieren Sie einige Befehle aus. Bei dem ständigen Hin und Her zwischen der Eingabezeile und den Ausgaben des Systems können Sie mit etwas Fantasie noch regelrecht den Fernschreiber rattern hören…

Terminals statt Fernschreiber

Ich fasse noch einmal zusammen: Durch Fernschreiber, die mit Computern im Time-Sharing-Betrieb verbunden wurden, war die interaktive Nutzung von Computern bei gleichzeitiger Erfüllung der hohen Anforderungen an Durchsatz und Rechenleistung möglich. Turnaround-Zeiten sanken von Tagen und Stunden auf Minuten und Sekunden und mittels Editoren konnten die Computer als Werkzeug zum Schreiben der Programme verwendet werden, die dann später auf dem Computer auch gleich gestartet werden konnten. Der Fernschreiber oder die elektrische Schreibmaschine als Ein- und Ausgabegerät hatten aber ihre Nachteile, denn Fernschreiber und Schreibmaschinen erzeugten ein analoges Medium durch Einschreibung von Schriftzeichen auf ein Endlospapier. Innerhalb des Computers wurden durch die interaktive Software virtuelle Objekte erzeugt, die durch den Nutzer sehr dynamisch änderbar waren, doch nach außen hin ließen sich diese Objekte nicht mit den gleichen dynamischen, manipulierbaren Eigenschaften darstellen. Man konnte zum Beispiel einen im Computer gespeicherten Text ändern, aber man konnte mit dem Fernschreiber eben nicht den schon ausgegebenen Text auf dem Papier ändern. Die Konsequenz aus dieser Lücke zwischen der flexiblen Welt im Computer und der statisch eingeschriebenen Welt der Nutzungsschnittstelle war, dass Änderungen der virtuellen Objekte im Computer nur dadurch vorgenommen werden konnten, dass die Änderungen sprachlich beschrieben wurden. Sich dabei ergebende Änderungen konnten nicht direkt, sondern nur vermittelt über eine Anforderung des Nutzers und eine Antwort in Form eines Ausdrucks des Systems wahrgenommen werden.

Die geschilderte kommandoorientierte Arbeitsweise lässt sich ein bisschen mit dem Bestellen von Pizza vergleichen. Stellen Sie sich vor, Sie rufen bei einer Pizzeria an, von der Sie keine dieser praktischen, faltbaren Papierkarten bei sich zu Hause haben. Sie wollen dort Pizza bestellen. Wir denken uns nun einen sehr fantasielosen Angestellten der Pizzeria, der immer nur genau das tut, was Sie ihm sagen. Vor seiner Nase hat dieser Angestellte der Pizzeria die komplette Speisekarte, einen Zettel und einen Stift, um aufzuschreiben, was Sie gerne haben möchten. Sie sehen von all dem natürlich nichts, denn Sie haben ihn ja am Telefon. Wie kommen Sie nun zu Ihrem Essen?

• Zunächst einmal müssen Sie fragen, was Sie überhaupt bestellen können, also vielleicht erst einmal, welche grundsätzlichen Gruppen an Gerichten es gibt, also Nudeln, Pizza, Fischgerichte und so weiter. Letztlich können Sie durch mehrfaches Nachfragen so hinter die Inhalte der Speisekarte kommen und etwas auswählen.
• Nun geben Sie einige Bestellungen auf. Natürlich wissen Sie für viele der Gerichte nicht genau, welche Zutaten sie haben, welche Pizza etwa welchen Belag hat. Sie müssen also wieder einmal – und wahrscheinlich öfter – nachfragen.
• Die Antwort zu einem Gericht Ihrer Wahl gefällt Ihnen vielleicht nicht. Brokkoli? Kann man das nicht durch Paprika ersetzen? Wieder müssen Sie nachfragen und gegebenenfalls eine entsprechende Anweisung geben.
• Was hatten Sie jetzt gleich alles bestellt? Haben Sie vielleicht etwas vergessen? Hat Ihr Gegenüber Sie immer richtig verstanden? Haben Sie sich vielleicht versprochen? Da Sie den Zettel Ihres Gegenübers auf der anderen Seite nicht sehen können, bleibt Ihnen nur, sich die Bestellung nochmal vorlesen zu lassen.
• Wo Sie sich das jetzt nochmal so anhören, fällt Ihnen auf, dass die überbackenen Nudeln vielleicht doch etwas mächtig sein könnten. Sie bitten darum, diese zu streichen und bestellen lieber eine Pizza Margherita. Wurde das richtige Gericht entfernt? Sie ahnen es schon – Sie müssen wieder nachfragen.

So kompliziert ist es bei Ihnen nicht, wenn Sie etwas bestellen? Wahrscheinlich nicht, denn Sie haben eventuell eine App oder eine Speisekarte der Pizzeria zu Hause, auf der Sie sehen können, was zur Auswahl steht und auch, welche Anpassungen an den Gerichten Sie vornehmen können. Außerdem weiß Ihr Gegenüber natürlich um die Probleme der Bestellungen dieser Art und denkt mit, wiederholt etwa, was er verstanden hat und gibt gegen Ende der Bestellung von selbst eine Zusammenfassung. In dieser Situation sind Sie bei der Nutzung des Computers nicht. Sie haben keinen Einblick in die komplette Auswahl, die Ihnen das System bietet, und der Kommandozeilen-Interpreter ist leider – vielleicht auch Gott sei Dank – sehr schlecht darin, für Sie mitzudenken und zu erkennen, wenn Sie etwas versehentlich getan haben.

Terminals und räumliche Objekte

Die Probleme dieser sprachlich-indirekten Interaktion mit dem Computer können mit der Einführung von Terminals mit Bildschirm und Tastatur überwunden werden, denn das Terminal erlaubt Ihnen eine dauerhafte, räumliche Darstellung und Manipulation von virtuellen Objekten der Nutzungsschnittstelle.

Die Entwicklung von Terminals ist ein in der Computergeschichte tendenziell zu wenig betrachteter Bereich. Man könnte ohne Weiteres ganze Bücher nur über die Entwicklung von Terminals und ihren Einfluss auf die Entwicklung von Nutzungsschnittstellen schreiben, denn spätere Terminals wurden mit eigenen Prozessoren, einem eigenen Betriebssystem und Speichermedien ausgestattet und wurden damit quasi zu Personal Computern. Wir wollen es vorerst aber nicht so weit treiben und uns auf die einfachen Geräte wie das rechts abgebildete ADM-3A von Lear Siegler beschränken. Dieses Gerät ist kein Computer, sondern nur ein Terminal. Ein solches Gerät konnte anstelle eines Fernschreibers an einen Computer angeschlossen werden und dann zunächst einmal genau so wie dieser verwendet werden. Anstelle eines Ausdrucks wurden die Zeichen auf dem Bildschirm ausgegeben. War der Bildschirm vollgeschrieben, rutschten die Zeichen automatisch nach oben. Terminals mit zusätzlichem Speicher erlaubten sogar das Scrollen nach oben, um wie beim Papierausdruck das vorher Ausgegebene ansehen zu können. Das hier gezeigte ADM-3A konnte 24 Zeilen zu je 80 Zeichen anzeigen und unterstützte im Gegensatz zur Version ohne das A am Ende nicht nur Großbuchstaben, sondern auch Kleinbuchstaben. 80 Zeichen pro Zeile bedeutet, dass die komplette Breite des US-Letter-Formats oder auch des DIN-A4-Formats dargestellt werden konnte.

Häufig wurden Terminals dieser Art zunächst als Ersatz für einen Fernschreiber, aber sonst genauso wie dieser, eingesetzt. Der Betrieb war leiser, es wurde nicht so viel Papier verbraucht und ein Terminal war auch erheblich kleiner als ein Fernschreiber. Wenn man es bei der fernschreiberartigen Betriebsart beließ, wurde das Potenzial des neuen Geräts aber gar nicht genutzt. Scherzhaft wurde dann der Begriff „Glass Teletype“ verwendet, denn das Terminal war dann funktionsidentisch mit einem Teletype, also einem Fernschreiber, nur dass das Papier eben aus Glas war. Der eigentliche innovative Vorteil von Terminals dieser Art lag aber nicht im Sparen von Papier, sondern in der Möglichkeit, Zeichen nicht nur ausgeben, sondern auch löschen und überschreiben zu können, und damit vor allem darin, den Cursor frei auf dem Bildschirm positionieren zu können. Diese Positionierungstechnik erlaubte es, die Buchstaben auf dem Bildschirm zu arrangieren und dieses Arrangement flexibel zu aktualisieren. Diese Art der Terminal-Nutzung, bei der mit Steuerzeichen der Bildschirm gelöscht werden und der Ein- und Ausgabecursor frei positioniert werden konnte, war damit die Grundlage von sich aktualisierenden Statusanzeigen, Formularmasken am Bildschirm, Menüs, Editoren, bei denen der bearbeitete Text am Bildschirm dauerhaft zu sehen und zu bearbeiten ist, und vielem Weiteren mehr, was für uns heute an den Nutzungsschnittstellen der Computer selbstverständlich erscheint.

Dumme und intelligente Terminals

Bei dem ADM-3A – ADM steht übrigens für American Dream Machine – handelte es sich um ein Gerät, das man als „Dumb Terminal“ bezeichnete. Der Hersteller Lear Siegler verwendete diesen Ausdruck sogar in der eigenen Werbung für das Gerät, allerdings mit dem Kniff, dass die Verwendung eines solchen dummen Terminals doch eine sehr intelligente Sache sei. Wenn es „dumb terminals“ gab, musste es natürlich andere Terminals gegeben haben, die weniger dumm waren. In der Tat gab es die und ganz folgerichtig wurden sie „intelligent terminals“ genannt.

Den Unterschied zwischen den beiden Terminal-Arten kann man sich an einem Beispiel gut klarmachen: Stellen Sie sich ein Programm vor, in dem Sie ein Formular ausfüllen können, sagen wir, für eine Lieferung. Beim Dumb Terminal füllte das Programm den Bildschirm des Terminals mit den Zeichen der Eingabemaske, positionierte dann den Cursor beispielsweise an die Position hinter „Nachname:“ und wartete auf Eingaben des Nutzers. Das Programm merkte sich dabei, dass nun das Eingabefeld „Nachname“ ausgefüllt wird. Tippte der Nutzer nun ein „F“ ein, verarbeitete der Computer diese Eingabe, aktualisierte die Eingabevariable und schrieb ein F auf den Bildschirm. Folgte nun ein Backspace, verarbeitete der Computer auch dies und löschte das F wieder aus dem Speicher und vom Bildschirm. So ging das für alle eingegebenen Zeichen weiter. Erst wenn irgendwann die Eingabe mit ENTER abgeschlossen wurde, speicherte das Programm die bisherige Eingabevariable in eine Programmvariable, positionierte dann den Cursor hinter „Vorname:“ und das Spiel begann von Neuem. Sie merken sicher, dass der Programmieraufwand und damit auch der Ausführungsaufwand während der Nutzung bei einem solchen Programm hoch war, denn das System musste jede einzelne Eingabe interpretieren, in Ausgaben umsetzen, den Cursor positionieren und so weiter.

Beim Einsatz eines „intelligent terminals“ war der Aufwand auf dieser Ebene viel geringer. Wurde zum Beispiel ein ADM-1 oder ein Datapoint 3300 verwendet, wurde vom Programm eine komplette Bildschirmmaske übertragen, die auch Informationen darüber enthielt, welche Bereiche für den Nutzer manipulierbar waren und welche nicht. Das Terminal selbst übernahm die Eingabekontrolle innerhalb der festgelegten Felder. Wenn ein Nutzer etwas in ein mehrzeiliges „Bemerkungen“-Feld tippte, konnte er darin beliebig Korrekturen vornehmen, Zeichen oder gar ganze Zeilen einfügen, ohne dass das Computerprogramm mit dieser Bearbeitung etwas zu tun hatte. Erst beim Betätigen einer Sende-Taste, oft auch „Datenfreigabe“ genannt, wurden die Daten an das Time-Sharing-System übertragen. Intelligente Terminals sparten dadurch erheblich Aufwand bei der Anwendungsprogrammierung und „Rechenzeit“ bei der Programmausführung, da viele der Standardverarbeitungen der Texteingabe an das Terminal selbst abgegeben wurden. Sie können das etwa mit dem Programmieren eines Eingabeformulars für eine Website vergleichen. Auch hier verwenden die Nutzer eine Art intelligentes Terminal, nämlich einen Webbrowser. Sie müssen sich als Programmierer einer Website nicht mit Details wie der Eingabe des Nutzers auf der Ebene der Eingabe von Buchstaben auf der Tastatur beschäftigen, sondern können darauf bauen, dass Browser und Betriebssystem die entsprechenden Funktionen zur Verfügung stellen. Sie behandeln erst wieder die fertige Eingabe des Nutzers.

Die Verwendung von Intelligent Terminals scheint sehr sinnvoll zu sein. Dumb Terminals waren dennoch viel verbreiteter und haben die Nutzungsschnittstellen stärker weitergebracht. Warum war das so? Zum einen waren diese Terminals natürlich erheblich günstiger, was gerade dann, wenn in einer Organisation viele Terminals genutzt werden sollten, natürlich ein nicht zu unterschätzender Vorteil war. Der zweite Vorteil betraf auf der anderen Seite die Einsatzbereiche der Terminals. Intelligent Terminals entfalteten ihren größten Vorteil bei klassischen Masken, also Eingabeformularen mit vielen Datenfeldern. Dumb Terminals waren darauf hingegen nicht festgelegt, denn sie konnten alles darstellen und verarbeiten, was mit einer dynamischen Text-Ein-und-Ausgabe denkbar war, und waren nicht auf die Eingabeformate beschränkt, die ihnen das Terminal vorgab. Einen Editor, wie den im Folgenden vorgestellten „vi“, können Sie zum Beispiel kaum mit den Funktionalitäten eines intelligenten Terminals umsetzen. Natürlich konnten Sie ein intelligentes Terminal auch wie ein Dumb Terminal betreiben, doch gingen dann alle Vorteile verloren. Andersherum können Sie die Funktionalität eines Intelligent Terminals, genug Rechenleistung vorausgesetzt, gut mit Software simulieren.

Direkte Manipulation: Visuelle Editoren

Wir haben uns ein paar Seiten zuvor angesehen, wie man einen Text mit dem Unix-Editor „ed“ bearbeiten kann. Sein Nutzungsparadigma ist noch heute auf einfache Terminals und Fernschreiber ausgelegt. Wir wagen nun, ausgestattet mit einem Terminal wie dem ADM-3A, den Schritt zu einem visuellen Editor.

Von „ed“ zu „vi“

Der oben abgebildete Unix-Editor „vi“ aus dem Jahr 1976 – „vi“ steht für „visual“ – ist dem Editor „ed“ im Grunde von der Funktionsweise her gar nicht unähnlich. Im Gegensatz zu „ed“ sieht man bei „vi“ jedoch einen Ausschnitt des Textes dauerhaft am Bildschirm. „vi“ erlaubt es auch, einen Cursor im Text zu positionieren, dann in einen Einfügemodus zu wechseln und neue Textinhalte an der Stelle des Eingabecursors einzufügen. In einem Befehlsmodus erlaubt „vi“ die Eingabe von Befehlen in eine Befehlszeile am unteren Bildschirmrand. Das Resultat dieser Befehle, zum Beispiel das Ersetzen eines Wortes durch ein anderes, wird in „vi“ sofort als Änderung des dargestellten Textes angezeigt. Die Bedienung des „vi“ ist für heutige Maßstäbe kryptisch und kompliziert, doch verwirklicht der Editor, ganz seinem Namen entsprechend, die Potenziale von am Bildschirm dauerhaft sichtbaren und auch dort bearbeitbaren Zeichen. Zwar erlaubt der Editor die Eingabe von Befehlen, doch müssen diese nicht mehr für das Einfügen genutzt werden und auch für die Ausgabe ist es nicht mehr nötig, die Zeilennummer im Text zu kennen. „vi“ unterstützt weiterhin die Manipulation von Texten per Befehl. Fans von „vi“ mögen den Editor oft gerade wegen dieser Möglichkeit, Textmanipulationen per Kommando durchführen können. In der Tat kann dies gerade bei komplexen Operationen und wenn man sich gut auskennt, sehr schnell von der Hand gehen, denn „vi“ erlaubt Textumformungen per regulärer Ausdrücke. Für Unkundige sehen diese Befehle allerdings oft so aus, als sei jemand auf die Tastatur gefallen.

Vergleicht man die Ur-Version von „vi“ mit der Funktionalität heutiger Text-Editoren, bemerkt man, dass eine heute ganz grundlegende Eigenschaft noch fehlt: Der große Vorteil der Textbearbeitung an Terminals war ja, dass der ausgegebene Text selbst direkt an Ort und Stelle bearbeitet werden konnte. Statt eines Befehls der Art „Füge in Zeile 20 nach dem 4. Wort ein Komma ein“, konnte mit dem Cursor an diese Stelle navigiert und das Komma eingefügt werden. Jeder moderne Editor unterstützt diese Arbeitsweise – auch „vi“. Was bei „vi“ aber nicht ging, war die räumliche Markierung eines Textausschnitts und das Anwenden eines Manipulationsbefehls auf diesen Bereich. Wenn Sie heute auf einem Linux- oder Unix-basierten System „vi“ eingeben, öffnet sich ein Editor, den Sie genau wie zuvor beschrieben verwenden können. Es handelt sich aber in der Regel nicht mehr um den „vi“ aus den 1970er Jahren, sondern um eine erweiterte Version mit Namen „vim“ (für „vi improved“). Ende der 1980er Jahre wurde der klassische Editor in vielerlei Hinsicht erweitert. Unter anderem gibt es nun einen Modus, der eine räumliche Selektion von Textteilen erlaubt. Die selektierten Textteile werden invertiert dargestellt. Dieses Selektieren unter „vim“ funktioniert folgendermaßen:

• Sicherstellen, dass Sie sich im Befehlsmodus befinden. Den Einfügemodus gegebenenfalls durch ESC verlassen,
• den Cursor am Beginn des Blocks positionieren,
• durch Eingabe von SHIFT+v die komplette Zeile, durch STRG+v den kompletten Block markieren oder
  • v eingeben, um den Blockanfang festzulegen,
  • mit dem Cursor zum Blockende navigieren,
• d (delete) eingeben, um den Block auszuschneiden oder y (yank), um ihn zu kopieren,
• mit dem Cursor zur Zielposition navigieren,
• p (paste) eingeben, um den Block hier einzufügen.

Die Möglichkeit der räumlichen Selektion der auf dem Bildschirm angezeigten Elemente ermöglicht hier die direkte Manipulation. Klassischerweise wird dieser Begriff „direkte Manipulation“ mit Maus-Interaktion und grafischen Darstellungen verbunden¹⁷. Im Prinzip reicht aber ein Text-Terminal aus, insofern Objekte räumlich dargestellt und auch räumlich selektiert und manipuliert werden können. Das ist bei „vi“ der Fall. „Direkte Manipulation“ bedeutet, dass der Handlungs- und der Wahrnehmungsraum gekoppelt sind. Objekte werden bei „vi“ an einem Ort am Bildschirm angezeigt, werden an ebendiesem Ort selektiert und an Ort und Stelle manipuliert. Wenn „vi“ allerdings im Befehlsmodus verwendet wird, ist das nicht so, denn dann werden die Manipulationen in einer Befehlszeile eingegeben, wirken sich aber auf Objekte an anderer Stelle aus.

Experimentelle grafische Systeme

Die bis hierhin beschriebenen interaktiven Computersysteme mit angeschlossenen Fernschreibern oder später mit Text-Terminals beschränkten sich in ihrer Schnittstelle auf rein textuelle Ein- und Ausgaben oder allenfalls auf Textzeichen, mit denen eine Art Pseudo-Grafik erzeugt werden konnte.

Im „vim“-Beispiel des vorherigen Kapitels wurde ein Cursor räumlich positioniert, um Objekte am Bildschirm zu selektieren. Eine solche Selektion per Cursor-Tasten ist innerhalb von Texten praktikabel, in vielen Fällen aber jedoch recht umständlich und indirekt. Von Smartphones kennen Sie heute alle eine erheblich direktere Methode, nämlich das Zeigen auf ein Objekt mit dem Finger. Es ist durchaus erstaunlich, dass etwas ganz Ähnliches bereits in den 1950er Jahren erdacht und genutzt wurde. Zwar brauchte das Zeigen damals noch ein Zusatzgerät, doch dieses Zusatzgerät konnte damals schon direkt auf den Bildschirm gerichtet werden. Die Anfänge dieser direkten räumlichen Selektion und der grafischen Darstellung von Informationen liegen, wie oft in der Computergeschichte, beim Militär.

Whirlwind und SAGE

Mitte der 1940er bis Anfang der 1950er Jahre entwickelte das Massachusetts Institute of Technology (MIT) einen Echtzeitcomputer für die US Navy. Er war zunächst als Flugsimulator geplant, wurde dann später aber für die Anforderungen der Flugüberwachung neu konzipiert. Dieser „Whirlwind“-Computer war in vielerlei Hinsicht technisch beachtenswert, schon allein weil es sich um einen Echtzeit-Computer handelte, der laufend Daten verarbeitete, anzeigte und Eingaben erwartete. Whirlwind konnte unter anderem auch Speicherinhalte auf dem Bildschirm eines Oszilloskops zur Anzeige bringen. Das war für sich genommen nicht außergewöhnlich. Selbst der britische EDSAC von 1945 verfügte schon über eine solche Einrichtung, bei der Speicherinhalte des Computers als Punkte auf einem Bildschirm angezeigt werden konnten. Eine Innovation war jedoch die Entwicklung eines stiftartigen Geräts, „Lightpen“ oder zu Deutsch „Lichtgriffel“ genannt. Das einfache Instrument ist rechts abgebildet. Mit diesem Stift konnte auf Punkte auf dem Bildschirm gezeigt werden. Der Computer konnte die Position des Stiftes auf dem Bildschirm erkennen und somit das Speicherbit, auf das gezeigt wurde, identifizieren.

Der Lightpen war eine genial einfache Konstruktion, die sich die Funktionsweise von Monitoren mit Bildröhre zunutze machte. Stifte dieser Art bestanden im Prinzip nur aus einer einfachen Fotozelle, die an der Spitze des Stiftes angebracht war. Der Stift selbst kann also nur feststellen, ob es an der Spitze des Stiftes hell ist oder nicht. Bei einem Monitor mit Kathodenstrahlröhre, also etwa auch bei den alten, klobigen Fernsehern, wurde ein Bild dadurch erzeugt, dass ein Elektronenstrahl Punkte auf einer fluoreszierenden Schicht auf der Vorderseite der Röhre zum Leuchten bringt. Der Bildaufbau erfolgte dabei wie ein geschriebener Text Zeile für Zeile von links nach rechts und von oben nach unten. Dies geschah allerdings so schnell, dass man mit bloßem Auge den Bildaufbau nicht erkennen konnte. Zeigte man nun mit einem Lightpen auf eine Stelle auf einem erleuchteten Bildschirm, wurde die Fotozelle zu einem spezifischen Zeitpunkt hell beleuchtet. Durch präzise Messung dieses Zeitpunktes und den Abgleich mit dem Wissen, wann die Darstellung des Bildes in der oberen linken Ecke begann, konnte errechnet werden, auf welche Bildschirmposition der Lightpen gerade zeigte. Der Lightpen des Whirlwind-Computers war allerdings noch nicht als Eingabegerät für die eigentliche Funktionalität des Computers gedacht, sondern wurde zu Fehlerbehebungszwecken genutzt.

Der Whirlwind-Computer war die Grundlage für das in den 1950er Jahren vom MIT und IBM aufgebaute SAGE-System. SAGE steht für Semi-Automatic Ground Environment. Das Herzstück von SAGE waren zwei riesige, von IBM hergestellte Computer. Die beiden Systeme arbeiteten parallel, um Computerfehler und Ausfälle möglichst auszuschließen. Die Aufgabe des SAGE-Systems war die Luftraumüberwachung. Feindliche sowjetische Flugzeuge sollten erkannt und gegebenenfalls Abwehrmaßnahmen eingeleitet werden können. Eine einfache Radarüberwachung des Luftraums konnte das nicht gut leisten, da mit einer üblichen Radaranlage immer nur recht kleine Bereiche überwacht werden konnten und es zum damaligen Zeitpunkt bereits viele völlig ungefährliche militärische und zivile Flugbewegungen gab.

Ein verdächtiges Radar-Echo konnte so leicht in der Fülle der Informationen untergehen. Um die Luftraumüberwachung zu verbessern, wurden die Daten vieler verteilter Radarstationen im SAGE-Computer zusammengeführt. Diese Daten wurden mit den vorhandenen Informationen über gemeldete Flugbewegungen abgeglichen. Alles für ungefährlich Erachtete wurde herausgefiltert, sodass nur noch Informationen über abweichende, potenziell feindliche Flugzeuge übrigblieben. Der Luftraum wurde mit einer Vielzahl spezieller Konsolen überwacht. Oben abgebildet sehen Sie eine Weapons Director Console. Zentral war ein Bildschirm, ein sogenanntes „View Scope“, der der Radartechnik entliehen wurde. Er zeigte die vom Computer berechneten Daten, also etwa eine Karte vom Umriss des Geländes und die Positionen von eventuell feindlichen Flugzeugen an. Die Soldaten, die an diesen Konsolen saßen, konnten mittels eines Zeigegeräts Objekte auf dem Bildschirm auswählen. Sie nutzten dafür eine sogenannte „Lightgun“, die sie auf den Bildschirm hielten und „abdrückten“. Die vielen Knöpfe rund um den Bildschirm erlaubten es unter anderem, auf das markierte Objekt bezogene Funktionen aufzurufen, also etwa die bisherige Route des Flugobjektes anzuzeigen, oder die aktuelle Route virtuell in die Zukunft fortzusetzen. Schlussendlich konnten auf diese Weise Ziele zum Abfangen durch Raketen vorgemerkt werden.

TX-0 und TX-2

In Zeiten des Kalten Krieges beflügelten sich zivile und militärische Forschung oft gegenseitig. Das Lincoln Lab des MIT, an dem Whirlwind gebaut wurde und das am SAGE-System beteiligt war, entwickelte 1955 bis 1956 eine experimentelle, transistorbasierte Version des Whirlwind-Computers mit dem Namen TX-0 (Transistorized Experimental Computer Zero). Mit dem System wurden neue Ansätze zur Mensch-Maschine-Interaktion exploriert. Es verfügte wie der Whirlwind über eine grafische Ausgabe mittels eines an die Radartechnik angelehnten Bildschirms. Er diente nun aber nicht mehr nur der Fehlerbehebung, sondern wurde auch als reguläre Ausgabemöglichkeit genutzt. Wie beim SAGE-System konnte ein Gerät zur räumlichen Eingabe an diesem Bildschirm genutzt werden. Im nicht-militärischen Kontext wurde dafür nun wieder der Begriff „Lightpen“ verwendet.

Der TX-0 hatte zwei direkte Nachfolger. Zum einen wurde am Lincoln Lab mit dem TX-2 ein weiterer experimenteller Rechner entwickelt und 1958 in Betrieb genommen. Aus den Erkenntnissen des TX-0 und einigen Einflüssen des TX-2 entstand aber auch der erste kommerzielle Rechner mit grafischer Ein- und Ausgabe, die PDP-1 der Firma Digital Equipment (DEC), von der später noch einmal die Rede sein wird. An den drei Systemen, dem TX-0, dem TX-2 und der PDP-1, wurde am MIT in den 1950er und 1960er Jahren an so fortschrittlichen Ideen wie Handschrifterkennung, grafischen Texteditoren, interaktiven Debuggern (Programmen zum Finden und Entfernen von Programmfehlern), Schachprogrammen und anderen frühen Projekten der sogenannten „künstlichen Intelligenz“ gearbeitet.

Eines der Projekte, das wegweisend für die Entwicklung von Nutzungsschnittstellen mit räumlich-grafischer Anzeige und Objektmanipulation war, war das „Sketchpad“-System, das 1963 von Ivan Sutherland im Rahmen seiner Doktorarbeit konzipiert und umgesetzt wurde. Das Foto unten zeigt einen Wissenschaftler des MIT am auf dem TX-2 laufenden Sketchpad-System. In der Hand hat er einen Lightpen. Mit diesem Stift konnten grafische Objekte erzeugt und manipuliert werden. Dies geschah durch Zeigen auf einen Punkt und die Betätigung einer der Tasten auf der Tastatur auf der linken Seite. Auf diese Art und Weise konnten Strecken oder Kreise aufgezogen werden. Beschränken wir uns hier beispielhaft auf Strecken. Um eine Strecke zu zeichnen, wurde der Stift zum gewünschten Startpunkt bewegt und eine Taste auf der Tastatur gedrückt. Nun wurde der Stift zum Endpunkt der Strecke bewegt. Das System zeichnete während dieses Erzeugungsprozesses fortlaufend eine gerade Linie zwischen dem Startpunkt und der aktuellen Position des Stifts auf dem Bildschirm. Ein Tastendruck fixierte auch diesen Punkt, der dann wiederum zum Ausgangspunkt der nächsten Strecke wurde. Dieser Prozess konnte abgebrochen werden, indem der Stift vom Bildschirm genommen wurde.

Alle Punkte von Strecken und den anderen geometrischen Figuren konnten auch im Nachhinein noch bearbeitet werden. Dafür musste ein Punkt zunächst ausgewählt werden. Dies geschah durch Zeigen mit dem Lightpen. Der Punkt musste dabei nicht ganz genau getroffen werden, was sich hätte schwierig gestalten können. Das System unterstützte die Auswahl eines Punkts dadurch, dass auch die unmittelbare Umgebung des Punktes dem Punkt zugeordnet wurde. Ein Auswahlcursor, der unter der Stiftposition angezeigt wurde, sprang in diesem Fall auf den Punkt, um anzuzeigen, dass sich die folgenden Manipulationen auf diesen Punkt beziehen würden. Auch wenn mit dem Stift also leicht neben den Punkt gezeigt wurde oder wenn die Abtastung nicht genau war, konnte ein Punkt präzise selektiert werden. War ein Punkt selektiert, konnte dieser durch Betätigen einer Taste in einen Verschiebezustand gebracht werden, der wiederum per Tastendruck oder durch Wegnehmen des Stiftes beendet wurde. Auch bei dieser Operation wurde während des kompletten Manipulationsvorgangs die Zeichnung laufend aktualisiert, sodass der Sketchpad-Nutzer jederzeit fortlaufend über die Konsequenzen seiner Manipulation auf dem Laufenden war.

Diese direkte Manipulation setzt eine Reihe von technischen Gegebenheiten voraus, die zur Zeit von Sketchpad noch alles andere als selbstverständlich waren.

• Objekte mussten dauerhaft und stabil sichtbar gemacht werden. Hierfür bedurfte es eines Bildschirms und einer Ansteuerung desselben, die es ermöglichen, die Zeichen oder Grafiken in so schneller Folge zur Anzeige zu bringen, dass sie für das menschliche Auge als stabile Objekte erschienen.
• Die Objekte mussten räumlich selektiert werden können. Es bedurfte also eines räumlichen Eingabegeräts, das sich auf Koordinaten am Bildschirm beziehen konnte. Diese Rolle übernahm bei Sketchpad der Lightpen des TX-2. Darüber hinaus brauchte es eine Programmierung, die diese Koordinaten den am Bildschirmort vorhandenen Objekten zuordnen konnte.
• Räumliche Manipulationen mussten umgehend in Manipulationskommandos übersetzt werden, die wiederum unverzüglich für eine Aktualisierung der Darstellung sorgten, denn nur durch die schnelle und unmittelbare Verarbeitung konnte der Eindruck einer direkten Manipulation erreicht werden. Wäre es in solchen Abläufen zu Verzögerungen gekommen, wäre ein präzises Arbeiten nicht mehr möglich gewesen. Um diesen extrem hohen Grad der Responsivität zu erreichen, entwickelte Sutherland eine performante Datenstruktur¹⁸, die in Kombination mit der hohen Rechenleistung der Maschine, die entsprechende Verarbeitungsgeschwindigkeit erlaubte.

Für Sketchpad entwickelte Sutherland neben den geschickten Datenstrukturen, die die direkte Manipulation ermöglichten, eine Vielzahl anderer spannender Konzepte, die sich auch noch in heutigen CAD-Systemen (Computer Aided Design) wiederfinden. All diese würden sicher eine umfangreiche Betrachtung verdienen, können hier aber nur exemplarisch und in aller Kürze aufgezählt werden. Beachtenswert ist etwa:

• Beim Zeichnen geometrischer Strukturen konnten Zwangsbedingungen, sogenannte „Constraints“, definiert werden. Ein Zeichner konnte zum Beispiel festlegen, dass der Winkel zwischen zwei Strecken neunzig Grad betragen muss, dass zwei Strecken gleich lang sein sollen oder dass Linienführungen parallel zueinander verlaufen müssen.
• Sketchpad bot seinen Nutzern nicht nur mehrere virtuelle Zeichenblätter, zwischen denen umgeschaltet werden konnten. Jedes dieser Zeichenblätter war zudem noch erheblich größer als die Darstellung auf dem Bildschirm. Sketchpad erlaubte es, den sichtbaren Ausschnitt zu verschieben und die Granularität der Anzeige zu verändern, also zu zoomen.
• Bei Sketchpad konnten Objekte aus Teilobjekten zusammengesetzt werden. Ein auf einem der virtuellen Zeichenblätter erzeugtes Objekt konnte in ein anderes Blatt in beliebiger Größe und Rotation eingefügt werden. Die auf diese Art eingefügten Objekte waren keine Kopien, sondern Referenzen auf das Ursprungsobjekt. Änderungen an einem der Teilobjekte wurden somit automatisch in alle zusammengesetzten Objekte übernommen. Ein Sketchpad-Nutzer konnte zum Beispiel auf einem Zeichenblatt ein Fenster zeichnen, auf dem zweiten eine Tür und auf dem dritten ein Haus. Für das Haus verwendete er die vorher gestalteten Komponenten. Kehrte er nun zum Zeichenblatt der Tür zurück und verfeinerte die Darstellung durch Hinzufügen eines Schlosses und einer Klinke, hatte auch das Haus auf dem dritten Blatt ein Schloss und eine Klinke in seiner Tür.

Das Vermächtnis von SAGE, Sketchpad und Co.

Die technischen Gegebenheiten des TX-2, die eine Software wie Sketchpad ermöglichten, waren zum damaligen Zeitpunkt herausragend. Es handelte sich um ein experimentelles System, auf dem genau solche Versuche durchgeführt werden konnten. Der große Rest der Computerwelt war noch lange Zeit ganz anders als diese Rechner mit ihrer direkten Nutzerinteraktion.

Die Entwicklung vom Whirlwind über SAGE und TX-0 zum TX-2 und entsprechender innovativer Software führte 1959 zur Entwicklung der PDP-1¹⁹, dem ersten Minicomputer, den man käuflich erwerben konnte. Das Foto oben zeigt eine voll ausgestattete PDP-1. Der eigentliche Computer ist das schrankartige Gebilde auf der linken Seite. Im unteren Bereich des Rechners sehen Sie das Bedienfeld zur Steuerung. Darüber befand sich ein Lochstreifenleser. DEC verwendete Lochstreifen mit einer speziellen Faltung. Sie sehen einige dieser Lochstreifen in der Halterung über dem Leser. Ebenso wie beim TX-0 und dem TX-2 stand bei der PDP-1 die Interaktion im Fokus. Ein- und Ausgaben erfolgten also nicht nur über das Bedien-Panel, sondern auch über eine angeschlossene elektrische Schreibmaschine oder über Bildschirm und Lightpen. Sie sehen beides rechts im Bild. Auch hier wurde wieder auf die bewährte Technik aus dem Radarbereich zurückgegriffen. Mit 53 Exemplaren war die PDP-1 noch kein wirklich viel verkaufter Rechner. Mit einem Preis von 120.000 Dollar (umgerechnet auf 2021 etwa 1,1 Million Dollar) war der Rechner auch nicht gerade erschwinglich. Das sollte sich durch die von der PDP-1 eröffnete neuen Geräteklasse der Minicomputer aber ändern. Die PDP-8, die Sie im nächsten Kapitel kennenlernen, war eine der erfolgreichsten Vertreterinnen dieser Geräteklasse, deren Eigenschaften ein wichtiger Schritt in Richtung Personal Computer waren.

Minicomputer

Minicomputer sind eine in der populären Computergeschichte mitunter übersehene Geräteklasse. In der vom ZDF produzierten deutschen Version der amerikanischen Dokumentation „Triumph of the Nerds“ mit dem Namen „Die kurze Geschichte des PCs“ wird im Zusammenhang mit dem „ersten PC“, dem Altair 8800, den Sie im nächsten Kapitel kennenlernen werden, behauptet: „Zuvor hatten Computer ganze Räume gefüllt, versteckt in Großkonzernen, Behörden oder Instituten.“ Natürlich stimmt es, dass die meisten Menschen vor dem Aufkommen der Personal Computer Ende der 1970er Jahre nicht direkt mit Computern in Kontakt kamen und schon gar keinen Computer ihr Eigen nennen konnten, aber dass Computer vor dem PC immer ganze Räume füllten, ist eben nicht wahr. Relativ kleine Computer gab es schon fünfzehn bis zwanzig Jahre vorher. Selbst der LGP-30 von 1956, den Sie im Kapitel „Frühe Echtzeitsysteme“ kennengelernt haben und die PDP-1 von 1960 aus dem vorangehenden Kapitel waren bereits recht kompakte Rechner.

Ein anderer interessanter und sehr kompakter Rechner entstand Anfang der 1960er Jahre ebenfalls am Lincoln Lab des MIT. Der oben abgebildete Library Instrument Computer, kurz LINC, war ein schrankgroßer Computer, unter dem Rollen angebracht waren. Der Computer wurde dadurch mobil und konnte in einem Labor immer an die Stelle gebracht werden, an der er gerade gebraucht wurde. Auch sonst war der Computer sehr auf Laborbedürfnisse zugeschnitten. Das betraf schon die Recheneinheit selbst, die beim LINC über eine Fließkomma-Recheneinheit verfügte. In der Praxis bedeutete das, dass mit dem LINC gut mit Zahlen mit vielen Nachkommastellen gerechnet werden konnte. Nicht bei allen Computern war das der Fall und oft war es auch nicht von Nöten. In der Buchhaltung und bei der Flugbuchung beispielsweise kam man über die zwei Nachkommastellen für Pfennig- oder Centbeträge in der Regel nicht hinaus. Wenn es im Labor jedoch um genaue Messwerte ging, mussten diese natürlich auch im Computer gespeichert und verarbeitet werden können. Bemerkenswert war der Rechner durchaus auch was seine Nutzungsschnittstelle anging. Interessant war bereits das fest zum System gehörende Bandlaufwerk mit der sogenannten LINCTape-Technologie, die später von der Firma Digital Equipment Corporation (DEC) unter dem Namen DECTape auch in anderen Minicomputern verwendet wurde. Sie sehen zwei LINCTape-Laufwerke auf dem Foto rechts auf dem Tisch. Im Gegensatz zu Bändern von Großrechnern, bei denen es in erster Linie auf hohe Lese- und Schreibgeschwindigkeit ankam, die Daten auf den Bändern aber nicht wieder verändert wurden, wurde das DECTape als System mit wahlfreiem Zugriff gestaltet. Ein DECTape verfügte über ein Datei-Inhaltsverzeichnis und damit über Dateien, die per Namen angesprochen und manipuliert werden konnten. Eine ausgeklügelte Fehlerkorrektur sorgte dafür, dass die Bänder nicht nur einigermaßen schnell im Zugriff, sondern auch sehr ausfallsicher waren.

Für einen Laborrechner besonders wichtig war die Möglichkeit, analoge Signale in Form von Spannungen direkt verarbeiten und auch analoge Ausgabesignale erzeugen zu können. Auch in der Hardware-Schnittstelle befanden sich analoge Komponenten. Eingabewerte konnten nicht nur per Tastatur eingegeben, sondern auch mit Drehknöpfen eingestellt werden. Neben der Bedienung per elektrischer Schreibmaschine konnte der LINC auch per Tastatur und Bildschirm genutzt werden. Tastatur und Bildschirm sehen Sie auf dem Foto links auf dem Tisch. Ein zentrales und sehr interessantes Programm war hier ein Screen Editor für Programme, die mit ihm auf dem Bildschirm als Text ausgegeben und mit Hilfe der Tastatur bearbeitet werden konnten.

Das LINC-Projekt wurde von der Firma Digital Equipment weitergeführt, die die Technik mit eigenen Rechnern kombinierte und einzelne Komponenten auch in Minicomputer mit weniger direkter Ausrichtung auf den Laborbetrieb integrierte. Der Inbegriff des Minicomputers schlechthin war DECs PDP-8. Die erste Version dieses Rechners sehen Sie rechts abgebildet. Es handelte sich um einen der ersten Computer, die auf einem Schreibtisch Platz fanden, wenn man von kleinen Rechnern für reine Schulungszwecke mal absieht. Der Computer kostete im Jahr 1965 18.500 Dollar, was in heutiger Kaufkraft (2021) etwa 157.500 Dollar entspricht. Im Vergleich zu Großrechnern der damaligen Zeit war das eine sehr günstige Anschaffung. Mit Verbesserungen in der Transistor- und später in der Mikrochip-Technologie wurden im Laufe der Jahre viele Versionen dieses Computers hergestellt. Bereits im Folgejahr folgte eine funktionsidentische, aber sehr langsame PDP-8/S, die der erste ernstzunehmende Computer mit Kosten unter 10.000 Dollar war. Die sehr verbreitete PDP-8/E aus dem Jahr 1970 kostete dann sogar nur noch 6.500 Dollar.

Die PDP-8-Versionen nach der Urversion waren erheblich kleiner, als das hier abgebildete Gerät. Die komplette Technik konnte in den unteren Kasten eingebaut werden. Der große Aufbau oben war nicht mehr notwendig. Markant für alle Versionen der PDP-8 war das Front-Panel mit seinen Lämpchen und Schaltern, mit denen Werte in den Speicher eingegeben und ausgelesen sowie die Operationen des Geräts gesteuert werden konnten. Über ebendiese Schalter konnte das Gerät programmiert werden. Programmieren über das Front-Panel bedeutete, dass ein Programm Bitfolge für Bitfolge in den Speicher eingegeben wurde. War dies geschehen, konnte der Programmzähler auf die Startadresse gesetzt und das Programm gestartet werden. Natürlich blieb diese Programmiermöglichkeit nicht die einzige. War etwa ein Lochstreifenleser oder ein Leser für DECTape angeschlossen, musste im Zweifelsfalle nur noch ein kleiner Loader von Hand eingegeben werden. Das eigentliche Programm wurde dann vom Medium nachgeladen. In der Praxis der PDP-8-Nutzung mussten relativ selten Programme per Schalter eingegeben werden, denn wenn sie erst einmal eingegeben waren, blieben sie auch nach dem Ausschalten des Computers erhalten. Dass dies so war, lag an der Speichertechnologie, die die PDP-8 verwendete. Wir haben im Zusammenhang mit der IBM 305 RAMAC im Kapitel Frühe Echtzeitsysteme bereits Magnettrommeln als persistenten Arbeitsspeicher kennengelernt. Diese Trommeln waren allerdings klobig und in Bezug auf die Speicherkapazität ziemlich beschränkt. Zudem war die Technologie sehr langsam. Bei der PDP-8 wurde daher eine andere Technologie gewählt.

Der Arbeitsspeicher der PDP-8 war ein Magnetkernspeicher. Ein solcher Speicher besteht aus Feldern mit kleinen Eisenringen, die auf Drähte aufgefädelt sind. Ein diagonal durchgezogener Draht dient dem Auslesen des Speichers. Jeder Eisenring kann individuell magnetisiert werden. Da es zwei verschiedene Möglichkeiten gibt, diese Magnetisierung vorzunehmen, zwei mögliche Polarisierungen, ergeben sich zwei mögliche Speicherwerte, entsprechend einer 1 oder einer 0, also einem Bit. Wenn beim Schreiben eines Bits dieses Bit „kippt“, wird im Lesedraht – dem diagonalen Draht – eine Spannung induziert. Ein Bit wird also dadurch gelesen, dass versucht wird, es zu setzen. Das Auslesen des Speichers zerstörte also die gespeicherten Daten. Um die Information zu erhalten, musste der Bitwert nach dem Lesen also neu gespeichert werden. Ein Magnetkernspeicher war schnell, aber vor allem teuer, denn die Ringe wurden per Hand aufgefädelt. Sein großer Vorteil war, dass er wie die Magnettrommel auf Magnetismus basierte und die Speicherhaltung daher nicht auf Strom angewiesen war. Der Speicher behielt seine Information ohne anliegende Spannung. Die Grundausstattung der PDP-8 verfügte über einen Speicher von 4.096 12-Bit-Worten. Bei einer Zeichencodierung von 6 Bit bedeutete das, dass 8.192 Zeichen im Speicher Platz fanden. Durch Hinzufügen eines Speichererweiterungscontrollers konnte der Speicher bis auf 32.768 Worte erweitert werden.

Ab dem Jahr 1968 war für die PDP-8 eine einfache Programmiersprache namens FOCAL (Formulating On-Line Calculations in Algebraic Language) verfügbar. Die Sprache war in etwa mit BASIC vergleichbar, hatte gegenüber dieser aber einige Vorteile. Das folgende Beispiel eines FOCAL-Programms findet sich in einer Werbebroschüre von DEC aus dem Jahr 1969²⁰.

01.10 ASK "HOW MUCH MONEY DO YOU WANT TO BORROW ?",PRINCIPAL
01.20 ASK "FOR HOW MANY YEARS ?",TERM
01.30 FOR RATE=4.0,.5,10;DO 2.0
01.40 QUIT

02.10 SET INTEREST=PRINCIPAL*(RATE/100)*TERM
02.20 TYPE "RATE",RATE,"   ","INTEREST",INTEREST,!

Ein hier sichtbarer Unterschied zu BASIC ist, neben unterschiedlichen Schlüsselworten wie ASK statt INPUT und TYPE statt PRINT, die Unterstützung von Blöcken. Sie zeigen sich in der Zeilennummerierung. Dieses einfache Beispiel hat zwei Blöcke. Die Zeilen des ersten Blocks beginnen mit „01.“, die zweiten mit „02.“ Ein Block kann als Ganzes referenziert werden. Das geschieht hier in Zeile 01.30. Es handelt sich bei der Zeile um eine Schleife, die die Variable RATE von 4 bis 10 in Schritten von 0.5 hochzählt. Der eigentliche Schleifenrumpf, also die Befehle, die mehrfach ausgeführt werden sollen, folgt im Beispiel aber nicht direkt an Ort und Stelle, wie es bei BASIC notwendig wäre. Stattdessen wird für jede Iteration DO 2.0 aufgerufen, also der zweite Block ausgeführt. Wird das Programm gestartet, sieht das Ergebnis etwa folgendermaßen aus:

HOW MUCH MONEY DO YOU WANT TO BORROW ?:100
FOR HOW MANY YEARS ?:5
RATE=    4.0000   INTEREST=   20.0000
RATE=    4.5000   INTEREST=   22.5000
RATE=    5.0000   INTEREST=   25.0000
RATE=    5.5000   INTEREST=   27.5000
RATE=    6.0000   INTEREST=   30.0000
RATE=    6.5000   INTEREST=   32.5000
RATE=    7.0000   INTEREST=   35.0000
RATE=    7.5000   INTEREST=   37.5000
RATE=    8.0000   INTEREST=   40.0000
RATE=    8.5000   INTEREST=   42.5000
RATE=    9.0000   INTEREST=   45.0000
RATE=    9.5000   INTEREST=   47.5000
RATE=   10.0000   INTEREST=   50.0000
*

Interaktive Programmierung in FOCAL ist natürlich nicht die einzige Art, wie man die PDP-8 verwenden kann. Eine Reihe von Betriebssystemen wurden für den Rechner entwickelt. Am beliebtesten und verbreitetsten unter ihnen war das System OS/8. Es war stark inspiriert vom Betriebssystem TOPS-10 für DECs Großrechnerreihe PDP-10. TOPS-10 war ein Time-Sharing-Betriebssystem, das für seine recht einfache Bedienweise geschätzt wurde. Für die erheblich einfachere und schlechter ausgestattete PDP-8 konnte und musste das System aber natürlich abgespeckt werden. Es handelte sich bei der PDP-8 ja eben nicht um einen Rechner, der gut für Time-Sharing geeignet war. In OS/8 verwendete folglich nur ein Nutzer zu einer Zeit das System. Es brauchte dementsprechend keine time-sharing-typischen Verwaltungsoperationen, keine Nutzerverwaltung, keine Quotas und auch keine komplexe Verwaltung für externe Massenspeicher. Übrig blieb ein einfaches Betriebssystem, das über einen Kommandozeilen-Interpreter verfügte, ein integriertes Hilfesystem hatte und sich Kommandozeilen-Parameter früherer Aufrufe eines Programms merkte. Letzteres war und ist durchaus etwas Besonderes! Der Befehl DIR beispielsweise gab bei OS/8 das Inhaltsverzeichnis der Dateien auf einem DECTape aus. DIR /A /N zeigt die Dateien in alphabetischer Sortierung mit lesbarem Änderungsdatum an. Hatte man diese Parameter einmal eingegeben, wurde fortan auch bei einem einfachen DIR das Verzeichnis auf die beschriebene Art angegeben. Die Parameter wurden automatisch wieder angewandt. Diese Funktionalität war besonders praktisch, wenn man etwa zwischen einem Editor und einem Compiler hin- und herwechselte. Nur einmal mussten dann Dateinamen und Parameter angegeben werden. Danach reichte das Aufrufen des Editors und des Compilers ohne die Zusatzinformationen, denn die passenden Parameter und Dateinamen wurden automatisch ergänzt.

Das Betriebssystem OS/8 und sein großer Bruder TOPS-10 waren Inspiration für das Betriebssystem CP/M, dem ersten verbreiteten Betriebssystem für Personal Computer. Dessen Entwickler Gary Kildall arbeitete selbst mit den DEC-Betriebssystemen und nutzte sie zur Entwicklung seines CP/M. Die Nutzungsschnittstelle von CP/M war ihrerseits die Vorlage für Microsofts MS-DOS, dessen Kommandozeilen-Interpreter sich, kaum verändert, immer noch in Windows findet. Den Befehl dir, mit dem Sie heute noch in der Eingabeaufforderung von Windows ein Verzeichnis-Listing ausgeben können, können Sie über MS-DOS, CP/M und OS/8 bis zu TOPS-10 zurückverfolgen.

Persönliche Computer

Mit den Minicomputern wie der PDP-8 sind wir den Personal Computern schon ziemlich nahegekommen. Manch später Minicomputer mutet wie ein Personal Computer an. Unten abgebildet sehen Sie ein VT78 von DEC. Dieses Gerät kam 1977 auf den Markt. Es ist technisch eine inzwischen auf Chip-Größe geschrumpfte PDP-8, die in ein VT52-Terminal eingebaut wurde. Auf diesem kompakten Gerät lief eine angepasste Version von OS/8 und das Textverarbeitungsprogramm WPS-8 von DEC. Der Rechner basierte auf der Architektur eines bewährten Minicomputers und eines ebenso bewährten VT52-Terminals. Handelt es sich also um einen kompakten Minicomputer? Um ein intelligentes Terminal? Oder ist das schon ein Personal Computer?

Sie sehen, dass es wieder einmal gar nicht einfach ist, zu sagen, was einen Personal Computer ausmacht. Der Begriff „Personal Computer“, vor allem in seiner Abkürzung PC, steht heute meist für den IBM 5150, also den IBM Personal Computer von 1981, und seine direkten Nachfolger und Kompatiblen. Die damals von IBM auf den Markt gebrachte Architektur ist wohl eine der beständigsten Computer-Architekturen überhaupt. Nahezu alle Desktop-PCs und Laptops, die heute, im Jahre 2021, genutzt werden, sind Nachfolger dieses Rechners und sind noch heute mit damaligen Rechnern und mit ihrer Software grundsätzlich kompatibel¹. Tatsächlich ist die IBM-PC-Architektur mit ihrem zum Intel 8086 kompatiblen Prozessor allerdings bei Weitem nicht mehr die verbreitetste Computer-Architektur. Es gibt inzwischen weit mehr Smartphones und Tablets als PCs und Laptops, und diese Geräte basieren auf einer anderen technischen Grundlage – doch zu den Smart-Geräten kommen wir erst im nächsten Abschnitt des Buches.

Hier soll es zunächst um den Personal Computer gehen, aber natürlich nicht nur um den IBM PC, denn den Begriff „Personal Computer“ so einzuschränken, würde uns nicht erlauben, die Entwicklungslinien zu verfolgen. Es gab erheblich mehr, was seinerzeit „Personal Computer“, „Heimcomputer“ oder auch „Tischcomputer“ genannt wurde. Dass die Firma IBM auf den Gedanken kam, einen PC herauszubringen und dass dann später Microsoft darauf kam, eine Arbeitsumgebung mit dem Namen „Windows“ zu kreieren, hat eine Vorgeschichte, die es zu erkunden gilt.

Es bleibt nun aber immer noch die Frage, was denn nun ein Personal Computer ist. Wie verhält sich der Personal Computer zum Minicomputer? Zunächst gibt es eine große Gemeinsamkeit: Ein Personal Computer ist wie ein Minicomputer eine lokale Ressource, verfügt also über einen lokalen Speicher und lokale Ein- und Ausgabegeräte. Auch wenn man zur Bedienung eines Minicomputers oder eines frühen Personal Computers vielleicht einen Fernschreiber oder ein Terminal benutzte, stand der Computer in der Regel nur wenige Meter neben dem Terminal und nicht etwa weit entfernt in einem Rechenzentrum. Eine Konsequenz dieser lokalen Ressourcen und der lokalen Nutzung war, dass der Computer nicht mehrere Nutzer im Time-Sharing bediente, sondern zu jedem Zeitpunkt von nur einem Nutzer bedient wurde².

Aufgrund der genannten ähnlichen Charakteristika von Personal Computer und Minicomputer, werden Rechner wie die PDP-8 und der LINC von manchen Enthusiasten als „frühe Personal Computer“ bezeichnet. Vergleicht man Minicomputer zu ihrer Hochzeit Anfang der 1970er mit Personal Computern ab 1975, kann man aber durchaus Unterschiede ausmachen. Minicomputer entstanden zur Zeit transistorbasierter Rechner, aber noch vor dem Aufkommen integrierter Schaltkreise und vor allem vor dem Aufkommen des Mikroprozessors. Viele spätere Minicomputer waren zwar mehr und mehr miniaturisiert und verwendeten auch Mikrochips, verblieben aber noch längere Zeit bei Recheneinheiten, die aus mehreren Komponenten bestanden. Personal Computer hingegen entstanden zeitgleich mit dem Aufkommen der ersten Mikroprozessoren. Mit der Miniaturisierung, der Massenherstellung von Komponenten und der Bastel-Anstrengungen früher PC-Pioniere gelang es, Computer zu erheblich niedrigeren Preisen herzustellen. Ein weiterer, wichtiger Unterschied zwischen einem Minicomputer und einem Personal Computer liegt im Namen. Natürlich sind Namen Schall und Rauch, doch ist das „Personal“ in Personal Computer nicht unberechtigt. Ein Personal Computer ist in den meisten Fällen einem Nutzer oder einer Familie zugeordnet. Man besitzt seinen eigenen Personal Computer oder teilt sich einen in der Familie, und selbst im Büro steht einem ein Personal Computer individuell zur Verfügung, auch wenn er einem nicht direkt gehören mag. Minicomputer hingegen waren meist nicht einer Person zugeordnet, sondern gehörten eher zur Einrichtung einer Werkstatt oder eines Labors.

Verwandt mit den Personal Computern sind auch die Rechner, die „Workstations“ genannt werden. Hier ist eine Abgrenzung noch schwieriger zu treffen. Sie liegt vor allem in den Kosten und damit in der Leistungsfähigkeit. Während Personal Computer im Heimbereich, in der Schule und im Büroumfeld anzutreffen sind, werden die leistungsfähigeren Workstations eher im technisch-wissenschaftlichen Umfeld eingesetzt. Typische Workstations wie die Rechner von Sun Microsystems schauen wir uns im Rahmen dieser Geschichtserzählung nicht an. Im Kapitel „Schreibtische und Fenster“ werfen wir aber einen Blick auf die Rechner Alto und Star von Xerox, die man wohl dieser Geräteklasse zuordnen könnte.

In der folgenden Tabelle sehen Sie typische Charakteristiken jeder Geräteklasse inklusive eines typischen Vertreters aufgeführt. Den Personal Computer habe ich hier in Hobby-Computer, Heim-Computer und Büro-Computer aufgeteilt. Sie werden im Verlaufe des Kapitels sehen, dass es hier durchaus Unterschiede gab, was Leistungsfähigkeit, Ausstattung und auch die Nutzungsschnittstelle anging.

Auf die Frage, was einen Personal Computer in der Geschichte der Nutzungsschnittstelle ausmacht, kommen wir im Kapitel „Kleine Computer im Büro“ nochmals zurück. Sie werden dann sehen, dass, vielleicht wichtiger als die oben besprochenen Unterschiede, die Software und ihre Ausnutzung der Potenziale interaktiver Nutzungsschnittstellen den kleinen, aber feinen Unterschied ausmacht, der die Personal Computer von den Minicomputern qualitativ abhebt.

Auf zum Altair!

Ebenso wie es ein Bedürfnis vieler zu sein scheint, den ersten Computer überhaupt benennen zu können, wird auch der erste Personal Computer vielfach gesucht und benannt. Hier einen Ersten zu finden, ist aber fast noch müßiger und noch aussichtsloser, als beim Computer an sich, denn natürlich war es auch hier nicht so, dass der Blitz in jemanden fuhr, der dann mit einem Personal Computer etwas völlig Neues, noch nie Dagewesenes ersonnen hätte, ohne Anleihen bei bisherigen Computern zu nehmen. Ich stelle Ihnen in diesem Kapitel mit dem Altair 8800 den Computer vor, dem die Ehre, der erste Personal Computer gewesen zu sein, vielleicht am häufigsten zugeschrieben wird. Sie werden sehen, dass Funktions- und Arbeitsweisen bestehender Computer, vor allem der populären Minicomputer, bei der Konzeption des Altair eindeutig Pate standen.

Mit Minicomputern wie der PDP-8 aus dem vorhergehenden Kapitel wurden Computer relativ klein und günstig und waren so erstmals auch für kleine Organisationen erschwinglich. Für eine Firma mit einem Elektrolabor etwa war eine PDP-8/E von 1970 mit ihren 6.800 Dollar (2021: 47.000 Dollar) durchaus preisgünstig. Für Privatleute sah das aber anders aus, zudem ja auch noch Kosten für Terminals und Speichergeräte, etwa ein DECTape-Gerät, hinzukamen. Computer waren bis etwa Mitte der 1970er Jahre daher etwas, das es in Firmen, im Militär, in Universitäten und Hochschulen gab und von dem Privatleute vielleicht etwas gehört hatten, was ihnen aber nicht direkt zugänglich war. Computer umgab dadurch durchaus eine etwas mystische Aura. Gerade für eher Linksdenkende gehörten sie zum militärisch-industriellen Komplex. Das Bedürfnis vieler Hobbybastler, sich ihren eigenen Computer für zu Hause zu bauen, hat so neben dem reinen Interesse an der Technik durchaus auch einen politischen Aspekt. Sich seinen eigenen Computer zu bauen statt der Computertechnik nur ausgeliefert zu sein, kann man regelrecht als einen Akt der Befreiung und Selbstbestimmung interpretieren. Aus dieser Stimmungslage entstanden viele der amerikanischen Computerpioniere des Silicon Valley. Ein entsprechender Duktus findet sich noch heute oft in ihrer Außendarstellung, was eine gewisse Ironie innehat, denn die Rolle von Firmen wie Apple hat sich natürlich im Laufe der Jahrzehnte stark gewandelt. Werden wir aber nicht politisch und greifen wir der Geschichte nicht vor, sondern kommen wieder zur Situation in den 1970er Jahren, in der die ersten Personal Computer aufkamen.

Anfang der 1970er Jahre brachte die Firma Intel den ersten vollintegrierten Mikroprozessor auf den Markt. Der Prozessor mit der Bezeichnung 4004 und der ein Jahr später erschienene 8008 kamen zum Beispiel in Taschenrechnern, Tisch-Rechenmaschinen und teils auch in frühen Videospielen zum Einsatz. Auch Hobbybastler fanden Interesse an den Prozessoren und konstruierten sich eigene kleine, experimentelle Computersysteme auf Basis dieser Prozessoren. Für wirklich ernsthafte Rechenanlagen waren sie aber nicht geeignet. Das änderte sich im Jahr 1974 mit der Vorstellung des Intel 8080, einem 8-Bit-Mikroprozessor mit einem 16-Bit-Datenbus, der 64 KB Arbeitsspeicher adressieren konnte.

Angaben in Bit, hier 8-Bit, haben Sie in Bezug auf einen Prozessor sicher schon einmal gehört. Aber was bedeutet das eigentlich? Ich sollte an dieser Stelle vielleicht einige Begriffe und Sprechweisen erklären.

8-Bit Prozessor?

Dass ein Prozessor ein 8-Bit-Prozessor ist, bedeutet, dass er darauf ausgelegt ist, mit Folgen von je 8 Bit zu operieren. So ein Prozessor kann zum Beispiel zwei Zahlen, die je in 8 Bit binär codiert sind, in einem Schritt addieren, weil er über einen eingebauten 8-Bit-Addierer verfügt. Mit 8 Bit lassen sich nur 256 verschiedene Werte darstellen, etwa die von 0 bis 255. Die Konsequenz daraus ist aber nicht, dass man mit einem solchen Prozessor nur kleine Zahlen verarbeiten könnte. Es ist ohne weiteres möglich, viel größere Zahlen, die mehr Bits benötigen, zu verarbeiten. Das macht es aber komplizierter. Sie können sich das klarmachen, indem Sie einen Prozessor annehmen, der im normalen Zehnersystem rechnet. Das kann man es sich etwas leichter vorstellen, als die für den Menschen unhandlichen Einsen und Nullen im Binärsystem. Unser imaginärer Prozessor hat die Fähigkeit, zwei Zahlen zu addieren, kann allerdings immer nur drei Stellen einer Zahl gleichzeitig verarbeiten. 54 + 92 können sie ohne Probleme ausrechnen, doch was machen Sie bei 12742 + 7524? Ganz einfach, Sie rechnen zunächst mal nur mit den hinteren drei Stellen. 742 + 524 = 1266. Dieses Ergebnis ist mit 4 Stellen zu lang! Sie können nur die 266 „abspeichern“ und haben einen Überlauf von 1. Also „Eins im Sinn“, wie man in der Schule so schön sagte. Diese 1 müssen Sie mitverarbeiten, wenn Sie die vorderen Teile der Zahl verrechnen. Wir haben nun für den vorderen Teil also 1 + 12 + 7 zu berechnen. Diese Berechnung müssen Sie in zwei Schritten durchführen, denn der Prozessor kann immer nur zwei Zahlen addieren. Also: 1 + 12 = 13 und 13 + 7 = 20. Das Ergebnis des vorderen Ergebnisteils ist also 20, das des hinteren 266. Das Gesamtergebnis unserer Addition ist also 20266. Wie Sie sehen, konnten wir die Berechnung durchführen, doch statt einmal zu addieren, mussten wir gleich dreimal ran. Hinzu kam noch Aufwand für die Koordination des Prozesses.

Adress-Bus?

Auch der Adressraum des Arbeitsspeichers eines Systems wird in Bit angegeben. Was bedeutet die Bit-Zahl hier? Stellen Sie sich den Arbeitsspeicher eines Computers der Einfachheit halber wie einen Schrank mit ganz vielen Schubladen vor. In jede Schublade können Sie eine bestimmte Zahl von Bits hineinlegen. Diese Bitfolge nennt man ein „Wort“. Wie lang ein solches Wort ist, wie viel Bits es also enthält, hat sich im Laufe der Computergeschichte oft geändert. Nehmen wir hier der Ära entsprechend wieder einmal 8 Bit. 8 Bit werden üblicherweise auch ein Byte genannt. Die Größe des Arbeitsspeichers in Bytes ist nun die Anzahl der Schubladen des Schranks. Ein Prozessor muss dem Arbeitsspeicher im Computer mitteilen können, welche Schublade er braucht. Stellen Sie sich das so vor, dass an jeder Schublade eine Zahl steht. Ein Programm kann also das Byte aus Schublade Nummer 245 anfordern oder einen neuen Byte-Wert dort hineinschreiben. Die Auswahl der Schubladen geschieht über den sogenannten Adress-Bus, der einfach nur aus einer Reihe von Stromleitungen besteht. Die Frage ist nun, wie viele Stromleitungen benötigt werden. Würde der Adress-Bus aus nur einer einzigen Leitung bestehen, könnte nur die eine Speicherzelle – wenn keine Spannung auf der Leitung ist – oder die andere – wenn Spannung auf der Leitung ist – angesprochen werden. Es gäbe also nur zwei verschiedene Speicherstellen (0 und 1), die angesprochen werden könnten. Das Resultat wäre ein Arbeitsspeicher von 2 Byte. Bei zwei Leitungen wären es schon 2²=4 Speicherstellen (00, 01, 10, 11), bei drei Leitungen 2³=8 Byte und so weiter. Bestünde der Adress-Bus aus 8 Leitungen, man spricht dann von einer Busbreite von 8 Bit, könnten 2⁸=256 verschiedene Speicherstellen direkt angesprochen werden. Damit ließe sich ein Taschenrechner bauen, aber für einen ernsthaften Computer reicht das natürlich nicht. Verwendet man nun wie beim Intel 8080 16-Bit-lange Adressen, sind es 2¹⁶ Bytes, also 65.536 Bytes oder auch 64 KB³. Ein Prozessor mit einem 16-Bit Adressraum kann also 64 KB Speicher direkt adressieren. Mit Techniken wie Bank Switching kann man aber durchaus auch mehr Speicher ansprechen.

Bank Switching?

Die Beschränkung auf eine Adress-Bus-Breite von 16 Bit bedeutet nicht, dass man mit einem solchen Prozessor auch wirklich zwangsweise nur 64 KB nutzen könnte, denn es gibt Techniken, mit denen man die Speichergröße prinzipiell beliebig erweitern kann. Kommen wir nochmal zum Schrank mit den Schubladen zurück und erweitern das Bild ein wenig. Stellen Sie sich eine Wand vor. An diese Wand stellen Sie direkt nebeneinander Schränke mit Schubladen, bis die Wand voll ist. Die Schubladen bilden nach wie vor die direkt adressierbaren Speicherzellen des Systems. Sie können immer auf die Schubladen in den Schränken an der Wand zugreifen. Wenn Sie nun mehr Daten speichern müssen, können Sie sich behelfen, indem Sie ganze Teilschränke austauschen. Sie haben nebenan eine große Lagerhalle mit ganz vielen Schränken und können bei Bedarf einen oder mehrere der Teilschränke von der Wand ins Lager bringen und dafür andere Schränke aus dem Lager holen und an die Zugriffswand stellen. Diese Technik nennt man „Bank-Switching“. Commodores C128 von 1985 ist ein Beispiel für einen Rechner, der diese Technik verwendete, um trotz eines 16-Bit-Adress-Busses 128 KB Speicher zu verwalten. Der Nachteil des Bank-Switchings ist natürlich der Zusatzaufwand. Sie haben zwar viel Speicher, aber können Teile davon nicht direkt adressieren, sondern müssen erst immer dafür sorgen, dass der richtige Schrank an der Wand steht. Dadurch kann die Programmierung komplex werden, je nachdem wie maschinennah Sie programmieren. In jedem Fall benötigt es immer Zeit, die Speicherbänke auszutauschen.

Intels frühe Prozessoren 8008 und 8080 waren 8-Bit-Prozessoren. Der 8008 hatte einen 14-Bit-Adress-Bus, konnte also 16 KB Speicher direkt adressieren. Beim 8080 waren es, wie oben schon erwähnt, 16 Bit Busbreite und somit 64 KB direkt adressierbarer Arbeitsspeicher. Das war im Vergleich zu Großrechnern wenig, im Vergleich zu Minicomputern aber gar nicht mal schlecht. Eine PDP-8 konnte selbst in ihrer größten Ausbaustufe keine 64 KB adressieren. Das Maximum waren hier 32-K-Worte à 12 Bit, was rein rechnerisch 48 KB Speicher entspricht. Diese Umrechnung hinkt allerdings in der Praxis, denn wenn Sie 32.768 Speicherstellen mit je 12 Bits haben, sind das zwar genau so viele Bits wie 49.152 Speicherstellen à 8 Bit, also 48 KB, aber natürlich können Sie sie nicht so nutzen, denn die Bits sind ja nicht byte-weise ansprechbar und stehen nicht in dieser „Stückelung“ zur Verfügung.

Der Altair 8800 – Die Wunderkiste

„Bastel’ dir deinen eigenen Computer“ war ein beliebtes Thema von (US-amerikanischen) Elektronik-Hobbyzeitschriften in der Mitte der 1970er Jahre. Bemerkenswert war etwa der 1974 in der Zeitschrift „Radio-Electronics“ vorgestellte Bastelcomputer Mark-8. Die Zeitschrift erläuterte die Funktionsweise und stellte Bauanleitungen für den auf einem Intel 8008-Prozessor basierenden Computer zur Verfügung. Man konnte den Rechner nicht komplett zusammengebaut bestellen oder gar im Laden kaufen, sondern musste selbst zum Lötkolben greifen. Das war natürlich bei Weitem nicht jedermanns Sache. Der größte Einfluss des Mark-8 war dann auch nicht der Rechner selbst, sondern dass er die Redakteure der Zeitschrift „Popular Electronics“ dazu veranlasste, im Jahr 1975 selbst einen Computer, den Altair 8800, vorzustellen.

Dieser Computer basierte auf der oben genannten, modernen 8080-CPU. Computerinteressierte konnten den Rechner bei der Firma MITS als Bausatz bestellen und selbst zusammenbauen, aber auch diejenigen, die das nicht konnten oder wollten, hatten die Möglichkeit, an den Rechner zu kommen, denn für „nur“ 621 Dollar, was nach heutiger Kaufkraft (2021) etwa 3.100 Dollar entspricht, ließ sich der Rechner komplett zusammengebaut mit Gehäuse beziehen. Für die 621 Dollar bekam man die Grundausstattung des Rechners, die ziemlich spärlich war. Der Rechner verfügte dann über keinerlei externe Speichermöglichkeit und nur über sage und schreibe 256 Byte Arbeitsspeicher. Diese sparsame Grundausstattung hinderte die Autoren bei Popular Electronics nicht daran, den Computer euphorisch zu beschreiben:

The era of the computer in every home–a favorite topic among science-fiction writers–has arrived! It’s made possible by the POPULAR ELECTRONICS/MITS Altair 8800, a full-blown computer that can hold its own against sophisticated minicomputers now on the market. And it doesn’t cost several thousand dollars.

Hier wurde also überschwänglich der Anfang einer neuen Ära beschrieben, einer Ära, die man aus Science-Fiction-Literatur kenne. Nüchterner ist dann der Vergleich des Rechners mit schon bekannten Geräten. Der Altair könne es mit den Minicomputern aufnehmen. Auf dem Titelblatt der Zeitschrift ist der Altair dann auch mit „World’s First Minicomputer Kit to Rival Commercial Models…“ angekündigt. Popular Electronics propagierten hier zwar also einen Computer für zu Hause, aber der Computer, den man dann daheim hatte, entsprach den Computern der damaligen Zeit, den Minicomputern – eben ein Minicomputer für zu Hause. Mit diesem Hintergrund erklärt sich auch das Aussehen des Computers. Aus der heutigen Erwartung, wie PCs aussehen, ist das Design des Altair sehr außergewöhnlich, nimmt man aber einen Minicomputer wie DECs PDP-8 als Maßstab, ist das Design des Altair 8800 ganz folgerichtig: Es handelt sich um eine Kiste mit einem Front-Panel, an dem sich eine Reihe von Leuchtdioden und eine ganze Menge Kippschalter befinden. Jemand, der Minicomputer und ihre Bedienung kannte, fühlte sich hier sofort zu Hause.

Der Vergleich mit der zehn Jahre älteren Architektur der PDP-8 offenbart weitere Parallelen. Auch die PDP-8 musste in ihrem Grundzustand ohne weitere angeschlossene Ein- und Ausgabegeräte über das Front-Panel bedient werden. War ein kleines Loader-Programm in den Speicher eingegeben, konnte die PDP-8 Programme von einem externen Medium, etwa von einem Lochstreifen einlesen. Der Anschluss eines Fernschreibers oder eines anderen Terminals an eine PDP-8 ermöglichte die interaktive Nutzung des Systems. DEC stellte für die PDP-8 die im vorherigen Kapitel beschriebene einfache Interpreter-Programmiersprache FOCAL bereit. Später folgte dann mit OS/8 und einigen Parallelentwicklungen der Übergang zu kommandozeilenorientierten Betriebssystemen, die von der Bedienweise an verbreitete Time-Sharing-Systeme angelehnt waren, allerdings nicht deren Komplexität aufwiesen. Nahezu die gleichen Entwicklungsschritte konnte man nun, zehn Jahre später, beim Altair 8800 nochmals nachvollziehen. Auch hier verwirklichten sich mit der Entwicklung der Nutzungsschnittstellen die Potenziale digitaler Systeme. Es lohnt sich, diese Entwicklung etwas genauer zu betrachten, denn die Produkte, die hier entstanden, waren nicht auf den Altair beschränkt, sondern waren maßgeblich für die weitere Entwicklung der Personal Computer noch bis zum heutigen Tag.

Front-Panel-Programmierung – Bits zum Anfassen

Einen taufrischen Altair 8800 dazu zu bringen, etwas Sinnvolles zu tun, war gar nicht so einfach, denn es bedeutete, den Rechner über das Front-Panel zu programmieren, Werte einzugeben und Ergebnisse abzulesen. Mit dem charakteristischen Front-Panel aus Leuchtdioden und Kippschaltern ließen sich Speicherstellen mit Werten befüllen, entsprechend auslesen, der Programmzähler setzen, das Programm starten und unterbrechen oder, zwecks Fehlersuche, in Einzelschritten ausführen. Wollte man den Altair 8800 programmieren, musste man den Maschinencode des Intel 8080 kennen und die Befehle nacheinander, Byte für Byte, über Kippschalter in den Speicher eingeben. Wenn das geschehen war, empfahl es sich, die Werte im Speicher nochmals genau zu überprüfen, denn schnell konnten sich Fehler eingeschlichen haben. War das Programm in Ordnung, setzte man den Programmzähler auf den ersten Befehl des Programms und betätigte den mit RUN beschrifteten Schalter, um das Programm ablaufen zu lassen. Wenn das Programm zu einem Ende gekommen war, oder wenn der Programmablauf unterbrochen wurde, konnte, wieder über das Front-Panel, der Inhalt des Speichers und somit auch ein eventuelles Rechenergebnis abgelesen werden.

Das folgende Programm ist eine abgewandelte Form eines Programms aus dem Operator’s Manual des Altair. Es handelt sich um ein sehr einfaches Programm, das zwei Zahlen, die in den Speicherstellen 128 und 129 gespeichert wurden, addiert und das Ergebnis in Speicherstelle 130 speichert.

00 111 010 Lade in den Akkumulator Inhalt
10 000 000 von Speicherstelle 128
00 000 000 (2. Byte der Speicherstelle, da 16 Bit pro Adresse)

01 000 111 Speichere Akkumulator in Register B

00 111 010 Lade in den Akkumulator Inhalte
10 000 001 von Speicherstelle 129
00 000 000

10 000 000 Addiere Register B zum Akkumulator

00 110 010 Speichere den Akkumulator-Inhalt
10 000 010 in Speicherzelle 130
00 000 000 

01 110 110 Halt

Das eigentliche Programm besteht hier nur aus den vorne in den Zeilen angegebenen Bitfolgen. Die dahinterstehenden Texte sind nur Kommentar und dienen Ihnen als Leser des Programms dem Verständnis. Um das Programm eingeben zu können, musste man natürlich zunächst einmal den Computer einschalten. Er befand sich dann in einem zufälligen Startzustand. Alle Speicherstellen und Register des Rechners hatten einen zufälligen Wert. Das Betätigen von RESET beseitigte diesen misslichen Zustand und setzte alle Werte auf 0. Nun wurden die Befehle nacheinander binär über die Kippschalter eingegeben und mittels der DEPOSIT-Taste oder der DEPOSIT-NEXT-Taste bestätigt. DEPOSIT NEXT war eine Bequemlichkeitsfunktion. Statt jede einzelne Adresse erst anwählen zu müssen, bevor man einen Wert speicherte, sprang DEPOSIT NEXT jeweils automatisch zur nächsten Speicheradresse, sodass die Befehle hintereinander eingegeben werden konnten. Als nächstes mussten die beiden zu addierenden Zahlen eingegeben werden. Dies ging durch Setzen der Kippschalter auf 128 (binär 10 000 000) und einem Druck auf EXAMINE. Der aktuelle Speicherinhalt, also 0, wurde jetzt dadurch angezeigt, dass keine Leuchtdiode aufleuchtete. Ein Wert konnte nun eingegeben und mit DEPOSIT NEXT gespeichert werden. Angezeigt wurde dann automatisch Speicherstelle 129. Auf die gleiche Art und Weise konnte nun hier ein Wert gespeichert werden. Da nun Programm und Daten vollständig eingegeben wurden, konnte das Programm gestartet werden. Dafür wurde der Programmzähler auf den Beginn des Programms gesetzt. Da das Programm ab der Speicheradresse 0 eingegeben wurde, musste also der Programmzähler wieder auf 0 gestellt werden, um das Programm ab dieser Adresse loslaufen lassen zu können. Dazu wurden alle Kippschalter nach unten gestellt und dann EXAMINE betätigt. Nun konnte das Programm durch Betätigen von RUN gestartet werden. Das extrem kurze Programm hatte natürlich keinerlei nennenswerte Laufzeit. Direkt nach dem Auslösen von RUN war das Programm auch schon beendet, was durch das Aufleuchten der WAIT-Leuchtdiode angezeigt wurde. Man konnte nun das Ergebnis aus der Speicherzelle 130 ablesen. Dies geschah durch Eingeben von 130 (binär 10 000 010) und einer Auslösung von EXAMINE.

Die Front-Panel-Schnittstelle des Altair 8800 war eine reine Maschinenschnittstelle. Das, was man in dieser Schnittstelle sah und eingab, war ganz direkt der Zustand der Maschine, explizit vor allem der Zustand des Speichers. Die Ausgabe entsprach den Bits in Speicherzellen, die Eingaben entsprachen genau den Bits, die in die Speicherzellen geschrieben werden sollten und die einzelnen Befehle entsprachen eins zu eins den Operationen des Prozessors. Auf diese Art und Weise, durch das Eingeben von Programmen und Daten vom Front-Panel, mag es grundsätzlich möglich gewesen sein, alle möglichen komplexen Programme in den Computer einzugeben, wirklich praktikabel war das aber natürlich nicht. Die Betriebsart eignete sich eher dafür, die Funktionsweise des Computers zu erlernen und zu verstehen, aber nicht wirklich für ernsthafte Programmierung. Hinzu kam noch, dass das Programm ja nur im Arbeitsspeicher vorlag und dieser, ganz im Gegensatz zur PDP-8 mit ihrem Magnetkernspeicher, flüchtig war. Schaltete man das Gerät aus, waren sowohl Programm als auch Daten verschwunden.

Lochstreifen – Programme von der Rolle

Natürlich war die Front-Panel-Programmierung nicht die einzige Betriebsart des Altair. Über nachrüstbare Schnittstellen ließ sich zum Beispiel ein Fernschreiber an den Computer anschließen. Wie schon Jahre zuvor bei den Minicomputern und den Time-Sharing-Systemen war auch hier wieder der Teletype ASR Model 33 ein gern verwendetes Gerät. Dieser Fernschreiber verfügte über eine Tastatur, über die Buchstaben, Zahlen und Steuerzeichen eingegeben werden konnten. Außerdem hatte er einen Druckkopf, der Buchstaben auf „endloses“ Papier druckte. Der Fernschreiber war mit einem Lochstreifenleser und einem Lochstreifenstanzer ausgestattet. Zeichen konnten damit im 8-Bit-Code auf die Lochstreifen gestanzt und auch von ihnen gelesen werden. Der Lochstreifenstanzer konnte dafür genutzt werden, die von der Gegenstelle kommenden Zeichen nicht nur auszudrucken, sondern sie auch auf einem Lochstreifen zu speichern. Der Lochstreifenleser konnte umgekehrt anstelle der direkten Tastatureingabe genutzt werden. Dieses System hatte sich für die Weiterleitung von Nachrichten bewährt und konnte nun auch für das Laden von Programmen in den Altair genutzt werden. Dass der Fernschreiber einen 8-Bit-Code nutzte, war natürlich praktisch, denn der Rechner hatte ja eine Architektur, bei der jedes Datenwort 8 Bit lang war, also jede ansprechbare Speicherstelle 8 Bit an Daten speicherte.

Mit dem Fernschreiber war es möglich, Programme vom Lochstreifen einzulesen. Dabei stellte sich allerdings ein grundlegendes Problem: Ein Altair „wusste“ schlichtweg nichts von Fernschreibern oder Lochstreifen. Er konnte nur das im Arbeitsspeicher gespeicherte Programm ausführen, aber direkt nach dem Einschalten gab es dort ja gar kein Programm. Wollte man ein Programm vom Lochstreifen lesen, musste man daher zunächst ein kleines Programm per Front-Panel in den Computer eingeben und dieses starten. Die Aufgabe dieses Programms, „Loader“ genannt, war es, Daten vom Lochstreifenleser zu lesen, in den Arbeitsspeicher des Computers zu kopieren und dann auszuführen. Dieses Programm konnte sich dann seinerseits der Fähigkeiten des Fernschreibers bedienen, also etwa Ergebnisse ausdrucken oder Nutzereingaben verarbeiten. Eine wichtige Software, die auf diese Art und Weise ausgeliefert wurde, war ihrerseits eine Programmierumgebung.

BASIC – Programmierung interaktiv

Der Anschluss eines Fernschreibers erlaubte es, am Altair eine interaktive Programmierumgebung zu nutzen, also ein Programm in dem man programmieren und das Programm ausführen und testen kann. Auch hier kann man Parallelen zur PDP-8 ausmachen. Bei dieser stand seinerzeit mit dem FOCAL-Interpreter eine solche Umgebung zur Verfügung. FOCAL-Programme wurden zwar langsam ausgeführt, doch ihre Programmierung war recht komfortabel. Für den 8080-Prozessor von Intel gab es zunächst keine vergleichbare Programmierumgebung. Es gab zwar einige Compiler für höhere Programmiersprachen, jedoch keine interaktive Programmierumgebung. Eine solche Umgebung, und damit faktisch das erste Betriebssystem für den Altair 8800, wurde von Bill Gates und Paul Allen entwickelt. Die beiden gründeten mit ein paar Mitstreitern kurze Zeit darauf die Firma Microsoft. Die von Allan und Gates hier implementierte Programmiersprache BASIC war natürlich keine Erfindung der beiden. Von den Ursprüngen von BASIC war ja bereits im Kapitel über Time-Sharing die Rede. Als die Programmiersprache in den 1960er Jahren am Dartmouth College eingeführt wurde, wurde sie von Studierenden und Angestellten des College genutzt. Diese Nutzer saßen seinerzeit vor einem Fernschreiber, genau wie beim BASIC von Microsoft am Altair. Allerdings hatten die Dartmouth-Nutzer natürlich keinen kleinen Computer neben sich stehen, sondern verbanden sich mit dem zentralen Time-Sharing-System DTSS. Der Altair war natürlich kein Time-Sharing-System⁴ und im Gegensatz zum DTSS wurde nun kein BASIC-Compiler, sondern ein Interpreter⁵ eingesetzt, aber aus der Nutzungsperspektive waren die BASIC-Programmierungen am DTSS und am Altair ziemlich vergleichbar und in beiden Fällen profitierte die Programmierbarkeit des Computers durch die interaktiven Möglichkeiten der Programmiersprache und durch den auf Fernschreibernutzung optimierten interaktiven Editor.

Mit den 256 Byte Grundausstattung des Altair konnte natürlich kein BASIC verwendet werden. Der Speicher musste entsprechend aufgestockt werden. Gates und Allen schafften es, sehr speichereffizient zu programmieren, sodass schon 4 KB Arbeitsspeicher ausreichten, um BASIC zu betreiben.

Da es sich beim BASIC am Altair um einen Interpreter handelte, konnten BASIC-Befehle ausgeführt werden, ohne ein ganzes Programm schreiben zu müssen. Die Eingabe PRINT 5+5 wurde umgehend ausgeführt und das Ergebnis direkt ausgegeben. Das Erstellen eines Programms konnte ebenfalls sofort beginnen, indem die Zeilen mit vorangestellter Zeilennummer eingegeben wurden. In vielen Fällen würden Sie aber wahrscheinlich kein neues Programm erstellen, sondern ein vorhandenes wiederverwenden wollen. Es mag Sie nun verblüffen, dass der erste BASIC-Interpreter von Microsoft über keinerlei Einrichtung verfügte, Programme einzulesen. Es gab weder ein LOAD noch einen SAVE-Befehl. Microsoft hatte diese beiden Befehle aber nicht etwa einfach vergessen. Eine Laderoutine war vielmehr gar nicht nötig, denn Microsoft konnte sich eine Eigenart der Fernschreiber zunutze machen. Um ein neues Programm zu laden, musste ein Nutzer einfach NEW eintippen, um das vorherige Programm aus dem Speicher zu löschen, musste dann den Lochstreifen mit dem Programm in den Lochstreifenleser einfädeln und den Fernschreiber so einstellen, dass er den Lochstreifen einlas. Der Fernschreiber „tippte“ dann das BASIC-Programm anstelle des Nutzers ein. Für den Interpreter verhielt es sich genau so, als würde der Nutzer es selbst gerade händisch eingeben. Ähnlich funktionierte das Speichern. Der Nutzer tippte LIST, also den Befehl, der das komplette Programm ausdruckte, startete den Lochstreifenstanzer und drückte dann auf die Zeilenvorschubtaste. Der BASIC-Interpreter führte dann den LIST-Befehl aus, gab also das komplette Programm aus und der Fernschreiber schrieb es dabei auf dem Lochstreifen mit.

Stattete man seinen Computer mit BASIC von Microsoft aus, verfügte man über eine Schnittstelle, die es ermöglichte, das Gerät zu verwenden, ohne wissen zu müssen, wie der Arbeitsspeicher des Rechners strukturiert war. Man musste nun nicht mehr ein Programm in der Maschinensprache des Prozessors eingeben, vom Loader einmal abgesehen. Auf der Ebene der Programmierumgebung stand der Quelltext des Programms zeilenweise in Form virtueller Objekte zur Verfügung, die interaktiv manipuliert werden konnten. Ein BASIC-Programm konnte natürlich selbst virtuelle Objekte erzeugen, also so geschrieben worden sein, dass es Daten auf eine Art und Weise abfragte und anzeigte, die es der Nutzungswelt entsprechend zu Objekten machte. An vielen Stellen hatte ein Nutzer von BASIC am Altair aber noch sehr direkt mit der Technik des Computers und des Fernschreibers zu tun. Zwar war das geladene Programm am Rechner manipulierbar, die Programme selbst waren aber keine Objekte im Computer, sondern realweltliche Objekte, nämlich die Lochstreifenrollen, auf denen sie gespeichert waren. Wollte der Nutzer ein Programm laden oder speichern, konnte er nicht auf ein Objekt im Computer referenzieren, sondern musste sich mit dem auf dem Lochstreifen gespeicherten Datenstrom und seiner Verarbeitung im Lochstreifenleser und -stanzer beschäftigen. Auch Eingabedaten waren nicht als eigene Objekte verfügbar, denn es gab im Microsoft BASIC dieser Generation kein Konzept von Dateien, die man hätte laden oder speichern können. Eingabedaten, so nicht von der Tastatur eingegeben, standen vielmehr in DATA-Zeilen direkt im Programm oder kamen, wie die Programme selbst, von Lochstreifenrollen als Ersatz einer Eingabe per Tastatur.

Auftritt: Terminal und Kassette

Der frühe BASIC-Interpreter für den Altair war ganz und gar auf den Fernschreiber ausgelegt. Er diente nicht nur der Eingabe per Tastatur und der Ausgabe auf Papier, sondern auch als Lese- und Speichergerät für Massenspeicher (Lochstreifen) und als externalisierte Lade- und Speicherroutine. Fernschreiber waren aber Mitte der 1970er Jahre nicht mehr der neuste Schrei in Sachen Nutzungsschnittstelle und wurden daher auch am Altair schnell ersetzt. Natürlich konnte man das BASIC von Microsoft auch mit einem Terminal einsetzen, allerdings war dieses BASIC nicht im Geringsten auf Terminals ausgelegt und konnte seine Vorteile nicht nutzen.

• BASIC hatte keine Möglichkeit, den Cursor auf dem Bildschirm zu positionieren oder den Bildschirminhalt zu löschen. So wie es der BASIC-Befehl PRINT nahelegt, konnte BASIC immer nur etwas Neues dazuschreiben.
• Es gab keine Backspace-Funktionalität im heutigen Sinne, denn Fernschreiber hatten natürlich keine Möglichkeit, ein Zeichen wieder vom Papier zu entfernen. Wollte man etwas löschen, musste man dies durch Eingeben eines Unterstrichs tun. Wollte man PRINT tippen, hat aber versehentlich PRR eingegeben, konnte man das zweite R durch die Eingabe eines Unterstrichs „löschen“, das R und der Unterstrich blieben aber am Bildschirm stehen. Eine Eingabe von PRR_INT 5_6+_*6 wurde genau so angezeigt, wurde aber intern zu PRINT 6*6 verarbeitet und gab dementsprechend 36 aus.
• Ein Terminal verfügte natürlich nicht über einen Lochstreifenleser und -stanzer. Es konnten aber ohne diese Vorrichtungen keine Programme geladen und gespeichert werden, was die Nutzbarkeit des BASIC-Interpreters am Terminal natürlich stark einschränkte.

Angepasste BASIC-Versionen gingen diese Probleme an. Sie erlaubten nun das Laden und Speichern von Programmen mittels der Befehle CLOAD und CSAVE. Das Medium für die Programme war dann eine Musikkassette, die sich in einem an den Altair angeschlossenen Kassetten-Recorder befand. Das Programm wurde auf den Kassetten als schrille Tonfolgen gespeichert. Außer dem anderen Medium änderte sich aber nicht viel, denn es gab keinerlei Dateisystem und damit auch keine Programme als Objekte. Im Gegensatz zu Bandlaufwerken von Großrechnern und Minicomputern, etwa dem DECTape, gab es hier keinen vom Computer verwalteten Index und keine Möglichkeit, das Band computergesteuert an bestimmte Stellen zu spulen. Diese lästige Aufgabe oblag ganz allein dem Nutzer. Spätere BASIC-Versionen ergänzten die Unterstützung der Backspace-Taste, sodass fälschlich eingegebene Zeichen wieder gelöscht werden konnten. Das BASIC des Altair unterstützte allerdings nie die programmierte Positionierung des Cursors auf dem Bildschirm. Es gab also keine Programme, die Objekte räumlich stabil und manipulierbar am Bildschirm darstellen konnten.

Disketten – mehr als nur schnell und wahlfrei

Während der pure Altair in seiner Grundausstattung relativ günstig war, kam schnell eine gehörige Summe zusammen, wenn der Rechner mit mehr Speicher, einer seriellen Schnittstelle und mit einem Terminal oder einem Fernschreiber versehen wurde. Derart ausgestattete Rechner standen eher nicht mehr bei Privatleuten, sondern in Firmen, Schulen oder Universitäten. Noch häufiger war dies so, wenn der Rechner mit einem Diskettenlaufwerk bestückt wurde, denn dieses kostete im Jahr 1975 allein schon 2.000 Dollar, was umgerechnet auf 2021 etwa 10.000 Dollar entspricht.

Oben sehen Sie unter dem eigentlichen Altair 8800 ein fast ebenso großes Gehäuse, in das ein 8-Zoll-Diskettenlaufwerk eingebaut ist. Disketten sind Ihnen vielleicht noch bekannt. Sie waren in verschiedenen Ausführungen bis in die 2000er Jahre als günstige, beschreibbare Wechseldatenträger verbreitet, bevor sie durch die USB-Sticks endgültig verdrängt wurden. Disketten waren im Prinzip billige, kleine Wechselfestplatten. Normale Festplatten bestehen aus mehreren magnetisierten Metallscheiben, die mittels Schreib-Leseköpfen gelesen und beschrieben werden können, indem die Magnetisierung der Oberfläche abgetastet oder verändert wird. Eine Diskette war nur eine einzige solche Scheibe und speicherte somit verhältnismäßig wenige Daten (einige 100 Kilobyte). Bei der Scheibe handelte es sich überdies nicht um eine Metallscheibe, sondern lediglich um eine magnetisierte Folie. Ähnlich wie bei der Festplatte bewegte sich ein Schreib-Lesekopf über die rotierende Scheibe und las und schrieb Daten. Die Rotationsgeschwindigkeit und damit die Schreib- und Lesegeschwindigkeit war aber natürlich erheblich niedriger. Im Vergleich zu Musikkassetten war die Diskette aber dennoch weit überlegen. Die höhere Datenrate und damit das schnellere Laden von Programmen wurde hier vielfach als der große Vorteil von Disketten beschrieben. Dieser Geschwindigkeitszuwachs ist natürlich nicht zu verachten, ist für uns hier aber nicht das Spannendste. Viel interessanter ist, dass mit der Diskette die Nutzungsschnittstelle nun um weitere Objekte bereichert wurde.

Das Diskettenlaufwerk des Altair las und beschrieb Disketten mit 8 Zoll Größe, hier links abgebildet. Diese Disketten sowie die später bei vielen Büro- und Heimcomputern üblichen 5,25 Zoll großen Disketten (Mitte) wurden „Floppy Disks“ oder kurz „Floppy“ genannt. Der Name rührt wohl schlicht daher, dass die Datenträger aufgrund ihrer biegsamen datentragenden Folie und der ebenfalls biegsamen Plastikummantelung ziemlich labbrig, oder englisch eben „floppy“ waren. Die später üblichen kleineren 3,5-Zoll-Disketten (rechts), die bis in die 2000er Jahre hinein verwendet wurden, verfügten über eine dickere Plastikummantelung und über eine metallische Schutzlasche, die den eigentlichen Datenträger vor Berührungen schützte. 3,5-Zoll-Disketten sind feste Gebilde. Der Begriff „Floppy“ passt hier, obwohl manchmal noch verwendet, nicht mehr wirklich.

Microsoft passte das BASIC so an, dass es mit Disketten umgehen konnte. Statt mit CLOAD und CSAVE konnte nun mit LOAD und SAVE geladen und gespeichert werden. Der Unterschied wirkt klein, ist aber doch gewaltig, denn bei der Diskette musste und konnte nicht mehr von Hand gespult werden. Ein Programm wurde nun geladen, indem ein vorher vergebener Name angegeben wurde. Mit der Unterstützung von Disketten wurden die Programme also selbst zu Objekten. Mittels CAT konnte eine Liste der gespeicherten Programme ausgegeben werden. Die Programme selbst konnten per Name referenziert und somit geladen, gespeichert oder auch gelöscht werden. Programme wurden zu Objekten der Nutzungsschnittstelle. Wie das Laden und Speichern technisch ablief, brauchte den Nutzer nun nicht mehr zu kümmern. Es war kein Spulen, kein Einfädeln und auch kein manuelles Ein- und Ausschalten von Lese- und Speichergeräten mehr nötig. Nicht nur die Programme wurden mit dem Disketten-BASIC zu Objekten. Auch Ein- und Ausgaben konnten Objekte werden, denn BASIC erlaubte nun das Einlesen von Daten aus Dateien, genauso wie die Ausgabe in Dateien. Mit dieser Funktionalität übertraf das Microsoft-BASIC die Fähigkeiten des originalen BASIC des Dartmouth-College, denn dort war es zwar möglich, Programme zu laden und zu speichern, ein Konzept von Daten-Dateien gab es aber nicht.

CP/M – Das Betriebssystem

Microsoft lieferte zwar ein BASIC mit Disketten-Funktionalitäten und rudimentärer Unterstützung von Terminals, schöpfte aber das volle Potenzial beider Techniken auf dem Altair nicht aus. Anders sah es aus, wenn man das Betriebssystem CP/M nutzte. CP/M steht für Control Program/Monitor (später geändert zu Control Program for Microcomputers). Das Betriebssystem wurde bereits 1974, also vor der Präsentation des Altair von Gary Kildall für den Prozessor Intel 8080 entwickelt. Kildall bot den Erzählungen nach Intel das Betriebssystem an. Der Prozessorhersteller war aber offenbar nicht daran interessiert. CP/M war das erste weit verbreitete Betriebssystem für Home- und Personal-Computer. Der Wikipedia-Eintrag zu CP/M listet sage und schreibe 200 verschiedene Rechnertypen, auf denen das System lief. Es ist leider heute selbst bei vielen Retro-Computing-Anhängern in Vergessenheit geraten, was wohl daran liegen mag, dass das System rein textbasiert war und nicht auf den beliebten, spieletauglichen Geräten der 1980er zu finden war oder dort zumindest nicht genutzt wurde. Obwohl den meisten nicht mehr bekannt, finden sich Spuren der Nutzungsschnittstelle von CP/M aber selbst in aktuellen Versionen von Microsoft Windows wieder. CP/M gehörte allerdings nie der Firma Microsoft. Kildall gründete 1976 seine eigene Software-Firma mit dem wohlklingenden Namen Digital Research. Wie die Nutzungsschnittstelle von CP/M in Windows landete, dazu später mehr.

Kildall traf in CP/M viele interessante technische Entscheidungen. Das System war im Prinzip auf allen Rechnern mit Intel 8080 und kompatiblen Prozessoren lauffähig. Abgesehen vom kompatiblen Prozessor waren die Rechner, auf denen CP/M lief, aber sehr verschieden. Um dennoch das gleiche System und die gleiche Software einsetzen zu können, ersann Kildall das Basic Input/Output System, kurz BIOS. Dieses BIOS musste für jede Systemarchitektur angepasst werden. Der Rest des Betriebssystems konnte wiederverwendet werden und, vielleicht noch wichtiger, die Software konnte rechnerunabhängig programmiert werden. Anstatt die Hardware direkt anzusprechen, galt es nun, die Funktionen des BIOS zu nutzen. In der Praxis ging diese Rechnerunabhängigkeit allerdings nicht so weit, wie es wünschenswert gewesen wäre. Das BIOS abstrahierte etwa nicht vom eingesetzten Terminal. Da verschiedene Terminals ganz unterschiedliche Fähigkeiten hatten und verschiedene Steuersignale verwendeten, um etwa den Bildschirm zu löschen und den Cursor zu positionieren, war man daher immer darauf angewiesen, eine passende Kombination aus Software und Terminal zu nutzen.

Die Eigenarten verschiedener Terminals wurden sicher deshalb nicht für das BIOS berücksichtigt, da CP/M selbst die Vorteile eines Terminals kaum ausnutzte. Die Haupt-Interaktion mit dem Betriebssystem erfolgte über einen Command Processor namens CCP (Console Command Processor). Da Kildall selbst Rechner von DEC nutzte und auf diesen auch CP/M entwickelte, war die Funktionsweise bis hin zu den Befehlen angelehnt an TOPS-10 und war damit dem OS/8 der PDP-8 ziemlich ähnlich. CP/M war im Vergleich zu OS/8 allerdings noch einfacher. Wie OS/8 hatte CP/M keinerlei Nutzerverwaltung und keine Vorrichtungen für Time-Sharing oder Multitasking. Während OS/8 allerdings sehr flexibel in Sachen Speichermedien war und vom DEC-Tape bis zu Festplatten so ziemlich alles unterstützte oder durch Programmieren eines Treibers zugänglich machen konnte, unterstützte CP/M ausschließlich Disketten, auf denen Dateien gespeichert werden konnten. Diese Dateien hatten einen Namen von maximal acht Zeichen Länge, gefolgt von einem Punkt gefolgt von drei weiteren Zeichen, dem sogenannten „Suffix“, auch „Dateiendung“ genannt. Das Suffix wurde genutzt, um klarzumachen, um welche Art von Datei es sich handelte. COM etwa stand für direkt ausführbare Programme, BAS für BASIC-Programme und TXT für Textdateien. CP/M unterstützte mehrere Diskettenlaufwerke, die mit Buchstaben angesprochen wurden. A stand für das erste Laufwerk, B für das zweite und so weiter. Mit dem Befehl dir konnten die Dateien auf der Diskette aufgelistet werden. Eine Ordnerstruktur unterstützte CP/M noch nicht, was aufgrund des beschränkten Speicherplatzes der Disketten aber kein Problem darstellte.

Auf der Abbildung oben sehen Sie, wie es aussah, wenn CP/M auf einem Altair mit angeschlossenem Terminal verwendet wurde. CP/M meldete dem Nutzer seine Eingabebereitschaft in Form einer Kommandozeile. A> bedeutete, dass sich die eingegebenen Kommandos auf die Diskette im ersten Diskettenlaufwerk beziehen. Der Befehl dir *.bas auf der Kommandozeile bewirkte, dass alle Dateien mit der Dateiendung .bas, also alle BASIC-Programme, angezeigt wurden. Der Befehl type diente dazu, eine Datei auf den Bildschirm auszugeben und der Aufruf von mbasic hallo.bas startete den BASIC-Interpreter von Microsoft, der mit jedem CP/M mitgeliefert wurde, und führte in ihm das Programm „hallo.bas“ aus. Dieses tat hier nichts mehr, als Hallo Welt auf den Bildschirm auszugeben. Die Ideenherkunft von CP/M in den Time-Sharing-Systemen der 1970er Jahre merkte man dem System stark an. Es bediente sich letztlich wie ein Time-Sharing-System, an das ein Fernschreiber angeschlossen wurde. Der Nutzer konnte Befehle eintippen, das Computersystem schrieb dann die Ausgabe der Ausführung des Befehls auf den Bildschirm, darunter konnte wieder ein Befehl eingegeben werden und so weiter.

Der Kommandozeilen-Interpreter von CP/M war einige Jahre später die Vorlage für das Betriebssystem 86-DOS von Seattle Computer Products. Im Gegensatz zu CP/M lief 86-DOS, ganz dem Namen entsprechend, nicht mit dem 8-Bit-Prozessor 8080, sondern mit Intels neuem 16-Bit-Prozessor 8086 und dessen günstiger Variante 8088, der im ersten IBM PC verbaut wurde. 86-DOS wurde mitsamt Entwickler von Microsoft gekauft und dann unter den Namen PC-DOS für IBM und MS-DOS für kompatible Rechner vertrieben. Sowohl CP/M als auch DOS fordern mit A> zu einer Eingabe auf. Das Konzept der Laufwerkszuordnung per Buchstabe wurde übernommen, das Wechseln zwischen den Laufwerken funktionierte auf die gleiche Art und Weise und auch die grundlegenden Befehle wie dir und type waren die gleichen. Da diese Grundkonzepte auch in die Eingabeaufforderung von Windows übernommen wurden, können Sie diese Grund-Arbeitsweisen des CP/M von 1974 auch heute, 46 Jahre später, noch erleben. Zu Microsofts DOS und der Entwicklung von Windows kommen wir aber später im Kapitel Windows und MacOS. Bleiben wir zunächst einmal in den 1970ern und werfen einen Blick auf die Killer-App von CP/M. Bei einer Killer-App handelt es sich nicht etwa um ein Ballerspiel. Es ist auch sonst nichts Gefährliches. Als Killer-App bezeichnet man Anwendungsprogramme, die einen so großen Nutzen bringen, dass sie allein die Anschaffung eines bestimmten Systems rechtfertigen.

WordStar – Die Killer-App

Die Interaktionsmethode von CP/Ms Kommandozeilen-Interpreter CCP war in keinster Weise herausragend. Sie glich der Methode von Time-Sharing-Systemen der 1960er und 1970er Jahre, blieb in Sachen Komfort aber sogar hinter diesen zurück. Viel interessanter in Bezug auf die Nutzungsschnittstelle waren viele Anwendungsprogramme, die unter CP/M liefen, denn durch CP/M wurde dem Computer nicht nur eine komfortable Umgebung zur Programmierung in verschiedensten Programmiersprachen bereitgestellt, sondern vor allem auch die Grundlage für Standard-Software geschaffen. Ein gutes und sehr wichtiges Beispiel ist hier das Programm „WordStar“, das erste nennenswerte Textverarbeitungsprogramm für Mikrocomputer. Es verfügte bereits über viele Funktionen, die man auch heute noch von Textverarbeitungssystemen kennt, von der Textformatierung bis hin zur Rechtschreibprüfung. Es war damit eine der frühen Killer-Apps für Mikrocomputer-Systeme. Neben seinen funktionalen Aspekten hatte WordStar auch eine sehr fortschrittliche Nutzungsschnittstelle, die auch heute noch in manchen Aspekten herausragend ist.

Diese Abbildung zeigt die Nutzungsoberfläche von WordStar mit einem schon geladenen Text. Der Bildschirm ist in zwei Bereiche eingeteilt. Der Bereich unterhalb der Zeile mit den vielen Minus-Zeichen ermöglicht die Textbearbeitung. Hier kann ein Eingabe-Cursor frei positioniert werden. Es ist möglich, Text zu löschen und neue Zeichen zwischen die bereits vorhandenen Textteile einzufügen. Statt einer damals noch verbreiteten Kommandozeile wurde bei WordStar also die direkte Manipulation verwendet. WordStar ist daher zwingend auf ein Terminal mit Bildschirm angewiesen, denn die Software nutzte den Vorteil von Terminals gegenüber Fernschreibern aus. Während ein Fernschreiber immer nur unten auf dem Papier etwas Neues ausdrucken konnte und sich das vorher Gedruckte nach oben verschob, konnte auf einem Terminal die Schreibmarke an beliebige Stellen gesetzt und dort konnte geschrieben werden. Dadurch bekamen die Zeichen am Bildschirm eine räumliche Position, an der sie stabil stehenblieben bzw. von der sie an beliebige andere Stellen verschoben werden konnten. Eine Manipulation der Zeichen bedeutete nicht ein komplettes Neu-Drucken, sondern wurde zu einer räumlichen Änderung an Ort und Stelle des Zeichens.

Der Bereich oberhalb der Trennlinie zeigte Status-Informationen und ermöglichte den Zugriff auf die Funktionalität der Software. Vor allem dieser Bereich war seinerzeit außergewöhnlich, denn mit den dort angezeigten Informationen war es möglich, sich das Programm zu erschließen und Auskunft darüber zu erhalten, welche Eingaben und Manipulationen möglich waren. In den seinerzeit üblichen Programmen mit Kommandozeile oder auch einem Editor wie „vi“ war das nicht so. Hier musste man wissen, welche Eingaben möglich waren oder musste es im Handbuch nachlesen. Die Programme selbst gaben keinerlei Hinweise darauf. Natürlich konnten nicht alle Funktionen des Programms vollständig in diesem Steuerungsbereich aufgeführt werden, denn schon zu diesem Zeitpunkt hatte die Textverarbeitungs-Software weit mehr Funktionen und Formatierungsmöglichkeiten als darstellbar waren. Genutzt wurde daher ein System von Menüs und Untermenüs. CTRL+k zum Beispiel öffnete das Untermenü für Block- und Speicher-Kommandos.

Die Erschließbarkeit von WordStar war in der damaligen Zeit herausragend. Bei Weitem nicht jede Software, die die Möglichkeit der räumlichen Einteilung auf dem Bildschirm ausnutzte, erläuterte ihre Bedienung auf diese Art und Weise selbst. Trotz der für heutige Verhältnisse arg eingeschränkten grafischen Möglichkeiten erlaubte es WordStar gut, sich die angebotenen Handlungsoptionen zu erschließen. In einigen Aspekten war die Erschließbarkeit sogar besser als bei heutigen Textverarbeitungen. Man kann das am Beispiel der Block-Operationen, die ich Ihnen zuvor für „vim“ beschrieben habe, ganz gut nachvollziehen. Die auszuführende Aktion war es, einen Textauszug zu markieren und an eine andere Stelle im Text zu verschieben. Grundvoraussetzung hierfür ist natürlich die Möglichkeit, Textbereiche markieren zu können. Zu Zeiten von WordStar war die Computermaus zwar schon erfunden, war jedoch auch in der Fachwelt noch im großen Stile unbekannt. Recht komfortabel konnte jedoch durch Positionieren des Schreibcursors und der Eingabe von Tastaturkürzeln beispielsweise ein Block Text räumlich selektiert und verschoben werden. Die Tastaturkürzel wurden jeweils auf dem Bildschirm angezeigt. Ein Druck auf CTRL und k wechselte das im oberen Bereich angezeigte Menü und gab die möglichen „Blockbefehle“ an. Ein Nutzer erfuhr dort unter anderem, dass B für Blockbeginn, K für Blockende und C für Kopieren steht. WordStar erlaubte es also, sich über die angezeigten Menüs herzuleiten, wie diese Markierung erreicht werden kann. Moderne Textverarbeitungen gehen hingegen davon aus, dass man schon wissen wird, wie man per Maus oder per Tastatur eine Selektion vornehmen kann. Am Bildschirm gibt es keine erkennbaren Hinweise darauf, wie das zu bewerkstelligen ist.

Die Rolle des Altair

Ob der Altair 8800 tatsächlich als erster Personal Computer bezeichnet werden sollte, ist, wie zu Beginn erläutert, fraglich. Durchaus sinnvoll ist es aber, im Altair den Rechner zu sehen, mit dem die Computer im Privatbesitz den Schritt von experimentellen Bastelrechnern zu voll ausgereiften Produkten schafften, die man im Laden kaufen konnte. Mit dem Altair und seinen vielen sehr ähnlichen Nachbauten wie dem IMSAI 8080 oder dem Cromemco-Z1 erhielt der PC seine eigene Charakteristik. Während das System zu Beginn mit seiner Programmierung über das Front-Panel und einem angeschlossenen Fernschreiber noch eher als ein erschwinglicher, leicht eingeschränkter Minicomputer für Hobbyisten anzusehen war, hatte er sich mit der Verbesserung der Ein- und Ausgabemöglichkeiten weiterentwickelt und trat mit dem Betriebssystem CP/M und Software wie WordStar aus dem Schatten seiner großen Brüder. Nutzer verfügten nun über ein System mit einer leistungsstarken Nutzungsschnittstelle. Statt mit den technischen Details der Maschine beschäftigten sie sich nun ausschließlich mit vom Computer für sie erzeugten virtuellen und räumlichen Objekten. Auch die Charakteristik von Software änderte sich von selbst geschriebenen, sehr spezifischen Programmen hin zu Anwendungsprogrammen als (kommerzielle) Produkte. Es war der Beginn der Standard-Software.

Der Altair war der Startschuss für viele Entwicklungen. Seine schiere Existenz hat Computerbastler und Unternehmer inspiriert. Von Microsoft war hier bereits die Rede, aber auch Steve Jobs und Steve Wozniak, die Gründer der Firma Apple, geben den Altair als ihre Inspiration an. Über die entstandenen Produkte erfahren Sie mehr in den folgenden Kapiteln.

Die Dreifaltigkeit von 1977

Auch wenn der Altair 8800 von 1975 als erster Personal Computer bezeichnet werden kann, ist doch viel eher 1977 das Jahr, in dem die Ära der Personal Computer wirklich begann. Denn in diesem Jahr kamen drei Computermodelle auf den Markt, die schon rein äußerlich viel mehr dem glichen, was wir heute einen PC nennen würden, und die die Entwicklung über viele Jahre prägten. Der Commodore Personal Electronic Transactor 2001 (kurz PET), der Apple II und der TRS-80 der amerikanischen Elektronik-Kette Tandy/Radio-Shack wurden einige Jahre später von der Computerzeitschrift „Byte“ als die sogenannte „1977 Trinity“ bezeichnet.

Oben abgebildet sehen Sie die drei Computer. Sie sehen im Gegensatz zum Altair 8800 nicht mehr aus wie ein eingelaufener Minicomputer mit Kippschaltern und Leuchtdioden, sondern haben die heutige Anmutung eines PCs mit Bildschirm, einer Zentraleinheit, Speichergeräten und einer Tastatur. Die Komponenten waren bei den drei Rechnern mehr oder weniger stark integriert. Der TRS-80 war der am stärksten modular aufgebaute Rechner mit separater Basiseinheit, Bildschirm und Tastatur, beim Apple II waren Zentraleinheit und Tastatur kombiniert – eine bis in die 1990er Jahre beliebte Bauweise – und beim links abgebildeten Commodore PET gab es alles aus einem Guss. Nicht nur Tastatur, Zentraleinheit und Bildschirm, sondern sogar ein Kassettenrekorder als Datenspeicher wurden hier integriert. Von den drei im Jahr 1977 vorgestellten Geräten begann die Entwicklung des Apple II relativ früh, nämlich bereits früh im Jahre 1976. Commodore PET und TRS-80 waren hingegen ziemlich schnelle Entwicklungen. Der PET wurde im Januar 1977 als erster von den drei Rechnern der Öffentlichkeit vorgestellt, kam jedoch erst im Oktober des gleichen Jahres auf den Markt und war erst Ende des Jahres wirklich verfügbar. Zu diesem Zeitpunkt konnte der TRS-80 bereits ab August und der Apple II ab Juni gekauft werden. Wieder einmal ist es also schwierig, den ersten zu küren.

Die drei Rechner sind sich von der Bedienung her recht ähnlich. Sie bedienen sich im Prinzip wie ein voll ausgestatteter Altair 8800 mit integriertem Terminal und direkt eingebautem BASIC-Interpreter. Der Apple II war insofern eine Ausnahme, als dass er als einziger der drei Computer grafikfähig war, also nicht nur Textzeichen auf dem Bildschirm ausgeben konnte, sondern auch Linien, Kreise und andere grafische Objekte. Der TRS-80 und der PET hatten eine reine Textausgabe. Da der PET aber über viele grafische Sonderzeichen, inklusive allerlei Linien und Muster-Zeichen, verfügte – die sogenannten PETSCII-Zeichen – konnten Anwendungen und Spiele erzeugt werden, die fast die Anmutung einer echten Grafikausgabe hatten. TRS-80 und Apple II verfügten über eine leicht abgewandelte Schreibmaschinen-Tastatur. Der erste PET hatte hingegen eine gänzlich unmögliche Tastatur mit winzigen Tasten in einer eigenartigen Anordnung. Das Tastenfeld glich optisch mehr einer Tafel Schokolade als einer ernstzunehmenden Tastatur. Natürlich war dieser Missstand auch bei Commodore bekannt. Alle nachfolgenden Modelle des Rechners verfügten daher über eine sehr solide Schreibmaschinentastatur, die als einzige sogar einen Ziffernblock besaß. Dafür musste aber der eingebaute Kassettenrecorder weichen und fortan bei Bedarf extern angeschlossen werden.

Die drei Rechner richteten sich grundsätzlich an Privatleute, Schulen und kleine Firmen, wurden aber aufgrund unterschiedlicher Marktpositionierungen und Ausstattungsmerkmale unterschiedlich angenommen. Der TRS-80 war von den drei Rechnern zunächst der erfolgreichste. Sein Vorteil war, dass er vergleichsweise günstig war und durch das US-weite Netz von „Radio Shack“ überall verfügbar war. Durch die Verbreitung in diesen Elektronikläden fand er natürlich bei Elektronikbastlern Anklang. Den Commodore PET gab es in verschiedenen Ausführungen, die sich vor allem in der Speicherausstattung und in der Grafikausgabe unterschieden. Vor allem auf den Büroeinsatz war die Variante mit achtzig Zeichen pro Zeile ausgerichtet. Die günstigere Vierzig-Zeichen-Variante mit größeren Buchstaben war vor allem in Schulen beliebt. Der Apple II war erheblich teurer als TRS-80 und PET, verfügte allerdings, wie gesagt, auch als einziger über die Möglichkeit, Grafik darzustellen. In frühen Versionen des Apple II musste man sich allerdings aufgrund der Art und Weise, wie die Farbe erzeugt wurde, zwischen einer scharfen Darstellung von Text auf einem monochromen Monitor und einer bunten, aber nicht gut lesbaren Darstellung auf einem Farbmonitor entscheiden. Apples Werbung zielte vor allem auf den Heimmarkt ab. Eltern wurde nahegelegt, dass die Kinder nur dann fit für die Welt von morgen seien, wenn sie einen Apple II besäßen. Seine Verbreitung in Schulen war dementsprechend auch ziemlich hoch – und das nicht nur in den USA, sondern auch in Europa. Der Apple II blieb lange Zeit ein erfolgreiches Produkt. Er wurde als vollständig kompatibler Apple IIe bis 1993 gebaut⁶.

Alle drei Rechner verfügten aber über einen eingebauten BASIC-Interpreter im ROM (Read Only Memory). Man musste also kein BASIC laden, wie noch beim Altair, sondern den Rechner nur einschalten. Die Programmierumgebung stand sofort zur Verfügung. Das BASIC des Commodore PET stammte von Microsoft. Apple und Tandy hatten zunächst andere, eingeschränktere BASIC-Dialekte, schwenkten dann aber um, sodass am Ende alle drei Rechner ein von Microsoft hergestelltes BASIC verwendeten. Leider bedeutete das aber nicht, dass die BASIC-Programme zwischen den Rechnern austauschbar gewesen wären, denn nur die Grundsprache war identisch. Funktionen, die spezifischer waren, etwa zur Grafikdarstellung oder zum Zugriff auf die externen Schnittstellen waren bei den drei Rechnern unterschiedlich. Die BASIC-Programme des einen Computers waren daher inkompatibel mit den BASIC-Interpretern der anderen. Auch jenseits des BASIC-Dialekts waren die Computer nicht softwarekompatibel. Programme, die für einen Rechnertyp entwickelt wurden, liefen nur auf diesem. Nicht einmal die Codierung auf den Disketten und Kassetten an sich war identisch, sodass auch die Dateien des einen Rechners auf dem anderen nicht gelesen oder gar bearbeitet werden konnten.

Bei Markteinführung war bei den drei Rechnern die Musikkassette das Medium, auf dem Programme ausgeliefert wurden, von dem eigene Programme geladen und auf dem sie gespeichert werden konnten. Das war natürlich nicht besonders praktisch. Für alle drei Computer kamen daher zügig Diskettenlaufwerke auf den Markt. Vor allem beim PET und Apple II verdrängte die Diskettennutzung die kassettenbasierte Nutzung nahezu vollständig. Mit der Verfügbarkeit der Diskettenlaufwerke kam natürlich die Notwendigkeit für ein entsprechendes Betriebssystem. Ein solches auf Diskettennutzung optimiertes Betriebssystem wurde Disk Operating System, kurz DOS, genannt.

Sowohl Apple als auch Tandy nannten diese Software DOS (DOS und ProDOS bei Apple, TRSDOS und NewDOS/80 bei Tandy). Heute wird mit DOS meistens das Betriebssystem MS-DOS von Microsoft gemeint. Dafür ist es hier aber noch vier Jahre zu früh.

Man darf sich unter Betriebssystem hier allerdings nicht das vorstellen, was wir heute von unseren PCs und Laptops kennen oder was im Time-Sharing-Betrieb üblich war. Die Betriebssysteme von Apple II und TRS-80 erweiterten lediglich das eingebaute BASIC um Routinen zum Diskettenzugriff. Commodore verzichtete sogar gänzlich auf ein softwarebasiertes Betriebssystem im eigentlichen Sinne, sondern baute die entsprechende Funktionalität direkt in die Diskettenlaufwerke ein.

Fazit

So wichtig die Geräte für die frühe Geschichte persönlicher Computer waren, so vergleichsweise unwichtig waren sie aus Nutzungsschnittstellen-Sicht. Zwar machen die Rechner die Computertechnik der Bevölkerung jenseits der Selbstbastler und Computerbegeisterten zugänglich, in Sachen Nutzungsschnittstelle bieten sie jedoch keinen Vorteil zu einem voll ausgestatteten Altair 8800 mit laufendem Altair-BASIC von Microsoft. Die Nutzer bedienen in allen Fällen eine für Time-Sharing-Systeme auf Fernschreiber-Basis entwickelte Programmiersprache, die um das Handling lokaler Datenträger erweitert wurde.

Kleine Computer im Büro

Ende der 1970er und Anfang der 1980er Jahre spielte die elektronische Datenverarbeitung in vielen Firmen zwar bereits eine immer größer werdende Rolle, die Schreibtische in den Büros waren aber noch meist computerfrei. Die Ergebnisse von Computer-Auswertungen wurden meist in Papierform weiterverarbeitet. Wenn es eine interaktive Computernutzung gab, fand diese an Terminals statt, die mit einem firmeneigenen Großrechner oder einem leistungsstarken Minicomputer wie einer PDP-10 verbunden waren. Allenfalls eine Entwicklungsabteilung oder ein Labor hatte einen eigenen Minicomputer. Als Ende der 1970er Jahre mit dem Altair und der 1977-Dreifaltigkeit Computer für Bastler und Privatleute verfügbar wurden, entdeckte auch manch kleiner Betrieb die Technik für sich und optimierte seine Verwaltung durch den Einsatz eines kleinen Computers. Zuvor war für diesen Anwenderkreis ein Computer weit jenseits alles Finanzierbaren. Große Unternehmen, die seit langem große Rechenanlagen betrieben, sahen in den neuen, kleinen Computern indes keinen Sinn. Sie galten eher als Spielzeug denn als ernsthaftes Arbeitsgerät. Diese Einschätzung sollte sich bald ändern. Der Meinungswandel kam interessanterweise nicht durch bessere oder schnellere Hardware oder gar dadurch, dass die Firmenbosse Teil einer vorgeblichen Revolution sein wollten. Verantwortlich waren vielmehr einige wenige Software-Anwendungen, die für die kleinen Rechner verfügbar waren. Diese Programme allein rechtfertigten die Anschaffung der kleinen Computer für den Büroeinsatz.

Apple II und VisiCalc

Das vielleicht wichtigste dieser neuen Programme, die es nur auf den neuen kleinen Computern gab, war das 1979 von Dan Bricklin und Bob Frankston entwickelte Programm „VisiCalc“. Bricklin bezeichnete das Programm seinerzeit als „a magic sheet of paper that can perform calculations and recalculations“. Es handelte sich um die erste Tabellenkalkulations-Software nach heutigem Maßstab. Schaut man sich die Software heute an, ist die Ähnlichkeit mit Excel von Microsoft bestechend. Nach dem Starten der Anwendung wird der Großteil des Bildschirms durch ein Tabellenblatt in Anspruch genommen. In die Zellen der Tabelle können Texte, Zahlenwerte oder auch Formeln eingetragen werden. Jede Zelle ist durch Angabe der Zeile (als Nummer) und der Spalte (als Buchstabe) identifizierbar und auch innerhalb von Berechnungen referenzierbar. Die Werte in einer Zelle können somit in Formeln genutzt werden. Werden die referenzierten Werte geändert, aktualisieren sich auch automatisch alle aus diesen Werten berechneten Zellinhalte. All das kennen Sie heute genau so aus Programmen wie Excel, LibreCalc oder Google Spreadsheets.

Das Herausragende an VisiCalc war nicht, dass Berechnungen angestellt werden konnten oder dass die Rechenergebnisse in Tabellenform präsentiert wurden. Auch andere Software-Produkte ermöglichten das. Das Überzeugende für die Nutzer war vielmehr die Interaktivität der Software. Am besten kann man sich das klarmachen, wenn man sich überlegt, wie eine einfache Berechnung mit und ohne VisiCalc durchgeführt werden konnte.

Sollte eine Berechnung wie die oben zu sehende mit einer klassischen Software auf einem Time-Sharing-System durchgeführt werden, mussten zunächst die Eingabedaten erzeugt werden. Dafür erstellte man eine Datei, in der die von den einzelnen Personen getätigten Ausgaben entsprechend einer festgelegten Notationsweise abgelegt wurden. In einer anderen Datei wurde nun definiert, wie die Daten zu verrechnen sind, hier also, dass eine Summe zu bilden ist. Auf der Kommandozeile startete man dann die Auswertungs-Software und erhielt, der Konfiguration entsprechend, etwa eine tabellarische Aufbereitung der Berechnung und des Ergebnisses. Sollte nun ein Wert geändert werden, musste die Datei mit den Eingabewerten bearbeitet und die Auswertung neu durchgeführt werden. Bei VisiCalc war es nun ganz anders: Sowohl Eingabewerte als auch Berechnungsvorschriften waren als Objekte am Bildschirm sichtbar. Sie konnten vom Nutzer selbst ohne Programmiereingriffe oder komplexe Editor-Operationen erstellt und angepasst werden, indem der Eingabefokus einfach auf die entsprechende Zelle gesetzt wurde. Sollten Änderungen gemacht werden, musste nur der Wert oder die Formel geändert werden. Alle abhängigen Werte aktualisierten sich sofort. Es mussten keine Programme geändert werden, es gab keine komplexen Codierungen und auch die „unfreundliche“ Kommandozeile musste nicht genutzt werden. Die einfache Änderbarkeit, die permanente Sichtbarkeit von Eingabe, Ausgabe und Verarbeitungsvorschriften und die schnelle Aktualisierung konnten gar nicht hoch genug eingeschätzt werden, ermöglichten sie doch Nutzungsszenarien, die vorher gar nicht denkbar waren. Bei Kreditberechnungen etwa konnte einfach mit Zinssatz und Rückzahlung gespielt werden. Die Änderungen wurden sofort sichtbar und erlaubten so ein exploratives Vorgehen, das bei der alten Lösung so mühselig gewesen wäre, dass es faktisch unmöglich war.

VisiCalc lief auf dem Apple II und zunächst auch nur auf diesem. Dass die Software gerade für diesen Computer entwickelt wurde, hatte offenbar wenig damit zu tun, dass er so besonders gut geeignet gewesen wäre. Mit einem Commodore PET oder einem TRS-80 wäre es sicher genau so gut gegangen. Bob Frankston entwickelte das Programm nur deshalb für den Apple II, weil auf dem Time-Sharing-System des MIT, das er für die Entwicklung nutzte, ein entsprechender Cross-Assembler zur Verfügung stand, der Maschinencode für den Apple II erzeugen konnte. Er konnte also komfortabel den leistungsfähigen Rechner zur Programmierung nutzen und dann das Programm auf dem günstigen Personal Computer ausführen.

Die Nutzungsschnittstelle von VisiCalc

Wenn man sich VisiCalc heute auf einem echten Apple II oder in einem Emulator ansieht, hat man sofort eine Vorstellung davon, wie es sich bedient. Die Art der Zellennummerierung und die Art und Weise, wie berechnet wird, ist in einem aktuellen Excel nahezu identisch. Probleme hat man allerdings wahrscheinlich erst einmal mit dem Bewegen des Cursors, was dem Umstand geschuldet ist, dass frühe Apple II nur zwei Tasten zur Cursor-Steuerung hatten. Man konnte mit ihnen folglich entweder nur horizontal nach rechts und links oder vertikal nach oben und unten steuern. Mit der Leertaste schaltete man in VisiCalc daher zwischen horizontal und vertikal um. Auf dem obigen Screenshot ist in der rechten oberen Ecke an dem Minus-Zeichen zu sehen, dass gerade der horizontale Modus aktiv ist. Die Eigenarten der Cursorbewegung in VisiCalc waren zwar seltsam, stellen einen Nutzer aber nicht vor allzu große Probleme. Größere Probleme bekam man aber, wenn man versuchte, eine Datei zu laden oder zu speichern, denn ganz im Gegensatz zum im Altair-Kapitel besprochenen WordStar zeigte VisiCalc dem Nutzer nur sehr unzureichend an, welche Optionen verfügbar waren. So spannend und innovativ die Software von der Funktionalität her war, so sehr war sie, was die Erschließbarkeit der Funktionen anging, ein Kind ihrer Zeit. Man musste die notwendigen Eingaben und Kommandos entweder kennen oder das Handbuch nutzen, um das Programm zu bedienen. Das Beispiel des Ladens einer Datei zeigt das gut:

Um eine Datei zu laden, musste man das Programm zunächst in den Kommando-Modus versetzen. Wie das ging, stand allerdings nirgendwo. Man musste wissen oder nachschlagen, dass man dazu / eintippen muss. Wenn man das getan hat, zeigte VisiCalc in der ersten Bildschirmzeile an, welche Kommandos eingegeben werden konnten. Man erfuhr, dass man B, C, D, F, G, I, M, P, R, S, T, V, W oder - wählen konnte – mehr nicht. Mit dieser Information war man aber natürlich nicht viel schlauer als vorher und musste wieder ausprobieren oder nachlesen. Tat man das, erfuhr man, dass man nun S für storing und dann L für load eingeben konnte, um eine Datei zu laden. Auch das Beenden hatten Bricklin und Frankston dem „Storing“ zuordnet. Der Befehl dafür lautete im Ganzen /SQ.

Dass Bricklin und Frankston ein so komplexes Programm wie eine Tabellenkalkulation auf einem doch relativ schwachbrüstigen Rechner wie dem Apple II realisieren konnten, ist nicht zu gering einzuschätzen. Tabellenkalkulationen sind heute so selbstverständlich, dass das Innovative an dem Konzept nicht mehr offensichtlich ist: Bei VisiCalc wurden Zahlen, Texte und Formeln in Zellen geschrieben. Die Daten waren damit nicht nur Werte in Variablen, die auf Anforderung ausgegeben werden konnten, sondern standen stabil am Bildschirm als räumlich manipulierbare und referenzierbare Objekte zur Verfügung. Änderungen an Zellen und Werten wurden nicht nur sofort angezeigt, anstatt erneut per Befehl zur Anzeige gebracht werden zu müssen, sondern auch alle anhängigen Zellen wurden automatisch aktualisiert. Das ganze angezeigte Blatt wurde komplett neu durchgerechnet und war folglich immer aktuell. Sie mussten nie eine Neuberechnung manuell anstoßen. VisiCalc bot also nicht nur räumliche Objekte, sondern erfüllte vor allem auch das Potenzial der Responsivität. Der Clou der Software lag in der Kombination dieser beiden Potenziale. Dass die Informationen in den Arbeitsblättern in räumlich eindeutige, per Koordinaten ansprechbare und referenzierbare Zellen abgelegt wurden, erlaubte auch Nicht-Computerkundigen, Berechnungen zu „programmieren“, ohne eine komplexe Programmiersprache zu kennen oder gar wissen zu müssen, wie der Computer im Inneren funktioniert. Damit eine solche responsive Aktualisierung möglich war, mussten Bricklin und Frankston austüfteln, wie sie die Daten der Arbeitsblätter geschickt im Speicher ablegen konnten, um eine schnelle Neuberechnung und Aktualisierung zu erreichen, ohne dass die Neuberechnung für eine merkliche Verzögerung bei der Bedienung sorgen würde.

Dieses kleine Wunder in Sachen Interaktivität brauchte keinen leistungsstarken experimentellen Rechner in einem Labor, sondern lief auf einem „billigen“ Apple II mit 32 KB Arbeitsspeicher und auch nur auf diesem Gerät. Die teuren Time-Sharing-Systeme im Rechenzentrum hatten nichts Vergleichbares. VisiCalc allein war daher für manche Firma Grund genug, Apple IIs für den Büroeinsatz zu erwerben.

CP/M auf den Apple II – Der Computer im Computer

Im Kapitel über den Altair 8800 haben Sie WordStar kennengelernt. Auch diese Textverarbeitung war eine Anwendung, die die Anschaffung eines Computers für den Büroeinsatz rechtfertigen könnte, denn WordStar ermöglichte es einem Büroangestellten mit Personal Computer, einen Text selbst zu tippen und zu formatieren, ohne selbst eine Schreibmaschine nutzen zu müssen oder auf eine Sekretärin zuzugreifen, die ein aufgenommenes Diktat abtippt. WordStar wurde allerdings nicht für den Apple II, sondern für das Betriebssystem CP/M entwickelt. Dieses Betriebssystem lief aber nicht auf dem Apple II, denn dieser verfügte nicht über einen Prozessor, der zum Intel 8080 kompatibel war. Firmen, die Personal Computer für den Büroeinsatz anschaffen wollten, standen damit vor einem Dilemma. Für den Apple II gab es VisiCalc, aber die anderen attraktiven Programme – neben WordStar auch das Datenbanksystem dBase und viele Programmierumgebungen und Compiler – liefen unter CP/M.

Die Lösung dieses Problems kam von einer anderen Seite, als man es vielleicht vermuten würde. Techniker von Microsoft entwickelten eine als „SoftCard“ bezeichnete Einsteckkarte für den Apple II. Die Karte verfügte über einen eigenen zum Intel 8080 kompatiblen Zilog-Z80-Prozessor. Die restliche Schaltung auf der Einsteckkarte diente dazu, die Hardware des Apple II so „umzubiegen“, dass sie für den Prozessor der Karte wie ein typischer CP/M-Rechner wirkte. Es handelte sich gewissermaßen um einen Computer im Computer. Eingesteckt in einen Apple II ermöglichte die Karte also das Ausführen von CP/M auf einem Apple-Gerät. Ein entsprechend angepasstes CP/M und Microsofts BASIC-Interpreter wurden mitgeliefert (MBASIC.COM und GBASIC.COM auf dem Screenshot oben), sodass auch für den Altair oder andere CP/M-Rechner entwickelte BASIC-Software sofort auf dem Apple II lauffähig war. Zusätzlich ausgestattet mit einer Einsteckkarte, die auf dem Bildschirm achtzig Zeichen pro Zeile verfügbar machte und zusätzlichen Arbeitsspeicher bereitstellte, liefen nun auch WordStar und dBase auf dem Apple II. Die Erweiterungsoption blieb kein Nischenprodukt, sondern wurde massenhaft erworben. Die SoftCard war damit ein großer Erfolg. Im Jahr 1980 war sie Microsofts größte Einnahmequelle und durch die Karte und spätere Nachbauten wurde der Apple II der CP/M-Rechner mit der größten Verbreitung.

IBMs Weg zum Personal Computer

Mit dem Apple II und CP/M zogen die ersten Personal Computer in Büros und Unternehmen ein. Apple, Commodore, MITS (der Hersteller des Altair) und die anderen Hersteller von Personal Computern waren für die Firmenwelt genauso neu wie für Privatleute. Natürlich gab es auch vorher schon Computer in Wirtschaftsunternehmen, doch waren ganz andere Firmen in diesem Markt aktiv. Neben der Firma Digital Equipment (DEC) mit ihren beliebten Großrechnern und Minicomputern gab es etwa Computer von Bull, Nixdorf und vor allem vom Branchen-Primus IBM. Die Firma stand regelrecht synonym für große Rechenanlagen in Militär, Verwaltung und Universitäten. Unzählige Entwicklungen in der Computertechnik, wie Festplatten, Multitasking und Paralleles Rechnen gehen auf IBM-Erfindungen zurück oder wurden, wenn von IBM schon nicht erfunden, dann zumindest dort zur Marktreife gebracht. IBMs Computer waren vor allem große Rechenanlagen, aber auch Minicomputer waren im Angebot. Verbreitet war in den 1970er Jahren zum Beispiel der Minicomputer System/3 Model 6.

Ende der 1970er und Anfang der 1980er Jahre drangen nun die neuen Firmen mit kleinen, flexiblen Produkten in den angestammten Bereich von IBM vor. Es dauerte einige Jahre, bis IBM antwortete und seinen eigenen Personal Computer herausbrachte. Die populäre Computergeschichte stellt diesen Fakt, dass IBM erst vier Jahre nach Apple, Commodore und Tandy und sechs Jahre nach dem Altair 8800 einen Personal Computer im Angebot hatte, so dar, dass IBM kleinen Computern nichts abgewinnen konnte und nur große Rechner für beachtenswert hielt. Diese Darstellung wurde sicherlich noch vom Marketing der Firma Apple unterstützt. Im Rahmen der Einführung des Apple Macintosh im Jahre 1984 etwa behauptete Steve Jobs:

In 1977, Apple, a young fledgling company on the west coast invents the Apple II, the first personal computer as we know it today. IBM dismisses the personal computer as too small to do serious computing and unimportant to their business.

Hier ist wohl Steve Jobs’ typisches „Reality Distortion Field“ am Werke gewesen⁷. IBMs vermeintliche Geringschätzung kleiner Computer fand ihren Eingang in manches Buch und manche Dokumentation. Ganz so einfach war es aber nicht. In der Tat hatte IBM mit seinen Computern nicht die Privatperson im Blick. IBM baute Computer für Firmen, keine Heimcomputer. Das hieß aber nicht, dass man keinen Sinn in einem kleinen Computer sah. Das konnte schon deswegen nicht der Wahrheit entsprechen, weil IBM schon seit 1973 einen mobilen Computer entwickelte und diesen ab 1975 verkaufte. Dieser Computer, der IBM 5100, ist heute nahezu vergessen. Es handelte sich um einen tragbaren Computer mit einer ausklappbaren Tastatur, einem eingebauten Bildschirm und einem Bandlaufwerk für Daten und Programme. Warum IBM mit diesem Computer nicht der Marktführer bei den Personal Computern wurde, ist natürlich letztendlich teilweise Spekulation, doch liegen einige Gründe nahe.

Unter anderem war der Rechner mit 16.000 Dollar (in 2021er Kaufkraft entsprechend 79.800 Dollar) extrem teuer. Eine wichtige Rolle spielt meiner Ansicht nach aber auch die Software, bzw. das Fehlen derselben. Als um die Jahre 1979 und 1980 herum die ersten Personal Computer Einzug in die Firmenwelt hielten, hatte sich diese neue Rechnergattung weniger in der Hardware, sondern vor allem durch Software wie VisiCalc, WordStar und Co. von früheren Rechnergenerationen emanzipiert. Rechner wie ein ausgebauter Altair 8800 mit Diskettenlaufwerk, Terminal und CP/M, ein Commodore PET, ein Apple II oder TRS-80 waren keine reinen Fortführungen der Geräte der 1960er und 1970er. Es handelte sich nicht um abgespeckte, verkleinerte Großrechner und auch nicht um billigere Minicomputer, sondern um ein neues Konzept kleiner, autarker Rechner auf der technischen Grundlage von Mikroprozessoren, mit eigener Software und eigenen Nutzungsweisen.

Der 5100 war kein solcher Rechner. Er war ein kompakter, mobiler Computer, der Programme für IBM-Minicomputer und IBM-Mainframes ausführen konnte. Damit das möglich war, baute IBM Interpreter für die Programmiersprachen APL und BASIC ein. Mittels Schalter konnte zwischen den beiden Programmiersprachen umgeschaltet werden. Der APL-Compiler entsprach dem der System/370-Großrechner und der implementierte BASIC-Dialekt wurde auch auf den System/3-Minicomputern verwendet.

IBM hatte 1975 beim 5100 also eher einen Einzelnutzer-Mini-Großrechner im Angebot als einen Personal Computer. Dabei blieb es aber nicht, denn auf den 5100 folgten eine ganze Reihe weiterer Rechner. Betrachtenswert war der System/23 Datamaster. Dieser ab dem Juli 1981 verkaufte Computer war ein Schreibtischrechner mit zwei integrierten Diskettenlaufwerken. Das Gerät konnte mit vielen bürotypischen Anwendungen wie Buchhaltungssoftware und Textverarbeitung ausgestattet werden. Der Datamaster war IBM-typisch teuer und zielte auf die typische IBM-Kundschaft, also auf Firmenkunden ab. Im Fokus standen allerdings nicht die Unternehmen mit einem großen Rechenzentrum, sondern vor allem kleine Firmen ohne Erfahrung mit elektronischer Datenverarbeitung. Der Rechner wurde mit einer sehr gut verständlichen Anleitung ausgeliefert und Software wurde so gestaltet, dass sie ohne komplizierte IT-Begrifflichkeiten auskam. Diesen Computer könnte man durchaus Personal Computer nennen. Mit einem Preis von 9.000 Dollar, was inflationsbereinigt auf das Jahr 2021 über 26.500 Dollar entspricht, war das System allerdings weit teurer als typische Personal Computer, und mit der Möglichkeit, zwei Nutzer an zwei Konsolen gleichzeitig zu bedienen, gingen die Möglichkeiten des Systems über das hinaus, was man üblicherweise einem Personal Computer zuschrieb. Der Datamaster blieb einige Jahre im Angebot von IBM, wurde aber bereits einen Monat später vom IBM 5150, dem „IBM Personal Computer“ in den Schatten gestellt.

Der IBM PC und ein Betriebssystem von Microsoft

Im August 1981 war es soweit: IBM brachte den Rechner „IBM 5150 Personal Computer“ auf den Markt, der den Begriff „Personal Computer“ prägte und dessen direkte Nachfolger heute noch genutzt werden. Fast jeder PC, den Sie heute kaufen können ist ein Rechner, der zu diesem Ur-PC kompatibel ist. Sie könnten den Rechner im Prinzip also mit dem ursprünglichen DOS starten und die Software von 1981 laufen lassen. Von 2006 bis 2020 verwendeten auch alle Apple Macintoshs diese Architektur.

Vergleicht man die technischen Daten des 5150 mit denen typischer Computer der damaligen Zeit, erscheint er nicht besonders herausragend. Als Prozessor kam ein Intel 8088 zum Einsatz. Dieser arbeitete intern mit 16-Bit-Daten, hatte aber einen 8-Bit-Daten-Bus. Um 16 Bit aus dem Speicher zu lesen, musste der Prozessor also zwei Ladevorgänge durchführen. Intel hätte auch einen 8086 mit 16-Bit-Daten-Bus nehmen können. Dann wäre der Speicherzugriff schneller, der Speicher allerdings auch teurer gewesen. Der 8088-Prozessor verwendete eine Adresslänge von 20 Bit. Da jede Adresse 8 Bit Daten bezeichnete, was einem Byte entspricht, hätte der IBM PC also theoretisch 2²⁰ Bytes, also 1 MB Arbeitsspeicher adressieren können. Kaufte man 1981 allerdings einen PC, war dieser bei Weitem nicht so gut ausgebaut. Man konnte den Rechner mit 16 KB oder mit 64 KB bestellen. Eine Erweiterung war zwar bis 640 KB möglich, aber natürlich auch sehr teuer.

Man konnte einen IBM PC seinerzeit gänzlich ohne Diskettenlaufwerk und ohne Betriebssystem erwerben und betreiben, denn in jeden IBM PC und dem Nachfolgerechner PC XT war ein Microsoft-BASIC direkt in die Hardware eingebaut. Schaltete man den Rechner ohne Diskettenlaufwerk oder ohne eingelegte Betriebssystemdiskette ein, startete automatisch das Cassette BASIC von Microsoft. Es konnte also wie beim Apple II oder einem Commodore PET sofort mit dem Programmieren begonnen werden. Programme konnten mit dem eingebauten BASIC von Kassette gelesen und darauf gespeichert werden. Der PC verfügte dazu über eine Buchse auf der Rückseite, an die ein handelsüblicher Kassetten-Recorder angeschlossen werden konnte. Kaum jemand benutzte den Rechner jedoch so, denn für diese eingeschränkte Arbeitsweise war er viel zu teuer. Software für den Rechner wurde nahezu zu 100 % nicht auf Kassette, sondern auf Diskette angeboten. Die allermeisten ausgelieferten PCs verfügten daher über mindestens ein Diskettenlaufwerk. Zwei Laufwerke waren sehr verbreitet und vereinfachten die Bedienung des Rechners im Alltag. Auch die Diskettenlaufwerke des IBM 5150 waren im Vergleich zur Konkurrenz übrigens nicht sehr besonders. Das ursprüngliche Laufwerk, das die Disketten nur einseitig beschreiben konnte, brachte 160 KB auf einer Diskette unter. Zum Vergleich: Der Apple II konnte zu dieser Zeit schon seit einigen Jahren 140 KB auf einer Diskettenseite speichern. Man lag also etwa im gleichen Leistungsbereich.

Ein IBM PC war im Vergleich zu anderen Personal Computern vergleichsweise teuer. Die günstigste Variante mit 16 KB Arbeitsspeicher, CGA-Grafik (siehe unten) und ohne Diskettenlaufwerk kostete 1.565 Dollar (entsprechend 2021: 4.620 Dollar). Mit dieser Variante des Rechners konnte man allerdings fast nichts anfangen, außer eigene BASIC-Programme zu programmieren, zu speichern und zu laden. Das hätte man an anderer Stelle günstiger bekommen können. Ein voll ausgestatteter Rechner mit Betriebssystem, Diskettenlaufwerk und 64 KB Arbeitsspeicher kostete locker das Doppelte. Für Privatleute war dieser Rechner dann aber unerschwinglich und letztendlich wohl auch nicht gedacht, denn der Zielmarkt von IBM waren seit jeher Wirtschaftsunternehmen, die die Firma seit Langem kannten und auch vor allem für IBMs Wartungsverträge schätzten.

Zur Business-Ausrichtung des IBM PCs passten auch die weiteren technischen Eigenschaften. Der Rechner hatte zum Beispiel keine nennenswerte Klangausgabe. Es gab zwar einen Lautsprecher, doch dessen Aufgabe war es eher, bei einer fehlerhaften Eingabe zu piepsen. Im Grafikbereich gab es zwei Ausstattungsmöglichkeiten. Bei der Verwendung eines „Monochrome Display Adapters“, kurz MDA, konnte der Rechner nur Text in zwei Helligkeitsstufen darstellen. Auf dem verwendeten Monitor entstand dabei ein scharfes, nicht flackerndes Bild mit einer guten Zeichendarstellung in grüner oder bernsteinfarbener Schrift auf schwarzem Grund. Die MDA-Karte bot auch eine Schnittstelle zum Anschluss eines Druckers, der natürlich auch im Firmenumfeld wichtiger war als zu Hause. Die Alternative zum MDA-Adapter war die Verwendung eines Color Graphics Adapters, kurz CGA. Auch der CGA-Adapter erlaubte die Darstellung von 80 Zeichen pro Textzeile. Die Zeichendarstellung war hier allerdings ein wenig gröber. Dafür verfügte der Textmodus über sechzehn Farben, die, ganz im Gegensatz zum Apple II, auf entsprechenden Monitoren gut lesbar dargestellt werden konnten. CGA-Grafik verfügte natürlich auch über echte Grafikmodi: 640 x 200 Pixel konnten monochrom und 320 x 200 Pixel bei vier Farben⁸ dargestellt werden. Leider hatte sich IBM hier für sehr ungeschickte Farbpaletten entschieden. Wirklich schöne Grafik war in CGA daher nicht möglich und für Spiele war ein IBM PC mit CGA-Ausgabe sicher nicht ideal. Natürlich gab es Spiele für den IBM PC mit CGA-Grafik. Eine wirkliche Plattform für Spiele im Heimbereich wurde der PC allerdings erst Jahre später.

Ein Betriebssystem muss her!

Für einen gut ausgestatteten IBM PC mit einem oder zwei Diskettenlaufwerken brauchte es ein Betriebssystem. Beim Datamaster im gleichen Jahr war noch ein BASIC-Interpreter mit integrierten Befehlen für das Diskettenhandling die Hauptinteraktionskomponente. Beim PC entschied man sich für ein von einer Programmierumgebung unabhängiges Betriebssystem. IBM hatte kein Betriebssystem für den Rechner, entwickelte es aber auch nicht selbst, sondern lizenzierte ein System von Microsoft, das Microsoft eigentlich selbst auch noch gar nicht hatte. Der Programmierer Tim Patterson hatte ein Betriebssystem für die 8086er-Linie von Intel-Prozessoren entwickelt und sich dafür die Bedienweise und einige der zentralen Konzepte bei CP/M von Digital Research abgeschaut. Sein Betriebssystem 86-DOS sah CP/M zum Verwechseln ähnlich. Viele der von CP/M bekannten Befehle funktionierten auch unter dem neuen Betriebssystem. Die Ähnlichkeit der Systeme bestand auch auf der Architekturebene, was bedeutete, dass CP/M-Programme relativ leicht auf 86-DOS übertragen werden konnten. Microsoft kaufte das Betriebssystem und lizenzierte es unter dem Namen PC-DOS an IBM. Viele, teils in sich widersprüchliche, Geschichten ranken sich darum, wieso IBM ein Betriebssystem von Microsoft orderte und nicht auf das etablierte CP/M von Digital Research zurückgriff. Je nach Einstellung erschien dann Bill Gates von Microsoft als der gerissene Geschäftsmann, der seine Konkurrenz mit einem schlechten Produkt aus dem Markt drängte, oder aber es wird behauptet, dass Gary Kildall von Digital Research die IBM-Verantwortlichen habe sitzen lassen und daher selbst schuld gewesen sei, nicht zum Zuge gekommen zu sein. Lesen Sie diese Geschichten gerne an anderer Stelle nach, aber glauben Sie nichts von dem, was Sie da lesen, denn fünf verschiedene Erzählungen geben sieben verschiedene Versionen der gleichen Geschichte wieder. Die Wahrheit ist kaum noch festzustellen, wahrscheinlich aber ohnehin viel langweiliger als die spannenden Geschichten.

Microsofts DOS wurde fortan mit jedem neuen IBM PC, der über ein Diskettenlaufwerk verfügte, vertrieben. Es gilt allgemein als Geniestreich von Microsoft, dass IBM seinerzeit nicht die exklusiven Rechte an dem Betriebssystem erhielt. Microsoft durfte es auch anderen Unternehmen lizenzieren und tat dies auch. Da der IBM-Rechner großteils aus Standardkomponenten bestand, kamen bald viele Klone (die sogenannten IBM-Kompatiblen) auf den Markt, auf denen DOS, dann unter dem Namen MS-DOS, lauffähig war.

Die Software macht den Unterschied!

Es ist bemerkenswert, dass die frühen Personal Computer zwar über Betriebssysteme verfügten, die stark der alten Fernschreiber-Bedienweise von Time-Sharing-Systemen entsprachen, der Siegeszug von Personal Computern in Büros aber auf einer Reihe von Anwendungen beruhte, die über diesen Kommandozeilen-Stil weit hinausgingen. Das war schon beim Apple II und bei den CP/M-Geräten so. Sowohl VisiCalc, Wordstar als auch dBase zeichneten sich dadurch aus, dass sie die Potenziale interaktiver Computersysteme zu einem weit höheren Grad erfüllten als das Betriebssystem, auf dem sie liefen. Alle drei Anwendungen boten ihren Nutzern eine räumliche Nutzungsoberfläche mit Objekten, die am Bildschirm dauerhaft dargestellt und an ihrem Anzeigeort bearbeitet werden konnten. Im Vergleich zu den Nutzungsoberflächen von heute wirken sie zwar altmodisch und kompliziert, doch war vieles von dem, was es heute gibt, hier schon angelegt. Sie stellten die alten Time-Sharing-Oberflächen mit Fernschreibern oder Glass-Terminals weit in den Schatten. Der IBM PC und sein Betriebssystem MS-DOS bzw. PC-DOS brachten in Sachen Nutzungsschnittstelle nichts Neues. Das Betriebssystem war sehr stark an CP/M angelehnt, was ja seinerzeit seine Eigenschaften vom Großrechner-Time-Sharing-System TOPS-10 geerbt hatte. Arbeiten mit dem Kommandozeilen-Interpreter von DOS fühlte sich daher an, wie die Nutzung eines Großrechners mittels Fernschreiber. Die Möglichkeiten der räumlichen Anordnung von Objekten am Bildschirm wurden nicht genutzt. Zwar konnte der Computer mit einer CGA-Grafikkarte im Grafikmodus betrieben werden und das im monochromen Modus sogar in für damalige Verhältnisse ganz ordentlicher Auflösung, das Betriebssystem und die meisten Anwendungen machten davon aber kaum Gebrauch. Grafikausgabe wurde in Spielen und in Anwendungen für die Darstellung von Inhalten verwendet, etwa für die Anzeige eines Diagramms in der Tabellenkalkulation „Lotus 1-2-3“.

IBM-Computer und die vielen günstigen Kompatiblen wurden in der Geschäftswelt ein großer Erfolg. Die populäre Business-Software aus der Apple-II- und CP/M-Welt wurde übertragen. VisiCalc, WordStar und Co. waren also auch unter DOS verfügbar. Im Laufe der Jahre wurden sie durch Konkurrenzprogramme verdrängt, die vor allem von der Grafikfähigkeit und von der Möglichkeit, den Rechner mit mehr Speicher zu bestücken, profitierten. WordStar blieb recht lange am Markt, bekam aber schon 1982 mit WordPerfect und 1983 mit Microsoft Word Konkurrenz. VisiCalc verlor schnell an Bedeutung. Microsofts erster Versuch einer Tabellenkalkulation namens „Multiplan“ konnte 1982 zwar noch nicht viele Anhänger finden, aber das 1983 erschienene Lotus 1-2-3 lief VisiCalc schnell den Rang ab. Es stand innerhalb kürzester Zeit genauso synonym für Tabellenkalkulation wie vorher VisiCalc und heute Excel. Das große neue Feature von Lotus 1-2-3 im Vergleich zu VisiCalc war vor allem, dass sich nun Diagramme und Business-Grafiken darstellen ließen.

Die Menge, der für den IBM PC verfügbaren Software wuchs in kurzer Zeit extrem an. Neben vielen Programmen aus dem Büro- und Firmenbereich standen natürlich schnell auch allerlei Entwicklungsumgebungen zur Verfügung. Eine Übersicht über alle nennenswerten Software-Produkte der frühen IBM PC-Zeit zu geben, führt an dieser Stelle natürlich viel zu weit. Es kann aber durchaus spannend sein, sich alte Software aus dieser Zeit exemplarisch anzuschauen. Natürlich wirkt ihre Nutzungsschnittstelle heute altmodisch, aber mitunter verfügte die alte Software über interessante Eigenschaften, die man sich heute wieder wünschen würde.

Als ein Beispiel für eine interessante Nutzungsschnittstelle schauen wir uns hier einmal die frühen Versionen von Microsoft Word an. Die erste Version von Word erschien 1983. Die Abbildung zeigt diese erste Version mit seiner sehr typischen Nutzungsschnittstelle. Von Version 1 bis 5 verwendete Microsoft für Word einen Design-Stil, den Microsoft als Standard-Schnittstelle für viele seiner Programme verwendete. Oben befand sich der Inhaltsbereich der Software. Hier sah man etwa den gerade zur Bearbeitung geöffneten Text. Am unteren Bildschirmrand befand sich stets ein Kommandobereich. Durch Drücken von ESC gelangte man in diesen Bereich. Alle hinter dem Wort „COMMAND:“ stehenden Worte entsprachen einer Funktion oder einem Untermenü. Aufgerufen werden konnte die Funktion oder das Untermenü durch das Eingeben des Anfangsbuchstabens. Um einen markierten Textblock zu kopieren, tippte man also ESC und dann C. Alternativ konnten die Kommandos auch ohne vorheriges Drücken der ESC-Taste mit einer Maus ausgewählt werden. Kaum jemand verfügte 1983 jedoch über eine Maus, die als Standard-Eingabegerät erst ein Jahr später mit der Vorstellung des Apple Macintosh überhaupt Verbreitung fand. Bis sie auch bei IBM PCs und Kompatiblen zum Standard gehörte, dauerte es noch bis in die 1990er Jahre.

Das Beachtenswerteste an den frühen Word-Versionen war nicht der Kommandobereich. Die Bedienung damit funktionierte und ermöglichte, sich die Funktionalität des Programms zu erschließen, war allerdings nichts wirklich Besonderes. Spannend waren aber einige Funktionalitäten der Software. Eine sehr interessante Funktion versteckte sich beispielsweise hinter „Window“. Hatte Microsoft zu diesem frühen Zeitpunkt schon Nutzungsschnittstellen mit Fenstern? Wie man auf der Abbildung sieht, erlaubte es Word in der Tat, den Bildschirm in mehrere Bereiche, die Microsoft „Fenster“ nannte, aufzuteilen und darin zum Beispiel verschiedene Dateien anzuzeigen. Das ist für sich genommen nichts Besonderes. Jede moderne Textverarbeitung bietet Ihnen diese Möglichkeit. Spannend ist aber, dass zwei Fenster dieser Art auch das gleiche Dokument anzeigen konnten. Die Abbildung oben zeigt in beiden Fenstern die gleiche Datei „PB.TXT“ an. Diese zwei Fenster im gleichen Dokument machen es möglich, in einem Bereich etwa den Anfang des Textes anzuzeigen, in dem man vielleicht ankündigt, was man alles schreiben möchte, während man im anderen Bereich weiter unten im Dokument schreibt und die gegebenen Versprechen erfüllt. Als ich bei einer Erkundung der alten Word-Version in einem Emulator diese Funktion fand, war ich begeistert. So eine Funktion hätte ich gerne in aktuellen Textverarbeitungen. Umso erstaunter war ich, denn ich fand diese Funktion auch in späteren Word-Versionen – und zwar in allen Versionen von Word bis zum heutigen Tage. Die Funktion ist aber bei Weitem nicht mehr so prominent und mir deshalb nie aufgefallen. Man findet sie in aktuellen Word-Versionen im Ribbon „Ansicht“ unter „Neues Fenster“ bzw. „Teilen“ und in älteren im entsprechenden Menü.

Ebenfalls sehr interessant waren die Funktionen zum Ausschneiden und Einfügen. Die entsprechenden Befehle hießen Copy, Delete und Insert, wobei Delete dem heutigen „Ausschneiden“ entsprach. Bemerkenswert war, was passierte, wenn man einen Block markiert hatte und dann Copy oder Delete aufrief. Man wurde nämlich aufgefordert, diesem Schnipsel einen Namen für das „Glossary“ (auf deutsch etwa „Textbausteine“) zu geben. Es gab also nicht wie heute eine einzige Zwischenablage, in der immer nur ein Inhalt vorhanden ist und bei der ein neuer Inhalt den vorherigen überschreibt, sondern eine richtige Sammlung von Text-Schnipseln, die verfügbar bleiben. Diese Schnipselsammlung konnte man in der Software einsehen und beim Einfügen konnten beliebige Schnipsel eingesetzt werden. Dafür musste man den vergebenen Namen kennen oder aus der Liste auswählen. Das Glossar, also die Schnipselsammlung, war im Gegensatz zur modernen Zwischenablage überdies auch nicht flüchtig. Es konnte unabhängig vom Dokument abgespeichert und dann bei der nächsten Nutzung der Textverarbeitung wiederverwendet werden. So eine Schnipselsammlung mit ihrer komplexen Logik des Kopierens und Einfügens, die viel mehr dem typischen Umgang mit Texten entspricht als der heutige von Apples „Lisa“ übernommene Umgang mit der Zwischenablage, würde ich mir in modernen Textverarbeitungen wünschen – und, oh Wunder, es gibt auch auch diese Funktionalität noch in modernen Word-Versionen (unter dem Namen „Schnellbausteine“). Sie hat allerdings inzwischen ihre Verbindung mit der Zwischenablage und ihren Operationen verloren.

Der PC als Heimcomputer?

Heute sind die allermeisten Computer, die man zu Hause hat und die nicht Smartphones oder Tablets sind, direkte Nachfahren des IBM PC. Zum damaligen Zeitpunkt am Anfang der 1980er Jahre war der IBM PC für den Heimanwender hingegen noch ziemlich uninteressant. Ein heimtauglicher Rechner musste günstig sein, vielleicht das Programmieren ermöglichen, er musste aber vor allem für Spiele geeignet sein. Mit guter Ausstattung war der IBM PC sehr teuer, aber trotzdem nicht sehr spieletauglich und mit schlechter Ausstattung war er immer noch teuer, dann aber in jeder Hinsicht völlig unattraktiv. Wer es auf Spiele abgesehen hatte, war mit einer der damals aufkommenden Spielekonsolen besser bedient, und wer einen Computer zum gelegentlichen Spielen, für eigene Programmierexperimente und für die gelegentliche Textverarbeitung nutzen wollte, konnte mit einem Apple II mehr anfangen. Interessant waren auch ein VIC 20 (in Deutschland unter dem Namen VC 20 verkauft) oder ein Atari 800. Diese beiden gehörten zur neuen Rechnerklasse der Heimcomputer, deren bekanntester Vertreter der Commodore 64, kurz C64, werden sollte, und die wir uns im kommenden Kapitel genauer anschauen wollen.

Die Heimcomputer der 8-Bit-Ära

Mit den Heimcomputern dringen wir in den Bereich der Computergeschichte vor, der heute unter dem Schlagwort „Retro Computing“ viele begeisterte Anhänger hat. Die Retro-Fans basteln an den alten Rechnern herum, schreiben neue Software und Spiele für dreißig Jahre alte Computer und schwelgen in Erinnerungen an ihre Kindheit und Jugend, als sie mit diesen Rechnern ihre ersten Schritte in der Computerwelt machten, ihre ersten eigenen Programme schrieben und als sie auf dem Schulhof die neusten Spiele mit ihren Kumpels tauschten. Viele Bücher über Computergeschichte legen ihren Fokus genau auf diese Epoche der Rechnergeschichte, beschreiben alle Geräte ganz genau und erzählen Geschichten und Anekdoten über die Herstellerfirmen, die Entstehung der Geräte und über die damalige Nutzerszene. In diesem Buch wird dieses Kapitel allerdings wohl eines der kürzesten werden. Dafür gibt es einen persönlichen und einen fachlichen Grund: Der persönliche Grund ist, dass ich kein Spieler bin. Der fachliche und wohl auch der wichtigere Grund ist, dass diese Geräte zwar für viele der Einstieg in die Computerwelt waren, sie in Bezug auf die Nutzungsschnittstellen aber nur wenig Neues brachten.

1981, als der IBM PC begann, in die Bürowelt vorzudringen, gab es in den meisten heimischen Wohnungen noch keine Computer. Die am Markt angebotenen Computer waren nicht gerade günstig (Apple II), nicht gut für Spiele geeignet (Commodore PET) oder sogar keines von beidem (IBM PC). Seit einigen Jahren waren aber die ersten Spielekonsolen von Atari und Activision auf dem Markt. Sie boten gute Grafik- und Soundfähigkeiten und wurden einfach an den heimischen Fernseher angeschlossen. Spiele wurden als Steckmodule, sogenannte „Cartridges“, ausgeliefert. Die Bedienung war dadurch sehr einfach. Um ein Spiel laufen zu lassen, musste man nur die Konsole an den Fernseher und die Controller an die Konsole anschließen, ein Modul einstecken und das Ganze einschalten. Umfangreiches Wissen über Computertechnik war nicht nötig. Die Spielekonsolen wurden im Laufe der Jahrzehnte natürlich weiterentwickelt. Es gibt sie auch heute noch und nach wie vor zeichnen sie sich dadurch aus, dass sie vergleichsweise einfach zu bedienen sind und keine besonderen Computerkenntnisse erfordern. Die frühen Spielekonsolen waren ein Grundstein der nun aufkommenden Heimcomputer, die sich dann unabhängig von ihnen weiterentwickelten.

Im Jahr 1979 bereits brachte Atari die Computer Atari 400 und Atari 800 auf den Markt. Die beiden Rechner waren im Prinzip Atari-Spielekonsolen mit eingebauter Tastatur, wobei gerade die Tastatur des Atari 400 für effektives Tippen nicht geeignet war, denn es handelte sich um eine Folientastatur wie man sie heute allenfalls noch von älteren und billigen Fernbedienungen kennt. Programme und Spiele für die Atari-Computer erschienen in Form von Einsteckmodulen. Wenn man so ein Einsteckmodul hatte, öffnete man die Klappe oberhalb der Tastatur, setzte das Modul ein und startete den Rechner. Wie bei den Spielekonsolen wurde das Programm sofort gestartet und konnte direkt verwendet werden. Die meisten Module waren natürlich Spiele, es gab aber auch ein Textverarbeitungsmodul und einen BASIC-Interpreter. Steckte man dieses Modul ein und startete das Gerät, startete das Atari BASIC und man konnte, wie auf einem Commodore PET oder Apple II, eigene Programme erstellen.

Wenn man mit dem Computer in BASIC programmierte, musste man die Programme natürlich abspeichern und laden können. Hierfür musste man einen Programmrekorder erwerben. Dabei handelte es sich um einen Kassettenrecorder für handelsübliche Musikkassetten, allerdings mit zusätzlicher Elektronik, sodass die Codierung der Daten in Töne und die Decodierung der Töne in Daten schon im Gerät vorgenommen wurde. Auf eine Musikkassette mit dreißig Minuten Länge (also einer Seite einer 60er-Kassette) passten 50 KB Daten. Da die Kassette in ihrer normalen Geschwindigkeit abgespielt wurde, hieß das natürlich, dass das Laden von 50 KB Programm ganze dreißig Minuten gedauert hätte. So lange musste man aber nie warten, denn die Rechner verfügten nur über 8 KB Arbeitsspeicher, was die mögliche Programmgröße selbstredend beschränkte. Auch ein Diskettenlaufwerk war verfügbar, das natürlich einen schnelleren Zugriff bot und pro Diskette insgesamt 180 KB, also 90 KB pro Diskettenseite, speichern konnte.

Die Atari-Computer blieben nicht die einzigen Computer dieser Art. Atari selbst baute ab 1983 die Computer 600XL und 800XL, die mit 16 bzw. 64 KB Arbeitsspeicher ausgerüstet waren und das Atari BASIC bereits integriert hatten. Bereits 1980 erschien der VIC 20 der Firma Commodore (in Deutschland VC 20 genannt). Gegenüber den Atari-Rechnern war er ziemlich eingeschränkt. Er konnte nur etwa 22 Zeilen à 23 Zeichen Text auf den Bildschirm bringen und hatte keinen richtigen Grafikmodus. Aufgrund seines günstigen Preises fand er aber durchaus Verbreitung. 1982 folgte auf den VIC 20 der Heimcomputer der 1980er schlechthin⁹, der Commodore 64, kurz C64. Er wurde bis 1994 gebaut.

Der Commodore 64 (C64)

Commodore hatte 1977 den Commodore PET auf den Markt gebracht. Dieser wuchtige Rechner mit integrierter Tastatur und integriertem Bildschirm war vor allem für Schulen und Unternehmen interessant. Mit dem VIC 20 verfügte Commodore 1980 dann über einen Computer, der für Arbeit und Programmierung eher weniger geeignet, dafür aber günstig und dank einfacher Grafik- und Soundoptionen spieletauglich war. Ganz in dieser Linie stand auch der Commodore 64, kurz C64, der 1982 erschien. Der Rechner wurde unter der Maßgabe entwickelt, günstiger als ein Apple II zu sein, eine komfortable Programmierung zu ermöglichen und vor allem auch durch die Unterstützung von Grafik und Sound gut für Spiele geeignet zu sein und damit auch Atari den Rang ablaufen zu können.

Wie konnte man beim C64 etwa gegenüber einem teuren Apple II etwas einsparen, um günstiger zu sein? Sparen konnte man sich zum Beispiel den Monitor, denn jeder Nutzer hatte bereits einen Monitor zu Hause, nämlich den heimischen Fernseher. Der C64 wurde also wie zuvor schon der VIC 20 an das Fernsehgerät daheim angeschlossen. Dieser erledigte auch gleich die Klangwiedergabe, es brauchte also keinen eingebauten Lautsprecher. Dass durch die Fernsehausgabe die Auflösung eingeschränkt war, war für den Einsatzzweck im Heimbetrieb weniger problematisch. Der C64 war nicht der Rechner zum Verfassen von Serienbriefen oder für umfangreiche Tabellenkalkulation. Diesen Bereich überließ man gerne anderen oder bot mit den Nachfolgern des PET selbst entsprechende Geräte an.

Der C64 war ein sehr attraktives Gerät. Obige Tabelle zeigt einige technische Eigenschaften des Commodore 64 und des IBM PC 5150 im Vergleich. Wie Sie sehen, war der PC tatsächlich nur in den eher für Büroeinsatz wichtigen Eigenschaften im Vorteil: Es konnten im Textmodus achtzig Zeichen pro Textzeile und im Grafikmodus bei zwei Farben eine Auflösung von 640 x 200 Pixeln erreicht werden. Der Commodore 64 hingegen erlaubte die Darstellung von sechzehn Farben im Text- und im Grafikmodus bei einer Auflösung von 320 x 200 Pixeln. Der PC konnte bei dieser Auflösung nur vier Farben anzeigen. Aus ganz verschiedenen Welten waren die Klanggeneratoren der Systeme. Der PC hatte nur einen einstimmigen Piepser, der C64 hingegen einen dreistimmigen Synthesizer, der für ein durchaus hörenswertes Klangerlebnis sorgen konnte.

Schaltete man einen Commodore 64 ein, startete sofort ein BASIC-Interpreter. Verwendet wurde das gleiche BASIC, das Commodore auch schon beim PET verwendet hatte, also ein BASIC-Dialekt von Microsoft. Ein Besitzer eines C64 konnte sofort nach dem Einschalten BASIC-Befehle eingeben und etwa wie auf der Abbildung oben die einfache Berechnung 5+3*7 durchführen. Auch mit der Programmierung eines richtigen BASIC-Programms konnte sofort begonnen werden. Der C64 verfügte, wie auch schon der PET, über einen komfortablen Editor für die BASIC-Programmierung. Der Cursor ließ sich frei auf dem Bildschirm bewegen. Da die Ausgabe einer Zeile im BASIC-Listing der Definition ebendieser Zeile entspricht, ließ sich das Programm komfortabel bearbeiten, indem im Listing in die entsprechende Zeile navigiert, die Ausgabe dort verändert und die geänderte Zeile durch das Drücken von „Return“ zur Neueingabe gemacht wurde. Andere Rechner wie der Apple II unterstützten dies grundsätzlich zwar auch, doch war die Bewegung des Cursors dort nur sehr umständlich durch die Eingabe von Tastenkombinationen zu erreichen.

Auch die in BASIC erstellten Programme konnten die Vorteile eines Text-Bildschirms ausnutzen. Der Bildschirm ließ sich löschen, Farben konnten verwendet werden und der Cursor ließ sich durch das Programm frei positionieren. Eigenartigerweise gab es trotz der herausragenden Grafik-Soundchips des C64 keine BASIC-Befehle zur Grafik- und Klangausgabe. Programmierer mussten sich behelfen, indem sie mit dem Befehl POKE direkt Werte in Speicherbereiche des Computers schrieben. Dies funktionierte zwar, brachte den Programmierer aber eigentlich unnötig nah an die Hardware-Ebene.

Wie beim Atari 800, beim Apple II, dem PET und dem TRS-80 gab es auch beim C64 die zwei Varianten des Massenspeichers, die in den 1980er Jahren üblich waren. Die günstigere, aber langsame Variante war die Nutzung von handelsüblichen Musikkassetten. Das zugehörige Abspielgerät wurde von Commodore „Datassette“ genannt. Auf ein dreißigminütiges Band konnten mit Bordmitteln 100 KB Daten gespeichert werden. Vielen Nutzern, Entwicklern und Bastlern war das allerdings zu wenig und zu langsam. Mit Hilfe von sogenannten „Turbo-Loadern“, die es sowohl in Hardware- als auch in Software-Form gab, gelang es ihnen, bis zu 1 MB auf die Kassettenseite zu quetschen. Auch für den C64 gab es natürlich Diskettenlaufwerke. Erstaunlicherweise war die Verbreitung dieser Laufwerke national unterschiedlich. In Großbritannien etwa war die Kassette das Medium der Wahl, gerade, was Spiele für den C64 anging, in Deutschland waren beide Speichermedien anzutreffen und in den USA wurde ein C64 eigentlich nur mit Diskettenlaufwerken verwendet. Auf eine Seite einer Diskette passten 163 KB Daten. Auch die andere Diskettenseite konnte beschrieben werden. Dafür musste man die Diskette allerdings händisch umdrehen. Die Diskette konnte mit 400 Bytes pro Sekunde sagenhaft langsam gelesen werden. Eine ganze Diskette einzulesen, dauerte sage und schreibe sieben Minuten. Auch bei der Disketten-Nutzung gab es Schnell-Lader, die den Datendurchsatz auf 10 KB pro Sekunde steigern konnten.

Die meisten Computer der damaligen Zeit mussten mit einem eigenen Disk Operating System ausgestattet werden, um mit Disketten arbeiten zu können (Apple II, TRS-80, IBM PC) oder hatten ein solches integriert (etwa Atari 600XL/800XL). Bei den Commodore-Rechnern war das nicht so. Deren Betriebssystem unterstützte, genau schon wie das des PET und des VIC 20, Diskettenlaufwerke eigentlich überhaupt nicht. Wollte man Daten von der Diskette laden, musste man die Gerätenummer des angeschlossenen Geräts angeben. Bei Diskettenlaufwerken war das üblicherweise die Nummer 8. Dass es sich dabei dann um ein Diskettenlaufwerk handelte, war für den Rechner irrelevant. Man konnte ein Programm auf genau die gleiche Art und Weise – unter Angabe einer anderen Gerätenummer – auch von einer Schnittstelle lesen, an der zum Beispiel ein anderer Computer per Kabel angeschlossen war, der die Daten sendete. Für das System war es unerheblich, welche Art von Gerät auf der anderen Seite hing. Wie die Daten also von einer Diskette zu lesen waren, wie eine Diskette strukturiert war oder wie sie formatiert wurde, war keine Sache des Betriebssystems des C64. All diese Funktionen brachte Commodore direkt im Diskettenlaufwerk unter, das dadurch letztlich zu einem kleinen Computer für sich wurde. Diese von Commodore gewählte Architektur für den Diskettenzugriff klingt sehr sinnvoll, denn die konkrete Implementierung des Datenträgerzugriffs wurden so vom Computer und vom Betriebssystem abgekoppelt. Dies erlaubte grundsätzlich, verschiedenste Disketten- oder sogar Festplattenlaufwerke anzuschließen, die alle auf die gleiche Art und Weise hätten angesprochen werden können, solange sie nur über die gleiche Schnittstelle verfügten. Leider war diese Entkopplung in der Praxis aber gar nicht so toll, denn der C64 hatte nicht etwa eine abstrahierte Unterstützung von Diskettenlaufwerken als allgemeine Datenträger, sondern schlichtweg gar keine Unterstützung für sie.

Im Bild oben sehen Sie, wie am Commodore 64 ein Programm, hier das Programm „RATEN“ von Diskette geladen wurde. Dies gelang über den Befehl LOAD "RATEN",8. Wichtig ist der Zusatz ,8, die Angabe der Gerätenummer 8. Vergaß man diese zwei Zeichen, versuchte der C64 das Programm von Kassette zu laden. Auf die gleiche Art und Weise wie das Laden funktionierte das Speichern, also etwa mit SAVE "NEU",8. Diese beiden Operationen waren noch recht einfach und einleuchtend. Kompliziert wurde es aber, wenn man zum Beispiel ein Programm auf der Diskette löschen wollte. Der C64 kannte keinen Befehl dafür. Man musste also eine Verbindung zum Diskettenlaufwerk aufbauen, eine speziell formatierte Nachricht dort hinschicken und die Verbindung wieder schließen. Wollte man zum Beispiel das Programm „UNSINN“ löschen, ging das durch die Eingabe von OPEN 1,8,15,"S:UNSINN.PRG":CLOSE 1. Aus Nutzungsschnittstellen-Sicht war das natürlich ziemlich schrecklich. Statt mit virtuellen Objekten umzugehen, diese zu erstellen, zu löschen oder zu manipulieren, öffnete man Kanäle zu angeschlossenen Geräten und schickte diesen kryptische Nachrichten. Man begab sich also für so alltägliche Operationen wie das Löschen, Kopieren oder Umbenennen von Dateien ganz tief hinab in die Technik des Computers bzw. des Diskettenlaufwerks. Diesen Missstand dürften viele der Besitzer des Rechners aber wohl gar nicht bemerkt haben, sie steckten nur eine Diskette ein und gaben LOAD "*",8,1 ein, um das erste Programm auf der Diskette direkt zu laden und zu starten und schon konnten sie ihr Lieblingsspiel spielen.

Die Rolle der 8-Bit-Heimcomputer

Mit den Heimcomputern der 8-Bit-Ära drangen Computer in die Wohn- und Kinderzimmer vor, was natürlich zu einem nicht geringen Anteil daran lag, dass sie mit ihren Grafik- und Soundfähigkeiten gut für Spiele geeignet waren und dass sich diese Spiele, wenn sie auf Kassette oder Diskette verbreitet wurden, gut kopieren ließen. Dadurch, dass die Geräte beim Einschalten mit einem BASIC-Interpreter starteten und damit einen schnellen Zugang zur Programmierung boten, hat aber auch so mancher, der den Computer zum Spielen angeschafft hatte, auch das Programmieren erlernt und kleine Programme für die Probleme des Alltags oder der Hobbys gebaut. Betrachtet man die Rechner aus der Nutzungsschnittstellen-Perspektive, brachten sie nichts wirklich Neues. Im Gegenteil: Sie hinkten Betriebssystemen wie CP/M oder auch dem DOS des Apple II sogar hinterher.

Die Heimcomputer entwickelten sich natürlich weiter. Die Nachfolgegeneration der 8-Bit-Computer von Commodore und Atari war nicht nur eine aufgemotzte Variante dieser Geräte, sondern auch stark beeinflusst vom Apple Macintosh. Der Commodore Amiga und der Atari ST waren somit gleichermaßen Nachfolger der auf Spiele fokussierten 8-Bit-Computer und Konkurrenten für die Bürocomputer Macintosh und IBM PC. Gleichzeitig wurden die IBM PCs mit besserer Grafik und besserem Sound stetig spieletauglicher und fanden mit sinkenden Preisen auch ihren Platz auf manch heimischem Schreibtisch. Die Zeit der an den Fernseher angeschlossenen Computer ging zu Ende und die Unterscheidung zwischen typischen Heim- und Bürocomputern schwand zusehends.

Schreibtisch mit Fenster

Machen wir uns klar, wo wir in der Geschichte des Personal Computers inzwischen angekommen sind. Aus den bescheidenen Anfängen Mitte der 1970er hat sich eine beeindruckende Industrie entwickelt. Versetzen wir uns zum Beispiel ins Jahr 1983: Heimprogrammierer und Spieleliebhaber bekamen für ein überschaubares Budget einen Commodore 64 oder einen Atari 800XL. Wer mehr Geld ausgeben konnte, besorgte sich einen Apple II. Auch manche Schule und kleinere Firma rüstete sich mit den Apple-Rechnern aus. Für Firmen attraktiv war natürlich auch der IBM PC, inzwischen in seiner zweiten Ausführung PC XT. Viele andere Hersteller wie Compaq boten Nachbauten des IBM PCs für kleines Geld an. Nahezu alle genannten Rechner waren grafikfähig. Die Grafikfähigkeiten wurden genutzt, um etwa Diagramme auszugeben, Grafiken anzuzeigen und natürlich, um Spiele möglich zu machen. Teil der Nutzungsschnittstelle der Betriebssysteme und der Software wurde die Grafik noch nicht. Die Betriebssysteme blieben textterminal-basiert. Populäre Software nutzte allerdings die Möglichkeit, mit Textzeichen den Bildschirm räumlich zu strukturieren. Wie das geschah, war nicht standardisiert. Jeder Software-Hersteller kochte im Prinzip sein eigenes Süppchen, sodass sich jede Anwendung anders bediente. 1984 wurde ein Computer auf den Markt gebracht, der dies änderte. Seine Nutzungsschnittstelle setzte auf Grafik und die Firma, die den Rechner herstellte, stellte Ressourcen und Vorgaben bereit, die dafür sorgten, dass alle Software-Programme eine einheitliche Nutzungsschnittstelle erhielten. Dieser Rechner war der Apple Macintosh. Seine Nachfahren, heute nur noch „Mac“ genannt, kennen wir noch immer als größte Konkurrenz zu Rechnern mit Microsoft Windows. Der Macintosh war der erste wirtschaftlich (mehr oder weniger) erfolgreiche Rechner, dessen Nutzungsschnittstelle das WIMP-Paradigma (Windows, Icons, Menus und Pointer) verwendete und dessen zentrales Konzept der sogenannte Desktop war. Um die Geschichte dieser Art der Nutzungsschnittstellen geht es in diesem Kapitel, denn die Wurzeln des Macintosh und seiner Nutzungsschnittstelle reichen weit in die Computergeschichte zurück. Sie liegen in experimentellen Rechnern der 1960er und 1970er Jahre. Auch die Computermaus fand in diesen Jahrzehnten ihren Anfang.

Das Zeigegerät – Die Geschichte der Maus

Eine Nutzungsschnittstelle mit verschiebbaren Fenstern, auswählbaren Icons und aufklappbaren Menüs kann nicht effektiv mit einer reinen Text-Tastatur verwendet werden. Sie verlangt vielmehr nach einem Eingabegerät, das eine räumliche Auswahl ermöglicht. Nun wird das Aufkommen von Computern mit Nutzungsschnittstellen genannter Art meist, und das auch zu Recht, mit der Maus als Eingabegerät verbunden. Sie wissen aber aus dem Kapitel über experimentelle grafische Systeme, dass es räumliche Eingabemethoden schon sehr lange gab und dass die Maus nicht den Anfang machte. An SAGE und Sketchpad haben Sie nämlich Lichtgriffel (Lightpens) als Eingabegeräte kennengelernt. Ebenfalls früh in Betracht gezogen, hier allerdings nicht betrachtet, wurden Joysticks als Eingabegeräte, um die Auswahl eines Bildschirmobjektes zu ermöglichen. Die Computermaus brachte gegenüber Lichtgriffel und Joystick Vorteile durch ihre Eigenschaft, sehr genaue und präzise Selektionen und Manipulationen zu ermöglichen, dabei aber nicht sehr ermüdend zu sein.

Beim Versuch, die Anfänge der Computermaus herauszubekommen, geraten wir wieder in eine Situation, in der man sich streiten kann, wer die erste Maus erdacht, erfunden und auf den Markt gebracht hat und wieder, wie schon bei der Frage nach dem ersten Computer, wird die Frage meist je nach nationaler Brille auf dem Kopf des Fragestellers unterschiedlich beantwortet.

Wir kennen Computermäuse als kleine, kästchenartige Gebilde, die über eine Tischoberfläche geschoben werden können und deren Bewegungen eine korrespondierende Bewegung eines Zeigers am Bildschirm auslösen. Heutige Mäuse funktionieren meist rein optisch. In den 1980er und 1990er Jahren waren hingegen Mäuse verbreitet, in denen sich eine Kugel mechanisch drehte. Diese Kugel war in der Maus so gelagert, dass ihre Bewegung mit der Bewegung des Gerätes über die Tischoberfläche korrelierte. Die Idee, die Rotation einer Kugel mechanisch abzutasten und als Eingabe zu nutzen, ist allerdings älter als interaktive Computer und damit auch älter als die Maus. Bereits in den 1950er Jahren wurden sogenannte „Trackballs“ in der Radartechnik eingesetzt. Ein solcher Trackball war, wie der Name sagt, eine Kugel (ball), deren Bewegung nachvollzogen (tracked) wird. Trackballs wurden in die Oberfläche der Radarstation eingelassen. Radar-Operatoren konnten die Kugel dann mit der Hand bewegen, um etwa die Bewegung eines Auswahlkreuzes auf dem Radarschirm zu steuern.

Unter den Firmen, die derartige Bedienkonsolen für die Luftraumüberwachung mit Trackball herstellten, war auch die deutsche Firma Telefunken. Telefunken deutschte den Begriff „Trackball“ ein und nutzte den wunderschönen Begriff „Rollkugelsteuerung“. Im Angebot der Firma war Ende der 1960er und Anfang der 1970er Jahre eine Großrechnerserie namens TR-440. Sie fand Einsatz in vielen Universitäten, was unter anderem daran lag, dass ihre Anschaffung durch öffentliche Gelder unterstützt wurde. In den allermeisten Einrichtungen dürfte der Rechner seinerzeit im typischen Batch-Betrieb genutzt worden sein, um eine Massennutzung zu ermöglichen. Allerdings war auch eine interaktive und sogar eine grafische Nutzung des Rechners möglich. Telefunken bot dazu einen sogenannten „Satellitenrechner“ namens TR-86 an. Die Aufgabe dieses Rechners war die Abwicklung der Ein- und Ausgabe, die damit vom eigentlichen Großrechner abgetrennt wurde, denn schließlich konnte man es nicht rechtfertigen, dass ein ganzer Großrechner seine Rechenzeit dafür „verschwendete“, dass ein Nutzer etwas eintippte. An den Satellitenrechner konnten Terminals angeschlossen werden. In der Produktpalette von Telefunken fand sich neben Text-Terminals auch ein grafisches Terminal mit der Bezeichnung SIG 100 (SIG für Sichtgerät). Das SIG 100 bestand aus einem Schwarz-Weiß-Fernseher und einer angebauten Tastatur. An dieses Sichtgerät wiederum konnte eine eigene Version der Rollkugelsteuerung mit der Bezeichnung RKS 100-86 angeschlossen werden.

Die Rollkugelsteuerung RKS 100-86 – ich nenne sie im Folgenden kurz „Rollkugel“ – funktionierte im Prinzip genauso wie die Rollkugelsteuerung der Radargeräte, allerdings mit einem wichtigen Unterschied: Die Rollkugel an den Radargeräten war fest in die Bedienkonsolen integriert. Für den Einsatz am SIG 100 war das nicht geeignet, denn dieses war ein Gerät, dass man auf vorhandene Tische stellen sollte. Einen Trackball in diese Tische einzulassen, passte nicht ins Konzept. Man drehte die Rollkugel also kurzerhand um und baute sie in ein Gehäuse, das über den Tisch geschoben werden konnte.

Oben sehen Sie die Abbildung einer dieser Rollkugelsteuerungen. Das Gerät ist größer als das, was man von heute kennt und als einen das Foto erahnen lässt. Die Halbkugel, die über den Tisch geschoben wird, hat einen Durchmesser von zwölf Zentimetern. Man bediente sie also, indem man die ganze Hand darauflegte. Dabei musste man darauf achten, nicht versehentlich den Knopf auf der Oberseite zu drücken. Wenn man die Rollkugel über den Tisch schob, bewegte sich im inneren des Geräts eine Kugel. Wie Sie auf der unteren Abbildung sehen, wird die Rotation der Kugel an zwei Bauteile übertragen, die ein bisschen an Fahrrad-Dynamos erinnern. Diese Bauteile sind sogenannte „Encoder“, die die Bewegung der Kugel in einen 8-Bit-Code übertragen, der dann über ein Kabel nach außen geführt wird.

Der Telefunken-Ingenieur Rainer Mallebrein entwickelte die Rollkugel ab 1965. Ab 1968 konnte man sie als Zubehör für das Sichtgerät erwerben. Oft verkauft wurde sie allerdings nicht. Keine fünfzig Exemplare wurden hergestellt. Die Zeit für diese Art von Eingabegeräten war noch nicht gekommen, denn nur wenige verwendeten einen zwanzig Millionen Mark teuren Großrechner interaktiv und noch weniger hatten Verwendung für eine grafische Ein- und Ausgabe. Entsprechend gering war natürlich die Menge der Software, die überhaupt mittels Rollkugel bedienbar war. Spätere Rechner von Telefunken unterstützten die Rollkugel daher nicht mehr – das innovative Eingabegerät geriet in Vergessenheit. Hiermit endete die deutsche Geschichte der Computermaus, die nicht einmal so hieß.

Am Stanford Research Institute (SRI) entwickelten etwa ab 1963 der Informatiker Douglas Engelbart und seine Kollegen des Augmentation Research Centers, dessen Leiter Engelbart war, ein experimentelles Computersystem namens oNLine-System, kurz NLS. In einer Selbstdarstellung¹⁰ beschreiben Engelbart und Co. das Projekt folgendermaßen:

Viewed as a whole, the program is an experiment in cooperation of man and machine. The comprehensible part of man’s intellectual work involves manipulation of concepts, often in a disorderly cut-and-try manner, to arrive at solutions to problems. Man has many intellectual aids (e.g., notes, files, volumes of reference material, etc.) in which concepts are represented by symbols that can be communicated and manipulated externally. We are seeking to assist man in the manipulation of concepts–i.e., in his thinking, by providing a computer to aid in manipulation of these symbols. A computer can store and display essentially any structure of symbols that a man can write on paper; further, it can manipulate these symbols in a variety of ways. We argue that this service can be made available to help the on-going intellectual process of a problem-solving man; the service can be instantly available to perform tasks ranging from the very smallest to the very largest.

Dieser Text wurde 1965 geschrieben. Für diese Zeit war das, was beschrieben wurde, absolut außergewöhnlich, denn es wurde ein Computersystem beschrieben, das interaktiv genutzt werden konnte. 1965 wurden, wie Sie inzwischen wissen, die wenigsten Rechner so betrieben, und ein interaktiver Betrieb von leistungsstarken Rechnern kam schon mal gar nicht infrage. Nur militärische und einige experimentelle Systeme wurden so genutzt. Es war die Rede von einem System, das den Menschen beim Denken unterstützen sollte, indem es einen dynamischen Umgang mit Symbolen am Bildschirm erlaubte. Im weiteren Textverlauf erfährt man, dass dies nicht nur für einzelne Nutzer, sondern auch kollaborativ möglich sein sollte. Engelbart und seine Kollegen beschrieben viele faszinierende Techniken, wie das Verknüpfen von Texten miteinander, die Einteilung eines Bildschirms in verschiedene Bereiche und die räumliche Auswahl von Operationen am Bildschirm. Damit das alles möglich war, brauchte es natürlich einen leistungsfähigen Computer, aber eigentlich gab es solche Computer in vertretbarer Größe und mit vertretbarem Budget noch gar nicht. Engelbart und seine Kollegen nutzten daher letztlich einen universitären Großrechner einfach so wie einen modernen PC.

Eines der Konzepte von NLS war es, die Nutzer keine Funktionsnamen eingeben zu lassen, sondern die Funktionen am Bildschirm zur Auswahl anzubieten. Damit das möglich war, brauchte es etwas, was Engelbart und Kollegen „Operand Selecting Device“ nannten. Die Gruppe testete eine Reihe von Geräten, die zu diesem Zweck verwendet werden konnten, darunter auch Joysticks und die von SAGE und Sketchpad bekannten Lichtgriffel. Als das vielversprechendste Eingabegerät stellte sich ein Konstrukt namens „Mouse“ heraus¹¹, deren ersten Prototypen sie 1964 selbst entwickelt hatten. Gegenüber dem Lichtgriffel hatte die Maus vor allem den Vorteil, dass nicht direkt auf den vertikalen Bildschirm gezeigt werden musste, was sehr ermüdend sein konnte und auch den Nachteil hatte, dass man stets den Inhalt mit den eigenen Fingern verdeckte. Bei der Maus wird stattdessen ein „bug“, wir würden heute „Mauszeiger“ sagen, auf dem Bildschirm positioniert.

Auf dem Bild sehen Sie einen Nachbau des frühen Maus-Prototypen. Wie Sie sehen, handelte es sich um ein erheblich einfacheres Gerät als die deutsche Rollkugel. Auf der Unterseite der Maus befanden sich zwei Rollen. Diese Rollen waren so gestaltet, dass sie sich drehten, wenn die Maus längs der Rolle bewegt wurde, und einfach rutschten, wenn die Bewegung quer zur Rolle erfolgte. Die Bewegung der Maus wurde in NLS in eine Bewegung des „bug“ auf dem Bildschirm umgesetzt. Vorgestellt wurde die Maus 1968 in der „Mother of All Demos“, bei dem auch die anderen innovativen Features des Systems präsentiert wurden.

Wir haben nun eine deutsche und eine amerikanische Maus. Beide wurden unabhängig voneinander entwickelt. Die deutsche Rollkugel wurde zur Marktreife gebracht und war erheblich solider gebaut – sie war allerdings kein Erfolg und geriet in Vergessenheit. Unter anderem mag das daran gelegen haben, dass die Rollkugel für ein System entwickelt wurde, für das eine grafisch-räumliche Bedienung allenfalls eine Ausnahme war. Engelbarts Maus war seinerzeit eher ein „Proof of Concept“. Das System, an dem sie eingesetzt wurde, war allerdings eines, das stark auf die grafisch-räumliche Bedienung ausgerichtet war. Auch wenn Engelbarts Maus noch kein fertiges Produkt war und auch seine direkten Weiterentwicklungen keine Verbreitung außerhalb des SRI hatten, haben seine Entwicklungen am NLS mehr Einfluss auf die weitere Nutzungsschnittstellen-Entwicklung gehabt, als die Rollkugel von Telefunken, denn viele, die an der Maus des NLS mitentwickelten, landeten später am Xerox PARC, wo die Maus zum zentralen Eingabegerät innovativer Computer wurde. Dieser größere Einfluss schmälert die Entwicklungsleistung von Herrn Mallebrein und seinen Kollegen nicht im Geringsten, es zeigt vielmehr, wie sehr es manchmal eine Frage der Begleitumstände oder letztlich sogar ein wenig des Zufalls ist, welche technischen Entwicklungen sich durchsetzen und welche nicht.

Das Experiment – Der Xerox Alto

Die ersten grafischen Nutzungsschnittstellen der Art, wie wir sie auch heute noch verwenden, wurden am Xerox PARC entwickelt. Anders als in Deutschland ist Xerox (gesprochen etwa „Sie-Rocks“) in den USA ein Name, den absolut jeder kennt. Die Firma hat ihren Namen von der Trockenkopie, die im Englischen „Xerography“ genannt wird. Xerox hielt das Patent an dieser Kopiertechnik, auf der alle modernen Fotokopierer und Laserdrucker basieren. Der Firmenname „Xerox“ wird in den USA so sehr mit Fotokopien verbunden, wie Google mit Websuche und bei uns in Deutschland Zewa mit Küchenrollen. „A Xerox“ ist dort ein Ausdruck für eine Fotokopie und „to xerox“ steht für das Fotokopieren. Innovationen in der Computer- und Nutzungsschnittstellen-Technik erwartet man nun nicht unbedingt bei einer Firma, die Kopierer herstellt, doch gerade diese Firma gründete eines der wichtigsten Forschungsinstitute für innovative Nutzungskonzepte und Computer. Xerox wollte auch in der Zukunft der Büro- und Informationstechnik mit von der Partie sein und gründete daher 1970 das Xerox Palo Alto Research Center (Xerox PARC). Bemerkenswert an der Philosophie von Xerox war, dass die Forscher, die am PARC beschäftigt waren, in dem, was sie taten und woran sie forschten, im Prinzip völlig frei waren. Das Resultat war eine unglaubliche Kreativität und Innovationskraft. Wenn man sich die Liste dessen anguckt, was alles am PARC entwickelt und konzipiert wurde, kann man manchmal den Eindruck gewinnen, dass nahezu alle moderne Computertechnik, die wir heute noch nutzen, dort ihren Anfang nahm. Zentrale Konzepte der Objektorientierung, einer Programmiertechnik, wurden am PARC entwickelt, der Ethernet-Standard stammt vom PARC, der Laserdrucker und vieles, vieles mehr.

Eines der frühen zentralen Projekte am Xerox PARC war die Entwicklung des Alto. Die ersten Konzepte zu diesem Rechner wurden schon 1972 entwickelt und im März 1973 wurde der erste Alto fertiggestellt. Der Alto war wohl der erste Computer, sieht man mal von NLS ab, der für seine Bedienung im großen Stile auf die Maus setzte. Er nimmt damit und vor allem mit der für ihn entwickelten Software eine sehr wichtige Rolle in der Entwicklung der grafischen Nutzungsschnittstelle ein. Erstaunlicherweise wird er in vielen Computergeschichten entweder vergessen oder mit dem Xerox Star von Anfang der 1980er Jahre in einen Topf geworfen. Für diesen und quasi für alle grafischen Nutzungsschnittstellen, die in den 1980er-Jahren folgten, war der Alto ein Grundstein, aber er war eben doch etwas eigenes, das es sich zu betrachten lohnt.

Eine Dokumentation des PARC aus dem Jahr 1974 beschreibt den Xerox Alto als „personal computer system“¹². Eine interessante Wortwahl, denn üblicherweise lässt die Computergeschichte die Personal Computer ja mit dem Altair im Jahr 1975 beginnen. Die Entwickler bei Xerox verraten uns in der Dokumentation, was sie unter einem personal computer verstehen:

By ‘personal computer’ we mean a non-shared system containing sufficient power, storage and input-output capability to satisfy the computational need of a single user.

Diese Definition hätte später auch ziemlich gut auf IBMs Personal Computer von 1981 gepasst, denn Xerox zielte hier darauf ab, dass der Computer von einer einzelnen Person genutzt wird und quasi komplett für diese zur Verfügung steht. Dass der Computer dieser Person auch gehört im Sinne der Personal-Computer-Idee beim Altair, wurde hier nicht erwähnt und war wohl auch nicht das, was Xerox sich vorstellte, denn am PARC sollten ja die Bürocomputer der Zukunft entwickelt werden. Günstige Heimcomputer hatte man nicht im Blick¹³.

Technisch gesehen handelte es sich beim Xerox Alto um einen Minicomputer. Üblicherweise standen auf einem Tisch Bildschirm, Tastatur und die vom NLS-Projekt übernommenen Eingabegeräte Maus und „Chord Keyset“, einer Fünf-Finger-Tastatur. Diese Zusatztastatur war für die Bedienung der Alto-Programme sehr wichtig, da sie mit wichtigen Programmfunktionen belegt wurde. In der Regel unter dem Tisch stand die Prozessoreinheit in der Größe eines durchschnittlichen Kühlschranks. Ein Alto war für die damalige Zeit mit einem Minimum von 128 KB und einem Maximum von 512 KB mit sehr viel Speicher ausgestattet. In den Rechner waren zwei Wechselplattenlaufwerke eingebaut. Jede der Wechselplatten fasste 2,5 MB Daten. Der Bildschirm des Alto wurde hochkant verwendet, was auf die intendierte Nutzung als Bürorechner zurückzuführen ist, denn der Hochkant-Bildschirm kann den kompletten Inhalt eines Papierblattes anzeigen. Der Alto zeigte auf dem Bildschirm Inhalte im Grafikmodus an. Die Anzeige war rein schwarz-weiß (ohne Grautöne) mit einer für die damalige Zeit extrem hohen Auflösung von 606 x 808 Bildpunkten.

Wo Sie nun von den technischen Gegebenheiten dieses Rechners erfahren haben, erwarten Sie wahrscheinlich, dass er mit einem innovativen Betriebssystem mit einer spannenden Nutzungsschnittstelle ausgeliefert wurde. Wenn Sie sich nun das Grundsystem des Alto ansehen würden, wären Sie wahrscheinlich enttäuscht, denn der Computer verfügte über eine Kommandozeile mit der typischen Charakteristik dieser Interaktionsform. Interessant für uns sind nicht die Eigenschaften dieser Kommandozeile, sondern die Anwendungsprogramme, die am PARC für den Alto entwickelt wurden. Eigentlich all diese Programme hatten großen Einfluss auf das, was in den Jahrzehnten darauf kommen sollte. Hier eine nicht vollständige Aufstellung interessanter Programme:

Neptune: Ein Dateimanager mit zweispaltiger Darstellung und Datei- und Operationsauswahl per Mausbedienung. Neptune ist ein entfernter Vorgänger von heutigen Dateimanagern wie Explorer oder Finder.

Bravo (1974): Eine Textverarbeitung, die die Formatierung des Textes nicht nur grundsätzlich ermöglichte, sondern diesen auch direkt am Bildschirm anzeigen konnte. Bravo erlaubte die Verwendung verschiedener Schriftarten in einem Dokument und sogar die Einbindung von Bildern, die gleichzeitig mit dem Text am Bildschirm zu sehen waren. Bravo gilt allgemein als das erste Textverarbeitungssystem, das nach dem WYSIWYG-Prinzip arbeitete (What you see is what you get).

Gypsy (1975): Der Nachfolger von Bravo. Das Programm zeichnet sich durch eine „moduslose“ Oberfläche aus. Was das bedeutet, kann man sich am Verschieben eines Textblocks klarmachen. In einem modusbasierten System verschiebt man einen Textblock, indem man einen Verschiebemodus aktiviert. Das System bittet den Nutzer dann nacheinander, zunächst den zu verschiebenden Block zu markieren und dann die Stelle mit dem Zeiger anzufahren, an die man den Block verschieben möchte. Während der Modus aktiv ist, kann man mit dem Programm nur Text verschieben. Alle anderen Programmfunktionen stehen nicht zur Verfügung. Auch Bravo funktionierte noch so. In Gypsy wurde es nun anders gelöst. Eine spannende Erfindung in diesem Zusammenhang war etwas, was etwa dem nahekommt, was wir heute „Zwischenablage“ nennen. Gypsy verwendete den Begriff „Wastebasket“, was auf eine leicht andere Funktionsweise hindeutet. Der Wastebasket war dauerhaft am Bildschirm sichtbar. Die Bedienungsanleitung¹⁴ erläutert:

The Wastebasket has two lines but can be expanded at the expense of the document window. Whenever material is cut (deleted) it is put in the Wastebasket so that the operator can see what has been cut and have access to it for reinsertion.

Im Wastebasket landeten nur Inhalte, die aus dem Dokument gelöscht wurden. Für ein normales Kopieren oder Verschieben im Text war diese Ablage nicht notwendig. Man markierte bei gedrückter, rechter Maustaste den Ursprungstext und mit gedrückter, mittlerer Maustaste den Zielbereich. Drückte man nun die Taste PASTE auf der Fünf-Finger-Tastatur, wurde der Text von der Quelle in den Zielbereich kopiert – ganz ohne Wastebasket. Dieser konnte beim Einfügen aber durchaus ins Spiel kommen, denn da der vorher am Zielort vorhandene Text überschrieben wurde, landete dieser im Wastebasket und blieb damit verfügbar, um ihn gegebenenfalls an anderer Stelle wieder benutzen zu können.

Markup: Ein pixel-basiertes Grafikprogramm, ganz ähnlich dem späteren Apple Paint oder Microsoft Paint.

Draw: Ein Vektor-Grafikprogramm, das es ermöglichte, Texte, Figuren und Linien zu zeichnen. Alles Gezeichnete stand als Objekt zur Verfügung, konnte also auch als solches weiterverarbeitet und manipuliert werden.

Laurel und Hardy: Diese zwei E-Mail-Programme erlaubten nicht nur das Versenden von Nachrichten innerhalb des bürointernen Netzwerks (der Alto nutzte intensiv das ebenfalls am PARC entwickelte Ethernet), sondern sogar schon die Übertragung von Dokumenten und Zeichnungen.

Die Software des Alto war überaus innovativ. Mit dem Computer wurden frühe Erfahrungen damit gemacht, wie man die Grafikfähigkeit des Systems in der Nutzungsschnittstelle ausnutzte, indem man sowohl Elemente der Nutzungsschnittstelle als auch des zu bearbeitenden Inhalts am Bildschirm als räumliche Objekte darstellte und auch an Ort und Stelle bedienbar machte. Man kann die Leistung der Entwickler des Alto nur dann richtig würdigen, wenn man betrachtet, zu welchem Zeitpunkt die Geräte hergestellt und die Software programmiert wurde – nämlich in den frühen 1970er Jahren. Computernutzung bedeutete zu dieser Zeit in aller Regel Programmierung mit Lochkarten im Batch-Betrieb oder Terminal-Betrieb mittels Fernschreiber und Kommandozeile. Die räumlich-grafische Software des Alto war hier der Einstieg in eine ganz andere Welt.

Die Welt in Fenstern – Die Smalltalk-Umgebung

Von der einen Nutzungsschnittstelle des Xerox-Alto zu sprechen, ist eigentlich gar nicht sinnvoll möglich. Jedes der oben angesprochenen Anwendungsprogramme hatte seine ganz eigenen Arten der Steuerung und der Objekt-Interaktion. Verwendet man die Programme heute, kommt einem die Bedienung durchaus kompliziert und ungewohnt vor. Es gab noch nicht das heute quasi universelle Konzept von Buttons, Menüs, Icons, Fenstern oder Scrollbars, doch auch diese Spielart der Nutzungsschnittstellen hat ihren Anfang am Xerox PARC und am Alto in der Smalltalk-Programmierumgebung.

Smalltalk ist zunächst einmal eine am Xerox PARC entwickelte Programmiersprache, die in der Geschichte der objektorientierten Programmierung eine wichtige Rolle gespielt hat. Auch das heute in der Programmierung viel verwendete Model-View-Controller-Konzept¹⁵ hat seine Ursprünge in Smalltalk. Smalltalk war aber weit mehr als nur eine Programmiersprache. Ab der Version Smalltalk 76 war die Sprache eng verbandelt mit der Umgebung, in der entwickelt wurde. Wie Sie auf der Abbildung sehen, bestand die Nutzungsschnittstelle der Smalltalk-Umgebung aus einem grauen Hintergrund, auf dem Fenster angeordnet werden konnten. Diese Fenster waren Sichten von Smalltalk-Objekten oder laufenden Smalltalk-Programmen. Sie ließen sich auf dem Hintergrund verschieben, in der Größe ändern und soweit zusammenfalten, dass nur noch ihr Label zurückblieb. Die Fenster verfügten, wenn nötig, auf der linken Seite über eine Scrollbar, mit der ein Ausschnitt aus dem Inhalt gewählt werden konnte. Ein Klick mit der mittleren Maustaste auf ein Smalltalk-Objekt – und in Smalltalk war im Prinzip alles ein selektierbares Objekt – öffnete ein Menü. Dieses Menü enthielt unter anderem stets den Eintrag „examine“. Wenn Sie diese Funktion aufriefen, erhielten Sie Zugriff auf die Definitionen des Objekts. Vereinfacht kann man sagen, Sie erhielten Zugriff auf die hinter dem Objekt stehende Programmierung und konnten diese auch verändern – und das im laufenden System.

Programmieren in Smalltalk war etwas ganz anderes als der Umgang mit Programmierumgebungen, wie Sie sie vielleicht heute kennen, etwa wenn Sie mit XCode oder mit Microsoft Visual Studio programmieren. Lassen Sie mich das an einem kleinen Beispiel klarmachen, das erläutert, wie Sie mit ihrem Computer umgehen könnten, wenn die Nutzungsschnittstelle Ihres Windows- oder Macintosh-Rechners so funktionieren würde wie die Smalltalk-Umgebung. Programmierer mögen mir meine Sprachwahl verzeihen; ich versuche, die Eigenschaften von Smalltalk zu verdeutlichen, ohne zu viel Programmier-Fachvokabular zu verwenden. Wenn Ihr Windows oder Ihr MacOS so funktionieren würde wie die Smalltalk-Umgebung, dann stünde alles, was Sie am Bildschirm als Objekt sehen, Ihnen auch in seiner dahinterstehenden Programmierung zur Verfügung und es wäre Ihnen möglich, diese Programmierung im laufenden Betrieb zu ändern. Nehmen wir an, Sie hätten immer ein Problem damit, dass Sie Buttons versehentlich auslösen. Sie könnten dem nun abhelfen, indem Sie sich in einem Programm, das einen Button hat, mit Hilfe der Programmierumgebung durchhangeln, bis Sie bei der Grundspezifikation eines Buttons angekommen sind. Diese ändern Sie nun so ab, dass ein Button zum Beispiel nur dann auslöst, wenn Sie auch die SHIFT-Taste auf der Tastatur drücken. Ab dem Zeitpunkt, an dem Sie diese Neudefinition durchgeführt hätten, würde sie gelten und zwar für alle Buttons im kompletten System. Das Besondere wäre hier nicht, dass Sie das Verhalten einer Standardkomponente ändern können – das können Sie grundsätzlich bei jeder Programmierung, wenn es zugegebenermaßen auch nicht sehr einfach ist – sondern, dass Sie das zur Laufzeit des Systems und für das ganze System machen könnten, dass Sie also keine Programme neu in Maschinencode übersetzen und neu starten müssten.

Sehr bemerkenswert war auch die Verbindung von Programmcode und formatierbarem Text im gleichen Dokument. Nehmen wir ein Fenster, das den Inhalt eines Dokuments am Bildschirm anzeigt. Der Text dieses Dokuments konnte im Fenster direkt formatiert werden, also etwa in verschiedene Schriftarten, Schriftgrößen, fett, kursiv und unterstrichen gesetzt werden. Das für sich ist zwar nicht trivial, aber auch nicht übermäßig interessant. Spannend ist aber, dass die Dokumente auch Smalltalk-Code enthalten konnten und dieser an Ort und Stelle ausgeführt werden konnte. Dazu musste der Text nur markiert, das Menü aufgerufen und der Programmcode mit „Do it“ direkt an Ort und Stelle ausgeführt werden.

Der Desktop – Xerox Star und Apple Lisa

Der Alto ist ein in der Computergeschichte gerne übersehener Meilenstein, dem ich hier natürlich auch nur in Streiflichtern gerecht werden konnte. Zentrale Konzepte aktueller grafischer Nutzungsschnittstellen inklusive der Vorgänger heutiger Standardsoftware wurden auf und mit diesem Computer entwickelt. Vieles war seiner Zeit voraus. Die Textverarbeitung Bravo und die Smalltalk-Umgebung (beide von 1976) sind hier besonders zu erwähnen. Aber: Der Rechner war sehr experimentell angelegt. Es wurden im Laufe der 1970er Jahre etwa 2.000 Geräte gebaut und größtenteils innerhalb von Xerox und dem PARC eingesetzt. Erst Ende der 1970er wurde der Rechner für 32.000 Dollar (2021: 118.000 Dollar) verkauft.

Es gehört zur populären Computergeschichte, dass dem Apple-Mitgründer Steve Jobs bei einem Besuch im Xerox PARC Anfang der 1980er Jahre Smalltalk gezeigt wurde und er so begeistert war, dass er das Design der sich in der Entwicklung befindenden Apple Lisa, die er verantwortete, komplett umkrempeln ließ. Die „Lisa“ wurde damit zu einem der ersten beiden kommerziell hergestellten Computersysteme mit der Desktop-Metapher. Bereits zwei Jahre bevor Apple seinen ersten Rechner mit der Desktop-Metapher vorstellte, brachte Xerox selbst allerdings das Xerox 8010 Information System auf den Markt. Die auf diesem Computer laufende Software hatte die Bezeichnung „Star“. Es hat sich jedoch eingebürgert, dass auch der Computer als solches als „Xerox Star“ bezeichnet wird.

Die Zielgruppe von Xerox Star und Apple Lisa waren nicht Techniker und schon gar nicht Computer-Bastler – für diese waren beide Computer viel zu teuer – sondern Menschen, die in ihrer Arbeit mit Dokumenten zu tun hatten, Texte schrieben, Illustrationen anfertigten oder Listen verwalteten. Diese Nutzer kannten sich in diesen Bereichen gut aus. Computertechnik war in den meisten Fällen nicht ihr Interesse. Star und Lisa waren daher die ersten beiden nennenswerten Computersysteme, die darauf ausgelegt wurden, von Nutzern bedient zu werden, die explizit nichts von Computern verstanden. Es dauerte ziemlich lange, bis es wieder Systeme gab, die den Nutzern so wenig technische Kenntnis abverlangten wie diese Rechner. Erst die PDAs der 1990er Jahre konnten das wieder für sich beanspruchen.

Abgesehen vom Umstand, dass der Star und die Lisa beide über ein Desktop-Konzept verfügten und ihre Bedienung zu einem großen Teil auf der Maus basierte, waren die Rechner schon im äußeren Erscheinungsbild ziemlich unterschiedlich. Der Xerox Star war ein sehr wuchtiges Gerät, das aussah wie ein zu breit geratener PC-Tower oder ein schmaler Kühlschrank. Er fand unter dem Tisch Platz. Auf dem Tisch standen nur Bildschirm, Tastatur und Maus, die oben abgebildet sind. Ein Xerox Star verfügte über bis zu 1,5 MB RAM, eine lokale Festplatte von 10 bis 40 MB und einen für die damalige Zeit riesigen hochauflösenden 17-Zoll-Monitor mit 1024 x 800 monochromen Bildpunkten. Das System konnte zwar isoliert genutzt werden, war aber vom Konzept her auf die Nutzung in einem Firmennetzwerk ausgerichtet. Ein typischer Xerox Star wurde per Ethernet mit Dateiservern und anderen Computern verbunden, was unter anderem auch das Verschicken von E-Mails im Firmenkontext erlaubte. Zwar bedeutete die Verwendung des Stars eine intensive Nutzung der Maus, die über zwei Tasten verfügte, doch spielte auch die Tastatur eine große Rolle. Neben der Möglichkeit, Zahlen und Buchstaben einzugeben, verfügte diese Tastatur nämlich über eine Reihe von Tasten für allgemeine Funktionen wie Löschen, Kopieren, Verschieben oder das Anzeigen von Eigenschaften.

Die Apple Lisa hatte ein ganz anderes Erscheinungsbild: Sie war ein sehr kompaktes All-In-One-Gerät. Das komplette Gerät stand auf dem Schreibtisch. Bildschirm und Zentraleinheit waren integriert. Die erste Version der Lisa verfügte über zwei 5,25-Zoll-Laufwerke für 871-KB-Disketten. Eine spätere Revision, die ebenfalls oben abgebildet ist, verfügte über ein einziges 3,5-Zoll-Laufwerk für 400-KB-Disketten. Ausgestattet war die Apple Lisa mit üppigem 1 MB RAM. Sie wurde in der Regel mit einer 5-MB-Festplatte verwendet, die extern angeschlossen werden musste (auf der Abbildung oben auf das Gerät gestellt). Der Bildschirm war mit 12 Zoll Größe und einer Auflösung von 720 x 360 Pixeln im Vergleich zum Star ziemlich klein. Die Maus der Lisa verfügte nur über eine einzige Taste und auch die Tastatur war einfacher gestaltet als die des Star. Spezielle Sondertasten wie am Star gab es nicht. Die Tastatur spielte damit bei der Bedienung der Lisa eine erheblich geringere Rolle. Alle Operationen und Funktionsaufrufe wurden per Maus durchgeführt. Die Tastatur musste und konnte nur zum Eingeben von Texten genutzt werden.

Der Desktop des Xerox Star

Sowohl die Apple Lisa als auch der Xerox Star hatten ein komplexes Desktop-Konzept, das sich von aktuellen Nutzungsschnittstellen, die über ein gleichnamiges Konzept verfügen, also Windows, MacOS und die üblichen Linux-Oberflächen, durchaus in wichtigen Punkten unterschied.

Das Grundkonzept der Nutzungsschnittstelle des Star war eine „Desktop“ genannte Hintergrundfläche, auf der die Objekte der aktuellen Arbeit, also Textdokumente, Grafiken, Datenbankobjekte und Tabellen abgelegt wurden. Ich nenne diese Art von Objekten im Folgenden der Einfachheit halber zusammenfassend „Dokumente“. Die Dokumente wurden auf dem Desktop üblicherweise in einer verkleinerten Form, als sogenanntes „Icon“, dargestellt. Ein Dokument konnte durch Öffnen genauer betrachtet werden. Dazu wurde zunächst das Objekt mit der Maus selektiert und dann auf der Tastatur die Open-Taste gedrückt. Das Dokument wurde dann zu einem Fenster vergrößert. Das Icon selbst verblieb als weißer Schatten auf dem Desktop. Auf der Abbildung oben sehen Sie das Dokument „Star picture“ geöffnet als Fenster und daneben als komplett weißes Icon auf dem Desktop.

Finden Sie die Formulierung „Das Dokument wurde dann zu einem Fenster vergrößert.“ eigenartig? Heute würde man das wohl nicht so formulieren. Man würde eher sagen: „Ein Doppelklick öffnet die Datei im entsprechenden Anwendungsprogramm.“ Beim Star konnte man das so aber nicht sagen, denn in der Nutzungsschnittstellen-Welt des Star gab es gar keine Anwendungsprogramme¹⁷. Sie kamen in der Nutzungswelt nicht vor. Es war nicht möglich, eine Textverarbeitung oder ein Grafikprogramm per Icon oder per Name anzusprechen und zu starten. Die Interaktionswelt funktionierte anders. Es gab nur Dokumente und Ordner, die als Icons oder in Fenster-Form sichtbar waren. Neue Dokumente wurden dadurch erzeugt, dass auf dem Desktop liegende Dokumente kopiert wurden. Dazu wurde ein Icon ausgewählt, auf der Tastatur „Copy“ gedrückt und mit der Maus eine Zielposition ausgewählt. Die Grundoperation der Arbeit mit dem Star war folglich – sehr passend für einen Kopierer-Hersteller – das Duplizieren von Vorlagen. Ein Initial-Set von leeren Dokumenten aller Art (inklusive Ordnern) lag für diesen Zweck in einem „Directory“ auf dem Schreibtisch bereit. Eine Vorlage musste aber keinesfalls ein leeres Dokument aus dem Directory, sondern konnte sehr gut auch ein vorher verfasstes Dokument sein. Der Star-Bedienungsphilosophie entsprach zum Beispiel, dass sich ein Nutzer eine Briefvorlage mit einem Blindtext erstellte, diese auf dem Desktop ablegte und später bei Bedarf duplizierte, wenn ein Brief geschrieben werden sollte.

Man konnte am Star mit mehreren Dokumenten gleichzeitig arbeiten, indem mehrere Icons in einem Fenster geöffnet wurden. Mehrere Programme liefen also gleichzeitig. Den Fachbegriff für diese Betriebsart haben Sie sicher schon einmal gehört: Multitasking. Die ursprüngliche Betriebssystemversion des Star ordnete die Fenster automatisch an. Spätere Versionen erlaubten überlappende Fenster. Wenige Computer boten 1981 Multitasking und keines davon, von rein experimentellen Systemen mal abgesehen, machte die verschiedenen Programme bzw. Dokumente in grafisch-räumlicher Darstellung gleichzeitig sichtbar.

Das Desktop-Konzept des Star war konsequenter als das heutiger Computersysteme. Der Desktop war der zentrale Ort für die Objekte der aktuellen Arbeit. Umgesetzt wurde hier eine klare Unterscheidung zwischen diesem Arbeitsbereich und der Ablage von Dokumenten. Die Ablage bestand innerhalb der Oberfläche aus Icons, die wie Aktenschränke aussahen. Hinter ihnen standen Datei-Ablage-Server, die per Netzwerk mit dem Star verbunden wurden. Dokumente konnten in diese Aktenschränke, „Drawer“ genannt, verschoben oder kopiert werden. Wenn ein Dokument dann aus einem Drawer wiederverwendet werden sollte, musste es erst auf den Desktop verschoben oder kopiert werden, denn Dokumente konnten immer nur vom Desktop aus bearbeitet werden. Das mag kompliziert erscheinen, ist aber letztlich in der Nutzungsschnittstellen-Welt folgerichtig, wenn man das Konzept des Desktops als dem Ort für die aktuellen Arbeitsobjekte ernst nimmt. Die Dokumente der aktuellen Arbeit wurden auf den Schreibtisch gelegt. Wollte man mit etwas arbeiten, musste man es erst dort hinlegen. Man fing nicht etwa an, direkt im Aktenschrank an Dokumenten herumzuwerkeln. Ob diese Notwendigkeit, Dokumente erst auf den Schreibtisch zu legen, übrigens wirklich darauf zurückzuführen ist, dass man es bei Xerox für nötig hielt, die Arbeitsweise im Büro so genau nachzuahmen, kann durchaus bezweifelt werden, denn es gibt einen sehr plausiblen technischen Grund dafür, dass Dokumente nicht aus einer Dateiablage heraus geöffnet werden können. Die Dateiablagen sind Dateiserver im Netzwerk, der Desktop hingegen ist auf der lokalen Festplatte gespeichert. Dateien direkt in der Dateiablage zu bearbeiten, hätte eine hohe Netzlast verursacht und zudem Probleme provoziert, wenn verschiedene Nutzer an verschiedenen Geräten auf das gleiche Dokument zugegriffen hätten. Durch die Einschränkung, dass nur Dokumente auf dem Desktop bearbeitet werden konnten, wurden derartige Probleme vermieden.

Der Desktop der Apple Lisa

Die Nutzungsoberfläche der Apple Lisa ähnelte auf den ersten Blick viel mehr heutigen Nutzungsschnittstellen als die des Xerox Star. Es handelte sich um eine typische Apple-Oberfläche mit einer Menüleiste am oberen Bildschirmrand, wie sie auch heute noch üblich ist. Auf dem Desktop befand sich ein Icon für die Festplatte und eines für den Papierkorb. Diese optische Ähnlichkeit mit heutigen Systemen kann einen leicht in die Irre führen, denn schaut man sich die Funktionsweise des Lisa-Desktops genauer an, gab es doch große Unterschiede zu heutigen Systemen, denn der Desktop spielte bei der Lisa als der Ort, an dem sich die Dokumente der aktuellen Arbeit befinden, eine viel größere Rolle als heute.

Im Gegensatz zum Xerox Star standen bei der Lisa Anwendungsprogramme durchaus als Objekte zur Verfügung. Programme wurden auf Diskette ausgeliefert. Man konnte sie entweder direkt von dort verwenden oder aber, was natürlich sinnvoller war, auf die eigene Festplatte kopieren, indem man die Icons von der Diskette auf die Festplatte zog. Apple implementierte einen ziemlich heftigen Kopierschutz. Jede Lisa verfügte über eine eigene Seriennummer, die nicht etwa nur aufgedruckt war, sondern im Rechner selbst in einem Chip gespeichert war. Beim ersten Zugriff auf die Programme, also beim Starten oder beim Kopieren, wurden die Programmdisketten „serialisiert“. Das Programm lief fortan nur noch auf genau dieser einen Lisa.

Nur einige werkzeugartige Programme, wie etwa ein Taschenrechner oder die Uhr, wurden bei der Lisa direkt per Doppelklick gestartet. Die anderen Programme lagen zwar als Objekte auf der Festplatte, startete man sie jedoch direkt, erhielt man nur eine Meldung, die einen darüber informierte, dass man es falsch gemacht hat. Die eigentliche Nutzung der Programme erfolgte ähnlich wie beim Xerox Star über den Zugriff auf Dokumente, die, in der gleichen Logik wie beim Star, in ein Fenster vergrößert wurden. Neue Dokumente wurden, ähnlich wie beim Star, dadurch erzeugt, dass bestehende Dokumente dupliziert wurden. In der Arbeitsweise des Star lag es bereits nahe, einige Dokumente zu Vorlagen zu erklären, also etwa eine Briefvorlage zu erzeugen. Was eine Vorlage war, wurde beim Star allerdings nicht technisch explizit gemacht. Die entsprechenden Dokumente waren Dokumente wie alle anderen auch. Apple dachte sich für die Lisa das erheblich ausgefeiltere Schnittstellenkonzept der Abreißblöcke (englisch: „stationery pad“) aus, das in der Bedienungsanleitung des Systems wie folgt beschrieben ist:

Each stationery pad represents an infinite supply of either blank or customized paper, which you use for creating new documents. The design on the pad matches the design on the tool and documents associated with the pad. […] Each tool comes with a pad of blank stationery, and you can make your own custom stationery pads.

Mit jeder Software-Anwendung, die mit Dokumenten arbeitete, wurde also ein entsprechender Abreißblock mitgeliefert. Wenn man diesen Abreißblock zu öffnen versuchte oder einen Doppelklick machte, wurde ein Blatt abgerissen, was technisch bedeutete, dass das leere Dokument kopiert wurde, die Kopie neben dem Abreißblock abgelegt und mit einem automatischen Titel versehen wurde. Auch eigene Dokumente mit Inhalt oder sogar ganze Ordner inklusive ihres Inhalts konnten bei der Lisa zum Abreißblock gemacht werden. Die Funktionsweise im Umgang war damit immer gleich. Ein Doppelklick auf so eine selbst erzeugte Vorlage erstellte eine Kopie am gleichen Ort, die dann in der Folge bearbeitet werden konnte.

Bei der Lisa spielte der Desktop als Ort für die aktuellen Arbeitsdokumente eine große Rolle. Apple hat sich hier ein ausgefeilteres System überlegt als Xerox bei seinem Star, was teils auch daran liegen dürfte, dass es sich bei der Lisa um ein System handelte, das auf eine lokale Festplatte und weniger auf Dateiserver ausgerichtet war. Im Gegensatz zum Star musste man bei der Lisa die Dokumente, die man bearbeiten wollte, nicht erst auf den Desktop bringen – das System erledigte diesen Schritt vielmehr quasi nebenbei für den Nutzer. Grundsätzlich hatte jedes Dokument und jeder Ordner bei der Apple Lisa einen Ort in der Dateiablage der Festplatte¹⁸. Diese Dokumente und Ordner lagen, wenn gerade mit ihnen gearbeitet wurde, auf dem Desktop, ihr Ort innerhalb der Dateiablage blieb aber bestehen. Sie können das auf obiger Abbildung gut am Dokument „Important Information“ sehen, das sich auf dem Desktop befindet, aber auch an seinem eigentlichen Speicherort auf der Festplatte als ausgegrautes Icon zu sehen ist. Diese zweite Position in der Dateiablage spielte bei der Verwaltung der Arbeitsobjekte an der Lisa eine wichtige Rolle.

Es gab eine Reihe von Möglichkeiten, wie ein Dokument auf den Schreibtisch kommen konnte. Die vielleicht naheliegendste Möglichkeit war, ein Dokument per Drag and Drop auf den Schreibtisch zu ziehen. Wenn man das tat, wurde das Dokument faktisch weder verschoben noch kopiert, sondern nur auf dem Desktop zugreifbar gemacht und am ursprünglichen Speicherort „ausgegraut“. Eine andere Methode, ein Dokument auf den Desktop zu legen, erfolgte aus einem Anwendungsfenster heraus. Sie konnten bei der Lisa im Gegensatz zum Star ein Dokument direkt am Speicherort auf der Festplatte öffnen und bearbeiten. Wenn Sie mit der Bearbeitung fertig waren, hatten Sie nun aber, im Gegensatz zu anderen Systemen, zwei Möglichkeiten: Sie konnten zwischen „Save & Put Away“ und „Set Aside“ wählen. Ersteres wählten Sie, wenn Sie das Dokument nicht mehr brauchten. Letzteres, also „Set Aside“, schloss das Anwendungsfenster und stellte das Dokument auf dem Desktop zur späteren Verwendung bereit – und zwar ganz unabhängig davon, ob es vorher vom Desktop aus geöffnet wurde oder nicht¹⁹. Dieses System sorgte dafür, dass quasi automatisch all das, was man noch weiter verwenden wollte, auf den Desktop gelangte. Brauchte man Dokumente oder Ordner, die auf dem Desktop lagen, nun nicht mehr, konnte man sie in den Papierkorb legen – dann wurden sie endgültig gelöscht. Wenn man sie für die spätere Bearbeitung behalten wollte, musste man sie wieder ablegen. Dafür reichte es, sie einfach zu markieren und im Menü „Put Away“ auszuwählen. Die Dokumente wurden dann gespeichert und an ihren eigentlichen Ort auf der Festplatte zurückgelegt.

Genau wie beim Star war bei der Lisa der Desktop der Ort für die aktuellen Arbeitsmaterialien. Alles, was gerade bearbeitet wurde, lag auf dem Desktop als Icon bereit oder war als Fenster geöffnet. Dass ein solcher Arbeitsprozess natürlich länger sein konnte als ein Arbeitstag, hat Apple bei der Gestaltung der Nutzungsschnittstelle durchaus vorgesehen. Es war nicht nötig, bei Arbeitsende alles abzuspeichern, dann in die Dateiablage einzusortieren und beim nächsten Mal wieder zusammenzusuchen. Das System nahm dem Nutzer diese Aufgabe ab. Drückte man auf den Ausschalter der Lisa, wurden alle Änderungen automatisch gespeichert. Beim nächsten Start des Systems wurden die Dokumente, die vorher auf dem Desktop lagen, automatisch wieder an ihren Platz gelegt und, sofern sie vorher geöffnet waren, auch automatisch erneut geöffnet. Die Arbeitsvorgänge wurden dadurch unabhängig von den technisch-organisatorisch bedingten Rechnersitzungen.

Fazit

Die Apple Lisa und der Xerox Star schafften eine Nutzungsschnittstellen-Welt, die von technischen Aspekten der Maschine sehr unabhängig war. Zwar brauchten alle interaktiven Computer virtuelle Objekte und boten natürlich Anwendungsobjekte als solche an, doch bedurfte es bei den meisten Nutzungsschnittstellen auch Kenntnisse über die Objekte der technischen Computerwelt und ihrer Operationen. Allen voran waren das Programme als Objekte und Operationen wie das Laden und Speichern von Dateien. Lisa und Star funktionierten da anders: Es gab kein Konzept eines Programms, das man verwendete, um eine Datei in den Arbeitsspeicher einzulesen. Angeboten wurde vielmehr eine Darstellung eines Objektes in einem Fenster, also in seiner detailreichen und bearbeitbaren Form. Das Dokument wurde in beiden Systemen zum zentralen Objekt der Interaktion und der Desktop zum zentralen Ort der aktuellen Arbeitsmaterialien. Es gab übrigens in beiden Systemen keine „Speichern unter“-Funktion. Diese hätte in die angebotene Objektwelt auch nicht gut hineingepasst, denn durch diese Funktion würde ja eine Anwendung eine Aufgabe ausführen, die ein neues Dokument erzeugt. Eine solche Funktion ergibt aber keinen Sinn, wenn das Fenster nicht ein Programm, sondern ein Dokument ist. Die Laden- und Speichern-Funktionen an sich, also im Sinne einer Anwendung, die eine Datei in den Arbeitsspeicher einliest oder den Arbeitsspeicherinhalt in einer Datei ausgibt, ergab in den Dokumenten-Welten von Star und Lisa schlichtweg keinen Sinn. Zwar gab es bei der Lisa ein „Save & Continue“ und auch dem „Put Away“ war stets ein „Save“ an die Seite gestellt – dies hatte aber eher Sicherheitsgründe, um beispielsweise einen Bearbeitungsstand nicht zu verlieren, wenn etwa der Strom ausfiel oder der Rechner eine Funktionsstörung hatte. Funktionierte alles richtig, musste man eigentlich nie explizit speichern, denn das passierte automatisch, wenn die Dokumentfenster geschlossen oder, im Falle der Lisa, die Dokumente zurückgelegt wurden.

Spätere Nutzungsschnittstellen mit Desktop-Konzept, wie wir sie noch heute großteils nutzen, sind nicht mehr so ausgefeilt wie Star und Lisa. Das kann man bedauern – dass es so gekommen ist, hat aber durchaus Gründe, auf die ich im folgenden Kapitel genauer eingehe. Um es kurz zu sagen: Die Arbeitsweise von Star und Lisa erforderte einen erheblichen Hardware-Einsatz, der die Rechner so teuer machte, dass beide Computer als wirtschaftliche Misserfolge angesehen werden müssen. Günstige Rechner wie der Apple Macintosh folgten, doch ihre erheblich sparsamere Hardware-Ausrüstung machten derart ausgeklügelte Nutzungskonzepte wie die der Lisa unmöglich.

Fenster jetzt auch für zu Hause

Die im Kapitel „Schreibtisch mit Fensterblick“ vorgestellten Systeme Xerox Alto, Xerox Star und Apple Lisa haben die Nutzungsschnittstellen von Computern mit Konzepten wie dem Desktop, Fenstern, Menüs und mit ihrer Optimierung für die Mausbedienung und damit auf grafisch-räumliche Eingaben neu definiert. Wirklich große Verbreitung hatten die Rechner aber nicht. Dies lag nicht zuletzt daran, dass sie aufgrund ihrer hohen technischen Anforderungen extrem kostspielig waren. Obwohl für sich genommen kein Erfolg, wurden Alto, Star und Lisa die Grundlage für die 16-Bit-Personal-Computer der Mitte der 1980er Jahre. Bis zur Vorstellung des Apple Macintosh im Jahr 1984 bedienten sich alle populären Heim- und Bürorechner (also Apple II, Commodore PET, C64, IBM PC, usw.) des Kommandozeilen-Paradigmas. Einzelne Anwendungen wie WordStar, VisiCalc, später Lotus 1-2-3 und Word nutzten die Räumlichkeit des Bildschirms, basierten aber grundsätzlich auf Textdarstellungen und verfügten nicht über eine einheitliche Nutzungsschnittstelle. Die Grafikfähigkeiten der Computer, soweit vorhanden, wurden für Spiele und zur Wiedergabe von Inhalten genutzt, etwa für Business-Grafiken, nicht aber für die Nutzungsschnittstelle.

Apple Macintosh – Der Kleine

Ein Jahr nach der Apple Lisa, also im Jahr 1984, präsentierte Apple mit großem medialen Aufwand einen kleinen Computer mit dem Namen „Macintosh“. Mitunter wird behauptet, dass der Rechner entwickelt worden sei, weil die Lisa nicht erfolgreich war. So kann es aber nicht gewesen sein, denn es war schlichtweg gar nicht möglich, in nur einem Jahr einen komplett neuen Computer samt so komplexer Nutzungsschnittstelle zu entwickeln. Die Entwicklung beider Computer verlief größtenteils parallel. Nachdem der Macintosh zunächst als günstiger, textbasierter Computer geplant war, wurde die Entwicklung schon etwa ab 1981 in Richtung eines Computers mit grafischer Nutzungsschnittstelle geändert. Diese Schnittstelle war auf den ersten Blick der Nutzungsschnittstelle der Lisa sehr ähnlich. Der Rechner wurde hauptsächlich per Maus bedient, es gab Fenster, die am Bildschirm verschoben werden konnten, es gab eine ständig sichtbare Menüleiste am oberen Bildschirmrand und das Betriebssystem präsentierte sich dem Nutzer als graue Fläche, auf der Dokumente abgelegt werden und auf der Fenster verschoben werden konnten, die die Inhalte von Datenträgern als Datei-Icons anzeigten. Diese Fläche wurde, genau wie bei der Lisa, „Desktop“ genannt.

Der Computer wurde in den ersten Jahren mit „Lisa Technology“ beworben. Eine typische Lisa kostete 10.000 Dollar (entsprechend 26.950 Dollar im Jahr 2021). Mit 2.500 Dollar war der Macintosh viel günstiger, allerdings war er ihr gegenüber technisch stark eingeschränkt. Zwei dieser Einschränkungen hatten zur Folge, dass die Nutzungsschnittstellen-Welt des Macintosh bei genauer Betrachtung doch bedeutend anders funktionierte als die der Lisa. Die erste Einschränkung betraf den Arbeitsspeicher. Die Lisa hatte einen für damalige Zeit sehr groß bemessenen Speicher von 1 MB. Beim ersten Macintosh wurde hier extrem gespart. Er verfügte nur über 128 KB Arbeitsspeicher. Das war zwar doppelt so viel wie bei Heimcomputern der damaligen Zeit mit ihren üblichen 64 KB, doch für ein grafisches System, das auch für komplexere Aufgaben wie Textverarbeitung samt grafischer Anzeige des Texts genutzt werden sollte, war das sehr knapp bemessen. Die zweite gewichtige Einschränkung betraf den Massenspeicher. Eine Lisa wurde in aller Regel mit einer Festplatte betrieben. Die hatte zwar für heutige Verhältnisse eine geradezu winzige Größe von 5 oder 10 MB, erlaubte zur damaligen Zeit aber, alle Anwendungsprogramme und viele Dokumente komfortabel gleichzeitig in schnellem Zugriff zu haben. Der Macintosh konnte zwar später auch Festplatten ansprechen, das Betriebssystem war aber auf reinen Disketten-Betrieb ausgelegt. Das Diskettenlaufwerk war natürlich nicht nur viel langsamer als eine Festplatte, mit nur 400 KB war die Menge der auf einer Diskette speicherbaren Daten und Programme ebenso bescheiden.

Die Einschränkungen auf der Ausstattungsseite hatten Auswirkungen auf die Funktionsweise der Nutzungsschnittstelle. Im Gegensatz zur Lisa war der Macintosh eine Single-Tasking-Maschine, konnte also nur ein Programm zur gleichen Zeit ausführen. Mehrere Programme passten schlichtweg nicht in den knapp bemessenen Speicher. Eine Auslagerung von Speicherinhalten auf den Massenspeicher – die heute typische Technik, wenn der Arbeitsspeicher nicht ausreicht – war ohne eine schnelle Festplatte nicht möglich, und über diese verfügte der Macintosh zunächst ja nicht. Der Single-Tasking-Betrieb änderte natürlich die Art und Weise, wie mit dem System gearbeitet werden konnte. Hatte man ein Dokument in einer Anwendung geöffnet, hatte man keinen Zugriff mehr auf die Dateiverwaltung und den Desktop. Wollte man nun Dateiverwaltungsoperationen durchführen, musste man die gerade geöffnete Anwendung erst wieder verlassen. Ein Desktop als zentraler Ort, der ständig zur Verfügung stand, quasi hinter allem liegt, war beim Macintosh schlichtweg nicht realisierbar.

Da der erste Macintosh keine Festplatte hatte, standen die Programme logischerweise nicht permanent zur Verfügung, sondern mussten von ihrer jeweiligen Diskette geladen werden. Das System erlaubte es zwar, sich ein Dokument auf den Desktop zu legen oder an seinem Speicherort in der Dateiablage zu öffnen, doch dann kam es in aller Regel zu einer Unterbrechung, denn man musste meist die Datendiskette herausnehmen, die Diskette mit dem Anwendungsprogramm einlegen, das Anwendungsprogramm starten, dann die Diskette mit dem Dokument wieder einlegen und erst dann konnte man mit der Bearbeitung des Dokuments beginnen. Gerade da in der Standardausstattung des Geräts nur ein einziges Disketten-Laufwerk zur Verfügung stand, wurde man zum regelrechten Discjockey. Hier beispielhaft die notwendigen Schritte zum Einfügen eines auf einer Diskette gespeicherten Bildes in einen auf einer anderen Diskette gespeicherten Text:

• Textverarbeitungs-Programmdiskette einlegen
• Programm-Icon suchen und Programm starten
• Textverarbeitungs-Programmdiskette auswerfen
• Dokumentdiskette einlegen
• Dokument laden
• Dokumentdiskette auswerfen
• Bilderdiskette einlegen
• Bild laden und in den Text einfügen
• Bilderdiskette auswerfen
• Dokumentdiskette wieder einlegen
• Datei speichern und warten, bis das Programm wieder reagiert

Das Arbeiten mit den Disketten und das ständige Ein- und Auswerfen schlug sich auch in den Funktionen der Nutzungsschnittstellen der Anwendungsprogramme selbst nieder. Im Gegensatz zu den Anwendungen von Lisa und Star etwa konnte ein Abspeichern beim Macintosh nicht implizit erfolgen. Was heißt das? Als Nutzer einer Lisa musste man über das Laden von Dateien und das Abspeichern eigentlich nicht nachdenken. Das Laden geschah durch das Öffnen aus der Dateiablage heraus und das Speichern passierte bei sich anbietender Gelegenheit von selbst, spätestens dann, wenn man den Computer ausschaltete. Die Einschränkungen des Macintosh machten diese Arbeitsweise unmöglich, denn der kleine Arbeitsspeicher erlaubte nicht, die Inhalte mehrerer Dokumente gleichzeitig zu halten. Man kam also nicht umhin, Dokumente zwischenzeitlich zu speichern und zu schließen, um den Arbeitsspeicher wieder frei zu machen. Das Speichern konnte leider auch nicht, wie bei der Lisa, quasi nebenher, bei Bedarf oder automatisch bei Programmende ohne explizite Nutzerinteraktion durchgeführt werden, da das Schreiben auf Diskette zum einen laut und langsam war, und vor allem aber, weil der Rechner während des Schreibvorgangs blockierte und ein Weiterarbeiten nicht möglich war. Ein implizites Speichern, also ohne Nutzerinteraktion, war auch beim Beenden der Anwendungen oder dem Schließen des Fensters eines Dokumentes nicht möglich, denn es war durchaus unwahrscheinlich, dass sich die Diskette, auf der ein Dokument gespeichert werden sollte, zum Zeitpunkt des Speicherns überhaupt im Laufwerk befand.

Die technischen Einschränkungen von Arbeitsspeicher- und Massenspeichergröße führten, wie Sie sehen, notwendigerweise dazu, dass das implizite Speichern der früheren, sehr teuren Systeme, auf dem Macintosh nicht umsetzbar war. Die Anwendungsprogramme mussten daher zwangsläufig Mechanismen erhalten, um Dateien laden, speichern, unter einem anderen Namen oder auf einer anderen Diskette zusätzlich speichern zu können.

Atari ST – Der Vielseitige

An dieser Stelle ist die Gelegenheit günstig, Ihnen ein Konkurrenzprodukt zum Apple Macintosh vorzustellen, dessen Nutzungsschnittstelle an vielen Stellen noch mehr auf die Einschränkungen eines Single-Tasking-Betriebssystems mit Diskettenbedienung optimiert war, als die des Macintosh. Obige Abbildung zeigt einen Atari 520ST+, der im Jahre 1986 erschien. Der einzige Unterschied zum ursprünglichen ST war der auf 1 MB verdoppelte Arbeitsspeicher. Abgesehen davon waren die beiden Rechner identisch. Der ST erschien 1985 und kostete in der Ausstattungsvariante mit monochromem Monitor mit knapp 800 Dollar (entsprechend 2.000 Dollar im Jahr 2021) zwar nur ein Drittel des Macintosh, war aber technisch erheblich besser ausgestattet.

Ataris Computer spielte, wenn man so will, zwei Rollen. Man konnte ihn mit einem Farbmonitor erwerben oder über ein Zusatzgerät an den eigenen Fernseher anschließen. In dieser Nutzungsform konnte der Rechner je nach gewählter Auflösung vier bzw. sechzehn Farben darstellen und war mit seinem Soundchip und seiner schnellen Motorola-CPU der moderne Nachfolger von Ataris 8-Bit-Heimcomputern der frühen 1980er. Entschied man sich jedoch für den monochromen Monitor, war der ST vor allem eine Konkurrenz zum Macintosh, und vermochte als Rechner in Büros und Verwaltung durchaus zu überzeugen. Der ST war nicht nur viel günstiger als der Macintosh, sondern verfügte auch über eine bessere Tastatur mit Pfeiltasten und Nummernblock und über einen erheblich größeren Monitor, der eine sehr hohe, flimmerfreie Bildqualität lieferte.

Das Betriebssystem des Atari ST trug den Namen TOS (The Operating System). Technisch stand hinter diesem System eine 16-Bit-Umsetzung des Betriebssystems CP/M von Digital Research, das Sie im Kapitel über den Altair 8800 kennengelernt haben. Frühe Bücher über den Atari ST, die noch vor seinem Erscheinen geschrieben wurden, enthielten zum Teil noch Beschreibungen des Kommandozeilen-Interpreters von CP/M und beschreiben die Grundcharakteristika dieses Betriebssystems. Sie erläutern auch eine grafische Nutzungsoberfläche mit dem Namen GEM (Graphics Environment Manager), die wie CP/M von Digital Research entwickelt wurde. Als der Computer 1985 erschien, war von der Kommandozeile von CP/M dann nichts mehr zu sehen. Atari hatte sich entschlossen, das Betriebssystem so zu gestalten, dass es wie der Apple Macintosh direkt in die grafische Nutzungsoberfläche GEM startete und auch nur auf diese Art und Weise zu bedienen war. An mancher Eigenart konnte man die CP/M-Basis aber durchaus erkennen, etwa beim Ansprechen von Diskettenlaufwerken über Laufwerksbuchstaben oder auch dem Benennungsschema von Dateien mit acht Zeichen für den Namen, gefolgt von einem Punkt und drei Zeichen zur Definition des Dateityps. In dieser Hinsicht glich das System des Atari ST mehr dem DOS der IBM PCs als dem Betriebssystem des Apple Macintosh, bei dem dem Nutzer viel mehr Flexibilität bei den Dateinamen gegeben wurde.

Im Vergleich zum Macintosh war der Desktop des Atari stark abgespeckt. Startete man den Rechner, bekam man zwar wie beim Macintosh eine graue Oberfläche zu sehen, auf der in Fenstern die Inhalte von Disketten und Ordnern angezeigt werden konnten und auch Desktop-Icons sowie ein Papierkorb waren vorhanden, doch so grundsätzliche Möglichkeiten wie das Ablegen einer Datei direkt auf der Desktop-Oberfläche war nicht möglich. Diese Funktionsbeschneidung war in Bezug auf die Ausstattung des Rechners durchaus folgerichtig, denn die Sinnhaftigkeit, Dateien auf den Desktop zu legen, waren in einem Single-Tasking-System und der Ausrichtung auf Disketten, wie oben erläutert, ja ohnehin arg eingeschränkt.

Da beim Single-Tasking-System des Atari ST der Desktop als Ort der Dateiverwaltung nicht zur Verfügung stand, wurden in vielen Anwendungsprogrammen Funktionen zur Dateiverwaltung bereitgestellt. Obige Abbildung zeigt die Textverarbeitung 1st Word Plus, die neben dem Angebot, Dateien laden, speichern und drucken zu können, auch das direkte Löschen von Dateien auf der Diskette anbot. Versetzt man sich in die Lage eines Diskettennutzers, war diese Funktion sehr sinnvoll. Stellen Sie sich die Situation vor: Sie haben an einem wichtigen Text geschrieben, wollen ihn nun abspeichern, stellen dann aber fest, dass nicht mehr genug Platz auf der Diskette vorhanden ist. Wenn Sie Glück haben, haben Sie eine andere Diskette zur Hand, doch was, wenn nicht? Sie können nicht auf den Desktop wechseln und ein paar Dateien löschen, denn es handelt sich ja um ein Single-Tasking-System. Zum Desktop zu wechseln, hieße, das laufende Programm zu beenden, aber das würde bedeuten, den geschriebenen Text zu verwerfen, weil Sie ihn ja nicht abspeichern können. Die Funktion, direkt aus der Textverarbeitung nicht mehr benötigte Dateien auf der Diskette löschen zu können, kann da Ihre letzte Rettung sein.

Commodore Amiga – Der Multimediale

In Konkurrenz sowohl zum Atari ST als auch in gewisser Weise zum Macintosh stand der Commodore Amiga, dessen erstes Modell ebenfalls 1985 erschien. Oben abgebildet sehen sie das verbreitetste Modell des Rechners, den Amiga 500 aus dem Jahr 1987. Auf den ersten Blick sieht dieser Rechner dem Atari ST sehr ähnlich. Auch beim Amiga 500 sind Recheneinheit und Tastatur integriert, beide verfügen über eine Maus und verwenden als Speichermedium 3,5-Zoll-Disketten. Wie Sie auf dem Bildschirm sehen, verfügte auch der Amiga über eine Nutzungsschnittstelle mit Icons und Fenstern und war insofern auch dem Macintosh ähnlich. Statt von einem Desktop wurde beim Amiga aber von „Workbench“, also einer Werkbank, gesprochen. Disketten enthielten dementsprechend auch keine Ordner, sondern Schubladen. Werkbank und Schubladen für die zentralen Konzepte sind zunächst einmal nur andere Namen, doch zeigte sich in diesem Namen letztlich eine ganz andere Ausrichtung, die sich entgegen der vom Xerox Star übernommenen Denkweise des Macintosh und des Atari ST nicht an der Büroarbeit orientierte.

Die große Stärke des Rechners waren seine Grafik- und Sound-Fähigkeiten. Er verfügte über unzählige Grafikmodi, von hohen Auflösungen von 640 x 512 Pixeln mit sechzehn Farben bis hin zu 580 × 368 Pixeln²⁰ bei sage und schreibe 4.096 gleichzeitig darstellbaren Farben. Keine andere Heim- oder Personal-Computer-Plattform war zu diesem Zeitpunkt so grafikmächtig. Das Videosignal und die Bildschirmtechnologie waren bekannte, solide Fernsehtechnik. Der mitgelieferte Monitor war im Prinzip ein kleiner Farbfernseher ohne Empfangsteil. Die Verwendung dieser Technik hatte ihre Vorteile was die multimedialen Fähigkeiten des Rechners anging. Verbunden mit dieser Design-Entscheidung waren allerdings auch erhebliche Nachteile, die einen Einsatz gerade im Büro erschwerten, denn zwar bot der Monitor eine hohe Auflösung, die grundsätzlich auch feine Textausgaben oder Grafiken erlaubt hätte, doch stand die hohe Auflösung nur im sogenannten „Interlaced-Modus“ zur Verfügung. Der Nachteil dieser Technik, auf die ich hier im Detail nicht genauer eingehen möchte, war, dass es zu einem sichtbaren und unangenehmen Flimmern kam, wenn in der Vertikalen Bildelemente mit einem hohen Kontrast aufeinandertrafen. Das Flimmern ließ sich zwar durch eine geschickte Farbwahl minimieren, doch dann litt der Kontrast. Für die klassische Büroanwendung Textverarbeitung mit der Darstellung von feinem, schwarzem Text auf weißem Grund war der Amiga daher eher schlecht geeignet. Durch seine herausragende Grafikeinheit zusammen mit einem ebenfalls hervorragenden Soundchip war der Amiga jedoch eine ideale Plattform für Spiele. Darüber hinaus wurden die Grafik- und Sound-Funktionalitäten auch für Bildbearbeitung und Animation genutzt. Hier wurde die technische Entscheidung, bei der Grafikausgabe auf Fernsehtechnik zu setzen, zu einem großen Vorteil, denn die Videosignale des Amiga ließen sich direkt mit vorhandener Video- und Fernsehtechnik koppeln. So manche Animation, die seinerzeit im Fernsehen zu sehen war, wurde von einem Amiga-Rechner erzeugt.

Der Amiga und sein Betriebssystem waren in einer weiteren Hinsicht den Pendants von Atari, Apple und auch IBM überlegen, denn im Gegensatz zu diesen war der Amiga multitaskingfähig. Öffnete man eine Textdatei oder ein Bild aus einem Fenster in der Workbench, öffnete sich ein weiteres Fenster, das den Text oder das Bild darstellte. Auch die Workbench mit ihren Fenstern blieb aber weiterhin verfügbar. Weder der Atari ST, der Apple Macintosh oder der IBM PC konnten das damals bieten. Selbst dann wenn die Fenstertechnik nicht eingesetzt werden konnte, weil das verwendete Programm einen anderen Grafikmodus verwendete als die Workbench, konnte zwischen den Programmen gewechselt werden, unter anderem – hier zeigen sich wieder die herausragenden Grafikfähigkeiten des Systems – durch eine Einteilung des Bildschirms in mehrere „Viewports“. Dann lief etwa in der oberen Bildschirmhälfte eine Animation in niedriger Auflösung mit vielen Farben und in der unteren Hälfte ein anderes Programm mit hoher Auflösung und nur wenigen Farben.

Multitasking und Fenster auf dem IBM PC

Mitte der 1980er Jahre waren mit Macintosh, Atari ST und Amiga drei Computersysteme auf dem Markt, die die grafische Nutzungsschnittstelle und im Falle des Amiga auch das Multitasking im Personal-Computer-Bereich etablierten. Verglich man die drei Systeme mit dem DOS des IBM PC, schien dieses eher noch der vorherigen Computergeneration anzugehören, während Macintosh, ST und Amiga frisch und modern wirkten. Auch die Nutzungsschnittstelle des IBM PC blieb aber natürlich nicht auf dem Stand von 1981 stehen, sondern schloss mehr und mehr zu den drei fensterbasierten Systemen auf. Die Grundlage hierfür war neben schnelleren Prozessoren und mehr Arbeitsspeicher vor allem die zunehmende Verbreitung von Festplatten.

War zu Beginn der 8-Bit-Heimcomputer-Ära noch die Kassette das Speichermedium der Wahl, war die 16-Bit-Generation von vorn herein auf Diskettennutzung ausgelegt. Die Zeit der Diskette als Haupt-Massenspeicher war jedoch nur eine Zwischenperiode. Sowohl der Atari ST, Commodore Amiga, Apple Macintosh als auch der IBM PC konnten um eine Festplatte ergänzt werden. In der ersten Gerätegeneration war eine solche Platte oft noch ein externes Gerät, das zusätzlich auf dem Tisch stand. Später war eine Platte oft schon ab Werk eingebaut. Der IBM PC XT (für Extended Technology) von 1983 konnte etwa schon mit einer eingebauten 10-MB-Platte erworben werden. Doch Vorsicht! Dass die 16-Bit-Computergeneration im Prinzip schon von Anfang an Schnittstellen für den Anschluss einer Festplatte vorsah und dass heutige Exemplare dieser Rechner in den Sammlungen der Retro-Computing-Fans auch meist über eine Festplatte verfügen, sollte Sie nicht dazu verleiten, zu glauben, dass Festplatten schon damals im Heimbereich verbreitet waren. Retro-Computing-Anhänger haben oft viel Spaß daran, die alten Rechner auf ihre maximale Ausbaustufe zu erweitern. Teils schaffen sie es mit modernen Tricks sogar, die alten Computer weiter aufzurüsten, als es damals überhaupt möglich war. Zum damaligen Zeitpunkt waren die meisten Systeme natürlich nicht derartig üppig ausgestattet. Es waren viel bescheidenere Konfigurationen verbreitet, denn Festplatten und Arbeitsspeicher waren sündhaft teuer. Bestellte man den IBM PC XT mit der 10-MB-Festplatte, einem Monitor und einer Arbeitsspeicherausstattung von 640 KB, musste man 8.000 Dollar auf den Tisch legen. Berechnet man die Inflation mit ein wären das im Jahr 2021 über 21.500 Dollar gewesen und damit selbst für viele kleine Betriebe zu teuer – von Heimanwendern ganz zu schweigen.

Als Microsoft 1981 die erste Version seines DOS an IBM lizenzierte, standen Festplatten noch nicht im Fokus. DOS war, wie das CP/M, an das es angelehnt war, klar ein Betriebssystem für Disketten. Das merkte man vor allem daran, dass es ein zentrales Element heutiger Betriebssysteme, das hierarchische Dateisystem, bei DOS noch nicht gab. DOS und CP/M erlaubten es, Dateien auf Disketten zu schreiben und diese über ihren Dateinamen ansprechbar zu machen. Eine Diskette war aber in sich nicht weiter strukturiert. Es gab also keine Unterverzeichnisse oder Ordner. Alle Dateien lagen auf einer Ebene. Bei einer Diskette, auf die 180 KB oder 320 KB Daten geschrieben werden konnten, war eine solche Strukturierung im Prinzip auch nicht nötig. Die Diskette selbst war quasi die Ordnungseinheit für die Dateien. Schloss man nun aber eine Festplatte an und hatte 5 oder gar 10 MB zur Verfügung, wurde es unpraktisch, alle Dateien in einer großen Liste zu führen. Eine Unterstrukturierung wurde notwendig.

1983 erschien die zweite Version des DOS von Microsoft. Das Betriebssystem hatte zwar den gleichen Namen und mutete von der grundsätzlichen Bedienung auch recht ähnlich an, es handelte sich aber im Grunde um eine nahezu komplette Neuentwicklung. Microsoft erweiterte das DOS um eine ganze Reihe von Funktionen und Konzepten aus dem Betriebssystem Unix. Dazu gehörten die Technik des Piping, bei dem Ein- und Ausgabe von Programmen umgeleitet werden, sowie eine einfache Programmiermöglichkeit durch sogenannte Batch-Dateien. Mehr zu diesen Unix-Konzepten erfahren Sie im Kapitel über Linux und Unix. Die für die meisten Nutzer wahrscheinlich wichtigste Neuerung war die Einführung des hierarchischen Dateisystems mit Ordnern und Unterordnern. Mit ihnen kamen zentrale neue Befehle, die ins Standardrepertoire aller DOS-Nutzer aufgenommen wurden: Zum schon bekannten dir zum Auflisten des Inhalts eines Verzeichnisses kamen nun etwa cd für change directory zum Wechseln in ein anderes Verzeichnis und md für make directory zum Erstellen eines Unterverzeichnisses.

Während die frühen Personal-Computer mit ihrer Diskettenzentrierung und wenig Speicher zwangsläufig Geräte sein mussten, bei denen sich zu jedem Zeitpunkt nur ein einziges Programm im Speicher befand und abgearbeitet wurde, erfüllten gut ausgestattete IBM-kompatible PCs mit einer Festplatte und mit viel Arbeitsspeicher grundsätzlich die Voraussetzung, auch mehrere Programme gleichzeitig verfügbar zu machen. Tatsächlich konnte man bei IBM den PC in einer Konfiguration erwerben, die das ermöglichte. Als Betriebssystem wurde dann nicht Microsofts DOS, sondern Unix ausgeliefert, zunächst in der Variante PC/ix der Firma ISC und ab 1985 mit Xenix von Microsoft. Unix auf dem IBM PC setzte sich zum damaligen Zeitpunkt aber nicht durch, denn die Hardware-Anforderungen waren hoch und die Software-Auswahl aufgrund der geringen Verbreitung bescheiden. Die große Menge an Software, die den IBM PC so attraktiv machte, von Tabellenkalkulationen über Textverarbeitungsprogramme bis hin zu Datenbanken oder gar Spielen, wurden für DOS entwickelt. DOS ermöglichte zwar kein richtiges Multitasking, eine sehr einfache, eingeschränkte Möglichkeit, ein Programm zu starten, ohne das andere dafür beenden zu müssen, gab es ab der Version 2 aber doch, denn ein Programm konnte nun ein anderes Programm starten. Die verwendete Software musste diese Möglichkeit aber explizit vorsehen. Um zu verstehen, wie die Verwendung mehrerer Programme möglich war, braucht es einen kleinen Ausflug in die Mechanismen, wie ein Programm geladen wird. Keine Angst, ich versuche, es nicht zu kompliziert zu machen:

Wenn Sie ein CP/M oder ein MS-DOS starteten, begrüßte Sie nach einiger Zeit der Kommandozeilen-Interpreter, der es Ihnen ermöglichte, Befehle einzugeben, um Dateien zu kopieren, sie zu löschen oder aber auch, um ein Programm zu starten. Der Kommandozeilen-Interpreter selbst war aber auch nur ein Programm. Seine einzige Besonderheit war, dass es vom Betriebssystem automatisch gestartet wurde. Nutzte man den Kommandozeilen-Interpreter, um ein anderes Programm zu starten, wurde das Programm in den Arbeitsspeicher kopiert und dann gestartet. Wurde das Programm beendet, ging die Kontrolle zurück an das Betriebssystem, das dann automatisch wieder den Kommandozeilen-Interpreter in den Speicher lud und startete. Zu jedem Zeitpunkt war also nur ein Programm im Speicher – und folglich lief auch zu jedem Zeitpunkt nur ein einziges Programm. Auf die gleiche Art funktionierten auch die anderen Betriebssysteme. Bei einem Macintosh war es das Programm Finder, das automatisch gestartet wurde. Es stellte die Ordnerfenster und den Desktop bereit. Startete man aus dem Finder heraus ein anderes Programm, wurde dieses an des Finders Stelle in den Speicher kopiert und gestartet. Nach dem Beenden des Programms lud und startete das Betriebssystem automatisch wieder den Finder. Mit der Version 2 von Microsofts DOS wurde die Möglichkeit des Programm-Startens ein wenig verändert. Es war nun nicht mehr so, dass das Laden eines Programms unbedingt das bisherige Programm im Speicher verdrängte. Ein laufendes Programm, ich nenne es einmal „A“, konnte nun ein anderes Programm „B“ in den Speicher laden und starten. Dabei blieben aber alle Daten von Programm A im Speicher erhalten. War der Nutzer mit dem, was er in Programm B erledigen wollte, fertig und beendete das Programm, wurde das Programm A dort fortgesetzt, wo es unterbrochen wurde. Diese technische Änderung, wie Programme geladen werden konnten, ermöglichte es noch nicht, mehrere Programme gleichzeitig laufen zu lassen und zwischen ihnen hin und her zu wechseln, denn dafür hätte es eine Art von übergeordneter Steuerung gebraucht, die die verschiedenen im Speicher befindlichen Programme unter ihrer Kontrolle gehabt und dem Benutzer das Wechseln ermöglicht hätte. So etwas gab es unter MS-DOS aber noch nicht. Was aber möglich war, war das Ausführen von Programmen in einer Art Kette. Stellen Sie sich die folgende Situation einmal vor: Sie wollen einen Brief schreiben, haben dafür die Textverarbeitung geöffnet und bereits einen längeren Textabschnitt verfasst. Nun bemerken Sie aber, dass Sie für den Brief eine Information brauchen, die in einem Tabellenblatt der Tabellenkalkulation steht. Wenn Ihre Textverarbeitung es nun ermöglicht, können Sie direkt aus ihr heraus die Tabellenkalkulation starten und dort die Information in Erfahrung bringen. Nach dem Beenden des Tabellenkalkulationsprogramms landen Sie – als wäre nichts gewesen – automatisch wieder in Ihrem Text in der Textverarbeitung, in dem Sie die neuen Erkenntnisse direkt unterbringen können. Wirklich komfortabel war das nicht, doch es verringerte zumindest die Notwendigkeit, im Programm A alles speichern zu müssen und das Programm zu beenden, nur um ein Programm B nutzen zu können.

Die Voraussetzung dafür, dass das so klappte, war natürlich das Vorhandensein von hinreichend Arbeitsspeicher und das war durchaus ein Problem, denn Speicher war nicht nur teuer, sein Handling unter DOS war auch ein sehr komplexes Unterfangen. Wenn Sie einen Computer-Freak in Ihrem Bekanntenkreis haben, der alt genug ist, dass er oder sie noch mit DOS gearbeitet haben könnte, sprechen Sie ihn oder sie mal darauf an. Ein stundenlanger Vortrag (zum Beispiel über die Unterschiede zwischen oberem und hohem Speicher oder gar zwischen Extended Memory und Expanded Memory) oder ein plötzliches Erbleichen verbunden mit Schnappatmung sind Ihnen sicher!

VisiOn, TopView, DESQView

Weiter oben habe ich Ihnen erzählt, dass das erste Computersystem nach Xerox Star und Apple Lisa, das auf Mausbedienung und Fenster gesetzt hat, der Apple Macintosh von 1984 gewesen sei. In einer groben Betrachtung stimmt das auch. Schaut man aber genau hin, findet man VisiOn, eine grafische Arbeitsumgebung für IBM PCs, die bereits 1982 präsentiert wurde und ab Ende 1983 in den Verkauf kam. Der Hersteller der VisiON-Bedienoberfläche war die Firma VisiCorp, die auch hinter VisiCalc stand, der Urversion der Tabellenkalkulation, die ich Ihnen im Kapitel über den Apple II vorgestellt habe. In mancher Hinsicht war VisiOn der Nutzungsschnittstelle des Macintosh überlegen, denn im Gegensatz zum Apple-Rechner bot das System die Möglichkeit, mehrere Dokumente in verschiedenen Anwendungen gleichzeitig geöffnet zu haben und zwischen diesen hin und her zu wechseln. Diese Fähigkeit ging natürlich mit entsprechenden Hardware-Anforderungen einher. Der PC brauchte 512 KB Arbeitsspeicher, eine Festplatte von mindestens 5 MB Größe, eine CGA-Grafikkarte und eine Maus. IBMs PC XT aus dem gleichen Jahr verfügten zwar, wenn man die teuere Ausstattungsvariante wählte, über eine Festplatte, aber üblicherweise nur über 128 KB Arbeitsspeicher. Eine Maus gehörte nicht zum Lieferumfang des Rechners. Zu den 5.000 Dollar für dieses Spitzengerät kamen also noch die Kosten für die Speicheraufrüstung und für eine Maus hinzu.

VisiOn war kein komplettes Betriebssystem. Um es zu nutzen, startete man den Computer zunächst mit Microsofts DOS und lud dann VisiOn wie jede andere DOS-Anwendung. VisiOn präsentierte sich dann zunächst mit dem „Application-Manager“, mit dem Anwendungen aufgerufen werden konnten. Die Anwendungen wurden, wie oben zu sehen, jeweils in einem eigenen Fenster dargestellt. Bei besagten Anwendungen handelte es sich nicht um die normalen Anwendungen für IBM PCs, sondern um eigens für VisiON erstellte Programme. Neben dem Application Manager stand eine Textverarbeitung (VisiOn Word), eine Tabellenkalkulation (VisiOn Calc) und eine Software zum Erzeugen von Business-Grafiken (VisiOn Graph) zur Verfügung. Das System wäre grundsätzlich um weitere Anwendungen erweiterbar gewesen, zusätzliche Software erschien jedoch nie.

Wenn man moderne fensterbasierte Nutzungsoberflächen kennt, erscheint einem die Bedienung von VisiOn in mancherlei Hinsicht eigenartig. Schon beim ersten Blick auf die Abbildung wirkt die Nutzungsschnittstelle fast ein bisschen auf den Kopf gestellt. Statt eines Menüs oben im Fenster, wie bei Windows, oder am oberen Bildschirmrand, wie beim Macintosh, werden systemweite Funktionen ganz unten auf dem Bildschirm und Anwendungsfunktionen in der Fußzeile des jeweiligen Fensters angezeigt. Den Fenstern fehlen überdies all die kleinen Bedienelemente zum Schließen, Verschieben, Vergrößern und Verkleinern. Diese findet man stattdessen im Menü in der Fußzeile. Nicht nur die Position ist aber aus heutiger Sicht außergewöhnlich; die komplette Arbeitsweise wirkt regelrecht verdreht. Alle heutigen grafischen Nutzungsschnittstellen verwenden das Objekt-Verb-Paradigma. Man markiert zunächst ein Objekt, etwa eine Datei oder ein Fenster, und wählt dann die Handlung aus, die man ausführen will, etwa Öffnen, Schließen oder Löschen ebenjener Datei oder des Fensters. VisiOn verwendete hingegen eine Verb-Objekt-Arbeitsweise. Wollte man ein Fenster schließen, klickte man unten zunächst auf „CLOSE“. In der Zeile darüber meldete das System dann „Close. Which Window?“. Nun musste man das Objekt anklicken, das geschlossen werden sollte, hier also eines der Fenster. Diese Arbeitsweise erscheint uns heute total ungewöhnlich. Dass die Software-Ingenieure bei VisiCorp trotzdem darauf kamen, ist aber aus der damaligen Sicht gar nicht so unverständlich, denn nach dem Verb-Objekt-Prinzip funktionierten auch die damals ja noch dominierenden Kommandozeilen-Schnittstellen. Wollte man unter DOS die Datei „unsinn.txt“ löschen, schrieb man den Befehl an den Anfang und das Objekt, auf das er sich bezog, als Zweites: del unsinn.txt.

Dass VisiOn kein Erfolg war, können Sie sich vermutlich denken. Das lag jedoch nicht an der eigenartigen Bedienweise. An diese hätte man sich durchaus gewöhnen können und auch ein Umstellen auf Objekt-Verb-Betrieb wäre in späteren Versionen sicher umsetzbar gewesen. Das Problem war eher, dass VisiOn aufgrund seiner hohen Anforderungen an die Hardware wohl ein paar Jahre zu früh kam. Nur für die Nutzung der Maus und der Fenstertechnik einen derart hochgezüchteten, teuren Computer anzuschaffen, war letztlich nicht zu rechtfertigen. Problematisch war auch die Software-Situation. Zwar lieferte VisiOn typische Büro-Software mit, doch liefen eben nicht die etablierten Software-Produkte, wegen derer die IBM-Rechner und ihre Kompatiblen in der Wirtschaftswelt so verbreitet waren. Die Textverarbeitung war kein WordPerfect und kein WordStar und die Tabellenkalkulation war kein Lotus 1-2-3, noch nicht einmal ein vollwertiges VisiCalc.

Wenn Sie meine Erläuterungen zum Xerox Alto gelesen haben, dann haben Sie dort erfahren, dass das System, wenn auch kein kommerzieller Erfolg, großen Einfluss auf die Entwicklung der Nutzungsschnittstellen hatte, was auch damit zusammenhing, dass Steve Jobs einen Besuch beim Xerox PARC machte, wo ihn die Präsentation der Smalltalk-Umgebung zu weitreichenden Änderungen der in der Entwicklung befindlichen Schnittstellen der Apple Lisa und letztlich des Macintosh bewog. Auch VisiOn fand seine Inspiration in der Smalltalk-Umgebung, war aber auch wiederum Inspiration für spätere Entwicklungen. Der Erzählung nach sah Bill Gates die Präsentation der Umgebung auf der COMDEX 1982, was ihn darin bestärkte, sein eigenes Projekt voranzutreiben, das unter dem Namen „Windows“ bekannt werden sollte. Noch war es aber nicht soweit und die Nutzer des IBM PCs mussten sich mit MS-DOS und seiner eingeschränkten Nutzungsschnittstelle zufrieden geben.

Wenn Sie sich Mitte der 1980er Jahre einen IBM PC oder einen seiner günstigeren Kompatiblen leisteten und diesen mit hinreichend Arbeitsspeicher und einer Festplatte ausstatteten, stand Ihnen eine große Software-Vielfalt offen. Der PC war nicht gerade eine Spiele- oder Grafik-Plattform, aber gerade im Bereich der Business-Software blieben am PC kaum Wünsche offen. Die ärgerlichste Einschränkung des Systems bei der täglichen Arbeit war, dass es sich immer noch um ein Single-Tasking-System handelte. Die Nutzer waren gezwungen, ständig Dateien zu speichern, Programme zu schließen, andere Programme zu starten, sie wieder zu schließen und so weiter. Die Programme, die eigentlich gleichzeitig gebraucht wurden, konnten nur abwechselnd verwendet werden. Nutzer des Amiga oder auch die wenigen Nutzer von VisiOn waren hier klar im Vorteil. Sie konnten einfach zwischen den Programmen hin und her wechseln. Wenn ich von Multitasking rede, ist mir an dieser Stelle übrigens egal, ob es sich um echte Gleichzeitigkeit handelt, bei dem die Programme im Hintergrund weiterlaufen, oder ob nur der Wechsel zwischen Programmen ermöglicht wird, bei dem das aktive Programm ausgeführt wird, während die anderen Programme einfrieren. Es gibt Situationen, in denen echtes Multitasking wichtig ist, etwa, wenn Sie in einem Programm Musik spielen lassen und währenddessen in einem anderen Programm arbeiten wollen. In sehr vielen Fällen gibt es in der Praxis aber keinen Unterschied, ob ein Hintergrundprogramm weiterläuft oder nicht. Wenn Sie etwa von der Textverarbeitung in die Tabellenkalkulation wechseln, ist es völlig egal, ob die Textverarbeitung dabei angehalten wird.

Eine Reihe von Software-Herstellern brachte 1985 Systemerweiterungen heraus, die es ermöglichen sollten, mehrere DOS-Programme gleichzeitig laufen zu lassen und zwischen ihnen nach Belieben zu wechseln. Verbreitung fanden IBMs TopView und die Software DESQView von QuarterDeck. Beide Produkte erlaubten es, MS-DOS-Programme jeweils in ihrem eigenen Fenster laufen zu lassen. Dieser Fensterbetrieb funktionierte allerdings nicht mit jedem Programm. Programme, die den kompletten Bildschirm verwendeten, um zum Beispiel Grafiken anzuzeigen, konnten zwar oft mit den Systemerweiterungen verwendet, allerdings nicht in einem Fenster dargestellt werden. Im November 1985 erschien die erste Version von Microsoft Windows. Auch diese neue Betriebssystem-Umgebung erlaubte es, mehrere Programme gleichzeitig in Fenstern ausführen zu lassen. Neben Anwendungen, die extra für Windows geschrieben wurden, funktionierte das auch mit DOS-Programmen, sofern das Programm mitspielte und der Arbeitsspeicher ausreichte. Beides war nicht oft der Fall.

In der Praxis blieb Multitasking auf IBM-kompatiblen Systemen noch recht lange eingeschränkt. Das hängt damit zusammen, dass Beschränkungen von IBMs ursprünglichem PC und die Notwendigkeit, zu diesem kompatibel zu bleiben, die Speicherverwaltung unter MS-DOS extrem komplex machten. Alle gleichzeitig laufenden Programme mussten im Prinzip in einem Speicherbereich von nur 640 KB Platz finden. Hinzu kam das Problem, dass in DOS-Programmen oft hardwarenahe Tricks angewendet wurden, um die Software schneller zu machen. In Multitasking-Umgebungen machten diese Tricks immer Probleme, da jeder der Software-Entwickler davon ausging, den Rechner komplett unter Kontrolle zu haben. Fingen nun zwei Programme an, gleichzeitig direkt auf die Hardware zuzugreifen, zum Beispiel um etwas auf den Bildschirm zu zeichnen, gab es bestenfalls eine chaotische Darstellung, schlimmstenfalls stürzte der Rechner einfach ab. DOS-Programme waren schlicht und ergreifend nicht für Multitasking-Betrieb ausgelegt. Und Windows? Windows-Anwendungen waren natürlich von vornherein fenster- und multitaskingtauglich, doch bis Windows wirklich eine nennenswerte Verbreitung bekommen sollte, gingen noch gut fünf Jahre ins Land.

Windows und MacOS

Ein Blick ins Jahr 1985 offenbart im Markt der Heim- und Personal-Computer eine bunte Vielfalt. Gerade im amerikanischen Business-Bereich sehr beliebt waren der IBM PC und seine unzähligen Nachbauten. Viel verkauft wurden natürlich die 8-Bit-Heimcomputer wie der Commodore 64 oder der Atari 800XL. Dazu kam der teurere, aber auch besser ausgestattete Apple II. Die Geräte der Nachfolgegeneration dieser Rechner, der Commodore Amiga, der Atari ST und der Apple Macintosh waren bereits verfügbar, fanden ihre Abnehmer und sprengten allmählich die Trennung zwischen Heim- und Bürocomputer. C64 und Co blieben aber noch lange Zeit erfolgreich, da sie viel günstiger waren, als die neuen Geräte, und da es ein riesiges Software- und Spieleangebot für die Geräte gab, die man zudem noch leicht kopieren konnte. In Amerika waren verschiedenste Computer unter der Marke Tandy verfügbar und der britische Computermarkt bereicherte die Auswahl um Rechner von Sinclair, Amstrad und Acorn. Diese Aufstellung ist natürlich bei Weitem nicht komplett. Was nahezu all diese Computertypen gemein hatten, war nicht nur, dass sie klein und – im Vergleich zu Minicomputern von nur zehn Jahren vorher – auch günstig waren und auf Mikroprozessortechnologie basierten, sondern dass sie zueinander nicht kompatibel waren: Sie hatten jeweils ein eigenes Betriebssystem mit einer eigenen Nutzungsschnittstelle, sodass sie sich unterschiedlich bedienten. Auch die Programme des einen Rechners waren auf dem anderen nicht lauffähig. Meist waren noch nicht einmal die Datenträger lesbar. Die Inkompatibilität galt sogar für die Computer des gleichen Herstellers. Ein Apple Macintosh konnte die Programme des Apple II nicht laufen lassen und auch ein Spiel, das für den C64 entwickelt wurde, lief nicht auf einem Amiga.

Computer-Nostalgiker trauern dieser Zeit mit den vielen verschiedenen Systemen oft nach, denn jedes System hatte seine eigenen Macken, seine eigenen Stärken und seine typischen Charakteristika. In der damaligen Zeit jedoch haben sich viele darüber geärgert, denn die Inkompatibilitäten auf allen Ebenen kosteten viel Zeit und Nerven. Schrieb etwa ein stolzer Besitzer eines Macintosh einen Text im mitgelieferten MacWrite, speicherte ihn auf einer 3,5-Zoll großen Diskette ab und gab sie einem Bekannten mit einem IBM PC, dann hatte der schon mal das Problem, dass er wahrscheinlich gar kein Laufwerk hatte, in das er diese Disketten stecken konnte, denn beim IBM PC waren damals 5,25-Zoll große Disketten und die entsprechenden Laufwerke üblich. Gab er sie seinem Kollegen mit einem Amiga, konnte der die Diskette zwar physikalisch ins Laufwerk stecken, doch lesen konnte er sie nicht, denn die Art und Weise, wie die Daten auf der Diskette gespeichert wurden, unterschied sich zwischen den Systemen. Selbst dann, wenn es jemand hinbekam, die Dateien des einen Rechners auf dem anderen zugreifbar zu machen – der Atari ST konnte zum Beispiel mit einem PC formatierte 720-KB-Disketten lesen – war damit auch noch nicht viel erreicht, denn auf den verschiedenen Systemen gab es jeweils eigene Software, die meist mit der der anderen Systeme nicht kompatibel war. Man konnte die Dateien des fremden Systems dann zwar auf dem Desktop sehen, aber leider weder betrachten noch bearbeiten. Natürlich gab es damals Möglichkeiten, die Inkompatibilitäten zu umschiffen. Dateien wurden zum Beispiel oft nicht per Diskette, sondern mittels eines Kabels übertragen, das zum Beispiel die standardisierten Schnittstellen der Rechner an der Stelle miteinander verband, an der man normalerweise einen Drucker anschloss. Jeweils eine kompatible Übertragungs-Software auf beiden Systemen, die man sich zur Not sogar noch selbst programmieren konnte, ermöglichte es, die Dateien zu übertragen. Einigte man sich dann noch auf Standard-Dateiformate oder war im Besitz von praktischen Konvertierungsprogrammen, konnte man durchaus Dateien zwischen den Rechnern austauschen. Praktisch war das alles aber nun wirklich nicht.

Die Vielfalt auf dem Personal-Computer-Markt hielt sich bis etwa Mitte der 1990er Jahre. Ataris Falcon 030 war 1993 der letzte Computer der ST-Reihe. Im gleichen Jahr beendete Apple die Produktion des Apple IIe. Der Commodore 64 wurde bis 1994 gebaut und die letzten Amiga-Modelle wurden 1996 auf den Markt gebracht. Die bisherige Vielfalt ging verloren – der Personal-Computer-Markt wurde mehr und mehr eine zweiseitige Angelegenheit mit Apple und seinem MacOS²¹ auf der einen Seite und Microsoft mit Windows auf der anderen. Betrachtet man die beiden Systeme heute, findet man weit mehr Ähnlichkeiten als Unterschiede. Es handelt sich bei beiden Systemen um ausgereifte Betriebssysteme mit komplexen Nutzungsschnittstellen. Ihre Unterschiede fallen größtenteils in den Bereich persönlicher Präferenzen. Inkompatibilitäten sind heute auch nicht mehr das Problem. Große Teile der Software sind auf beiden Systemen verfügbar, Datenträger des einen Systems sind auf dem jeweils anderen meist zumindest lesbar und standardisierte Dateiformate erleichtern die Zusammenarbeit über die Systemgrenzen hinweg.

Ich will Ihnen nachfolgend in aller Kürze erläutern, wie sich die beiden Betriebssysteme dahin entwickelt haben, wo sie heute sind, denn die Voraussetzungen für die Entwicklung waren alles andere als gleich. Apple musste, mit einer kurzen Ausnahme Ende der 1990er Jahre, stets nur seine eigenen Geräte mit seiner eigenen Hardware im Blick haben. Microsoft sah sich hingegen der Situation gegenüber, eine Systemsoftware entwickeln zu müssen, die auf einer Vielzahl von Geräten einsetzbar war. In dieser Hinsicht ist Apple noch heute im Vorteil, was manchmal ein Grund dafür sein dürfte, dass das MacOS etwas glatter läuft und etwas weniger komplex ist als Microsofts Windows. Mein Fokus im folgenden geschichtlichen Abriss liegt nicht auf derartigen produktpolitischen Aspekten, sondern auf der Nutzungsschnittstellen-Welt der Systeme. Mich interessiert nur am Rande, was sich bei den Systemen „unter der Haube“ tat. Dass es zum Beispiel bei Apple dreimal einen Wechsel der Hardware-Architektur gab, ignoriere ich hier einfach, genauso wie die Multimedia- und Internetfähigkeiten der Systeme, die sich bis auf Kleinigkeiten nicht unterschieden.

MacOS – Der Desktop und der Finder

Die erste Version von MacOS erschien mit dem Ur-Macintosh im Jahre 1984. Dieser Macintosh war, wie im vorherigen Kapitel beschrieben, ein sehr einfacher Rechner mit nur 128 KB RAM, einem einzigen Diskettenlaufwerk und ohne Festplatte. Folge dieser Einschränkung war, dass der Rechner im Single-Tasking-Betrieb laufen musste, also stets nur ein Programm zur gleichen Zeit genutzt werden konnte. Die Hauptoberfläche des Betriebssystems war eine Software namens Finder. Der Finder erlaubte den Zugriff auf das Dateisystem, bot einen Desktop an, auf dem sich ein Papierkorb befand, eingelegte Disketten als Icons angezeigt wurden und Dateien abgelegt werden konnten. Ein Doppelklick auf ein Disketten-Icon öffnete ein Fenster, das die auf der Diskette gespeicherten Dateien als Icons anzeigte. Befand sich auf der Diskette ein Ordner, konnte auch dieser mit dem Finder geöffnet werden. Ein Doppelklick auf ein Datei-Icon startete das mit dem Dokument verbundene Programm. Oft musste dazu allerdings eine andere Diskette eingelegt werden, auf der das Programm gespeichert war. War der Nutzer mit der Bearbeitung fertig, musste er das Programm beenden und die Betriebssystemdiskette wieder einlegen. Es wurde dann wieder der Finder mit dem Desktop geladen.

Typisch für MacOS war, dass Dateien und Ordner per Drag and Drop verschoben werden konnten, so zum Beispiel auch zwischen geöffneten Ordnerfenstern oder von einer Diskette auf eine andere. Das ging sogar mit nur einem Diskettenlaufwerk. Der Finder ermöglichte es dafür, eine Diskette zwar auszuwerfen, allerdings auf dem Desktop noch zugreifbar zu halten. Sobald auf diese Diskette zugegriffen werden sollte, verlangte das System den Wechsel der Diskette. Das Kopieren einer Datei von einer Diskette auf die andere wurde dadurch möglich, war aber natürlich durch den kleinen Arbeitsspeicher begrenzt und war bei großen Dateien mit vielfachem Hin- und Herwechseln der Disketten verbunden. Komfortabler funktionierte es, wenn man sich ein zusätzliches, externes Diskettenlaufwerk kaufte und an den Rechner anschloss. Auf der Diskette gespeicherte Dokumente und Ordner konnten nicht nur zwischen Fenstern verschoben, sondern überdies auch aus den Fenstern herausgezogen und direkt auf der Desktop-Oberfläche abgelegt werden. Dass das bei einem rein auf Diskettenbetrieb ausgelegten Betriebssystem funktionierte, kann einen durchaus erstaunen. Wo befand sich eine Datei, wenn sie auf den Desktop gelegt wurde? Die Antwort auf diese Frage kennen Sie schon, wenn Sie im vorherigen Kapitel gelesen haben, was es mit dem Desktop der Apple Lisa auf sich hatte. Wurden am Macintosh Dateien auf den Desktop verschoben, wurden sie, wie bei der Lisa, zwar auf dem Desktop-Hintergrund angezeigt, ihr eigentlicher Speicherort blieb aber die Diskette. Bei der Lisa sah man die Datei dann weiterhin auch als ausgegrautes Icon am ursprünglichen Speicherort, beim Macintosh hat man auf diese Darstellung des eigentlichen Speicherorts verzichtet. Eine auf dem Desktop abgelegte Datei erschien nur dort und nicht mehr im Disketten- oder Ordnerfenster, so dass der Eindruck entstehen konnte, die Datei wäre von der Diskette auf den Desktop verschoben worden. Von diesem visuellen Unterschied abgesehen, funktionierte der Mechanismus aber genau so wie bei der Lisa. Wählte man eine auf dem Desktop abgelegte Datei aus und klickte dann im Menü auf „Put Away“ (in frühen Versionen des Betriebssystems mit „Put Back“ betitelt) wurde die Datei vom Desktop entfernt und erschien fortan wieder an ihrem ursprünglichen Speicherort, sie wurde der Metapher entsprechend „zurückgelegt“.

Der Desktop des Macintosh zeigte stets die Dateien an, die auf der gerade eingelegten Diskette als auf dem Desktop liegend verzeichnet, waren. Auf jeder Diskette gab es dafür einen eigenen Bereich. Hier wurde gespeichert, welche Ordner einer Diskette gerade in einem wie gearteten Fenster geöffnet und welche Dateien einer Diskette auf dem Desktop an welcher Position abgelegt waren. Nur durch das Speichern dieser Informationen auf der Diskette war es möglich, dass nach der Beendigung eines Programms der Finder wieder die gleichen Dateien auf dem Desktop und die gleichen Fenster geöffnet darstellen konnte. Legte man bei laufendem Finder eine Diskette ein, erschienen die von dieser Diskette früher auf dem Desktop abgelegten Dateien wieder an ihrer gespeicherten Stelle und auch die Ordnerfenster, die zuvor geöffnet waren, erschienen wieder. Jede Diskette speicherte also in gewisser Weise ihren eigenen Desktop. Diese Art der Desktop-Verwaltung eröffnete ganz interessante Einsatzszenarien für die Arbeit in verschiedenen Arbeitskontexten, etwa in verschiedenen Projekten: Setzte man voraus, dass eine Diskette immer die Dokumente eines einzelnen Projekts speicherte, konnte man sich für jedes seiner Projekte einen Desktop einrichten und diesen dann bei Bedarf laden, indem man die passende Diskette erneut einlegte. Spannend war diese Technik auch, wenn man in einem Büro arbeitete, in dem es mehrere Macintoshs gab, denn man konnte nun seine Projektdiskette mitnehmen, in den Macintosh an einem anderen Arbeitsplatz einlegen und hatte trotzdem alle Arbeitsmaterialien auf dem Desktop parat und auch alle Ordnerfenster wieder so geöffnet, wie man sie am eigenen Rechner hinterlassen hatte.

Microsoft Windows – Ein Fehlschlag?

1983, bereits vor der Veröffentlichung des Macintosh, kündigte Microsoft eine grafische Nutzungsoberfläche namens Windows an. Microsoft war an der Software-Entwicklung des Macintosh beteiligt. Die ersten Versionen von Excel und PowerPoint und die erste Word-Version mit grafischer Nutzungsschnittstelle erschienen nicht für den IBM PC, sondern für den Macintosh. Diese Entwicklungseinblicke erlaubten Microsoft natürlich, sich für das eigene System „inspirieren“ zu lassen. Der Vorwurf des Ideendiebstahls stand fortan immer im Raum und war Gegenstand von Gerichtsurteilen und nicht zuletzt Stoff für die religionsartig geführten Debatten über das bessere System. Wenn Sie in dieser Hinsicht eine Meinung haben, möchte ich Sie bitten, sich zumindest für den Moment davon zu lösen und MacOS und Windows zunächst einmal als das zu betrachten, was sie sind bzw. was sie waren, denn die Unterschiede der Systeme sind eigentlich viel interessanter, als die Inspirationen, von denen es im Laufe der kommenden Jahrzehnte ohnehin in beiderlei Richtung viele geben sollte.

Die erste veröffentliche Version von Windows erschien im November 1985. Dieses Windows 1.0 hatte einen schlechten Ruf. Der war sicherlich teilweise berechtigt – dazu später mehr. Auf der anderen Seite gilt es jedoch durchaus anzuerkennen, was Microsoft hier hinbekommen hat. Die Hardware-Voraussetzungen von Windows waren auf dem Papier recht bescheiden. Ein Nutzer brauchte nur 256 KB RAM, einen Rechner mit zwei Diskettenlaufwerken, eine Maus und eine Bildwiedergabe, die nicht nur Text, sondern auch Grafik anzeigen konnte. Mit Ausnahme der Maus, die damals noch kein Standard war, war diese Ausstattung für Rechner des Jahres 1985 nichts Besonderes mehr. So wie es auch bei vielen Windows-Versionen in den folgenden Jahren der Fall sein sollte, war diese von Microsoft angegebene Minimalausstattung für das System aber nicht wirklich nutzbar. Eine Festplatte und vor allem mehr Arbeitsspeicher waren sehr anzuraten. Festplatten wurden zwar im Firmenkontext bereits üblich, doch Arbeitsspeicher über die 1-MB-Grenze hinaus war noch extrem kostenintensiv. Besaß man aber eine damit verbundene teure Speicher-Erweiterungskarte, konnte Windows den zusätzlichen Speicher verwenden und stellte seinen Anwendungen somit mehr Speicher als die unter MS-DOS direkt verwendbaren 640 KB zur Verfügung.

Windows 1.0 war noch kein eigenständiges Betriebssystem. Ein Windows-Nutzer startete seinen Rechner mit MS-DOS und lud dann Windows so wie jedes andere DOS-Programm. Je nach eingebauter Grafikkarte erschien das System nun in verschiedener Optik. War nur eine CGA-Grafikkarte eingebaut, wurde Windows monochrom dargestellt. Die Auflösung war mit 640 x 200 Punkten etwas eingeschränkt, aber durchaus nutzbar. Verfügte der stolze Windows-Nutzer hingegen über eine extrem moderne EGA-Grafikkarte, stieg die Auflösung auf 640 x 350 Pixel bei sechzehn Farben. Die beste Auflösung von 720 x 348 Pixeln konnte mit einer sogenannten Hercules-Grafikkarte erreicht werden. Da Hercules-Grafikkarten von Haus aus keine Farbe unterstützten, war natürlich auch hier die Darstellung monochrom. In der Abbildung oben sehen Sie Windows in der EGA-Darstellung. Die Farbwahl von Microsoft lässt aus ergonomischer Sicht stark zu wünschen übrig. Über die Gründe hierfür kann ich nur spekulieren. Zum einen war die Fähigkeit des EGA-Grafikstandards, gedeckte Farben anzuzeigen, eingeschränkt. Die sechzehn möglichen Farben waren allesamt recht grell und gesättigt. Zum anderen kann ich mir gut vorstellen, dass Microsoft durchaus ein wenig herausstellen wollte, dass das eigene System im Gegensatz zu damaligen Macintosh-Rechnern, Farben unterstützt. Es mag sein, dass deswegen so auffällige Farben gewählt wurden.

Windows erlaubte die Ausführung von DOS-Anwendungen im Fenster, aber vor allem natürlich die Ausführung von expliziten Windows-Anwendungen. Es gab bei Windows keinen Desktop und auch kein mit dem Finder wirklich vergleichbares Tool. Zentrale Schnittstelle war die sogenannte „MS-DOS Executive“, ein sehr simpler Dateimanager und Programmstarter. Er bestand aus nur einem Fenster, in dem ein Datei-Listing angezeigt wurde. Es gab keine Icons, keine räumliche Positionierung und kein Drag and Drop. Da Windows auf DOS aufsetzte, wurde auch dessen Dateinamenbeschränkung von acht plus drei Zeichen in Großbuchstaben und ohne Sonderzeichen geerbt. Man konnte also eine Datei nicht „Der 5. Versuch eines Buches über Computergeschichte.doc“ nennen, sondern musste sich mit so etwas wie „CGESCH_5.DOC“ begnügen. Windows 1.0 sah verglichen mit Apples Betriebssystem eher grobschlächtig aus. Die Farben waren extrem bunt, das System verwendete in seiner Nutzungsschnittstelle durchgehend Schriftarten aus der Terminal-Ära statt für die grafische Schnittstelle neu entwickelten Fonts wie bei Apple, und selbst die kleinen Icons an den Fenstern, etwa die an den Scrollbars, sahen im Vergleich zu denen bei Apple sehr altbacken aus. Hinzu kam, dass das System auf den meisten damaligen Computern unwahrscheinlich langsam lief. Vielfach konnte man regelrecht zuschauen, wie die Bildschirminhalte neu gezeichnet wurden.

Windows war MacOS aber auch in manchem durchaus voraus. Allem voran muss hier das Multitasking genannt werden. Mehrere Anwendungen konnten bei Windows in Fenstern gleichzeitig laufen. Die Fenster konnten dabei so angeordnet werden, dass man die Anwendungen gleichzeitig im Blick hatte. Oben sehen Sie die Anwendungen Paint und Write nebeneinander. Eine systemweite gemeinsame Zwischenablage erlaubte es, Daten zwischen den Programmen auszutauschen. Es konnte zum Beispiel die in Paint gezeichnete Grafik kopiert und im Text in Write eingefügt werden. Das ging so zwar sehr vergleichbar auch beim Macintosh, etwa mit den Programmen MacPaint und MacWrite, allerdings musste bei Windows keines der Programme erst beendet werden, um die Operation im anderen durchzuführen – ausreichend Arbeitsspeicher natürlich vorausgesetzt.

Das Fensterhandling bei Windows 1.0 unterschied sich von dem späterer Windows-Versionen und auch von dem von MacOS. Verwenden wir das System heute, ist ein bisschen Eingewöhnung erforderlich. Noch recht normal ist die Möglichkeit, ein Fenster zu minimieren, bei Windows 1.0 durchaus korrekt „Iconize“ genannt, denn eine minimierte Anwendung erschien nun als Icon am unteren Bildschirmrand. Auch eine Darstellung, bei der ein Fenster den ganzen Bildschirm füllte, „Zoomed“ genannt, war bereits vorhanden. Auffällig im Vergleich zu heutigen Systemen ist aber, dass es bei Windows 1.0 mit der Ausnahme von Meldungsfenstern und eingeblendeten Fenstern zum Laden und Speichern von Dateien keine überlappenden Fenster gab. Diese Eigenschaft wird aus heutiger Sicht gerne als Nachteil des Systems beschrieben. Probiert man es aber einmal selbst aus, wird klar, dass die Art und Weise, wie bei Windows 1.0 Fenster angeordnet wurden, durchaus sehr praktisch war. Im Gegensatz zu einem heutigen Windows oder MacOS, bei dem der Nutzer die volle Kontrolle über die Fensterpositionierungen hat, übernahm bei Windows 1.0 das System selbst einen Großteil der Aufteilungsarbeit. Lief nur ein einziges Programm, etwa nach dem Start die MS-DOS-Executive, wurde diesem der maximale Platz eingeräumt. Startete der Nutzer dann ein weiteres Programm, wurde der Bildschirm automatisch aufgeteilt, sodass beide Anwendungen ihren Platz fanden. Ganz der Automatik hingeben musste man sich aber nicht. Der Nutzer hatte durchaus Einfluss auf die Anordnung. Nahm er etwa ein Icon einer minimierten Anwendung auf und zog es an den oberen Bildschirmrand, wies Windows dem dazugehörigen Fenster die obere Bildschirmhälfte zu. Gleiches funktionierte auch mit den anderen Bildschirmrändern und mit nicht-minimierten Fenstern durch die Auswahl des Menüeintrags „Move“ oder durch Ziehen der Titelleiste an den entsprechenden Rand. Hatte man diesen Mechanismus erst einmal heraus, war es in Windows 1.0 sehr einfach, mehrere Anwendungen bzw. mehrere Dokumente gleichzeitig in den Blick zu bringen, um mit ihnen im Zusammenhang zu arbeiten. Eine Anordnung wie die obige von Write und Paint in späteren Windows-Versionen oder auch in MacOS zu erzeugen, bedeutete viel Aufwand, unter Windows 1.0 dauerte es nur wenige Sekunden. Erst in Windows 7, also 24 Jahre später, führte Microsoft wieder eine Funktion ein, mit der eine automatische Aufteilung der Fenster auf diese Art und Weise möglich war und verband damit die Vorteile der automatischen Fensteraufteilung mit den Vorteilen frei positionierbarer Fenster.

Die erste Windows-Version war kein Erfolg, obwohl die grafische Nutzungsschnittstelle von Microsoft der von Apple in einigen Punkten durchaus überlegen war. Sie ermöglichte Multitasking, das Fensterhandling war gerade bei der Ausführung mehrerer Anwendungen zur gleichen Zeit sehr praktisch, und im Gegensatz zum Macintosh konnte Windows auch in Farbdarstellung verwendet werden. In vielen anderen und vielleicht auch wichtigeren Bereichen hinkte Microsoft aber hinterher. Das optische Design von MacOS war viel ausgetüftelter. Mit dem Finder stand ein effektives Werkzeug zur Dateiverwaltung zur Verfügung, der Desktop konnte im Rahmen der Einschränkung des Systems als Ort für die aktuellen Arbeitsdokumente dienen und das System war durch seine Einschränkung auf Single-Tasking und seine Optimierung auf die verwendete Hardware recht flott. Windows hingegen war auf den meisten damaligen PCs zwar lauffähig, verfügte dann aber nicht über genug Leistung für ein wirklich flüssiges Arbeiten. Mit dazu beigetragen, dass kaum jemand Windows 1.0 kaufte, hat sicher auch, dass es außer den einfachen, mitgelieferten Programmen quasi gar keine Software gab. Selbst Microsofts eigene Anwendungen Word und Excel wurden erst für die zweite Version von Windows verfügbar.

Die Möglichkeit, mehrere Programme gleichzeitig im Zugriff zu haben, war natürlich auch beim Macintosh gefragt. Nach einigen speziellen Lösungen wurde im Jahr 1987 der Multifinder eingeführt. Verwendete man ihn statt des klassischen Finders, konnte man in der Menüleiste des Macintosh zwischen den laufenden Anwendungen wechseln. Für Macs mit wenig Speicher oder ohne Festplatte, also Systemen bei denen Multitasking wenig Sinn ergab, blieb der alte Finder mit dem Single-Tasking-Betrieb erhalten.

Ebenfalls im Jahr 1987 stellte Microsoft die zweite Version von Windows vor. Das System lief nun glatter und schneller. Ebenso wie beim Macintosh gab es nun überlappende Fenster. Die praktische Funktion des automatischen Fenster-Handlings fiel dem leider zum Opfer. Für Windows 2 gab es nun auch Software zu kaufen. Zu nennen sind hier vor allem Adobe Pagemaker, MS Word und MS Excel. Alle drei Programme sind von der jeweiligen Macintosh-Software portiert worden.

Windows 3 – Windows wird erwachsen

Die ersten wirklich erfolgreichen Windows-Versionen erschienen mit der 3er-Serie ab 1990. Windows 3.0 wurde optisch komplett neu gestaltet. Die klobigen Terminal-Schriften, die auch in Windows 2 noch verwendet wurden, wurden zum Teil durch modernere Bildschirmschriften ersetzt. Auch die MS-DOS-Executive wurde abgeschafft und durch zwei Programme ersetzt, die die grundsätzliche Arbeitsweise mit Windows von nun an prägten. Der Programm-Manager diente der Übersicht der auf dem Rechner installierten Anwendungsprogramme. Diese wurden als Icons dargestellt, die in sogenannte „Programmgruppen“ eingeordnet wurden. Das Konzept des Programm-Managers war ähnlich dem der Programm-Launcher und Homescreens bei iOS und Android. Auch hier steht das Anwendungsprogramm im Vordergrund, wird durch ein Icon repräsentiert und von einer zentralen Stelle aus gestartet. Dem Programm-Manager wurde ein neu entwickelter Datei-Manager an die Seite gestellt. Dieses Dateiverwaltungsprogramm ermöglichte einen erheblich komfortableren Umgang mit den Dateien im Dateisystem als die vorherige MS-DOS-Executive. Innerhalb des Datei-Managers konnten mehrere Fenster geöffnet werden. Dateioperationen ließen sich somit bequem per Drag and Drop erledigen.

Das sehr populäre Windows 3.1 aus dem Jahr 1992 brachte vor allem Änderungen unter der Haube. Aus Nutzungsschnittstellen-Sicht erwähnenswert war die OLE-Technik (Object Linking and Embedding), die es erlaubte, Objekte aus einem Programm in ein anderes Programm einzubetten und dabei die Bearbeitbarkeit des Objektes weiterhin zu gewährleisten. So ließen sich zum Beispiel Ausschnitte aus Excel-Tabellen in Word einbinden, ohne die Möglichkeit der weiteren Bearbeitbarkeit zu verlieren.

Die 3er-Versionen von Windows waren durch die starke Präsenz des Programm-Managers als Haupt-Nutzungsoberfläche stark programmbasiert. Man öffnete in der Regel nicht ein Dokument, sondern startete ein Programm und lud dann darin das Dokument. Der Dateimanager ermöglichte zwar eine komfortable Dateiverwaltung innerhalb von Windows, hatte aber einen ganz anderen Charakter als der Finder. Das lag schon mal daran, dass der Datei-Manager erheblich weniger zentral war. Er stellte nicht, wie der Finder, die Hauptoberfläche des Betriebssystems, sondern war nur eines der vielen Anwendungsprogramme. Auch seine Darstellung war viel technischer als Apples Finder. Man arbeitete nicht mit als Icons dargestellten Dokumenten, die frei innerhalb eines Fensters oder auf dem Desktop positionierbar waren, sondern organisierte Dateien in Listenform.

MacOS 7 – Der Zenit des klassischen Betriebssystems

Bei Apple endete 1991 mit MacOS 7 die Ära der Betriebssysteme, die auf Rechnern liefen, die nur über ein Diskettenlaufwerk verfügten. Das System verlangte nun eine Festplatte und mindestens 2 MB RAM. Da viele alte Macintosh-Computer noch gerne genutzt wurden, blieb MacOS 6 noch lange in Gebrauch und wurde auch von neuerer Software noch unterstützt. Die Version 7 führte einige Änderungen in der Arbeitsweise des Systems ein. Eher eine Kleinigkeit war hier vielleicht die Einführung von Labels. Dateien konnten nun mit einer Markierung wie etwa „fertig“ oder „kritisch“ versehen werden. Besonders praktisch war dieses Feature auf Systemen mit Farbmonitoren, denn Labels wurden mit Farben verbunden. Wurde eine Datei etwa mit „hot“ beschriftet, wurde das Icon rötlich eingefärbt und hob sich somit direkt optisch von den anderen ab. Da MacOS nun sicher davon ausgehen konnte, dass eine Festplatte zur Verfügung steht, wurden einige Änderungen an der Arbeitsweise des Systems vorgenommen. Eine dieser Änderungen betraf das Löschen von Dateien. Bis hierhin funktionierte der Papierkorb von MacOS so, dass eine Datei, die gelöscht wurde, zunächst nur zur Löschung vorgemerkt und fortan an ihrem Ort im Dateisystem nicht mehr angezeigt wurde. Das eigentliche Löschen passierte erst dann, wenn die Diskette ausgeworfen oder wenn der Desktop-Prozess selbst beendet wurde, im Single-Tasking-Betrieb also beim Laden eines anderen Programms, im Multi-Tasking-Betrieb spätestens beim Herunterfahren des Rechners. Ab MacOS 7 hatte der Papierkorb nun einen festen Ort auf der Systemfestplatte. Sein Inhalt blieb also fortan so lange erhalten, bis er explizit geleert wurde.

Eine durchaus tiefgreifende Änderung, die aber den meisten Nutzern wahrscheinlich gar nicht direkt auffiel, betraf die Funktionsweise des Desktops an sich. Bis einschließlich MacOS 6 funktionierte der Desktop in der zu Beginn beschriebenen Funktionsweise. Auf dem Desktop abgelegte Dateien wurden zwar dort angezeigt, ihr eigentlicher Speicherort war aber ein Ort auf einer eingelegten Diskette oder auch einer angeschlossenen oder eingebauten Festplatte. Dateien konnten im Finder auf den Desktop gezogen werden und von dort aus per „Put Away“ wieder zurückgelegt werden. Speicherte man eine Datei aus einer Anwendung heraus ab, konnte man sie auf die Platte oder auf eine Diskette speichern, nicht aber direkt auf den Desktop legen. Diesen Schritt musste man später im Finder unternehmen. Ab MacOS 7 war es nun möglich, Dateien und Ordner auch direkt auf dem Desktop zu erzeugen und unmittelbar dorthin zu speichern. Für diese Dateien und Ordner funktionierte „Put Away“ nun nicht mehr, die Funktion blieb grundsätzlich aber erhalten.

Zehn Jahre nach der Lisa wurde auch das Konzept der „Stationery Pads“ wieder eingeführt. Zur Erinnerung: Bei der Apple Lisa waren Stationery Pads das zentrale Konzept zum Erzeugen neuer Dateien. Statt in einer Anwendung eine Datei unter einem neuen Dateinamen abzuspeichern, erzeugte man bei der Lisa die Kopie einer Vorlagendatei, indem man einen Doppelklick auf einem Stationery Pad, was im übertragenen Sinn „Abreißblock“ bedeutet, machte. Daraufhin wurde automatisch eine Kopie erzeugt, die nun zur Bearbeitung geöffnet werden konnte. Nun gab es die Abreißblöcke auch beim Macintosh. Die Implementierung der Stationery Pads unter MacOS 7 war allerdings erheblich einfacher. Bei der Lisa erzeugte ein Klick auf einen Abreißblock eine Kopie am gleichen Speicherort und in räumlicher Nähe. Bei MacOS 7 wurde lediglich die Originaldatei im verknüpften Programm geladen. Hier stand dann die Option „Speichern“ nicht zur Verfügung, was den Nutzer zwang, „Speichern unter“ zu wählen. Die Funktion der Stationery Pads gibt es übrigens heute noch. Sie kann über die Eigenschaft „Formularblock“ in den Datei-Informationen aktiviert werden. Die Umsetzung entspricht heute aber eher wieder der der Lisa. Es wird eine Kopie am gleichen Speicherort erzeugt.

Betrachten wir die beiden wichtigsten Betriebssysteme im Jahr 1994, finden wir zwei unterschiedliche Paradigmen: Auf dem Macintosh hatte sich eine dokumentbasierte Arbeitsweise etabliert. Es gab kein Äquivalent zu einem Programm-Manager. Die zentrale Komponente des Betriebssystems war der Finder mit seiner grafisch-räumlichen Darstellung des Dateisystems. Bei Windows hingegen standen die Anwendungen im Vordergrund, was sich vor allem durch die Dominanz des Programm-Managers ausdrückte. Die Dateiverwaltung fand in einem Zusatz-Tool als eine der vielen möglichen Funktionen des Computersystems statt. Im Jahre 1995 sollte sich dieser Unterschied in den Arbeitsweisen drastisch verringern, denn mit Windows 95 gelang Microsoft die Verbindung der beiden Welten. Zudem war Windows 95 technisch in vielerlei Hinsicht dem Apple-Betriebssystem überlegen. Apple geriet in Sachen Betriebssystem zunehmend ins Hintertreffen. Noch stärker als bei Windows 95 zeigte sich Microsofts technischer Vorsprung bei Windows NT. NT stand für New Technology. NT-Systeme wurden in der Regel bei Servern und auf Firmenrechnern eingesetzt. Das Betriebssystem ging aus der zunächst gemeinsamen Entwicklung eines Betriebssystems namens OS/2 zusammen mit IBM hervor. Windows NT war im Gegensatz zu anderen Windows-Versionen inklusive Windows 95, 98 und ME kein Aufsatz auf MS-DOS, sondern ein eigenständiges System. Die erste Version von Windows NT hatte im Jahre 1993 die Versionsnummer 3.1. Sie war das erste Windows, das Nutzerkonten und lange Dateinamen unterstützte, hatte ansonsten aber die gleiche Nutzungsschnittstelle wie Windows 3.1. Das im Jahr 1996 veröffentlichte Windows NT 4 war von der Bedienweise identisch mit Windows 95. Die technischen Neuheiten von Windows NT waren mannigfaltig. Ihre Erörterung würde an dieser Stelle aber viel zu weit führen, denn sie betreffen nicht die Nutzungsschnittstelle des Systems und hatten keinerlei Einfluss darauf, welche Nutzungsschnittstellen-Welten am PC zur Verfügung standen.

Windows 95 – Die Verbindung der zwei Welten

Für Windows 95 konzipierte Microsoft eine komplett neue Desktop-Oberfläche. Vieles, was Sie heute als Nutzungsschnittstelle von Windows kennen, wurde in dieser Windows-Version eingeführt. Alle Windows-Versionen ab 1995 unterstützten lange Dateinamen mit Leerzeichen und Umlauten. Windows verfügte nun über einen Desktop, auf dem sich ein Papierkorb und ein Icon namens „Arbeitsplatz“ (im Englischen: „My Computer“) befanden. Die Papierkorb-Funktionalität war bei Windows gänzlich neu. Dateien wurden nun wie beim Macintosh nicht mehr direkt gelöscht, sondern zunächst im Papierkorb abgelegt, aus dem sie wieder zurückgeholt werden konnten. Der „Arbeitsplatz“ bot Zugriff auf die Festplatten und Diskettenlaufwerke des Computers. Der bisherige Dateimanager wurde durch den Windows Explorer ersetzt. Seine Standard-Darstellung ähnelte der von MacOS. Ein Ordner öffnete sich in ein Fenster mit Icon-Ansicht, die räumlich anpassbar war. Wurde ein Ordner-Icon innerhalb dieses Fensters per Doppelklick geöffnet, öffnete sich ein neues Fenster, das die Inhalte dieses Ordners anzeigte. Dieses Verhalten konnte stärker als bei Apple angepasst werden. Viele stellten sich den Explorer zum Beispiel so ein, dass das Öffnen eines Unterordners kein neues Fenster öffnete, sondern dieser einfach im gleichen Fenster angezeigt wurde. Diese Variante wurde in späteren Windows-Versionen zum Standard. Waren viele Dateien zu organisieren, bot der Explorer eine zweigeteilte Ansicht. In einer Leiste auf der linken Seite wurde dann der Verzeichnisbaum angezeigt, während im Hauptinhaltsbereich die Dateien des ausgewählten Ordners in Listenform angezeigt wurden. Diese durchaus praktische Ansichtsvariante des Explorers ist leider im Laufe der Jahre abhandengekommen und durch eine Anzeige wichtiger Ordner an dieser Stelle ersetzt worden.

Der Explorer von Windows 95 war nicht nur viel anpassbarer als Apples Finder, er ermöglichte im Gegensatz zu diesem auch Nebenläufigkeit. Der Fachbegriff hierfür lautet „Multi-Threading“. Im Grunde ist Multi-Threading fast das Gleiche wie das bekanntere Multitasking. Während man unter Multitasking heute allerdings meist das gleichzeitige Ausführen mehrerer Programme versteht, meint Multi-Threading die gleichzeitige Ausführung mehrerer Aktionen innerhalb einer Anwendung. Das Multi-Threading machte sich vor allem bei langlaufenden Operationen bemerkbar. Kopierte man zum Beispiel viele Dateien, zeigten sowohl Windows 95 als auch MacOS Fenster an, die den Fortschritt des Kopiervorgangs anzeigten und dessen Abbruch ermöglichten. Bei MacOS musste man nun entweder das Kopieren abwarten oder aber abbrechen, bevor man mit dem Finder weiterarbeiten konnte. Unter Windows 95 hingegen blieben Explorer und Desktop auch während der Kopieroperation arbeitsbereit. Das Kopieren wurde im Hintergrund zu Ende geführt, während der Nutzer andere Aufgaben erledigten konnte.

Mit dem Explorer holte Microsoft in Sachen Desktop und Datei-Handling zu Apples Betriebssystem auf und war diesem in manchen Bereichen voraus. Windows konnte von nun an wie MacOS dokumentzentriert betrieben werden. Während man unter Windows 3.1 noch Microsoft Word öffnete, dann im Datei-Menü „Öffnen“ wählte, um eine Datei auszuwählen, wurde es unter Windows 95 üblich, den Ordner mit der gewünschten Datei im Explorer anzunavigieren und durch Doppelklick die Datei im passenden Programm zu öffnen. Die bisherige Möglichkeit, eine Anwendung direkt zu starten, blieb in Windows 95 erhalten. Die Auswahl der Anwendung geschah allerdings nicht mehr aus einem Bildschirm füllenden Programm-Manager heraus, sondern aus dem neu erfundenen Startmenü, das neben dem Zugriff auf die Systemeinstellungen und die neu eingeführte Dateisuche Zugriff auf die installierten Anwendungen in einem hierarchisch organisierten Menü ermöglichte. Die Abbildung oben zeigt das geöffnete Startmenü mit der ausgewählten einfachen Textverarbeitung WordPad. Das Startmenü war Teil der ebenfalls neu eingeführten Taskleiste am unteren Bildschirmrand. Mit dieser bekam Windows eine neue Nutzungsschnittstelle für das Wechseln zwischen den laufenden Programmen und Fenstern. In vorherigen Windows-Versionen war dies nur mittels der Tastenkombination „ALT-Tab“ möglich, die auch heute noch bei Windows (und inzwischen auch als „CMD-Tab“ unter MacOS) funktioniert. Der Nachteil dieser Methode ist, dass die Liste der laufenden Anwendungen nicht dauerhaft sichtbar ist und nur derjenige, der die Tastenkombination kennt, überhaupt die Chance hat, Anwendungen zu wechseln ohne laufend Fenster verkleinern oder verschieben zu müssen. Mit der Taskleiste gab es nun ein Stück Nutzungsschnittstelle, das den Windows-Nutzern durchgehend anzeigte, welche Programme liefen und den Wechsel zwischen den Anwendungen mit einem einzigen Klick erlaubte.

Mit Windows 95 hat sich die Nutzungswelt für Windows-Nutzer komplett geändert. Man mochte sich über manche Implementierungsdetails streiten und den von MS-DOS geerbten Konfigurations-Wahnsinn beklagen, aus Nutzungsschnittstellen-Sicht jedoch war Microsoft hier ein großer Wurf gelungen. Die dokumentzentrierte Desktop-Welt, wie es sie am Macintosh gab, wurde mit der programmbasierten Arbeitsweise, wie sie bei Windows üblich war, erstaunlich bruchlos verwoben. Windows verfügte nun im Vergleich zu MacOS mit dem Explorer über einen potenteren Datei-Manager und mit der Taskleiste über einen viel besseren Task-Switcher. Apple geriet durch Windows 95 unter Druck, denn das System war nicht nur von der Nutzungsschnittstelle her mindestens auf gleichem Niveau, auch die Systemstruktur an sich war solider als die von MacOS, bei dem Apple an das ursprüngliche Single-Tasking-System immer neue Funktionalitäten „drangebastelt“ hatte und das daher viele Altlasten mitschleppte. MacOS hatte zum Beispiel keinen Speicherschutz. Wenn mehrere Programme gleichzeitig laufen, belegt jedes dieser Programme einen eigenen Bereich im Arbeitsspeicher. Unter MacOS waren diese Bereiche nicht gegeneinander geschützt. Ein laufendes Programm konnte die Speicherinhalte der anderen Programme lesen und auch verändern. Das war nicht nur sehr unsicher, sondern auch absturzgefährdend. Ein fehlerhaftes Programm konnte leicht andere Programme oder sogar das ganze Betriebssystem mit sich reißen. Eine Neuentwicklung tat not! Die Entwicklung eines Nachfolgers für das klassische MacOS verzögerte sich jedoch immer wieder. Für Microsoft war die Anpassung der Nutzungsschnittstelle, die sie mit Windows 95 vornahmen, hingegen die Vorgabe für das nächste Jahrzehnt. Die folgenden Windows-Versionen NT 4, 98, ME, 2000 und XP wurden zwar optisch jeweils an den Zeitgeist angepasst, die Grundelemente der Nutzungsschnittstelle Desktop, Explorer, Taskleiste und Startmenü blieben aber nahezu unverändert bestehen.

Apple versuchte sich in den folgenden Jahren an einer Betriebssystem-Neuentwicklung namens „Copland“, geriet damit aber in große interne Schwierigkeiten. Gezwungen, mit dem alten Betriebssystem weiterzumachen, erschienen die Versionen 8, 8.5 und 9 von MacOS. Apple nahm hier vor allem viele optische Veränderungen vor und integrierte einige Komponenten der gescheiterten Neuentwicklung in das alte Betriebssystem. Ab 1997 unterstützte auch der Finder Nebenläufigkeit, sodass nun auch hier Dateioperationen das Weiterarbeiten im Finder nicht mehr blockierten. Mit MacOS 8.5 integrierte Apple die Suchsoftware „Sherlock“ in das Betriebssystem. Diese Software erlaubte nicht nur die lokale Suche, sondern suchte über Schnittstellen auch in Internet-Datenbanken. MacOS 9 brachte eine Unterstützung für mehrere Nutzer am gleichen Macintosh. Microsoft sah dies bereits in NT 3.1 aus dem Jahr 1993 vor. Auch Windows 95 unterstützte, wenn auch eingeschränkt, mehrere Benutzerkonten am gleichen Computer. Von diesen Änderungen abgesehen blieb das alte MacOS viel länger, als Apple es plante. Zusammen mit einer unübersichtlichen Produktpolitik brachte es Apple 1997 an den Rand der Pleite. Die Firma rettete sich durch den Kauf der Firma Next Computer, einer Gründung von Apple-Mitgründer Steve Jobs. Teil dieses Kaufs war das Betriebssystem NextStep, eine innovatives, grafisches Betriebssystem auf Unix-Basis. NextStep wurde auf die Macintosh-Architektur portiert. Einige Elemente der NextStep-Nutzungsoberfläche, etwa ein zentrales Dock, wurden in die neu konzipierte Oberfläche namens Aqua übernommen, das sich ansonsten stark an der Funktionsweise des bisherigen MacOS orientierte. Das neue Betriebssystem, das rein technisch kaum etwas mit der vorherigen Version zu tun hatte, bekam die Versionsnummer 10, die fortan immer als X geschrieben wurde. Über 10 ist Apple bis zum Jahr 2020 nicht hinausgekommen, denn seit der Version 10.0 wurde nur noch hinter dem Komma hochgezählt. Erst mit der Version mit dem Codenamen “Big Sur” erhöhte Apple die Versionsnummer auf 11.

MacOS X (10) – MacOS neu erfunden

MacOS 10.0 von 2001 sah dem vorherigen Betriebssystem durchaus ähnlich. Es gab aber gewichtige Unterschiede in der Nutzungsschnittstelle. Da der Unterbau des Betriebssystems nun Unix war, gab es erstmals eine Kommandozeile, die in einem Terminal-Programm aufgerufen werden konnte. Das auffälligste neue Element des Betriebssystems war aber nicht die Kommandozeile, sondern das von NextStep geerbte Dock am unteren Bildschirmrand. Im Dock werden bis zum heutigen Tage bei MacOS häufig genutzte Programme dauerhaft vorgehalten. Außerdem zeigt es an, welche Programme gerade aktiv sind und enthält einen Bereich, in dem minimierte Fenster abgelegt werden können. Die Menüleiste des Finders konnte Verknüpfungen zu Ordnern und Dateien aufnehmen und stand dem Nutzer damit als Schnellzugriff zur Verfügung. In der Abbildung oben sind hier die Ordner Computer, Home, Favorites und Applications untergebracht. Ab MacOS 10.3 wurde diese Funktion in eine Leiste auf die linke Seite eines Finder-Fensters verschoben, wo man sie auch bei aktuellen MacOS-Versionen noch findet. Der Desktop war nun, wie bei Windows, ein dedizierter Ordner im Nutzerverzeichnis, der lediglich vollflächig angezeigt wurde. Dateien wurden auf den Desktop verschoben oder kopiert. Das praktische „Put Away“ gab es fortan leider nicht mehr.

Mit MacOS 10 war Apple mit Microsoft grundsätzlich wieder gleichauf. Ehrlicherweise musste man sich aber eingestehen, dass die Versionen 10.0 und 10.1 noch mit vielen „Kinderkrankheiten“ zu kämpfen hatten und auf vielen der damals verbreiteten Macs nicht performant liefen. Auch bei neuen Geräten lieferte Apple zunächst beide Systeme aus, was viele Nutzer dazu veranlasste, weiter auf das altbekannte MacOS 9 und seine umfangreiche Software-Bibliothek zu setzen. Schlussendlich setzten sich die neuen Versionen aber durch, denn nicht nur waren die Systeme nach Beseitigung der anfänglichen Probleme stabiler, der Finder wurde ebenso erheblich verbessert und auch das Dock erwies sich als große Stärke des Systems. Gleichzeitig wurde die Einfachheit der Bedienung früherer Systeme beibehalten. Apple schloss aber nicht nur auf, sondern ging in einigen Bereichen auch weiter als Microsoft, etwa mit der neuen zentralen Anwendung namens „Vorschau“. Die Vorschau konnte eine Vielzahl von Dateien anzeigen, ohne das Anwendungsprogramm überhaupt starten zu müssen. Diese Funktion war sehr praktisch und sinnvoll, denn in der Tat sollen Dateien in vielen Fällen ja nur betrachtet und nicht etwa bearbeitet werden. Diese Vorschaufunktion in MacOS wurde daher im Laufe der Jahre stets weiter verbessert.

Ebenfalls im Jahr 2001 erschien Microsofts beliebtes Windows XP. Aufgrund von Problemen bei der Entwicklung eines Nachfolgers und des schlechten Rufs des 2007 erschienenen Windows Vista blieb Windows XP faktisch bis 2009 die aktuelle Windows-Version. Mit Windows XP führte Microsoft die professionelle NT-Linie und die klassische, auf MS-DOS basierende Windows-Linie zusammen. Windows XP war keine DOS-Erweiterung mehr, sondern ein vollständiges Betriebssystem. In Sachen Nutzungsschnittstelle stand Windows XP weiterhin in der Tradition von Windows 95, verfügte aber über ein Standard-Aussehen, das die Oberfläche sehr bunt darstellte. Zusammen mit dem Standard-Hintergrundbild einer hügeligen Wiesenlandschaft brachte dies dem System den Spitznamen „Teletubby-Windows“ ein.

In den folgenden Jahren glichen sich MacOS und Windows nach und nach immer mehr aneinander an. Ab 2003 bot MacOS 10.3 eine komfortable Funktion, alle geöffneten Fenster in einer Übersicht namens „Exposé“ auf die Schnelle zu überblicken. Im 2005 erschienenen MacOS 10.4 machte Apple die Suche bzw. ihre Ergebnisse zu einem zentralen Element des Betriebssystems. Ein Index-System namens „Spotlight“ wurde eingeführt, die Suche wurde in die Finder-Fenster und in die System-Menüleiste eingefügt. Auch bei Windows wurde die Suche zentraler. Ab Windows Vista (2007) befand sich ein Suchfeld prominent im Startmenü. In Windows 10 ist es dann dauerhaft sichtbar in die Taskleiste gewandert. Ebenfalls 2007 verminderte MacOS 10.5 nochmals die Notwendigkeit, Anwendungen zu öffnen. Eine Quickview-Funktion wurde eingeführt, die eine markierte Datei durch Druck auf die Leertaste direkt anzeigte und durch abermaliges Betätigen der Leertaste wieder verschwinden ließ. Nach der gefloppten Windows-Version Vista erschien 2009 mit Windows 7 wieder eine Windows-Version, die sehr populär wurde. Die wohl auffälligste Neuerung dieses Systems betraf die Taskleiste, die nun wie das Dock von MacOS eine Kombination aus Task-Switcher und Schnellstartleiste wurde. Als Antwort auf Apples Exposé konnte in der Taskleiste mit der Funktion Aero-Peek eine Schnellübersicht der Fenster einer geöffneten Anwendung angezeigt werden. Hilfreich waren auch die Verbesserungen im Fenster-Handling. Mit der Funktion Aero-Snap gab es 24 Jahre nach Windows 1.0 wieder eine Funktion, Fenster automatisch anordnen zu lassen. Zog man ein Fenster an den rechten oder linken Bildschirmrand, nahm es automatisch die Hälfte des Bildschirms ein. Unter Windows 10 wurde diese Funktion nochmals optimiert, sodass nun auch Drei-Fenster-Anordnungen möglich wurden.

MacOS 10.7 – Implizites Speichern sorgt für Verwirrung

2011 führte Apple in MacOS 10.7 eine Änderung ein, die nicht nur Freunde fand, in Bezug auf die Sichtweise, wie ich hier die Idee von Nutzungsschnittstellen eingeführt habe, aber sehr sinnvoll und bei Weitem überfällig war. Die Art und Weise, wie Dateien gespeichert werden, wurde so geändert, dass ein explizites Speichern nicht mehr nötig war. Eigentlich ist es verwunderlich, dass das Laden und Speichern bei MacOS im Jahre 2011 noch genau so funktionierte, wie im Jahr 1984, denn die Gründe dafür, es damals so zu gestalten, bestanden schon lange nicht mehr. Zu Beginn des Kapitels habe ich Ihnen erläutert, dass die Hardware-Einschränkungen des Macintosh dafür sorgten, dass Nutzer bearbeitete Dateien explizit speichern mussten. Dieses explizite Speichern war nach wie vor üblich, obwohl es mit auf Festplatten basierenden Systemen und üppiger Speicherausstattung eigentlich keine Notwendigkeit mehr dafür gab bzw. gibt. Es wäre, sagen wir einmal im Jahr 1993, durchaus performant möglich gewesen, regelmäßig automatisch zu speichern, statt diese Bürde dem Nutzer aufzuerlegen.

Ein implizites, dauerhaftes Speichern hätte für die Nutzer der Computer große Vorteile gehabt, denn explizit speichern zu müssen, ist immer eine große Fehlerquelle. Auch Sie haben es sicher schon erlebt, dass sie längere Zeit an etwas gearbeitet haben, ohne zu speichern, und dann kam es zum Unglück, sei es, dass das Programm abstürzte, der Strom ausfiel, oder Sie die Frage, ob Sie die Änderungen verwerfen oder speichern wollen, versehentlich falsch beantwortet haben. Explizit speichern zu müssen, ist aber nicht nur ein Problem für fahrlässige oder schusselige Computernutzer. Es widerspricht vielmehr auch der Grundidee, die von den Nutzungsschnittstellen vermittelt wird. Die Desktop-Metapher, die es ja bei MacOS seit jeher und bei Windows seit 1995 gab, vermittelt die Illusion, dass ein Dokument, das als Icon vorliegt, in ein Fenster vergrößert und darin bearbeitet werden kann. Die vom System erzeugte Welt sorgt eigentlich dafür, dass der Computernutzer die technischen Operationen wie das Laden von Festplatteninhalten in den Arbeitsspeicher nicht mehr wahrnehmen sollte. Man manipuliert in der Welt der Nutzungsschnittstelle nicht irgendwelche Speicherinhalte, sondern bearbeitet die Elemente eines Dokuments am Bildschirm. Verwendet man aber, wie beim Macintosh des Jahres 1984 Operationen wie „Laden“, „Speichern“ und „Speichern unter“, bricht die Illusion. Nutzer müssen nun den Unterschied zwischen Festplattenspeicher und Arbeitsspeicher kennen, verstehen, dass die Dokumentinhalte vom Festplattenspeicher in den Arbeitsspeicher kopiert werden und von dort wieder auf den Festplattenspeicher zurückgespeichert werden. Dieses Wissen und diese Aktionen haben aber überhaupt nichts mit der dargebotenen Objektwelt zu tun, sondern mit der technischen Funktionsweise dahinter und sollten dem Nutzer eigentlich verborgen bleiben. Leider wurde das explizite Speichern von Betriebssystemgeneration zu Betriebssystemgeneration sowohl am Mac als auch in Microsofts Windows fortkopiert.

Nach 27 Jahren änderte Apple bei seinem Betriebssystem nun diese grundlegende Arbeitsweise. Ein geöffnetes Dokument wurde nun fortlaufend gespeichert. Ein explizites Speichern war nicht mehr nötig. Man öffnete eine Datei, bearbeitete sie und schloss sie wieder. Es wurde stets automatisch und ohne Nutzerinteraktion gespeichert. Das neue Paradigma war eigentlich eine viel konsequentere Umsetzung der Objektwelt einer dokumentbasierten Nutzungsschnittstelle. Die Änderung dieser doch sehr grundlegenden Funktion brachte aber ihre Probleme mit sich. Zum einen arbeiteten nicht alle Programme nach dem neuen Paradigma. Die Mac-Versionen von Microsoft Office und LibreOffice funktionieren zum Beispiel bis zum heutigen Tage (2021) auf die alte Art und Weise. Ein noch größeres Problem entstand aber vor allem durch die über Jahrzehnte erlernten Abläufe, die nun zu einem Datenverlust führen konnten. Ein Beispiel macht das klar: Sie haben vor, einen Brief zu schreiben. Um sich ein bisschen Arbeit zu erleichtern, tun Sie dies, indem Sie einen vorhandenen Brief überarbeiten und unter einem neuen Namen ablegen. Fast dreißig Jahre lang ging das, indem Sie den alten Brief in der Textverarbeitung öffneten, die notwendigen Anpassungen vornahmen und den Text dann per „Speichern unter“ als neue Datei abspeicherten. Wenn Sie das nun bei einem Programm machen, das Apples neues Speicher-Paradigma verwendet, ändern Sie fortwährend den ursprünglichen Brief, dessen Inhalt dann verloren geht und ein „Speichern unter“ finden Sie gar nicht mehr²². Die fortan richtige Abfolge der Handlungen ist nun wieder die Gleiche wie schon beim Xerox Star. Der ursprüngliche Brief wird zunächst dupliziert, das Duplikat umbenannt und dann zwecks Anpassung geöffnet. Apple ist die Problematik der versehentlichen Überarbeitungen durchaus aufgefallen. Glücklicherweise führte Apple zur gleichen Zeit eine Dateiversionierung ein, mit der die versehentlich geänderte Version des ursprünglichen Briefes wieder hervorgebracht werden kann. Viele versehentliche Überschreibungen wurden zudem dadurch verhindert, dass das System Dateien, die seit Längerem nicht geändert wurden, automatisch mit einem speziellen Schreibschutz versieht. Öffnet man sie und versucht, die Dateiinhalte zu ändern, wird man vor die Auswahl gestellt, die Datei zu entsperren oder zu duplizieren und das Duplikat zu bearbeiten.

Mit der Überarbeitung der Speichern-Funktion sorgte Apple für einige Probleme bei den Nutzern seiner Betriebssysteme, obwohl die Entwickler mit der Umstellung auf implizites Speichern die Macintosh-Anwendungen eigentlich nur der Arbeitsweise anpassten, mit der Anwendungen auf iPhones und iPads schon seit jeher arbeiteten. In Apples iOS, in Googles Android und auch vorher schon bei den PDAs gab es das explizite Speichern und mit ihm die Notwendigkeit, sich mit dessen technischen Hintergründen auseinander zu setzen, noch nie, und kaum jemand vermisst sie hier auch, denn bei iOS und Android war immer klar, dass man in einer App ein Objekt bearbeitet. Die Denkweise, dass man mit einem Programm eine Datei in einen unsichtbaren Arbeitsspeicher lädt, war nie Teil dieser Nutzungsschnittstellen-Welt.

Windows 8 – Das gescheiterte Experiment

Die Umstellung der Dateispeicherung bei MacOS war sicherlich eine Änderung, die die Art und Weise, wie über die Nutzungsschnittstelle und ihre Objekte nachgedacht werden musste, änderte. Das war jedoch nichts gegen die Änderungen, die Microsoft 2012 wagte. Der Umbau vom vorherigen Windows 7 zu Windows 8 wirkte noch drastischer als der von Windows 3 zu Windows 95, und im Gegensatz zu diesem war er ein ziemlicher Reinfall.

Windows 8 schaffte das zentrale Element der Nutzungsschnittstelle, das dem ganzen System den Namen gibt, nämlich die Fenster, großteils ab. Auch Desktop und Taskleiste waren nun nicht mehr so zentral wie in den letzten siebzehn Jahren. Das Startmenü wurde sogar ganz abgeschafft. An der Stelle all dieser Konzepte übernahm Microsoft die Nutzungsschnittstelle, die für das Telefon-Betriebssystem Windows Phone und für die Spielekonsole Xbox entwickelt wurde. Statt mit Fenstern, Desktop und Startmenü präsentierte sich das System nun mit großen farbigen Kacheln, die allerlei Informationen anzeigen konnten. Die Nachrichten-App konnte etwa die neusten Schlagzeilen, die Mail-App die Betreffs der neusten Nachrichten und die Kalender-App die anstehenden Termine direkt anzeigen. Tippte man auf eine Kachel oder klickte sie an, öffnete sich die entsprechende Anwendung. Eines der Ziele von Windows 8 war es, alle Systeme des Herstellers mit der gleichen Nutzungsschnittstelle auszurüsten, vom Telefon über Tablets, Laptops, Spielekonsolen bis zum klassischen PC auf dem Schreibtisch. Das Resultat war, dass faktisch eine an Touch-Bedienung auf kleinen Geräten angepasste Nutzungsschnittstelle zum Standard für alle Zielsysteme erklärt wurde. Der Bruch war radikal.

Die Anwendungen von Windows 8, zumindest die, die für das System neu entwickelt wurden, sahen anders aus als bisherige Windows-Anwendungen und wurden auch anders bedient. Windows hatte, anders als es der Name nahelegt, keine Fenster mehr. Programme hatten von nun an auch keine Titelzeile und kein sichtbares, zentrales Menü mehr. Bisher zentrale Elemente der Nutzungsschnittstelle waren nicht mehr sichtbar. Die Standardmenüs einer Anwendung erschienen erst, wenn sie per Touch-Geste „hineingeslided“ wurden oder wenn innerhalb der Anwendung die rechte Maustaste geklickt wurde. Sie erschienen auch nicht mehr in Form einer Menüleiste, sondern als ein breiter Balken am rechten Bildschirmrand. Noch mehr als die Menüs war die Nutzungsschnittstelle zum Beenden von Programmen regelrecht versteckt. Es gab keinen sichtbaren Hinweis mehr darauf, wie man ein Programm beenden konnte. Der etablierte X-Button existierte nicht mehr. Stattdessen musste man das Programm im oberen Bildschirmbereich anklicken und dann nach unten ziehen. Ich spare mir an dieser Stelle die Erläuterung, auf welche Art und Weise fortan zwischen Programmen gewechselt, das Pendant zur Taskleiste eingeblendet oder das System heruntergefahren werden konnte. Sie können sich vorstellen, dass all dies ähnlich kompliziert wurde. Das Problem war weniger, dass es nicht mehr auf die gewohnten Arten und Weisen funktionierte. Der Übergang von Windows 3.11 zu Windows 95 zeigte, dass man sich hier durchaus zügig umgewöhnen kann. Wirklich problematisch war vielmehr, dass es keine am Bildschirm sichtbaren Hinweise mehr darauf gab, welche Operationen möglich waren, oder dass sie überhaupt angeboten wurden.

Ganz verschwunden war der Desktop unter Windows 8 nicht. Viele Nutzer, die die Windows-Version in der Praxis genutzt haben, werden ihn wahrscheinlich sogar nahezu ständig gesehen haben, denn immer wenn man eine klassische Windows-Anwendung verwendete, und dazu gehörten auch Microsoft Office und der beliebte Firefox-Browser, wechselte Windows 8 zum Desktop, der wie immer mit einem Arbeitsplatz-Icon und einer Taskleiste ausgestattet war, die auch die unter Windows 7 eingeführte Schnellstart-Funktion für Programme beinhaltete. Es gab allerdings keinen Start-Knopf und kein Startmenü mehr. Befand man sich auf dem Desktop, funktionierte Windows fast wie immer. Anwendungen erschienen in Fenstern und hatten die typischen Kontrollfelder zum Minimieren, Maximieren und Schließen. Allerdings funktionierten nur die klassischen Windows-Anwendungen so. Startete man eine moderne, neue Anwendung, was auch vom Desktop aus grundsätzlich möglich war, wechselte man wieder in den Vollbildmodus. Windows 8 fühlte sich daher an, als würde man zwei Betriebssysteme gleichzeitig verwenden. Auf der einen Seite eines mit Desktop, Fenstern und Taskleiste, auf der anderen Seite eines mit Kacheln, Anwendungen im Vollbildmodus und mit viel Gesten-Interaktion. Das System bediente sich in einem Moment so und im nächsten Moment ganz anders. Das Gefühl der „Zweigeteiltheit“ wurde noch dadurch verstärkt, dass die beiden Teile kaum miteinander verbunden wurden. Der neue Task-Switcher von Windows 8 zeigte zum Beispiel zwar auch die im Desktop laufenden Anwendungen an und erlaubte es, hierhin umzuschalten, die Taskleiste der Desktop-Oberfläche jedoch ignorierte die modernen Anwendungen vollständig und zeigte nur die klassischen Windows-Anwendungen an.

Windows 8 war ein Fiasko! Der Versuch, die Nutzungswelten des klassischen Windows mit denen von Smartphones und Tablets zusammenzuführen, resultierte mehr in einem absurden Spagat als in einer wirklichen Integration. Microsoft legte im Jahr 2013 Windows 8.1 nach, das einige der ärgerlichsten Änderungen von Windows 8 wieder ausglich. Man konnte nun zum Beispiel einstellen, dass das System gleich nach dem Start den Desktop anzeigte und das Wiedereinführen des Start-Buttons in der Taskleiste erlaubte den Nutzern von Desktop-Rechnern und Laptops nun wieder, mit der Maus oder dem Trackpad auf einfache Art und Weise zur Anwendungsübersicht zu gelangen. Die Änderungen nutzten Microsoft aber nichts mehr. Windows 8 und 8.1 wurden von Firmen nahezu komplett ignoriert und auch von Privatanwendern wenig verwendet. Windows 7 blieb de facto bis zur Einführung von Windows 10 das aktuellste genutzte Windows-Betriebssystem. Ein Windows mit der Versionsnummer 9 gab es nie. Wohl auch, um die Abkehr vom ungeliebten Windows 8 darzustellen, sprang Microsoft 2015 von Version 8 gleich zu Windows 10.

Auch Windows 10 sollte sowohl für klassische Desktop-Rechner und Laptops genauso gut funktionieren wie für Tablets und Telefone. Dieses Mal ging Microsoft es aber geschickter an. Statt wie bei Windows 8 eine einzige Nutzungsschnittstelle für beide Interaktionsarten vorzusehen, gab es nun zwei Modi: Im Desktop-Modus ist die Nutzungsschnittstelle sehr ähnlich wie die von Windows 7. Die Kacheln wurden ins Startmenü verbannt, das mit dieser Windows-Version wieder eingeführt wurde. Alle Anwendungen, ob modern oder klassisch, erschienen wieder in Fenstern und hatten normale Fenster-Controls zum Minimieren, Maximieren oder Schließen. Verwendet man Windows hingegen im Tablet-Modus, verhält es sich ganz anders: Das zentrale Nutzungsschnittstellen-Element ist dann der Kachel-Bildschirm, der allerdings weniger bunt ausfällt, als unter Windows 8. Alle Anwendungen, egal, ob modern oder klassisch, erscheinen im Tablet-Modus im Vollbild, allerdings blieben die Fenster-Controls erhalten. Programme lassen sich also per Klick auf das X in der rechten oberen Ecke schließen. Nicht nur das System als Ganzes passt sich dem Eingabe-Modus an, auch die für Windows 10 optimierten Anwendungen können den aktuellen Modus erkennen und im Tablet-Modus eine touch-optimierte Nutzungsschnittstelle verwenden. Im Explorer etwa wird im Tablet-Modus mehr Platz zwischen den Dateien in Listenform gelassen, um zu verhindern, dass man versehentlich auf die falsche Datei tippt.

Fazit

Die verbleibenden beiden großen grafischen Nutzungsschnittstellen von Apple und Microsoft haben sich, vom Ausreißer Windows 8 abgesehen, im Laufe der Jahre stark angeglichen. Es gibt Unterschiede in manchem Detail, aber im Großen und Ganzen sehen sich die Nutzer der Systeme sehr ähnlichen Objektwelten ausgesetzt, die auf sehr ähnliche Arten und Weisen manipuliert und verwaltet werden können. Betrachtet man den obigen Abriss nochmal im Rückblick, sieht man weniger Revolution als viele kleine Evolutionsschritte, die im Laufe der Jahre zu Nutzungsschnittstellen führten, die es immer weniger notwendig machten, sich mit den technischen Details der Computersysteme zu beschäftigen. Gestartet waren die beiden Betriebssysteme aber mit ganz unterschiedlichen Konzepten.

Unter DOS musste man, wie in jedem mir bekannten kommandozeilenorientierten Betriebssystem, das Programm, mit dem man eine Datei bearbeiten wollte, explizit starten. In der Nutzungsschnittstellen-Welt von Lisa und Star hingegen stand das Dokument an zentraler Stelle. Das direkte Starten von Anwendungen war gar nicht möglich. Diese unterschiedlichen Fokussierungen in der Arbeitsweise findet man noch immer, wenn man sich die Windows- und MacOS-Versionen von Anfang der 1990er ansieht. Unter Windows 3 war der Programm-Manager die zentrale Schaltstelle des Betriebssystems. Folglich nutzte man das System eher, indem man ein Programm startete, als dass man ein Dokument direkt öffnete. Dies war im Dateimanager zwar grundsätzlich möglich, aber recht unüblich. Unter MacOS hingegen gab es keine zentrale Verwaltung von Programmen. Programme konnten aus dem Finder heraus explizit gestartet werden. Das war hier aber eher unüblich. Eher navigierte man mit dem Finder eine Datei an, die man bearbeiten wollte und öffnete sie direkt. Mit Windows 95 und Mac OS 10 schafften es beide Betriebssystemhersteller, die beiden Denk- und Arbeitsweisen zu vereinheitlichen. Startmenü, Taskleiste und Dock bieten Direktzugriff auf die Anwendungen, während Finder und Explorer so zentral im System sind, dass eine dokumentzentrierte Arbeitsweise nach wie vor möglich und üblich ist.

In den aktuellsten Versionen der Systeme kann man übrigens einen neuen Trend ausmachen, den man verkürzt als „Abschaffung der Dateien“ bezeichnen könnte und der sicherlich durch die Beliebtheit der Mobilbetriebssysteme iOS und Android befördert wird. Es gibt immer mehr Anwendungen, die Objekte darstellen und verwalten können, die nicht mehr direkt als Dateien in Erscheinung treten. Die Apple-Anwendungen iTunes und Fotos (früher iPhoto) und plattformübergreifend die Notizbuch-Software Evernote sind gute Beispiele für diese neue Art von Software. In den Anwendungen können Musikstücke, Videos, Fotos und Textnotizen verwaltet bzw. bearbeitet werden. Diese Objekte liegen zwar als Dateien auf der Festplatte des Rechners, sind aber im Regelfall nicht mehr direkt zugänglich, denn die Anwendungen selbst kümmern sich um alle Verwaltungsoperationen. Mit dieser Entwicklung ist, wie wohl mit jeder Entwicklung in der Nutzungsschnittstelle, nicht jeder einverstanden. Dem Nutzer wird ein Teil der Flexibilität, die die freie Dateiverwaltung bietet, genommen. Im Gegenzug dazu ist die Nutzung des Computers einfacher und weniger technisch, denn man betrachtet und bearbeitet nun Fotos, Videos, Textdokumente oder Notizen statt generischer Dateiobjekte. Die einen reden hier vom sogenannten „Goldenen Käfig“ und beklagen die Einschränkungen, manch anderer wird durch solche Vereinfachungen erst in die Lage versetzt, die Computer überhaupt zu nutzen. Ich habe meine Meinung dazu, verrate Sie Ihnen aber nicht, denn ein richtiges Wahr und Falsch gibt es an dieser Stelle sicher nicht.

Unix und Linux

In meinen bisherigen Darstellungen der Entwicklung von Nutzungsschnittstellen habe ich das Betriebssystem Unix zwar dann und wann erwähnt, aber im Großen und Ganzen ignoriert. Tatsächlich hatte ich ursprünglich vor, es auch dabei zu belassen, denn Unix kam zum einen als Vertreter der textbasierten Time-Sharing-Betriebssysteme relativ spät auf den Markt und ist zum anderen, was die grafischen Nutzungsschnittstellen angeht, zumindest im Bereich der PC-Betriebssysteme nicht verbreitet. Man findet es wohl sehr oft auf Rechnern, die nicht direkt von Endnutzern verwendet werden, sondern Dienste im Hintergrund bereitstellen. Solche Rechner nennt man im Allgemeinen „Server“. Nahezu alle Websites, die Sie heute aufrufen können, laufen unter einem unix-artigen Betriebssystem, doch kann das dem Nutzer des Computers, auf dem der Webbrowser läuft, letztlich egal sein. Im Laufe der Recherche für viele der anderen Kapitel dieses Buches habe ich dann entschieden, dass es doch ein eigenes Unix-Kapitel braucht, denn das Betriebssystem hatte zum einen starken Einfluss auf andere Betriebssysteme und zum anderen werden im Unix-Bereich Nutzungsschnittstellen entwickelt, die zwar wenig genutzt werden, die aber dennoch teils so interessante Eigenschaften haben, dass man sie nicht einfach unter den Tisch fallen lassen sollte.

Von Multics zu Unics – Die Frühgeschichte

Lassen Sie mich mit der Geschichte von Unix etwa fünf Jahre vor dem Zeitpunkt beginnen, an dem das System das erste Mal in Erscheinung getreten ist, denn die Vorgeschichte des Systems erklärt manche der typischen Unix-Eigenheiten. Nachdem wir im vorherigen Kapitel schon in der Gegenwart angekommen sind, machen wir also einen Sprung weit zurück ins Jahr 1964, etwa zehn Jahre vor dem Aufkommen der ersten Personal Computer, in die Zeit, in der im großen Stile an der Time-Sharing-Technik entwickelt und geforscht wurde. In diesem Jahr 1964 begannen das Massachusetts Institute of Technology (MIT), die Firma General Electric (GE), damals ein Hersteller von Computern, und die Bell Labs mit der Entwicklung eines komplexen Time-Sharing-Systems. Wichtig für die Geschichte von Unix ist hier vor allem die Beteiligung des Forschungslabors Bell Labs. Diese Einrichtung war Teil des damaligen amerikanischen Telefon-Monopolisten AT&T, ein Fakt, der für die weitere Geschichte noch wichtig werden sollte.

MIT, GE und Bell Labs begannen im Jahr 1964 mit der Entwicklung eines Time-Sharing-Betriebssystems namens Multiplexed Information and Computer Service, kurz Multics. Das Betriebssystem war für die damalige Zeit extrem modern und mit Eigenschaften ausgestattet, die gerade im Einsatz in einer großen Rechenanlage mit vielen zugreifenden Nutzern sehr sinnvoll waren. Hierzu gehörte zum Beispiel die Verwaltung von Massenspeichern wie Festplatten, Magnetbändern oder Wechselplatten. Das System hatte in Sachen Datenträgerverwaltung interessante Konzepte. Heutige PC-Betriebssysteme wie Windows oder MacOS verwalten Datenträger in den meisten Fällen als unabhängige Einheiten. Wenn Sie etwa eine externe Festplatte oder einen USB-Stick an den Rechner anschließen, erscheint ein neuer Datenträger im System. Sie können nun darauf zugreifen und etwa Dateien herauf- oder herunterkopieren. Die Organisation, was auf welchem Datenträger gespeichert ist, müssen Sie aber selbst durchführen. Ist Ihnen die Festplatte in Ihrem Rechner zu klein und Sie bauen eine weitere ein, müssen Sie sich selbst darum kümmern, welche Dateien Sie auf welcher Festplatte abspeichern. Bei Multics war das anders: Dort vergrößerte eine neue, angeschlossene Festplatte oder ein eingelegtes Band die Menge des zur Verfügung stehenden Massenspeichers. Das System schichtete die gespeicherten Dateien automatisch so um, dass sich die häufig genutzten Dateien auf einem schnelleren Speichermedium befanden, etwa einer schnellen Festplatte, während die weniger genutzten auf langsame Medien wie Wechselplatten oder Magnetbänder umgelagert wurden. Diese Platten und Bänder mussten nicht dauerhaft vorgehalten werden. Operatoren im Rechenzentrum konnten Platten und andere Medien nahezu beliebig hinzufügen und entfernen. Würden Sie das bei einem heutigen System machen, würden im Normalfall Dateien und Verzeichnisse verschwinden oder wie von Geisterhand erscheinen. Das Dateisystem von Multics machte diese technische Realität der Speichermedien jedoch für den Nutzer vollständig unsichtbar. Nehmen wir einmal an, ein Nutzer hatte Monate zuvor eine Datei angelegt, diese aber seitdem nicht wiederverwendet. Zwischenzeitlich wurde sie vom System auf ein Magnetband umkopiert und archiviert. Wollte unser Nutzer nun auf diese Datei erneut zugreifen, war das kein Problem. Sie wurde ihm nach wie vor als vorhanden angezeigt. Sollte sie nun geladen oder ausgegeben werden, ging das nicht sofort. Der Benutzer wurde zunächst mit einer Systemmeldung vertröstet, während dem Operator im Rechenzentrum angezeigt wurde, dass er ein bestimmtes Magnetband einlegen sollte. Sobald er das tat, stand die Datei wieder zur Verfügung und wurde gegebenenfalls automatisch wieder auf ein schnelleres Speichermedium verschoben. Niemand musste händisch die Datei vom Magnetband auf eine Arbeitsfestplatte kopieren oder ähnliches. Diese Aufgabe wurde vollständig vom System selbst übernommen.

Das Multics-System war groß und komplex und verfügte über viele Funktionen für große Time-Sharing-Rechenanlagen, von der gerade beschriebenen Datenträgerverwaltung bis hin zu einer ausgefeilten Nutzerverwaltung. Die Weiterentwicklung zog sich hin, was nicht allen am Projekt Beteiligten zusagte. Im Jahre 1969 zogen sich die Bell Labs daher aus dem Projekt zurück. Dies setzte einerseits Ressourcen frei, führte aber andererseits zum Problem, dass für die eigenen Computer nun andere Betriebssysteme gefunden oder entwickelt werden mussten. Ken Thompson und Dennis Ritchie, zwei Techniker bei Bell Labs begannen daher, einfach aus der Notwendigkeit heraus, mit der Entwicklung eines eigenen, kleineren Betriebssystems für die am Bell Labs eingesetzten Minicomputer PDP-7 und später PDP-11/20 von DEC. Im Jahre 1970²³ wurde das System als Verballhornung von Multics zunächst Unics (Uniplexed Information and Computer Service) getauft. Der Name wurde später in „Unix“ geändert, wobei heute nicht mehr genau zu klären ist, wann die Umbenennung stattfand und wer dafür verantwortlich war. Die frühen Unix-Versionen wurden in der maschinennahen Assembler-Programmiersprache für die PDP-7 und die PDP-11 geschrieben, liefen also auch nur auf diesen Computern. Ab 1973 änderte sich das, denn große Teile des Systems wurden in der von Dennis Ritchie entwickelten Programmiersprache C, die auch heute noch weithin genutzt wird, neu geschrieben. Dieser Schritt erhöhte nicht nur die Wartbarkeit des Betriebssystems von Seiten der Entwickler, sondern erlaubte später auch die Portierung des Systems auf andere Hardware-Architekturen.

Jedem sein Unix – Die Zersplitterung

Das neue Betriebssystem Unix wurde zunächst nur innerhalb von AT&T verwendet und entwickelt. Das System wuchs dabei in Funktionalität und Komplexität natürlich an, von einem einfachen Single-Tasking-Betriebssystem noch auf der PDP-7 zu einem Multi-User-Multi-Tasking-Betriebssystem, das es auch noch heute ist. Der Entwickler Bell Labs war, wie bereits angedeutet, Teil des damaligen Telefonmonopolisten AT&T. Eine der Bedingungen dafür, dass AT&T sein Monopol haben durfte, war, dass sich der Konzern auf Telefondienstleistungen und Kommunikation beschränkte und mit seinem Angebot nicht etwa auch in verwandte Wirtschaftsbereiche ausuferte. Der Verkauf von Computern und Betriebssystemen war damit für die Firma ein Tabu. Natürlich konnte niemand AT&T verbieten, für interne Zwecke ein Betriebssystem zu entwickeln. Lediglich verkaufen durfte AT&T ein solches System nicht. Was allerdings erlaubt war, und auch intensiv betrieben wurde, war die Lizensierung des Systems an Interessenten. Computerhersteller, die ein Betriebssystem suchten, konnten bei AT&T eine Lizenz erwerben und erhielten damit Zugriff auf den Programmcode des Systems, den sie relativ frei verwenden und für ihre Belange anpassen konnten. Besonders attraktiv war diese Lizenzierung für Bildungseinrichtungen und Universitäten, die für die Lizenz nur einmalig 200 Dollar bezahlen mussten. Einer dieser Lizenznehmer war die University of Berkeley. Informatiker und Studierende der Universität passten das System von AT&T für ihre Forschungszwecke an, erweiterten die Netzwerkfunktionalitäten und verbesserten die Performanz. Das daraus entstehende System wurde BSD (Berkeley Software Distribution) genannt. Nachfolger dieses Systems sind in der Form von FreeBSD und NetBSD noch heute verbreitet.

Dass Lizenznehmer von Unix das System ihren eigenen Bedürfnissen anpassen konnten, führte dazu, dass es kein einheitliches Unix mehr gab. Es gab das UNIX von AT&T, das in der Regel in Großbuchstaben geschrieben wurde. Daneben gab es viele andere Unixe, etwa das BSD der University of Berkeley, SunOS von Sun Microsystems, Xenix von Microsoft, AIX von IBM und viele andere mehr. All diese Systeme waren irgendwie jeweils Unix, aber sie waren doch verschieden. Das war natürlich einerseits der Charme des Projektes, denn jedes Unix war für seinen Einsatzzweck optimiert, andererseits brachte diese Zersplitterung die Gefahr, dass ein absolutes Chaos entsteht. Um ebendieses zu vermeiden, wurde ab 1985 eine Standardisierung angestrebt, die heute unter dem Begriff „POSIX-Standard“ bekannt ist. Der Standard beschreibt eine Art Mindestanforderung für Unix-Systeme, die bei allen Derivaten gleich sein soll.

Das Telefonmonopol von AT&T wurde in den 1980er Jahren zerschlagen. Ab dem Jahr 1984 durfte das an den Bell Labs entwickelte System daher auch als Produkt verkauft werden. AT&T verschärfte fortan die Lizenzpolitik. Neue Versionen des UNIX von AT&T konnten nicht mehr so günstig lizenziert und angepasst werden. Dieser Schritt sorgte natürlich für Gegenreaktionen. Unix war an Universitäten weit verbreitet und dort wegen seiner Flexibilität sehr geschätzt. Die University of Berkeley mit ihrem wichtigen Unix-Derivat BSD schrieb alle vorhandenen AT&T-Teile aus ihrem System heraus und ersetzte sie durch funktionsgleichen, also zum POSIX-Standard kompatiblen, eigenen Code. Ab 1991 stand BSD dann AT&T-frei unter einer Open-Source-Lizenz zur Verfügung. „Open Source“ bedeutet, sehr einfach formuliert, dass jeder sich den Quellcode beschaffen und nach Lust und Laune für eigene Projekte anpassen kann, ohne Lizenzgebühren bezahlen zu müssen. Nach diesem Prinzip funktioniert heute sehr viel Software, etwa der Browser Firefox, die Grundlage des Browsers Chrome und die Office-Programme LibreOffice und OpenOffice.

Die quelloffenen BSD-Versionen von 1989 und 1991 waren nicht der erste Versuch, ein Unix ohne AT&T-Abhängigkeit zu erzeugen. Bereits 1983 startete Richard Stallman eigens zu diesem Zweck das GNU-Projekt. Das Ziel Stallmans war freie Software²⁴ – und hier im Speziellen ein UNIX-kompatibles Betriebssystem ohne eine einzige Zeile des Original UNIX-Codes von AT&T. Die Abkürzung GNU steht daher auch vielsagend für „GNU is Not UNIX!“. GNU als Komplett-Betriebssystem ist bis heute noch nicht fertig. Aus dem Projekt hervorgegangen sind aber eine ganze Menge wichtiger Tools und Programmpakete, darunter der Kommandozeilen-Interpreter „bash“, der weit verbreitet ist und in vielen Unixen und darüber hinaus genutzt wird. Die ganze Palette der GNU-Software-Werkzeuge bildete zusammen mit einem von Linus Torwalds Anfang der 1990er Jahre entwickelten Open-Source-Betriebssystemkern vor allem aber die Grundlage für das Betriebssystem Linux²⁵.

Linux steht somit in der Unix-Tradition, aber ist Linux damit auch ein Unix? Man kann die Frage nur mit einer Gegenfrage beantworten: Ist BSD ein Unix, obwohl explizit alle Programmcodes von AT&T entfernt wurden? Woran will man das festmachen? Eine Möglichkeit wäre der oben genannte POSIX-Standard, denn der beschreibt unix-artige (oder auch „unixoide“) Betriebssysteme. Bezeichnet man alle Betriebssysteme, die diesen Standard vollständig oder zumindest großteils erfüllen, als Unix, müsste man, wenn man die aktuellen Varianten von BSD (FreeBSD, OpenBSD) als ein Unix bezeichnet, auch Linux als ein Unix ansehen. In der Praxis wird das jedoch oft nicht gemacht. Ganz im Gegenteil: Wenn Sie eine Linux-Distribution nutzen und diese als Unix bezeichnen, werden Sie viele Informatiker zurechtweisen. Wir haben hier einmal wieder so einen Streit, den ich an dieser Stelle nicht auflösen kann, nicht auflösen will und glücklicherweise auch nicht auflösen muss, denn ich habe mir ja die Nutzungsschnittstellen-Brille ausgesucht, um die Computergeschichte zu beschreiben und aus dieser Perspektive gibt es keinen nennenswerten Unterschied zwischen einem FreeBSD, also einem Unix, und einem Linux. Ein kommandozeilenorientiertes BSD und ein kommandozeilenorientiertes Linux können Sie kaum unterscheiden und das Gleiche gilt für Unixe oder Linuxe mit den grafischen Nutzungsschnittstellen wie KDE oder Gnome. Sie sehen sehr ähnlich aus, verhalten sich ähnlich und sind daher, zumindest aus meiner Sicht, auch ähnlich genug, um sie beide unter „Unix“ zusammenzufassen.

Die Macht der Kommandozeile – Die Unix-Shell

Ich habe Ihnen nun viel über die Geschichte des Systems erzählt, aber noch kein Wort darüber verloren, wie sich Unix in der Nutzung darstellt. Beginnen wir mit dem Grundkonzept, den wichtigsten Objektarten, mit denen ein Unix-Nutzer umgehen muss. Unix ist an dieser Stelle sehr einfach. Die wichtigsten Objekte sind Dateien und Verzeichnisse bzw. Unterverzeichnisse. Heute wird ein Unterverzeichnis gerne als „Ordner“ bezeichnet. Das ist für Unix aber eigentlich anachronistisch, denn dieser Ausdruck entstammt dem Begriffsrepertoire der grafischen Nutzungsschnittstellen der 1980er Jahre. Im Jahre 1970 stellten sich die meisten Computernutzer ihr Dateisystem noch nicht als Analogie zu Büros mit Dokumenten und Ordnern vor. Sie sahen viel eher Dateien, die in einem Index aufgelistet wurden. Dieser Index wurde „Verzeichnis“ oder, auf Englisch, „Directory“ genannt. Unix ist ein Betriebssystem, das um das Dateisystem herum entwickelt wurde. Das Grundkonzept der Unix-Dateiablage, eine hierarchische Verzeichnisstruktur, wurde von Multics übernommen. „Hierarchisch“ bedeutet, dass ein Verzeichnis nicht nur Dateien, sondern auch seinerseits Verzeichnisse beinhalten kann. In einem solchen Dateisystem kann jede Datei durch die Angabe eines Pfades identifiziert werden. Dieser beginnt an einer allgemeinen Wurzel und folgt dann den Unterverzeichnissen bis zur Datei. Ein / wird als Trennzeichen verwendet. Ein typischer Unix-Pfad ist etwa /home/User/texts/history.txt.

Die Interaktion mit dem Unix-Betriebssystem erfolgt klassischerweise mit einem Kommandozeilen-Interpreter. Im Unix-Bereich wird dieser meist „Shell“ genannt. Nutzer der Shell befinden sich zu einem Zeitpunkt immer in einem bestimmten Pfad der Dateisystem-Hierarchie und können diese Position mit Hilfe des Befehls cd ändern. cd dirname wechselt etwa ins Unterverzeichnis dirname. Die Zeichenfolge .. steht für das übergeordnete Verzeichnis, auch Elternverzeichnis genannt. cd .. wechselt also in das Verzeichnis, das das Verzeichnis enthält, in dem man sich gerade befindet. Dieses Konzept, inklusive des Befehls cd und des Parameters .. für das Elternverzeichnis wurde auch in andere Betriebssysteme übernommen. Microsoft portierte sie schon 1983 in die zweite Version seines DOS. Lediglich das Trennzeichen im Pfad drehte Microsoft um und verwendete den Rückschrägstrich, meist „Backslash“ genannt. In einer aktuellen Eingabeaufforderung von Windows können Sie sowohl \ als auch / als Trennzeichen verwenden.

In der Nutzungswelt von Unix erscheint eigentlich alles als Datei. Selbst an den Computer angeschlossene Geräte werden als Datei dargestellt und haben dementsprechend einen Pfad im Dateisystem. Das hat für den modernen Nutzer eigentümliche Konsequenzen. Man kann zum Beispiel eine Datei auf einem angeschlossenen Drucker ausdrucken lassen, indem man sie auf den Drucker kopiert. Der Befehl dafür lautete zum Beispiel cp ./test.txt /dev/lp0. Mit einem ähnlichen Befehl kann man die Datei aber auch an die Soundkarte schicken oder auf dem Bildschirm eines anderen angemeldeten Nutzers ausgeben, denn all diese Ressourcen stehen genauso als Dateien, also über einen Dateipfad, zur Verfügung.

Unix ist sehr modular aufgebaut. Nahezu jede Komponente kann durch eine andere ersetzt werden. Es gibt zum Beispiel nicht den einen Kommandozeilen-Interpreter, sondern mehrere Alternativen, die eingesetzt werden können. Sehr verbreitet ist heute zum Beispiel die bash aus dem GNU-Repertoire. Auch die zur Verfügung stehenden Befehle können ausgetauscht und erweitert werden, denn sie sind, von wenigen Ausnahmen abgesehen, nicht wie bei MS-DOS in den Kommandozeilen-Interpreter eingebaut, sondern liegen als kleine ausführbare Programme vor. Über alle Unix-Derivate hinweg, so unterschiedlich sie auch sein mögen, gibt es aber einen typischen Satz an kleinen Tools und Shell-Befehlen. Dazu gehören etwa:

• ls zur Ausgabe einer Liste der Einträge in einem Verzeichnis
• cat zur Ausgabe eines Dateiinhalts
• cp zum Kopieren von Dateien
• mv zum Verschieben oder Umbenennen von Dateien
• rm zum Löschen von Dateien
• mkdir zum Erstellen von Verzeichnissen
• cd zum Wechseln in Verzeichnisse

Die meisten dieser Befehle ergeben für sich allein stehend keinen Sinn. cat etwa muss man zumindest noch mitgeben, welche Datei es ist, die man angezeigt haben will und wenn man cp eingibt, muss man zumindest sagen, welche Datei man wohin kopieren möchte. Diese zusätzlichen Angaben werden „Parameter“ genannt. Sehr typisch für Unix-Systeme ist die oft sehr große Zahl möglicher Parameter. Der Befehl ls etwa gibt, für sich allein stehend, alle nicht versteckten Dateien im aktuellen Verzeichnis als einfache Liste aus. Gibt man den Parameter a hinzu, also ls -a, werden auch versteckte Dateien angezeigt. Gibt man hingegen ls -l an, wird eine umfangreichere Liste ausgegeben, die auch Dateigröße, Erstellungsdatum usw. beinhaltet. Will man, dass in dieser Liste auch die versteckten Dateien enthalten sind, kann man beides durch ls -a -l oder auch ls -al kombinieren. Diese beiden Parameter sind bei Weitem nicht die einzig möglichen. Alle Parameter von ls lassen sich im in die meisten Unix-Systeme integrierten Hilfesystem, den sogenannten „man-pages“ nachlesen. Bei einem BSD-Unix steht dort dann zum Beispiel ls [-ABCFGHLOPRSTUW@abcdefghiklmnopqrstuwx1] [file ...]. Jeder Buchstabe steht für einen möglichen Parameter.

Software von verbreiteten Betriebssystemen wie Windows oder auch MS-DOS unterscheidet sich stark von typischer Unix-Software. Eine typische DOS- oder Windows-Anwendung ist interaktiv, verfügt über eine eigene Nutzungsschnittstelle und deckt in der Regel einen großen Funktionsbereich ab. Unter Unix hingegen sind Programme meist recht kleine Werkzeuge, die eine bestimmte Aufgabe ohne weitere Nutzerinteraktion besonders gut machen, jedoch nicht darüber hinaus gehen. Diese kleinen Programme kann man kombinieren, indem man die Ausgabe des einen Programms zur Eingabe des anderen Programms macht. Neben Dateien sind damit auch Datenströme ein Grundkonzept des Betriebssystems. Um diese zu verstehen, hilft es, sich wieder in die Urgeschichte des Computers zurückzuversetzen. Stellen Sie sich jedes kleine Unix-Tool als einen kleinen Computer vor, der mit einem Lochstreifenleser und einem Lochstreifenstanzer ausgestattet ist. Wenn Sie einen solchen Computer nun loslaufen lassen, wird ein Eingabe-Lochstreifen gelesen und dabei ein Ausgabe-Lochstreifen erzeugt. Diesen Ausgabe-Lochstreifen könnten Sie nun einem anderen kleinen Computer mit einem anderen Programm als Eingabe-Lochstreifen geben. Wenn Sie den dann laufen lassen, wird die vorherige Ausgabe als Eingabe aufgefasst und wiederum ein neuer Ausgabe-Lochstreifen erzeugt. Auf genau diese Art und Weise funktionieren im Prinzip die Unix-Tools. Nehmen wir den Befehl cat ./events.log. Dieser Befehl gibt die Datei „events.log“ aus dem aktuellen Verzeichnis aus – in unserem eben angestellten Gedankenspiel erzeugt sie einen Lochstreifen mit dem Inhalt der Datei. Diesen Lochstreifen geben wir nun einem anderen unserer kleinen Computer als Eingabe. Auch zu diesem gehört natürlich ein Befehl, nämlich grep ERROR. Wenn Sie diesen Befehl so für sich eingeben – versuchen Sie es ruhig einmal, wenn sie ein MacOS oder ein Linux zur Verfügung haben –, passiert erst einmal wenig. grep erwartet eine Eingabe, und da Sie keine Eingabe zur Verfügung gestellt haben, erwartet das Tool, dass Sie sie selbst machen. Tippen Sie zum Beispiel „Hallo Welt!“ und drücken Sie die Eingabetaste, passiert, außer dass dieser Text auf dem Bildschirm steht, nichts. Schreiben Sie aber „Dies ist ein ERROR!“ und drücken auf Enter, passiert etwas. Die Zeile steht nun zweimal am Bildschirm. Was grep ERROR nämlich tut, ist, die Zeilen der Eingabe, die das angegebene Wort, also ERROR enthalten, in die Ausgabe zu übernehmen. Alle anderen Zeilen werden verworfen.

Nun haben Sie schon zwei kleine Computer. Der eine erzeugt einen Lochstreifen mit dem Inhalt der Datei „events.log“ und der andere arbeitet als Filter, indem er alle eingegebenen Zeilen, die das Wort „ERROR“ enthalten auf den Ausgabe-Lochstreifen übernimmt und alles andere ignoriert. Nun müssen Sie dem System noch mitteilen, dass der Ausgabe-Lochstreifen des ersten Computers der Eingabe-Lochstreifen des zweiten werden soll. Hierzu dient bei Unix der senkrechte Strich, entsprechend dem Namen der Technik auch „Pipe-Zeichen“ genannt. Mit dem | erzeugen Sie eine Verbindung, eine Pipe, zwischen der Ausgabe eines Tools und der Eingabe des anderen. Das Resultat cat ./events.log|grep ERROR gibt also alle Zeilen aus der Datei „events.log“ aus, die das Wort „ERROR“ enthalten. Mit einer besonderen Art von Pipe können Sie dafür sorgen, dass diese Ausgabe nicht einfach auf dem Bildschirm steht, sondern wieder in eine Datei geschrieben wird. Dies geht mit dem „Größer“-Zeichen gefolgt vom Dateinamen. Der Befehl cat ./events.log|grep ERROR>errors.log erzeugt also eine Datei „errors.log“ mit den ausgefilterten Zeilen der Datei „events.log“.

Mit dem Piping kann man, wenn man es erst einmal verstanden hat, die vielen kleinen Tools von Unix auf geschickte Weise miteinander kombinieren. Manche Aufgaben sind aber komplexer, als dass man sie als einfaches Hintereinander-Ausführen mehrerer Programme bei gleichzeitiger Weitergabe der Ausgabe verstehen könnte. Als Beispiel soll hier einmal das Problem des Umbenennens von Dateien gelten. Erstaunlicherweise ist Unix an dieser Stelle nicht besonders gut ausgestattet. Stellen Sie sich einmal vor, Sie haben einen Ordner voll mit Bilddateien, die „bild001.jpg“, „bild002.jpg“ und so weiter heißen. Sie wollen diese Dateien nun so umbenennen, dass „image001.jpg“, „image002.jpg“ und so weiter herauskommt. Wenn Sie Windows-Nutzer sind und die Eingabeaufforderung verwenden, geht das ganz einfach mit einem einzigen Befehl ren bild*.* image*.*. Unter Unix geht es leider nicht so einfach. Warum das so ist, hängt damit zusammen, wie die Sternchen, die für beliebige weitere Zeichen stehen, aufgelöst werden. Ich spare mir an dieser Stelle eine genaue Erklärung, denn ich nutze das Umbenennen nur als Beispiel und nehme nicht an, dass Sie mein Buch verwenden wollen, um in die Geheimnisse der Unix-Shells tiefer einzusteigen.

Um das Umbenennen auch unter Unix hinzubekommen, kann man sich ein kleines Programm, ein Shell-Script, schreiben. Das könnte zum Beispiel²⁶ wie folgt aussehen. Die hier abgedruckten Zeilennummern dienen nur der folgenden Beschreibung. Sie sind nicht Teil des Shell-Scripts.

 1:  #!/bin/bash
 2:  # renames.sh
 3:  # basic file renamer
 4: 
 5:  criteria=$1
 6:  re_match=$2
 7:  replace=$3
 8:  
 9:  for i in $( ls *$criteria* ); 
10:  do
11:      src=$i
12:      tgt=$(echo $i | sed -e "s/$re_match/$replace/")
13:      mv $src $tgt
14:  done

Gehen wir das Programm kurz durch: Die ersten drei Zeilen sind im Grunde nur Kommentare, die dazu dienen, dass man auf die Schnelle erkennen kann, was dieses Shell-Script macht. Eine besondere Rolle kommt dabei der ersten Zeile zu, denn dort steht, welcher Kommandozeilen-Interpreter dieses Shell-Script ausführen soll. Es handelt sich hier um die schon angesprochene bash-Shell aus dem GNU-Projekt. Die Zeilen 5 bis 7 dienen vor allem der besseren Lesbarkeit des Programms. Hier werden die Parameter, die dem Script mitgegeben werden, in Variablen mit sinnvollen Namen gespeichert. Startet ein Nutzer das Script mit dem Aufruf rename.sh *.jpg bild image, wird an dieser Stelle *.jpg in criteria gespeichert, die Variable re_match erhält den Wert bild und entsprechend findet sich image in der Variablen replace. Das eigentliche Programm beginnt erst in Zeile 9. Betrachten Sie zunächst einmal, was dort innerhalb der Klammer steht. Dort wird der Befehl ls aufgerufen, der, wie Sie inzwischen wissen, für das Ausgeben eines Verzeichnisinhalts verantwortlich ist. Hier im Script wird das Ergebnis aber nicht ausgegeben, sondern in einer Variablen gespeichert. Vor der Klammer steht for i in. Hierbei handelt es sich um eine der typischsten Strukturen eines jeden Computerprogramms, nämlich um eine sogenannte „Schleife“. Alles zwischen do in Zeile 10 und done in Zeile 14 wird nicht nur einmal, sondern mehrfach ausgeführt, und zwar genau so oft, wie das Verzeichnislisting aus der Klammer lang ist. Das Listing wird also Zeile für Zeile durchgegangen. In einer Variablen namens i steht dann jeweils der aktuelle Dateiname. Was innerhalb der Schleife passiert, ist im Grundsatz ganz einfach. In Zeile 11 wird der ursprüngliche Dateiname, also der, der aus dem Listing gerade dran ist, in eine Variable src gespeichert. In Zeile 12 wird bestimmt, wie der neue Dateiname lauten soll. Das Ergebnis wird in der Variablen tgt gespeichert. In Zeile 13 wird nun die Datei unter Zuhilfenahme des Befehls mv umbenannt.

12:      tgt=$(echo $i | sed -e "s/$re_match/$replace/")

Trickreich ist die Zeile 12, denn hier greifen wieder die Unix-Tools ineinander. Schauen wir uns zunächst an, was innerhalb der Klammer passiert. Zunächst steht hier einmal der Befehl echo. Diesen Befehl kann man zum Beispiel dafür benutzen, um in einem Script etwas auf dem Bildschirm auszugeben, denn echo erzeugt genau das: ein Echo. Tippen Sie in einer Linux-Konsole echo Hallo, wird in der Zeile darunter Hallo ausgegeben. Im Script wird hier natürlich nicht Hallo ausgegeben, sondern der Inhalt der Variablen i, also des Dateinamens, der angepasst werden soll. echo schreibt in diesem Fall auch nicht auf den Bildschirm, denn dahinter steht das schon bekannte Pipe-Zeichen. Die Ausgabe wird also zur Eingabe für ein anderes Unix-Tool. Dieses Tool ist der Editor „sed“. „Sed“ steht für „stream editor“. Er funktioniert ähnlich wie der „ed“, den wir in einem früheren Kapitel besprochen haben, kennt im Gegensatz zu diesem aber kein Konzept von Zeilen. Eine Textdatei ist in „sed“ einfach eine lange Folge von Zeichen. Als praktischer Editor ist „sed“ damit ziemlich nutzlos, doch für den Zweck der automatisierten Verarbeitung ist er ideal. „Sed“ bekommt den soeben mit echo ausgegebenen Dateinamen als Eingabe. Nehmen wir einmal an, diese Eingabe sei einbildung.jpg. „Sed“ wurde mit dem Parameter -e gestartet. Hinter diesem befindet sich ein sogenannter „regulärer Ausdruck“. Diese Zeichenfolgen sind Befehle, um in einem Text etwas zu finden und gegebenenfalls auch darin etwas zu verändern. Der hier angegebene Ausdruck sucht nach dem, was in der Variablen re_match steht und ersetzt es durch das, was in replace steht. In unserem Beispiel wird also in einbildung.jpg nach bild gesucht und dieses Vorkommen in image geändert. Im Normalfall würde das Ergebnis einimageung.jpg wieder auf dem Bildschirm landen, aber hier im Shell-Script landet es stattdessen in der Variablen tgt.

Unix ist nicht das einzige Betriebssystem, das Shell-Scripte unterstützt, und auch die Technik des Piping ist nicht auf Unix beschränkt. Microsoft übernahm beide Techniken bereits 1983 für seine zweite Version des DOS. Scripte sind dort unter dem Namen „Batch-File“ oder auch „Batch-Datei“ bekannt. Der Begriff hat nicht besonders viel mit dem Batch-Processing aus der Lochkartenzeit zu tun. Der Name ist in vielen Fällen auch einigermaßen irreführend, denn natürlich kann ein solches Script dafür genutzt werden, um viele Dateien oder Datensätze in einem Rutsch, also als einen Stapel zu bearbeiten. Genau so ein Beispiel haben Sie gerade gesehen. Nicht jedes Shell-Script und schon gar nicht jede Batch-Datei von DOS oder Windows erfüllt aber diese Eigenschaft. Oft handelte es sich einfach nur um fünf Befehle, die hintereinander ausgeführt werden sollten, und deren ewige Wiederholung eingespart werden sollte oder es handelte sich, gerade bei DOS, um einfache Menüstrukturen, die sich viele Nutzer bastelten, um schnell die Programme ihrer Wahl starten zu können, ohne Befehle auf der Kommandozeile eingeben zu müssen.

Piping und Shell-Scripting ist unter Unix aufgrund der vielen kleinen Tools sehr mächtig. In Systemen wie DOS oder der Windows-Eingabeaufforderung sind ähnliche Techniken zwar möglich, aber bei Weitem nicht so verbreitet und so oft eingesetzt. Unix ist mit seiner Shell ein sehr leistungsfähiges Betriebssystem. Die Nutzungsschnittstellen-Welt von Unix ist aber ganz anders als die, die Nutzer aktueller Betriebssysteme meist gebrauchen. Es herrscht nach wie vor ein fernschreiberartiger Terminal-Stil. Die einzig wirklich interaktiven Programme, die man bei einem klassischen Unix braucht, sind die Shell selbst und ein Editor. Außer diesem Editor braucht es in der Unix-Welt im Prinzip keine Software, die die Räumlichkeit des Bildschirms ausnutzen würde. Zwar sind in der Unix-Welt Dateien die zentralen Objekte der Interaktion, es ist aber für das Piping auch eine datenstromorientierte Denkweise notwendig. Gerade diese Denkweise, die ich Ihnen oben durch die Metaphorik mit den vielen kleinen Computern und den Lochstreifen zu erklären versucht habe, ist für Nutzer heutiger Systeme, zumindest wenn sie nicht auch Programmierer sind, nur schwer verständlich, denn sie ist sehr technisch. Die Genialität der klassischen Unix-Schnittstelle liegt dann auch nicht in ihrer Einfachheit, sondern in der unerreichten Flexibilität, denn mit Shell, Dateisystem, Piping und Scripting kann man sich die vielen kleinen Unix-Tools stets so zusammensetzen, wie man es gerade braucht.

X-Window-System – Unix kann auch grafisch

Die klassische Unix-Schnittstelle, die ich Ihnen gerade beschrieben habe, finden Sie bei allen unixoiden Betriebssystemen. Egal, ob Sie ein Xenix aus den 1980ern nutzen oder unter einem Ubuntu-Linux oder unter MacOS ein Terminal starten: Sie befinden sich immer in der oben beschriebenen Nutzungsschnittstellen-Welt, die sich auch immer ganz ähnlich gibt. Natürlich ist die Entwicklung zu grafischen Nutzungsschnittstellen aber auch an der Unix-Welt nicht spurlos vorbeigezogen. Als Grundlage für die größere Verbreitung grafischer Nutzungsoberflächen unter Unix kann das X-Window-System des MIT angesehen werden, das seit 1987 in stabiler Version zur Verfügung steht. Ein Blick in die Computergeschichte offenbart durchaus auch frühere grafische Schnittstellen, doch blieben diese oft experimentell oder waren auf einzelne Unix-Derivate beschränkt. Die X-Window-Technik hingegen war ein allgemeiner Standard, der sich bis heute gehalten hat²⁷. Wohl wegen der Namensähnlichkeit mit Microsofts Windows wird die X-Window-Technik mitunter selbst als grafische Nutzungsschnittstelle angesehen. Das ist jedoch eine Fehlcharakterisierung. X-Window stellt nur einen allgemeinen Mechanismus zur Verfügung, den laufende Programme dafür nutzen können, auf den Bildschirm zu zeichnen und Eingaben von Maus, Tastatur usw. zu erhalten. Wie das aussieht, wie die Nutzungsschnittstelle beschaffen ist, welche Objekte es gibt, und letztlich sogar, ob es überhaupt Fenster gibt, ist nicht der Gegenstand von X-Window.

Windows und MacOS sind mehr oder weniger monolithische Systeme. Sie bieten die Methoden zur Anzeige auf dem Bildschirm generell, bieten Bildschirmelemente wie Buttons, Eingabefelder etc. an und kümmern sich auch um die Verwaltung von Fenstern. Hinzu kommen noch Nutzungsschnittstellen zur Dateiverwaltung, zum Starten von Programmen und zum Wechseln zwischen diesen Programmen. Bei grafischen Nutzungsoberflächen unter Unix sind all diese Bereiche getrennt. Das sieht in etwa wie folgt aus:

• Die grundlegendste Ebene bildet der sogenannte X-Server. Er bietet Anwendungen Möglichkeiten, auf den Bildschirm zu zeichnen und die Maus- und Tastatur-Interaktionen des Nutzers zu empfangen. Die Begrifflichkeit „Server“ ist hier etwas verwirrend. Als Server bezeichnet man üblicherweise einen Computer im Netz oder ein Programm auf einem solchen Computer, das Dienste zur Verfügung stellt, die dann mittels Nutzungsschnittstellen-Programmen genutzt werden können. Diese nennt man üblicherweise „Clients“. Das Konzept des X-Servers stellt das ein bisschen auf den Kopf. Der X-Server ist es, der allgemeine Funktionalitäten zur räumlich-grafischen Ein- und Ausgabe zur Verfügung stellt. Die Software-Programme bedienen sich dieser Fähigkeiten und sind damit die Clients. Der Nutzer nutzt also die Clients mittels eines X-Servers.
• Nutzungsschnittstellen sind zusammengesetzt aus sehr grundlegenden Elementen wie Bildschirmbereichen, Buttons, Menüs und Eingabefeldern. Damit nicht jede Software-Anwendung hier das Rad neu erfinden muss, bedienen Entwickler sich Bibliotheken mit solchen Elementen. Diese werden Widget Toolkits genannt.
• Die grundlegende Funktionalität von Fenstern und ihrer Verwaltung obliegt den Window Managern. Der Umfang dieser Fenster-Manager ist unterschiedlich. Auf jeden Fall gehört zu ihnen die Möglichkeit des Fensterverschiebens sowie des Schließens von Fenstern. Die meisten Fenster-Manager setzen dafür die bekannten Methoden mit einem in der Größe veränderbaren Fensterrahmen und einer Reihe von Buttons zum Minimieren, Maximieren und Schließen um. Viele Fenster-Manager stellen auch einen Task Switcher zum Umschalten zwischen Fenstern und einen Application Launcher zum Starten von Programmen bereit.
• Die Kombination aus Window Manager, Widget Toolkits und so grundlegenden Programmen wie einem Datei-Manager und einem Application Launcher bildet ein sogenanntes Desktop Environment.
• Mit einem Betriebssystem wird üblicherweise auch ein Satz typischer Anwendungen ausgeliefert, der teilweise allgemein verfügbar, in anderen Fällen aber extra an das entsprechende System angepasst ist. Im Linux-Bereich werden diese Sammlungen installierter Software-Produkte und Verwaltungswerkzeuge Distribution genannt. Jede Distribution macht eine Vorauswahl bezüglich des Desktop Environments, der mitgelieferten Tools und Verwaltungswerkzeuge und passt diese entsprechend der Philosophie der Distribution an, fügt eigene Plug-Ins hinzu, tauscht Module aus und passt das Aussehen und die Einstellungen an.

Die populäre Linux-Distribution Ubuntu beispielsweise verwendet, Stand 2021, die Desktop-Umgebung GNOME. Der Window-Manager von GNOME heißt „Mutter“, als Datei-Manager kommt „Nautilus“ zum Einsatz. Zu GNOME gehört auch das GTK-Toolkit, das Nutzungsschnittstellen-Elemente bereitstellt. Die Distribution openSUSE hingegen setzt auf die Desktop-Umgebung KDE Plasma mit dem Window-Manager KWin und dem Widget Toolkit qt. Der Datei-Manager von KDE nennt sich „Dolphin“. Linux Mint nutzt den Window Manager Cinnamon mit dem Datei-Manager Nemo, der eine Abspaltung (ein sogenannter „Fork“) einer früheren Nautilus-Version ist. Sie haben hier also dreimal Linux, aber dreimal gibt es sich anders, mit anderen Werkzeugen und mit einer anderen Nutzungsschnittstelle. Damit ist die Verwirrung aber noch nicht am Ende, denn Sie können nicht nur das Desktop Environment austauschen, sondern die Werkzeuge auch kreuz und quer verwenden. Auch wenn man also eine KDE Plasma-Umgebung einsetzt, kann man GNOME-Programme nutzen, insofern man die passenden Toolkits mitinstalliert hat, worum sich die Verwaltungswerkzeuge des Betriebssystems in aller Regel von selbst kümmern. Man kann also auch ein Nautilus unter KDE laufen lassen oder die teils umfassenden KDE-Anwendungen unter Linux Mint installieren. Diese große Flexibilität und Kompatibilität ist es, weswegen es schlichtweg nicht möglich ist, über die grafische Nutzungsschnittstelle von Unix und Linux allgemein zu sprechen. Man braucht, um überhaupt etwas sagen zu können, die Angabe der Distribution, die Version und letztlich eigentlich auch immer die Angabe aller Anpassungen, die ein Nutzer gemacht hat.

KDE Plasma

Eine Betrachtung der grafischen Unix-Nutzungsschnittstellen kann also nur exemplarisch sein, aber diese Beispiele können es stark in sich haben, denn es ist mit ihnen teils viel mehr möglich, als Windows und MacOS im Angebot haben. Um das zu belegen, zeige ich Ihnen einmal die Linux-Distribution Kubuntu 19.03 mit dem Desktop Environment KDE Plasma 5.

Die Nutzungsschnittstelle von KDE Plasma ist grundsätzlich ziemlich stark an die Nutzungsschnittstelle aktueller Windows-Versionen angelehnt. Es gibt einen Startbutton und ein Startmenü, eine Taskleiste und einen Desktop. Der Datei-Manager Dolphin wirkt wie eine Mischung aus Apples Finder und dem Explorer von Microsoft, hat allerdings interessante Features wie eine Split View, die es weder unter Windows noch auf dem Mac von Haus aus gibt. Spannend an der Nutzungsschnittstelle ist das Desktop-Konzept. Bei Windows und auch bei aktuellem MacOS ist der Desktop ein Ordner auf der Festplatte, dessen einzige besondere Eigenschaft es ist, dass seine Inhalte, also die enthaltenen Dateien und Ordner, großflächig als Hintergrund hinter allen Fenstern angezeigt werden. Bei KDE Plasma ist dies auch möglich und in Kubuntu ist diese Einstellung der Standard. Das Layout kann jedoch von „Ordneransicht“ auf „Arbeitsfläche“ umgeschaltet werden.

In der Arbeitsflächen-Ansicht können auf dem Desktop in jeweils eigenen Bereichen kleine aktive Komponenten untergebracht werden. Diese als „Widget“ bezeichneten Miniprogramme können allerlei Aufgaben erfüllen, von der Anzeige des aktuellen Wetters bis zur direkten Einbindung von Websites auf dem Desktop. Wenn Sie ein Android-Telefon besitzen, kennen Sie dieses Konzept, denn auch Android ermöglicht es, auf den Übersichtsbildschirmen nicht nur Icons zum Starten der gewünschten Anwendungen unterzubringen, sondern auch direkt Objekte auf diesen Bildschirmen zu haben, die etwas anzeigen und mit denen interagiert werden kann. Auch in Windows Vista konnte man sich kleine Progrämmchen auf den Desktop legen. Widgets allein wären daher noch nicht etwas, was mich dazu bewegen würde, Ihnen etwas vom KDE-Desktop vorzuschwärmen. Spannend wird die Sache aber dann, wenn man sich über die Möglichkeiten eines sehr einfachen Widgets ein wenig Gedanken macht, nämlich dem Widget, das die Inhalte eines Ordners zur Anzeige bringt. Oben sehen Sie ein Beispiel dafür. Zwei Ordner-Anzeige-Widgets zeigen jeweils einen Ordner an. Der obere Bereich zeigt den Inhalt des Download-Ordners, während der untere den Inhalt eines Ordners mit dem Namen „Projekt 1“ zeigt.

Diese Ordner-Widgets ermöglichen es, viel mehr als Windows und MacOS, dass man sich den Desktop zum eigenen Arbeitsplatz machen kann. Nutzt man KDE Plasma, kann man sich die Projekte, an denen man gerade arbeitet, als eigene Bereiche auf dem Desktop einrichten, mit den Dateien arbeiten und sie sogar zwischen den Ordnern hin und herschieben. Braucht man zwischenzeitlich einen weiteren Bereich direkt im Zugriff, richtet man sich einfach ein weiteres Widget ein. Ist ein Projekt abgeschlossen und nicht mehr relevant, kann man einfach das Widget entfernen. Die Dateien liegen dann nicht mehr auf dem Desktop, sind aber natürlich in der Dateiablage weiterhin vorhanden.

Ebenfalls sehr praktisch bei der Arbeit mit einer Vielzahl von Projekten ist die Funktion „Activities“. Mit ihr lassen sich verschiedene Desktops für verschiedene Aufgaben einrichten. Jeder Desktop hat seine eigene Einrichtung, mit eigenen Widgets, eigenem Hintergrundbild und auch eigenen geöffneten Anwendungen. Die Funktionalität, mehr als einen Desktop anzubieten und so mehrere Arbeitskontexte zu ermöglichen, ist gerade im Bereich der Unix-GUIs schon sehr alt. Inzwischen sind ähnliche Funktionen auch in MacOS und in Windows verfügbar. Ihre Umsetzung ist allerdings im Verhältnis zu den „Activities“ von KDE sehr eingeschränkt, denn weder unter Windows noch unter MacOS werden einem wirklich verschiedene Desktops mit verschiedenen Elementen bereitgestellt. Man kann lediglich zwischen Sätzen geöffneter Fenster wechseln. Anders bei KDE Plasma: Dort kann sich so etwa einen Heim-Desktop und einen Arbeits-Desktop einrichten und sich beiden Kontexten entsprechend anpassen, ohne dass die Objekte des einen Kontextes mit denen des anderen in Konflikt geraten. Braucht man die gleichen Elemente auf mehr als einem dieser Desktops, ist das mit der Widget-Einrichtung gar kein Problem, denn niemand hindert einen daran, für den gleichen Ordner der Festplatte jeweils ein Anzeige-Widget auf den Desktop zu schieben.

Die Anzahl der Leute, die Unix- oder Linux-Systeme mit grafischer Nutzungsschnittstelle bei sich zu Hause oder auf der Arbeit einsetzen, ist verschwindend gering, im niedrigen einstelligen Prozentbereich. Um so erstaunlicher ist es, dass, wie hier zum Beispiel bei KDE Plasma, sehr interessante Nutzungsschnittstellen für die Systeme entwickelt werden, und um so bedauerlicher ist es natürlich, dass kaum jemand in den Genuss dieser Nutzungsschnittstellen kommt. Warum das letztlich so ist, hat sicherlich viele Gründe, über die ich hier nur spekulieren kann. Manches hat sicherlich mit der Marktmacht der großen Firmen Microsoft und Apple und der damit zusammenhängenden großen Verbreitung ihrer Software-Infrastrukturen zu tun. Ein anderer gewichtiger Grund ist meiner Meinung nach aber auch, dass Unix und Linux sich mit ihrer grundsätzlichen Philosophie ein wenig selbst die Möglichkeit des Erfolgs verbauen. Die oben skizzierte Offenheit der Konfiguration und die Möglichkeit, nahezu alles mit allem zu kombinieren, scheint Entwickler durchaus zu beflügeln, neue innovative Funktionen einzubauen. Sie sorgt aber auch dafür, dass man sich als Linux- oder Unix-Nutzer bei Problemen immer noch ein wenig mehr alleine fühlt als andere. Wenn Sie mit Ihrem Windows 10 ein Problem haben, finden Sie sicher jemanden im Bekanntenkreis, der das Problem nachvollziehen und Ihnen helfen kann. Wenn Sie Linux nutzen, wird das aufgrund der Verbreitung schwieriger, aber selbst wenn Sie jemanden finden, der auch Linux nutzt, dann nutzt der wahrscheinlich eine andere Distribution mit anderen Fenster-Managern, anderen Einstellungen und anderen Systemtools.

Unix auf Smartphones?

Dass Unix und Linux im Endanwenderbereich geringe Verbreitung haben, gilt nur, wenn man nur den Bereich der Desktop-Betriebssysteme betrachtet und wenn man MacOS nicht als Unix, sondern als eigenes System zählt. Generell ganz anders sieht die Sache aus, wenn Sie Smartphones und Tablets mit hinzuzählen, denn Apples iOS basiert wie MacOS auf BSD-Unix und Android von Google verwendet unter der Haube Linux als Betriebssystem. Sollte ich Ihnen MacOS, Android und iOS nun also hier als Unix-Systeme vorstellen? Es gibt wie immer mehrere Sichtweisen. Meine ist die der Nutzungsschnittstellen-Welten. Es ergibt zum Beispiel Sinn, wie im vorherigen Kapitel dargelegt, Windows als etwas anderes als MS-DOS zu beschreiben, denn es hat seine ganz eigene Nutzungsschnittstellen-Welt. Wenn Sie einem erfahrenen Informatiker etwas vom Betriebssystem Windows 3.11 erzählen, wird er Sie aufklären, dass es sich bei Windows 3.11, genauso wie bei Windows 95, 98 und ME, nicht um eigenständige Betriebssysteme handelte, sondern um Erweiterungen für MS-DOS. Aus Sicht der Betriebssystemtechnologie mag das stimmen, doch für mich ist es schlichtweg egal. Die Nutzungswelten von reinem DOS mit nur einem gleichzeitig laufenden Programm, einer Kommandozeile und Anwendungen im Text-Modus, und von Windows, mit mehreren gleichzeitig laufenden Anwendungen, einem Programm-Manager und grafischen Objekten, die räumlich manipuliert werden können, sind ganz verschieden. Ein Windows-Nutzer nutzt nicht eigentlich immer noch DOS – zumindest nicht, wenn man die Nutzungsschnittstellen-Brille aufhat. Das Gleiche gilt noch viel stärker für Unix, Android und iOS. Auf der technischen Ebene der Prozess- und Datenträgerverwaltung mag das eine ein Aufsatz auf das andere sein, aber aus Sicht des Nutzers handelt es sich jeweils um eigene Nutzungsschnittstellen-Welten. Android und iOS stehen in einer ganz anderen Tradition als Unix und Linux. Sie sind nicht die Urenkel eines alten Time-Sharing-Systems, sondern Nachfolger der mobilen Personal Digital Assistants der 1990er Jahre und in diesem Zusammenhang will ich sie Ihnen im folgenden Kapitel auch beschreiben.

Vom PDA zum Smartphone

Die Computergeschichte, die ich Ihnen bis hierher erzählt habe, führte, unter anderem, zu dem Desktop-PC, den Sie bei sich zu Hause oder im Büro stehen haben, oder zu dem Laptop, den Sie vielleicht mit sich herumtragen. Diese Computer machen aber einen eher kleinen Teil des heutigen Computermarkts aus. Statistiken zeigen, dass im Jahr 2019 etwa 260 Millionen solcher PCs verkauft wurden¹. Dem stehen im gleichen Jahr sage und schreibe 1,6 Milliarden verkaufte Smartphones und Tablets gegenüber². Unter diesen machen die Smartphones natürlich den größten Teil aus, doch selbst die Anzahl der verkauften Tablet-Computer allein ist größer als die der Desktop-PCs und Laptops zusammengenommen.

Die technische Grundlage der heutigen Betriebssysteme für Tablets und Smartphones bilden Linux (Android) und Unix (iOS und iPadOS). Die Nutzungsschnittstellen dieser Systeme haben aber eine ganz andere Charakteristik als die Unix- und Linux-Systeme mit ihren hierarchischen Dateisystemen und komplexen Shells und Desktop-Oberflächen. Unter Unix, Linux, aber auch unter Windows und MacOS spielt die Dateiablage eine extrem große Rolle. Die Programme zum Zugriff auf die Dateiablagen sind in allen Systemen zentrales, wenn nicht sogar das wichtigste Element der Nutzungsschnittstelle. Die Nutzungswelten von Android, iOS und iPadOS kennen solche zentralen Ablagen nicht oder allenfalls als Zusatzoption ³. Im Vordergrund der Systeme stehen die Anwendungen, neuerdings Apps genannt. Die Apps verwalten ihre Inhaltsobjekte selbst. Was heißt das konkret? Nehmen wir Apples Textverarbeitung Pages, die sowohl auf dem Mac, als auch für iPad und iPhone verfügbar ist. Wie öffnen Sie eine Datei in Pages? Auf dem Mac haben Sie mindestens zwei Möglichkeiten. Sie können entweder die Anwendung Pages öffnen, dann im Menü „Ablage“ (entspricht „Datei“ bei Windows) „Öffnen“ wählen und die Datei auswählen oder Sie verwenden den Dateimanager Finder, suchen die Datei und öffnen Sie durch einen Doppelklick von dort aus. In beiden Fällen spielt die zentrale Dateiablage eine große Rolle. Das Textdokument wird in dieser Dateiablage als eigenständiges, von der Anwendung Pages unabhängiges Objekt angezeigt. Wenn Sie Pages jedoch auf einem iPhone oder einem iPad verwenden, geschieht dies zunächst einmal wie im erstgenannten Fall. Sie öffnen die App – in der Regel durch Antippen des App-Icons auf einem Startbildschirm oder in der App-Übersicht. Nun öffnen Sie aber nicht wie oben eine extern verfügbare Datei. Vielmehr zeigt Ihnen Pages selbst alle Dokumente an, die es unter seiner Verwaltung hat. Sie müssen nie auf „Öffnen“ oder „Speichern“ klicken, sondern wählen einfach das Dokument aus, um das es Ihnen geht, bearbeiten es und wenn Sie damit fertig sind, schließen Sie die App oder wechseln zu einer anderen. Laden und Speichern geschieht jeweils implizit ohne Ihr Zutun.

Dass sich Smartphone- und Tablet-Betriebssysteme und -Anwendungen so anders bedienen als die klassischen PC-Systeme, kommt nicht von ungefähr. Smartphones und die moderne Generation von Tablet-Computern mit Android oder iPadOS, die sich als größere, vielseitigere Spielart des Smartphones entwickelt haben, stehen in einer ganz anderen Tradition als die des PC mit seinen Wurzeln in den Time-Sharing-Systemen und den Pionierarbeiten des Xerox PARC in den 1970ern.

Computer für unterwegs

Die Geschichte der Nutzungsschnittstellen des Computers, wie ich sie Ihnen in diesem Buch vorgestellt habe, war letztlich immer auch eine Geschichte der Miniaturisierung, von den Großrechnern über Minicomputer bis hin zu den Personal Computern. Die Miniaturisierung bedeutete oft weit mehr, als dass die Geräte kleiner wurden. Ein moderner PC ist keine kleine Version eines ENIAC oder einer Zuse Z3. Es handelt sich um Maschinen mit ganz unterschiedlicher Charakteristik. Sie werden ganz anders bedient und auch für ganz andere Zwecke verwendet. Das ist aber natürlich nicht bei jeder Miniaturisierung so. Verwendet man statt eines Desktop-PCs einen kleinen kompakten PC in der Größe eines Buches, gibt es keinen wirklich signifikanten Unterschied. Das Gleiche gilt im Großen und Ganzen auch, wenn Sie Laptops betrachten. Natürlich sind sie viel kleiner und ermöglichen es, PCs in Situationen und an Orten zu verwenden, an denen dies mit einem Desktop-Rechner noch kaum möglich gewesen wäre, aber es ist eben doch ein miniaturisierter Personal-Computer für dessen Bedienung man die Personal-Computer-Denkweise an den Tag legen muss. Neben dieser Miniaturisierung des Personal-Computers gab es allerdings noch eine weitere Miniaturisierungs-Entwicklungslinie, die Geräte hervorgebracht hat, die eine eigene Geräteklasse mit eigener Bedienung und eigener Denkweise darstellen. Das vorübergehende Endprodukt dieser Entwicklung haben wahrscheinlich auch Sie in Ihrer Tasche stecken oder auf dem Tisch liegen. Die Entwicklungslinie der Miniaturisierung, die zum Smartphone geführt hat, möchte ich Ihnen in diesem letzten Abschnitt meines Buchs vorstellen.

Ein zentraler Aspekt heutiger Smartphones sind sicherlich die „Apps“, also die im Mittelpunkt stehenden Anwendungen. Jede App eines typischen Smartphone-Betriebssystems hat ihre eigene, klar abgegrenzte Funktion. Die beim PC so allgegenwärtigen Dateien, abgelegt in einer hierarchischen Dateiablage, kommen in der Nutzungsschnittstelle eines Smartphones im Prinzip nicht vor. Eine Notiz-App verwaltet die mit ihr erstellten Notizen, eine Musik-App die Musik, eine Textverarbeitungs-App die Dokumente. Notiz-Dateien, Text-Dateien oder Musik-Dateien gibt es in der Nutzungsschnittstellen-Welt nicht. Diese Einschränkung mag weniger flexibel sein, macht die Nutzung der Geräte aber auch viel einfacher, was der Akzeptanz der Technik zugutekommt. Viele Menschen, die von sich sagen, dass sie mit einem Computer nicht umgehen können, nutzen ganz selbstverständlich ein Smartphone und kommen ganz gut damit zurecht.

Natürlich wurden schon vor dem Smartphone Nutzungsschnittstellen erdacht, die es gerade den nicht-computeraffinen Nutzern ermöglichen sollten, von der Computertechnik zu profitieren. Sie haben zum Beispiel im Kapitel „Schreibtische und Fenster“ vom Xerox Star erfahren, dessen Zielgruppe Angestellte mit Bürotätigkeiten waren. Die Nutzungsweise, die die Xerox-Entwickler beim Star damals einführten, der Desktop und das dokumentzentrierte Arbeiten, war allerdings das absolute Gegenteil der App-Idee der Smartphones. Die Anwendungen standen beim Star nicht etwa im Vordergrund, sie kamen in seiner Nutzungsschnittstellen-Welt gar nicht vor. Den heutigen app-basierten Nutzungsschnittstellen viel näher kam da schon die typische Nutzungsweise des Apple II. Zwar konnte man den Apple II mit einem DOS starten und dann mittels Kommandozeile die Dateien auf Disketten verwalten, doch konnte man die Kommandozeile auch gänzlich meiden, wenn man sie nicht nutzen wollte. Wollte man etwa die Tabellenkalkulation VisiCalc nutzen, musste man keine Befehle eingeben, sondern nur die passende Diskette einlegen und den Computer starten. VisiCalc startete dann automatisch. Genauso hielt es jeder nennenswerte Software-Hersteller. Software wurde stets auf einer Diskette ausgeliefert, die so eingerichtet war, dass der Computer direkt mit ihr gestartet werden konnte. Man wählte also durch Auswahl der passenden Programmdiskette quasi seine „App“, um den modernen Ausdruck zu verwenden. Die Objektauswahl, also das Laden, Speichern oder gar Löschen von Dateien, übernahmen diese Programme jeweils für sich. Ich kann es natürlich nicht belegen, aber es scheint mir sehr plausibel, dass neben dem Vorhandensein von Programmen wie VisiCalc gerade diese Design-Entscheidung des automatischen Bootens in eine Anwendung hinein mit ein Grund dafür war, dass der Apple II für die Wirtschaftswelt attraktiv wurde, denn es war dadurch sehr einfach, einen Apple II für Tabellenkalkulation oder Textverarbeitung zu nutzen, ohne größere Computerkenntnisse haben zu müssen. Man musste sich nicht mit einem doch irgendwie kryptischen Betriebssystem herumplagen, sondern nur die Diskette mit dem richtigen Programm einlegen. Um alles Weitere kümmerte sich die Nutzungsschnittstelle des Anwendungsprogramms selbst, die im Gegensatz zum DOS die Potenziale der räumlichen Schnittstelle auszunutzen wusste.

Mobile Personal Computer

Nutzer aus Handel und Wirtschaft waren mit die ersten, die einen Sinn darin sahen, mobile Computer zu nutzen. Für einen Handlungsreisenden etwa hatte es einen großen Wert, die typische Büroarbeit auch an Ort und Stelle, im Hotel oder notfalls sogar im Auto erledigen zu können. Es wurden daher schon relativ früh mobile Personal Computer hergestellt. Auf diesen Rechnern liefen grundsätzlich die gleichen Betriebssysteme wie auf „großen“ Personal-Computern. Auf dem Osborne 1, den ich Ihnen gleich vorstellen möchte, lief zum Beispiel das damals verbreitete CP/M, das Sie im Kapitel über den Altair 8800 kennengelernt haben. Nutzer konnten eine CP/M-Diskette in das Diskettenlaufwerk des Osborne einlegen und dann mit der Tastatur und dem winzigen Bildschirm die Kommandozeile bedienen, doch genau wie beim Apple II konnte man diese doch eher technische Oberfläche auch großteils meiden, indem man ein Programm direkt startete.

Osborne 1 (1981)

Der Osborne 1 war meines Wissens nach der erste nennenswerte mobile Rechner für die Zielgruppe der Büroarbeiter. Zwar existierten durchaus schon vorher einige mobile Geräte, wie der IBM 5100 aus dem Jahr 1975 und der HP85 aus dem Jahr 1980, doch waren das noch keine Rechner, die wie ein PC mit Standard-Software ausgestattet werden konnten. Der IBM 5100 konnte Programme in den Programmiersprachen BASIC und PL/1 ausführen, die unter anderem auch auf IBMs großen Rechenanlagen verbreitet waren. Auch der HP85 bot dem Nutzer eine BASIC-Umgebung. Sein Schwerpunkt lag mit einem Kolonnendrucker⁴ und der Möglichkeit, am Bildschirm Funktionen auszuplotten vor allem im wissenschaftlichen Bereich. Weder der IBM 5100 noch der HP85 waren dazu gedacht, unterwegs Briefe zu verfassen, Datenblätter in einer Tabellenkalkulation zu erstellen oder eine Adressdatenbank zu aktualisieren. Der Osborne hingegen war genau hierfür ausgelegt.

Der Osborne 1 erschien im Jahre 1981 kurz vor der Vorstellung des IBM PCs. Es handelte sich um einen voll ausgestatteten Rechner, der das etablierte Betriebssystem CP/M nutzen konnte. Dazu werkelte in dem Rechner eine zum Intel 8080 kompatible Zilog-80-CPU, die auch in vielen Heimcomputern der 1980er Jahre Verwendung fand. Osborne stattete den Computer mit 64 KB Speicher aus, was das Maximum dessen war, was mit CP/M und der Rechnerarchitektur möglich war. Der Rechner verfügte über eine voll ausgestattete Tastatur, die im Gegensatz zu vielen CP/M-Rechnern sogar über Pfeiltasten verfügte. Da es sich um einen Rechner für Büroarbeit handelte, gab es auch einen Nummernblock. Die Tastatur war gleichzeitig auch der Deckel des Computers. Zwei Diskettenlaufwerke gehörten ebenfalls mit zur Ausstattung. Der Schwachpunkt des Rechners war sicherlich sein Bildschirm. In der Mitte des großen, wuchtigen Gerätes befand sich ein mit 5 Zoll lächerlich kleiner monochromer Röhrenmonitor, der 24 Textzeilen à 52 Zeichen darstellen konnte. Heutige Smartphone-Displays sind in der Regel weitaus größer als dieser Bildschirm. Im stationären Betrieb musste man den Bildschirm nicht nutzen, denn das Gerät ermöglichte auch den Anschluss eines größeren Monitors. Der Osborne 1 wog etwa elf Kilogramm und war damit alles andere als ein Leichtgewicht. Es handelte sich zwar um einen mobilen Rechner, doch verstand man darunter damals etwas ganz anderes als das, was wir uns heute unter einem Mobilrechner vorstellen. Niemand hatte wohl den Anspruch, diesen Rechner ständig dabei zu haben wie ein Tablet oder ein Notebook, doch ein Handlungsreisender konnte den Osborne bequem im Auto transportieren, mit ins Hotel nehmen oder vielleicht bei einem Außendiensteinsatz beim Kunden auf einen Schreibtisch stellen und direkt vor Ort arbeiten. Eine Batterie hatte der Rechner nicht. Man war also auf eine 220 Volt- bzw. 110 Volt-Stromversorgung angewiesen.

Zentral für den Rechner war die mitgelieferte Software. Neben dem meist mit CP/M ausgelieferten MBASIC von Microsoft waren das die Tabellenkalkulation SuperCalc, die Textverarbeitung WordStar und die Datenbank dBase. Später waren auch drei Buchhaltungsprogramme mit im Paket. Dass Software mit dem Rechner ausgeliefert wurde, war bei CP/M-Systemen nicht unwichtig, denn zwar war das Betriebssystem ein gesetzter Standard, sodass grundsätzlich die Software, die auf einem CP/M-System lief, auch auf einem anderen zum Laufen gebracht werden konnte, doch zum einen gab es kein einheitliches Diskettenformat, sodass es nicht ohne großen Mehraufwand möglich war, die Programme, die etwa auf Altair-Disketten gespeichert waren, auf dem Osborne zu verwenden, und zum anderen unterschieden sich die Systeme oft sehr stark in ihren Terminal-Fähigkeiten. Im Kapitel „Terminals statt Fernschreiber“ haben Sie über die Vorteile von Bildschirmterminals gegenüber den alten Fernschreibern gelesen. Sie ermöglichten es, Objekte am Bildschirm direkt zu bearbeiten und an Ort und Stelle zu aktualisieren. Damit das realisierbar war, musste es möglich sein, die einzelnen Zeichen am Bildschirm direkt anzusteuern, zu löschen und zu überschreiben. Das geschah, indem spezielle Zeichen, sogenannte „Steuercodes“, an das Terminal geschickt wurden. Verschiedene Terminals verwendeten aber leider ganz verschiedene Steuercodes. Beim Osborne kam noch die eigenartige Zeilenlänge von 52 Zeichen hinzu. Verwendete man hier eine Software, die von 80 Zeichen ausging, wäre die Darstellung bestenfalls unvollständig, schlimmstenfalls völlig chaotisch gewesen.

Der Grund, warum ich den Osborne als einen der ersten Schritte zur Entstehung einer neuen Art von mobilen Computern ansehe, liegt zum einen in der recht typischen Auswahl der Software, die wir gleich bei nahezu allen Geräten wiederfinden werden. Zum anderen liegt es daran, wie die Firma Osborne die Programme auslieferte, denn wie beim Apple II musste sich niemand, der das nicht wollte, mit einer Kommandozeile herumplagen. Wollte man ein Datenblatt bearbeiten, galt es nur, die Diskette mit der entsprechenden „App“ einzulegen und den Rechner zu starten. Jede Diskette war so eingerichtet, dass sie ein Rumpf-Betriebssystem enthielt, also zum Starten des Rechners verwendet werden konnte und dann das jeweilige Anwendungsprogramm direkt startete. Das machte den Osborne in der Bedienung sehr einfach, viel einfacher als zum Beispiel den Compaq Portable von 1983, der mit einem viel größeren Bildschirm, mehr Speicher und mit MS-DOS ausgestattet war. Diesem Gerät stand zwar eine viel größere Software-Basis offen, die dank etablierter Standards auch von einem zum anderen Rechner weiterkopiert werden konnte, doch musste sich der Nutzer des Compaq mehr mit dem Betriebssystem MS-DOS auseinandersetzen, als es ihm vielleicht lieb war. Der Compaq Portable war kein Schritt zu PDA und Smartphone, sondern eher zum Notebook oder Laptop, das heutzutage unter Windows 10 oder MacOS betrieben wird.

EPSON PX-8 (1984)

Der Osborne 1 war ein mobiler Computer in dem Sinne, dass er nicht zwangsläufig ortsfest im Büro oder auf dem heimischen Schreibtisch stehen musste. Ein Gerät zum „Immer-Dabeihaben“ war er aber auch nicht. Doch auch solche Geräte gab es bereits in den 1980er Jahren. In der Abbildung sehen Sie den 1984er PX-8 von EPSON. Das Gerät hat in zugeklapptem Zustand etwa die Dicke eines Fachbuchs. Der Rechner findet also durchaus Platz in einer Aktentasche. Legte man den Rechner vor sich auf den Tisch, konnte man ein kleines Display ausklappen. Dann kommt auch ein Laufwerk für Mikrokassetten zum Vorschein. Solche Kassetten fanden in den 1980er, 1990er und auch noch in den frühen 2000er Jahren in Anrufbeantwortern und Diktiergeräten ihre Anwendung. Die Ausstattung des PX-8 war trotz des großen Unterschieds im Erscheinungsbild der des Osborne recht ähnlich. Auch hier war ein Z80-Prozessor verbaut und auch die Speicherausstattung von 64 KB war identisch. In einem kompakten, mobilen Gerät konnte aber natürlich nicht, wie beim Osborne oder einem Compaq Portable, eine Bildröhre verbaut werden. Stattdessen kam ein Flüssigkristall-Display zum Einsatz. Es erzeugte ein scharfes, kontrastreiches Bild und konnte 8 Zeilen Text à 80 Zeichen darstellen. 8 Zeilen sind zwar nicht viel, doch war das Display für Textverarbeitung unterwegs schon recht gut geeignet, denn die 8 Zeilen reichen durchaus, um ein wenig vom Textzusammenhang sehen zu können, und die Zeilenlänge von 80 Zeichen ermöglichte es, Text zu schreiben, ohne dass der Textausschnitt horizontal verschoben werden musste.

Auch EPSON setzte beim PX-8 auf das etablierte CP/M-Betriebssystem. Es musste hier allerdings nicht von einer Diskette oder gar von der Mikrokassette geladen werden, sondern war als ROM-Modul (Read-Only Memory) fest in den Rechner eingebaut. Zusätzlich dazu konnten zwei weitere Steckplätze mit Festspeichermodulen bestückt werden. Kunden konnten unter anderem die Textverarbeitung Portable WordStar, die Tabellenkalkulation Portable Calc, die Terminverwaltung Personal Scheduler oder die Datenbank dBase II wählen. Allerdings konnten stets nur zwei dieser Software-Module gleichzeitig eingesetzt werden.

Nutzer des PX-8 brauchten sich üblicherweise nicht mit ihrem Betriebssystem auseinanderzusetzen. Die Anwendungsprogramme konnten sie komfortabel über ein Menüsystem starten. Um die Dateiverwaltung kümmerten sich die Anwendungsprogramme größtenteils selbst. Die Nutzer kamen allerdings nicht ganz um die Eigenschaften des Dateisystemzugriffs von CP/M mit seinen Laufwerksbuchstaben herum. Gespeichert werden konnten Dateien auf den Mikrokassetten oder bei Anschluss eines externen Laufwerks auch auf Disketten. In vielen Fällen war das aber nicht notwendig, denn auch ganz ohne externe Speichermedien konnte der Rechner Dateien auf einer batteriegepufferten RAM-Disk intern speichern. RAM-Disk bedeutet, dass ein Teil des Arbeitsspeichers abgezwackt und so verwendet wird, als handelte es sich um einen Datenträger. Der Hauptvorteil einer RAM-Disk besteht darin, dass sie sehr schnell ist. Ihr großer Nachteil ist allerdings, dass der Speicherplatz, je nach Rechnerausstattung, sehr beschränkt ist und dass der Inhalt der RAM-Disk verloren geht, wenn die Stromversorgung abbricht. Nutzer des PX-8 taten also gut daran, ihre Datenbestände regelmäßig auf persistentere Speichermedien zu sichern.

Pocket-Computer

In der Tradition der einfachen, mobilen Rechner wie dem PX-8 stehen die Pocket-Computer der späten 1980er Jahre. Diese Rechner, die mitunter auch unter dem Begriff „Palmtop PC“ bekannt waren, waren vom Funktionsumfang dem PX-8 ziemlich ähnlich, wurden aber soweit verkleinert, dass man sie in einer etwas größeren Jackentasche unterbringen konnte.

Atari Portfolio (1989)

Das erste Gerät dieser Art war der hier abgebildete Atari Portfolio, den Atari selbst als „16 Bit Personal Computer“ beschrieb. Er wurde 1989 auf den Markt gebracht und kostete damals 399,95 Dollar (in 2021er Kaufkraft etwa 866 Dollar). Er hatte etwa die Größe einer VHS-Video-Kassette und wog ca. 500 Gramm. Obwohl der Rechner die Marke Atari trug wurde, lief auf ihm nicht etwa das TOS des Atari ST, sondern das viel einfachere DIP DOS, ein Betriebssystem, das größtenteils mit Microsofts MS-DOS kompatibel war. Es handelte sich technisch hier also in der Tat um einen kleinen IBM-PC-kompatiblen Rechner. Mit seiner Hardware-Ausstattung, einem Intel 80C88 mit 4,92 MHz und 128 KB Arbeitsspeicher war er in etwa so leistungsfähig wie der Ur-PC von IBM aus dem Jahre 1981. In einem so kleinen Gehäuse war das durchaus ordentlich. Gegenüber dem IBM PC eingeschränkt war natürlich wieder einmal der Bildschirm. Auf dem Flüssigkristall-Display fanden nur 8 Textzeilen à 40 Zeichen Platz.

Genau wie beim PX-8 musste man die Software des Portfolio nicht von einem Datenträger laden, denn sie war auf einem ROM-Chip in das Gerät fest eingebaut. Per Menü erreichbar war eine Adressverwaltung (samt Telefon-Wählhilfe⁵), eine Terminverwaltung, ein Wecker, ein einfacher Texteditor als Textverarbeitung, eine Tabellenkalkulation und ein Taschenrechner. All diese Software und das DIP-DOS-System fanden auf einem 256 KB Daten fassenden ROM-Chip Platz. Wie beim PX-8 war es nicht nötig, den Kommandozeilen-Interpreter zu nutzen. Die Programme konnten per Menü und sogar per Tastendruck direkt von der Tastatur aus gestartet werden. Ebenso wie der PX-8 konnte der Portfolio Daten auf einer integrierten RAM-Disk speichern. Der Platz dort war jedoch stark beschränkt. Als externe Speichermedien standen daher Speicherkarten nach dem Bee-Card-Standard zur Verfügung. Diese Karten hatten etwa die Größe einer Karte eines handelsüblichen Kartenspiels oder einer Kreditkarte, waren allerdings etwa so dick wie ein Bierdeckel. Das Bild oben zeigt eine solche Karte, die sage und schreibe 32 KB Daten fassen konnte. Die Karte sieht ein bisschen aus, wie eine zu groß geratene SD-Speicherkarte, wie man sie heute in digitalen Kameras verwendet. Die Technik ist jedoch eine ganz andere, denn die heute verwendete Flash-Speicher-Technik stand damals im Massenmarkt noch nicht zur Verfügung. Die Speicherkarten enthielten daher eine Knopfzellen-Batterie und eine Elektronik, die die eingebauten Speicherzellen dauerhaft mit Strom versorgte. Auf vergleichbaren Karten, allerdings in einer stromlosen Festspeicherversion, konnte auch Zusatz-Software wie etwa ein Schachspiel und eine Finanz-Software erworben werden. Diese Software-Module verfügten nur über einen Festspeicher-Chip, brauchten also keine Pufferbatterie. Zusatzmodule verbanden den kleinen Rechner über eine serielle Schnittstelle mit einem PC, einem Modem oder einem Drucker.

Der Portfolio blieb nicht das einzige Gerät seiner Klasse. Aus dem Jahr 1991 etwa stammt der HP 95LX von Hewlett Packard. Er war dem Portfolio in Sachen Ausstattung und Funktionsumfang ziemlich ähnlich, hatte allerdings mehr Speicher und einen Bildschirm, der 16 Zeilen anzeigen konnte, was den Rechner sicher für Aufgaben wie Tabellenkalkulation besser geeignet machte, bei denen ein wenig Überblick über das Tabellenblatt ja hilfreich ist. Springen wir noch ein paar Jahre weiter ins Jahr 1994, findet man den HP 200LX, der nun eine CGA-kompatible Grafikausgabe aufweist, allerdings auf einem Flüssigkristall-Display in Graustufen. Mit dem Gerät wurde es möglich volle 25 Zeilen à 80 Zeichen Text anzuzeigen.

Frühe PDAs

Viele der kleinen, mobilen Computer, die ich Ihnen soeben vorgestellt habe, werden heute nachträglich der in den 1990ern populären Geräteklasse der PDAs (Personal Digital Assistants) zugeordnet. Diesen Begriff gab es damals so allerdings noch nicht. Er kam erst mit Apples Newton auf, den ich Ihnen erst im folgenden Kapitel vorstellen werde.

Mit den PDAs wird, zumindest meinem Verständnis der Computergeschichte entsprechend, die eingangs beschriebene neue Charakteristik deutlich. Sie sind keine miniaturisierten PCs, sondern etwas eigenes mit eigener Nutzungsschnittstellen-Welt. Trifft das hier schon zu? Die vorgestellten Geräte stehen bei der Beantwortung dieser Frage auf einer Grenze. Der klobige Osborne 1 ist wohl am ehesten noch eine transportable Version eines typischen CP/M-basierten Computersystems seiner Zeit. Die Geräte, die ich Ihnen danach gezeigt habe, sind allesamt nicht nur kompakter, ihre Bedienung ist auch weit weniger PC-artig. Man muss keine Software mehr von Disketten laden, muss den Kommandozeilen-Interpreter nicht nutzen und hat insgesamt sehr wenig mit dem Betriebssystem zu tun, da die mitgelieferte Software und ihre Nutzungsschnittstellen im Vordergrund stehen. Dahinter stehen aber nach wie vor noch die Standard-Betriebssysteme CP/M oder DOS. Die Software der Systeme ist PC-Standard-Software, wenn auch manchmal ein kleines bisschen an die kleinen Geräte angepasst. Am offensichtlichsten wird das in der Art und Weise, mit der innerhalb der Anwendungen die Dateien geladen und gespeichert werden, denn spätestens an dieser Stelle schlägt das Dateisystem des Betriebssystems mit seinen Laufwerksbuchstaben und Pfaden auf die Nutzungsschnittstelle durch. Die genannten Computer sind wichtige Schritte zum Personal Digital Assistant, ich würde ihnen das Etikett selbst aber noch nicht anheften, denn meiner Meinung nach fehlt der wichtige Schritt einer komplett eigenen Nutzungsschnittstelle, die nicht mehr auf CP/M oder DOS aufbaut und damit auch deren Charakteristika nicht mehr teilt. Erste Schritte in eine solche Richtung wurden bereits Mitte der 1980er Jahre gemacht.

PSION Organiser

Einer der ersten mobilen Computer, der nicht auf einem PC-Betriebssystem basierte, war der PSION Organiser von 1984. Der Rechner hatte die Anmutung eines zu groß und vor allem zu dick geratenen Taschenrechners. Das Gerät verfügte zur Ausgabe nur über eine einzige Zeile mit 16 Zeichen. Damit und mit dem sehr kleinen Speicher von 2 KB waren die Einsatzmöglichkeiten natürlich beschränkt. In seiner Grundausstattung bot das Gerät nur eine sehr minimalistische Datenbank, eine Uhr und eine Taschenrechnerfunktionalität. Weitere Funktionen konnten durch Anstecken von Modulen, die zusätzlich erworben werden konnten, verfügbar gemacht werden. Unter diesen gab es auch ein Modul mit einer einfachen Programmiersprache mit dem zumindest im Deutschen ungeschickten Namen POPL.

Schon praktischer im Einsatz war die zweite Ausgabe des Organisers aus dem Jahre 1986, die zunächst mit zwei-, später mit drei- und vierzeiligem Display aufwartete. Besonders beliebt waren diese Organiser in Betrieben, in denen es galt, viele Daten zu erfassen. Die Geräte waren nahezu unverwüstlich und konnten mit Erweiterungsmodulen gut mit Schnittstellen und Eingabegeräten wie Barcode-Scannern verbunden werden.

Gegenüber den oben genannten Pocket-PCs waren PSIONs Organiser natürlich eingeschränkt. Das hatte aber den Vorteil, dass ihre Nutzungsschnittstelle natürlich zwangsläufig einfacher war. Zum Einsatz kam nun nicht mehr Standard-Software aus dem PC-Bereich, sondern Software mit Nutzungsschnittstellen, die extra für diese Geräteklasse entwickelt wurden.

PSION Series 3 (1993)

Die Nachfolgegeräte des PSION Organiser II verloren den Namensteil Organiser, was eigentlich ein wenig merkwürdig ist, denn die Geräte ab der Series 3 im Jahre 1993 unterstützten eigentlich viel mehr als vorher die Aufgaben, für die man klassischerweise Papier-Organiser nutzte. Die Geräte glichen vom äußeren Aufbau mehr den zuvor erläuterten Pocket-Computern als dem frühen EPSON-Organiser. Im Gegensatz zu den Pocket PCs kam nun aber kein CP/M oder MS-DOS mehr zum Einsatz, sondern ein eigens neu entwickeltes System namens EPOC. Auf der Abbildung sehen Sie EPOC im Einsatz auf einem Series-3a-Gerät. Das Gerät bot die schon bekannten Anwendungen für Kalender, Datenbank und Taschenrechner, aber auch Tabellenkalkulation und Textverarbeitung. Mit der Programmiersprache OPL konnten eigene Anwendungen für die Geräte geschrieben werden, die auch auf alle grafischen Fähigkeiten der Nutzungsschnittstelle zugreifen konnten.

Die Abbildung verdeutlicht gut eines der interessanten Eigenschaften der Nutzungsschnittstelle der Series 3. Anders als bei den PC-Betriebssystemen liegt dem EPOC kein für den Nutzer sichtbares Dateisystem zugrunde. Es gibt daher kein dem Explorer oder Finder entsprechendes Programm zur Verwaltung von Dateien. In den Anwendungsprogrammen gibt es dementsprechend auch kein Äquivalent eines allgemeinen Öffnen- und Speichern-Dialogs. Die Anwendungen selbst verwalten vielmehr die mit ihnen erstellten Dokumente und bieten sie auf geeignete Weise an. Die Nutzungsschnittstelle der Series-3-Geräte weist dabei ein Feature auf, das es in späteren Geräten nicht mehr gab und das es so meines Wissens nach auch bei keinem anderen PDA oder Smartphone je gab. Sie haben auf der Hauptübersicht nicht nur die Anwendungen wie „Address“ oder „Accounts“, sondern auch die mit dieser Anwendung zuletzt verwendeten Objekte direkt im Angebot. Diese Objekte konnten mit den Pfeiltasten direkt ausgewählt und durch „Enter“ geöffnet werden. Dieser Mechanismus verdeutlicht nicht nur anschaulich die Zuordnung dieser Nutzungsobjekte zu ihren Anwendungen, sondern war zudem noch eine sehr praktische Abkürzung und eine praktische Übersicht.

Die Geräte von PSION und anderen Herstellern vollzogen den eingangs angedeuteten Schritt von einer Geräteklasse zur anderen. Sie sind das Produkt von Miniaturisierung, aber sie sind nicht einfach nur verkleinerte Desktop-PCs, sondern etwas anderes. PC-typisch ist noch der Grundaufbau des Geräts mit Tastatur und Bildschirm. Auch dieser sollte sich in den 1990ern mit dem Apple Newton und den Palm-PDAs ändern.

Personal Digital Assistants

Die mobilen Geräte von PSION, Series 3 und die Folgegeräte, habe ich Ihnen als eine eigene Geräteklasse vorgestellt. Es handelt sich bei ihnen nicht mehr um kleine, kompakte PCs, sondern um Geräte mit einer ganz eigenen Nutzungsschnittstelle und einer ganz eigenen Objektwelt, die ganz anders verwendet werden, als ein PC oder Laptop. Die Geräte werden heute der Klasse der Personal Digital Assistants, kurz PDA, zugerechnet. So richtungsweisend diese vorgestellten Geräte auch gewesen sein mögen, in Sachen Eingabetechnik waren sie noch recht altmodisch, basierten sie doch vollständig auf der Eingabe per Tastatur, die auch räumlich einen beträchtlichen Anteil des Geräts ausmachte. Am PC war man hier mit der Maus, die die direkte, räumliche Auswahl von Objekten am Bildschirm ermöglichte, bereits weiter. Bei den nun folgenden Geräten, die nicht nur nachträglich als PDA bezeichnet wurden, sondern die auch unter dieser Bezeichnung verkauft wurden – allen voran der Apple Newton – stand der Bildschirm als Eingabegerät im Vordergrund. Eine Tastatur gab es in vielen Fällen teilweise nicht mehr. Eingaben wurden stattdessen mit einem Stift oder teilweise auch mit den Fingern direkt auf dem Bildschirm durchgeführt.

Newton MessagePad – Der Vorreiter

Wie so häufig stapelte Apple bei der Markteinführung des Newton hoch. Nicht weniger als die Neuerfindung des Personal Computing wollte die Firma für sich beanspruchen. Das neue Gerät, der Personal Digital Assistant mit dem Namen Newton MessagePad aus dem Jahr 1993, war in der Tat ein innovatives Gerät, das neue Eingabe- und Nutzungsformen ermöglichte, die vorher weder mit einem PC, einem Macintosh noch mit früheren kompakten Computern möglich waren. Ein Erfolg war der Newton jedoch nicht, was vor allem mit der schlechten Leistung eines zentralen Features zu tun hatte. Dazu gleich mehr. Von der reinen Funktionalität her betrachtet, stand der Newton ganz in der Tradition der im vorherigen Kapitel betrachteten Geräte. Die auf dem 4 MB großen ROM-Chip untergebrachte Software bot eine Textverarbeitung, die Möglichkeit zum Anlegen von Notizen und Checklisten, einen Kalender, eine Adressverwaltung, einen Taschenrechner, Uhr und Wecker sowie ein Programm zum Lesen von elektronischen Büchern. Einen Dateimanager gab es nicht. Das Konzept der Datei an sich kam in der Nutzungsschnittstelle des Newton nicht vor.

Vom Standpunkt der Eingabemethodik und damit auch von der grundsätzlichen Bedienweise her unterschieden die Geräte sich jedoch stark. Der Bildschirm des Newton war 6 Zoll groß und konnte 320 x 240 Pixel in 16 Graustufen darstellen. Alle Eingaben wurden über die Bildschirmoberfläche durchgeführt. Das Betriebssystem Newton OS war daher vollständig auf die Bedienung mit dem mitgelieferten Stift ausgelegt, der praktischerweise auf der rechten Seite zum Transport in das Gerät hineingeschoben werden konnte. Mit dem Stift konnten Funktionen ausgewählt und Buttons angeklickt werden. Vor allem aber konnte mit ihm geschrieben und gezeichnet werden. Der Newton verfügte dazu über mehrere Eingabemodi. Der einfachste war der „Sketches-Modus“. Hier erscheinen alle Linienzüge, die mit dem Stift auf der Bildschirmoberfläche gemacht wurden, direkt als Strichzeichnungen im Dokument. Die geometrischen Figuren, die Sie auf der Abbildung sehen, wurden im „Shapes-Modus“ erzeugt. In diesem Modus war es möglich, Figuren wie Rechtecke, Dreiecke, Kreise und Linien recht grob zu zeichnen. Die Figuren wurden (in den meisten Fällen) erkannt und als saubere Figur-Objekte angelegt. Verwendete man hingegen den „Ink-Text-Modus“, arbeitete eine Texterkennung daran, den in Handschrift auf das Display geschriebenen Text zu erkennen und in digitalen Text umzuwandeln.

Alle geometrischen Figuren, Texte und auch die Linienzüge der Freihandzeichnungen standen als Objekte zur Verfügung. Sie ließen sich also am Bildschirm bearbeiten, verschieben, löschen und im Falle grafischer Elemente auch in Größe und Ausrichtung verändern. All diese Operationen wurden wieder mit dem Stift durchgeführt. Hierzu wurden einige sehr interessante Interaktionsformen ersonnen. Ein Wort etwa konnte dadurch gelöscht werden, dass man es in einer Zick-Zack-Geste durchstrich. Der Newton machte dann ein „Puff“-Geräusch und das Wort verschwand vom Bildschirm. Das Gleiche funktionierte auch mit grafischen Objekten. Spezielle Eingabegesten existierten, um einzelne Worte oder neue Zeilen einzufügen. Sollten mehrere Objekte, egal ob Text oder Grafik, markiert werden, geschah dies, indem man den Stift eine Sekunde auf eine Stelle auf dem Bildschirm hielt und dann den Text unterstrich oder die grafischen Objekte umrahmte. Sobald man den Stift dann vom Bildschirm nahm, waren die Objekte markiert und konnten zum Beispiel verschoben werden.

Aus Nutzungsschnittstellen-Sicht faszinierend war Apples Umsetzung der Zwischenablage, denn auch die funktionierte vollständig räumlich. Nehmen wir an, man wollte einen Satz aus einem Notizdokument an eine andere Stelle verschieben. Um das zu tun, markierte man den Satz wie oben beschrieben und schob ihn dann an den linken oder rechten Bildschirmrand. Dort wurde er dann in Kurzform angezeigt. Im Bild rechts sehen Sie, wie das aussah. Hier wurde der Satz „Joe is in Suite 302“ aus dem Notizbuch an den Rand geschoben. Inzwischen wurde der Kalender aufgerufen. Der kopierte Satz befindet sich immer noch am Bildschirmrand. Er kann nun in den Kalender eingefügt werden, indem er einfach an die Stelle gezogen wird, an der er hinterher stehen soll. Kopieren war ähnlich einfach. Der einzige Unterschied zum Verschieben bestand darin, dass das Objekt vor dem Verschieben mit einer Art halbem Doppelklick (runter-hoch-runter) markiert wurde. Die Newton-Interpretation der Zwischenablage ist sicher ungewöhnlich, aber aus der Sicht eines Nutzungsschnittstellen-Interessierten ist sie spannend, denn sie ist vielen anderen Zwischenablagen voraus. Einzig die Zwischenablage des Bravo-Editors des Xerox Alto, die ich Ihnen im Kapitel „Schreibtische und Fenster“ beschrieben habe, ist von der Funktionalität her ähnlich. Im Gegensatz zu MacOS, Windows sowie iOS und Android hat man beim Newton die Objekte, die verschoben oder kopiert werden können, stets im Blick. Die Inhalte der Zwischenablage stehen als sichtbare Objekte am Bildschirm zur Verfügung und werden durch räumliche Operationen eingefügt oder kopiert. Bei allen anderen Systemen hingegen befinden sie sich in einer unsichtbaren Zwischenablage und werden durch eine nicht-objektbezogene Kommandoauswahl eingefügt. Wenn man in Word „Einfügen“ anklickt, sieht man erst nach der Aktion, was eingefügt wurde, was der Befehl also bewirkt hat, auf welches Objekt er sich bezog. Nicht nur hier ist die Newton-Zwischenablage im Vorteil. Sie ist auch nicht, wie die Zwischenablagen an modernen Systemen, auf ein einziges Objekt beschränkt. Niemand hindert Sie beim Newton daran, verschiedene Schnipsel erst am Bildschirmrand zu sammeln und dann an anderer Stelle einen nach dem anderen einzufügen. Bei aktuellen Systemen geht das nicht – dort müssen Sie ständig zwischen Quelle und Ziel hin- und herwechseln.

Wieder einmal habe ich Ihnen in den höchsten Tönen ein Gerät beschrieben, das als ein großer Flop in die Computergeschichte einging. Dieses Mal lag es aber nicht am Preis. Mit 900 Dollar war das Gerät zwar nicht gerade ein Schnäppchen, unbezahlbar war es aber auch nicht, und es gab durchaus viele Kunden, die sich für das Gerät interessierten. Die frühen Kunden stellten aber schnell ein großes Problem fest. Die Schrifterkennung des Newton funktionierte nicht vernünftig. Es war in der Praxis für viele Nutzer schlichtweg unmöglich, auf dem Newton Text einzugeben, selbst nach längerem Trainieren und Korrigieren der Fehleingaben. Mit dem Erscheinen der zweiten Version des Newton-Betriebssystems im Jahre 1996 wurde die ursprüngliche Schrifterkennung durch eine komplette Neuentwicklung ausgetauscht, die nun gerade auf neueren, leistungsfähigeren Newton-Geräten viel besser funktionierte. Zu diesem Zeitpunkt war der Ruf des Newton allerdings schon ziemlich ruiniert, was der ohnehin schwierigen Situation der Firma Apple zu diesem Zeitpunkt nicht zuträglich war. Mit der Rückkehr von Steve Jobs zu Apple im Jahre 1997 wurde die komplette Newton-Produktlinie eingestellt – und Jobs versprach, dass Apple nie wieder PDAs herstellen werde. Eine Aussage, die ihm bei der Einführung des iPad im Jahr 2010, noch vorgehalten werden sollte.

Palm Pilot – Der Zuverlässige

Zum Zeitpunkt, als der Newton eingestellt wurde, schickte sich ein anderer Hersteller an, den Markt zu erobern. Im Jahr 1996 erschien mit dem Palm Pilot das erste einer Reihe von kompakten Geräten, die üblicherweise unter dem Namen „Palm“ zusammengefasst wurden. Sie wurden bis weit in die 2000er hinein von verschiedenen Herstellern gebaut. Vergleicht man das erste Palm-Gerät, den Palm Pilot von 1996 mit einem Newton von 1993, scheint der Newton in jeder Hinsicht im Vorteil zu sein. Der Pilot hatte im Vergleich zum Newton einen geradezu winzigen Bildschirm mit nur 160 x 160 Bildpunkten, der zudem im Gegensatz zum Newton keine Graustufen anzeigen konnte. Auch der Palm wurde mit einem Stift bedient. Die Interaktion war allerdings viel weniger facettenreich als die des Newton.

Am offensichtlichsten wurde das vielleicht bei der Texteingabe. Beim Newton gab man den Text handschriftlich an der Stelle ein, an der er später auch erscheinen sollte. Beim Palm hingegen bediente man sich einer speziellen, „Graffiti“ genannten, Schrift, die man Buchstabe für Buchstabe in ein Feld unterhalb des Bildschirms hineinschrieb. Charakteristisch für die Graffiti-Schrift war, dass die Buchstaben eindeutig waren und in nur einem Zug geschrieben werden konnten. Von Seiten der Software waren die Palm-Geräte mit dem Angebot früherer kompakter, mobiler Geräte vergleichbar. Auch hier fand man ein Adressbuch, einen Kalender, eine Anwendung zum Festhalten von Notizen und To-Do-Listen. Bei späteren Software-Versionen war auch ein Programm zum Verfassen von E-Mails und zur persönlichen Finanzverwaltung mit dabei. Das Gerät war natürlich nicht auf diese Anwendungen beschränkt. Eine Liste von 2008 verzeichnet sage und schreibe 50.000 Software-Titel für Palm-PDAs. Auch hardware-seitig entwickelten sich die Geräte im Laufe der Jahre weiter. Man konnte Palms mit WLAN-, Mobilfunk- oder sogar GPS-Modulen erwerben.

Die Palm-Geräte waren erheblich weniger ambitioniert als Apples Newton, waren jedoch im Gegensatz zu diesem sehr erfolgreich am Markt. Die Einfachheit der Geräte und der Software dürften mit der Hauptgrund für den Erfolg gewesen sein, denn im Gegensatz zu Apples Newton hielt die Technik des Palm die Versprechen, die sie machte.

Windows CE – Der Herkömmliche

Der Vollständigkeit halber seien an dieser Stelle PDAs erwähnt, die mit dem Betriebssystem Windows CE betrieben wurden. Bei Windows CE handelte es sich um ein Betriebssystem von Microsoft, dessen Nutzungsschnittstelle der von Windows 95 stark ähnelte. So verfügte das System über eine Taskleiste und ein Startmenü. Auch die Anwendungen ähnelten denen des PCs. Die Systeme hatten einen Explorer, einen Pocket Internet Explorer, Pocket Word, Pocket Excel etc. Diese Software-Ausstattung machte die Geräte natürlich kompatibel zu den klassischen Dateiaustauschformaten der PC-Welt.

Die Nutzungsschnittstelle der PDAs mit Windows CE war erstaunlich schlecht an die mobilen Computer angepasst. Die Geräte wurden üblicherweise mit einem Stift bedient, doch selbst damit war es nicht immer einfach, sie zügig und fehlerfrei zu bedienen, denn die Objekte der Nutzungsschnittstelle waren zum Teil recht klein. Die Abstammung der Nutzungsschnittstellen des Betriebssystems und der Software aus der Software-Welt des PCs schlug sich auch an anderer Stelle nieder. Als eine ganz typische Eigenschaft von PDAs habe ich Ihnen inzwischen mehrfach das implizite Speichern erläutert. Bei den Palm-Geräten, beim Apple Newton, bei den PDAs von PSION und den vergleichbaren Geräten wurde dem Nutzer nicht abverlangt, die vorgenommenen Änderungen explizit zu speichern. Verwendete man auf den Geräten beispielsweise die Notizbuch-Funktion, machte eine Notiz, wechselte dann zum Kalender und machte dort einen Eintrag, um schlussendlich die Taschenrechner-Funktion aufzurufen, musste zu keinem Zeitpunkt explizit eine Speichern-Funktion aufgerufen werden. Jede Änderung wurde stets automatisch ohne Zutun des Nutzers gespeichert. Bei Windows CE verhielt es sich hingegen so, wie man es von Windows kannte. Machte man in Pocket Word eine Änderung an einer Textdatei, musste man die Datei explizit abspeichern, wenn man sie denn behalten wollte. PDAs mit Windows CE waren zwar einerseits sehr leistungsstark, denn sie waren in der Regel gut ausgestattet und boten eine große Software-Vielfalt, doch aus Sicht ihrer Nutzungsschnittstelle boten sie nichts Neues und waren für die Geräteklasse sogar in gewisser Weise ein Rückschritt.

Fazit

Die hier vorgestellten Personal Digital Assistants waren aus Sicht der Nutzungsschnittstelle sehr interessant. Die Geräte und ihre Software waren natürlich nicht so funktionsreich wie ihre Pendants aus dem PC-Bereich. Die kompakte Bauweise forderte in beiden Aspekten ihren Tribut. Die Nutzungsschnittstelle der Geräte war jedoch auch insofern interessant, als dass für diese neue Gerätegeneration beginnend mit dem PSION Organiser eine komplett neue Nutzungsschnittstelle entwickelt wurde. Die Nutzungswelten dieser kleinen Computer standen weder in der Tradition der WIMP-Interfaces von Xerox und Apple aus den späten 1970er bzw. frühen 1980er Jahren noch in der Tradition der terminal-orientierten Kommandozeilen der 1960er Jahre. Die besonderen Bedingungen ihres Einsatzes brachten eine neue Nutzungsweise und damit auch eine neue Nutzungsschnittstellen-Welt hervor.

Wie bereits oben beschrieben wurden PDAs im Laufe der Jahre um viele Fähigkeiten erweitert. Von Palm etwa gab es ab den frühen 2000er Jahren Geräte der Treo-Serie, die den klassischen PDA um ein GSM-Modul erweiterten. Die Geräte ermöglichten dadurch sowohl das Telefonieren als auch die Nutzung des Internets über den GPRS-Standard. Der PDA wurde so mehr und mehr zu dem, was wir heute „Smartphone“ nennen.

Smartphones

PDAs der Art, wie ich sie zuvor beschrieben habe, gibt es heute nicht mehr. Sie sind zusammen mit Geräten wie dem Mobiltelefon, mobilen Pagern und Kompaktkameras im Smartphone aufgegangen. Maßgebliche Entwickler von Nutzungsschnittstellen für Smartphones sind heute die Firmen Apple und Google. Während Apple mit dem Newton Erfahrung im Bereich der PDAs hatte, seine eigene PDA-Linie aber 1997, zehn Jahre vor der Einführung des iPhones einstellte, war Google bis dahin nicht im Bereich der Betriebssysteme und der Nutzungsschnittstellen für PDAs oder ähnliche Geräte tätig. Mit Nutzungsschnittstellen für Mobiltelefone hatten beide Firmen bis dahin nichts zu tun.

Man kann ein Smartphone in der Computergeschichte auf verschiedene Arten und Weisen betrachten, etwa als einen PDA mit einer hinzugefügten Mobilfunkoption oder als ein Mobiltelefon mit zusätzlichen PDA-Funktionalitäten. Auf verschiedene frühe Smartphones trifft bei genauerer Betrachtung mal mehr das eine, mal mehr das andere, mal noch eine andere Interpretation zu. Ein Beispiel für einen PDA mit hinzugefügten Telefon-Funktionen habe ich im vorherigen Kapitel kurz angerissen. Mit der Treo-Serie des Herstellers Handspring – einer Abspaltung von Palm, die später wieder mit ihrer Ursprungsfirma fusionierte – wurde dem PDA ein Telefonmodul hinzugefügt. Die Mobilfunk-Funktionalität beschränkte sich seinerzeit auf die reine Telefonfunktion. Erst im Jahre 2004 folgte ein Modell, das auch Daten über Mobilfunk empfangen und versenden konnte, das also Zugang zum Internet hatte. Im Jahr 2005 erschien dann ein Palm-PDA mit WLAN-Funktionalität. Es handelte sich dabei allerdings um einen reinen PDA ohne Telefonfunktion. Erst im Jahre 2008 war ein Palm-Smartphone verfügbar, das sowohl über WLAN als auch über Mobilfunk-Fähigkeiten verfügte.

Frühe Smartphones

Palm erweiterte seine PDAs mit den Mobilfunkmodulen zu Smartphones, war damit allerdings vergleichsweise spät dran. 2002 bereits erschien das erste Blackberry-Smartphone der Firma Research In Motion und bereits im Jahre 1996 brachte Nokia sein erstes Smartphone auf den Markt.

Nokia Communicator

Die Firma Nokia war viele Jahre lang Marktführer für Mobiltelefone. Im Jahr 2008, ein Jahr nachdem Apple sein iPhone vorstellte, erreichte der Marktanteil von Nokia fast 40 Prozent. Die Firma war zu diesem Zeitpunkt schon lange im Geschäft. Das erste Auto-Telefon der Firma wurde ab 1982 verkauft und das erste Mobiltelefon im heutigen Sinne, als einteiliges Gerät ohne separaten Hörer, wurde 1985 vorgestellt. Auch ein Smartphone hatte Nokia früh im Programm. Fast zehn Jahre früher als Palm bereicherte Nokia den Mobilfunkmarkt mit seinem ersten Communicator – dem Nokia 9000.

Der erste Communicator war für die Zeit ein erstaunliches Gerät. Auf den ersten Blick sah es aus wie ein normales Mobiltelefon der damaligen Zeit, wenn auch signifikant dicker und größer. Im oberen Bereich des Gerätes befand sich eine kleine LCD-Anzeige, darunter eine Nummerntastatur. Das Gerät verfügte über alle Funktionen, die auch ein einfaches Nokia-Telefon bot. Wirklich interessant wurde das Gerät, wenn man es aufklappte, denn dann eröffnete sich dem Nutzer ein PDA mit Telefon- und Internetanbindung. Die Bedienung der PDA-Funktionen erfolgte über eine kleine Tastatur. Der Bildschirm war für die damalige Zeit sehr ordentlich. Er verfügte über eine Auflösung von 640 x 200 Pixeln und konnte vier Graustufen anzeigen. Der Communicator bot die für PDAs bekannten Funktionalitäten, also etwa eine Anwendung für Notizen, einen Kalender, eine Kontaktverwaltung etc. Das Herausragende an dem Gerät waren nicht die PDA- oder die Mobilfunktion alleine, sondern ihre Kombination vor allem mit der Möglichkeit des Datenaustauschs über das Mobilfunknetz. Der Communicator erlaubte sowohl das Senden und Empfangen von E-Mails als auch von analogen Fax-Kopien. Auch Terminal-Verbindungen zu entfernten Rechnern ließen sich mit dem Gerät aufbauen und selbst ein Webbrowser stand zur Verfügung. Aus heutiger Sicht mag das nicht spektakulär klingen, doch muss man sich klarmachen, dass hier von einem Gerät von 1996 die Rede ist. Zu diesem Zeitpunkt war das World Wide Web in der allgemeinen Öffentlichkeit noch nicht sehr verbreitet. Kaum ein Nutzer von heimischen Computern oder Bürorechnern war an das Internet angebunden, und somit waren auch Webbrowser noch kaum verbreitet. Hier gab es nun einen – und das auf einem kompakten, mobilen Gerät!

Blackberry

Nokia bot schon sehr früh seinen Communicator an und entwickelte diesen auch stetig weiter. Die Marke stand aber nicht in erster Linie für diese leistungsstarken Geräte. Nokia bediente vor allem den Massenmarkt und hatte Mobiltelefone mit verschiedenen Ausstattungsmerkmalen im Angebot und verdiente damit sein Geld. Anders war die Lage bei der Firma Blackberry. Das Wort „Blackberry“ wurde Anfang der 2000er Jahre zu einem Äquivalent für das Wort Smartphone. Die meisten dieser Geräte wurden seinerzeit noch, ähnlich wie bei Nokias Communicator, nicht von Privatleuten, sondern vor allem von Handelsreisenden und Führungskräften verwendet. Blackberry bot eine starke Einbindung an die zentrale Infrastruktur der Firmen mit Funktionalitäten zur unternehmensweiten Kalender-, Mail- und Kontaktsynchronisation.

Der Ursprung der Smartphones der Firma Research In Motion (RIM) lag im Jahre 1996 in einem Gerät, das noch nicht den Namen „Blackberry“ trug. Der „Inter@ctive Pager 900“ war ein sogenannter Two-Way-Pager. Er nutzte frühe Mobilfunk-Datennetzwerke der USA. Pager waren damals unter Leuten, die immer erreichbar sein mussten, sehr verbreitet. Es gab sie in verschiedenen Ausführungen. Ganz einfache Geräte ermöglichten es nur, eine Telefonnummer anzuzeigen. Wollte man jemandem etwas auf einen Pager schicken, rief man die Telefonnummer des Pager-Dienstes an und gab dort die Nummer des Pagers und die Nummer dessen, der zurückgerufen werden sollte, an. Pager dieser Art haben Sie bestimmt schon einmal in Film und Fernsehen gesehen. Sie wurden zum Beispiel verwendet, um Ärzte „anzupiepsen“. Weiterentwickelte Geräte erlaubten auch das Anzeigen eines Mitteilungstextes oder gar die Wiedergabe einer Tonnachricht. In all diesen Fällen verlief die Kommunikation einseitig. Es handelte sich um reine Empfangsgeräte. Der Inter@active Pager 900 war im Vergleich zu diesen Geräten viel ausgereifter. Die Kommunikation fand über die Mobilfunk-Datennetzwerke über das Internet statt. Die Geräte erlaubten sowohl das Empfangen als auch das Versenden von Nachrichten über das Internet. Im Prinzip handelte es sich bei den Geräten um mobile E-Mail-Maschinen.

Die Firma RIM entwickelte ihre Pager zu Smartphones weiter, denen Sie den Namen „Blackberry“ gaben. Rechts abgebildet ist die erste Fassung dieser Geräte, ein Blackberry Quark aus dem Jahr 2003. Die E-Mail-Komponente war bei diesen Geräten nach wie vor sehr zentral. Blackberrys erlaubten sowohl den Mail-Versand über normale Internet-E-Mail-Konten als auch über Microsoft-Exchange-Server und später über eigene Server-Infrastrukturen. Um die E-Mail-Funktionalität herum bot der Quark sowohl die typischen Funktionen eines Telefons, also der Telefonfunktion mit Telefonbuch und der SMS-Funktion als auch die eines PDAs, von Notizen bis zum Kalender. Auch ein Webbrowser gehörte zum Funktionsumfang des Geräts. Palm entwickelte die Geräte in verschiedene Richtungen weiter. Das charakteristische Merkmal vieler Blackberrys blieb die voll ausgestattete Tastatur. Diese Geräte waren gerade bei den Nutzern, die viel E-Mail-Korrespondenz unterwegs verfassen wollten, sehr beliebt. Andere Blackberrys glichen mehr typischen Mobiltelefonen der Zeit, allerdings mit einer um einige Tasten erweiterte Zifferntastatur, die auch für Texteingabe genutzt werden konnte. Einzelne Tasten waren, ganz ähnlich wie bei einfachen Handys, mit mehreren Buchstaben belegt. Dass dennoch mit nur jeweils einem Tastenanschlag getippt werden konnte, lag an einer Technik namens SecureType, hinter der letztlich ein Wörterbuch von 35.000 Worten stand, die das Gerät an der Tastenfolge erkannte. Andere Telefonhersteller verwendeten die T9-Technik. die letztlich ähnlich funktionierte. Geräte wie der Blackberry Pearl von 2006 verfügten auch über einen Mediaplayer und eine integrierte Kamera mit 1,3 bis 2 Megapixeln Auflösung. Noch viel eingeschränkter als die Fotoauflösung war bei diesen Geräten allerdings die des Bildschirms mit nur 260 x 320 Pixeln.

Smartphone neu gedacht

Ich habe Ihnen oben grob einige Entwicklungslinien des Smartphones nachgezeichnet. Palm erweiterte seine PDAs um Mobilfunkfunktionalitäten, Nokia stattete ein Mobiltelefon mit zusätzlichen PDA-Funktionalitäten aus, und Blackberry entwickelte seine mobilen E-Mail-Maschinen zu Smartphones mit Telefon- und Organizer-Funktionalitäten weiter. Betrachten wir den Entwicklungsstand im Jahr 2008, hatten sich die Geräte durchaus angeglichen und verfügten alle über ein recht ähnliches Angebot, wobei die Ursprungscharakteristika immer noch sichtbar waren. Ein Blackberry hatte seine Stärken nach wie vor in der mobilen Nutzung von Textnachrichten, während ein Palm immer noch in erster Linie ein PDA war. All diese Smartphones waren keine Geräte für den Massenmarkt. Vor allem die Blackberrys waren teure Geräte für Manager. Sie waren eingebunden in Firmenstrukturen und hatten eine im Vergleich zu typischen Mobiltelefonen edle Anmutung. Ähnlich verhielt es sich aber auch mit den Geräten der anderen Hersteller. Auch sie richteten sich in erster Linie an Führungskräfte und Handlungsreisende.

Was man sich unter einem Smartphone vorstellte, änderte sich zu dieser Zeit aber grundlegend, denn im Jahr 2007 erschien das erste iPhone von Apple. Dieses Smartphone verfügte im Gegensatz zu den anderen Smartphones nicht über eine Tastatur, sondern über einen berührungsempfindlichen Bildschirm. Apple hatte sich seit der Rückkehr von Steve Jobs zehn Jahre zuvor stark verändert. Nicht mehr die Macintosh-Computer standen im Vordergrund des Interesses, sondern vor allem die mobilen Medienplayer namens iPod und die dazugehörige iTunes-Software, mittels derer Inhalte gekauft und auf den Player übertragen werden konnten. Die Herkunftslinie als Medienwiedergabegerät war beim iPhone klar ersichtlich und wurde auch explizit beworben. Bei der offiziellen Vorstellung wurde das neue Gerät als drei Geräte in einem vorgestellt. Gleich das erste dieser Geräte war demnach ein „Widescreen iPod with Touch Controls“. Das zweite Gerät, das „Revolutionary Mobile Phone“ erscheint mir von den drei genannten das uninteressanteste zu sein, denn außer einem interessanten neuen Ansatz für Mailbox-Nachrichten war hier nichts wirklich Revolutionäres zu sehen. Durchaus interessant war aber wiederum das „Breakthrough Internet Communication Device“. Neben der E-Mail-Funktionalität zielte dies vor allem auf den Webbrowser ab. Dessen herausragendes Feature war es, normale Websites anzeigen zu können. Die Webbrowser auf den meisten Smartphones konnten entweder nur extrem eingeschränkte, mobile Websites im sogenannten WAP-Standard anzeigen oder zeigten normale Websites auf ganz eigenwillige Art und Weise an, denn da es bis dahin keinen brauchbaren Standard für die mobile Darstellung gab und die Web-Nutzung auf Telefonen noch eine absolute Ausnahme war, waren die Designs nahezu aller Websites im Jahr 2007 auf die Darstellung in PC-Browsern ausgelegt. Das iPhone vermochte es, auch diese, nicht für Telefonnutzung gedachten, Seiten anzuzeigen und mit einer geschickt integrierten Zoom-Funktion sogar trotz des kleinen Bildschirms recht gut bedienbar zu machen.

Heute fast vergessen ist, dass das erste iPhone etwas noch nicht hatte, was später typisch für die neuen Smartphones wurde: Es gab noch keine installierbaren Apps. Wenn man das Gerät nicht mit einem sogenannten „Jailbreak“ hackte, gab es keine Möglichkeit, die mitgelieferten Anwendungen aufzustocken. Googles Betriebssystem Android, das sich bereits in Entwicklung befand, ermöglichte von Anfang an die Installation von Zusatzanwendungen. Als das erste Android Smartphone, das HTC Dream, allerdings im September 2008 erschien, war auch Apple schon so weit und hatte seinen App-Store eingeführt.

Die meisten Smartphones verwenden heute entweder Apples iOS oder Googles Android. Auf eine gewisse Weise betrachtet sind diese Systeme den PDAs der 1990er und frühen 2000er sehr ähnlich. Das erste iPhone etwa verfügte neben den Anwendungen zum Schreiben von SMS und MMS und der Telefonfunktion über einen Kalender, einen Fotobetrachter, eine Anwendung für Sprachnachrichten, ein klassisches Notizbuch, eine Uhr-Anwendung samt Wecker, eine Taschenrechnerfunktion und die Möglichkeit zur Musikwiedergabe. All diese Anwendungen waren mehr oder weniger auch das Standardrepertoire von PDAs. Hinzu kamen bei Apple natürlich die internetbasierten Anwendungen bestehend aus einem Webbrowser, einem Youtube-Player, Google-Maps, einer App für die Wettervorhersage und natürlich dem iTunes Store zum Kaufen von Musik. Auch die Bildschirmgröße und der Eingabefokus auf direktes Zeigen entsprach weit mehr den PDAs als den Smartphones der damaligen Zeit, die großteils auf kleine Hardware-Tastaturen setzten. Ein iPhone glich in der Bedienung viel mehr einem frühen Palm-PDA oder sogar einem Newton als einem Blackberry. Eine grundsätzliche Charakteristik der neuen Generation der Smartphones ist aber dann doch ganz anders als die der PDAs. Typische PDAs wurden mit einem PC verbunden, um Daten zu synchronisieren. Gut ausgestattete PDAs und Smartphones hatten zwar Möglichkeiten, über das Mobilfunknetz ins Internet zu gehen, taten das aber in der Regel eher selten. Wenn sie es doch taten, war die übertragene Datenmenge minimal. Dafür, dass das so war, sorgten unter anderem auch die exorbitanten Gebühren, die für die Internetnutzung im Mobilfunknetz damals erhoben wurden. Die neuen Smartphones waren im Prinzip von vorn herein darauf ausgelegt, dauerhaft online zu sein. Zwar können die Geräte auch offline verwendet werden, doch ein Großteil ihrer Funktionalität ist darauf ausgelegt, dass immer und zu jedem Zeitpunkt eine Internetverbindung vorhanden ist. Das Vorhandensein der Geräte auf dem Markt hatte somit auch starken Einfluss auf Verfügbarkeit und Bezahlbarkeit der Mobilfunk-Infrastruktur – ein schönes Beispiel dafür, wie sich verschiedene technische Entwicklungen und ihre Nutzungsweisen gegenseitig beeinflussen.

Die neue Generation der Smartphones reiht sich zwar durchaus in die Geschichte ihrer Vorgänger ein und erbt sowohl Eigenschaften vom PDA, vom klassischen Mobiltelefon und vom Pager. Mit den Geräten ist aber in vieler Hinsicht tatsächlich eine Art Revolution gelungen. Menschen, die sich nie für Computer interessierten, nie einen besaßen oder bei der Einrichtung und Wartung stets Hilfe brauchten, besitzen nun die kleinen, leistungsstarken Smartphones und können sie zumeist auch ziemlich kompetent bedienen. Für den Erfolg der Geräte gibt es viele Gründe. Zu ihnen gehört nicht, dass ein Smartphone technisch etwas Revolutionäres ermöglichen würde. Auch weist ihre Nutzungsschnittstelle keine besonderen Features auf, die man vorher gar nicht gekannt hätte. Sie ist vielmehr, wie schon beim PDA, vor allem im Vergleich zum PC extrem vereinfacht. Apps auf dem Smartphone haben in der Regel weniger Funktionen und Einstellungen als PC-Anwendungen. Ein wichtiger Erfolgsfaktor der Smartphones ist sicher auch, dass sie mit ihrer Hardware- und Software-Ausstattung, gepaart mit einem dauerhaft verfügbaren Internet, eine Vielzahl von Geräten ersetzen. Ein Smartphone ist heute weit mehr als ein Mobiltelefon und ein PDA. Es ist auch ein Diktiergerät, eine kompakte Kamera, ein Navigationsgerät, ein Wecker, eine Taschenlampe und vieles weitere mehr, und all das hat man in nur einem kleinen Gerät immer dabei.

Die Nutzungsschnittstelle eines Smartphones hat eine ganz andere Anmutung als die eines PCs. Ein Smartphone mit einem PC gleichzusetzen ist ähnlich unsinnig, wie die Betrachtung eines modernen Windows-PC als Minicomputer, wie wir sie aus den 1970ern kennen gelernt haben. Die Geräte mögen intern auf ähnliche Art und Weise funktionieren, doch die Nutzungsschnittstelle, die uns durch die Hardware, aber vor allem durch die Software angeboten wird, erzeugt eine ganz andere Nutzungswelt.

Der Vergleich Smartphone versus PC mit Personal Computer versus Minicomputer hinkt natürlich ein wenig, denn während Minicomputer von den Personal Computern inzwischen mehr oder weniger vollständig abgelöst wurden, ist das beim Smartphone so nicht zu erwarten. Zwar ist für viele Anwender der Funktionsumfang eines Smartphones für ihre Anwendungsfälle ausreichend, doch bleiben viele Nutzungsszenarien, in denen nicht nur der große Bildschirm eines PCs notwendig ist, sondern in denen auch die Flexibilität und der Funktionsreichtum der PC-Nutzungsschnittstellen gebraucht wird. Hinzu kommt noch, dass Smartphones und Tablets, vor allem die aus dem Hause Apple, den Nutzer in seiner Freiheit ziemlich einengen. Alternative Betriebssysteme zu installieren, ist, wenn überhaupt, nur mit hohem Aufwand möglich und die Apps kommen im Regelfall, bei Apple sogar ausschließlich, aus vom Hersteller kontrollierten App-Stores. Für das Programmieren, also das Erzeugen eigener Anwendungsprogramme nach den eigenen Vorlieben, sind die Geräte schon aus diesem Grund ebenfalls eher ungeeignet, und selbst wenn man eine offenere Architektur verwendet, will man sicher nicht auf einer Smartphone-Tastatur ein komplexes Programm entwerfen. Man würde hierfür wohl immer ein Gerät wie einen PC oder ein Laptop mit einer gut ausgestatteten Entwicklungsumgebung verwenden wollen, auch wenn das Programm am Ende auf einem Smartphone oder auf einem Tablet verwendet werden soll.

Total vernetzt

Bei allem, was ich Ihnen bisher in diesem Buch erzählt habe, habe ich ein riesiges Themenfeld sträflich ausgelassen. Dass Computer miteinander vernetzt sein können, war allenfalls bei den Smartphones ein Thema. Dabei wäre vieles, was wir heute mit Computern machen, ohne Vernetzung und vor allem ohne das “Netz der Netze” gar nicht mehr denkbar. Das Internet ist allgegenwärtig: Viele von uns sind ständig online - oft sogar mit mehreren Geräten gleichzeitig. Diese Allgegenwärtigkeit wird oft als Revolution empfunden, denn das Internet verändert viele Medien, die es seit Jahrzehnten oder gar Jahrhunderten gibt. Tageszeitungen und Zeitschriften haben seit Jahren zu kämpfen und auch das klassische lineare Fernsehen und das Radio bekommen es immer stärker zu spüren.

Je nach Alter erinnern Sie sich vielleicht noch an eine Zeit “vor dem Internet” oder Sie kennen Menschen, die Ihnen davon erzählen. Um welche Zeit handelt es sich dabei eigentlich? Seit wann gibt es das Internet? Die Beantwortung dieser Frage ist letztlich eine Frage der Definition. Im Jahr 1969 nahm das von der Advanced Research Projects Agency (ARPA), einer Abteilung des US-Verteidigungsministeriums, finanzierte und betriebene ARPAnet seinen Betrieb auf. Dieses Netz gilt als Keimzelle des späteren Internet. Die Verbindung zum Verteidigungsministerium erklärt sicherlich den Mythos, das Internet sei als atomkriegssicheres Computernetz für das Militär geplant worden. Zwar gab es durchaus Überlegungen zu einer ausfallsicheren Netzwerktechnik für das Militär, aber mit dem Internet und seinen Vorläufern hat das wenig zu tun. Auf der Karte sieht man das Layout des Netzes im Jahr 1973. Wenn man sich anschaut, was in den mit IMP oder TIP beschrifteten Rechtecken steht, sieht man, dass es sich nicht um militärische Einrichtungen handelt, sondern um Universitäten und andere Forschungseinrichtungen. Die ARPA hat sie über ihr Netzwerk miteinander verbunden. Sicherlich erhoffte man sich davon auch einen Innovationsschub in Forschungsbereichen, die eigentlich dem Militär vorbehalten waren, aber das Netzwerk beschränkte sich nicht darauf.

Der Zweck des ARPnet war es, den Zugriff auf die Großrechenanlagen der Forschungseinrichtungen zu ermöglichen und somit Ressourcen gemeinsam zu nutzen. Sich aus der Ferne mit einer Rechenanlage zu verbinden, war im Prinzip nichts Neues. Im Kapitel über Timesharing haben Sie bereits davon gelesen. Beim Timesharing wurden Fernschreiber und andere Terminals mit einem Zentralrechner verbunden. Dies konnte über ein direktes Kabel oder über eine Telefonleitung und ein Modem erfolgen. Beim Timesharing befindet sich auf der einen Seite der Verbindung ein Computer, auf der anderen Seite ein Terminal oder ein Fernschreiber. Mit der gleichen Technik können natürlich auch zwei Computer untereinander Daten austauschen.

Datenübertragung per Modem

Der Begriff Modem wird Ihnen in diesem Kapitel noch öfter begegnen. Lassen Sie mich also kurz vorab erklären, was das eigentlich ist. Modems werden gebraucht, wenn man zwischen Computern Daten austauschen möchte, dafür aber eine Leitung verwenden muss, die sich für binäre Datenübertragung – Strom an oder Strom aus – nicht eignet. Modems wandeln die digitalen Daten des Computers in hörbare Töne um¹, die per Telefonleitung übertragen werden. Auf der anderen Seite der Verbindung befindet sich ebenfalls ein an einen Computer angeschlossenes Modem. Dort werden die Töne, die für den Menschen nur ein unangenehmes Kreischen darstellen, wieder in digitale Daten umgewandelt, die der Computer verarbeiten kann. Oben sehen Sie einen Akustik-Koppler, ein einfaches Modem für die Übertragung von Computerdaten über eine Telefonleitung. Auch bei so einem Akustik-Koppler werden die digitalen Daten des Computers in hörbare Töne umgewandelt. Ein Computernutzer, der Daten übertragen will, hebt den Hörer ab und wählt die Nummer einer Gegenstelle, die mit einem Computer verbunden ist. Kommt die Verbindung zustande, legt er den Hörer in den Akustik-Koppler. Der Vorteil von Akustik-Kopplern ist, dass man nichts an der Verkabelung des Telefonanschlusses ändern muss, sondern sein normales Telefon verwenden kann. Es gibt aber zwei Nachteile: Zum einen ist das Ganze etwas umständlich, weil man händisch wählen muss. Vor allem aber stören Geräusche aus der Umgebung die Übertragung. Professionellere Modems wurden unter Umgehung des häuslichen Telefons direkt an die Telefonleitung angeschlossen, was sowohl praktischer ist als auch schnellere Verbindungen ermöglicht.

Pakete im Netz

Ruft man einen entfernten Computer mittels Modem an, besteht eine dauerhafte Verbindung. Ein großflächiges Computernetz kann man auf diese Art und Weise aber nicht gut aufbauen, denn so viel Kapazität, um alle Rechner mit allen anderen dauerhaft zu verbinden, hat auch das beste Telefonnetz nicht. Es wäre auch absolute Verschwendung, denn mit den allermeisten Netzwerkteilnehmern möchte man ja nicht dauerhaft Daten austauschen. Eine andere Lösung muss her.

Die Idee hinter dem Internet beruht darauf, dass einzelne Computer nicht mit allen anderen, sondern immer nur mit einigen wenigen verbunden sind, die dann wiederum mit anderen verbunden sind und so weiter. Hinzu kommt die sogenannte Paketvermittlung. Sie können sich beides mit einer Analogie erklären, denn das Internet funktioniert weniger so wie das klassische Telefonnetz, sondern ist eher mit der Paketpost vergleichbar. Stellen Sie sich vor, Sie besitzen einen Oldtimer. Diesen wollen Sie mit der Post an einen Freund verschicken. Das ganze Auto verschickt die Post aber nicht. Es ist viel zu groß. Sie nehmen das Auto also kurzerhand auseinander, packen die Einzelteile in Pakete, legen jeweils einen Zettel mit dazu, wie die Teile wieder zusammenzusetzen sind, und bringen die einzelnen Pakete zur Post. Die Pakete werden nun von der Post nicht direkt zum Zielpostamt gebracht. Dann müssten ja zwischen allen Postämtern ständig Transporter hin und her fahren. Das wäre nicht effizient. Das lokale Postamt schickt ein Paket stattdessen an ein Verteilzentrum. Dieses schickt das Paket entsprechend der Zieladresse an ein anderes Verteilzentrum weiter. Je nach Entfernung wiederholt sich der Vorgang einige Male. Da Sie ja mehrere Pakete verschicken, könnte es durchaus sein, dass das eine Paket eine bestimmte Route nimmt, ein anderes Paket aber auf einem anderen Weg ankommt. Letztlich ist der Weg, den die Pakete genommen haben, aber ganz egal. Wichtig ist, dass alle Pakete am Ziel ankommen und das Auto am Zielort wieder zusammengesetzt werden kann.

Ganz vergleichbar funktioniert auch das Internet. Wenn Sie eine Datei auf einen Server hochladen, dann wird sie in viele kleine Teile zerlegt. Diese werden dann über ein Geflecht von Verteilerrechnern, den sogenannten Switches, bis zum Ziel geschickt und dort wieder zusammengesetzt.

Natürlich konnte nicht nur die ARPA Netze betreiben, die auf diese Art und Weise funktionierten. 1981 nahm die National Science Foundation (NSF) das Computer Science Network in Betrieb. 1986 kam dann das allgemeinere NSFNet dazu. Durch die Verbindung der Netze der NSF mit dem ARPAnet und dem Anschluss internationaler Netze an das NSFNet entstand ein Netz, das die Netze verband, ein Zwischen-Netz, ein Inter-Net. Dieser Begriff wurde Mitte bis Ende der 1980er Jahre immer gebräuchlicher. Das Internet ist also fast 40 Jahre alt oder, je nach Sichtweise, auch schon über 50 wenn man das ARPAnet als Anfang nimmt. Es kommt ganz darauf an, was man als den Anfang ansehen möchte.

Sprechen die Leute, die von der Zeit vor dem Internet sprechen, also von den 1960er oder 1970er Jahren? Möglich ist das natürlich, aber auch viel spätere Zeitpunkte können durchaus gemeint sein, denn das Internet und die Netze, aus denen es hervorgegangen ist, waren bis in die 1990er Jahre hinein der breiten Öffentlichkeit und auch in der Privatwirtschaft gar nicht bekannt. In einem Bericht des ARD-Magazins Panorama von 1987 über die Tätigkeiten deutscher Hacker des Chaos Computer Club[s] ist nur allgemein von einem “Internationalen Netzwerk” die Rede. Der Begriff “Internet” hätte wohl keinem etwas gesagt. Ein Bericht des ZDF Morgenmagazins aus dem Jahr 1996 behandelt die Frage “Was ist denn Internet überhaupt?”. Von NBCs Today Show aus Amerika gab es 1995 aus heutiger Sicht Kurioses zu sehen: Der Moderator der Sendung weiß nicht, wie man das a mit dem Kringel drumherum nennt und lässt sich zur verzweifelten Frage “What is Internet anyway?” hinreißen. Seine Kolleginnen und Kollegen können ihm auch nicht so recht weiterhelfen. Erst ein Assistent aus dem Off meint zu wissen, dass es sich um ein “Computer Billboard” handelt, also um ein computerisiertes Schwarzes Brett. Wenn Leute also von “vor dem Internet” sprechen, dann kann das durchaus auch die 1980er und die erste Hälfte der 1990er Jahre einschließen. Kaum jemand, der nicht an einer Universität oder Forschungseinrichtung damit zu tun hatte, kannte damals das Internet und auch für diese Leute hatte es keine so dominante Rolle wie heute.

Die spannende Geschichte des Internet umfangreich und vollständig zu erzählen, schaffe ich hier natürlich nicht. Ich empfehle Ihnen sehr, wenn es Sie interessiert, sich das Buch “ARPA Kadabra”² zu besorgen. Darin erfahren Sie alle technischen und nicht technischen Hintergründe und lernen die Protagonisten hinter der Entwicklung kennen. In diesem Buch fokussiere ich mich, was das Internet angeht, auf eine eher späte, aber sehr dominante Entwicklung, mit der das Netz öffentliche Wahrnehmung bekam – dem World Wide Web. Doch bevor wir dort hinkommen, gilt es, andere Vernetzungsprojekte zu betrachten, denn auch “vor dem Internet”, in den späten 1970er Jahren und in den 1980ern, konnte man bereits online gehen und einige dieser frühen Online-Dienste hatten sogar eine Nutzerschaft, deren Zahl in die Millionen ging.

Bildschirmtexte und Online-Dienste

Lassen Sie uns eine Zeitreise ins Jahr 1985 machen! Nicht politisch, nicht modisch, sondern in Sachen Computern und Kommunikationstechnik. Grundsätzlich hat sich natürlich technisch in allen Bereichen seit 1985 viel getan. Dennoch hätten wir bei unserer Zeitreise wahrscheinlich keine Probleme. Lassen wir mal die Computer beiseite, war das meiste nicht so sehr anders als heute. Genau wie heute gab es Autos und die hatten auch schon ein Lenkrad, ein Zündschloss und drei Pedale. Auch Züge und Flugzeuge gab es natürlich schon. Die Flugzeuge und Züge von 1985 funktionierten im Prinzip genauso wie heute und könnten durchaus auch heute noch betrieben werden. Das gleiche gilt auch für ein Radio oder einen Kugelschreiber. Mit all diesen Dingen hätten wir bei unserer Zeitreise kaum Probleme. Selbst mit einem Fernseher der damaligen Zeit kämen wir wahrscheinlich zurecht, obwohl es sich damals um recht wuchtige Geräte mit erstaunlich kleinem Bild handelte, die meisten Leute nur drei Programme empfangen konnten und viele Fernseher noch keine Fernbedienung hatten. Wo wir durchaus umdenken müssten, wäre der Bereich Telekommunikation. Dass man nicht whatsappen konnte, haben Sie sich wahrscheinlich schon gedacht. Smartphones gab es natürlich noch nicht. Darüber haben wir ja schon gesprochen. Das erste Mobiltelefonnetz für die größere Allgemeinheit, das analoge C-Netz, gab es erst ab 1986. Wenn wir also jemanden von unterwegs erreichen wollten, dann mussten wir uns eine Telefonzelle suchen. Die waren damals postgelb und standen an jeder Ecke. Das C-Netz wurde, genauso wie das “öffentliche Fernsprechnetz” – heute sagt man Festnetz dazu – und die Telefonzellen, von der Post betrieben.

Als jüngerer Leser mögen Sie jetzt stutzen. Was hat denn die Post mit Telefon und Mobilfunk zu tun? Heute nichts mehr, im Jahr 1985 jedoch sehr viel. Die Post hieß damals noch Bundespost. Das klingt nicht nur sehr offiziell, das war es auch. Es handelte sich um eine Bundesbehörde. Alles was mit der Post zu tun hatte, war also eine hoheitliche Angelegenheit. Die Briefträger und Paketzusteller der Bundespost waren Postbeamte und wollte man ein Paket aufgeben, tat man das nicht in irgendeiner Geschäftsstelle, sondern in einem Postamt. Den Paket-, Päckchen- und Briefdienst der Bundespost kennen Sie heute unter dem Namen Deutsche Post und zum Teil unter dem Namen DHL. Die Bundespost hatte aber viele weitere Aufgaben als das Verschicken von Briefen, Päckchen und Paketen. Zur bereits vorgestellten, sogenannten “gelben Post” kamen die sogenannte “blaue Post” – die Postbank – und die “graue Post”, die die Dienste für die elektronische Kommunikation vereinigte. Hierzu gehörte das genannte “öffentliche Fernsprechnetz”, ein Netz für Fernschreiber, Telex genannt, aber auch alle nennenswerten Rundfunk- und Fernsehsender. Sicher kennen Sie auch bei sich in der Gegend einen Rundfunk- und Fernsehturm³ oder eine große Antenne auf einer Anhöhe. Wenn Sie in Westdeutschland wohnen, wurde dieser Turm wahrscheinlich von der Bundespost errichtet und betrieben.

1995 wurde die Deutsche Bundespost privatisiert und in drei Aktiengesellschaften (Deutsche Post AG, Postbank AG und Deutsche Telekom AG) aufgespalten. Daran hat man 1985 aber noch nicht gedacht. Noch war Kommunikation in allen Bereichen eine staatliche Angelegenheit, denn die Bundespost hatte ein staatliches Monopol. Im Bereich der Briefe mag das nicht so einen großen Unterschied gemacht haben, aber in der Welt der Telekommunikation hatte dieses Monopol für die heutige Zeit eigenartige Konsequenzen. Das Telefon in meiner Familie, zum Beispiel, war im Jahr 1985 eines mit Wählscheibe⁴. Es stand im Flur auf einem kleinen Tischchen. Das Kabel des Telefons ging direkt in eine Dose an der Wand. Es gab keinen Stecker und auch keine Buchse. Man konnte das Telefon also nicht einfach austauschen oder außer Betrieb nehmen. Das war nicht nur schwer möglich, es war sogar verboten. Die Fernmeldeordnung bestimmte klar: “Der Teilnehmer darf die Teilnehmereinrichtungen nicht eigenmächtig ändern; unzulässig ist auch das eigenmächtige Einschalten selbstbeschaffter Apparate.” Unser Telefon war also natürlich kein selbstbeschaffter Apparat. Wie fast alle hatten wir es bei der Post gemietet und eigenmächtig haben wir es auch nicht angeschlossen. Ein Techniker der Bundespost hat dies getan.

Ähnlich wie in Deutschland war es überall in Westeuropa. In Österreich gab es die Österreichische Post- und Telegraphenverwaltung, in den Niederlanden die PTT (Staatsbedrijf der Posterijen, Telegrafie en Telefonie). In Frankreich hieß das staatliche Unternehmen DGT (Direction Générale des Télécommunications). Die Telekommunikation in Europa Mitte der 1980er Jahre war also geprägt durch ihre zentralisierte Struktur, betrieben durch meist staatliche Post- und Telekommunikationsunternehmen, die in ihrem Markt ein Monopol hatten. Das konnte ein Vorteil sein, konnte aber auch zum Nachteil werden. Beides werden wir sehen, wenn wir uns die europäischen “Vorgänger des Internets” ansehen. Der Beginn zu dieser Technik - der Videotext – lag in England und hatte erstmal gar nichts mit der Post oder mit Telefonleitungen zu tun.

Begriffsverwirrungen: Was in Deutschland vor allem von ARD und ZDF Videotext genannt wird, wird im internationalen Rahmen meist Teletext genannt. Videotex (ohne t) hingegen ist die internationale Bezeichnung für Dienste wie der deutsche Bildschirmtext, den ich Ihnen weiter hinten vorstelle. Um die Verwirrung komplett zu machen, gab es in Deutschland auch noch Teletex (ohne t) als modernere Variante des Fernschreibdienstes, der seinerseits Telex genannt wurde. Um es mir und Ihnen ein bisschen einfacher zu machen, verwende ich durchgehend die deutschen Begriffe Videotext und Bildschirmtext auch für die anderen europäischen Informationsdienste.

Eine Lücke geschickt ausgenutzt: Der Videotext

Techniker der BBC ersannen in den 70er Jahren eine Technik, um gleichzeitig mit dem Fernsehprogramm, quasi Huckepack im gleichen Sendesignal, textuelle Informationen auszuliefern. Der Dienst Ceefax (für “see facts”) ging dort bereits 1974 in den Regelbetrieb. Die private Konkurrenz ging wenig später an den Start und hieß Oracle. In Deutschland dauerte es etwas länger. Hier war man 1980 soweit.

Um es zu bewerkstelligen, neben dem normalen Fernsehbild und dem Ton auch noch ein textuelles Informationsprogramm auszuliefern, nutzte man eine Eigenschaft des Bildsignals aus, das seinerseits aufgrund einer technischen Notwendigkeit bestand. Um das Prinzip zu verstehen, muss man sich klarmachen, wie ein altes analoges Fernsehsignal an einem alten Röhrenfernseher dargestellt wird.

So ein Fernseher verwendet eine Kathodenstrahlröhre, um ein Bild anzuzeigen. Meist wird sie der Einfachheit halber Bildröhre genannt. Im hinteren Teil der Bildröhre, da wo sie ganz dünn wird, wird ein Elektronenstrahl erzeugt, der vorne auf dem eigentlichen Bildschirm auf eine Substanz trifft, die er zum Leuchten anregt. Mittels durch Spulen erzeugte Magnetfelder kann der Strahl umgelenkt werden, sodass verschiedene Bereiche des Bildschirms erreicht werden können. Damit man mit einer solchen Röhre ein flächiges Bild sieht, müssen alle Bereiche des Bildschirms von einem sehr kräftigen Elektronenstrahl regelmäßig getroffen werden. Dies geschieht beim Fernseher (und auch bei Computermonitoren) Zeile für Zeile von oben nach unten und von links nach rechts.

Stellen wir uns den Vorgang zur Verdeutlichung in einem Gedankenexperiment vor. Wir simulieren die Bilddarstellung eines Schwarz-Weiß-Fernsehers. Sie sind der Fernsehempfänger und ein Bekannter von Ihnen spielt den Fernsehsender. Er sendet Ihnen ein Bild, indem er eine Ihrer Hände ergreift und unterschiedlich stark zudrückt. In Ihrer anderen Hand halten Sie einen Stift mit einer breiten Spitze. Diesen Stift ziehen sie nun zeilenweise über ein Blatt Papier. Sie fangen in der ersten Zeile oben links an. Je stärker Sie den Stift auf das Papier drücken, desto dunkler wird es. Sie drücken immer genauso stark mit dem Stift auf das Papier, wie Ihr Bekannter Ihre Hand drückt. Dabei bewegen Sie den Stift gleichmäßig weiter. Wenn Sie am Ende einer Zeile angekommen sind, geht es in der nächsten Zeile weiter. Wenn das Blatt voll ist, haben Sie auf diese Weise ein komplettes Bild gezeichnet. Sie reißen das Blatt ab und fangen direkt oben wieder mit dem nächsten Bild an. Auf diese Art und Weise kann Ihnen ihr Bekannter eine Reihe von Bildern übertragen. Wenn das ganze schnell genug vonstatten ginge, entstünde dabei der Eindruck eines bewegten Bildes. Beim klassischen Fernsehen wurden so seinerzeit 25 Bilder in der Sekunde übertragen⁵.

Bilder können Sie auf diese Weise nun übertragen. Das Bild interessiert uns aber eigentlich gar nicht so sehr, denn es geht uns ja um den Text. Für den ist viel interessanter, was passiert, wenn gerade kein Bild übertragen wird. Das passiert bei unserem Gedankenexperiment, ohne dass ich es erwähnt hätte, ziemlich oft. Immer wenn eine Zeile voll ist, zum Beispiel, brauchen Sie ein klein bisschen Zeit, um den Stift an den Anfang der Folgezeile zu bewegen. Diese Zeitspanne ist nicht besonders lang. Länger dauert es dann schon, wenn ein ganzes Bild fertig ist. Sie müssen dann das fertige Bild abreißen und dann mit Ihrer Hand wieder nach oben links gehen. Während dieser Zeit können Sie kein Bild zeichnen. Man spricht beim Fernsehen hier von der vertikalen Austastlücke⁶. Ihr Bekannter hat in dieser Zeit aber ja immer noch Ihre Hand fest im Griff, kann Ihnen also etwas senden, Sie können damit aber nichts anfangen, denn Sie können es ja nicht zu Papier bringen. Diese Lücke, während derer kein Bild gezeichnet werden kann, macht man sich beim Videotext zu Nutze, indem man im Bildsignal digitale Daten unterbringt. Im Bild oben rechts wurde das Fernsehbild vertikal verschoben, sodass man die Austastlücke sieht. Die weiße, etwas unruhige Linie vor dem Beginn des Bildes ist das Ceefax-Signal der BBC.

Die Inhalte des Videotexts der BBC wurden von einer Redaktion beim Rundfunksender bereitgestellt. Typische Inhalte waren Nachrichten, Wetterberichte oder Sportergebnisse. Die Möglichkeiten der Darstellung waren der Technik der späten 1970er Jahre und Röhrenfernsehtechnik mit einer für heutige Verhältnisse niedrigen Auflösung entsprechend. Eine Seite bestand aus 24 Zeilen à 40 Zeichen. Ursprünglich standen nur acht Farben jeweils für Vordergrund und Hintergrund zur Verfügung. Bei diesen acht Farben handelt es sich um die Grundfarben und ihren Kombinationen, also Rot, Grün, Blau, Gelb, Cyan, Magenta, Schwarz und Weiß. Jede Seite verfügte über eine Nummer. Die nummerierten Seiten wurden vom Fernsehsender nach und nach ausgestrahlt. Man konnte an einem Fernseher mit Videotext-Decoder eine dreistellige Nummer eingeben und musste dann warten, bis die entsprechende Seite wieder gesendet wurde. Sie wurde dann dekodiert und angezeigt. Besonders wichtige Seiten, wie etwa die Übersichtsseite 100 oder Untertitel für das aktuell laufende Programm, wurden häufiger übertragen als andere, damit sie schneller aufgerufen werden konnten und häufiger aktualisiert wurden. Im Laufe der Jahre verbesserte sich die Videotext-Technik ein wenig. Mehr Farben wurden verfügbar und auch die Grafikfähigkeiten wurden etwas besser. Videotext behielt aber bis heute den Charme der 1970er und 1980er Jahre.

Trotz all seiner Einschränkungen kann man den Videotext in manchen Bereichen als altmodischen Vorgänger von Websites ansehen, denn man kann ihn ganz ähnlich nutzen. Statt im Web-Angebot der Tagesschau nach den aktuellen Nachrichten zu schauen, konnte man die entsprechende Videotextseite aufrufen und die Nachrichten lesen. Was beim Videotext aber natürlich gar nicht funktionieren kann, ist alles, was über die Seitenauswahl hinaus auf Eingaben des Nutzers basiert, denn einen Rückkanal gibt es ja nicht. Man könnte im Videotext also nie eine individuelle Fahrplanauskunft von Start- und Zielbahnhof realisieren. Es kann lediglich innerhalb der begrenzten Menge an Seiten, die übertragen wird, etwas ausgewählt werden. Diesen Nachteil kann man dadurch abschaffen, dass man das Übertragungsmedium ändert, also die Seiten nicht per Fernsehantenne, sondern z. B. per Telefonkabel ins Haus kommen lässt.

Prestel in Großbritannien

Genau das hat das UK Post Office Telecommunication, seit 1981 unter dem Namen “British Telecom”, getan und unter dem Namen “Prestel” ab 1979 angeboten. Prestel stand als Abkürzung für “press telephone”. In Sachen Darstellung hatte Prestel genau die gleichen Eigenschaften wie der Videotext. Seiten mit 24 Zeilen à 40 Zeichen konnten in acht Farben dargestellt werden. Über die Telefonleitung gab es nun aber einen Rückkanal, sodass ein Computer der British Telecom auf der anderen Seite Eingaben verarbeiten und entsprechend antworten konnte. Diese Antwort musste nicht immer eine komplette neue Seite sein. Viewdata, wie der Videotext- und Prestel-Standard betitelt wurde, verfügte über Cursor-Control-Character. Dadurch konnte durch Signale vom Postcomputer die angezeigte Seite in Teilen aktualisiert werden, ohne sie komplett neu laden zu müssen. Hiermit wurden sogar simple Animationen möglich. Was spannend klingt, war in der Praxis wohl ziemlich langweilig. Wirklich interaktive Dienste blieben die Ausnahme. Größtenteils bestand der Prestel-Dienst aus Seiten, die ganz ähnlich wie der Videotext mit einer Nummer aufgerufen wurden. Auf den Seiten gab es dann Verweise auf Unterseiten, die über ein Nummernpad aufgerufen werden konnten. Im Prinzip bot Prestel damit nicht viel mehr als das, was es schon im Videotext gab – allerdings mit einer größeren Ausrichtung auf geschäftliche Daten, wie etwa Aktienkursen. Ab 1983 kam das Feature hinzu, anderen Teilnehmern Nachrichten schicken zu können.

Wenn man der Darstellung von History Today glauben kann, kostete der günstigste Prestel-taugliche Fernseher im Jahr 1985 650 Britische Pfund. Umgerechnet auf das Jahr 2020 sind das 2320 Euro. Hinzu kamen Kosten von etwa 6 Euro pro Monat, tagsüber zusätzlich 6 Cent pro Minute zusätzlich zu den Telefonkosten und ggf. Sonderkosten für einzelne Seiten. Im Vergleich zum Btx in Deutschland, das ich Ihnen etwas später vorstellen will, war das gar nicht so viel, aber im Vergleich zum Videotext, der zwar einen etwas teureren Fernseher brauchte, aber ansonsten kostenfrei war, war Prestel ziemlich teuer. Ein Erfolg war der Dienst nicht. Über 90.000 Teilnehmer kam er nie hinaus.

Minitel/Télétel in Frankreich

Der Prestel-Dienst bot einer allgemeinen Öffentlichkeit im Prinzip die Möglichkeit, Computerdienste ohne größere Hürden zu nutzen. Besonders populär wurde der Dienst aber auf Grund des langweiligen Angebots nicht. Ganz anders sah das in Frankreich aus, und dass das so war, lag an Entscheidungen des französischen Staats in Form des staatlichen Kommunikationsunternehmens DGT (Direction Générale des Télécommunications).

Zu Beginn der 1980er Jahre befand der französische Staat die Kommunikationsinfrastruktur des Landes für veraltet. Dies galt es zu ändern. Ein modernes Telefonnetz sollte aufgebaut werden. Teil dieses Netzes sollte ein Bildschirmtextdienst mit dem Namen Télétel werden. Technisch orientierte sich die DGT am englischen Viewdata-Standard, den sie leicht verbesserte. Maßgeblich für den späteren großen Erfolg des Dienstes waren aber nicht diese technischen Verbesserungen, sondern die Entscheidung, jedem Teilnehmer ein kleines Zugangsgerät kostenfrei zur Verfügung zu stellen. Wenn man in Frankreich einen Telefonanschluss hatte, konnte man sich fortan entscheiden, ob man ein normales Telefonbuch oder ein solches Minitel haben wollte, mit dem sich Telefonnummern natürlich viel praktischer herausfinden ließen. Und das beste: Das Ganze war sogar kostenfrei! Durch diesen Trick brachte die DGT ihr Télétel in viele Haushalte. Da der Dienst so sehr mit den Zugangsgeräten, den Minitels, verbunden wurde, wurde der Begriff Minitel im Volksmund und auch in der Werbung zum Namen für den Dienst als Ganzes. “Faites-le en Minitel!” war die Devise! 1985 hatte der Dienst bereits 2 Millionen Nutzer. Anfang der 1990er waren es 6,5 Millionen und im Jahr 2000 erreichte der Dienst mit 25 Millionen Nutzern sein Maximum. Bei 55 Millionen Einwohnern sind dies mehr als beeindruckende Zahlen.

Auch wenn die Technik für die Datenübertragung und Darstellung dem britischen Prestel sehr ähnlich war, gab es in der praktischen Anwendung doch starke Unterschiede. Das britische System war in seinen Grundzügen zentralistisch. Der große Teil der Inhalte war auf Rechnern der British Telecom abgelegt. Mittels eines sogenannten Suchbaums navigierte man durch diese Seiten. Vereinzelt gab es Computer externer Dienstleister, die über das System erreichbar waren, etwa für Fahrkartenbuchungen und Online-Banking, aber das war eher die Ausnahme. In Frankreich hingegen waren externe Dienstleister der Normalfall. Die DGT bot zwar auch ein paar eigene Dienste an, war aber ansonsten größtenteils lediglich Vermittler.

Télétel konnte über verschiedene Einwahlnummern erreicht werden, die für den Nutzer mit verschiedenen Kosten verbunden waren. Die Preise in der folgenden Aufstellung entstammen dem Gebührenkatalog von 1994.

• Unter 3611 erreichte man das Telefonbuch. Drei Minuten konnte man diesen Dienst kostenfrei nutzen, was für die allermeisten Nummernrecherchen sicher ausgereicht hat. Wenn nicht, konnte man einfach auflegen, sich neu einwählen und bekam wieder drei freie Minuten.
• Für die Services auf 3613 mussten von Kundenseite nur die normalen Telefonkosten aufgebracht werden. Diese beliefen sich auf 7,80 Francs pro Stunde (heute etwa 2,10 Euro). Die Kosten für den Télétel-Dienst selbst trug hier der Anbieter.
• Bei 3614 war es umgekehrt. Hier zahlte der Anbieter nichts, aber der Kunde musste 21,90 Francs pro Stunde aufbringen (entsprechend 6,40 Euro).

Ab 1984 wurden diese Zugangsnummern um die “Kiosque”-Dienste erweitert. Dieser Name kam nicht ganz von ungefähr. Unter der zunächst eingeführten 3615 sollten zunächst nur Presseangebote zu finden sein. Schnell kamen auch andere Anbieter dazu – teils auf 3615, andere dann auf 3616 oder 3617. Wählte man sich hier ein, wurde man nach einer Kennung für den Dienst, den “code du service” gefragt. Dieser Code war bei Télétel in der Regel ein Wort. Mit den Diensten, die so erreichbar waren, waren dann Kosten von 50 Francs pro Stunde bis zu mehreren Hundert Francs pro Stunde verbunden. Das Geld haben sich France Telecom und der Anbieter geteilt. Bei einem klassischen 3615-Angebot mit 60 Francs pro Stunde gingen 20 Francs an die Telecom und 40 Francs an den Anbieter. Der Kiosque machte den Dienst für Presse- und Diensteanbieter sehr attraktiv, erlaubte er doch, Artikel und Informationen bereitzustellen und für diese bezahlt zu werden, ohne dass zwischen jedem Kunden und dem Anbieter ein Vertrag abgeschlossen werden musste und ohne dass man jeweils Kunden-Logins brauchte, so wie es heute im Web nötig ist, wenn man die Bezahlangebote von Zeitungen und Zeitschriften im Netz nutzen möchte. Im Télétel-Kiosque brauchte es das nicht. Das Geld für die Nutzung kam automatisch von der France Télécom und die holte es sich vom Kunden über die Telefonrechnung mit Aufschlag zurück.

Durch den niedrigschwelligen Einstieg mit den “verschenkten” Geräten und dem im Prinzip kostenlosen Telefonbuch-Dienst wurden die Minitels sehr erfolgreich. Auch die angebotenen Dienste wurden teils sehr beliebt. Wer als Firma, als Bank oder Versicherung etwas auf sich hielt, musste im Kiosque verfügbar sein. Schaut man sich französische Werbung der 1980er und 1990er an, sah man daher an allen Ecken Angaben wie “3615TOYOTA”. Doch nicht nur die klassische Wirtschaft und Presse hatten Interesse an Minitel. Viele Angebote für Horoskope, Telespiele, Jobvermittlungen und nicht zuletzt Erotikangebote und die sogenannte “Messagerie”, also das Chatten, machten das Minitel beliebt und zogen manchem Franzosen und mancher Französin das Geld aus der Tasche.

Frankreich war stolz auf sein Minitel und hielt lange daran fest. Selbst als das Web schon durchaus verbreitet war, verwendeten viele Franzosen gerne weiter die kleinen Terminals, eben weil sie so gut funktionierten, man keinen Computer und keine damit auch keine Computerkenntnisse brauchte und weil viele Dienste dort schnell und einfach verfügbar waren. 2012 war es dann aber doch soweit. Télétel samt dem Telefonbuchdienst und dem Kiosque wurden eingestellt.

Bildschirmtext (Btx) in Deutschland

Télétel in Frankreich mit seinen günstigen Minitel-Geräten war ein großer Erfolg – ein so großer sogar, dass die Minitel-Popularität die Verbreitung des Web in Frankreich zunächst hemmte. Gerade aus Sicht der Anbieter ist das verständlich, denn die Möglichkeit, sehr einfach Dienste gegen Geld anzubieten, bot das Web so damals nicht und tut es an sich auch heute noch nicht.

In Westdeutschland entwickelte die Bundespost einen grundsätzlich vergleichbaren Dienst. Hier sah die Sache aber ganz anders aus. Sprichwörtlicher deutscher Perfektionismus und Bürokratie verhinderten einen Erfolg wie in Frankreich. Doch fangen wir von vorne an.

Der Dienst Bildschirmtext der Deutschen Bundespost, kurz Btx, ging nach einer Testphase in Berlin und Düsseldorf 1983 bundesweit an den Start. Das Angebot war ähnlich wie das britische Prestel hierarchisch organisiert mit vielen Informationsseiten und Unterseiten, die auf Rechnern der Bundespost gespeichert wurden. Auch externe Diensteanbieter wie Banken, Dienste der Bundespost selbst sowie Fahrplan- und Fahrkartendienste der Bundesbahn waren erreichbar. Auch einen Mitteilungsdienst gab es. Grundsätzlich sind dies gute Voraussetzungen für einen erfolgreichen Dienst. Dass es nicht so kam, lag auf der Kundenseite sicherlich an den Kosten. Das zeigt ein direkter Vergleich: Der einmalige Anschluss an Btx kostete zunächst einmal schon 55 DM (DM-Preise von Mitte der 1980er Jahre entsprechen in etwa Euro-Preisen von 2021). Für Btx brauchte man natürlich noch ein Modem. Dieses musste man bei der Post für 8 DM im Monat mieten. Ein eigenes Modem durfte man nicht betreiben. Zur Eingabe und als Anzeigegerät brauchte man dann noch einen Btx-Decoder. Das konnte zum Beispiel ein Btx-fähiges Fernsehgerät sein. Solche Fernseher waren aber mit 2500 bis 3500 DM sehr teuer und waren nie wirklich verbreitet. Ein eigenständiger Decoder, den man an einen vorhandenen Fernseher anschließen konnte, schlug immerhin noch mit 1300 DM zu Buche. Minitel-ähnliche Geräte, sogenannte BITELs oder Multitels, konnte man von der Post für sage und schreibe 48 Euro im Monat mieten. Rechnen wir zusammen, kommen wir, von den Fixkosten abgesehen, schon auf 56 DM Grundkosten pro Monat, ohne auch nur eine einzige Minute den Dienst genutzt zu haben. Diese Kosten waren in Frankreich 0 Francs. Wollten wir den Dienst nun nutzen, schlug das mit 23 Pfennig alle 8 oder 12 Minuten zu Buche, je nach Tageszeit. Rechnen wir mit einem Durchschnitt und gehen von 1 Stunde Nutzung am Tag aus, sind das nochmals 41 DM, vorausgesetzt dass wir nur kostenfreie Angebote aus dem bundesweiten Angebot oder unserem eigenen Regionalangebot⁷ nutzen und keine “Mitteilungen” (also E-Mails) versendeten. Das Versenden einer solchen Mitteilung kostete nämlich 40 Pfennig, das Speichern beim Empfänger, wenn man die Nachricht also nicht nur einmal lesen, sondern auch behalten wollte, 1,5 Pfennig. Briefe kosten nun einmal Porto. Auch einzelne Angebote konnten Geld kosten; von 1 Pfennig bis 9,99 DM pro Aufruf konnten anfallen. Somit war es auch in Deutschland möglich, dass Anbieter, wie etwa die Frankfurter Allgemeine Zeitung, für ihre Inhalte bezahlt werden konnten.

Btx war für Privatleute sicher zu teuer. Lohnend war es hingegen für Unternehmen, denn die Post ermöglichte geschlossene Benutzergruppen. Reisebüros etwa konnten per BTX Flüge und Hotels über spezielle Seiten buchen, die für die Allgemeinheit nicht verfügbar waren, und Handelsreisende konnten sich über BTX mit ihrem Unternehmen synchronisieren.

Technisch war das deutsche Btx komplexer sowohl als Prestel als auch als der französische Télétel-Dienst. Die Bundespost trieb mit anderen europäischen Post- und Telekommunikationsbehörden den sogenannten CEPT-Standard⁸ voran. Dieser Standard sorgte dafür, dass Btx erheblich schöner aussehen konnte als Prestel und Télétel. Er war aber gleichzeitig auch ein Hemmschuh, denn der Dienst wurde dadurch fehleranfälliger und in Bezug auf die möglichen Endgeräte eingeschränkter. Letzteres mag, entsprechend der Geisteshaltung einer staatlichen Behörde, die gerne alles unter Kontrolle haben möchte, sogar durchaus gewünscht gewesen sein. Im Gegensatz zum Prestel-System, das auch mit Heim- und Personal-Computern genutzt werden konnte, mussten es in Deutschland teure Spezialdecoder sein, denn die Computer der damaligen Zeit konnten CEPT nicht darstellen und waren damit auch nicht für den BTX-Dienst zugelassen.

Das Besondere am CEPT-Standard im Vergleich mit den anderen Diensten war die für damalige Verhältnisse hohe Bildqualität. Neben Textdarstellung, die sicherlich dominierte, konnten auch echte Grafiken eingebunden werden. Andere Dienste konnten Grafik allenfalls mit speziellen Grafik-Buchstaben simulieren. Ein CEPT-Bild einer Btx-Seite hatte eine Auflösung von 480x250 Pixeln und konnte auf einer Bildschirmseite 32 Farben aus einer Gesamtpalette von 4096 Farben verwenden. Mit dieser Anforderung schieden nahezu alle verbreiteten Computer Mitte der 1980er Jahre als Endgeräte aus. Im PC-Bereich herrschte noch der CGA-Standard vor. Dieser erlaubte maximal vier fest zugeordnete Farben und hatte dann nur eine Auflösung von 320x200 Pixeln; das reichte auf keinen Fall. Die seit 1984 verfügbare, aber sehr teure EGA-Grafik hätte mit 640x350 Pixeln zwar eine hinreichend große Auflösung gehabt, konnte aber nur 16 Farben aus einer Palette von 64 nutzen. Selbst das ab 1987 verfügbare VGA zeigte bei einer ausreichenden Auflösung von 640x480 nur 16 Farben (immerhin aus einer Palette von 262.144). Abseits der IBM-PC-Kompatiblen sah es nicht wirklich besser aus. Der Commodore 64 stand mit 16 festen Farben und einer Auflösung von 320x200 Pixeln auf verlorenem Posten. Die gleiche Farbzahl und Auflösung hatte auch der Atari ST, wenn er mit einem Farbmonitor betrieben wurde. Lediglich der brandneue Commodore Amiga erfüllte die Voraussetzungen zur korrekten Anzeige von Btx-Seiten im CEPT-Standard.

Durch die Kombination aus hohen Kosten, übermäßig hohen technischen Anforderungen und viel Bürokratie wurde Btx in Deutschland nicht der Erfolg, den das Minitel in Frankreich der DGT brachte. Mit dem Aufkommen des World Wide Web ging der Dienst zunächst in T-Online auf und wurde dort T-Online Classic genannt. 2001 wurde er dann größtenteils eingestellt. Lediglich für den Bereich des Online-Banking blieb die alte Technik noch bis 2007 in Betrieb, denn Banken schätzten die technischen Eigenschaften des geschlossenen Dienstes. Wer die Btx-Seite einer Bank anwählte, war durch seine Zugangskennung bei der Telekom bekannt. Die Bank musste nur eine Zuordnung von Zugangskennungen zu Konten machen und brauchte sich ansonsten nicht um die Absicherung der Kommunikation oder ähnliches kümmern. Der wilde Westen des World Wide Web bot diese so wohltuende Geschlossenheit nicht.

Btx in Österreich

Mit Prestel, Télétel und Bildschirmtext habe ich Ihnen, glaube ich, die wichtigsten Vertreter dieser frühen Variante von Online-Diensten nahegebracht. Es lohnt sich aber, einen kleinen Abstecher zu machen in Deutschlands südliches Nachbarland Österreich, denn hier ging man einen anderen Weg als in Frankreich und in Deutschland.

Die Österreichische Post und Telegraphenverwaltung (PTV) betrieb einen auf dem gleichen CEPT-Standard wie in Deutschland basierenden Dienst, der auch ebenfalls Bildschirmtext hieß. Der Dienst war allerdings etwas günstiger als in Deutschland. Das macht ihn für sich genommen noch nicht interessant. Besonders und damit herausragend war aber die österreichische Einschätzung zum Endgerät. Während man in Frankreich ja auf ein sehr einfaches, kleines Gerät setzte und dieses kostenfrei abgab und während man in Deutschland sehr restriktiv in Sachen Endgeräten vorging und diese teuer verkaufte oder vermietete, entwickelte die PTV zusammen mit der Universität Graz unter Leitung des Informatik-Professors Hermann Maurer einen eigenen Btx-Decoder namens Mupid (Mehrzweck Universell Programmierbarer Intelligenter Decoder). Ein Mupid konnte von der PTV gemietet werden. Dafür musste man einmalig 1000 Schilling aufbringen und dann 130 Schilling pro Monat bezahlen (18,17 Euro in 2021).

Hier abgebildet sehen Sie die zweite Version des Mupid. Die erste Version wurde noch für die Testphase des Btx-Dienstes hergestellt, als man noch den englischen Prestel-Standard nutzte. Das abgebildete Gerät erschien 1984 nach der Umstellung auf CEPT. Es sieht aus wie ein typischer Heimcomputer der Zeit und, wie ich finde, sogar wie ein ziemlich modern designter. Der Mupid sah aber nicht nur wie ein Heimcomputer aus, er war auch einer oder er konnte zumindest einer werden, wenn man ihn mit Zusatzgeräten versah.

Ein Mupid wurde über ein Kabel an einen Fernseher angeschlossen. Ebenfalls angeschlossen werden musste, zumindest wenn man Btx-Seiten ansehen wollte, das von der PTV gemietete Modem. Der Mupid selbst verfügte über einen Z80-Prozessor. Den kennen Sie schon aus einer ganzen Reihe von Heimcomputern. Er ist kompatibel zum Intel 8080, also dem Computer, der nicht zuletzt mit dem Altair 8800 den Anfang des Personal-Computer-Zeitalters mit einläutete. Mit 128 KB Arbeitsspeicher war das Gerät ganz ordentlich ausgestattet. Schloss man ein separat erhältliches Diskettenlaufwerk an, konnte man auf dem Mupid tatsächlich CP/M und die zugehörige Software laufen lassen und hatte dann einen Heimcomputer. Unter den CP/M-Computern war der Mupid allerdings ein ganz besonderer, denn eigentlich sind CP/M-Systeme ja stets reine Textsysteme. Der Mupid hingegen verfügte über für die damalige Zeit durchaus beeindruckende Grafikfähigkeiten in Bezug auf Farbanzahl und Auflösung. Um Btx-Seiten im CEPT-Standard darstellen zu können, durfte das ja auch nicht anders sein.

Der Mupid konnte also sowohl Btx-Decoder als auch Heimcomputer sein. Der Clou bestand nun aber darin, diese beiden Eigenschaften miteinander zu verbinden. Im Btx-Modus konnte ein Mupid nämlich mehr als es ein “dummer” Decoder konnte. Er vermochte es beispielsweise, vektorbasierte Zeichnungen anzuzeigen oder Eingaben auf dem Decoder zu überprüfen, ohne sie übertragen zu müssen. Verfügte man über ein Diskettenlaufwerk, ließen sich mit dem Mupid Btx-Seiten auf Diskette speichern. Diese konnten dann ohne Telefonkosten zu verursachen gelesen werden. Mit der passenden Software ließen sich Btx-Seiten sogar auf dem Mupid erstellen und auf die Postcomputer übertragen.

Auch ohne Diskettenlaufwerk konnte auf einem Mupid Software ausgeführt werden. Diese kam dann direkt aus dem Btx auf den Rechner. Der Screenshot oben zeigt, wie das aussah. Sogenannte Telesoftware, wie die oben angekündigte einfache Textverarbeitung konnten aus dem Btx geladen und dann auf dem Mupid ausgeführt werden. Auch ein BASIC-Interpreter zum Programmieren kam so auf das Gerät. Software konnte, egal ob von Diskette oder aus dem Btx geladen, den Dienst als Datenverbindung und als Speicherort nutzen, also Daten aus dem Btx empfangen oder dorthin senden. Mit diesen Eigenschaften ließen sich spannende Szenarien umsetzen, wie diese Pressemitteilung aus dem Jahr 1986 zeigt:

EDV-Ausbildungsinitiative aus Graz als Weltpremiere.

Die Arbeitsgemeinschaft für Datenverarbeitung (ADV), die größte österreichische Vereinigung von Computeranwendern, stellt anlässlich der Grazer Btx-Tage (19.02. - 22.02.86 im Kongreßsaal Messegelände) ein von der steirischen Landesgruppe der ADV (Präsident Dr.J.Koren) initiiertes neuartiges Ausbildungsprogramm für jedermann vor.

Angelehnt an das weitverbreitete Taschenbuch “EDV für jedermann” von J. Koren und W. Thaller wurde unter der wissenschaftlichen Betreuung von o. Univ. Prof. Dr. H. Maurer (TU Graz) ein 20-teiliger Kurs zur Einführung in die wichtigsten Aspekte der EDV erarbeitet: die 20 Lektionen sind im Bildschirmtextsystem (Btx) der österreichischen Post gespeichert und sind daher österreichweit über die Telefonleitung (zum Telefonortstarif) abrufbar. Jede Lektion wird zunächst in den von der Post mietbaren Btx-Computer MUPID geladen und dort (ohne weitere Telefonverbindung) durchgearbeitet.

Im Gegensatz zu einem gedruckten Fernkurs bietet diese Art der Wissensvermittlung die anschauliche Darstellung von Abläufen durch bewegte Grafik (deren Geschwindigkeit vom Benutzer gesteuert wird, die wiederholbar ist, und vieles mehr) und die direkte Kontrolle des erarbeiteten Wissens durch Fragen, die der Btx-Computer MUPID stellt und die vom Benutzer beantwortet werden sollen. (MUPID kontrolliert, ob die Antworten stimmen!) Durch die Verwendung von Btx als “Lektionenbibliothek” ist es dem Lernenden möglich, Kommentare und Verbesserungsvorschläge an den Kursersteller elektronisch zu vermitteln, die auf gleichem Wege gegebenenfalls beantwortet werden: das Institut für Informationsverarbeitung wird diese Art der Betreuung probeweise durchführen. Übrigens, die ADV denkt auch daran, Prüfungen (mit entsprechenden Zeugnissen) für diesen Kurs anzubieten.

Sicherlich war diese Form des Lernens mit dem Computer nicht die Speerspitze der Forschung. Mit experimentellen, universitären Systemen waren ähnliche Szenarien auch schon vorher und auch ausgefeilter möglich. Spannend und innovativ an dem Ansatz in Verbindung mit Btx und Mupid ist aber, dass sowas nun alltagstauglich in einem öffentlichen Dienst und damit potenziell für jeden verfügbar wurde, ohne dass komplexeste Technik angeschafft werden musste. Mit dem französischen Minitel wäre das so nicht gegangen, denn die einfachen Geräte konnten ja keine Software ausführen und im deutschen Btx wäre es auch nicht gegangen, denn hier gab es kein flächendeckend verbreitetes, “intelligentes” Gerät wie den Mupid.

Der Mupid hatte ein faszinierendes Konzept. Die Entwickler um Hermann Maurer dachten sowohl in Sachen Technik als auch in Sachen Einsatzszenarien erheblich weiter, als dies in vielen anderen Ländern der Fall war. Sie brachten die Idee der Kommunikationsinfrastuktur und die des Heimcomputers zusammen und kreierten damit einen niedrigschwelligen Zugang mit Potenzialen, die eine größere Öffentlichkeit erst Jahrzehnte später für sich entdeckten. Dies erreichten sie mit einem freundlichen, einfachen Gerät, also ohne dass man zwangsläufig zum Computerspezialisten werden musste.

Fazit

Man kann durchaus von den Bildschirmtexten einiges lernen. Dazu gehört zum Beispiel, dass “das Internet”, und hier meine ich jetzt das WWW, zwar sicherlich vieles veränderte, aber nun auch nicht aus heiterem Himmel über uns kam. Die Zeit war offensichtlich reif für digitale Mediendienste wie den Bildschirmtext. Eine Betrachtung der Dienste zeigt auch, dass es möglich ist, Technologie dieser Art in einer Art und Weise bereitzustellen, die die technischen Hürden beim Kunden niedrig halten, denn für die Nutzer von Prestel, Btx oder Télétel war es ein einfaches Leben ohne ständige Sicherheitsupdates und ohne dass man von ihnen verlangt hätte, ein Betriebssystem zu beherrschen. Man erfährt auch, und das ja nicht zum ersten Mal, dass sich nicht immer das technisch Bessere durchsetzt, sondern oft auch das Verfügbarere, Einfachere und Niedrigschwelligere. Man lernt, dass zentralisierte Systeme großartig sein können und Kreativität fördern, wenn sie die Infrastruktur für individuelle, kreative Anbieter und Kunden bieten, aber dass solche Systeme zum Hemmschuh werden, wenn sie bürokratisch und unflexibel gestaltet sind. Letztendlich lehrt einen das Beispiel des österreichischen Btx, dass man durch Blicke über den Tellerrand, durch intelligente Kombinationen das Bekannte neu denken kann und sich dann neue Nutzungsmöglichkeiten ergeben.

Online-Dienste und Bulletin Board Systems

So attraktiv die Bildschirmtext-Dienste auch scheinen mögen, blieben sie doch eine ziemlich europäische Angelegenheit. Es gab einige Ableger in Asien und auch in den USA gab es vereinzelte Projekte, die aber lokal blieben und meist auch nicht lange überlebten. Dort gab es jedoch Online-Dienste und sogenannte Bulletin Board Systeme, die einen anderen Ursprung haben als die Bildschirmtexte in Europa.

Die Grundidee hinter Online-Diensten ist fast so alt wie die der interaktiven Computer selbst. Erinnern wir uns: Beim Time Sharing teilten sich viele Teilnehmer die Rechenzeit des Computers, der sie reihum bediente. Dazu bedienten sie sich Terminals – zu Beginn meist Fernschreiber, später dann eigene Geräte mit Tastatur und Bildschirm. Man konnte den Computer aus der Ferne nutzen, ohne die eigentliche Anlage je sehen zu müssen. Innerhalb eines Firmensitzes oder eines Universitätscampus war dies durch das Legen eines direkten Kabels zur Rechenanlage möglich, doch lag es ja nun auch nahe, die Dienste auch aus größerer Entfernung anzubieten. Schließlich gab es bereits ein landesweites Kommunikationsnetz in Form des Telefonnetzes. Mittels Modems konnten über dieses Telefonnetz sowohl Computer miteinander als auch, und darum geht es ja hier, Terminals mit entfernten Computern verbunden werden. Man konnte sich so von entfernten Orten mit Firmen- oder Universitätscomputern verbinden. Die Terminals selbst konnten nichts weiter als Textzeichen anzeigen und Tastatureingaben verschicken. Wenn das gut klappte, wirkte es so, als säße man direkt vor Ort am Terminal.

Diese Technik, um aus Entfernung auf Timesharing-Computersysteme zugreifen zu können, wurde zu einer Geschäftsidee, denn nicht jeder, der vielleicht davon profitieren könnte, hatte Zugang zu einem Timesharing-System. Vor allem viele kleinere Firmen konnten sich weder eigene Computer leisten noch hatten sie Zugang zu universitären Rechnern. Sehr zupass kam ihnen da das Angebot von Timesharing-Anbietern. Das waren Firmen, die es zu ihrem Geschäftsmodell machten, Computersysteme zu betreiben, auf die man sich gegen Gebühr aus Entfernung verbinden und auf denen man dann seine Programme laufen lassen konnte. Solche Firme gab es in kleiner Größe oder auch als große Player, wie etwa das schon 1969 gegründete CompuServe. Über das Telefonnetz konnte man sich von vielen großen Städten der USA auf die zentralen Timesharing-Computer von CompuServe verbinden und seine Programme laufen lassen. Diese Programme konnten ganz individuell sein. Viele Firmen brauchten aber natürlich ganz ähnliche Dienste und viele Dienste konnten gerade auch vom zentralen Charakter des Anbieters profitieren.

Ende der 1970er Jahre wurde CompuServe so von einem Timesharing-Anbieter zu einem Onlinedienst mit Zugriff auf Finanzinformationen, auf Banking, auf Lexika und Nachschlagewerke, auf Nachrichtenangebote und mit der Möglichkeit, zwischen den Teilnehmern Nachrichten zu verschicken. Zugang erlangte man nun nicht mehr mit Fernschreibern und Terminals, sondern mit aufkommenden Personal- und Heimcomputern. Das Ergebnis war bis in die 1990er Jahre, ganz wie der Großteil der Nutzungsschnittstellen der damaligen Computer, textbasiert. Mit dem Aufkommen grafischer Nutzungsschnittstellen änderte sich dies natürlich. CompuServe-Inhalte wurden nun in Fenstern und mit einer grafischen Nutzungsschnittstelle angezeigt. Andere Anbieter kamen hinzu. Bekannt sind America Online (AOL) und das Microsoft Network (MSN).

Einen regelrechten Gegenentwurf zu den großen Online-Diensten, die von großen Anbietern gepflegt wurden und stark kommerzielle Zwecke erfüllten, bildeten die BBS, die Bulletin Board Systems. Im deutschen Sprachraum wurde dieser Begriff erstaunlicherweise weder im englischen Original noch in der Übersetzung “Nachrichtenbrett-Systeme” verwendet. Stattdessen verwendete man mit “Mailbox” einen anderen englischen Ausdruck, der gar nicht besonders gut passt, denn private Briefe standen nie im Mittelpunkt der Systeme.

Hinter BBS-Systemen standen keine großen, kommerziellen Anbieter, sondern oft Privatleute oder allenfalls kleinere Firmen. Als das erste System dieser Art wird das Computerized Bulletin Board System (CBBS) angesehen. Ab 1978 konnte es im Raum Chicago per Modem angewählt werden. Man erreichte dann einen Altair-artigen Computer, um die digitale Version eines schwarzen Bretts einzusehen und dort Nachrichten zu hinterlassen. Diese namensgebende Funktionalität wurde im Laufe der Jahre ergänzt um private Nachrichten von einem Teilnehmer an einen anderen, die Möglichkeit, Software für den eigenen Heimcomputer herunterzuladen und oft sogar um einfache Online-Spiele und Chats. Ein solcher Chat war natürlich nur dann möglich, wenn das BBS-System über mehr als eine Leitung verfügte, denn nur dann konnten ja mehrere Teilnehmer gleichzeitig verbunden sein. Das war bei Weitem nicht bei allen BBS-Systemen der Fall. Typische BBS-Systeme waren häufig Heimcomputer von Technikbegeisterten. In den 1980er Jahren waren es oft IBM-kompatible PCs, die mit Microsofts DOS betrieben wurden. Auch C64-Systeme wurden gerne als BBS-Server eingesetzt. Diese Computer waren mit einem oder vielleicht auch mal mit zwei Modems ausgestattet. Nutzer des Systems brauchten ebenfalls ein Modem und konnten dann von ihrem Heimcomputer aus den BBS-Rechner anrufen und Daten austauschen. Oft war dieses Modem nur ein einfacher Akustikkoppler. Gerade in Deutschland hatte man, wenn man nichts Illegales machen wollte, auch kaum eine andere Wahl, denn Privatleute durften ja keine eigenen Modems an das Telefonnetz anschließen.

Ein BBS-System war eine Insel mit einem eigenen Angebot. Viele BBS-Systeme boten aber den sogenannten NetMail-Dienst an. Man konnte mit diesem Dienst Nachrichten an die Teilnehmer anderer BBS-Systeme schicken. Dies geschah natürlich noch nicht über das Internet, das zum damaligen Zeitpunkt ja noch nahezu rein auf Forschungseinrichtungen beschränkt war und damit weit weg war von dem, was man mit Heimcomputern machte. Vielmehr schlossen sich die BBS-Systeme selbst in Netzwerken zusammen. Verfasste man eine Nachricht an einen Teilnehmer in einem anderen BBS-System, wurde diese nicht sofort zugestellt, sondern erstmal zwischengespeichert. Irgendwann in der Nacht dann riefen sich die BBS-Computer untereinander an und tauschten die Nachrichten aus.

BBS-Systeme waren natürlich weit weniger professionell als die amerikanischen Online-Dienste oder die europäischen Bildschirmtext-Dienste. Das konnte aufgrund der Struktur ja auch nur so sein. BBS-Systeme stehen in einer ähnlichen Tradition wie die Personal Computer. Im Kapitel über den Altair 8800 habe ich Ihnen die Situation Ende der 1970er Jahre erläutert, als sich in den USA Bastler in Clubs zusammentaten, um ihre eigenen Rechner zu bauen und damit dafür zu sorgen, dass Computer nicht mehr nur eine Sache von Militär, Industrie und Verwaltung waren, mit der die normale Bevölkerung nichts zu tun haben sollte. Man kann das Ziel dieser Clubs regelrecht als Versuch eines Befreiungsschlags ansehen. BBS-Systeme haben einen ganz ähnlichen Charakter. Es waren nun nicht professionelle Firmen oder Postorganisationen, die die Welt der computerisierten Kommunikation eröffneten, sondern Technikbegeisterte und Hobbyisten, die mit ganz einfachen Mitteln die Welt verändern wollten.

Auf der Höhe ihrer Popularität ging die Anzahl der BBS-Systeme in den USA in die Zehntausende, mit Millionen regelmäßiger Nutzer. Zusammengenommen hatten die BBS-Systeme mehr Nutzer als Online-Dienste wie CompuServe. So mag es einen auch nicht wundern, dass das neue Betriebssystem Windows 95 im Jahr 1995 zwar noch keinen Webbrowser enthielt, aber sowohl einen Zugang zu Microsofts Online-Dienst MSN als auch ein Terminalprogramm, mit dem man ein angeschlossenes Modem ansteuern und mit einem BBS-System verbinden konnte. All dies sollte sich bald ändern, denn BBS-Systeme und Onlinedienste bekamen Konkurrenz durch lokale ISPs, Internet Service Provider. Das World Wide Web lief den etablierten Angeboten in nur wenigen Jahren den Rang ab.

Das World Wide Web

Mit der steigenden Popularität des Internets durch das World Wide Web ging die Zeit der Bildschirmtextsysteme, der Online-Dienste und der BBS-Systeme zu Ende. Das Internet hat seine Anfänge im Bereich von Universitäten und Wissenschaftsorganisationen. Es hat an sich keine Nutzungsschnittstelle, sondern ist eine reine Infrastruktur, die die Nutzung verschiedenster Dienste ermöglicht. Der wohl ursprünglichste Internetdienst hat den Namen telnet und erlaubt es Nutzern, sich über das Netz auf entfernten Computern anzumelden und diese fernzusteuern, den eigenen Computer also als Terminal für entfernte Großrechner zu verwenden. Der Dienst trat an die Stelle der Einwahl auf entfernte Computer über eine Telefonleitung. Über die Jahre kamen viele weitere Dienste hinzu. Einer der bekanntesten ist der E-Mail-Dienst, den wir ja auch heute noch nutzen. Vom FTP, dem Dienst zum entfernten Zugriff auf Dateien, wird im Kapitel Verteilte Persistenz noch die Rede sein. In diesem Kapitel soll es hauptsächlich um den Dienst gehen, der heute so dominant ist, dass er in der Öffentlichkeit allgemein für das Internet steht. Wir beginnen unsere Betrachtung des Internets aber – so kennen Sie das von mir schon – nicht direkt mit dem Web, sondern mit einer Parallelentwicklung und werden wieder sehen, dass die Zeit für bestimmte Entwicklungen offensichtlich reif war.

Ein Gopher wühlt sich durch Dokumente

Anfang der 1990er Jahre entstand an der Universität von Minnesota in den USA ein Dienst zur Verfügbarmachung von Text-Dokumenten. Dem Dienst wurde der Name Gopher (gesprochen Goffer) gegeben. Der Name ist etwas eigenartig. Schlägt man im Wörterbuch nach, findet man die “Taschenratte”. Der Hintergrund hinter der kuriosen Namensgebung ist vielschichtig. Das Maskottchen der Universität und des Staats Minnesota spielt mit hinein, aber auch umgangssprachliche Definitionen des Wortes und die Eigenart von Gophern, sich “durchzuwühlen”, spielt eine Rolle. Die offizielle Beschreibung von Gopher⁹ führt aus:

gopher n. 1. Any of various short tailed, burrowing mammals of the family Geomyidae, of North America. 2. (Amer. colloq.) Native or inhabitant of Minnesota: the Gopher State. 3. (Amer. colloq.) One who runs errands, does odd-jobs, fetches or delivers documents for office staff. 4. (computer tech.) software following a simple protocol for burrowing through a TCP/IP internet.

Der Zweck und die Charakteristik von Gopher erklären sich durch seine Herkunft als universitäres Informationssystem gut. Hier gilt es natürlich, viele Dokumente verfügbar und diese auf eine ordentliche, gut verständliche Art und Weise erschließbar zu machen. Man entschied sich dazu, die Dokumente in einer hierarchischen Struktur darzustellen, einer Organisationsform, die aus Bibliotheken und Verwaltung schon bekannt war. Auch dies erläutert die Beschreibung von Gopher sehr schön:

A hierarchical arrangement of information is familiar to many users. Hierarchical directories containing items (such as documents, servers, and subdirectories) are widely used in electronic bulletin boards and other campus-wide information systems. People who access a campus-wide information server will expect some sort of hierarchical organization to the information presented.

Das Gopher-System der Universität von Minnesota war technisch sehr simpel gestaltet. Im Vordergrund standen Textdateien, die in einer einfachen, hierarchischen Struktur organisiert waren und mit Volltextindizes leicht durchsucht werden konnten. Das System sollte zum einen leicht verständlich sein und zum anderen wenig Ressourcen benötigen. Wie das aussah, sehen Sie zum Beispiel auf obiger Abbildung. Hier werden die Indizes von Gopher-Seiten unter Windows 3.1 gezeigt. Aufgrund der Einfachheit der Struktur ließ sich der sogenannte Gopher-Space aber auch sehr einfach auf reinen Textterminals erobern. Gerade an Universitäten mit ihren Unix-Terminals war dies nicht zu vernachlässigen.

Gopher ist heute weitgehend unbekannt. Der Dienst wurde vom World Wide Web regelrecht überrollt. Als ein Grund dafür gilt auch, dass die Universität von Minnesota sich anschickte, mit der Technologie Geld verdienen zu wollen und sie nicht mehr frei zur Verfügung zu stellen. Dieser wirtschaftliche Faktor mag sicher eine Rolle gespielt haben, obgleich es nie wirklich dazu kam, dass Geld für die Gopher-Technologie verlangt wurde. Im Zusammenhang betrachtet scheinen mir andere Faktoren viel wichtiger gewesen zu sein. Die reine hierarchische Struktur und der starke Fokus auf Textdateien, die noch nicht einmal in Sachen Farbe und Schriftart angepasst werden konnten, passten nicht so recht zum aufkommenden Multimedia-Zeitalter. Firmenpräsenzen, aber auch Vereins- und Privat-Gopher-Seiten wären schon einigermaßen öde gewesen.

Das frühe World Wide Web

Die Grundidee hinter der Entwicklung des World Wide Web ist der von Gopher an der Universität von Minnesota gar nicht unähnlich, denn in beiden Fällen ging es letztlich um das Zugänglich-Machen von Informationsinhalten. Der britische Informatiker Tim Berners-Lee und sein belgischer Kollege Robert Calliau konzipierten und entwickelten das WWW am CERN in Genf. CERN steht für Conseil Européen pour la Recherche Nucléaire und ist das größte europäische Kernforschungszentrum. Bekannt ist es vor allem für seine großen Teilchenbeschleuniger. Die vielleicht einflussreichste Entwicklung des CERN ist aber bei Weitem nicht so kompliziert wie Teilchenphysik.

Man kann sich gut vorstellen, dass am CERN schon seit jeher viele Computer genutzt, viele Informationen abgelegt und viele Dokumente geschrieben wurden. So beschreibt es auch das Proposal für das WWW aus dem Jahr 1990¹⁰:

At CERN, a variety of data is already available: reports, experiment data, personnel data, electronic mail address lists, computer documentation, experiment documentation, and many other sets of data are spinning around on computer discs continuously.

Das Problem war aber die Verbindung der Informationen.

It is however impossible to “jump” from one set to another in an automatic way: once you found out that the name of Joe Bloggs is listed in an incomplete description of some on-line software, it is not straightforward to find his current electronic mail address. Usually, you will have to use a different lookup-method on a different computer with a different user interface. Once you have located information, it is hard to keep a link to it or to make a private note about it that you will later be able to find quickly.

Berners-Lee und Calliau wollten mit ihrem System also ein sehr konkretes Problem am CERN lösen. In der heutigen Geschichtserzählung, auch betrieben von Tim Berners Lee selbst, erscheint das mitunter anders. Die Wikipedia spricht zum Beispiel von seiner “vision of a global hyperlinked information system”. Ob es die gegeben hat, wann es sie gegeben hat und ob nicht aus dem späteren Erfolg dann ex post die Gedanken der Vergangenheit zu einer Vision verklärt wurden, wird hier nicht zu klären sein. Interessanter jedenfalls wird die Geschichtsbetrachtung, wenn man nicht von geniegleichen Visionären ausgeht, sondern wenn man, wie auch beim Rest der Computergeschichte, Beweggründe, Kontexte und Einflüsse betrachtet.

Betrachtet man das WWW rein von der technischen Seite her, war es nicht besonders innovativ und visionär, sondern im Gegenteil ziemlich einfach. Web-Technologie bestand nur aus zwei Spezifikationen, einer für Server, die das Übertragungsprotokoll HTTP beherrschen mussten, und einer weiteren für Terminalprogramme, Browser genannt, die die Auszeichnungssprache HTML interpretieren können mussten.

Die Hauptfunktionalität von HTTP-Servern ist das Ausliefern von Dokumenten. Dieser Prozess läuft sehr simpel ab. Stellen Sie sich einen HTTP-Server vor wie jemanden, der vor einem Telefon sitzt. Sie können diese Person anrufen. Nach dem Abnehmen sagen Sie ihr, welches Dokument Sie vorgelesen haben möchten. Die Person am anderen Ende liest das Dokument vor und legt direkt wieder auf. Diesen Vorgang sehen Sie in der Abbildung oben. Dort wurde ein Webserver ohne Browser angefragt, sodass man mitlesen kann, welche Daten gesendet und empfangen werden. In den ersten Zeilen sehen Sie in grün, dass hier eine Verbindung zum Port 80 des Rechners, der unter checkip.dyndns.org erreichbar ist, aufgebaut wird. Der Computer “nimmt ab” und erwartet, dass man ihm sagt, was man will. “GET /” bedeutet nicht weniger als “Gib mir die Hauptseite!”¹¹. Hätte der Server auch ein Impressum zu haben, könnte man zum Beispiel “GET /impressum.html” anfragen und würde entsprechend bedient. Unter der Anfrage sehen Sie die Antwort in Form eines sehr einfachen HTML-Dokuments. Danach beendet der Server direkt die Verbindung.

Wenn ein Browser eine Anfrage über HTTP an einen Server schickt, kriegt er eine Antwort. Das haben Sie gerade gesehen. Meist war und ist das wie oben reiner Text. Auch der Text, den Sie hier gerade lesen, könnte so übertragen werden. Es ergäben sich aber Einschränkungen, wenn man auf einfache Zeichen beschränkt bliebe. Grundsätzlich besteht ein reiner Text zwar aus einer Aneinanderreihung von Buchstaben, Zahlen, Leerzeichen und einigen Sonderzeichen. Dokumente wie das, das Sie gerade lesen, bestehen aber aus mehr als nur einer solchen Aneinanderreihung. Sie haben auch eine Struktur, die sich in sichtbaren Eigenschaften offenbart. Der Satz, den Sie gerade lesen, ist Teil eines Absatzes, etwas weiter oben und auch weiter unten finden Sie Überschriften verschiedener Hierarchieebenen. Sie erkennen sie an der Formatierung mit großer oder fetter Schrift. An mancher Stelle wird durch Änderung des Schriftstils etwas besonders herausgestellt. Die Textzeichen, die von einem HTTP-Server kommen, können selbst aber nicht groß, klein, kursiv oder fett sein. Bei reinem Text ist in Sachen Formatierung nicht mehr möglich als bei einer alten Schreibmaschine oder einem Fernschreiber. Es gibt nur Buchstaben, Zahlen, Sonderzeichen, Leerzeichen und Zeilenumbrüche. Damit ein Browser daraus einen formatierten, strukturierten Text machen kann, muss man in den Text etwas hineinschreiben, was nicht direkt angezeigt wird, was aber die Struktur beschreibt. Genau das macht HTML, die Hypertext Markup Language. Wir schauen uns zunächst einmal ein paar Beispiele an. Keine Angst, Sie müssen dafür nicht zum Programmierer werden.

Die Originalfassung von HTML von Tim Berners-Lee definierte 22 sogenannte Tags, die genutzt werden konnten, dem Text Struktur zu geben. Das englische Wort “Tag” übersetzt sich als “Etikett”. Man klebt also quasi Etiketten an den Text, um seine Struktur zu beschreiben. Das sah dann zum Beispiel so aus:

1: <TITLE>Ein einfaches Dokument</TITLE>
2: <H1>Dies ist 
3: HTML
4: <P>Dies ist ein sehr einfaches HTML-Dokument.
5: <P>Zu HTML gibt es viel zu sagen. <HP1>Das Wichtigste sind die Tags</HP1>.
6: <H2>Tags!
7: <P>Die erste Version hat 22 Tags: TITLE, NEXTID, A, ISINDEX, PLAINTEXT, 
8: LISTING, P, H1, H2, H3, H4, H5, H6, ADDRESS, DL, DT, UL, LI, MENU 
9: und DIR. 14 davon sind auch heute noch aktuell.

In Zeile 1 wird der Dokument-Titel bestimmt. Alles, was zwischen <TITLE> und </TITLE> steht, ist der Titel des Dokuments. Bei aktuellen Browsern ist das der Text, der in der Titelzeile des Fensters bzw. als Beschriftung des Tabs angezeigt wird. Zeile 2 beginnt mit <H1>. Das sagt dem Browser, dass alles, was danach kommt, eine Überschrift der ersten Ordnung ist, also der obersten Ebene. Browser zeigen Überschriften in der Regel in großer, fetter Schrift an. Zeilenumbrüche werden in HTML übrigens ignoriert. Dass das Wort “HTML” in einer eigenen Zeile steht, hat also keine Konsequenz in der Darstellung. Eine Überschrift würde da wieder aufhören, wo </H1> steht. Das hat man sich hier aber gespart. Also endet die Überschrift da, wo eine andere Textart beginnt. Das ist in Zeile 4 der Fall, denn da beginnt mit <P> ein Absatz (auf Englisch paragraph). Ähnlich sieht es in Zeile 5 aus. Hier beginnt ein neuer Absatz; der davor endet also automatisch. Interessant ist, was im zweiten Teil der Zeile passiert, denn hier steht Text zwischen <HP1> und </HP1>. HP steht für “highlighted phrase”. Es handelt sich also um Text, der besonders herausgestellt wird. Er könnte zum Beispiel fett dargestellt werden¹². Zeile 6 definiert wieder eine Überschrift, dieses Mal eine der zweiten Ordnung, also etwas kleiner in der Darstellung. In Zeile 7 folgt dann wieder ein Absatz.

Das ist alles keine Hexerei, oder? Man kann sich das Ganze eigentlich so vorstellen, als würde einem jemand den Text durchgeben, den man in einer Textverarbeitung wie Word eingeben soll. Die Tags sind dann immer Hinweise, welche Formatierungsknöpfe man drücken soll. Bei H1, H2 und P wählt man jeweils die Formatvorlagen für Überschriften und Absätze aus und bei HP1 klickt man auf fett. Mehr ist es zunächst einmal gar nicht. Das eigentlich Interessante an HTML, weswegen das Ganze für das CERN interessant war und was auch den Namen Hypertext Markup Language erklärt, zeigt dieses Beispiel:

<H2>Links
<P>Das Wichtigste an HTML sind die <A HREF=links.htm>Links zu anderen 
Ressourcen</A>. Mehr erfahren Sie, wenn Sie auf den Link klicken.

Die erste Zeile definiert wieder eine Überschrift. Das kennen wir schon. Dann folgt ein Absatz – auch schon bekannt. Interessant ist dann <A HREF=links.htm> bis </A>. Hier handelt es sich um einen Link, also eine Verknüpfung zu einem anderen Dokument. Der Text dazwischen, also “Links zu anderen Ressourcen”, kann angeklickt werden. A steht für “anchor”. Danach folgt ein Attribut HREF für “hypertext reference” und dahinter steht dann, wohin dieser Link führt, nämlich zum Dokument mit dem Namen links.htm. Wählt ein Nutzer den Link aus, kontaktiert der Browser per HTTP den Server und sendet den Befehl GET /links.htm. Die Antwort wird wieder ein HTML-Dokument sein, das der Browser anzeigen kann. Ein Anker konnte nicht nur Ausgangspunkt eines Links, sondern auch dessen Ziel sein. In dem Dokument links.htm könnte zum Beispiel <A NAME=wichtig><H1>Wichtige Links</H1></A> stehen. Man könnte den Link oben dann zu <A HREF="links.htm#wichtig"> ändern. Er würde dann direkt zum Anker im Zieldokument springen.

Die ganzen komischen Abkürzungen, die Sie hier kennengelernt haben, HREF für “hypertext reference”, HTML für “hypertext markup language”, HTTP für “hypertext transport protocol” haben das merkwürdige Wort Hypertext gemeinsam. Über Hypertext wurde in den 1980ern und 1990ern sehr viel geforscht. Viele Hypertext-Systeme wurden entwickelt, von denen heute selbst unter Informatikern kaum noch jemand etwas weiß. Weiter unten erzähle ich Ihnen mehr darüber, welche Potenziale hinter Hypertext stecken. Beim World Wide Web bedeutet Hypertext nicht mehr als das, was ich Ihnen gerade bereits erläutert habe, nämlich die Möglichkeit, in ein Textdokument sogenannte Anker einzubauen, die Start- und Endpunkte von Verknüpfungen sein können.

Mit dem, was ich bis hierher erläutert habe, habe ich das frühe Web technisch fast vollständig beschrieben. Charakteristisch für das WWW war nicht seine technische Finesse, sondern gerade seine extrem technische Einfachheit und Offenheit. Nicht nur war es recht einfach, eigene Webserver und Browser zu programmieren, durch die Dezentralität war es auch möglich, einen eigenen Server einzurichten. Insofern man über einen dauerhaften Internetzugang verfügte, was am Anfang natürlich vor allem an Universitäten, später dann bei vielen Unternehmen und dann nach und nach bei mehr und mehr sogenannten “Hostern” der Fall war, konnte man einen Server ans Netz anschließen und war damit Teil des World Wide Web, ohne dass es irgendeiner zentralen Koordination bedurft hätte und dieser Server mit irgendwelchen anderen Webservern etwas zu tun haben müsste.

Typisch gerade für das frühe WWW war, dass ein Server in der Regel nicht mehr tat, als Dateien, die auf einer großen Festplatte gespeichert waren, so auszuliefern, wie sie waren. Von vornherein war allerdings auch vorgesehen, dass über Webserver und Browser auch Zugriff auf bereits vorhandene Systeme realisiert werden konnte. Damit das funktionierte, musste ein Server so programmiert werden, dass er mehr konnte als einfach nur Dateien versenden. Er musste vorhandene Systeme im Hintergrund aufrufen, die erhaltenen Informationen aufarbeiten und HTML-garnierten Text an den Browser schicken. Dadurch wurde es möglich, über das Web auch auf die Inhalte von existierenden CERN-internen Hilfesystemen, auf eine Informationssuchmaschine und sogar auf das Telefonbuch zuzugreifen. Die Proposals für das WWW weisen darauf hin, dass das Telefonbuch dann z. B. Links zwischen Personen, Abteilungen und Arbeitsgruppen beinhalten könnte. Natürlich sind diese Beispiele recht simpel, aber, wenn man es nüchtern betrachtet, liegt hier die Grundlage für das, was man später Web-Anwendung nennen sollte, also eine webbasierte Nutzungsschnittstelle für eine komplexe Anwendungslogik im Hintergrund.

Da das WWW zunächst vor allem für das CERN entwickelt wurde, fehlten ihm Eigenschaften, die für eine allgemeine Nutzung durchaus vieler Features nötig gewesen wären. Der erste Browser für das WWW, der von Tim Berners-Lee selbst geschriebene Browser, der verwirrenderweise auch selbst den Namen “World Wide Web” trug, konnte nicht nur Webseiten anzeigen, sondern diese auch ändern. Das klappte sowohl bei HTML-Dateien auf der lokalen Festplatte als auch über HTTP. Was fehlte, war jegliche Art von Zugriffsbeschränkungen. Im Proposal heißt es dazu:

[The project will not aim] to use sophisticated network authorisation systems. Data will be either readable by the world (literally), or will be readable only on one file system, in which case the file system’s protection system will be used for privacy. All network traffic will be public.

[…]

Discussions on Hypertext have sometimes tackled the problem of copyright enforcement and data security. These are of secondary importance at CERN, where information exchange is still more important than secrecy. Authorisation and accounting systems for hypertext could conceivably be designed which are very sophisticated, but they are not proposed here.

Diese Lösung mochte CERN-intern funktionieren; sobald das World Wide Web allerdings wirklich “worldwide” wurde, wurde dieser Mangel kritisch. Stellen Sie sich einmal vor, Sie könnten die Website der Tagesschau aufrufen und den Text einer Nachricht einfach ändern und er wäre dann für jeden geändert, ohne dass an irgendeiner Stelle überprüft würde, wer Sie sind und ob Sie überhaupt berechtigt sind, diese Änderung vorzunehmen. Die praxisuntaugliche Funktionalität zum Ändern des Inhalts von Websites, wie Berners-Lee sie umsetzte, fehlte dann logischerweise bei nahezu allen öffentlichen Servern und Browsern.

Die Geschichte der Browser

Den Browsern und ihrer Entwicklung kam in der Geschichte des World Wide Web eine große Rolle zu. Das Web wurde nicht zentral kontrolliert. Daher konnte keiner wirklich bestimmen, was Webtechnologie ist und was nicht. Verschiedenste Nutzergruppen und Anbieter hatten natürlich ganz unterschiedliche Vorstellungen darüber, was die Technik leisten sollte. Der Wettstreit unter verschiedenen Browser-Entwicklern wurde gleichermaßen zu einem Innovationstreiber als auch zu einem Spaltpilz.

Die ersten Browser wurden am CERN entwickelt. Neben einem Browser für reine Textterminals war das vor allem der Browser “World Wide Web” von Tim Berners-Lee, von dem oben schon die Rede war. Er entwickelte die Software für NeXT-Computer, die ich Ihnen in meiner Geschichtserzählung bisher vorenthalten habe. Die Firma NeXT gehörte dem Apple-Mitgründer Steve Jobs, der bei Apple zwischenzeitlich in Ungnade gefallen war. Ende der 1990er Jahre kaufte Apple die Firma inklusive Jobs selbst und dem NeXT-Betriebssystem, das die Grundlage für Mac OS 10 darstellte.

Hier sehen Sie den Browser “World Wide Web”. Zu sehen sind zwei Fenster mit Webinhalten, von denen eines ein Bild zeigt. Das Bild befindet sich in einem Extrafenster. Bilder als Teil des Textes konnte der Browser nicht anzeigen und HTML sah dies zunächst einmal auch gar nicht vor, was natürlich selbst für nüchterne wissenschaftliche oder wirtschaftliche Dokumente eine gehörige Einschränkung war. Sollten Bilder verfügbar gemacht werden, wurden sie einfach verlinkt und konnten dann durch Anklicken in einem neuen Fenster geöffnet werden.

Nach einigen frühen Browserentwicklungen an Universitäten und Hochschulen, von denen die meisten für verschiedene Unix-Betriebssysteme entwickelt wurden, war der Browser NCSA Mosaic von 1993 derjenige, der für die frühe Popularität des WWW sorgte. Auch Mosaic war ein Universitätsprodukt, denn das National Center for Supercomputing Applications (NCSA) ist eine Organisation, die an der University of Illinois Urbana-Champaign angesiedelt ist. Die Software war allerdings nicht nur für Universitäten interessant, denn sie war einfach zu bedienen, einfach zu installieren und stand nicht nur für Unix, sondern auch für den Apple Macintosh und für Microsoft Windows zur Verfügung. Das herausragende Feature des Browsers war sicherlich die Anzeige von Bildern innerhalb des HTML-Dokuments. Persönlich sehr spannend finde ich aber eine Funktionalität, die in späteren Browsern gänzlich verloren gegangen ist und an der man die Herkunft von Mosaic im Wissenschaftsumfeld noch gut erkennen kann. Mosaic erlaubte es nämlich, Webdokumente mit Kommentaren zu versehen und das, wie im Folgenden beschrieben¹³, nicht nur persönlich, sondern auch in Arbeitsgruppen und sogar öffentlich.

Mosaic provides a mechanism whereby any piece of information on the Internet – in other words, any document that can be named by a URL – can be annotated with voice or textual comments. Such annotations are persistent across sessions and can themselves be annotated. There are several possible levels, or domains, of annotations: personal, workgroup, public, and global. Personal annotations are stored in the local file space of the user who makes the annotations and are visible only to that user. This is the default annotation domain.

Persönliche Anmerkungen wurden also lokal auf der Festplatte abgespeichert. Wollte man in einer Arbeitsgruppe Anmerkungen teilen, musste man sich einen entsprechenden Annotation-Server installieren.

Workgroup annotations are shared among a fairly small, fairly local group of people working together on a common problem. This is the type of asynchronous collaboration originally envisioned as a core capability of Mosaic. NCSA has developed a prototype workgroup annotation server that enables this type of collaboration. New annotations, if they are placed in the “workgroup domain” by the user making the annotation, are registered with the annotation server. Each time any member of the group accesses the annotated document, the annotation will then appear as a hyperlink virtually inlined – transparently merged, on the fly – into the bottom of the document.

Auch für allgemein-öffentliche Anmerkungen hatten die Programmierer von Mosaic Lösungen vorgesehen. Leider sind die entsprechenden Funktionalitäten nie wirklich zu Ende entwickelt worden. Die große Zeit des Browsers Mosaic war in der schnelllebigen Zeit des frühen Web wohl auch nicht lang genug, als dass sich ein solches Feature im größeren Sinne hätte durchsetzen können. Mehr auf Privatleute und die allgemeine Wirtschaft ausgelegte Browser setzten andere Prioritäten.

Im Jahr 1994 bereits erschien die erste Version des Netscape-Browsers¹⁴. Unter der Leitung von Marc Andreessen, einem der Hauptentwickler von Mosaic, wurde ein komplett neuer Browser entwickelt, der nun gar nichts mehr mit Universitäten zu tun hatte. Die Gestaltung der Nutzungsschnittstelle hatte höhere Priorität. Verwendet man mit den heutigen Nutzungsgewohnheiten Mosaic und Netscape¹⁵, kommt einem der Wechsel zu Netscape wie eine Offenbarung vor. Auf der Abbildung von Mosaic oben sehen Sie über dem Mauszeiger die Web-Adresse, die sogenannte URL. Was aussieht, wie eine auch heute noch bekannte Eingabezeile, ist gar keine. Es handelt sich um eine reine Ausgabe. Wenn sie eine Website öffnen wollen, müssen sie dies über das Öffnen-Menü tun und die Adresse dann ganz genau angeben, mit http:// vorweg. Ohne funktioniert es nicht. Beim Netscape dann hat die Adresszeile ihre heutige Funktionalität und auch andere heute selbstverständliche Features findet man, etwa die Möglichkeit, Lesezeichen anzulegen. Sehr prominent direkt als Button verfügbar (der 5. in der Buttonleiste) ist eine Funktion, die heute fast unverständlich wird: das Nachladen von Bildern.

Heute, in Zeiten schneller Netze und dauerhaft verfügbarer Netzwerkverbindungen, erscheint das Ausschalten von Bildern nicht mehr sinnvoll. Allenfalls Werbebilder möchte man manchmal gerne loswerden. Mitte der 1990er sah die Sache noch anders aus. Modems aus der Zeit hatten oft eine Geschwindigkeit von 9600 Bit/Sekunde. Bei 8 Bit für einen Buchstaben konnten also 1200 Buchstaben in einer Sekunde über eine Telefonleitung gehen. Das klingt nach viel, doch machen wir mal einen Vergleich: Im Oktober 2020 war die durchschnittliche Zugangsgeschwindigkeit in Deutschland 65 Mbit/s. Das ist über 6000-mal schneller. Ein Bild von 100 KiByte entspricht 100 x 1024 x 8 Bit = 819.200 Bit. Mitte der 1990er Jahre hätte die Übertragung dieser Datei bei idealen Bedingungen ganze 85 Sekunden gedauert, heute sind es noch 12,6 Millisekunden. Wollte man sich also nur schnell informieren, tat man gut daran, die Bilder auszuschalten, denn Bilddaten waren und sind naturgemäß viel größer als die reinen HTML-Inhalte. Hatte man die Bilder eingeschaltet, dauerte es ggf. nicht nur lange, sondern wurde dadurch auch teuer¹⁶. Außerdem war man dann stundenlang telefonisch nicht erreichbar, denn ein Modem verwendete ja die ganz normale Telefonleitung, um sich mit einem Provider zu verbinden. Bilder ausschalten konnte man sowohl in Netscape als auch in Mosaic. Kam man nun aber auf eine Website, auf der man die Bilder dann sehen wollte, konnte man beim Netscape diese mit nur einem Klick nachladen. Bei Mosaic musste man das Laden von Bildern einschalten, die Seite dann händisch neu laden und das Laden von Bildern dann für die nächste Seite ebenso händisch wieder abschalten. Der Knopf war keine große Sache, aber doch ungemein praktisch.

Abgesehen von genannten Verbesserungen in der Nutzungsschnittstelle bestanden die neuen Funktionen des Netscape für Anbieter vor allem in mehr Einfluss auf das Aussehen, wodurch sich attraktivere Websites erstellen ließen. Bereits in Version 1.1 konnten HTML-Autoren den normalerweise grauen Texthintergrund durch ein Bild ersetzen lassen:

<BODY BACKGROUND="tisch.gif">
<P>Diese Seite hat einen Holztisch-Hintergrund</P>

In Version 2 erfand Netscape einige weitere Tags und Attribute, um das Aussehen des Textes zu beeinflussen.

<P>Hier kommt <FONT SIZE=+2 FACE="arial,helvetica" COLOR="red">
ganz besonderer</FONT> Text.</P>
<CENTER>Dieser Text ist zentriert.</CENTER>

Verwendeten Anbieter von Websites diese Tags, konnte das ein Problem werden, denn zunächst konnte nur Netscape etwas damit anfangen. Ein älterer Browser wie Mosaic ignorierte diese neuen Tags einfach. Oft war das egal, aber wenn der <FONT>-Tag dafür benutzt wurde, um, zum Beispiel unter einer Menge von Möglichkeiten, durch grüne Farbe die korrekte herauszustellen, dann fehlte diese Information schlimmstenfalls völlig. Probleme dieser Art sollten noch schlimmer werden, denn Netscape sollte nicht der einzige erfolgreiche Browser-Hersteller bleiben und andere Entwickler erfanden andere Tags und unterstützten ihrerseits die von Netscape erfundenen nicht unbedingt oder nur teilweise.

Der erste Netscape-Browser war ab Dezember 1994 verfügbar. Zu diesem Zeitpunkt war die Firma Microsoft schwer beschäftigt mit dem Abschluss der Entwicklung ihres neuen Betriebssystems Windows 95, das im August 1995 auf den Markt kam und das Arbeiten im PC-Bereich mit der neuen Nutzungsoberfläche und den multimedialen Fähigkeiten stark veränderte. So wie es auch heute noch üblich ist, waren bei Windows 95 manche Programme vorinstalliert, darunter zum Beispiel die simple Textverarbeitung WordPad, das Grafikprogramm Paint und das Programm HyperTerminal zur Verbindung mit entfernten Rechnern. Ein Webbrowser jedoch war nicht mit dabei. Es wird gerne behauptet, dass Bill Gates, der Mitgründer und damalige Chef von Microsoft, noch 1993 das Web als Hype bezeichnet habe und dass man sich bei Microsoft um Wichtigeres kümmern solle. Wie so oft ist nicht belegt, und wahrscheinlich auch gar nicht belegbar, dass es diese Aussage so überhaupt gegeben hat. Selbst wenn es so gewesen sein sollte, gäbe es eigentlich keinen wirklichen Grund, sich über die Aussage lustig zu machen. 1993 war das WWW ja noch überhaupt nicht verbreitet, die allermeisten Inhalte kamen von Forschungsinstituten. Die Websites waren reine Textwüsten und Zugang zum Web war für Privatleute kaum zu bekommen. Onlinedienste wie CompuServe und AOL erfreuten sich hingegen größer werdender Beliebtheit. Im Web nicht die Revolution zu sehen wäre zu diesem Zeitpunkt keine absurde Einschätzung gewesen. Im Nachhinein mit Schadenfreude darüber herzuziehen ist wohlfeil. Die Aussage wird im Übrigen, unabhängig davon, ob es sie gegeben hat oder nicht, gerne noch unzulässig ausgedehnt. In der deutschen Wikipedia findet sich zum Beispiel die Aussage, dass “Bill Gates und somit auch Microsoft zu Zeiten von Windows 95 nicht an den Erfolg des Internets glaubten”¹⁷. Das ist ganz nachweislich und belegbar falsch, denn schon im Mai 1995, also noch vor dem Erscheinen von Windows 95, schrieb Gates in einem Memo von einer “Internet Tidal Wave”, der man sich nun ganz hingeben solle, und die man sogar dominieren wolle. Auch in öffentlichen Fernsehauftritten im Jahr 1995 wurde Gates nach dem Internet befragt. Er schwärmte dort davon in den höchsten Tönen und bezeichnete es als “Next Big Thing”.

Hatte man die erste Version von Windows 95 ohne mitgelieferten Browser installiert, konnte man sich natürlich Netscape nachinstallieren. Der Browser war auf vielen der damals verbreiteten Zeitschriften-CDs enthalten. Auch einen Browser von Microsoft, den Internet Explorer, konnte man sich bald besorgen, denn Microsoft bot für etwa 50 Dollar ein sogenanntes Plus-Paket für Windows 95 an und das beinhaltete neben Hintergrundbildern, Bildschirmschonern, Mauszeigern und Systemsounds auch den eigenen Browser. Die Softwarefirma hatte kurz entschlossen einen Browser der Firma Spyglass¹⁸ lizensiert. Der erste Internet Explorer wurde nur von sehr wenigen Leuten genutzt. Erst Version 3 im Jahr 1996, die in aktualisierten Windows-95-Versionen dann vorinstalliert war und die auch vielfach bei Softwareinstallationen mitgeliefert wurde, wurde populär. Version 4 aus dem Jahr 1997 überholte bereits Netscape. 1998 hatte Microsoft dann den sogenannten “Browserkrieg” praktisch gewonnen. Die Gründe dafür waren vielfältig. Zum einen war Microsoft in Sachen Features zum damaligen Zeitpunkt durchaus innovativ und setzte mit dem Internet Explorer Maßstäbe. Andererseits ließ Microsoft der Konkurrenz von Netscape kaum eine Chance. Im oben bereits erwähnten Dokument, dem mit der “Tidal Wave”, verkündete Bill Gates das Ziel, das Internet dominieren zu wollen, und diesem Ziel ging man mit allen Mitteln nach. Nicht nur, dass der Internet Explorer ab Version 3 vorinstalliert und mit Windows 98 fest ins Betriebssystem integriert wurde, Microsoft setzte sogar die Computerhersteller unter Druck. Wollten diese ihre Computer mit Windows ausliefern – was natürlich fast jeder Hersteller wollte –, dann durfte dies nur ohne vorinstallierten Alternativbrowser geschehen. Wollte der Hersteller einen anderen Browser mitliefern, bekam er keine Windows-Lizenz. Dieses Verhalten wurde später Gegenstand von Gerichtsverhandlungen, die für Microsoft nicht erfreulich waren. Der Firma Netscape brachte das allerdings nichts mehr.

In den 4er-Versionen der Browser war der Browserkrieg zwischen Netscape und Internet Explorer noch auf seinem Höhepunkt – und auch die Inkompatibilitäten zwischen den Browsern erreichten ihr Maximum. Beide Browser ermöglichten inzwischen dynamische Inhalte, bei denen sich Elemente auf der geladenen Seite je nach Eingabe änderten. Einfache Beispiele hierfür, die damals auch sehr populär waren, waren Navigationsmenüs, bei denen man die Oberpunkte aufklappen konnte, sodass die Unterpunkte sichtbar wurden. Die Technik ermöglichte aber weitaus mehr bis hin zu komplett in Webtechnologie programmierten Anwendungen und Spielen. Das Problem war nun aber, dass Microsoft und Netscape ganz verschiedene HTML-Tags, ganz verschiedene Techniken zur Programmierung und Formatierung anboten. Websites, die für den Internet Explorer gestaltet wurden, konnten im Netscape nicht gescheit angesehen werden und umgekehrt. Man stand als Anbieter also vor einem Problem. Manche entschieden sich für einen der Browser und präsentierten den Nutzern des anderen einen unfreundlichen Hinweis, dass sie das falsche Programm verwendeten. Andere machten sich entweder die Mühe und erstellten zwei Versionen ihrer Websites oder bissen in den sauren Apfel und verzichteten ganz auf die modernen Features.

Die Spaltung des Web war aufgrund der offenen Gestaltung natürlich von vornherein ein mögliches Problem. Es gab daher schnell Bestrebungen, die Webtechnologie zumindest ein bisschen beisammenzuhalten und für Kompatibilität zu sorgen. Zunächst kümmerte sich eine Gruppe am CERN selbst darum und zwischenzeitlich gab es eine entsprechende Gruppe der IEEE¹⁹. Recht zügig bildete sich dann das W3C, das World Wide Web Consortium. Hier arbeiten alle großen Softwarehersteller zusammen und legen Spezifikationen für Webtechnologie fest. Die erste definierte Version von HTML hatte die Nummer 2.0 und wurde im November 1995 publiziert. 1997 folgte die Version 3.2. Die einleitenden Worte dazu weisen darauf hin, wie der Standard erstellt wurde:

HTML 3.2 is W3C’s specification for HTML, developed in early `96 together with vendors including IBM, Microsoft, Netscape Communications Corporation, Novell, SoftQuad, Spyglass, and Sun Microsystems. HTML 3.2 adds widely deployed features such as tables, applets and text flow around images, while providing full backwards compatibility with the existing standard HTML 2.0.

Die Browserhersteller setzten sich also zusammen und schrieben eine Definition, die aus dem bestand, was sich in ihren Browsern als erfolgreich erwiesen hat und worauf sie sich untereinander einigen konnten. Dieser Ansatz hatte dann seine Probleme, ab dem es nur noch einen einzigen nennenswerten Browseranbieter gab. Was der implementierte, war faktisch Standard, und was in der W3C-Vorgabe stand, aber vom Internet Explorer nicht umgesetzt wurde, konnte faktisch auch nicht angewandt werden.

1998 hatte Microsoft den Browserkrieg gewonnen. Netscape stellte den Programmcode seines Browsers frei zur Verfügung und gründete die Mozilla-Organisation. Diese machte sich an eine Neuentwicklung, aus der 2002 der erste Firefox-Browser hervorging. Firefox hatte es allerdings sehr schwer gegen den Internet Explorer. Der erschien 2001 in Version 6 und war ein für die damalige Zeit ordentlicher Browser. Er war stark in die Betriebssysteme von Microsoft eingebunden, namentlich in das brandneue Windows XP. Da ihn so viele Nutzer verwendeten, gestalteten fast alle Anbieter von Websites diese so, dass sie mit dem Internet Explorer problemlos funktionierten. Das Problem der Marktführerschaft ohne nennenswerte Konkurrenz war, dass Microsoft sich mit der Weiterentwicklung sehr viel Zeit lassen konnte. Erst 2006 erschien die Nachfolgeversion 7. Leider, und hier spreche ich aus eigener Erfahrung, blieb der “IE6”, wie er meist abgekürzt wurde, als Untoter noch länger das Maß aller Dinge, denn viele verwendeten ihn auch weiterhin. Microsoft hatte sich nämlich entschlossen, etwas gegen illegale Kopien seines Windows zu tun. Das bedeutete unter anderem, dass die Aktualisierung des Internet Explorers auf Version 7 auf Windows-Versionen, die nicht bei Microsoft legal erworben und registriert wurden, verhindert wurde - und das waren nicht ganz wenige²⁰. Eine andere Gruppe, die den alten Internet Explorer länger verwendete, fand sich erstaunlicherweise in vielen Firmen, denn da der IE6 so lange aktuell war, wurden viele interne Webanwendungen genau auf diesen Browser abgestimmt. Der Internet Explorer 7 hatte viele der Fehler der Version 6 nicht mehr und entsprach viel mehr den Vorgaben des W3C, und genau damit konnte er die Unternehmens-Webanwendungen nicht mehr korrekt anzeigen.

Mit der Vorherrschaft des Internet Explorers stagnierte die browserseitige Weiterentwicklung des WWW faktisch für fast ein Jahrzehnt. Eine Besserung dieser Situation ergab sich erst Ende der Nuller-Jahre, zum einen mit der Vorstellung des iPhone und der darauffolgenden Smartphone-Welle und zum anderen damit, dass Google seinen eigenen Browser Chrome auf den Markt warf. Dieser konnte schnell Marktanteile gewinnen und ist inzwischen selbst recht unangefochten Marktführer – zumindest im Bereich der klassischen Personal Computer.

Das Web als Plattform

Das World Wide Web hat sich weit fortentwickelt vom ursprünglichen Zweck der Zugänglichmachung von Dokumenten am CERN. Dafür, dass das so kam, gab es viele Einflussfaktoren, wobei Ursache und Wirkung oft gar nicht zu trennen sind. Die frühe Webtechnologie an sich war offenbar attraktiv sowohl für Anwender als auch für Anbieter, waren dies Universitäten, öffentliche Stellen oder auch Firmen. Die Seiten wurden immer aufwändiger, da die Browser für die Seitenanbieter immer mehr Gestaltungsfeatures anboten. Neue Features im Browser führten zu neuen Ideen bei den Anbietern und Nutzern und diese führten ihrerseits wieder zu Weiterentwicklungen im Browserbereich. Komplexere und reichhaltigere Websites benötigten immer mehr Bandbreite. Die allgemeine Verfügbarkeit höherer Bandbreiten und die dauerhafte Verfügbarkeit des Netzes ermöglichten im Gegenzug wieder Nutzungsszenarien, die vorher gar nicht denkbar waren. Die Konkurrenz unter Anbietern, sowohl was die Browser, die Zugangsprovider als auch die Diensteanbieter anging, sorgte in einer komplexen Wechselwirkung für eine Weiterentwicklung von Technik und Nutzungsformen.

Das Web heute ist eine Plattform, eine Ansammlung von Technologien in Browsern und auf Servern, mit denen nicht nur Web-Seiten, sondern auch Web-Anwendungen erzeugt werden können. Wie oben beschrieben, waren die Grundzüge dafür ja bereits im Ur-Web am CERN vorgesehen, wenn man die Anbindung des Telefonbuchs und anderer Auskunftssysteme des CERN an das Web als sowas ansehen möchte. Damals handelte es sich natürlich noch um relativ simple Anfragen. Komplexere Anwendungen waren aus vielerlei technischen Gründen zunächst nur schwer möglich.

Das Hauptproblem war die Gedächtnislosigkeit des HTTP-Protokolls. Denken Sie nochmal an meinen Vergleich des HTTP-Servers mit jemandem, der ein Telefon abnimmt, dem dann gesagt wird, was man vorgelesen haben will, der das dann vorliest und der dann direkt wieder auflegt. In diesem ganzen Prozess hat man sich nie mit Namen oder irgendeinem Erkennungszeichen gemeldet. Wenn Sie den gleichen Server nochmal “anrufen”, dann kennt er Sie nicht mehr. Jeder Anruf ist unabhängig vom anderen. Dem kann man mit einem Trick abhelfen. Der Server kann Ihnen bei der ersten Antwort eine Kennung mitgeben. Bei jedem weiteren Kontakt geben Sie diese Kennung wieder an. Wofür braucht man das? Zum Beispiel, wenn Sie einen Bestellvorgang auf einer Website haben, dann machen Sie ja nicht alle Angaben auf einer Seite, sondern durchlaufen mehrere Seiten hintereinander. Damit das vernünftig funktionieren kann, müssen diese Angaben natürlich miteinander in Verbindung gesetzt werden können. Sonst wüsste die Website dann, wenn Sie die Kreditkarteninformationen eingeben, schon nicht mehr, wer Sie eigentlich sind und was Sie kaufen wollen.

Die einzelnen HTML-Seiten waren in der Browser-Anzeige zunächst statisch. Die frühen Browser konnten eine HTML-Seite vom Server abrufen und anzeigen. Das einzig Dynamische dann war das Scrollen im Browser, falls das Dokument länger als eine Bildschirmseite war. Sollte etwas Neues, etwa etwas Aktualisiertes auf der Seite erscheinen, musste man sie manuell neu laden oder auf einen Link zu einem anderen Dokument klicken. Wirklich interaktive Anwendungen waren so kaum möglich, denn das Neuladen war langsam und erfolgte immer nur auf explizite Anforderung des Nutzers. Im Laufe der Jahre wurden verschiedenste Techniken ersonnen, um dieses Problem zu umgehen oder abzuschaffen.

Die Versionen 3 der Browser von Microsoft und Netscape ermöglichten die Einbindung von Java-Applets. Java war und ist eine recht verbreitete Programmiersprache, die auch heute noch vielfach eingesetzt wird und an Schulen und Universitäten gelehrt wird. Einer der großen Vorteile der Sprache war, dass die damit erzeugten Programme plattformunabhängig waren, es also egal war, ob man sie unter Windows, unter Linux oder auf einem Macintosh laufen ließ. Sie liefen überall gleichermaßen. Das machte Java für das Web interessant. Viele Java-Programme haben gar keine Nutzungsschnittstelle, sondern laufen auf den Servern im Internet, also auf den Computern, die Dienste anbieten, auf die man aus der Ferne zugreifen kann. Java-Programme mit Nutzungsschnittstelle sehen in den jeweiligen Betriebssystemen meist nicht anders aus als die übrige Software, die dort sonst so läuft – sie wird also in der Regel in einem Fenster angezeigt. Ein Java-Applet hingegen hatte kein Fenster, sondern wurde in eine HTML-Seite eingebunden, genauso wie ein Bild. In einem Bereich der geladenen HTML-Seite lief dann ein Programm mit all dem, was in Java so möglich war, von der Office-Anwendung bis zum Spiel. Die Applets konnten sogar ihrerseits Verbindungen ins Netz aufnehmen und Daten von dort beziehen.

Bereits in Version 2 des Netscape-Browsers war es möglich, kleine Programme in der Programmiersprache JavaScript in die Website einzubinden. Obwohl der Name JavaScript es nahelegt, hat diese zum damaligen Zeitpunkt noch sehr einfache Programmiersprache nur wenig mit Java zu tun. JavaScript wurde für sehr simple Aufgaben benutzt. Man konnte mit ihr zum Beispiel prüfen, ob eine eingegebene E-Mail-Adresse das richtige Format hatte, also etwa, ob ein @-Zeichen in ihr vorkam. JavaScript konnte auch eine Brücke zu einem Java-Applet sein, also zum Beispiel auf der Website eingegebene Daten an das Applet weitergeben und vom Applet erzeugte Daten auf die Website schreiben. Merken Sie, was durch diese Kombination aus JavaScript mit Zugriff auf den HTML-Inhalt und Java-Applet mit der Möglichkeit des Netzwerkzugriffs möglich wird? Zum Beispiel könnte ein Applet alle paar Sekunden aus dem Netz die aktuelle Temperatur in Palma de Mallorca abrufen und diese an das JavaScript weitergeben, das sie dann an einer bestimmten Stelle im Dokument anzeigt. Es konnten also Inhalte nachgeladen werden. Wirklich im großen Stil durchgesetzt hat sich eine solche Teilaktualisierung der Seite aber erst erheblich später.

Java-Applets hielten sich nicht lange, was unter anderem daran gelegen haben dürfte, dass gut aussehende Nutzungsschnittstellen und multimediale Inhalte nicht gerade die Stärke von Java waren. Ab 1997 liefen Flash-Inhalte den Applets den Rang ab. Unter dem Namen Flash bot die Firma Macromedia seinerzeit ein Produkt an, mit dem sich grafische Szenen und Animationen programmieren ließen. Für Webbrowser entwickelte Macromedia ein “Plugin”, also ein kleines Zusatzprogramm, das ein Einbinden der Flash-Inhalte in die HTML-Dokumente erlaubte, ganz so, wie es auch bei den Java-Applets möglich war. Auch hier konnte JavaScript als Brücke verwendet werden. Flash-Inhalte waren aufgrund der guten Grafik-, Sound- und Videofeatures vor allem bei vielen Werbeagenturen beliebt, was dazu führte, dass manche Website gar keine klassischen HTML-Inhalte mehr bereitstellte, sondern dass nur bildschirmfüllend ein Flash-Inhalt eingebunden wurde. Kein Wunder, denn so konnte man bunte, animierte Buttons realisieren, die Geräusche machten, wenn man darauf klickte und die Inhalte, die dann aufgerufen wurden, konnten animiert hinein- oder hinausgeschoben werden. Das Ganze konnte also sehr interaktiv sein und, ebenso wie die Java-Applets, sich selbst aus dem Netz mit Daten versorgen. Der Einsatz von Flash hatte allerdings auch seine Nachteile. So ließen sich Flash-Inhalte kaum ausdrucken, waren für Suchmaschinen schlecht zu finden, einzelne Seiten waren nicht mehr über eine eigene Webadresse verfügbar und das Ganze verlangte den damaligen Computern einiges ab. Bei vielen Nutzern der Websites waren Flash-Inhalte daher überhaupt nicht beliebt.

Die Flash-Technik blieb den Websurfern recht lange erhalten. Zu Ende ging es mit ihr erst mit dem Aufkommen von Smartphones ab dem ersten iPhone im Jahr 2007, denn auf dem iPhone und auch auf den meisten Android-Geräten liefen Flash-Inhalte nie. Um diese Zeit herum gab es aber ohnehin viele Umbrüche. Google beglückte die Welt mit seinem eigenen Browser namens Chrome, der sehr schnell große Beliebtheit bekam. Apple schaffte es, dem iPhone einen Browser zu spendieren, der Websites, mit Ausnahme von Flash und Applets, sehr gut auf dem kleinen Bildschirm darstellen konnte. Microsoft brachte im Jahr 2009 nicht nur das neue Betriebssystem Windows 7 heraus, sondern spendierte diesem nach langer Zeit auch eine neue Version des Internet Explorers. Bei den wichtigen Playern in Sachen Browsern war also viel los. Dies äußerte sich auch darin, dass eben diese Player, Apple, Google, Mozilla (der Organisation hinter Firefox) und Microsoft sich zusammensetzten und eine neue HTML-Definition entwickelten. Diese HTML-Version, die dann als HTML5 bekannt wurde, hob den Browser nun in ganz neue Höhen. 2015 wurde sie fertig. Seitdem wird HTML ohne Versionsnummer weiterentwickelt. Der sogenannte “lebende Standard” enthält stets das, was sich bewährt hat und worauf sich die Browserhersteller geeinigt haben.

Die Techniken, die seit Mitte der 2000er hinzugekommen sind, machten Browser quasi zu kleinen Computern in sich, zu einer Sammlung von technischen Einrichtungen, mit denen netzbasierte, komplexe und multimediale Anwendungen umgesetzt werden können:

• Die Fähigkeiten der Formatierung von Text und Bild sowie die Positionierung und Animation von Elementen im Browser sind inzwischen so umfangreich, dass webbasierte Nutzungsschnittstellen den nativen Anwendungen in fast nichts mehr nachstehen. Ganz im Gegenteil ist es inzwischen oft so, dass sich auch “normale” Programme den Webtechnologien als Nutzungsschnittstelle bedienen.
• Die Programmiersprache JavaScript wurde standardisiert und verbessert. Die sogenannten JavaScript-Engines in den Browsern wurden immer weiter optimiert, was dazu führt, dass in modernen Browsern die JavaScript-Programme sehr performant ausgeführt werden können. Mit aktuellem JavaScript lassen sich komplexe Programme umsetzen, die zügig laufen.
• Um 2005 kam die AJAX²¹-Technik auf. Dahinter steht die Möglichkeit, dass ein JavaScript-Programm im Hintergrund Kontakt zum Webserver aufnehmen kann, um Daten dort abzurufen oder dort hinzuschicken, ohne dass eine komplett neue Seite geladen werden müsste. Dies verringerte nachhaltig die Notwendigkeit für Java-Applets oder Flash-Inhalte.
• Die AJAX-Technik wurde ergänzt um WebSockets, bei denen ein Webserver eine länger andauernde Verbindung zu einem Server herstellt. Hierdurch wurde es möglich, dass Server und Browser zügig Daten austauschen und dass ein Server einem Browser Nachrichten schicken kann, ohne dass diese explizit angefragt werden müssten. Wofür das gut ist, kann man sich an einem Chat gut klarmachen. Mit klassischer Web-Technologie müsste man eine Chatseite regelmäßig neu laden, um zu schauen, ob neue Nachrichten eingetroffen sind. Mit der AJAX-Technik würde dies im Hintergrund automatisch erledigt. Eine Webanwendung mit AJAX könnte zum Beispiel alle fünf Sekunden neue Daten anfragen und die Anzeige aktualisieren. Besteht hingegen eine WebSocket-Verbindung, braucht es diese Nachfrage nicht mehr. Vielmehr schickt der Server die Nachrichten über die aktive Verbindung selbst an den Browser ohne Verzögerungen.
• Das <canvas>-Element von HTML5 schafft eine Grafikfläche, auf die ein JavaScript-Programm pixelbasiert zeichnen kann. Es dient Webanwendungen zur Abspielfläche für grafiklastige Anwendungen von der webbasierten Bildbearbeitung bis zum komplexen Spiel.
• Für Algorithmen und Programmmodule, die trotz optimierter JavaScript-Engines nicht performant genug laufen, besteht die Möglichkeit, diese in einer typischen höheren Programmiersprache zu programmieren und dann in eine Webassembly-Datei übersetzen zu lassen²². Der Browser kann diese dann ausführen. Programme, die auf diese Art geschrieben werden, laufen zwar nicht so schnell wie normale, ausführbare Programme, sind aber doch erheblich schneller als in JavaScript geschriebene Software.

Übrigens: Auch auf der Server-Seite blieb die Entwicklung der Webtechnologie natürlich nicht stehen. Da die Nutzungsschnittstellen, um deren Betrachtung es in diesem Buch ja in erster Linie gehen sollte, aber natürlich nicht beim Server, sondern im Browser liegen, erspare ich Ihnen die Geschichte der serverseitigen Webprogrammierung an dieser Stelle.

Betrachtet man das WWW heute, erscheint es einem überhaupt nicht mehr wie ein einfaches Hypertext-System für wissenschaftliche Texte, als das es geplant wurde. Ein moderner Browser ermöglicht die Text- und Grafikanzeige in diversesten Formaten inklusive Vektorgrafik. Vor allem aber ermöglicht der Browser die Umsetzung von komplexer Software, von in Web-Seiten selbst eingebetteten Logik-Inhalten und kleineren interaktiven Elementen bis hin zu vollständigen Anwendungen. Die moderne Browser-Technik ermöglicht Software, die teils auf dem Server läuft, teils beim Anwender selbst, also im Browser. Selbst eine dauerhafte Internetverbindung ist dafür heute nicht mehr vonnöten. Einmal geladene Webanwendungen können, wenn die entsprechenden Vorkehrungen getroffen wurden, auch offline arbeiten. Selbst Bearbeitungen von Inhalten sind bei geschickter Programmierung offline möglich. Wenn wieder eine Internetverbindung zur Verfügung steht, werden die zwischengespeicherten Bearbeitungen dann automatisch mit dem Server synchronisiert. Das heutige Web ist eine technische Plattform. Alles kann heute im Browser laufen, von Spielen über Textverarbeitungen, Grafikbearbeitung bis zu Lerntools. Wenn Sie das Kapitel zu den Bildschirmtextdiensten nochmal anschauen, fällt Ihnen vielleicht auf, dass ein heutiger Browser ziemlich ähnlich zu dem ist, was man sich in Graz für das Mupid ausgedacht hat. Ein Browser kann vorbereitete Inhalte aus dem Netz zeigen, kann aber auch mit lokal gespeicherten Seiten arbeiten. Ein Browser kann in eine Seite eingebettete Software ausführen und eignet sich sogar auch selbst als Plattform für Software. Diese Software kann das Netz ihrerseits als Kommunikationskanal und als Speichermedium nutzen. All das hatten wir schon beim Mupid in den 1980er Jahren.

Die Potenziale des Hypertext

Ob Hermann Maurer aus Graz meine Charakterisierung aktueller Browser als moderne Mupids wohl gefallen würde? Einerseits wahrscheinlich schon, schließlich war der Mupid ja sein Kind. Er und seine Kollegen hatten eine Idee, die, was mit heutigen Browsern möglich ist, schon sehr früh umsetzte. Andererseits könnte Maurer vom Web auch ziemlich enttäuscht sein, denn er und seine Kollegen sahen großes Potenzial im Konzept des Hypertext und in der Beziehung war und ist das WWW ein ziemlicher Reinfall. Maurer und Kollegen hatten eine Alternative zu bieten, die sich allerdings gegen das WWW nicht durchsetzte.

Die Hypertextidee wird häufig auf ein Konzept aus dem Jahr 1945 zurückgeführt. Damals beschrieb der Ingenieur Vannevar Bush ein hypothetisches Gerät namens Memex. Oben ist es abgebildet. Was Sie dort sehen, ist kein Computer in dem Sinne, wie ich ihn in diesem Buch vorgestellt habe. Digitale Computer waren 1945 noch an einer Hand abzuzählen und das, was Bush mit dem Memex vorhatte, gehörte damals sicher nicht zu dem, wofür man die Rechenknechte nutzen wollte. Bush ging es bei seinem Gerät nicht ums Rechnen, sondern um die Unterstützung der Wissensarbeit durch moderne Technologie. Zentral war hier eine komplexe Mechanik und die Mikrofilmtechnik, eine Archivierungstechnologie, bei der Buchseiten und Dokumente abfotografiert und dann extrem verkleinert auf einem Filmstreifen abgelegt wurden. Mittels entsprechender Sichtgeräte konnten die Dokumente wieder sichtbar gemacht werden. Wirklich umgesetzt wurde die Memex-Idee damals nicht, auch wenn die technischen Komponenten grundsätzlich existierten. Das Ganze war nicht als Bauanleitung, sondern als Denkanregung gedacht. Lassen wir die innere Architektur des Memex daher beiseite und betrachten die intendierte Nutzungsschnittstelle des Geräts, also das, was oben auf der Tischplatte zu sehen ist.

Zentral sehen Sie zwei Bereiche, in denen Dokumente dargestellt werden können. Verwenden wir der Einfachheit halber den Begriff “Bildschirm” dafür. Mittels der Knöpfe rechts können für beide Bildschirme Dokumente aus dem Dokumentarchiv abgerufen werden. Dieses Archiv war groß angedacht – quasi eine ganze Bibliothek. Zwei Dokumente gleichzeitig im Blick zu haben ist sicher nicht unpraktisch, aber nun auch nicht revolutionär. Spannend war die von Bush beschriebene Technik, Dokumente miteinander in Verbindung setzen zu können. Bush sprach hier von einem Trail, also einem Pfad durch Dokumente zu einem bestimmten Thema. Diese Trails hätten einen Namen bekommen und wären in einer Memex unabhängig von den Dokumenten selbst abgespeichert worden. Durch Angabe des Namens über eine Tastatur hätte man einen Trail wieder hervorbringen können. Sogar die Möglichkeit, den Dokumenten Informationen hinzuzufügen oder neue, eigene Dokumente einzufügen, hatte Bush im Blick, denn seine Idee eines Memex enthielt auch Vorrichtungen zur Fotografie und zur Erstellung neuer Mikrofilme. Diese Vorrichtung war auch für ein weiteres wichtiges Feature notwendig, denn da Bush natürlich klar war, dass Wissensarbeit keine Ein-Personen-Show ist, sah er vor, dass ein kompletter Trail von der Maschine auf einen Mikrofilm hätte ausbelichtet werden können, um ihn an andere Wissensarbeiter weiterzugeben. Diese hätten ihn dann in ihre eigene Memex eingelegt, um die Dokumente in ihrem Zusammenhang zur Verfügung zu haben und nun selbst weiterverarbeiten zu können.

Die Ideen der Memex nahmen zentrale Elemente von dem vorweg, was später unter dem Begriff Hypertext diskutiert wurde. Der Begriff selbst und viele der zentralen Konzepte gehen auf Ted Nelsons Projekt Xanadu zurück. Xanadu ist bekannt dafür, seit 1960 in Entwicklung zu sein, wohl aber nie komplett fertig zu werden. Das gesamte Konzept dahinter hätte, wenn es denn umgesetzt worden wäre, sogar Lösungen für Urheberrechtsprobleme und die Bezahlung für referenzierte und zitierte Inhalte gehabt. Auf all das kann und will ich hier nicht eingehen. An einem tatsächlich existiert habenden System namens Intermedia will ich Ihnen aber ein von Memex schon bekanntes Potenzial verdeutlichen, das auch bei Xanadu eine ganz zentrale Rolle spielte.

Intermedia wurde ab Mitte der 1980er Jahre an der Brown University in den USA entwickelt. Es lief auf dem Betriebssystem A/UX, einem Unix-Derivat von Apple, das auf den leistungsfähigeren Macintosh-Geräten ausgeführt werden konnte. Das System ist ein interessanter Hybrid, denn es verfügte einerseits über die Nutzungsschnittstelle von MacOS mit seinen Menüs, Fenstern und Icons, hatte aber andererseits auch den kompletten Unix-Unterbau mit seinen Multitasking-Funktionalitäten und der Netzwerkfähigkeit. Das System war in dieser Hinsicht dem NextStep, auf dem Tim Berners-Lee das World Wide Web entwickelte, nicht ganz unähnlich. Vor allem war es aber genau wie dieses ein absolutes Nischenprodukt.

Hier sehen Sie Intermedia im Stand von etwa 1988. Grundobjekte des Systems sind Dokumente verschiedenster Art. Zunächst einmal hatte das System daher die grundsätzlichen Funktionalitäten damaliger Desktop-Systeme. Es gab, neben einigen spezielleren Anwendungen, vor allem eine einfache Textverarbeitung und ein Tool zur Erstellung und Bearbeitung von Grafiken. Da es auf einem Unix-System basierte, verfügte Intermedia über eine komplexe Rechteverwaltung und war netzwerktauglich. Dokumente konnten also lokal oder auch auf einer Netzwerk-Festplatte gespeichert sein. Wie es sich für ein Hypertext-System gehört, waren natürlich Verknüpfungen ein zentrales Konzept. Diese waren aber nun nicht, wie beim Web, in das Dokument selbst eingebaut (in HTML schreibt man ja <A>-Tags in die Dokumente), sondern waren, wie die Trails bei der Memex, als zusätzliche Objekte gespeichert. Dokumente in Intermedia enthielten selbst also keine Links. Ein Nutzer konnte trotzdem Links anlegen, die dann im Dokument dargestellt wurden. Oben in der Abbildung ist dieser Vorgang dargestellt. Zunächst wurde in einem Dokument ein Stück Text markiert und im Menü “Start Link” ausgewählt. Dann wurde in einem anderen Dokument Text markiert und der Link mit “Complete Link” vervollständigt. So wurden zwei Textstellen miteinander verbunden. Diese Verbindung war bidirektional. Man kam also, wie beim Memex, nicht nur vom ersten Dokument zum zweiten, sondern auch vom zweiten zum ersten. Die Links wurden zwar im Dokument angezeigt, nicht aber im Dokument abgespeichert. Das Dokument existierte nach wie vor als unabhängiges Objekt. Die Links wurden in einem sogenannten Web (das nichts mit dem World Wide Web zu tun hat) abgespeichert. Ein Web verband die Dokumente. Wollte man die Dokumente als verlinkt im Zusammenhang sehen, musste man immer auch ein Web laden. Schloss man das Web wieder, waren alle Links verschwunden und die Dokumente erschienen wieder jungfräulich. Öffnete man das Web, erschienen auch die Links erneut. Diese Trennung öffnete Potenziale, die das Web nicht erfüllen konnte.

• Link setzen ist bei Intermedia nicht die Aufgabe der Autoren. Das Konzept von Intermedia war es, dass die Nutzer Links setzten. Diese Funktionalität wurde an der Brown University in der Lehre genutzt. Studierenden wurden Dokumente zur Verfügung gestellt, die sie zum Teil erweitern, vor allem aber selbst verknüpfen sollten.
• Das heißt, dass man auch in Dokumente, für die man keine Schreibrechte hatte, die man also nicht bearbeiten durfte, dennoch Links einfügen konnte.
• Verschiedene Nutzer konnten unabhängig voneinander die gleichen Ressourcen auf verschiedene Arten und Weisen verlinken, indem sie jeweils ein eigenes Web erstellten.
• Links konnten durch Weitergabe von Webs also geteilt werden oder aber auch privat bleiben.

Intermedia war als auf Unix basierendes System natürlich netzbasiert. Es war aber nicht als öffentliche Ressource à la World Wide Web gedacht, sondern bezog sich auf lokale Arbeitsgruppen im Universitätskontext. Hier kommen Herman Maurer und seine Kollegen wieder ins Spiel. Seine Gruppe in Graz entwickelte, stark von Intermedia inspiriert, ein internetbasiertes Hypertextsystem namens Hyper-G, das später in Hyperwave umbenannt wurde. Oben sehen Sie, dass es über ein vergleichbares Feature verfügte, denn auch hier ließen sich Dokumente miteinander verknüpfen, ohne dass es einer Änderung der Dokumente selbst bedurft hätte. Links wurden auf unabhängigen Servern in von den Dokumenten unabhängigen Datenbanken gespeichert. Interessanterweise waren solche Features wohl durchaus auch einmal für das World Wide Web zumindest angedacht. Das Proposal von 1989 besagte nämlich: “One must be able to add one’s own private links to and from public information. One must also be able to annotate links, as well as nodes, privately.” Die Aussage ist einigermaßen erstaunlich, denn Konzept und Technologie des WWW gaben ein solches Feature überhaupt nicht her und tun es in ihrer Kerntechnologie auch heute noch nicht.

Fassen wir zusammen, muss man dem WWW natürlich einen großen Erfolg bescheinigen und muss zum anderen auch anerkennen, dass das heutige Web eine potente technische Plattform für netzbasierte Anwendungen aller Art ist. Betrachtet man jedoch die Potenziale des Hypertexts, ist das Web keine Offenbarung. Die tatsächlich existiert habenden Hypertextsysteme wie Intermedia oder Hyper-G wirken in dieser Hinsicht auch heute noch regelrecht futuristisch.

Verteilte Persistenz

Bis hierher habe ich Ihnen in der Geschichte der Vernetzung von Computern Technik vorgestellt, die im Großen und Ganzen Informationen im Netz abruft und zur Anzeige bringt oder teilweise auch als Programm ausführt. Dies ging von einfachen Darstellungen wie bei den BBS-Systemen über netzbasierte Hypertextsysteme bis hin zu modernen Browser-Infrastrukturen für netzbasierte Software im World Wide Web. Vernetzung hat aber natürlich weitere Potenziale. Ein wichtiges dieser Potenziale, das ich “verteilte Persistenz” nenne, möchte ich Ihnen abschließend vorstellen.

Wenn Sie heute einen PC, einen Laptop oder ein Tablet nutzen, ist es gar nicht mehr so einfach festzustellen, was eigentlich lokal auf dem Gerät gespeichert ist und was im Netz abgelegt wurde. Häufig wird dann der Begriff “Cloud” verwendet. Was das eigentlich genau bedeuten soll, ist selbst wolkig oder gar nebulös. Der Begriff ist wohl eher den Werbe- als den Technikabteilungen entsprungen. Er kann alles und nichts bedeuten. Wenn von “Dateien in der Cloud” die Rede ist, dann meint es in der Regel, dass Dateien irgendwo im Netz gespeichert sind und bei Bedarf lokal auf ein Gerät synchronisiert werden, ohne dass man sich genau darum kümmern müsste, wo und wie die Daten gespeichert sind und auf welche Art und Weise sie synchronisiert werden. Die bekanntesten Vertreter solcher Clouds sind Dropbox und OneDrive.

FTP, der Urahn der netzbasierten Dateiablage

Zugriff auf im Netz gespeicherte Daten ist prinzipiell nicht neu. Im Internet-Vorgänger ARPAnet gab es bereits seit 1971 den FTP-Dienst. Mit FTP (File Transport Protocol) konnte man sich bereits damals auf einem entfernten Computer anmelden, durch die dort freigegebenen Verzeichnisse stöbern und dann Daten auf den eigenen Rechner herunterladen oder von dort aus hochladen. Der Dienst wird auch heute noch bei manchem Webhoster verwendet, um Dateien auf den Server zu laden, die dann über einen Webserver abgerufen werden können. Im Gegensatz zu den 1970ern und 1980ern geschieht dies heute in der Regel mittels einer Software mit grafischer Nutzungsschnittstelle, die oft ziemlich ähnlich aussieht, wie die Dateimanager der Betriebssysteme. FTP erfüllt sicherlich seinen Zweck, ist aber nicht besonders praktisch, denn das Prinzip ist recht umständlich: Ist auf einem FTP-Server ein Dokument einer Textverarbeitung gespeichert, das man gerne bearbeiten will, kann man das nicht einfach so öffnen und bearbeiten, sondern muss das Dokument erst auf den eigenen Rechner herunterladen, kann es dort öffnen und bearbeiten, um es dann explizit wieder hochzuladen. Moderne FTP-Programme haben häufig das Feature, dies zu automatisieren. Ein Doppelklick auf eine Datei lädt diese herunter, öffnet sie mit dem verknüpften Programm und lädt das ganze nach Speichern auch automatisch wieder hoch. Das ist besser als nichts, aber doch behalten die per FTP zugreifbaren Dateien eine andere Charakteristik als die lokal gespeicherten. Sie erscheinen nicht im Explorer oder Finder und auch über die Funktionen zum Öffnen und Speichern in Programmen lässt sich meist auf keine Dateien per FTP zugreifen.

Dateifreigaben im lokalen Netz

In den 1980er Jahren kamen im Bereich kleinerer Netzwerke in Unternehmen Techniken zur Dateifreigabe auf: 1984 etwa das Network File System (NFS) in den Unix-Systemen von Sun Microsystems und bereits 1983 das SMB-Protokoll von IBM sowie Netware von Novell für IBM-kompatible PCs. Gerade letzteres erfreute sich im Bereich von Firmennetzwerken großer Beliebtheit. In allen genannten Fällen mussten Dateien nicht, wie bei FTP, händisch hoch- oder heruntergeladen werden. Vielmehr wurden Verzeichnisse, die auf einem Server gespeichert wurden, im lokalen System so eingebunden, als ob sie lokal vorlägen. Eine Freigabe von Novell Netware erschien unter MS-DOS als Laufwerk mit eigenem Laufwerksbuchstaben, also wie eine Festplatte oder ein Diskettenlaufwerk. Netzwerke dieser Art konnten klein sein, bestanden beispielsweise aus zwei oder drei PCs, oder wurden allen Rechnern einer Firma verfügbar gemacht. Privat betrieb man 1983 hingegen noch keine Netzwerke. Die meisten privaten Nutzer von Computern hatten zu diesem Zeitpunkt noch nicht einmal eine Festplatte.

Techniken wie Novell Netware, SMB oder NFS sind grundsätzlich auch in größeren Netzwerkverbünden wie dem Internet anwendbar. Rein technisch ist das kein Problem. Die Nützlichkeit ist jedoch eingeschränkt. Greift nämlich ein Programm auf eine Datei auf einem Netzlaufwerk zu, ist dies für das Programm genau so, als handele es sich um eine lokal auf dem Rechner gespeicherte Datei. Der Zugriff auf eine Datei im Netz ist natürlich langsamer, als wenn die Datei auf der Festplatte liegt. Im lokalen Netzwerk ist er aber immerhin schnell genug, damit eine sinnvolle Nutzung noch möglich ist. Ist man mit dem Server allerdings über eine sehr langsame Leitung per Internet verbunden, funktioniert das meist nicht mehr vernünftig. Das Laden und Speichern einer Datei dauert dann sehr lange – und wenn ein Programm die Datei zwischenzeitlich speichert, was ja zu empfehlen ist, muss man als Nutzer warten, bis man weiterarbeiten kann.

Synchronisation mit lokalen Kopien.

Noch schlimmer wird das Problem mit den Netzlaufwerken dann, wenn die Netzwerkverbindung gar nicht dauerhaft besteht. Das ist selbst in Firmennetzwerken mitunter der Fall, etwa wenn man ein Laptop verwendet und damit die Firma verlässt. Unter Windows kann man daher etwa einstellen, dass die Dateien eines Netzlaufwerks offline vorgehalten werden. Das Praktische daran ist, dass es für die Arbeit auf dem Rechner gar keinen Unterschied macht, ob man gerade eine Netzwerkverbindung hat oder nicht. Bearbeitet man ein Dokument, ohne dass es eine Verbindung gibt, bearbeitet man lediglich eine lokale Kopie. Sobald die Netzwerkverbindung wieder vorliegt, wird die Kopie ins Netzwerk übertragen. Um all dies braucht man sich als Nutzer nicht selbst zu kümmern. Laden, Bearbeiten und Speichern laufen genauso ab wie immer. Dieses Prinzip lässt sich auch auf im Internet gespeicherte Dateien anwenden, denn dann spielt das langsame Netz keine so große Rolle mehr. Populär wurde das mit dem Dienst Dropbox, den es seit 2007 gibt. Ganz so wie in Dateifreigaben bei Windows werden bei Dropbox und vergleichbaren Diensten die Dateien lokal auf den eigenen Computer synchronisiert. Man kann sie dort ganz normal verwenden, was auch daran liegt, dass es sich ja in der Tat um lokal auf der Festplatte gespeicherte Dateien handelt. Im Hintergrund werden die Dateien bei Änderungen mit den Kopien im Netz synchronisiert – eine vorhandene Netzwerkverbindung natürlich vorausgesetzt.

Probleme entstehen in beiden Fällen, wenn mehrere Personen gleichzeitig an den Dateien arbeiten. Bei im Netzwerk gespeicherten Dateien, die man oft ja gerade aus dem Grund dort ablegt, um sie gemeinsam verwenden zu können, kann genau eine solche gleichzeitige Bearbeitung natürlich schnell vorkommen. Es gibt dann zwei Versionen der gleichen Datei, die nicht automatisch synchronisiert werden können. Man muss sich als Nutzer explizit für eine der beiden Dateien entscheiden oder diese händisch zusammenführen.

Gemeinsame Objekte

Nehmen wir einmal an, Sie besitzen eine Datei mit einer Folienpräsentation. Sie sind dafür zuständig, die Folien 6 bis 10 zu überarbeiten, ihr Kollege kümmert sich um die Folien 1 bis 5. Wenn Sie versuchen, die Überarbeitung mit den genannten Dateiablagediensten zusammenzuführen, kommt es zu einem Synchronisationskonflikt, den Sie natürlich nicht sinnvoll dadurch lösen können, dass Sie sich entweder für Ihre Datei oder die Ihres Kollegen entscheiden. Sie würden dann immer entweder Ihre eigene Arbeit oder die Ihres Kollegen in den Müll werfen. Das Problem ist hier die zu grobe Granularität. Dateifreigaben und auch cloudbasierte Dateiablagen wie Dropbox arbeiten auf Dateiebene. Von den einzelnen Folien oder gar die einzelnen Elemente auf den Folien wissen diese Dienste nichts. Sie können die Präsentation also nicht auf dieser feinen Granularitätsstufe synchronisieren.

Anders sieht das aus, wenn man Software nutzt, die über das Netzwerk synchronisiert Zugriff auf gemeinsame Objekte bietet. Google Docs ist ein modernes Beispiel für eine solche Software. Sie können damit Texte gleichzeitig mit mehreren Mitstreitern online bearbeiten. Alle arbeiten gleichzeitig am gleichen Text. Es ist kein Hin-und-her-Schicken und keine explizite Synchronisierung notwendig. Natürlich müssen solche Dienste nicht zwangsweise internetbasiert sein. Wenn Sie Apple-Nutzer sind, können Sie sich zum Beispiel das Programm SubEthaEdit herunterladen und haben damit einen Texteditor, mit dem Sie im lokalen Netzwerk gemeinsam an Dateien arbeiten können.

In dieser Abbildung sehen Sie zwei frühe Repräsentanten solcher Programme. Links zu sehen²³ ist der Unix-Editor EMacs, der es in dieser Version erlaubt, jemandem über das Netz beim Bearbeiten eines Textes zuzusehen. Das Fenster oben zeigt den Master (in der letzten Zeile zu lesen), das untere den Observer, der zusehen, nicht aber selbst bearbeiten kann. Der Editor ShrEdit von 1994 auf der rechten Seite²⁴ erlaubt bereits das gemeinsame, gleichzeitige Bearbeiten des Textes.

Dass man auf diese Weise potenziell von unterschiedlichen Enden der Welt gemeinsam und gleichzeitig an einem Dokument arbeiten kann, wirkt heute fast selbstverständlich. Wenn man sich mal überlegt, was eigentlich dahintersteckt, kann man aber schon ins Staunen kommen, denn dieses gemeinsame Objekt, das Dokument, mit seinen Teilobjekten gibt es ja eigentlich gar nicht. Jeder sieht und bearbeitet eine eigene Kopie. Diese wird im Hintergrund so schnell mit den Kopien der anderen synchronisiert, dass der Eindruck eines gemeinsamen, geteilten Objekts entsteht. Dass das klappt, ist kein Pappenstiel, denn ein einfaches Synchronisieren des ganzen Dokuments würde ja nicht ausreichen. Zum einen würde das viel zu lange dauern. Ein komplexes großes Dokument könnte man wohl kaum mehrmals pro Sekunde per Netz durch die ganze Welt schicken. Das geht selbst bei den heutigen hohen Netzwerkgeschwindigkeiten nicht. Die Entwickler entsprechender Tools standen also vor der Aufgabe sich zu überlegen, wie man die Datenmenge stark reduzieren kann, etwa, indem man nur die Stellen des Dokuments versendet, die sich verändert haben, oder indem man die Änderungsoperationen als solche überträgt. Das allein reicht aber nicht, denn dann würden zwar die Änderungen der Mitarbeiter stets zügig sichtbar werden, der Überblick darüber, wer gerade wo arbeitet, könnte sich aber schwieriger gestalten. Es braucht also zusätzliche Informationen, die mit übertragen werden müssen. Dazu gehört etwa der Mauszeiger oder der Schreib-Cursor der Mitarbeiter zusammen mit der Anzeige ihrer Namen. Mit solchen Awareness- oder zu Deutsch Gewärtigkeitsinformationen gelingt die gemeinsame Arbeit erheblich einfacher. Trickreich bleibt es dennoch, denn bekannte Funktionalitäten wie Undo und Redo werden nun ziemlich kompliziert. Stellen Sie sich vor, wir würden gemeinsam an diesem Absatz arbeiten. Ich schriebe am Ende des Absatzes einen neuen Satz. Kurz danach korrigieren Sie einen Fehler am Beginn des Absatzes. Wenn ich dann auf “Undo” klicke, was passiert dann eigentlich? Wird meine Änderung zurückgenommen oder Ihre? Was würde man erwarten?

Halten wir an dieser Stelle mal inne. Wo sind wir jetzt angekommen? Wir arbeiten weltweit verteilt, gleichzeitig und gemeinsam an virtuellen Objekten. Eine Vielzahl von Entwicklern hat sich intelligente Dinge ausgedacht, damit das so funktioniert und wenn es funktioniert, dann ist alles super. Eigentlich ist es fast schon Zauberei, wenn es nicht so selbstverständlich geworden wäre. Dadurch, dass sich die technischen Hintergründe auf geschickte Art und Weise immer mehr der Wahrnehmung der Nutzer entziehen, sind Nutzungsformen möglich, die vorher undenkbar waren. Dieses Verstecken der Technik ist die Grundlage der Potenziale, die die digitale Technik bietet. Damit verbunden ist dann aber, dass man fast zwangsläufig als Nutzer und als Interessierter das technische System gar nicht mehr durchblicken kann und immer auf die bereits vorgefertigten Lösungen angewiesen ist. Bei einem Commodore 64 konnte man noch jeden einzelnen Chip ergründen, konnte das komplette auf einem Chip untergebrachte ROM analysieren und an Software und gegebenenfalls sogar an Hardware selbst Hand anlegen. Ein moderner Laptop ist mehrere tausend Mal potenter in jeder Hinsicht und bietet durch die Geschwindigkeit, die Vernetzung und durch geschickte Programmierung die geschilderten verteilten Wunderwelten mit gemeinsamen, persistenten Objekten, aber wirklich durchdringen kann man das alles nicht mehr.

Schlussgedanken

An dieser Stelle endet mein Einblick in die Computergeschichte aus der Nutzungsschnittstellen-Perspektive. Wie Sie sicher gemerkt haben, lag mein Hauptfokus nicht auf den allerneuesten Nutzungsschnittstellen, sondern vor allem auf den Windungen der Computergeschichte, die zum Status quo geführt haben. Ihr aktuelles Smartphone muss ich Ihnen nicht beschreiben. Sie haben es in der Tasche und nutzen es wahrscheinlich etliche Male am Tag. Mein Ansatz war ohnehin ja nicht der, Ihnen reine Beschreibungen und technische Daten zu präsentieren. All diese Dinge können Sie an anderer Stelle mit mehr Details und in größerer Vollständigkeit nachlesen. Was ich Ihnen vermitteln wollte – und hoffentlich auch vermittelt habe –, ist das, was im wissenschaftlichen Umfeld gerne “Wechselwirkung” genannt wird. Technische Weiterentwicklungen der Computertechnik passierten in den allermeisten Fällen nicht einfach so ohne Grund, sondern weil es einen Bedarf an neuen Nutzungsformen gab, etwa weil die Programmierung mit Lochkarten so umständlich war oder weil neue Nutzungsszenarien antizipiert wurden – etwa wenn am Xerox PARC Computer für die Büronutzung entwickelt wurden. Um diese neuen Formen der Computernutzung umzusetzen, musste es zu Weiterentwicklungen in den Nutzungsschnittstellen kommen. Diese Weiterentwicklungen waren aber nicht immer ohne Weiteres möglich. Vielfach brauchte es zunächst technische Fortschritte in anderen Bereichen, etwa in der Prozessorgeschwindigkeit, in der Arbeitsspeichergröße oder auch in der Art und Weise, wie ein Bildschirm genutzt werden konnte. In manchen Fällen trieb der Druck nach Fortschritten in der Nutzungsschnittstelle diese Entwicklungen, in anderen Fällen inspirierten neue technische Möglichkeiten die Systementwickler zu neuen, experimentellen Nutzungsschnittstellen.

Ich habe in diesem Buch weit mehr weggelassen, als ich erzählt habe. Damit meine ich nicht nur die Details zu den einzelnen technischen Artefakten oder dass ich nicht jeden Minicomputer oder jeden PDA aufgeführt habe. Es fehlen in meiner Betrachtung auch komplette Bereiche der Nutzungsschnittstellen. Ich habe Ihnen zum Beispiel nichts von den Nutzungsschnittstellen-Welten erzählt, die man mit „Virtueller Realität“ betitelt, bei denen ein Nutzer etwa einen Helm aufsetzt und einen Datenhandschuh anzieht und dann dreidimensionale Welten erkunden kann.

Auch ein spannendes Potenzial einer vollständig „transparenten“ Vernetzung – also einer Vernetzung, bei der Sie nicht selbst Daten von einem Rechner zum anderen schicken müssen, sondern bei der die Kommunikation so erfolgt, dass Sie davon nichts merken – liegt dann vor, wenn nicht mehrere Nutzer das gleiche Objekt nutzen, sondern eine Anwendung ihre Nutzungsschnittstelle auf mehrere Geräte verteilt. Man nennt diese Art der Nutzungsschnittstelle “Distributed User Interface”. Stellen Sie sich doch einmal folgendes Szenario vor: Eine digitale Tafel, die ja auch nur ein Computer mit extravagantem Touch-Bildschirm ist, erlaubt das Erstellen und Positionieren von Objekten auf der Oberfläche. Ein Lehrender nutzt die Tafel, indem er die Objekte mit einem digitalen Stift erstellt und manipuliert. So eine Stifteingabe auf einer Tafel ist natürlich nicht für alle Arten von Eingaben ideal. Nehmen wir zum Beispiel an, es gäbe hier die Möglichkeit, Fotos einzufügen. Auf der Tafel, die ja alle sehen können, nun einen Datei-Browser zu öffnen, sodass ein Foto ausgewählt werden kann, ist unpraktisch. Ein Distributed User Interface könnte es erlauben, dass an der Tafel die Stelle, an der das Foto erscheinen soll, markiert und dann das Smartphone genutzt wird, um ein Foto auszuwählen oder um direkt eines zu erstellen. Ähnliches kann man sich für Textfelder vorstellen. Diese könnten an der Tafel ausgewählt, dann aber von einem Laptop aus mit Text befüllt werden. Alle drei Geräte, die digitale Tafel, das Smartphone und der Laptop bilden in diesem Fall die Nutzungsschnittstelle für die Bearbeitung der gleichen Objekte.

Alle diese neuen Potenziale und alle technischen Entwicklungen, die dahin geführt haben, dass sie heute teils genutzt werden, teils noch entdeckt werden müssen, wären es wert, erzählt zu werden, auch wenn es sich dann nicht mehr, wie in diesem Buch, um eine Geschichtserzählung handelt. Vielleicht erzähle ich Ihnen trotzdem eines Tages davon. Sie könnten dieses Buch dann quasi als den ersten Band betrachten. Dass es einen zweiten Band geben wird und dass er dann auch von mir sein wird, kann ich Ihnen natürlich heute nicht versprechen. Sehr sicher bin ich aber, dass Sie von den genannten Potenzialen hören und sie nutzen werden, wenn Sie es nicht jetzt schon tun. Lehnen Sie sich doch dann einmal einen Moment zurück und überlegen Sie, was alles hat passieren müssen, welch lange und komplexe Entwicklungsgeschichte es brauchte, um das so hinzubekommen.

Anmerkungen