Hva er et operativsystem, og hvordan virker det?

Kompendium beregnet på elever ved
Oslo By Steinerskole,
datalinjen, 1.skoleår.

(Kilde: artikkel av Curt Franklin, sakset fra www.howstuffworks.com).

Det er ikke urimelig å si at det er operativsystemet som, i størst grad, farver vår erfaring med datamaskiner. Det er det første vi ser av programvare når vi starter datamaskinen og det er det siste vi ser når vi skrur datamaskinen av igjen. Det er denne programvaren som får alle programmene (applikasjonene) til å virke. Operativsystemet organiserer og kontrollerer maskinvare både på og under pulten samt det vi har under hendene (tastatur / mus / etc.). Allikevel er det ofte slik at dersom man spør brukere, også erfarne brukere, hva operativsystemet egentlig gjør, er det mange som blir svar skyldig. Mange har en relativt god forståelse, men forbausende mange lever med misforståelser og rene feiloppfatninger.
Vi skal se litt på hvilke krav som stilles til programvare (software) for at det kan kalles et operativsystem fremfor program.

Det mest grunnleggende:

Det er meget viktig å være klar over at slett ikke alle datamaskiner (computere) har et operativsystem. Computeren som styrer mikrobølgeovnen hjemme på kjøkkenet, for eksempel, trenger ikke et operativsystem. Den har bare noen få, relativt enkle oppgaver. Den har også et meget enkelt input / output system. Den skal holde orden på en klokke, hvor mye strøm som sendes til elektronkanonen (hvor mange Watt den skal bruke, altså tining, full styrke etc.) og kunne avbrytes hvis døren åpnes. Kanskje det er roterende tallerken også. I/O systemet består av et enkelt LCD display og et minitastatur. Dette er forhold som er enkle og som er stabile, de endres aldri. Maskinvaren forandrer seg ikke. Det kommer aldri et nytt lydkort. I verste fall kan en komponent byttes ut ved en reparasjon, men da settes det alltid inn maken komponent.
For en slik datamaskin; ja, det er faktisk en datamaskin, ville et operativsystem bare være ekstra bagasje å drasse på. Det ville gjøre apparatet unødvendig komplisert og sikkert fordyre maskinen. Computeren i en mikrobølgeovn er bygget for å kjøre kun et eneste program hele tiden, alltid. Dette programmet, akkurat som med maskinvaren, forandres ikke.

Dersom en datamaskin skal kunne mer enn det som skjer på mikrobølgeovnens nivå er ofte et operativsystem nøkkelen til god funksjonalitet, enkelhet og brukervennlighet. Det med brukervennlighet kan slå begge veier. Det er ikke sikkert at det ville være noe lettere å betjene en mikrobølgeovn bare fordi den har fått et operativsystem istedenfor å være hardkodet. Mikrobølgeovnens datamaskin virker på samme, grunnleggende måte som de aller tidligste datamaskinene, for eksempel ENIAC.

For datamaskiner som vi ønsker at skal ha flere funksjoner enn en mikrobølgeovn, et elektronisk tenningssystem i en bil, eller et avansert fotografiapparat er det ofte nødvendig med et operativsystem. Dersom det er ønskelig å kunne endre programmer eller maskinvare (mer enn en svært sjelden gang) er det nødvendig med et operativsystem.
Alle ”desktop” computere har et operativsystem, men det kan variere voldsomt hvilket som er i bruk. Det finnes svært mange å velge mellom.
De vanligste operativsystemene er Windows-familien, Unix-familien og Macintosh. Det finnes hundrevis av andre operativsystemer for spesialiserte datamaskiner, roboter, kontrollsystemer for sanntidsoverføring også videre. Det finnes også spesialiserte operativsystemer for stormaskiner (mainframes) og andre noder for eksempel har Cisco et eget operativsystem for rutere. Et slikt operativsystem er spesialtilpasset for rutere, det er ikke i stand til å kjøre programmer eller spill, annet enn de rutingtabellene de skal betjene og dertil takle I/O fra et eller flere nettverksgrensesnitt. Hvorfor skulle man legge til mulighet for å kjøre Word på en ruter? Det er bare unødig ballast og bør unngås.

På det mest grunnleggende nivået har et operativsystem egentlig bare to oppgaver:

• Det skal styre alle de ressursene maskinen har. Både programvare og maskinvare. Det kan være kontrollen over drivere, prosesser, prosessor, RAM, harddiskplass, I/O gjennom com og parallellporter og lignende.

• Det skal tilby applikasjoner (for eksempel tekstbehandlere) et fast sett med regler for hvordan disse programmene kan benytte maskinvare uten å kjenne til detaljer om maskinvare. Det skal være unødvendig for et spill som Tetris å vite hvilken type harddisk, hvilket filsystem du har eller søketiden for RAM. Operativsystemet skal tilby et standard interface som alle programmer kan benytte uten videre. Hvordan dette grensesnittet er, varierer fra operativsystem til operativsystem. Dette er årsaken til at du ikke kan ta et program som er skrevet for Linux og kjøre det på en Macintosh.

  Den første oppgaven å styre maskinvare og programvareressurser, er svært viktig ettersom det kan være mange programmer og annet input som kjemper om å få bruke prosessorens tid. De forskjellige programmene og prosessene som foregår krever også RAM, bruk av diskplass, virtuelt minne og I/O-båndbredde. Det kan ikke være slik at et program, alene, får ta alle ressurser. Dette er det altså operativsystemets oppgave å holde orden på. Operativsystemets oppgave er å være en slags snill mamma som sørger for at alle får oppmerksomhet, men det kan variere hvor mye de får, de kan ha forskjellig viktighetsgrad, det vi gjerne kaller å ha forskjellig prioritet. En datamaskin har alltid en begrensning i ressursene og det er operativsystemets oppgave å sørge for rettferdig fordeling blandt de som sloss om tilgang.

  Den andre oppgaven å tilby et standardgrensesnitt som applikasjoner kan benytte er spesielt viktig dersom operativsystemet skal kunne brukes på datamaskiner av forskjellig type, eller hvis man må regne med at maskinvarekonfigurasjonen (hva som er der av hardware) kan endres. Det vi tenker på her er om en bruker selv kan bytte ut harddisk, nettverkskort, lydkort eller andre komponenter. Et konsistent (= som er det samme hele tiden) API (application programming interface), et programmeringsgrensesnitt, gjør at programmerere og programutviklere kan skrive et program for en maskin og fremdeles ha en relativt høy grad av sikkerhet for at dette programmet også kan kjøres på en tilsvarende maskin, selv om mengde RAM og diskplass ikke er det samme. Vi som er vanlige brukere og sjelden eller aldri har brukt annet enn IBM kompatible datamaskiner tenker ofte ikke på at den graden av mulighet for å bytte ut maskinvare, disker og ekspansjonskort, uten særlige problemer, slett ikke er det som er vanlig i resten av dataverdenen. Slik er det stort sett bare mikromaskiner beregnet på hjemmebruk og små til mellomstore bedrifter, eller som nettverkstilkoblede arbeidsstasjoner som er konstruert. Årsaken er at det er veldig krevende å skrive et operativsystem som skal kunne tilpasses alt mulig av maskinvare og programvare og dette krever massevis av ressurser fra operativsystemet og at selve operativsystemet blir stort (Windows 2000 har mer enn 40 millioner linjer med kode…). Det vi gjør er altså å si at det er operativsysteme5t som snakker til maskinvare og så kan programmene snakke til operativsystemet og ikke behøve å tenke på hva slags maskinvare som ligger i bunn. Et eksempel her er hvordan Windows 2000 kan betjene tusenvis av forskjellige skrivere fra forskjellige produsenter. Microsoft gir beskjed om hvordan en driver kan snakke til Windows 2000 og så er det opp til skriverprodusenten å vite hvilken type maskinvare som er i printeren, det bryr ikke Windows seg om, og printerprodusenten trenger ikke å tenke på hvem som har produsert parallellporten, det er allikevel operativsystemet som skal snakke til den. Vi har fått en ”tolketjeneste” mellom bruker, applikasjon og maskinvare. Denne ”tolken” er operativsystemet.

  Innenfor operativsystemer er det egentlig fire grupper, eller familier basert på hvilken type datamaskiner de brukes på, og hvilken type applikasjoner de støtter.

  • Real-time operativsystemer (RTOS) – Disse operativsystemene brukes hovedsakelig til å styre maskiner, industriroboter, vitenskaplige instrumenter og industrielle systemer. Et typisk RTOS har få, eller ingen grensesnitt hvor brukere kan ”gjøre noe”. Det er på en måte et operativsystem som ligger i en lukket eske, det er ferdig konfigurert for sine få og begrensede oppgaver når det blir levert. En hyperviktig del av oppgavene som et RTOS har er å styre ressursene slik at en bestemt operasjon utføres på nøyaktig like lang tid hver gang den samme operasjonen skal utføres. I et komplekst industrielt system (tenk deg et helautomatisk samlebånd som setter sammen et eller annet produkt) vil det være like katastrofalt om en operasjon utføres for tidlig, bre fordi det er ledige systemressurser, som at operasjonen ikke blir utført fordi systemet er opptatt. En automatisk lakkeringsbedrift er et godt eksempel: dersom delen som skal lakkeres dyttes videre til pakkeavdelingen før den ble lakkert, bare fordi det er ledig kapasitet i pakkeavdelingen, vil det være like galt som å begynne å lakkere før gjenstanden har kommet frem til lakkering, bare fordi malesprøyten tilfeldigvis var ledig.

  • Single-user – single-task – Som navnet antyder er dette et operativsystem som er beregnet på at det er en bruker, som gjør en ting av gangen. Et godt eksempel på et single-user, single-task operativsystem er Palm OS for håndholdte datamaskiner.

  • Single-user – multi-tasking – Dette er den typen operativsystemer vi vanligvis finner på desktop, laptop og hjemmedatamaskiner. Windows98 og MacOS (t.o.m. ver. 9) er typiske eksempler på operativsystemer som lar en enkelt bruker gjøre flere ting samtidig. Det er for eksempel fullstendig mulig for en bruker å laste ned en fil fra Internet samtidig som hun skriver et brev i en tekstbehandler og hører på musikk fra lydkortet.

  • Multi-user – Et ”multi-bruker” operativsystem lar flere brukere benytte systemressurser samtidig. Operativsystemets oppgave blir å betjene alle brukere slik at ingen blir nedprioritert i forhold til andre brukere og at den enkelte brukers programmer får nok prosessortid og RAM. Dersom et program crasher hos en bruker skal det ikke føre til at maskinen crasher, eller at andre brukere påvirkes av denne programfeilen. Typiske eksempler på multi-user systemer er OS400 (for IBM AS400 maskiner), Unix og VMS (OpenVMS) og en rekke mainframe operativsystemer. En mainframe er en stor maskin…

  Her er det viktig å klare å skille mellom et egentlig multi-user system og et single-user system som støtter nettverk. Både Windows 2000 og Novell Netware (vi snakker om serverversjonene) kan støtte tusenvis av brukere over et nettverk, men ingen av disse to er egentlig ekte fler-brukersystemer. Det er egentlig bare én bruker på et Windows 2000 eller Novell NetWare system og det er administrator. Alle log-in fra brukere over nettverket og nettverksstøtten i seg selv er, strengt tatt, slik operativsystemet ”ser” det, et program som kjøres av administratorkontoen.
  Med disse forskjellene i de ulike typene av operativsystemer i bakhodet, er det på tide at vi ser litt på de grunnleggende funksjonene et operativsystem må kunne tilby.

  Opp og gå!

  Når man skrur på strømmen til en datamaskin er det første programmet som kjøres et lite sett med instruksjoner som ligger lagret i maskinens Read Only Memory (ROM). Dette lille programmet kontrollerer maskinvaren og ser til at alt er i orden og at det er slik det var forrige gang maskinen var oppe. Det er dette vi kaller maskinens Power On Self Test (POST). Det kontrollerer det meste, men viktigst er prosessor, RAM og I/O system (BIOS). Resultatet av denne kontrollen lagres i en spesiell, reservert del av RAM. Så snart POST rutinen er ferdig og godkjent vil et nytt lite program som ligger lagret i ROM (også kjent som firmware) begynne å aktivere maskinens harddisker. I de aller fleste moderne systemer er det gjort slik at så snart diskene er satt i gang vil systemet finne den aller første introduksjonen til operativsystemet i spor 0 på harddisken. Denne programrutinen er den vi kaller systemets bootstraploader.
  Bootstrap-loader er et lite program som bare har en eneste oppgave; å laste operativsystemets kjerne til RAM og la det få overta kontrollen. På en Windows 2000 maskin heter bootstrap-loader ntldr. I sin aller enkleste form er det nok at bootstrap-loader setter opp de driverene som kommuniserer (snakker) med maskinvaren i maskinen. Det er ikke uvanlig å kalle maskinvare for hardware subsystems. Det neste det må gjøre er å dele opp RAM slik at operativsystemet får en del reservert, bruker ID (log-on informasjon) får en del og applikasjonene får noe RAM å bruke.
  Bootstrap må også sette opp de datastrukturene som holder og kontrollerer den myriaden av forskjellige flagg, signaler og semaforer som brukes i kommunikasjonen med maskinvare og applikasjoner. Det settes opp Interrupt for maskinvare (IRQ) og programmer (INT).
  Derefter vil bootstrap overlate kontrollen til operativsystemet.
  Dette er i den enkleste formen, avanserte operativsystemer kan ha delt dette opp i en mengde andre rutiner og underliggende rutiner, men det grunnleggende vil stort sett alltid være mulig å finne igjen.

  Operativsystemets oppgaver kan deles inn i seks hovedkategorier, i alle fall hvis vi ser helt generelt på det:
  
  
  

  • Prosessorstyring

  • Minnestyring

  • Maskinvarestyring

  • Diskplasstyring

  • Applikasjonsgrensesnitt

  • Brukergrensesnitt
    
    
    

  Det er nok mange som vil hevde at et operativsystem bør kunne mer enn disse seks oppgavene, og det er mange produsenter / selgere av operativsystemer som legger ved mye mer. Det kan være både applikasjoner som følger med pakken (NotePad og Paint i Windows og Gimp i Linux er eksempler på slikt) eller overvåknings og kontrollsystemer som går lenger, eller er kraftigere enn det som er vanlig.
  La oss ta en titt på hvilke verktøy og metoder operativsystemet bruker for å utføre dette.

  Prosessorstyring

  I bunn og grunn koker dette med prosessorstyring ned til to oppgaver som henger sammen med hverandre:
  
  
  

  • Sørge for at alle applikasjoner og prosesser får tilstrekkelig oppmerksomhet fra CPU-tid til å kunne fungere skikkelig.

  • Sørge for at så mange prosessorsykluser som mulig blir brukt til noe.
    
    
    

  En prosessorsyklus er en regneoperasjon. Hvis man har en prosessor på 800 MHz vil den gå gjennom 800 millioner prosessorsykluser i sekundet. En syklus som ikke har en oppgave vil få den såkalte Idle prosess å arbeide med. Det er den som heter ledig systemprosess på norsk. Dette er bare et enkelt regnestykke som prosessoren regner om igjen og om igjen hvis den ikke gjør noe annet. Prosessoren kan bare gå på en hastighet når den er på, den kan ikke saktne farten og den kan ikke stanse. Derfor har den et dusteregnestykke å holde på med hvis det ikke er noe fornuftig å gjøre.
  Den grunnleggende enheten som operativsystemet kontrollerer når det gjelder prosessorstyring er enten en prosess eller en tråd (thread), avhengig av hvilket operativsystem vi bruker.

  Det er fristende å velge å ikke se forskjell på en prosess og en applikasjon. Det gjør det hele så meget enklere… Imidlertid vil du ikke få den fulle og hele forståelse av hva som foregår, hvordan prosesser forholder seg til (interacts with) operativsystemet og maskinvaren.
  Det programmet du ser på skjermen (for eksempel en tekstbehandler) er, naturlig vis, en prosess, men det programmet (applikasjonen) kan starte en rekke andre prosesser. En type kunne være en nettverksprosess for å hente et dokument fra en server, eller fra en lokal harddisk. Det er vanligvis også en del prosesser forbundet med programmet som går i bakgrunnen, det vil si at du som bruker ikke ser eller får vite om dem.
  En prosess er altså et stykke programvare som utfører en eller annen handling og som kan avbrytes av en bruker, andre applikasjoner eller av operativsystemet.
  Det er prosesser, ikke applikasjoner som blir styrt av operativsystemet på den måten at de tildeles prosessortid efter behov.
  I et single-task system er denne styringen ganske grei. Operativsystemet tillater programmet å kjøre (eksekvere), og vil bare avbryte prosessene som tilhører programmet lenge nok til å kunne ta seg av andre interrupt og brukerens input.
  et interrupt er et spesielt signal som sendes ut fra maskinvare eller programvare for å tilkalle oppmerksomhet fra CPU.
  Det finnes to hovedtyper av interrupt, det er maskerte og ikke-maskerbare (masked or non-maskable) interrupt.
  Et maskert interrupt kan operativsystemet ignorere, eller la vente til en eller annen oppgave den holder på med er ferdig.
  Non-maskable interrupts er feilmeldinger fra for eksempel RAM. Disse feilmeldingene er så viktige at uansett hva CPU holder på med, må den avbryte det og behandle interruptet. Slike interrupts er gjerne noe som kommer noen mikrosekunder før skjermen blir blå og skriften hvit…

  Selv om interrupt (interrupt = avbrudd) vanskeliggjør kjøring av programmer og prosesser i et single-tasking system, blir denne oppgaven i betydelig grad vanskeliggjort dersom det er et multitasking system.
  for det første må operativsystemet betjene flere programmer og bytte mellom dem, slik at det ser ut til at flere ting skjer samtidig. Dette er mer komplisert enn det høres ut, prosessoren kan nemlig bare gjøre én ting av gangen. For å kunne gi inntrykk av at det foregår flere ting samtidig må operativsystemet sørge for at prosessoren bytter tråd / prosess flere tusen ganger i sekundet. Dette foregår slik:
  
  
  

  • En prosess ligger i en liten del av RAM som er reservert for denne prosessen. Den bruker også registre, stacker og køer inne i selve prosessoren.

  • Når to programmer multitasker (kjøres ”samtidig”) vil operativsystemet tillate hver av dem å kjøre et visst antall sykluser.

  • Efter at disse syklusene er ferdige vil operativsystemet ta en kopi av alle registre, stacker og køer og noterer seg hvor i prosessen dette avbruddet skjedde.

  • Derefter lar den den andre prosessen kjøre et visst antall sykluser.

  • Når den andre prosessen er ferdig med de syklusene den fikk tildelt, vil operativsystemet ta kopi av aller registre, stacker og køer, og laster inn den første prosessen igjen.
    
    
    

  Slik skiftes det mellom prosesser, og dersom det blir mange prosesser eller tråder som skal betjenes vil operativsystemet sette ned antall sykluser hver tråd får lov til å bruke før et bytte må finne sted.
  Al informasjon som trengs for å få til disse byttene (kopiene av prosessene) lagres i en datapakke som kalles prosess control block.
  En typisk prosesskontrollpakke inneholder:
  
  
  

  • Et ID nummer som identifiserer prosessen.

  • Pekere som viser hvor i prosessen databehandlingen sluttet forrige gang.

  • Innholdet i registeret.

  • Hvilken tilstand (status) de forskjellige flagg har.

  • Pekere som viser øvre og nedre grense for hvilket område i RAM denne prosessen skal bruke.

  • En liste over filer som er åpnet av prosessen (ofte .dll filer)

  • Prosessens prioritet

  • Oversikt over tilstand (status) for alle de I/O enhetene som prosessen eventuelt trenger / bruker.
    
    
    

  Når en prosess endrer status, for eksempel fra ventestatus til aktiv, vil de data som ligger i prosess control block bli brukt som om det var data i et vanlig program, og det brukes til er å fortsette kjøringen av prosessene og til å foreta selve bytteoperasjonen. Husk at dette går veldig fort!

  Denne byttingen mellom prosesser foregår i det stille, uten at brukeren trenger å gjøre noe, eller oppdage hva som skjer for den saks skyld.
  Det er imidlertid en ting det er viktig å være klar over; selve bytteprosessen krever også noen prosessorsykluser. Dette kan bety problemer. Hvis man starter alt for mange programmer samtidig vil det bli så mange prosesser å bytte mellom at operativsystemet tar storparten, eller i ekstreme tilfeller alle prosessorsyklusene til selve bytteprosessen. Hvis operativsystemet ikke er godt nok skrevet kan slikt skje. En situasjon som denne kalles thrashing, og det kreves vanligvis direkte inngrep fra brukeren for å stanse dette. I mange tilfelle er det bare en ting brukeren kan gjøre: å boote systemet.

  Det finnes metoder for å begrense muligheten for thrashing. En vanlig brukt metode er å begrense behovet for at nye prosesser må settes i gang. Noen operativsystemer har muligheten for å starte en slags ”light-prosesser” som vi kaller tråder. En tråd er en prosess, men normalt er den litt forenklet ved at en tråd ikke behøver å forholde seg til I/O enheter. En prosess kan starte mange tråder og nye prosesser, men en tråd kan ikke starte en prosess. Tråder trenger heller ikke en like stor og detaljert prosess control block.
  Det mest geniale er imidertid at dersom det er en tråd som må kjøres fra et program, og en slik tråd allerede finnes fra et annet program, så kan den eksisterende tråden av og til brukes. Det er altså ikke nødvendig å starte nye tråder.

  Hittil har alt det vi har sett på vært maskiner med bare en prosessor. Hvis vi ser på en maskin med to eller flere prosessorer blir billedet litt mer komplisert. Nå må operativsystemet ikke bare balansere prosesser og tråder efter prioritet, det må også dele arbeidet på de prosessorene (CPU) som finnes.
  Det er to metoder for å gjøre dette; symmetrisk og asymmetrisk. Den asymmetriske metoden går ut på at operativsystemet reserverer en prosessor for seg selv og sine egne behov og så deler den alt arbeid som har med applikasjoner å gjøre på de andre prosessorene. Symmetri betyr ”likhet” og i et tilfelle som dette ser vi at det ikke er likhet i arbeidsmengden de forskjellige prosessorene får. Dermed forstår vi også raskt at et symmetrisk operativsystem vil fordele alt arbeidet, også det som er operativsystemets egne prosesser og tråder likt mellom de tilgengelige prosessorene. Første ledige prosessor får neste oppgave, uansett hvilket program som eier den, og uansett hvilken CPU som hadde ledig kapasitet. Det er faktisk slik at selv om operativsystemet er det eneste som kjører på maskinen, vil arbeidet bli delt likt mellom prosessorene.

  Styring av minne og diskplass:

  
  
  

  Når et operativsystem styrer minne (RAM) er det to hovedoppgaver som må løses:
  
  
  

  • hver eneste prosess må ha nok minne til å kunne kjøre og prosessen kan ikke få lov til å kollidere (bruke samme minneadresse) som en annen prosess og ingen andre prosesser kan få lov til å kollidere med den gående prosessen.

  • De forskjellige typene minne må brukes på en effektiv måte, slik at prosessene kan kjøre så raskt og effektivt som mulig.

  Den første oppgaven krever at operativsystemet må sette minnegrenser for alle applikasjoner og annet software som kjører.

  
  
  

  
  
  

  La oss konstruere et eksempel. Vi tenker oss et system med 1 megabyte (1000 kilobyte) med RAM. Under bootprosessen blir operativsystemet pålagt å gå til den “øverste” delen av minnet og så ta den plassen det trenger i retning nedover. Vi tenker oss RAM som en slags trestruktur hvor den siste minneadressen er den “øverste”. La oss si at operativsystemet trenger 300 kilobyte for å kjøre.
  Nå begynner operativsystemet i “den andre enden” av RAM, altså ved den første minneadressen.
  Det første som det reserveres plass til er drivere som operativsystemet trenger for å kunne kommunisere med maskinvaren. I vår imaginære datamaskin bruker driverene 200 kilobyte med RAM.
  Dette betyr at så snart operativsystemet og nødvendige drivere er oppe og kjører, er det igjen 500 kilobyte som kan benyttes av applikasjoner og andre tjenester.

  Efterhvert som applikasjonene blir lastet inn i RAM, blir de tildelt en viss mengde minne som er delt opp i minneblokker. Hvis vi sier at minneblokkene er 2 kilobyte vil alle programmer bli tildelt minne på en slik måte at 2 k er det minste som kan tildeles og derefter blir det tildelt i blokker på 2 k. Det er altså ikke mulig (i dette imaginære systemet) å tildele en applikasjon 9 kB, det må bli 8 eller 10 kB.

  Applikasjonene vil alltid bli lastet til RAM i disse fastsatte blokkstørrelsene som blir satt opp ved hjelp av 4 eller 8 bytes computerord (instruksjonsord).
  Dette hjelper til å sikre at programmer ikke blir lastet på hverandre (kollisjon). Så snart dette er ordnet dukker det opp et annet spørsmål; hva skjer når de 500 kilobyte minne som var tilgjengelig for programmene er brukt opp?

  I de fleste computere er det mulig å legge til mer fysisk RAM efter at du har kjøpt datamaskinen. For eksempel kunne du utvide RAM fra 1 MB til 2 MB. Dette går helt fint, men det kan jo være et økonomisk spørsmål om hvorvidt du vil investere i mer minne.
  Denne løsningen tar heller ikke hensyn til en av de mest fundamentalefakta når det gjelder datamaskiner og RAM, nemlig det faktum at det aller meste av tilgjengelig fysisk RAM ikke er i bruk på et gitt tidspunkt. En prosessor kan kun lese eller skrive til en minneadresse av gangen. Dette betyr at størstedelen av RAM, på et gitt tidsunkt ikke er i bruk.
  Fordi harddiskkapasitet er mye billigere enn RAM så vil det å flytte data fra RAM til harddisk kunne utvide tilgjengelig RAM uten at det koster noe i kroner og øre.
  Denne metoden kalles styring av virtuelt minne.

  Diskplass og lagring på disk (virtuelt minne) er en av de typene minne som må styres av operativsystemet, og er den klart sakteste av minnetypene.
  Hvis vi skulle rangere minnetypene efter hastighet ville listen se slik ut:
  
  
  

  • Høyhastighetscache:

    Dette er en meget rask type minne som normalt finnes i ganske små mengder (i forhold til RAM og HD), men det gjøres tilgengelig for CPU via den raskeste kanalen i datamaskinen.Cachekontrollere forsøker å forutse (gjette) hvilke data CPU vil komme til å trenge i nær fremtid og henter dette fra hovedminnet til cacheminnet.
    Cacheminnet vil også huske de sist brukte filene og ha dem tilgjengelig raskere enn RAM kan gjøre dette, og betydelig raskere enn om det skulle hentes fra harddisk (HD).

  • Hovedminne:

    Dette er RAM, det minnet du ser at BIOS “teller opp” når du starter maskinen. I noen tilfelle står det også på skjermen under oppstart, hvor meget VRAM (VideoRAM) som er på skjermkortet.

  • Sekundærminnet:

    Vanligvis er dette en normal harddisk med roterende plater, men det kan også være magnetbånd, flashminne eller annet. Harddisk er suverent mest vanlig.

  Operativsystemets oppgave her, blir å balansere bruk av de forskjellige typene minne, efterhvert som applikasjoner og prosesser krever oppmerksomhet.
  Når operativsystemet gjør dette, gjøres det ved å flytte data i såkalte pages. Dette kalles også paging (utt. pæidsching). Dette er en moderne måte å flytte data, i tidligere tider (f.eks. I Win98) var det et litt annet system som ble kalt swapping. Forskjellen er ikke dramatisk, men det var slik at swapping betød at et helt program ble lagt i sekundærminnet, mens paging betyr at prosesser, tråder eller deler kan skrives til harddisk.

  Styring av maskinvareenheter:

  Kommunikasjonen mellom operativsystemet og stort sett alle maskinvarekomponenter som ikke er direkte plassert på hovedkortet skjer via små hjelpeprogrammer som kalles drivere. Det kan godt være elementer på hovedkortet som trenger drivere også, men det vanligste er at de er plug & play. Det betyr ikke at de ikke trenger drivere, men at driveren(e) er inkorporert i operativsystemet.
  Storparten av driverens oppgave er å være translatør (tolk) mellom de elektriske signalene som går i maskinvaregjenstandens subsystem, og høynivå programmeringssprogene som brukes i operativsystem og applikasjoner. Driveren tar i mot data som operativsystemet har definert som en fil og oversetter dette til en strøm av bits som plasseres på bestemte steder på lagringsenheter, eller for eksempel som en serie lyspulser i en laserskriver.
  Fordi det finnes så veldig mange typer maskinvaretyper, med meget store forskjeller i hvordan de virker, er det flere forskjellige typer drivere. Det finnes for eksempel både binære og tekstbaserte drivere. De fleste drivere er slik at de er i virksomhet bare når maskinvareenheten er virksom og de kjører som alle andre normale prosesser. Operativsystemet kan gi forskjellige drivere forskjellig viktighetsgrad (prioritet) slik at man ikke risikerer at viktigere prosesser må vente på mindre viktige prosesser.

  En annen, god grunn til å holde drivere adskilt fra operativsystemet er at det blir meget lettere å legge til nye funksjoner. Det er lett og greit å oppdatere en enkelt driver, men å oppdatere et operativsystem er en mye større operasjon og ikke alltid ønskelig. Det siste gjelder spesielt der noen har levet egne løsninger, egne programmer som er avhengig av bestemte versjoner av et spesielt operativsystem.En oppdatering av et operativsystem vil vanligvis bety ganske store omkostninger ved å skrive om kode, kompilere og distribuere på nytt, mens en enkelt driveroppdatering kan lastes ned fra Internet også over en vanlig telefonlinje.

  Operativsystemets oppgave med hensyn til styring av I/O (input / output) handler for det meste om å styre køer og buffere. Køer og buffere er spesielle lagringsområder som kan ta imot en strøm av bits, for eksempel fra et tastatur eller en seriell port (modem) og lagre dette i et mellomlager (en buffer) og så slippe det løs på prosessoren i en hastighet som prosessoren kan håndtere. Husk det kan jo hende at prosessorewn er opptatt med noe annet i øyeblikket.
  Det er nettopp når det er mange prosesser som kjøres samtidig at denne kø og buffer funksjonen blir spesielt viktig. Operativsystemet vil gi bufferene beskjed om å fortsette å ta imot datastrøm fra enhetene, men å slutte å sende videre til operativsystemet før denne driverprosessen igjen kan behandles av operativsystemet. Når OS er klar for å ta imot data fra f. eks. Tastaturet vil operativsystemet gi beskjed til bufferen om å fortsette å ta imot, men samtidig begynne å sende de eldste dataene først og så de nyere efterhvert som de er blitt plassert i køen. På denne måten kan operativsystemet behandle flere brukere og ta imot inndata fra flere kilder simultant. Det hele ser ut til å skje samtidig, men det er en illusjon, det bare bytter så fort at vi som brukere ikke har sjangs til å oppdage at det byttes mellom prosesser hele tiden.
  Det å organisere dette byttet mellom hvilke ressurser som til en hver tid skal ha oppmerksomhet er absolutt en av operativsystemets hovedoppgaver, og dersom vi snakker om et RTOS (real-time operating system) er det omtrent den eneste oppgaven OSet har.

  Grensesnitt (interface) mot verden:

  Applikasjonsgrensesnitt (application interface):

  Akkurat som drivere leverer et grensesnitt som programmer kan benytte, uten å måtte vite nøyaktig hva eller hvordan operasjonene egentlig utføres, har operativsystemet et tilsvarende grensesnitt (interface) som applikasjonsutviklere og programmerere kan benytte. Dette gir mulighet til å dra nytte av en rekke funksjoner i operativsystemet uten å måtte kjenne disse funksjonene i detalj, og uten å måtte tenke på at de kan endres over tid. Poenget er at om disse prosessene endres, må applikasjonsgrensesnittet forbli det samme.Da fortsette programmene å virke uten at de må skrives på nytt, bare fordi noen .dll filer er endret eller noe annet er oppdatert. Programmererene trenger ikke å holde seg oppdatert på alle små endringer i hvordan prosessoren utfører sitt arbeid.
  La oss se på et eksempel. Vi skal opprette en fil på harddisken, et sted hvor vi vil reservere plass til data som skal legges inn på et senere tidspunkt.

  La oss tenke oss at vi skal sette opp et vitenskapelig måleinstrument og vi vil la forskeren som skal bruke dataene selv gi filen et navn. Operativsystemet kan da f. eks. Inneholde et papplikasjonsgrensesnitt som kan tolke kommandoen MakeFile for å opprette filer.
  Når programmereren skriver koden kan hun inkludere en linje hvor det står:

  MakeFile [1, %Name, 2]

  I dette tilfellet vil denne instruksjonen gi operativsystemet beskjed om å opprette en fil som skal ha tilfeldig tilgang (random access) til data [1], hvor brukeren selv kan gi filen et
  navn [%Name] og hvor filens størrelse varierer med hvor mye data som er lagret der til enhver tid [2]. La oss se på hvordan operativsystemet gjør dette:

  1. Operativsystemet sender først en forespørsel til harddisken om hva som er første ledige adresse i filtabellen.

  2. Med denne informasjonen vil nå operativsystemet «skrive inn» den nye filen i filtildelingstabellen som angir hvor filen begynner og hvor den slutter, filnavn, filtype, informasjon om hvorvidt det er tatt backup av filen, hvilke brukere som har rettigheter til å lese eller skrive til filen og tidspunk med dato og klokkeslett for når filen ble opprettet.

  3. Operativsystemet skriver litt informasjon helt i begynnelsen på filen, informasjon som identifiserer filen, noen ganger tilgangsrettigheter og i noen tilfelle kan det være informasjon som et program trenger for å kunne benytte data fra filen, f. eks. Datatype og versjon.
     All denne informasjonen er spesiell for hver type harddisk og den kan variere i format fra harddiskprodusent til harddiskprodusent. Derfor er det viktig at det er et standardisert harddisk-drivergrensesnitt.

  Hvis nå programmereren har skrevet sitt program slik at det kan benytte dette standardiserte grensesnittet spiller det ingen rolle hvilken type harddisk som er i bruk og hvilket format denne produsenten har brukt. Driveren vil forstå de kommandoene programmet hennes benytter. Programmereren koder for et bestemt API (application programming interface) og trenger ikke tenke på mer, resten ordner operativsystemet.

  API og problematikk rundt standardisering av disse er blitt et svært hett tema i databehandlig og programmering de senere årene. Programvareselskaper forstår at programmerere som bruker deres API vil kunne profittere, rent økonomisk, og være med å kunne påvirke brukere og kanskje kunne, delvis, kontrollere deler av programvareindustrien. Dette er åprsaken til at mange programvareselskaper gir bort programmer som kan lese deres formater, såkalte viewers og readers. Et eksempel er Acrobat Reader fra Adobe. Dersom denne hadde kostet penger ville det vært mye vanskeligere å få andre selskaper til å levere produktdokumentasjon i PDF format, generert med Adobe Acrobat. PDF (Portable Dokument Format) er en åpen standard og alle kan skrive et program som kan generere og lese PDF, men Adobes programmer har bedre egenskaper enn mange andre og blir derfor et foretrukket redskap, noe man er villig til å betale for på utviklersiden, men neppe på brukersiden av problemstillingen.

  Brukergrensesnitt (user interface):

  Akkurat som et API gir et standardisert grensesnitt som en applikasjon kan bruke for å kommunisere med systemet, gir et UI (user interface) et strukturert miljø hvor bruker og programvare kan «møtes». I mer enn 10 år har stort sett all utvikling av UI vært gjort på de grafiske brukergrensesnittene (GUI). Her er det to som har fått mesteparten av oppmerksomheten, nemlig Apples Macintosh og Microsofts Windows, med Windows på klar førsteplass. I de senere årene har det blitt mer og mer oppmerksomhet rundt andre grafiske brukergrensesnitt som er utviklet for UNIX og GNU/Linux. Her har X-Windows, Gnome og KDE fått storparten av oppmerksomheten. Dette er GUI som har til formål å gjøre UNIX / GNU/Linux mer likt Windows og Macintosh for brukerene, sett fra brukerenes synspunkt.
  Tidligere var det stort sett bare ikke-grafiske UI for UNIX og GNU/Linux. Disse systemene har tradisjonelt bare brukt et skall (shell). Programmer som Korn Shell, C Shell, Bourne Shell og BASH (Bourne Again Shell) er tekstbaserte grensesnitt med en del funksjonalitet lagt til. Formålet er å gjøre det lettere å manipulere systemet, men dette regnes ofte som betydelig mindre brukervennlig enn et GUI. Til gjengjeld kan skall ha andre egenskaper som systemadministratorer setter pris på.
  Det er viktig å huske på at i alle disse eksemplene er et brukergrensesnitt et program eller en gruppe programmer som samarbeider og som ligger på et «mellomlag» mellom brukeren og operativsystemet. Dette gjelder også både Macintosh og Windows, selv om mekanismene og de tekniske løsningene kan være ganske forskjellige. Den helt grunnleggende funksjonaliteten i operativsystemet ligger i kjernen. Selve display manager funksjonen ligger, strengt tatt utenfor kjernen, men den kan være meget tett knyttet til kjernen allikevel. Det er nettopp måten et UI kommuniserer med kjernen som definerer forskjeller i operativsystemer, og som vil være avgjørende for hvilke systemer som vil vinne popularitet.

  Hva vil fremtiden bringe?

  Det er jo som kjent vanskelig å spå, særlig om fremtiden. En ting er det allikevel rimelig å anta, nemlig at det vil være vanskelig for bedrifter og brukere å forholde seg til de forskjellige filosofiene som ligger bak operativsystemene. På den ene siden har man de proprietære systemene som Windows og Macintosh, med deres vel ansette brukervennlighet og store utvalg av programmer som kan virke attraktivt til tross for at man da binder seg til en leverandør og kan få problemer dersom denne skulle bli borte, eller skru prisene så høyt at det blir urimelig å holde følge med dem. På den andre siden har man filosofien som ligger bak åpen kildekode (open source). Der de komersielle selskapene leverer sine programmer og drivere som kjørbare, binære filer som ikke med letthet kan studeres, endres og bygges videre på, vil åpen kildekodebevegelsen distribuere kildekoden slik at den kan endres, men på den betingelse at endringene også gjøres kjent og tilgjengelig for nye endringer. Synergien som oppstår når så mange programmerere på forskjellige nivåer genererer har vist å kunne frembringe programvare av meget høy kvalitet til meget lav omkostning. Dette kan tenkes å ville påvirke utviklingen i utviklingsland i større grad enn i de industrialiserte landene, men det har vist seg at systemer som GNU/Linux og FreeBSD også har fått en forbausende rask og stor utbredelse.
  Se bare på hvor mange som bruker Apache Webserver. :-)