Was im Bestand hat: Codebasen

Der letzte Artikel über Veränderungen im PC brachte mich recht schnell auf die gegenteilige Frage: was hat den Bestand oder besser gesagt, was hat am längsten Bestand? Nun die Hardware veraltet. Sie wird (in der Regel) immer leistungsfähiger oder eben nicht und stirbt dann aus wie Floppylaufwerke oder CD-ROMs, zumindest muss sie sich aber anpassen. Jeder, der mal sich Gedanken gemacht hat, wie er Dateien auf einer 5,25-Zoll-Floppy in einen heutigen PC zu bekommen weiß das. Als eingebautes Laufwerk ist es schon seit den Neunzigern nicht mehr dabei. Als externes Laufwerk gibt es ein 5,25-Zöller heute nicht mehr zu kaufen. Selbst wenn man ein altes Laufwerk noch hat, fehlt der Floppykontroller mit seinem 40-poligen Flachbandkabel um es anzuschließen. Ähnliches gilt für vieles. Seien es ISA Karten (der Bus wurde 1993 durch PCI ersetzt) oder digitale Monitor mit ihren Anschlüssen (heute sind Monitore auch wieder digital, aber haben HDMI, DVI oder Displayportstecker anstatt der alten sechspoligen Rundstecker.

Doch es gibt etwas was relativ beständig ist, das sind Codebasen. Eine Codebasis ist der Befehlsart eines bestimmten Prozessors oder weitergehend ein Programm, das definierte Schnittstellen nutzt, z.B. für die Ein-/Ausgabe.

Beim PC, worunter ich die Intel x86/IA64 Architektur verstehe, gab es drei wesentliche Codebasen:

• 16 Bit
• 32 Bit
• 64 Bit

Die Basis bildete der 16 Bit Code eingeführt mit dem Intel 8086. Ursprünglich war der 8086 als Lückenbüßer gedacht. Nach dem 8080 wollte Intel die 16 Bit Generation komplett überspringen und gleich zu einem 32-Bit-Design gehen. Doch das verzögerte sich, und als 1976 die ersten 16 Bit Prozessoren wie der TMS 9900 erschienen, entschloss man sich für eine Zwischenlösung, um die Kunden nicht zu verlieren. Das Design des 8086 wurde schnell entworfen mit einer maximalen Kompatibilität zum Vorgänger 8080. So hatte er dieselbe Zahl an allgemeinen Registern, konnte diese wie der 8080 auch getrennt als 8-Bit-Register nutzen und der Befehlssatz hatte den 8080 Befehlssatz als Teilmenge. So konnte ein Programm 80080 Assemblercode in 8086 Code umschreiben, wenngleich er nicht binärcodekompatibel war.

Intel hatte aber eine sehr befremdliche Ansprechweise des Arbeitsspeichers eingeführt. Alle Register waren 16 Bit breit, doch damit gab es nicht mehr Arbeitsspeicher als ein 8 Bitter, der zwei Register von 8 Bit für Adresszugriffe zu einem 16-Bit-Register zusammenfassen konnte. Intels Lösung waren vier Segmentregister, deren Inhalt zum Adressregister mit 16 multipliziert wurde. So konnte man die vier Register wie Fenster innerhalb eines 1 MByte großen Adressraums verschieben.

Das erste Binärformat für MS-DOS war das von CP/M übernommene .COM Format. Das unterstützte es nicht die Segmente zu verschieben, weshalb Code und Daten auf 64 KByte beschränkt waren, bei der allerersten Subvariante sogar auf nur zusammen 64 KByte. Beim allerersten IBM PC und MS-DOS 1 war so jeder speicher über 128 KByte Verschwendung denn Programme nutzen so nicht mehr. Später kam mit MS-DOS 2 das .EXE Format mit verschiebbaren Fenstern. Die Größenbeschränkung auf 64 KByte blieb aber. Genauer gesagt: Jedes Unterprogramm konnte maximal 64 KByte Code, 64 KByte Daten und 64 KByte Stack (benötigt für Transfers von Daten) haben. Bei Code kein Problem, denn man entwickelt normalerweise sehr viele Unterprogramme und keines ist 64 KByte groß. Aber die Einschränkung bei den Daten war gravierend. So dürften die globalen Daten, also alle Daten, auf die man immer zugreifen, kann auch maximal 64 KByte groß sein. Mancher erinnert sich vielleicht noch an Notepad und Write als Windows Editoren – die konnten maximal 64 KByte große Texte bearbeiten. Bilder sind auch schnell größer als 64 KByte. Natürlich geht das Arbeiten mit größeren Daten – aber nicht mit der Hochsprache, da muss der Programmierer selbst mit den Segmentregistern hantieren und die manuell in Assembler verschieben.

Die Lösung war wirklich besch… eine kleine Ersparnis beim Chipdesign die über ein Jahrzehnt Programmierern das Leben schwer machte. Denn Motorola zeigte wie es auch anders geht: Der MC 68000 war schon 32 bittig angelegt, auch die internen Register waren 32 Bit breit. Aber es wurden nur 16 Bit für den Datenbus und 24 Bit für den Adressbus herausgeführt, also ein Teil der Register nicht benutzt. Als es den Nachfolger MC 68020 gab, verdaute der aber so die Software des Vorgängers und hatte mehr adressierbaren Arbeitsspeicher.

Intel versuchte, mit dem 80286 mit Motorola gleich zu ziehen. Er erschien 1982. Auch er hatte nun einen 24-Bit-Adressraum, aber nach wie vor 16 Bit breite Register. Zudem hatte er Möglichkeiten Programme abzubrechen und Fehler abzufangen. So ein Feature ist wichtig für das Betriebssystem, dass so nicht mit sich aufhängt wenn ein Programm abstürzt, wie das bei DOS der Fall war. Das erforderte aber einen speziellen Betriebsmodus im Prozessor um diese Features zu aktiveren. Es sollte ja – der Fluch der Kompatibilität die alte Software noch weiter laufen. Den Riesenfehler den Intel machte, war das man vom 8086-Modus, der dann bald den Namen „Realmodus“ bekam zwar in den 80286 Modus „Protected Mode“ wechseln konnte, aber nicht mehr zurück. Nun muss jede Software aber erst mal entwickelt werden, auch das Betriebssystem selbst. Die Tools dafür insbesondere der Debugger mit dem Fehler erkennen konnte gab es aber alle im Realmodus und das hielt die Entwicklung für Software für den Protected Mode auf. Bill Gates plädierte bei der Zusammenarbeit mit IBM daher darauf, ihn komplett zu überspringen. Die ersten Windows Versionen 1+2 waren so komplett im Real Mode erstellt worden. Ab Windows 3 gab es immer mehr Teile, die im Protected Mode liefen.

Mit dem 80386, der 1985 erschien, hatte Intel das Problem gelöst. Man kam nun aus dem Protected Mode zurück in den Real Mode und es gab sogar einen abgesicherten Realmode, in dem der Prozessor mehrere DOS-Programme parallel ausführen konnte und diese voneinander und vom Betriebssystem isoliert „virtueller 8086 Modus genannt“. Diese Features bedeuteten für Windows 3 den kommerziellen Durchbruch. Denn vorher belegte Windows Speicher in den ersten 1 MB für DOS, so liefen die meisten größeren DOS Programme nicht. Nun konnte ein DOS Programm erheblich mehr Speicher nutzen und die meisten liefen auch unter Windows. das war wichtig, denn für windows gab es 1990 als Windows 3 erschien kaum Programme. Bedeutender war die neue Codebasis in der Intel die Breite der Register auf 32 Bit verbreiterte, 32 Bit Code oder IA32 (IA für Industrial Architecture) genannt. Wie langlebig Codebasen waren, zeigt dieser Prozessor. Der 80386 erschien 1985. Windows 3.1 hatte erstmalig einige Codebestandteile im 32-Bit-Code. Für Windows 3.11 gab es das Win32S Subsystem, das 32 Bit Code des 80386, 80485 Pentium … auch von Windows Programmen ausführen konnte als Option. Microsoft entwickelte zwar Windows NT(New Technology) ab 1993 als reines 32-Bit-Betriebssystem, aber das war eben inkompatibel zum 16 bittigen Windows 1 bis 3.11.

Windows 95 sollte auch den Windows 3.x Zweig auf 32 Bit heben, aber wie Tests schnell zeigten, waren viele Treiber noch 16 bittig, was besonders Intel verdrießte, denn ihr brandneuer Pentiumprozessor war auf 32 Bit Code optimiert worden und brach beim bisherigen 16 Bit Code in der Performance ein, war dann nicht schneller als ein viel billiger 486-er.

Erst Windows XP war durchgängig 32 bittig, das Win-16 Subsystem für alte Windows Programme gab es aber immer noch. Es ist sogar bis heute noch vorhanden, allerdings nur in den 32 Bit Versionen von Windows.

Ziemlich lange lies sich Intel mit der Einführung eines 64 Bit Codes Zeit. Andere Firmen präsentierten schon ein Jahrzehnt vor Intel 64 Bit Prozessoren, so Digital Equipment den Alpha Prozessor. Intels eigene Lösung war zudem relativ umständlich und brach mit den Konventionen, die es bisher gab. AMD hatte eine bessere Idee und nutzte einfach einige unbelegte Opcodes aus um die Befehle im 64-Bit-Modus zu definieren. Das Registermodell orientierte sich auch am bisherigen. AMD hatte damit von Anfang an Erfolg und Intel übernahm schließlich die AMD-Lösung als IA64 Architektur. Intel lies sich wahrscheinlich deswegen so viel Zeit mit der Einführung von 64 Bit Code, weil in der Praxis 64 Bit Code nicht schneller läuft und der Hauptvorteil, der ist, das er mehr als die 4 GB Arbeitsspeicher ansprechen kann. So erschien Intels Lösung erst 2005, die AMD-Lösung 2006. Erst bei Windows 7 das 2009 erschien überflügelten die Verkäufe der 64 Bit Editionen die der 32 Bit Editionen. Für die Programmierung ist die 32 Bit Version nach wie vor von Bedeutung. Solange ein Programm nicht mehr als 4 GB Speicher benötigt, das dürfte nur bei Programmen vorkommen, an denen wirklich viele mitarbeiten, bietet der 64 Bit Modus keinen Vorteil, nur sind die Programme doppelt so groß. Selbst Microsoft rät dazu, die 32 Bit Variante von Office zu installieren. Die Einschränkung gilt nicht für das Betriebssystem, das sollte 64 bittig sein, weil sonst auch das Betriebssystem nur maximal 4 GB Speicher ansprechen kann und die meisten neuen PC haben mehr Speicher. Jedes 32-Bit-Programm kann aber selbst 4 GB haben. Das 32 Bit Subystem ist auch Bestandteil der 64 Bit Edition von Windows, aber nur die 32 Bit Version von Windows enthält noch das 16-Bit-Subsystem für Windows bis 3.1 und DOS.

Bei geeigneter Windows Version laufen auch heute so noch DOS-Programme von 1981. Na ja zumindest theoretisch, denn sie stolpern dann über ander Veränderungen z.B. beim Dateisystem.

Noch besser brachte es Apple hin. Der erste Macintosh von 1984 basierte auf dem MC 68000 Prozessor, der dann auch weiter verbaut wurde, bis Motorola diese Linie beendete. Apple wechselte 1994 auf den Nachfolger PowerPC. Die Programme – im Binärcode liefen jedoch weiter, denn ein Emulator setzte diese in PowerPC Befehle um. Im Jahre 2005 wechselte Apple auf die Intel Prozessoren nachdem diese den PowerPC in der Performance überholten, erneut übersetzte ein Emulator den Binärcode auf die IA64 Architektur. Seit diesem Jahr bringt Apple neue Macintosh auf Basis der ARM Architektur heraus und erneut laufen alte Programme in einer Emulation weiter. Intel hat es also fertiggebracht vier verschiedene Prozessoren einzusetzen, ohne dass der Code neu übersetzt werden müsste. Bei einer konsistenten API, also definierten Befehlsaufrufen, die man zwar erweitert aber nicht ändert, reicht das Neukompilieren auch aus, um lauffähigen Code für den neuen Prozessor zu erzuegen. Das klappt aber auch allgemein. Computer gibt es ja schon lange. In vielen Bereichen entstanden Programme und Bibliotheken mit grundlegenden Algorithmen schon früh, in damals populären Programmiersprachen. In der Wirtschaft war dies COBOL, in der Wissenschaft und Technik FORTRAN. Nun große Überraschung – diese Programme sind bis heute im Einsatz, erweitert und gegebenenfalls neu übersetzt. Einen Vorgeschmack bekam die allgemeine Öffentlichkeit, als im Jahr 2000 der Y2K-Bug aktuell wurde: Cobol speichert Zahlen nicht binär sondern als Dezimalziffern ab. 99 belegt so zwei Bytes, je eines ür jede Ziffer. Also sparten sich Programmierer früher die „19“ bei der Jahreszahl ein, denn Speicher war knapp. So würde, aber ohne Änderung beim Jahr 2000 die Jahreszahl von „1999“ auf „1900“ springen … (Die „99“ ist gespeichert, die „19“ wird durch das Programm vorher ausgegeben).

Bis heute sind Programme in diesen Programmiersprachen aktiv, nur eben erweitert. Sie speichern z.B. ihre Daten in Dateien ab und Programme in neueren Sprachen lesen diese aus und erzeugen daraus Grafiken oder bauen Webseiten. Als CGI-Interface ist dies sogar genormt. Wer irgendetwas in einer Webseite eingibt, wird feststellen das daraus ein ganz langer String erzeugt wird er meist nach einem Fragezeichen an die Webadresse angehängt wird. Der Webserver trennt den String ab und übergibt ihn als „Tastatureingabe“ an ein Programm, das überhaupt nichts vom Web selbst wissen muss und die Ausgabe dieses Programms, ebenfalls als Text wird dann erneut verarbeitet. Berüchtigt sind in dem Zusammenhang die „Buffer Overflows“ – die Programmiersprache C prüft von sich aus nicht, ob der Platz im Speicher für einen Eingabestring ausreicht, um diesen auch aufzunehmen. Das muss der Programmierer machen. Tut er es nicht, dann überschreibt der zu lange String Code des Programms. Das kann man ausnutzen, um in Form von Strings Code in ein Programm einzuschleusen und somit ausführen kann. So was geht nur bei C und wird von Freunden der Programmiersprache als ein Feature und kein Fehler verstanden – ich nehme an, für die sind Fahrräder ohne Bremsen und Lenker auch nur Fahrräder mit Features …

Mit dem System können viele Sprachen weiter betrieben werden, auch wenn nur noch enige neue Programme darin entstehen. In einer Webanwendung kann Javascript auf dem Rechner des Besuchers ausgeführt werden, auf dem Server läuft dagegen PHP oder Java, welche die Webseiten bauen und Datenbanken abfragen, die Datenbanksysteme selbst können in Cobol erstellt worden sein.