Plattformübergeifend

Dieser Artikel oder Abschnitt ist nicht hinreichend mit Belegen (Literatur, Webseiten oder Einzelnachweisen) versehen. Die fraglichen Angaben werden daher möglicherweise demnächst gelöscht. Hilf Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst. Bitte entferne erst danach diese Warnmarkierung.

Plattformunabhängigkeit ist die Eigenschaft eines Programms, auf verschiedenen Computersystemen mit Unterschieden in Architektur, Prozessor, Compiler, Betriebssystem und weiteren Dienstprogrammen, die zur Übersetzung notwendig sind, lauffähig zu sein. Der Grad der Plattformunabhängigkeit wird als Portabilität bezeichnet (vom englischen „portability“). Dabei versteht man darunter nicht nur die bestehende Plattformunabhängigkeit, sondern auch den eingeschätzten Arbeitsaufwand, der benötigt würde, um das Programm in ein vollständig plattformunabhängiges umzuwandeln. Dieser Vorgang wird Portierung genannt.

Formen

Es gibt verschiedene Formen von Plattformunabhängigkeit:

• In Zwischencode vorliegende Software: Programme, die entweder in Form von Bytecode, wie hauptsächlich Java-Programme, oder eines portablen, interpretierbaren Quellcodes (Python, Perl, PHP und andere) vorliegen.
• Fat Binaries: Programmpakete, die mehrere lauffähige Versionen enthalten. Das Betriebssystem startet ohne Zutun des Anwenders die richtige Version. Beispiele für „fat binaries“ sind das OpenStep-Programmformat und die „fat binaries“ unter Mac OS, die sowohl auf Motorola 680x0-basierten Apple-Rechnern als auch auf PowerPC-Macs ausführbar sind oder auch Universal Binaries unter Mac OS X, die sowohl auf PowerPC, also auch auf x86 laufen. Voraussetzung dafür, dass eine „fat binary“ überhaupt erstellt werden kann, ist die Portabilität des Quellcodes.
• Quellcode-Portabilität: Diese Form der Plattformunabhängigkeit ist häufig bei C-Programmen für UNIX anzutreffen: Der Quellcode enthält Anweisungen, die es erlauben, die Betriebssystemunterschiede auszugleichen. Es existieren reichlich Hilfsmittel zu diesem Zweck, wie zum Beispiel GNU Autoconf. Eine weitere Möglichkeit ist die Verwendung systemunabhängiger Bibliotheken, wie Qt und Gtk+. Viele im Quellcode portable Programme stehen bereits in vorgefertigten Versionen plattformübergreifend bereit.
• Eingeschränkte Plattformunabhängigkeit ist gegeben, wenn zum Beispiel das Programm nur auf einem bestimmten Prozessor-Typ lauffähig ist, aber auf ansonsten verschiedenen Hardware-Architekturen. Dies ist häufig bei in Assemblersprachen geschriebenen Programmen der Fall, wie man sie in den frühen Zeiten der Microcomputer unter CP/M oft antraf; heute wird Assemblersprache meist nur noch für besonders zeitkritische Programmstellen verwendet, und zwecks Plattformunabhängigkeit ist meist noch eine hochsprachliche Version der gleichen Programmfunktionen beigegeben. Auch Programme, die unabhängig vom CPU-Typ nur auf einer bestimmten Betriebssystem-Familie funktionieren sind eingeschränkt plattformunabhängig.

Im Server-Bereich, wo schon sehr früh mit virtuellen Maschinen und virtuellen CPUs gearbeitet wurde, sieht es beim Thema Plattformunabhängigkeit etwas anders aus, als man es von klassischen Unix-/Linux-Portierungen her kennt – letztere fassen zwar zunehmend im Desktop-Bereich Fuß, verursachen durch die starke Ausrichtung auf x86-PCs in Sachen Plattformunabhängigkeit allerdings oftmals eher mehr Kopfzerbrechen als klassische Unix-Anwendungen.

Heutzutage wird eine relative Plattformunabhängigkeit am häufigsten durch die Verwendung von Laufzeitumgebungen von Sprachen wie Java oder .NET erzielt. Allerdings trifft der Begriff „Portabilität“ beiden Fällen nicht den Kern der Sache, da es sich von Beginn an um plattformunabhängige Konzepte handelte – also auch alle APIs auf jedem Zielsystem im Vorhinein so nachgebildet werden müssen, dass die Software zwangsläufig lauffähig ist. Ansonsten wäre beispielsweise eine Java VM nicht zertifizierungsfähig. Die Laufzeitumgebungen selbst sind auch nicht auf jeder Plattform verfügbar, was zum Beispiel im Fall von .NET zu Entwicklungen wie der des Mono-Projektes geführt hat. Portierungen sind aus lizenz- oder patentrechtlichen Gründen meist gar nicht möglich, daher kann man ebenso nur von einer Form von eingeschränkter Plattformunabhängigkeit sprechen.