Computer

Platform (computer)

Een platform – ook wel laag of niveau genoemd – in de informatica geeft een uniforme basis aan waarop toepassingsprogramma’s kunnen worden uitgevoerd en ontwikkeld. Het bevindt zich tussen twee componenten van een computersysteem . Het onderliggende onderdeel is niet zichtbaar voor het onderdeel dat het platform gebruikt . Daarom kan hetzelfde onderdeel op een platform op verschillende “bases” worden gebruikt. Er zijn verschillende platforms en platformconcepten in de informatica-sector.

Doelstellingen en methoden

Het idee achter een platform is de abstractie van gecompliceerde details voor een applicatiesoftware of de ontwikkelaar ervan.

Aan de ene kant kunnen deze details onbekende eigenschappen zijn van de uitvoeringsomgeving waarin in de toekomst een toepassingssoftware zal worden gebruikt die al dan niet bekend is op het moment van ontwikkeling van de toepassing. Deze eigenschappen van de uitvoeringsomgeving kunnen bijvoorbeeld het exacte type en de prestaties van de hardwarecomponenten zijn, of met welk onderliggende besturingssysteem de toepassing ooit door de gebruiker wordt bediend.

Aan de andere kant kan de motivatie voor abstractie ook gekende complexiteit zijn (bijvoorbeeld niet- gestandaardiseerde hardware, concurrerende leveranciers-API’s) die moeten worden beperkt om ontwikkelaars in staat te stellen applicaties sneller, goedkoper of gemakkelijker te ontwikkelen.

Deze vereenvoudiging kan worden bereikt door de applicatie ontwikkelaar verschaft een samenvatting modelfunctie specifieke functionaliteit, typisch in de vorm van een programmeerinterface (eng. API) waardoorheen onderliggende functionaliteit omhult . Voor de resulterende toepassing wordt dit meestal gedaan in de vorm van een dynamisch geïnterpreteerde runtime-omgeving (bijv. JRE , browser ) of een binaire ABI naar bekende softwarefuncties (bijv. Win32 , DirectX ).

Een eigenschap die deze abstractielagen kunnen bieden, is universaliteit, meestal compatibiliteit genoemd . Dit kan verwijzen naar de breedte , dat wil zeggen het aantal verschillende, geabstraheerde details, evenals de stabiliteit van het platform in de loop van de tijd. Compatibiliteit in de loop van de tijd kan betekenen dat de compatibiliteit met eerdere versies naarmate het platform evolueert, of de garantie van de fabrikant is dat deze met de komst van nieuwe abstracte “details” (bijv. Nieuwe besturingssystemen, nieuwe hardware) in het platform zullen worden geïntegreerd word ( opwaartse compatibiliteit ).

Platformtypen

Mogelijke componenten van een platform zijn een computerarchitectuur , programmeertaal , bibliotheken en runtime-omgevingen.

Hardware Platform

Voor platforms kan een onderscheid worden gemaakt tussen software- en hardwareplatforms. Een platform terwijl de machine horizontaal genoemd beschrijft een specifieke computer art of [Processor] familie . Het machineniveau wordt voornamelijk gegeven door een bepaalde computer- of processorarchitectuur en bevindt zich logischerwijs onderaan – onder het toepassingsniveau .

Een processorarchitectuur platform wordt één machinetaal , informatiewoord grootte, bytevolgorde , etc. Een voorbeeld hiervan is de wijdverbreide x86 – architectuur .

Hoe de afzonderlijke opdrachten van deze machinetaal intern in de microprocessor worden verwerkt (bijv. Met micro-ops ), kan echter sterk variëren binnen hetzelfde platform. Alleen de eindresultaten van de instructies blijven hetzelfde.

Hardwareplatforms kunnen ruwweg verdeeld in CISC – en RISC – architecturen zijn verdeeld. Met de huidige processorarchitecturen vervagen de grenzen tussen deze twee soorten architectuur echter steeds verder.

Software Platform

De zogenaamde software platforms , zoals applicatieniveau of laag genoemd (zie OSI model ), worden als volgt onderscheiden.

Op binaire interface gebaseerd platform

Compatibiliteit in de loop van de tijd kan bijvoorbeeld worden bereikt door middel van stabiele binaire interfaces van functiebibliotheken die worden gebruikt om toegang te krijgen tot het platform. Naarmate het platform evolueert, moet alleen de platformprovider ervoor zorgen dat de compatibiliteit wordt gehandhaafd. Vervolgens moet het de nieuwe versie van zijn platformbibliotheek verdelen, wijzigingen in het toepassingsprogramma ( opnieuw compileren of aanpassen) door applicatieontwikkelaars of configuratiewijzigingen door gebruikers zijn niet nodig.

Op broncode gebaseerd platform

Naast het bovenstaande concept van een op binaire compatibiliteit gebaseerd platform, dat het mogelijk maakt om eenmaal gemaakte software verder te gebruiken, is er nog steeds het concept van compatibiliteit over de draagbaarheid van de broncode van een applicatieprogramma. Hier is geen langdurige of brede uitvoerbaarheid van de compilaties van toepassingsprogramma’s gegarandeerd, [1] maar compileerbaarheid met een breed scala aan onderliggende hardware, programmabibliotheken en software-API’s, inclusief platformonafhankelijkheidgenoemd. Nadelen zijn dat het proces van compileren dan vaker en vooral door de gebruiker of applicatie-ontwikkelaar moet worden gedaan, een soms complex en foutgevoelig proces. Het creëren van draagbare software voor een dergelijk platform is ook een probleem. [2] Evenzo kan de noodzaak dat de broncode beschikbaar is voor de gebruiker een obstakel zijn, zoals bijvoorbeeld bij bedrijfseigen software, het vrijgeven hiervan is ongebruikelijk. Daarom is dit concept van op broncode gebaseerde compatibiliteit dominant, vooral in de open-source en unix-achtige besturingssystemen , terwijl binaire compatibiliteit dominant is in Windows , bijvoorbeeld[3] [4] of de Mac-besturingssystemen . [5]

Besturingssysteem als platform

Bijvoorbeeld, is het mogelijk een software platform – zoals de Win32 API en andere soortgelijke integrere in besturingssystemen interfaces – software-ontwikkelaars , applicaties te schrijven die op variabele, hardware , zoals processors van verschillende fabrikanten, verschillende grafische kaarten , diverse randapparaten , etc. zijn functioneel. Typisch zijn dergelijke toepassingen moeten binair programma, bestaande uit machineinstructies , samengesteld, zijn daarom alleen functioneel op een specifieke hardware, dus zet dit hardwareplatform op. Deze benadering kan worden gezien als een compromis tussen efficiëntie en niveau van abstractie, omdat het kostbare conversie tijdens runtime bespaart .

Runtime-omgeving als platform

Voor dynamisch geïnterpreteerde runtime-omgevingen wordt de applicatie verder geabstraheerd van de hardware. Dit betekent dat opdrachten en gegevens worden overgedragen naar een runtime-omgeving of een service , waar ze worden geïnterpreteerdtijdens runtime of worden vertaald naar de juiste machinetaal. Bovendien kunnen met een runtime-omgeving (bijv. JRE of webbrowser ) verschillende onderliggende besturingssystemen , dat wil zeggen andere softwareplatforms, worden weggevaagd.

Niet-technische aspecten van platforms

Marketing

Voor advertenties worden merknamen vaak op een simplistische manier samengevat dan technisch gedifferentieerde platforms. Een bekend voorbeeld hiervan is het ” Macintosh- platform”, waarvan de technische platformen fundamenteel kunnen verschillen, afhankelijk van de generatie. Deze simplistische kijk is gedeeltelijk omgezet in taal en publieke perceptie.

Dus z. Bijvoorbeeld het bedrijf Apple met het ” Macintosh ” – of “Mac” -platform, hoewel vrijwel alle platforms die deel uitmaken van de Macintosh (soms meerdere keren) zijn vervangen door de hele bestaansperiode. Vanuit technisch oogpunt was en is Macintosh een zeer divers en soms incompatibel hardware- en softwareplatform. (Macintosh gebruikte of gebruikte 680×0 , POWER en x64 .) Software-interfaces en standaarden die door Apple-besturingssystemen worden gebruikt, zijn of waren koolstof, Cocoa , POSIX , SUS , GNU software-omgeving , JREetc.). Om ervoor te zorgen dat gebruikers probleemloos van platform veranderen, gebruikte Apple overgangsbenaderingen zoals vetbinair of emulator . Als gevolg hiervan bleef de gehele productfamilie door het publiek als een enkel platform worden gezien.

Hetzelfde geldt voor de advertenties van het bedrijf Microsoft- merk ” Windows “. Hoewel de wijzigingen nooit zo uitgebreid waren als op de Macintosh, is Windows geen uniform platform. (Het gebruikte of gebruikte de x86 , x64 , ARM , MIPS , PowerPCen Alpha platforms , en leverde of stelde de platforms DOS , Win16 , Win32 , Win64 , Native API , Windows CE , .NET , POSIX , OS / 2 inen andere beschikbare toepassingen.) So z. De Win32- en Windows CE-API’s hebben bijvoorbeeld een zeer beperkte compatibiliteit. Alle DOS of Windows NT – kernel -gebouw Windows-producten bevatten meerdere platforms, het creëren van een achterwaartse compatibiliteit van gedeeltelijk tot 30 jaar is bereikt (in het geval van Win16) voor toepassingen.

Openheid

→ Hoofdartikel : Gesloten platform

Platformleveranciers hebben verschillende benaderingen van de openheid of integriteit van hun platforms. Dit betreft z. Bijvoorbeeld het ontwikkelingsmodel, kostenmodel of mate van openheid of vrijheid geboden door gebruik op verschillende niveaus.

Voorbeelden

Toepassingsinterfaces en besturingssystemen

Als een applicatie-interface is in wezen een door bekwame besturingssysteem geïntroduceerd of opgenomen programming interface ( Engels Application Programming Interface , short-API) worden genoemd. Er zijn echter ook platformonafhankelijke API’s die als een runtime-omgeving op meerdere besturingssystemen beschikbaar zijn en vaak later moeten worden geïnstalleerd.

  • AmigaOS ( AROS , MorphOS )
  • Android Runtime
  • Bada
  • BlackBerry
  • Carbon ( klassieke Mac OS , macOS )
  • Cocoa (macOS, GNUstep , iOS , …)
  • GNU software-omgeving, het GNU-project ( Unix / BSD , Linux , Fink , Cygwin …)
  • Linux Standard Base , LSB
  • Native API ( Windows NT )
  • OpenVMS
  • OS / 2
  • OS / 400
  • Palm OS
  • Draagbare besturingssysteeminterface , POSIX (Unix / BSD incl. MacOS, Linux, Windows NT, …)
  • Enkele UNIX-specificatie , SUS ( Unix , macOS)
  • Symbian
  • Windows Application Programming Interface : Win16, Win32, Win64 ( Windows , WinOS / 2 , ReactOS , Wine , …)
  • Windows CE ( Windows Mobile , Windows Phone , Windows Embedded )
  • z / OS
  • z / VM

Runtime-omgevingen

  • Adobe AIR
  • Common Language Runtime
  • Java Runtime Environment
  • mono
  • Mozilla Prism
  • PHP
  • uniPaaS

Serverplatforms

  • LAMP ( Linux , Apache , MySQL en PHP )
  • MAMP ( Mac OS X / OS X / macOS , Apache, MySQL en PHP)
  • WAMP ( Windows , Apache, MySQL en PHP)

Hardware

  • AMD Am29000
  • ARM
  • Atmel AVR
  • DEC Alpha (64-bit)
  • IBM 801
  • IBM System / 360 and System / 370 (24-bits adressering , 1964 en 1970)
  • IBM System / 390 (31-bits adressering, 1990)
  • IBM System z (64-bits adressering, achterwaarts compatibel met System / 390, / 370 en / 360, 2000)
  • Intel 4004 (4-bits gegevensbreedte met 4-bits gegevensbus, 12-bits adresruimte met 4-bits adresbus, 1971)
  • Intel 4040 (4-bits gegevensbreedte met 4-bits gegevensbus, 13-bits adresruimte met 4-bits adresbus, 1974)
  • Intel 8008 (8-bits gegevensbreedte met 8-bits gegevensbus, 14-bits adresruimte met 8-bits adresbus, 1972)
  • Intel 8080 (8-bits gegevensbreedte met 8-bits gegevensbus, 16-bits adresruimte met 16-bits adresbus, 1974)
  • Intel x86 (Intel 80×86 en compatibele processors)
    • 8086 / 8088 , 80186 / 80188 , Z80 en V20 (16-bit databreedte van 16 bits databus 20-bits adresruimte 20-bits adres, 1979)
    • 80286 (16-bits gegevensbreedte met 16-bits gegevensbus, 24-bits adresruimte met 24-bits adresbus, 1982)
    • 80386 (32-bits gegevensbreedte met 32-bits gegevensbus , 32-bits adresruimte met 24-bits adresbus , 1985)
    • IA-32 of i386 geeft de instructieset van de 80386 aan
    • talrijke instructieset-uitbreidingen voor IA-32 zoals AVX , FMA , MMX , PAE , SSE en nog veel meer.
    • IA-32 instructieset uitbreiding x64 (geïmplementeerd door AMD64 en Intel 64 : 64-bits gegevensbreedte, 64-bits adresruimte)
  • Intel i960
  • Intel Itanium of IA-64 (64-bits gegevensbreedte, 64-bits adresruimte, niet compatibel met IA-32 en 16-bits x86)
  • MIPS
  • Motorola 680×0 (uit 2004 Freescale , vanaf 2015 NXP )
    • 6800 en 6809 (Motorola, 8-bit databus, 8-bit adresbus, 1974)
    • 68000 en 68010 (Motorola, 16-bit databus, 24-bit adresbus, 1979)
    • 68008 (Motorola, 8-bits gegevensbus, 20-bits adresbus)
    • 68012 (Motorola, 16-bit databus, 31-bit adresbus)
    • 68020 en 68330 (Motorola, 32-bit databus, 32-bit adresbus, 1984)
    • 68030 , 68040 en 68060 (Motorola, 32-bit databus, 32-bit adresbus, vanaf 1987)
    • ColdFire (Freescale, 68060 ontwerp, vanaf 2004)
    • Dragonball (Freescale, voorheen MC68328 van Motorola, uit 1995)
  • Motorola 88000
  • OpenRISC
  • PDP-1 , PDP-4, PDP-7 , PDP-9 en PDP-15 (18-bits)
  • PDP-5, PDP-8 , PDP-12, PDP-14 en PDP-16 (12-bit)
  • PDP-6 en PDP-10 (36-bits)
  • PDP-11 (16-bits)
  • PA-RISC
  • macht
    • IBM Power (oorspronkelijk in de spelling POWER)
    • IBM en Motorola (vanaf 2004 Freescale , vanaf 2015 NXP ) PowerPC
  • SPARC
  • SuperH
  • VAX (32-bits)

Zie ook

  • kader

Literatuur

  • David S. Evans, Andrei Hagiu, Richard Schmalensee: Invisible Engines. Hoe softwareplatforms innovatie en transformatie industrieën stimuleren , MIT Press , Cambridge, Londen 2006, ISBN 0-262-05085-4 – behandelt softwareplatforms

Individuele proeven

  1. Jump up↑ Michael Simms: omgaan met zich misdragende bibliotheken in binaire producten ( Engels ) Linux Game Publishing . 18 augustus 2009. Gearchiveerd vanaf origineel op 22 februari 2014. Opgestuurd op 15 januari 2012: “ Het is een beetje een geheimzinnige kunstvorm, die een spel maakt dat op alle Linux-versies draait. […] [bibliotheken] willen hun eigen afhankelijkheden laden op een manier die we niet kunnen controleren. Het grootste probleem is dat OpenAL en SDL libasound proberen te verduisteren, en op sommige machines werkt libasound niet met onze binaire bestanden. In andere gevallen kan het hele spel crashen vanwege incompatibiliteit. Dit is een veelvoorkomend probleem bij het omgaan met onbekende systeemconfiguraties bij het verzenden van een binair product naar de wereld.
  2. Jump up↑ Troy Hepfner: Linux Game Development Deel 2 – Te distribueren binaire bestanden( Engels ) gamedev.net. 1 oktober 2007. Gearchiveerd vanaf origineel op 13 oktober 2007. Toegankelijk 19 december 2011: “ Het maken van een uitvoerbaar bestand dat op bijna alle Linux-distributies werkt, is een uitdaging.” Er zijn een aantal factoren die bijdragen aan het probleem […] “
  3. Jump up↑ Ian Murdock : Over het belang van achterwaartse compatibiliteit ( Engels ) 17 januari 2007. Betreden op 4 januari 2012.
  4. Jump up↑ Raymond Chen : Hoe zit het met BOZOSLIVEHERE en TABTHETEXTOUTFORWIMPS? ( Engels ) In: The Old New Thing . 15 oktober 2003. Gearchiveerd vanaf origineel op 3 juli 2004. Betreden op 4 januari 2012.
  5. Jump up↑ Simon Peter: AppImageKit Documentation 1.0 (PDF, 38 kB) PortableLinuxApps.org. P. 2-3. 2010. Opgerold op 29 juli 2011: “ Windows en de Mac zijn hard op weg een softwareplatform te worden”. de meeste Linux-distributies zien zichzelf als het systeem dat de applicaties omvat.