Kompatibilität (Technik)

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 20. April 2016 um 14:12 Uhr durch Sokonbud (Diskussion | Beiträge) (→‎Siehe auch: schon im Artikel mit Wikilink und form). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Zur Navigation springen Zur Suche springen

Unter Kompatibilität (auch Verträglichkeit) wird in der Technik entweder

verstanden. Erfüllt ein (oft neueres) System die Anforderungen eines anderen (und geht evtl. darüber hinaus), so spricht man von Abwärtskompatibilität (oder Rückwärtskompatibilität). Kann ein altes System die (Grund-) Anforderungen eines neuen erfüllen, nennt man dies Aufwärtskompatibilität (oder Vorwärtskompatibilität).

Ein elektronisches Bauteil kann 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.

Häufig wird fälschlicherweise die Kompatibilität mit Interoperabilität gleichgesetzt. Dies kann ein (vom Anbieter eines „kompatiblen“ Produktes) billigend in Kauf genommener Fehlgebrauch sein.

Computer-Hard- und Software

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

Binärkompatibilität

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ät

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ät

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.

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, so dass 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.[1]

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 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ät

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.

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.

Inkompatibilität bei Computer-Hard- und Software

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ät

Fehlerkompatibilität (englisch: bug compatibility) ist ein Fachbegriff aus der Informationstechnologie, 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.[2]

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.[3]

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.

Werbung

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.


Siehe auch

Literatur

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

Einzelnachweise

  1. Understanding Digital Interconnects. Audioholics, LLC, abgerufen am 27. Juli 2011 (englisch).
  2. Dieter Kranzlmüller: Spezielles Kapitel 5: „Transmeta’s Crusoe“, Vorlesungsfolien über Transmetas Crusoe-Prozessor und dessen Fehlerkompatibilität zum Intel x86
  3. Jankowski, Rabich, Reschke: ATARI Profibuch ST-STE-TT, Sybex Verlag, ISBN 3-88745-888-5, 12. Auflage, S. 86, Bcosstat (BIOS 8)