Zum Inhalt springen

„Plattform (Computer)“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Versionsgeschichte interaktiv durchsuchen
[gesichtete Version][gesichtete Version]
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
Anker nicht sinnvoll da die Überschriften so oder so einen bilden.
leider hast du offenbar nicht verstanden, wozu diese _zusätzlichen_ Anker gut sind, siehe auch "https://de.wikipedia.org/wiki/Diskussion:Plattform_%28Computer%29#Zus.C3.A4tzliche_Anker_in_den_.C3.9Cberschriften"
Zeile 19: Zeile 19:
Mögliche Bestandteile einer Plattform sind eine [[Rechnerarchitektur]], [[Programmiersprache]], [[Programmbibliothek|Bibliotheken]] und Laufzeitumgebungen.
Mögliche Bestandteile einer Plattform sind eine [[Rechnerarchitektur]], [[Programmiersprache]], [[Programmbibliothek|Bibliotheken]] und Laufzeitumgebungen.


=== Hardwareplattform ===
=== Hardwareplattform {{Anker|Maschinenebene|Prozessorebene}} ===


Bei Plattformen können zwischen Soft- und Hardwareplattformen unterschieden werden. Eine Hardwareplattform, auch '''''Maschinenebene''''' genannt, bezeichnet eine bestimmte [[Computer|Rechner]]­art oder eine ''[Prozessor]-Familie''. Die Maschinenebene ist hauptsächlich durch eine bestimmte [[Rechnerarchitektur|Rechner-]] oder [[Prozessorarchitektur]] (die '''''Prozessorebene''''') gegeben und liegt logisch betrachtet ganz unten – unter der [[#Anwendungsebene|Anwendungsebene]].
Bei Plattformen können zwischen Soft- und Hardwareplattformen unterschieden werden. Eine Hardwareplattform, auch '''''Maschinenebene''''' genannt, bezeichnet eine bestimmte [[Computer|Rechner]]­art oder eine ''[Prozessor]-Familie''. Die Maschinenebene ist hauptsächlich durch eine bestimmte [[Rechnerarchitektur|Rechner-]] oder [[Prozessorarchitektur]] (die '''''Prozessorebene''''') gegeben und liegt logisch betrachtet ganz unten – unter der [[#Anwendungsebene|Anwendungsebene]].
Zeile 29: Zeile 29:
Hardwareplattformen können grob in [[Complex Instruction Set Computing|CISC]]- und [[Reduced Instruction Set Computer|RISC]]-[[Architektur (Informatik)|Architekturen]] eingeteilt werden. Bei aktuellen Prozessorarchitekturen verwischen sich aber die Grenzen zwischen diesen beiden Architekturtypen zusehends.
Hardwareplattformen können grob in [[Complex Instruction Set Computing|CISC]]- und [[Reduced Instruction Set Computer|RISC]]-[[Architektur (Informatik)|Architekturen]] eingeteilt werden. Bei aktuellen Prozessorarchitekturen verwischen sich aber die Grenzen zwischen diesen beiden Architekturtypen zusehends.


=== Softwareplattform ===
=== Softwareplattform {{Anker|Anwendungsebene}} ===


Die sogenannten ''[[Software]]-Plattformen'', auch '''Anwendungsebene''' oder '''-schicht''' genannt (siehe auch [[OSI-Modell]]), werden wie folgt unterschieden.
Die sogenannten ''[[Software]]-Plattformen'', auch '''Anwendungsebene''' oder '''-schicht''' genannt (siehe auch [[OSI-Modell]]), werden wie folgt unterschieden.

Version vom 4. Februar 2017, 12:52 Uhr

Grundkonzept einer Plattform: oben eine beliebige Plattform (blau), die auf drei verschiedenen „Untergründen“ aufsetzt

Eine Plattform – auch Schicht oder Ebene genannt – bezeichnet in der Informatik eine einheitliche Grundlage, auf der Anwendungsprogramme ausgeführt und entwickelt werden können. Sie befindet sich zwischen zwei Komponenten eines Rechnersystems. Für die Komponente, welche die Plattform nutzt, ist die Komponente darunter nicht sichtbar. Daher kann dieselbe Komponente über eine Plattform auf verschiedenen „Untergründen“ betrieben werden. Es gibt eine Vielzahl von Plattformen und Plattformkonzepten im Informatikbereich.

Zielsetzung und Methoden

Die Idee hinter einer Plattform ist die Abstraktion von komplizierten Details für eine Anwendungssoftware bzw. deren Entwickler.

Einerseits können diese Details unbekannte Eigenschaften der Ausführungsumgebung sein, in der eine Anwendungssoftware zukünftig verwendet wird, die zum Entwicklungszeitpunkt der Anwendung nicht bekannt sind oder sein können. Diese Eigenschaften der Ausführungsumgebung können beispielsweise der genaue Typ und Leistungsfähigkeit der Hardwarekomponenten sein oder mit welchem unterliegendem Betriebssystem die Anwendung irgendwann einmal vom Anwender betrieben wird.

Andererseits kann die Motivation für eine Abstraktion auch bekannte Komplexität sein (z. B. unstandardisierte Hardware, konkurrierende Hersteller-APIs), die reduziert werden soll, um Entwicklern eine schnellere, günstigere oder einfachere Entwicklung von Anwendungen zu ermöglichen.

Erreicht werden kann diese Vereinfachung dadurch, dass dem Anwendungsentwickler ein abstrakteres Funktionsmodell von konkreter Funktionalität zur Verfügung gestellt wird, typischerweise in Form einer Programmierschnittstelle (eng. API), welche darunterliegende Funktionalität einhüllt. Für die resultierende Anwendung geschieht das typischerweise in Form einer dynamisch interpretierten Laufzeitumgebung (z. B. JRE, Browser) oder einer binären ABI zu bekannten Softwarefunktionen (z. B. Win32, DirectX).

Eine Qualität, die diese Abstraktionsschichten bieten können, ist Allgemeingültigkeit, üblicherweise als Kompatibilität bezeichnet. Das kann sich auf die Breite, also die Menge der verschiedenartigen, abstrahierten Details beziehen, wie auch auf die Stabilität der Plattform über die Zeit. Bei der Kompatibilität über die Zeit kann die Sicherstellung der Abwärtskompatibilität bei einer Weiterentwicklung einer Plattform gemeint sein oder auch die Zusicherung des Herstellers, dass mit dem Aufkommen neuer abstrahierbarer „Details“ (z. B. neue Betriebssysteme, neue Hardware) diese in die Plattform integriert werden (Aufwärtskompatibilität).

Plattformarten

Mögliche Bestandteile einer Plattform sind eine Rechnerarchitektur, Programmiersprache, Bibliotheken und Laufzeitumgebungen.

Hardwareplattform

Bei Plattformen können zwischen Soft- und Hardwareplattformen unterschieden werden. Eine Hardwareplattform, auch Maschinenebene genannt, bezeichnet eine bestimmte Rechner­art oder eine [Prozessor]-Familie. Die Maschinenebene ist hauptsächlich durch eine bestimmte Rechner- oder Prozessorarchitektur (die Prozessorebene) gegeben und liegt logisch betrachtet ganz unten – unter der Anwendungsebene.

Eine Prozessorarchitektur-Plattform verwendet eine einheitliche Maschinensprache, Datenwortgröße, Byte-Reihenfolge usw. Ein Beispiel dafür ist die weitverbreitete x86-Architektur.

Wie die einzelnen Befehle dieser Maschinensprache intern im Mikroprozessor verarbeitet werden (z. B. mit Micro-ops), kann sich aber innerhalb der gleichen Plattform stark unterscheiden. Nur die Endergebnisse, welche die Befehle liefern, bleiben dieselben.

Hardwareplattformen können grob in CISC- und RISC-Architekturen eingeteilt werden. Bei aktuellen Prozessorarchitekturen verwischen sich aber die Grenzen zwischen diesen beiden Architekturtypen zusehends.

Softwareplattform

Die sogenannten Software-Plattformen, auch Anwendungsebene oder -schicht genannt (siehe auch OSI-Modell), werden wie folgt unterschieden.

Binärschnittstellen-basierte Plattform

Kompatibilität über die Zeit lässt sich beispielsweise über stabilgehaltene Binärschnittstellen von Funktionsbibliotheken erreichen, mit denen auf die Plattform zugegriffen wird. Bei einer Weiterentwicklung der Plattform muss ausschließlich der Plattformanbieter dafür Sorge tragen, dass die Kompatibilität erhalten bleibt. Dieser muss dann die neue Version seiner Plattformbibliothek verbreiten, Änderungen am Anwendungsprogramm (Neukompilierung oder Anpassung) durch Anwendungsentwickler oder Konfigurationsänderungen durch Anwender sind nicht notwendig.

Quellcode-basierende Plattform

Neben dem obigen Konzept einer auf Binärkompatibilität basierenden Plattform, welches eine weitergehende Lauffähigkeit von einmal erstellter Software ermöglicht, existiert noch das Konzept der Kompatibilität über die Portierbarkeit des Quellcodes eines Anwendungsprogramms. Hier wird keine langfristige oder breite Lauffähigkeit der Anwendungsprogramm-Kompilate garantiert,[1] sondern eine Kompilierbarkeit mit einer weiten Palette an unterliegender Hardware, Programmbibliotheken und Software-APIs, auch Plattformunabhängigkeit genannt. Nachteile sind, dass der Vorgang des Kompilierens dann häufiger und vor allem durch den Anwender oder Anwendungsentwickler durchgeführt werden muss, ein manchmal komplexer und fehlerträchtiger Vorgang. Auch die Erstellung portabler Software für eine solche Plattform ist ein Problem.[2] Ebenso kann die Notwendigkeit, dass der Quellcode beim Anwender vorliegen muss, ein Hindernis sein, da beispielsweise bei proprietärer Software eine Offenlegung von diesem unüblich ist. Deshalb ist dieses Konzept der Quellcode-basierenden Kompatibilität vor allem im Opensource-Bereich und bei unixähnlichen Betriebssystemen dominierend, die Binärkompatibilität dagegen beispielsweise bei den Windows-[3][4] oder Mac-Betriebssystemen.[5]

Betriebssystem als Plattform

Beispielsweise ermöglicht es eine Softwareplattform – wie die Win32-API und -Betriebssysteme (auf Betriebssystemebene) – Softwareentwicklern, Anwendungen zu schreiben, die auf veränderlichen Geräten (oder Hardware), wie Prozessoren unterschiedlicher Hersteller, verschiedenen Grafikkarten, verschiedenen Peripheriegeräten usw. funktionsfähig sind. Typischerweise werden solche Anwendungen jedoch zu binären Programmen, bestehend aus Maschinenbefehlen, kompiliert, sind also nur auf einer spezifischen Hardware funktionsfähig, setzen also auf diese Hardwareplattform auf. Dieses Vorgehen kann als Kompromiss aus Effizienz und Abstraktionsgrad betrachtet werden, da dadurch aufwändige Konvertierung zur Laufzeit eingespart werden.

Laufzeitumgebung als Plattform

Bei dynamisch interpretierten Laufzeitumgebungen wird die Anwendung von der Hardware noch weitergehend abstrahiert. Das bedeutet, dass Befehle und Daten einer Laufzeitumgebung oder einem Dienst übergeben werden und dort erst zur Laufzeit interpretiert oder in die entsprechende Maschinensprache übersetzt werden. Weitergehend können mit einer Laufzeitumgebung (z. B. JRE oder Webbrowser) auch verschiedene unterliegende Betriebssysteme, also andere Softwareplattformen, wegabstrahiert werden.

Nichttechnische Aspekte von Plattformen

Marketing

Für die Werbung werden oft Markennamen in vereinfachender Weise, als technisch betrachtet eigentlich zu differenzierende Plattformen, zusammengefasst. Ein bekanntes Beispiel dafür ist die „Macintosh-Plattform“, deren technische Plattformen sich je nach Generation grundlegend unterscheiden können. Diese vereinfachende Sicht ist teilweise in den Sprachgebrauch und die öffentliche Wahrnehmung übergegangen.

So wirbt z. B. die Firma Apple mit der „Macintosh“- bzw. „Mac“-Plattform, obwohl über die gesamte Zeit des Bestehens praktisch alle Plattformen, die Macintosh ausmachen, (teilweise mehrfach) ausgetauscht wurden. Aus technischer Sicht besteht und bestand Macintosh aus sehr unterschiedlichen und teilweise inkompatiblen Hard- und Softwareplattformen. (Macintosh nutzte oder nutzt 680x0, POWER und x86-64. Von Apple-Betriebssystemen verwendete Softwareschnittstellen und Standards sind oder waren Carbon, Cocoa, POSIX, SUS, GNU-Software-Umgebung, JRE etc.). Um den Nutzern einen reibungslosen Wechsel der Plattformen zu gewährleisten, verwendete Apple übergangsweise Ansätze wie Fat Binarys oder Emulatoren. Dadurch wurde die ganze Produktfamilie in der Öffentlichkeit weiter als eine einheitliche Plattform wahrgenommen.

Ähnliches gilt auch für die von der Firma Microsoft beworbene Marke „Windows“. Obwohl die Änderungen nie so umfassend waren wie bei Macintosh, ist auch Windows keine einheitliche Plattform. (Es nutzte oder nutzt die x86-, x86-64-, ARM-, MIPS-, PowerPC- sowie die Alpha-Plattform und stellte oder stellt die DOS-, Win16-, Win32-, Win64-, native API-, Windows-CE-, .NET-, POSIX-, OS/2-Plattform und andere Anwendungen zur Verfügung.) So sind z. B. die Win32- und die Windows-CE-API nur sehr bedingt kompatibel. Alle auf den DOS- oder Windows NT-Kernel aufbauenden Windows-Produkte enthalten mehrere Plattformen, wodurch für Anwendungen eine Rückwärts-Kompatibilität von teilweise bis zu 30 Jahre (im Fall von Win16) erreicht wurde.

Offenheit

Differenzieren lassen sich Plattformen auch über Eigenschaften, wie z. B. das Entwicklungsmodell, Kostenmodell oder den Grad der Offenheit bzw. Freiheit die bei der Verwendung auf verschiedenen Ebenen gewährt wird. Eine Plattform kann z. B. in der Verwendung durch den Endnutzer, als Plattform für Softwareentwicklung oder in der Unterstützung von Hardware durch technische Maßnahmen, das Fehlen von offenen Spezifikationen oder der Notwendigkeit von Lizenzen beschränkt sein. Eine wissenschaftliche Veröffentlichung[6] von 2008 fand beispielsweise die in der Tabelle wiedergegebene Einordnung für aktuelle Betriebssystem-Marken und den zu jender Zeit darin enthalten Plattformen:

Beispiele

Anwendungsschnittstellen und Betriebssysteme

Die Anwendungsschnittstellen werden in der Regel mit den Betriebssystemen mitgeliefert, falls das (noch) nicht der Fall ist, werden sie durch passende Laufzeitumgebungen (nachträglich) zur Verfügung gestellt.

Laufzeitumgebungen

Server-Plattformen

  • LAMP (Linux, Apache, MySQL und PHP)
  • WAMP (Windows, Apache, MySQL und PHP)
  • MAMP (Mac OS X, Apache, MySQL und PHP)

Hardware

Siehe auch

Literatur

Einzelnachweise

  1. ↑ Michael Simms: Handling misbehaving libraries in binary products. Linux Game Publishing, 18. August 2009, archiviert vom Original am 22. Februar 2014; abgerufen am 15. Januar 2012 (englisch): „It is a bit of an arcane artform, making a game that runs on all Linux versions. […] [libraries] will load their own dependencies in a way we cannot control.The biggest problem is that OpenAL and SDL try to dlopen libasound, and on some machines, libasound doesn’t work with our binaries. On others, it can actually crash the whole game due to incompatibilities. This is a common issue when dealing with unknown system configurations when sending out a binary-only product into the world.“
  2. ↑ Troy Hepfner: Linux Game Development Part 2 - Distributable Binaries. gamedev.net, 1. Oktober 2007, archiviert vom Original am 13. Oktober 2007; abgerufen am 19. Dezember 2011 (englisch): „Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]“
  3. ↑ Ian Murdock: On the importance of backward compatibility. 17. Januar 2007, abgerufen am 4. Januar 2012 (englisch).
  4. ↑ Raymond Chen: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? In: The Old New Thing. 15. Oktober 2003, archiviert vom Original am 3. Juli 2004; abgerufen am 4. Januar 2012 (englisch).
  5. ↑ Simon Peter: AppImageKit Documentation 1.0. (pdf; 38 kB) PortableLinuxApps.org, 2010, S. 2-3, abgerufen am 29. Juli 2011: „A critical distinction between the approach known from Windows and the Mac and the one known from UNIX and Linux is the „platform“: While Windows and the Mac are seen as platforms to run software on, most Linux distributions see themselves as the system that includes the applications.“
  6. ↑ a b Thomas R. Eisenmann, Geoffrey Parker und Marshall Van Alstyne: Opening Platforms: How, When and Why? In: Harvard Business School Entrepreneurial Management Working Paper No. 09-030. Harvard Business School, 16. Oktober 2008, S. 2, abgerufen am 8. April 2012 (englisch, 10.2139/ssrn.1264012).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Plattform_(Computer)&oldid=162308200“