Platformă (computer)

Conceptul de bază al unei platforme: orice platformă (albastră) deasupra care se așează pe trei „suprafețe” diferite

În informatică, o platformă - numit , de asemenea , un strat sau nivel - reprezintă o bază uniformă pe care programele de aplicație pot fi executate și dezvoltate. Acesta este situat între două componente ale unui sistem informatic . Componenta de mai jos nu este vizibilă pentru componenta care folosește platforma . Prin urmare, aceeași componentă poate fi operată pe diferite „suprafețe” diferite printr-o singură platformă. Există o varietate de platforme și concepte de platformă în sectorul IT.

Componentele posibile ale unei platforme sunt arhitectura computerului , limbajul de programare , bibliotecile și mediile de rulare.

Stabilirea obiectivelor și metodele

Ideea din spatele unei platforme este abstractizarea detaliilor complicate pentru software-ul de aplicații sau dezvoltatorul acestuia.

Pe de o parte, aceste detalii pot fi proprietăți necunoscute ale mediului de execuție în care software-ul aplicației va fi utilizat în viitor, care sunt sau nu cunoscute în momentul dezvoltării aplicației. Aceste proprietăți ale mediului de execuție pot fi, de exemplu, tipul exact și performanța componentelor hardware sau a sistemului de operare cu care aplicația va fi operată de utilizator la un moment dat.

Pe de altă parte, motivația pentru o abstractizare poate fi, de asemenea, complexitatea cunoscută (de exemplu , hardware non-standard , API-uri ale producătorilor concurenți ) care urmează să fie redusă pentru a permite dezvoltatorilor să dezvolte aplicații mai rapid, mai ieftin sau mai ușor.

Această simplificare poate fi realizată oferind dezvoltatorului de aplicații un model funcțional mai abstract de funcționalitate concretă, de obicei sub forma unei interfețe de programare (API), care acoperă funcționalitatea de bază . Pentru aplicația rezultată, acest lucru se face de obicei sub forma unui mediu de execuție interpretat dinamic (de exemplu , JRE , browser ) sau a unui ABI binar pentru funcțiile software cunoscute (de exemplu , Win32 , DirectX ).

O calitate pe care o pot oferi aceste straturi de abstractizare este generalitatea, denumită de obicei compatibilitate . Acest lucru se poate referi la lățimea , adică la cantitatea de detalii diferite, abstractizate, precum și la stabilitatea platformei în timp. Compatibilitatea în timp poate însemna asigurarea compatibilității descendente în cazul dezvoltării ulterioare a unei platforme sau a asigurării producătorului că odată cu apariția de noi „detalii” abstracte (de exemplu, sisteme de operare noi, hardware nou) acestea vor fi integrate în platformă (în sus compatibilitate ).

Tipuri de platforme

Când vine vorba de platforme, se poate face o distincție între platformele software și hardware.

Platforma hardware

O platformă hardware și nivelul mașinii numite descriu o anumită familie de artă sau computer [Procesor] . Nivelul mașinii este dat în principal de o anumită arhitectură de calculator sau procesor și, din punct de vedere logic, se află în partea de jos - sub nivelul aplicației .

O platformă de arhitectura de procesor foloseste un singur limbaj mașină , cuvânt de date dimensiune, ordinea octet , etc. Un exemplu în acest sens este larg raspandita x86 - arhitectura .

Totuși, modul în care comenzile individuale ale acestui limbaj de mașină sunt procesate intern în microprocesor (de exemplu, cu micro-ops ) pot diferi însă foarte mult în cadrul aceleiași platforme. Doar rezultatele finale pe care le furnizează comenzile rămân aceleași.

Platformele hardware pot fi împărțite aproximativ în arhitecturi CISC - și RISC - sunt împărțite. Cu arhitecturile actuale ale procesorului, însă, limitele dintre aceste două tipuri de arhitectură devin din ce în ce mai neclare.

Platforma software

Așa-numitele platforme software , cunoscute și sub denumirea de nivel de aplicație , se disting astfel.

Platforma bazată pe interfață binară

Compatibilitatea în timp poate fi realizată, de exemplu, prin interfețe binare stabile ale bibliotecilor de funcții cu care este accesată platforma. Dacă platforma este dezvoltată în continuare, numai furnizorul platformei trebuie să se asigure că se menține compatibilitatea. Apoi, el trebuie să distribuie noua versiune a bibliotecii platformei sale; nu sunt necesare modificări ale programului aplicației ( recompilare sau adaptare) de către dezvoltatorii de aplicații sau modificări ale configurației de către utilizatori.

Platforma bazată pe codul sursă

În plus față de conceptul de mai sus a unei platforme bazate pe compatibilitate binară, care permite software - ul care a fost creat pentru a rula în continuare, există , de asemenea , conceptul de compatibilitate prin portabilitatea codul sursă al unui program de aplicație. Aici, nici pe termen lung sau executabilitate pe baza largă a programului de aplicație compilatii este garantată, dar compilability cu o gamă largă de hardware care stau la baza, program de biblioteci și API - uri de software, de asemenea , numit platforma independenta. Dezavantajele constau în faptul că procesul de compilare trebuie apoi realizat mai frecvent și mai ales de către utilizator sau dezvoltatorul de aplicații, care este uneori un proces complex și predispus la erori. Crearea de software portabil pentru o astfel de platformă este, de asemenea, o problemă. De asemenea, necesitatea ca codul sursă să fie disponibil utilizatorului poate fi un obstacol, deoarece, de exemplu, divulgarea software-ului proprietar este neobișnuită. Acesta este motivul pentru care acest concept de compatibilitate bazată pe codul sursă este predominant, în special în zona open source și cu sisteme de operare de tip Unix , în timp ce compatibilitatea binară este dominantă în cazul sistemelor de operare Windows sau Mac , de exemplu .

Sistem de operare ca platformă

De exemplu, permite o platformă software - ca API-ul Win32 și altele similare integrate în interfețele sistemelor de operare - dezvoltatorii de software , aplicațiile să scrie că pe hardware diferite, cum ar fi procesoare de la diferiți producători, diferite plăci grafice , diferite periferice etc. sunt funcționale . De obicei, astfel de aplicații sunt, totuși, pentru programe binare , constând din instrucțiuni de mașină , compilate , care sunt funcționale numai pe un anumit hardware, deci pariați pe această platformă hardware. Această procedură poate fi privită ca un compromis între eficiență și gradul de abstractizare, deoarece economisește conversia consumatoare de timp în timpul rulării .

Mediul de execuție ca platformă

În cazul mediilor de runtime interpretate dinamic, aplicația este extrasă din hardware. Aceasta înseamnă că comenzile și datele sunt transferate într-un mediu de execuție sau un serviciu și sunt interpretate acolo doar în timpul rulării sau traduse în limbajul corespunzător al mașinii. În plus, diferite sisteme de operare subiacente , adică alte platforme software, pot fi, de asemenea, extrase cu un mediu de execuție (de exemplu, JRE sau browser web ) .

Aspecte non-tehnice ale platformelor

marketing

Pentru publicitate, numele mărcilor sunt adesea rezumate într-un mod simplist, ca platforme care trebuie să fie diferențiate din punct de vedere tehnic. Un exemplu binecunoscut în acest sens este „ platforma Macintosh ”, ale cărei platforme tehnice pot diferi fundamental în funcție de generație. Această viziune simplistă a trecut parțial în utilizarea lingvistică și percepția publică.

Deci face publicitate z. B. Apple cu platforma „Macintosh” sau „Mac”, deși pe întreaga perioadă de existență practic toate platformele care alcătuiesc Macintosh au fost înlocuite (uneori de câteva ori). Din punct de vedere tehnic, Macintosh este format și constă din platforme hardware și software foarte diferite și uneori incompatibile. (În cursul istoriei sale, „Macintosh” a folosit sau folosește din punctul de vedere al arhitecturii procesorului 680x0 , PowerPC , IA-32 sau x64 și ARM64 . Interfețele software și standardele utilizate de sistemele de operare Apple sunt sau au fost Carbon , Cocoa , POSIX , SUS , mediu software GNU , JRE etc.) Pentru a garanta utilizatorilor o schimbare lină a acestor arhitecturi, Apple a folosit abordări temporare, cum ar fi binarii de grăsime sau binarii universali și emulatoarele (transparente) . Ca urmare, întreaga familie de produse a continuat să fie percepută de public ca o platformă uniformă.

Același lucru se aplică mărcii „ Windows ” promovată de Microsoft . Deși schimbările nu au fost niciodată la fel de extinse ca și Macintosh, nici Windows nu este o platformă unificată. (A folosit sau folosește platformele x86 , x64 , ARM , MIPS , PowerPC , precum și Alpha și a furnizat sau oferă platformele DOS , Win16 , Win32 , Win64 , Native API , Windows CE , .NET , POSIX , OS / 2 și altele aplicații disponibile.) De exemplu, API-urile Win32 și Windows CE sunt compatibile numai într-o măsură foarte limitată. Toate produsele Windows DOS sau Windows NT - kernel- building conțin mai multe platforme, ceea ce pentru aplicații a fost compatibil cu o versiune parțială de până la 30 de ani (în cazul Win16).

deschidere

Producătorii de platforme au abordări diferite în ceea ce privește deschiderea și apropierea platformelor lor. Aceasta privește z. B. modelul de dezvoltare, modelul costurilor sau gradul de deschidere sau libertate care se acordă atunci când se utilizează la diferite niveluri.

Exemple

Interfețe de aplicații și sisteme de operare

Deoarece o interfață de aplicație poate fi numită în mod esențial una prin sistemul de operare introdus sau inclus interfața de programare ( English Application Programming Interface , short-API). Cu toate acestea, există și API-uri multi-platformă care sunt disponibile pe mai multe sisteme de operare ca mediu de execuție și deseori trebuie instalate ulterior.

Medii de rulare

Platforme de server

hardware

  • AMD Am29000
  • SĂRAC
  • Atmel AVR
  • DEC Alpha (64 de biți)
  • IBM 801
  • IBM System / 360 și System / 370 ( adresare pe 24 de biți , 1964 și 1970)
  • IBM System / 390 (adresare pe 31 de biți, 1990)
  • IBM System z (adresare pe 64 de biți, compatibilă descendent cu System / 390, / 370 și / 360, 2000)
  • Intel 4004 (lățimea datelor pe 4 biți cu magistrala de date pe 4 biți, spațiu de adrese pe 12 biți cu magistrala de adrese pe 4 biți, 1971)
  • Intel 4040 (lățime de date de 4 biți cu magistrală de date de 4 biți, spațiu de adrese de 13 biți cu magistrală de adrese de 4 biți, 1974)
  • Intel 8008 (lățime date pe 8 biți cu magistrală de date pe 8 biți, spațiu de adrese de 14 biți cu magistrală de adrese pe 8 biți, 1972)
  • Intel 8080 (lățime date pe 8 biți cu magistrală de date pe 8 biți, spațiu de adrese pe 16 biți cu magistrală de adrese pe 16 biți, 1974)
  • Intel x86 (procesoare Intel 80x86 și compatibile)
  • Intel i960
  • Intel Itanium sau IA-64 (lățimea datelor pe 64 de biți, spațiu de adresă pe 64 de biți, nu este compatibil cu IA-32 și cu 16 biți x86)
  • MIPS
  • Motorola 680x0 (din 2004 Freescale , din 2015 NXP )
    • 6800 și 6809 (Motorola, magistrală de date pe 8 biți, magistrală de adrese pe 8 biți, 1974)
    • 68000 și 68010 (Motorola, magistrală de date pe 16 biți, magistrală de adrese pe 24 de biți, 1979)
    • 68008 (Motorola, magistrală de date pe 8 biți, magistrală de adrese pe 20 de biți)
    • 68012 (Motorola, magistrală de date pe 16 biți, magistrală de adrese pe 31 de biți)
    • 68020 și 68330 (Motorola, magistrală de date pe 32 de biți, magistrală de adrese pe 32 de biți, 1984)
    • 68030 , 68040 și 68060 (Motorola, magistrală de date pe 32 de biți, magistrală de adrese pe 32 de biți, din 1987)
    • ColdFire (Freescale, design 68060, din 2004)
    • Dragonball (Freescale, fost MC68328 de la Motorola, din 1995)
  • Motorola 88000
  • OpenRISC
  • PDP-1 , PDP-4, PDP-7 , PDP-9 și PDP-15 (18 biți)
  • PDP-5, PDP-8 , PDP-12, PDP-14 și PDP-16 (12 biți)
  • PDP-6 și PDP-10 (36 de biți)
  • PDP-11 (16 biți)
  • PA-RISC
  • putere
  • SPARC
  • SuperH
  • VAX (32 de biți)

Vezi si

literatură

Dovezi individuale

  1. ↑ Michael Simms: Manevrarea bibliotecilor care se comportă greșit în produse binare ( engleză ) Linux Game Publishing . 18 august 2009. Arhivat din original la 22 februarie 2014. Accesat la 15 ianuarie 2012: „ Este un pic o formă de artă arcane, făcând un joc care rulează pe toate versiunile Linux. [...] [Bibliotecile] își vor încărca propriile dependențe într-un mod pe care nu-l putem controla. Cea mai mare problemă este că OpenAL și SDL încearcă să deranjeze libasound, iar pe unele mașini, libasound nu funcționează cu binarele noastre. Pe alții, se poate prăbuși de fapt întregul joc din cauza incompatibilităților. Aceasta este o problemă obișnuită atunci când se tratează configurații de sistem necunoscute atunci când se trimite în lume un produs numai binar. "
  2. ↑ Troy Hepfner: Linux Game Development Part 2 - Distribuable Binaries ( engleză ) gamedev.net. 1 octombrie 2007. Arhivat din original pe 13 octombrie 2007. Adus pe 19 decembrie 2011: „ Crearea unui executabil care funcționează pe aproape toate distribuțiile Linux este o provocare. Există o serie de factori care contribuie la problemă [...] "
  3. ↑ Ian Murdock : Despre importanța compatibilității înapoi ( engleză ) 17 ianuarie 2007. Arhivat din original la 14 ianuarie 2012. Informații: linkul arhivă a fost inserat automat și nu a fost încă verificat. Vă rugăm să verificați linkul original și arhivă conform instrucțiunilor și apoi eliminați această notificare. Adus la 4 ianuarie 2012. @ 1@ 2Șablon: Webachiv / IABot / ianmurdock.com
  4. ↑ Raymond Chen : Dar BOZOSLIVEHERE și TABTHETEXTOUTFORWIMPS? ( Engleză ) În: The New New Thing . 15 octombrie 2003. Arhivat din original la 3 iulie 2004. Adus la 4 ianuarie 2012.
  5. ↑ Simon Peter: AppImageKit Documentation 1.0 (PDF; 38 kB) PortableLinuxApps.org. Pp. 2-3. 2010. Arhivat din original la 29 noiembrie 2010. Informații: linkul arhivă a fost inserat automat și încă nu a fost verificat. Vă rugăm să verificați linkul original și arhivă conform instrucțiunilor și apoi eliminați această notificare. Accesat pe 29 iulie 2011: „ O distincție critică între abordarea cunoscută de Windows și Mac și cea cunoscută de UNIX și Linux este„ platforma ”: În timp ce Windows și Mac sunt văzute ca platforme pe care să ruleze software, majoritatea distribuțiilor Linux se consideră sistemul care include aplicațiile. " @ 1@ 2Șablon: Webachiv / IABot / portablelinuxapps.org