Én størrelse passer ikke alle: Hvorfor programvare ikke er universalt kompatibel

Annonse

Du har nettopp lastet ned en funksjonspakket oppdatering til din favoritt open source-app. Alt fungerer bra, og du bruker det på andre enheter - så det er på tide å rulle det ut til de også.

Bortsett fra at den skinnende nye Linux-bærbare datamaskinen din ikke er kompatibel med Windows-installasjonspakken. Hva med Android-nettbrettet ditt? iPhone? PS4? Hvorfor kan du ikke bare ta det programvaren og bruke den hvor du vil? La oss utforske noen forskjellige barrierer mot drømmen om å "kjøpe en gang, løp hvor som helst."

Programvareutvikling og OS-arkitektur

For å forstå hvorfor programvare ikke fungerer på tvers av operativsystemer, krever det litt (bare litt, jeg lover) kunnskap om hvordan programvare lages.

Programvareutviklingsprosessen

I en veldig grunnleggende programvareutviklingsflyt for desktop, server og mobil (dvs. ikke nett Programmering vs. Nettutvikling: Hva er forskjellen?Du kan tro at applikasjonsprogrammerere og webutviklere gjør den samme jobben, men det er langt fra sannheten. Her er de viktigste forskjellene mellom programmerere og webutviklere. Les mer

), vil en programmerer:

1. Skriv inn noen kode inn i en eller flere filer.
2. Kompilere koden til noe datamaskinen kan utføre.
3. Test for å sikre at programmet fungerer som forventet.
4. Pakke og distribuere / distribuere programvaren.

Det er en kombinasjon av første og andre trinn som angår oss her. Prosessen av kompilering programvare, eller å slå den fra kode til de og nuller som en datamaskin forstår (maskinspråk) er komplisert. Vi kommer ikke inn på det i detalj, men det er nyttig å forstå på høyt nivå hva som skjer.

OS-arkitektur

Et viktig poeng å forstå er at et operativsystem ikke er en eneste enhet. Snarere består den av lag med programvare.

Operativsystemkjerner

Et operativsystem kernel er ansvarlig for å kommunisere med maskinvaren på datamaskinen. Programvare kommuniserer kommandoene sine til kjernen, som igjen gir kommandoer til maskinvaren for å (for eksempel) lese en fil fra harddisken, eller tegne et vindu på skjermen. Den koordinerer i utgangspunktet all informasjonen (enten det er lagrede data, beregninger eller brukerinput) mellom maskinvare og forskjellige programvare. Kjernen gjør all denne funksjonaliteten tilgjengelig for programvare via systemanrop.

Kjerneene i hvert operativsystem implementerer systemanrop på en annen måte, i forhold til hvilke som er tilgjengelige, hva de heter eller hvilke alternativer de tar. Som et resultat må programvare ta hensyn til systemanropene som støttes av kjernen i hvert operativsystem den målretter seg mot. Systemanropet du bruker for å sende data til GPU i Linux kan ha et annet navn, liste over informasjon du trenger å oppgi, eller begge deler i Windows. Det eksakte anropet er kanskje ikke en gang i det hele tatt.

Systembiblioteker

I mange tilfeller ringer ikke programvare direkte til kjernen. I stedet ringer det til systembiblioteker, eller samlinger av grunnleggende funksjoner. Biblioteker eksisterer slik at (for eksempel) hvert eneste program som lagrer filer på harddisken, ikke trenger å skrive en funksjon for å gjøre det. I stedet, det ganske enkelt lenker til et systembibliotek og bruker en eksisterende funksjon. GLibC-biblioteket for Linux er et godt eksempel, som også .DLL-filene i Win32 API eller innholdet i en Mac / System / Library-katalog Slik får du tilgang til OS X-bibliotekmappen og hvorfor det er nyttigDe fleste OS X-bibliotekmapper ligger best alene, men det er nyttig å kjenne deg vei i og rundt Brukerbiblioteket. Les mer .

Systembiblioteker fungerer som en slags oversetter mellom applikasjoner og kjernen for rutineoppgaver. Søknader gjør funksjon samtaler til disse bibliotekene, som håndterer mange detaljer på lavt nivå. De kan også foreta systemanrop til kjernen for enkelhets skyld. Som du kanskje har gjettet, betyr dette at disse bibliotekene er skrevet for en bestemt kjerne, og at de derfor ikke kan brukes på tvers av operativsystemer med forskjellige kjerner.

Operasjonssystem Utførelsesoverskrifter

Den siste veisperringen til universell programvare er formatet for kjørbare filer for operativsystemene. Et operativsystem forventer at filene det kjører, følger en bestemt binært filformat Alt du trenger å vite om filformater og deres egenskaperVi bruker ordfilen om hverandre: musikk, bilde, regneark, lysbildefremvisning og så videre. Men hva gjør en fil til en "fil" likevel? La oss prøve og forstå denne grunnleggende delen av databehandling. Les mer . For eksempel filer som kjøres og koblbart format (ELF) som kjører på operativsystemer som Linux og FreeBSD må spesifisere bestemte egenskaper for filen i visse byte, som vist nedenfor bilde.

De applikasjon binært grensesnitt (ABI) vist dyktig er av spesiell betydning. En kombinasjon av samtaler tilgjengelig fra prosessor, kjerne og systembibliotek, er en ABI lik en applikasjonsprogrammeringsgrensesnitt (API) ved at den definerer hvordan to programmer kommuniserer med hverandre. Men API er noe som brukes av programmerere (mennesker) i kildekoden for å indikere to programvarestykker bør snakke med hverandre. ABI er det som faktisk lar dem gjøre det når programvaren er satt sammen og kjørt. Hvert operativsystem implementerer en bestemt ABI, som kanskje eller ikke kan skifte mellom versjoner av det samme operativsystemet.

Generelt implementerer operativsystemer sin egen ABI, bestemt av en kombinasjon av prosessortypen, kjernen og eventuelle standard systembiblioteker. Men noen ganger vil et operativsystem implementere mer enn ett. FreeBSD har støtte for Linux-binærfiler, for eksempel fordi den gir en Linux ABI som et tillegg til FreeBSD-kjernen (i stedet for Linux-kjernen). Dette er forskjellig fra virtualizatiton programmer Hva er en virtuell maskin? Alt du trenger å viteVirtuelle maskiner lar deg kjøre andre operativsystemer på din nåværende datamaskin. Her er hva du bør vite om dem. Les mer for eksempel VMWare eller VirtualBox, som bruker programvare for å simulere en hel maskin (maskinvare og alt). Som et resultat er denne typen ABI-kompatibilitet raskere, men mye mer innsats for å opprettholde. Dette er grunnen til at det er sjelden, selv om Microsoft så nylig verdien Ubuntu er nå tilgjengelig i Windows StoreWindows Insiders kan nå laste ned og installere Ubuntu på Windows 10. Dette bringer Linux og Windows sammen i en uhellig union som noen gang har forestilt seg at de ville leve lenge nok til å være vitne til. Les mer ved å gjøre det.

Unntak: Tolket programvare

Basert på ovennevnte har vi lært at utviklere skriver programvare for en, og bare en, målsystemtype. Bortsett fra når de ikke gjør det. Det er mange applikasjoner som du kan laste ned og kjøre på en Mac, deretter kopiere og kjøre på Windows, og kanskje til og med kopiere igjen og kjøre på Linux uten problemer. Hvordan er dette mulig?

Ligget jeg opp til nå?

Det viser seg at det er en kategori programvare som ser ut på overflaten som om den bare "kjører overalt." Du kan laste ned og kjøre den på hvilken som helst støttet plattform - stikkordet blir "støttet." Faktisk laster du ned kildekoden for applikasjonen, mens en annen applikasjon (de tolk) er liksom å kjøre kildekoden direkte i sanntid. Dette er noe av en forenkling, så la oss se nøyaktig på hvordan dette fungerer med et par språk.

Java

Da Java først ble utgitt, løftet det (bokstavelig talt) "skrive en gang, kjør hvor som helst." Tanken var å skape applikasjoner ved å bruke Java-funksjoner for hvordan du lagrer filer, foreta beregninger eller opprette et program vindu. Så en Java Runtime Enviornment (JRE) for hver støttet datamaskinplattform ville kjøre koden og oversette disse til originale OS-funksjoner. Trikset for Java er da at det ikke kjører "direkte" på operativsystemet. Den kjører i en del av JRE som heter de Java Virtual Machine og det er det som kjører på operativsystemet.

Ved å sette inn dette ekstra programvarelaget mellom applikasjonen og operativsystemet lar Java deg fokusere på et sett med funksjoner som er de samme på tvers av operativsystemer. Du forteller Java hva du vil gjøre, og lar JVM for systemet ditt bekymre deg for hvordan du faktisk gjør det. Bildet nedenfor viser dette i aksjon, hvor JIDE-programvarens Java Desktop Application Framework viser den samme applikasjonen for Mac (øverst), Windows (midten til venstre), "ren Java" (midt til høyre) og Linux (nederst).

Java-programmer "presiserer" seg ikke nøyaktig i sanntid. Snarere vil Java-kompilatoren gjengi dem til "bytecode." Du kan tenke på bytecode som et halvbakt program. Når utvikleren slipper applikasjonen, er den samlet så mye den kan være uten å vite hvilket operativsystem den skal kjøre på. Når du faktisk lanserer den, vil JVM "bake den resten av veien" for å passe til funksjonene som er spesifikke for verts OS.

Python

Et populært tolket språk er Python 5 grunner til at Python-programmering ikke er ubrukeligPython - Du elsker det eller så hater det. Du kan til og med svinge fra den ene enden til den andre som en pendel. Uansett er Python et språk det er vanskelig å være ambivalent om. Les mer . Når du kjører et Python-skript, vil Python-tolken oversette kode til instruksjoner for operativsystemet. Den kan også fungere på samme måte som Java: når du "importerer" kode fra utenfor applikasjonen din, er den samlet til bykode første gang den kjøres. Så vil tolken vite om den påfølgende kjøringen den opprinnelige koden har endret seg, på hvilket tidspunkt den vil kompilere den til ny bytekode på nytt.

Et kult biprodukt av denne "on-demand" -kjøringen er at du kan bruke tolken til å utvikle skriptene dine interaktivt. Ved å skrive "python" på kommandolinjen, starter du tolken, og du kan kjøre kode og se resultatene umiddelbart.

Dette betyr at utviklere kan spille rundt og finpusse ting “live”. Deretter, når en kodelinje gjør det de vil, kopier og lim den inn en skriptfil (som er mye mer effektiv enn "kodekompilertest" -syklusen som ikke-tolkespråklige programmerere må gjøre).

Selv når programvaren er den samme, er det sannsynligvis ikke

Dessverre for brukere har ikke teknologibransjen utviklet et virkelig “universelt” format. Og det gjør det kanskje aldri. Innføring av disse typer standarder resulterer ofte i en "minst fellesnevner" -løsning, med innrømmelser for å få alles godkjenning.

Hva tror du? Vil du heller ha universalt kompatibel programvare, selv om det betydde at den ikke var like bra? Eller har du det bra med operativsystemet du bruker, og har ingen interesse for appene fra andre plattformer? Gi beskjed nedenfor i kommentarene!

Image Credits: Masterchief_Productions / Shutterstock