Kompatibilität (Technik)

technologische Kompatibilität von Hard- bzw. Software

Kompatibilität liegt in der Technik vor, wenn zwei oder mehr Produkte gegenseitig so koordiniert sind, dass sie störungsfrei miteinander funktionieren können und einem Nachfrager einen Nutzen stiften.

AllgemeinesBearbeiten

Besitzt jemand Musik-CDs, so können diese nur vollständigen Nutzen stiften, wenn sie auf einem CD-Player abgespielt werden. Jedes dieser beiden Produkte ist für sich alleine nicht nutzbringend. Dies ist eine von drei Arten der Kompatibilität.

ArtenBearbeiten

Die Fachliteratur unterscheidet drei Arten der Kompatibilität:[1]

Diese Arten können auch gleichzeitig vorkommen. So ist beispielsweise bei Peripheriegeräten neben der physischen Kompatibilität auch die Kommunikation zwischen Computer und Peripheriegerät durch erfolgreichen Datentransfer erforderlich.

Die Aufwärts- (oder Vorwärtskompatibilität) und Abwärtskompatibilität (oder Rückwärtskompatibilität) betrifft in der Informatik die chronologisch unterschiedlichen Versionen zusammengehöriger Produkte, insbesondere bei Hardware und Software. Sie sind abwärtskompatibel, wenn neuere Versionen mit älteren Versionen oder deren Schnittstellen verträglich sind. Aufwärtskompatibilität liegt vor, wenn ältere Versionen mit neueren oder deren Schnittstellen verträglich sind.

Erfüllt ein System die Anforderungen eines anderen (und geht eventuell darüber hinaus), wird es als mit letzterem kompatibel bezeichnet.

Zum Beispiel kann ein elektronisches Bauteil zu einem anderen mit unterschiedlicher Bezeichnung kompatibel sein. Die Bauteile können dann ausgetauscht werden, da sie dieselben Eigenschaften haben und meistens die gleiche oder eine ähnliche Bauform.

Im Gegensatz zur konkreten Austauschbarkeit und Gleichwertigkeit wird mit Interoperabilität etwas allgemeiner die Fähigkeit zur Zusammenarbeit von verschiedenen Systemen (durch die Einhaltung gemeinsamer Standards) bezeichnet. Beide Begriffe werden häufig synonym verwendet.

Computer-Hard- und SoftwareBearbeiten

 
Standardisierte Binärschnittstellen (englisch ABIs) über multiple Betriebssysteme sorgen für Binärkompatibilität, also die Portierbarkeit von Binärcode, während standardisierte Programmierschnittstellen (englisch APIs) für Quelltextkompatibilität, also die Portierbarkeit von Quellcode verantwortlich sind.

BinärkompatibilitätBearbeiten

Binärkompatibilität bezeichnet eine Eigenschaft von Betriebssystemen oder Prozessoren, digitale Daten auf die gleiche Weise zu „verstehen“. Meistens ist damit gemeint, dass ein Prozessor Anweisungen versteht, die für einen anderen geschrieben wurden (siehe auch Befehlssatz). Damit kann aber auch die Byte-Reihenfolge (Big- oder Little-Endian) oder, bei serieller Übertragung, die Bit-Reihenfolge gemeint sein.

Zwei Betriebssysteme sind binärkompatibel, wenn jedes Programm, das für das eine Betriebssystem kompiliert wurde, ohne erneutes Kompilieren sofort auf dem anderen Betriebssystem lauffähig ist.

Binärkompatibilität von Betriebssystemen kann einerseits auf Hardware-Ebene erreicht werden (CPU-Befehlssatzkompatibilität), durch Software-Emulatoren (z. B. durch eine Virtual Machine) oder durch vorherige Umformung (JIT-Compiler). Apple setzte z. B. zur Wahrung der Kompatibilität zwischen Motorola-68000- und PowerPC-Rechnern einen Software-Emulator ein.

QuelltextkompatibilitätBearbeiten

Quelltextkompatibilität bedeutet, dass ein Quelltext ohne Anpassung auf unterschiedlichen Systemen kompiliert werden kann. Zwei Betriebssysteme sind quelltextkompatibel, wenn zur Übertragung eines Programms ein erneutes Kompilieren notwendig ist, aber keine Änderungen am Quelltext.

AbwärtskompatibilitätBearbeiten

Als Abwärtskompatibilität wird die Verwendbarkeit bzw. Kompatibilität neuerer oder erweiterter Versionen eines technischen Objekts oder Standards zu den Anwendungsbedingungen einer früheren Version bezeichnet. Dabei ist die Relation Abwärtskompatibilität nicht notwendigerweise transitiv.

 
Darstellung der Abwärtskompatibilität anhand des Beispiels Tür. Zarge_21 ist abwärtskompatibel zu Türblatt_1, aber nicht zu Türblatt_0.

Eine neuere Version einer Software sollte die mit der älteren Version erstellten Dokumente wieder öffnen und weiterverarbeiten können. Während dies häufig gut gelingt, sind Dateien einer neueren Software-Version meistens durch die ältere Version nicht mehr lesbar, was viele Anwender zu Aktualisierungen zwingt.

Ein Beispiel für Abwärtskompatibilität ist UTF-8, das nach wie vor auf den ersten 128 Stellen die Zeichen des 7-Bit-ASCII-Zeichensatzes darstellt, sodass die darauf basierenden Rechensysteme nach wie vor ASCII-Dokumente korrekt verarbeiten und anzeigen können.

Der Signalübertragungsstandard HDMI ist eine Weiterentwicklung von DVI und dazu abwärtskompatibel. Beide benutzen dieselbe Signalcodierung TMDS.[2]

Im Hardware-Bereich wird heute ebenso erwartet, dass Programme für ein altes Computermodell auf einem neuen Modell (zumindest auf einem vom selben Hersteller) weiterhin zu verwenden sind, auch wenn umgekehrt viele Programme für das neue Modell auf dem alten nicht oder nur mit Einschränkungen nutzbar sind. Bei Großrechnern herrscht dieses Prinzip bereits seit den 1960er-Jahren vor, bei Microcomputern hat es sich bis Mitte der 1980er weitgehend durchgesetzt.

Abwärtskompatibilität in der IT-Branche geht oft mit Nachteilen einher. Beispiele sind

  • der seit Jahrzehnten in x86-Prozessoren existierende Real Mode, der in heutigen Prozessoren nicht mehr benötigt wird
  • die MS-DOS-basierten Windows-Versionen 95, 98 und ME, welche unter Problemen litten, weil sie aus Kompatibilitätsgründen weite Teile von MS-DOS und Windows 3.x weiterverwenden mussten.

AufwärtskompatibilitätBearbeiten

Als Aufwärtskompatibilität wird die Verwendbarkeit oder Kompatibilität älterer oder veralteter Versionen eines technischen Objekts oder Standards zu den Anwendungsbedingungen einer neueren Version bezeichnet.

Ein Beispiel ist das analoge Farbfernsehen, das mit Schwarz-Weiß-Fernsehempfängern als Schwarz-Weiß-Bild empfangen werden konnte.

Im Fall einer Textverarbeitungsanwendung kann das beispielsweise beinhalten, dass eine alte Version der Anwendung Dokumente anzeigen und bearbeiten kann, die von einer neueren Version erstellt wurden. Teile des Dokumentes, für die in der alten Version noch keine Funktion besteht, können zwingendermaßen nicht verarbeitet werden. Aufwärtskompatibilität bedeutet aber, dass diese Teile das einwandfreie Funktionieren der alten Version nicht beeinflussen.

In der Programmierung ist die Gewährleistung von Aufwärtskompatibilität schwieriger als die von Abwärtskompatibilität, weil beim Erstellen einer Version der Anwendung noch nicht alle Formate und Strukturen späterer Versionen bekannt sind. Trotzdem muss die aktuelle Version mit diesen Formaten und Strukturen arbeiten können. Bei der Abwärtskompatibilität entsteht dieses Problem nicht, da man beim Erstellen der neuen Version die Formate und Strukturen alter Versionen bereits kennt.

Eine alte Programmversion, die Daten einer neuen Version als Eingabe erhält, kann also nur die Daten verarbeiten, für die sie auch Anweisungen hat. Der Rest muss ignoriert werden und das Programm muss versuchen, nicht abzustürzen. Webbrowser ignorieren beispielsweise neue HTML-Tags, die sie nicht kennen.

Viele Programme sind heute aufwärtskompatibel und können auch noch große Unterschiede zwischen Versionen kompensieren. Werden Fähigkeiten einer späteren Programmversion in eine frühere Version per Update eingebracht, so spricht man von einem Backport.

Aufwärtskompatibilität von Computerhardware kann beispielsweise durch Emulation erreicht werden.

Inkompatibilität bei Computer-Hard- und SoftwareBearbeiten

Neuere Versionen eines Programms sind in der Regel abwärtskompatibel zu älteren Versionen. Diese älteren Versionen sind jedoch oft nicht aufwärtskompatibel. Werden Funktionen nicht nur erweitert, sondern geändert, so kann eine neue Version in Teilbereichen (abwärts-)inkompatibel zur alten Version werden. Geschieht dies bei dynamischen Bibliotheken, so tritt leicht der Zustand ein, den Programmierer scherzhaft als „DLL Hell“ bezeichnen: Da verschiedene Programme versuchen, für sie jeweils leicht unpassende Komponenten zu verwenden, funktioniert gar nichts mehr richtig.

Ein konkretes Beispiel: Der Athlon-64-Prozessor der Firma AMD ist abwärtskompatibel zum 8086-Prozessor der Firma Intel, der im Jahre 1978 erschien. Der Athlon 64 kann also Programme des alten 8086 ausführen. Umgekehrt gilt dies jedoch nicht. Die Kompatibilität beschränkt sich hier auf den Befehlssatz, wobei die Ausführungsgeschwindigkeit drastisch zugenommen hat. Der neue Prozessor selbst kann wegen unterschiedlicher Gehäusebauformen, Signale, Versorgungsspannungen usw. nicht mit dem alten ausgetauscht werden. Die beiden Prozessoren sind also hinsichtlich dieser Eigenschaften inkompatibel.

FehlerkompatibilitätBearbeiten

Fehlerkompatibilität (englisch: bug compatibility) ist ein Fachbegriff aus der Informationstechnik, der bedeutet, dass eine neue und verbesserte Software oder Hardware beziehungsweise ein alternatives Produkt von einem Mitbewerber die gleichen Fehler besitzt, und somit kompatibel ist.[3]

Der Grund für die Fehlerkompatibilität ist in der Regel nicht, dass es schwierig wäre, die Fehler zu beheben. Grund ist, dass bestehende Programme sich auf die Fehler verlassen und eventuell nicht mehr funktionierten, wenn man sie behöbe. Das Korrigieren des Fehlers verursacht also mehr Probleme als das Dokumentieren und Beibehalten des fehlerhaften Verhaltens. Ein bekannter Fehler wird somit schnell zu einem Teil des Interface und wird von Anwendern desselben berücksichtigt. Eine Änderung des Interface, auch wenn es inhaltlich eine Fehlerkorrektur ist, kann zu fehlerhaftem Verhalten bei abhängigen Systemen führen.

Beispiel

Im Atari Betriebssystem TOS waren in der ersten Version in der Funktion Bcostat die Gerätenummern für die Tastatur (hier: 3, sonst: 4) und die MIDI-Schnittstelle (hier: 4, sonst: 3) vertauscht. Da sich die Programmierer auf diese Vertauschung eingestellt hatten, und es funktionierende Software gab, die die vertauschten Gerätenummern verwendete, wurde in späteren Versionen die Dokumentation angepasst, und die Vertauschung der Gerätenummern in dieser Funktion beibehalten.[4]

Eine gängige Strategie ist, die Fehler im neuen Produkt zu korrigieren, aber das vorherige Verhalten zumindest über eine Option zu simulieren. So kann das System auch mit der neuen Version weiter betrieben werden, bis es selbst an die Änderungen angepasst wurde. Man spricht dann auch von einem Fehlerkompatibilitätsmodus.

WerbungBearbeiten

Gelegentlich werden in der Werbung Produkte als „kompatibel“ zu denen eines etablierten Wettbewerbers bezeichnet, um zu vermitteln, dass sie trotz ihres niedrigeren Preises mit jenen austauschbar sind. Diese „Produkteigenschaft“ kann jedoch auch als negatives „austauschbar“ wahrgenommen werden.

Wirtschaftliche AspekteBearbeiten

Ökonomisch betrachtet wird die Kompatibilität bei Komplementärgütern genutzt. So kann beispielsweise eine CD nur auf einem CD-Player gespielt werden. Die meisten Wiedergabegeräte können nur bestimmte Tonträger oder Bildträger für den Konsumenten wahrnehmbar machen (Schallplatten nur auf dem Schallplattenspieler). Auch Elektrogeräte benötigen manchmal Kompatibilität, denn Fernsehgeräte können nur das US-Farbübertragungssystem NTSC oder das europäisch standardisierte PAL-System störungsfrei empfangen.

Ein weiterer Aspekt ist der Lock-in-Effekt, weil es Produzenten über die technische Abhängigkeit gelingt, die Nachfrage der Verbraucher durch Kundenbindung auch künftig auf sich zu lenken. Der erste große kommerzielle Erfolg nach diesem Lock-in-Effekt war im Jahre 1902 der Gillette-Rasierer von King C. Gillette. Statt der damals üblichen Rasiermesser, die nachgeschärft werden konnten, verkaufte Gillette einen patentierten Klingenhalter, zu dem wegwerfbare Rasierklingen passten, die günstig herzustellen waren und mit hoher Marge dauerhaft an die Nutzer der Gillette-Klingenhalter verkauft werden.

Siehe auchBearbeiten

LiteraturBearbeiten

  • Markus Bechter: Kompatibilitätsabsicherung verteilter eingebetteter Systeme in der Mechatronik, Sierke-Verlag, 2008, ISBN 978-3-86844-091-1

EinzelnachweiseBearbeiten

  1. Joseph Farrell/Garth Saloner, Competition, Compatibility and Standards: The Economics of Horses, Penguins and Lemmings, in: The American Economic Review vol. 76, 1987, S. 940 ff.
  2. Understanding Digital Interconnects. Audioholics, LLC, abgerufen am 27. Juli 2011 (englisch).
  3. Dieter Kranzlmüller: Spezielles Kapitel 5: „Transmeta’s Crusoe“@1@2Vorlage:Toter Link/www.gup.jku.at (Seite nicht mehr abrufbar, Suche in Webarchiven Info: Der Link wurde automatisch als defekt markiert. Bitte prüfe den Link gemäß Anleitung und entferne dann diesen Hinweis. , Vorlesungsfolien über Transmetas Crusoe-Prozessor und dessen Fehlerkompatibilität zum Intel x86
  4. Hans-Dieter Jankowski/Dietmar Rabich/Julian F. Reschke, ATARI Profibuch ST-STE-TT, Sybex Verlag, ISBN 3-88745-888-5, 12. Auflage, S. 86; Bcosstat (BIOS 8)