Bærbarhet.

Ideelt sett bør OS-koden være lett portabel fra én type prosessor til en annen type prosessor og fra maskinvareplattformen (som ikke bare er forskjellig i type prosessor, men også i måten å organisere all maskinvare på) av én type til maskinvareplattformen av en annen type. Bærbare operativsystemer har flere implementeringsmuligheter for ulike plattformer, en slik OS-egenskap kalles også multi-plattform.

Det er flere "langlivede" populære operativsystemer (varianter av UNIX, MS-DOS, Windows NT, OS / 2), som et bredt spekter av applikasjoner er utviklet for. Noen av dem er veldig populære. Derfor, for en bruker som bytter fra ett OS til et annet av en eller annen grunn, er muligheten for å starte en kjent applikasjon i et nytt operativsystem veldig attraktiv. Hvis et OS har midler til å kjøre applikasjonsprogrammer skrevet for andre operativsystemer, sies det å være kompatibelt med disse OS. Det bør skilles mellom binær kompatibilitet og kildekompatibilitet. Kompatibilitet inkluderer også støtte for brukergrensesnitt til andre operativsystemer.

Det er en forskjell mellom binær kompatibilitet og programkildekompatibilitet. Binær kompatibilitet oppnås når du kan ta en kjørbar fil og kjøre den på et annet operativsystem. Kildekompatibilitet krever rekompilering av programmet først.

-3. 7. Kompatibilitet og flere applikasjonsmiljøer

Mens mange arkitektoniske funksjoner ved operativsystemer direkte angår bare systemprogrammerere, er konseptet flere applikasjonsmiljøer direkte relatert til behovene til sluttbrukere - operativsystemets evne til å kjøre applikasjoner skrevet for andre operativsystemer. Denne egenskapen til operativsystemet kalles kompatibilitet.

-3. 7. 1. Binær og kildekompatibilitet

Det må skilles mellom binær kompatibilitet og kildekompatibilitet. Applikasjoner lagres vanligvis i operativsystemet som kjørbare filer som inneholder binære bilder av kode og data. Binær kompatibilitet oppnås når du kan ta et kjørbart program og kjøre det på et annet OS-miljø.

Kildekompatibilitet krever en passende kompilator i programvaren til datamaskinen du har tenkt å kjøre programmet på, samt kompatibilitet med bibliotek og systemanrop. I dette tilfellet er det nødvendig å rekompilere de eksisterende kildetekstene til en ny kjørbar modul. Kildekompatibilitet er viktig først og fremst for applikasjonsutviklere som alltid har kildekode til rådighet. Men for sluttbrukere er bare binær kompatibilitet av praktisk betydning, siden de kun i dette tilfellet kan bruke det samme kommersielle produktet, levert i form av binær kjørbar kode, i forskjellige driftsmiljøer og på forskjellige maskiner. For en bruker som har kjøpt en pakke (for eksempel Lotus 1-2-3) for MS-DOS på en gang, er det viktig at han kan kjøre denne pakken han liker uten endringer og på den nye maskinen som kjører, for eksempel , Windows NT. Hvorvidt et nytt operativsystem er binært eller kildekompatibelt med eksisterende operativsystemer avhenger av mange faktorer. Den viktigste av disse er arkitekturen til prosessoren som det nye operativsystemet kjører på. Hvis prosessoren bruker samme instruksjonssett (eventuelt med noen tillegg) og samme adresseområde, kan binær kompatibilitet oppnås ganske enkelt.

For å gjøre dette er det tilstrekkelig å overholde følgende betingelser:

API-funksjonskall som applikasjonen inneholder må støttes av dette operativsystemet;

den interne strukturen til den kjørbare filen til applikasjonen må samsvare med strukturen til de kjørbare filene til det gitte operativsystemet.

Det er mye vanskeligere å oppnå binær kompatibilitet for operativsystemer designet for å kjøre på prosessorer med forskjellige arkitekturer. I tillegg til å oppfylle vilkårene ovenfor, er det nødvendig å arrangere emulering binær kode.

Anta for eksempel at du vil kjøre et DOS-program for en IBM PC-kompatibel datamaskin på en Macintosh-datamaskin. Macintosh er basert på Motorola 680x0 prosessor, og IBM PC er basert på Intel 80x86 prosessor. En Motorola-prosessor har en annen arkitektur (instruksjonssett, registerstruktur osv.) enn en Intel-prosessor, så den forstår ikke den binære koden til et DOS-program som inneholder instruksjoner for denne prosessoren. For at en Macintosh-datamaskin skal kunne tolke maskininstruksjoner som den i utgangspunktet ikke forstår, må spesiell programvare installeres på den - emulator.

Emulatoren må sekvensielt velge hver binær instruksjon fra Intel-prosessoren, dekryptere den programmatisk for å bestemme hva den skal gjøre, og deretter utføre den tilsvarende subrutinen som er skrevet i Motorola-prosessorinstruksjonene. Siden Motorola-prosessoren dessuten ikke har nøyaktig de samme registrene, flaggene og den interne aritmetiske logikkenheten som i Intel, må den også simulere (emulere) alle disse elementene ved hjelp av registrene eller minnet. Tilstanden til de emulerte registrene og flaggene etter utførelse av hver kommando bør være nøyaktig den samme som i en ekte Intel-prosessor. Dette er enkel, men veldig treg operasjon, ettersom en enkelt instruksjon fra en Intel-prosessor utføres betydelig raskere enn sekvensen av instruksjoner fra en Motorola-prosessor som emulerer den.

-3. 7. 2. Oversette biblioteker

Veien ut i slike tilfeller er å bruke den såkalte anvendte programvaremiljøer. En av komponentene som danner applikasjonsprogrammeringsmiljøet er et sett med API-funksjoner som operativsystemet gir til applikasjonene sine. For å redusere tiden brukt på å kjøre andres programmer, imiterer applikasjonsmiljøer kall til bibliotekfunksjoner.

Effektiviteten til denne tilnærmingen stammer fra det faktum at de fleste programmer i dag kjører på grafiske brukergrensesnitt (GUI) som Windows, Mac eller UNIX Motif, med applikasjoner som bruker mesteparten av tiden sin på å gjøre noe godt forutsigbar oppførsel. De ringer kontinuerlig til GUI-bibliotekene for vindusmanipulering og andre GUI-relaterte aktiviteter. I dag, i typiske programmer, brukes 60-80 % av tiden til å utføre GUI-funksjoner og andre OS-bibliotekanrop. Det er denne egenskapen til applikasjoner som gjør at applikasjonsmiljøer kan kompensere for den store tiden som brukes på å emulere et program én kommando om gangen. Et nøye utformet programvareapplikasjonsmiljø inneholder biblioteker som etterligner interne GUI-biblioteker, men er skrevet i "native" kode, og dette akselererer kjøringen av programmer med APIer til et annet operativsystem betydelig. Denne tilnærmingen blir noen ganger referert til som oversettelse for å skille den fra den langsommere prosessen med å emulere kode en instruksjon om gangen.

For eksempel, for et Windows-program som kjører på en Macintosh, kan det være veldig tregt å tolke kommandoer fra en Intel 80x86-prosessor. Men når en GUI-funksjon for åpent vindu kalles, kan en OS-modul som implementerer Windows-applikasjonsmiljøet avskjære denne samtalen og omdirigere den til rutinen for åpne vinduer som er rekompilert for Motorola 680x0-prosessoren. Som et resultat, i slike deler av koden, kan hastigheten til programmet nå (og muligens overgå) arbeidshastigheten på sin "native" prosessor.

For at et program skrevet for ett OS skal kjøres på et annet OS, er det ikke nok bare å sikre API-kompatibilitet. Konseptene bak ulike operativsystemer kan komme i konflikt med hverandre. For eksempel, i ett operativsystem kan en applikasjon få lov til å kontrollere I/O-enheter direkte, i et annet er disse handlingene privilegiet til operativsystemet. Hvert operativsystem har sine egne ressursbeskyttelsesmekanismer, sine egne feil- og unntakshåndteringsalgoritmer, en spesifikk prosessstruktur og minnestyringsplan, sin egen filtilgangssemantikk og grafisk brukergrensesnitt. For å sikre kompatibilitet er det nødvendig å organisere konfliktfri sameksistens innenfor ett OS av flere metoder for å administrere dataressurser.

-3. 7. 3. Metoder for implementering av anvendte programvaremiljøer

Oppretting av et fullverdig applikasjonsmiljø, fullt kompatibelt med miljøet til et annet operativsystem, er en ganske kompleks oppgave, nært knyttet til strukturen til operativsystemet. Det finnes ulike alternativer for å bygge flere applikasjonsmiljøer, som er forskjellige både i egenskapene til arkitektoniske løsninger og i funksjonalitet som gir varierende grad av applikasjonsportabilitet.

I mange versjoner av UNIX OS er applikasjonsmiljøoversetteren implementert som en vanlig applikasjon. I operativsystemer bygget ved hjelp av mikrokjernekonseptet, som Windows NT, kjører applikasjonsmiljøer som brukermodusservere. Og i OS / 2, med sin enklere arkitektur, er verktøyene for å organisere applikasjonsmiljøer innebygd dypt i operativsystemet.

Et av de mest åpenbare alternativene for å implementere flere applikasjonsmiljøer er basert på en standard OS-lagstruktur. I fig. 3. 8 operativsystemet OS1 støtter, i tillegg til sine "native" applikasjoner, applikasjoner til operativsystemet OS2. For dette inneholder den en spesiell applikasjon - et applikasjonsprogramvaremiljø som oversetter grensesnittet til det "utenlandske" operativsystemet - API OS2 til grensesnittet til dets "native" operativsystem - API OS1.

Ris. 3. 8. Et applikasjonsprogramvaremiljø som kringkaster
systemanrop

I en annen implementering av flere applikasjonsmiljøer har operativsystemet flere peer APIer. I eksemplet vist i fig. 3. For eksempel støtter operativsystemet applikasjoner skrevet for OS1, OS2 og OS3. For å gjøre dette er applikastil alle disse operativsystemene plassert direkte i kjerneområdet til systemet: API OS1, API OS2 og API OS3.

Ris. 3. 9. Implementering av kompatibilitet basert på flere
peer API

I denne varianten refererer funksjoner på API-nivå til OS-funksjoner på lavere nivå som må støtte alle tre generelt inkompatible applikasjonsmiljøer. Ulike operativsystemer administrerer systemtiden forskjellig, bruker et annet tidsformat, deler prosessortid basert på sine egne algoritmer osv. Funksjonene til hver API implementeres av kjernen under hensyntagen til spesifikasjonene til det tilsvarende OS, selv om de har et lignende formål.

En annen måte å bygge flere applikasjonsmiljøer på er basert på en mikrokjernetilnærming. Samtidig er det svært viktig å skille de grunnleggende operativsystemmekanismene som er felles for alle applikasjonsmiljøer fra høynivåfunksjoner som er spesifikke for hvert av applikasjonsmiljøene som løser strategiske problemer.

I henhold til mikrokjernearkitekturen implementeres alle OS-funksjoner av mikrokjernen og brukermodusservere. Det er viktig at hvert applikasjonsmiljø er utformet som en separat brukermodusserver og ikke inkluderer grunnleggende mekanismer (fig. 3. 10). Applikasjoner som bruker APIen, foretar systemanrop til det aktuelle applikasjonsmiljøet gjennom mikrokjernen. Applikasjonsmiljøet behandler forespørselen, utfører den (kanskje ved å bruke grunnleggende mikrokjernefunksjoner for hjelp), og sender resultatet tilbake til applikasjonen. I løpet av å utføre en forespørsel, må applikasjonsmiljøet på sin side få tilgang til de grunnleggende OS-mekanismene implementert av mikrokjernen og andre OS-servere.

Ris. 3. 10. Microkernel tilnærming til implementering av flere
anvendte miljøer

Denne tilnærmingen til konstruksjon av flere applikasjonsmiljøer har alle fordelene og ulempene til en mikrokjernearkitektur, spesielt:

· Det er veldig enkelt å legge til og ekskludere applikasjonsmiljøer, som er en konsekvens av den gode utvidbarheten til mikrokjerneoperativsystemer;

· Pålitelighet og stabilitet kommer til uttrykk i det faktum at hvis ett av applikasjonsmiljøene svikter, forblir alle de andre operative;

· Lav ytelse av mikrokjerne OS påvirker hastigheten til applikasjonsmiljøer, og dermed hastigheten på applikasjonskjøringen.

Opprettelsen av flere applikasjonsmiljøer innenfor ett operativsystem for å utføre applikasjoner fra forskjellige OS er en måte som lar deg ha en enkelt versjon av programmet og overføre det mellom operativsystemer. Flere applikasjonsmiljøer gir binær kompatibilitet for et gitt OS med applikasjoner skrevet for andre OS. Som et resultat har brukerne større valgfrihet av operativsystemer og enklere tilgang til kvalitetsprogramvare.

Hvis de arkitektoniske egenskapene til operativsystemer kun gjelder systemprogrammerere, er kompatibiliteten til operativsystemer direkte relatert til sluttbrukernes behov.

Skille mellom binær kompatibilitet (der applikasjoner er lagret i operativsystemet) og kildekompatibilitet.

Binær kompatibilitet oppnås når det er mulig å kjøre et kjørbart program for kjøring i miljøet til et annet operativsystem. For å gjøre dette må operativsystemene ha samme API.

Kildekompatibilitet krever en passende kompilator i programvaren til datamaskinen som programmet skal kjøre på. I dette tilfellet er det nødvendig å rekompilere den eksisterende kildeteksten til en ny kjørbar modul.

For sluttbrukeren er kun binær kompatibilitet av praktisk betydning. Hvorvidt et nytt operativsystem er binært kompatibelt avhenger først og fremst av arkitekturen til prosessoren som det nye operativsystemet kjører på. Det er vanskeligere å oppnå binær kompatibilitet (implementere samme API) på prosessorer med forskjellige arkitekturer.

En måte er å bruke spesielle programmer - emulatorer... Emulatoren må sekvensielt velge hver binær instruksjon beregnet på den emulerte prosessoren, dekryptere den programmatisk for å finne ut hva den gjør, og deretter utføre den tilsvarende subrutinen som er skrevet i prosessorens instruksjoner.

Dette simulerer registrene, flaggene og den interne aritmetiske logiske enheten til den emulerte prosessoren. Dette er enkelt, men veldig sakte arbeid, siden en prosessorinstruksjon utføres mye raskere enn sekvensen av instruksjoner som emulerer arbeidet til denne prosessoren på en annen prosessor.

Det er mer effektivt å bruke det kalt applikasjonsprogramvaremiljøer. I dag bruker typiske programmer 60 ... 80 % av tiden til å utføre GUI-funksjoner (grafisk brukergrensesnitt) og andre OS-bibliotekanrop.

Et nøye utformet programvareapplikasjonsmiljø inneholder biblioteker som etterligner interne GUI-biblioteker, men er skrevet i sin egen "native" kode.

Dermed oppnås en betydelig akselerasjon av kjøringen av programmer med API-en til et annet operativsystem. Denne tilnærmingen kalles kringkaste for å skille den fra den langsommere kodeemuleringsprosessen én kommando om gangen.

Avhengig av OS-arkitekturen kan oversettere av applikasjonsmiljøer implementeres i form av konvensjonelle applikasjoner eller som brukermodusservere (i mikrokjernearkitektur).

I andre implementeringer av flere applikasjonsmiljøer har OS-kjernen flere peer-appli(API), der funksjonene til hver API implementeres av kjernen, med hensyn til spesifikasjonene til det tilsvarende OS.

konklusjoner

1. Operativsystemet formidler mellom brukeren (en applikasjon lansert av brukeren) og maskinvaren, og gir brukeren et praktisk grensesnitt og effektivt distribuerer datasystemressurser mellom ulike applikasjoner. Utstyret kan ikke bare være lokale datafasiliteter, men også datanettverksfasiliteter. I sistnevnte tilfelle kalles operativsystemet et nettverksoperativsystem. Alle moderne operativsystemer er koblet til nettverk.

2. Alle oppgaver som løses av operativsystemet utføres av dets fire hoveddelsystemer: et undersystem for prosesskontroll, et undersystem for minneadministrasjon, et undersystem for fil- og ekstern enhetsadministrasjon, et undersystem for databeskyttelse og administrasjon.

3. Når man bygger moderne operativsystemer, brukes en flerlags tilnærming i deres arkitektur, som gjør det mulig å separere maskinavhengige OS-moduler i et eget lag, mens resten av operativsystemmodulene ikke vil avhenge av funksjonene til maskinvareplattformen. I tillegg tillater flerlagstilnærmingen uavhengig utvikling og modernisering av individuelle lag i operativsystemet.

4. Operativsystemer bygget på grunnlag av en mikrokjernearkitektur er mer pålitelige og utvidbare, men mindre effektive enn operativsystemer som ikke inneholder en mikrokjerne.

Selvtest spørsmål

1. Gi definisjonen av operativsystemet.

2. Hvilke funksjoner gir operativsystemet brukeren?

3. Hva er funksjonene operativsystemet gir applikasjonsprogrammereren?

4. Hvilke oppgaver løser operativsystemet i forhold til maskinvaren til datasystemet?

5. Hva er API?

6. Hva er essensen av multiprogrammering?

7. Hvilke oppgaver i operativsystemet er knyttet til arbeidet til delsystemet for prosesskontroll?

8. Hvilke oppgaver i operativsystemet er knyttet til driften av undersystemet for minneadministrasjon?

9. Hvilke oppgaver til operativsystemet er knyttet til driften av delsystemet for håndtering av filer og eksterne enheter?

10. Hvilke oppgaver i operativsystemet er knyttet til arbeidet med delsystemet databeskyttelse og administrasjon?

11. Gi en definisjon av begrepet en fil og en katalog?

12. Gi definisjonen av et nettverksoperativsystem

13. Hvilke operativsystemer kalles distribuert?

14. Hvilke funksjonelle komponenter er inkludert i nettverksoperativsystemet?

15. Hva kalles en nettverkstjeneste?

16. Hvordan kan nettverkstjenester implementeres i et peer-to-peer-nettverk?

17. Hvordan implementeres nettverkstjenester i et nettverk med en dedikert server?

18. Hva er essensen av flerlagstilnærmingen for å bygge et operativsystem?

19. Hvorfor trenger du en privilegert prosessormodus?

20. Hva er funksjonene til operativsystemkjernen?

21. Hvilke lag skiller man vanligvis ut når man bygger operativsystemkjernen? Hensikten deres?

22. Hva er funksjonene til driften av tilleggsmoduler til operativsystemet?

23. Hvilke oppgaver løses ved hjelp av operativsystemstøtteapparatet?

24. Hva er funksjonene til ressursforvaltere i et operativsystem med mikrokjernearkitektur?

25. Hva er fordelene og ulempene med mikrokjernearkitekturen til operativsystemet?

26. Hva er operativsystemkompatibiliteten?

27. Hva er essensen aven?

1. Typer kompatibilitet Spesifikke arkitektoniske og funksjonelle funksjoner til ethvert operativsystem bør kun gjelde systemprogrammerere og er kanskje ikke kjent for brukeren i det hele tatt. En OS-egenskap som kjennetegner muligheten til å kjøre applikasjoner skrevet for andre OSer i OS, kalles kompatibilitet.

Kompatibilitetstyper Applikasjoner lagres vanligvis på en datamaskin som kjørbare filer som inneholder binære bilder av kode og data. Binær kompatibilitet oppnås hvis du kan ta et kjørbart program som kjører i ett OS-miljø og kjøre det på et annet OS-miljø.

Kompatibilitetstyper Kompatibilitet på nivå med ref. tekster krever tilgjengelighet av passende kompilatorer som en del av PC-programvaren som denne applikasjonen skal brukes på, samt kompatibilitet på nivå med biblioteker og systemanrop. I dette tilfellet er det nødvendig å rekompilere kildekodene til programmene til nye kjørbare moduler.

Typer kompatibilitet For brukere er det bare binær kompatibilitet som betyr noe, siden de kun i dette tilfellet kan, uten spesielle ferdigheter og evner, bruke programvareproduktet som leveres i form av binær kjørbar kode i forskjellige driftsmiljøer og på forskjellige datamaskiner.

Typer kompatibilitet For å oppnå binær kompatibilitet er det nok å oppfylle følgende betingelser: kall til API-funksjoner som inneholder applikasjoner må støttes av dette operativsystemet; den interne strukturen til den kjørbare filen til applikasjonen må samsvare med strukturen til de kjørbare filene til det gitte operativsystemet. Den viktigste av disse er arkitekturen til prosessoren som operativsystemet kjører på.

Typer kompatibilitet Det er usammenlignbart vanskeligere å oppnå binær kompatibilitet for operativsystemer designet for å kjøre på prosessorer med forskjellige arkitekturer. I tillegg til å observere forholdene ovenfor, er det også nødvendig å organisere emuleringen av binærkoden.

Typer kompatibilitet Hensikten med emulatoren er å sekvensielt velge hver binær instruksjon til en prosessor, for eksempel Intel, dekryptere den programmatisk for å bestemme hvilke handlinger den spesifiserer, og deretter utføre en tilsvarende subrutine skrevet i prosessorinstruksjoner, for eksempel Motorola.

Typer kompatibilitet Det er imidlertid en annen, mye mer effektiv vei ut av den beskrevne situasjonen - bruken av såkalte programvaremiljøer. En av komponentene som danner programvaremiljøet er settet med API-funksjoner som OS gir for sine applikasjoner.

Typer kompatibilitet Effektiviteten til denne tilnærmingen bestemmes av det faktum at de fleste moderne programmer kjører under grafiske brukergrensesnitt (GUI) som Windows, UNIX, mens applikasjoner som regel bruker mesteparten av tiden på å utføre noen godt forutsigbare handlinger

Typer kompatibilitet De ringer kontinuerlig til GUI-bibliotekene for vindusmanipulering og andre GUI-relaterte handlinger. Det er denne funksjonen til applikasjoner som lar applikasjonsmiljøer kompensere for den store mengden tid som brukes på å emulere et program én kommando om gangen.

Typer kompatibilitet Et nøye utformet programvaremiljø inneholder biblioteker som etterligner de interne GUI-bibliotekene, men er skrevet i den "native" koden til operativsystemet. Dermed oppnås en betydelig akselerasjon av kjøringen av programmer med API-en til et annet operativsystem.

Typer kompatibilitet For at et program skrevet for ett OS skal kjøres på et annet OS, er det ikke nok bare å sikre API-kompatibilitet. Det kan godt hende at konseptene som ligger til grunn for ulike operativsystemer kolliderer med hverandre.

Typer kompatibilitet For eksempel, i ett OS, kan en applikasjon tillates å kontrollere I/O-enheter direkte, mens handlinger i et annet er privilegiet til operativsystemet. Naturligvis har hvert OS sine egne ressursbeskyttelsesmekanismer, sine egne feil- og unntakshåndteringsalgoritmer, en spesiell prosessstruktur og minnestyringsskjema, sin egen filtilgangssemantikk og grafisk brukergrensesnitt.

Typer kompatibilitet Alle disse forskjellene bestemmes av spesifikasjonene til maskinvareplattformen som operativsystemet kjører på, funksjonene til implementeringen, eller egenskapene som er fastsatt av utviklerne av systemet som iboende i dette systemet. For å sikre kompatibilitet er det nødvendig å organisere konfliktfri sameksistens innenfor ett operativsystem med flere måter å administrere datamaskinressurser på

Måter å implementere kompatibilitet Oppgaven til applikasjonsmiljøet er å kjøre programmet, så mye som mulig, som om det kjørte på et "native" OS. Men behovene til disse programmene kan komme i konflikt med utformingen av et gitt OS. Spesialiserte enhetsdrivere oppfyller ikke alltid sikkerhetskravene, og konflikter mellom minnebehandlingsopplegg og vindussystemer er mulig.

Måter å implementere interoperabilitet Applikasjonsmiljøet må også kjøre programmer med en akseptabel hastighet. Dette kravet kan ikke oppfylles av tidligere mye brukte emuleringssystemer. For å redusere tiden brukt på å kjøre andres programmer, bruker applikasjonsmiljøer programimitasjon på biblioteksnivå.

Måter å implementere kompatibilitet Til tross for at implementering i praksis av et fullverdig applikasjonsmiljø, fullt kompatibelt med miljøet til et annet OS, er en svært vanskelig oppgave, er det flere typiske tilnærminger til løsningen. Disse alternativene er forskjellige i arkitektoniske funksjoner og funksjonalitet som gir varierende grad av applikasjonsportabilitet.

I tillegg til sine "native" applikasjoner, støtter OS1 OS2 og NEO applikasjoner. For å gjøre dette er det applikasjonsprogrammeringsmiljøer som oversetter grensesnittene til den "utenlandske" API OC2 og NEO API til grensesnittet til deres "native" API OC1.

Måter å implementere kompatibilitet Det er en måte å bygge flere applikasjonsmiljøer ved å bruke konseptet med en mikrokjernetilnærming. Samtidig er det viktig å skille de grunnleggende OS-mekanismene som er felles for alle anvendte miljøer, fra høynivåfunksjoner som er spesifikke for hvert av de anvendte miljøene som løser strategiske problemer.

Metoder for implementering av kompatibilitet I samsvar med mikrokjernearkitekturen implementeres OS-funksjoner av mikrokjernen og brukermodusservere. Viktig: hvert applikasjonsmiljø er utformet som en separat brukermodusserver og inkluderer ikke grunnleggende mekanismer

Måter å implementere kompatibilitetsapplikasjoner som bruker API, foretar systemanrop til det aktuelle applikasjonsmiljøet gjennom mikrokjernen. Applikasjonsmiljøet behandler forespørselen, utfører den (kanskje bruker de grunnleggende funksjonene til mikrokjernen for dette) og sender resultatet til applikasjonen.

Måter å implementere kompatibilitet Under utførelsen av en forespørsel må applikasjonsmiljøet få tilgang til de grunnleggende OS-mekanismene implementert av mikrokjernen og andre OS-servere. Alle fordelene og ulempene med mikrokjernearkitekturen er iboende i denne tilnærmingen til konstruksjonen av flere applikasjoner, spesielt:

Måter å implementere interoperabilitet på er veldig enkle å legge til og ekskludere applikasjonsmiljøer, som er en konsekvens av den gode utvidbarheten til mikrokjerne OS; pålitelighet og stabilitet: hvis ett av applikasjonsmiljøene svikter, forblir alle de andre operative; lav ytelse av mikrokjerneoperativsystemer har en sterk effekt på hastigheten til applikasjonsmiljøer, og dermed på hastigheten på applikasjonsutførelsen.

Metoder for implementering av kompatibilitet Flere applikasjonsmiljøer gir binær kompatibilitet for et gitt OS med applikasjoner skrevet for andre OS. Som et resultat får brukerne mer frihet til å velge operativsystem og enklere tilgang til kvalitetsprogramvare.

Måter å implementere kompatibilitet Konklusjon API-kompatibilitet er ikke nok til at et program skrevet for ett OS skal kjøres på et annet OS. Et naturlig miljø er nødvendig: prosessstruktur, minneadministrasjon, feil- og unntakshåndtering, ressursbeskyttelsesmekanismer og filtilgangssemantikk.

Systemanrop er grensesnittet mellom operativsystemet og brukerprogrammet. De oppretter, sletter og bruker ulike objekter, hvorav de viktigste er prosesser og filer. Brukerprogrammet ber om en tjeneste fra operativsystemet ved å foreta et systemanrop. Det er biblioteker med prosedyrer som laster maskinregistre med visse parametere og avbryter prosessoren, hvoretter kontrollen overføres til behandleren av denne samtalen, som er en del av operativsystemkjernen.

Et systemanrop setter oppgaven i privilegert eller kjernemodus. Derfor kalles systemanrop noen ganger også programvareavbrudd, i motsetning til maskinvareavbrudd, som oftere bare refereres til som avbrudd. I de fleste operativsystemer foretas et systemanrop av et programavbrudd (INT).

Et maskinvareavbrudd er en hendelse generert av en enhet eksternt til prosessoren. Gjennom maskinvareavbrudd informerer maskinvaren enten prosessoren om at en hendelse har skjedd som krever en umiddelbar respons (for eksempel brukeren trykket på en tast), eller rapporterer fullføringen av en asynkron I/O-operasjon (for eksempel lesing av data fra disk til hovedminnet er ferdig).

En viktig type maskinvare interrupts - timeravbrudd generert periodisk med et fast tidsintervall. Tidtakeravbrudd brukes av OS ved planlegging av prosesser. Hver type maskinvareavbrudd har sitt eget nummer som unikt identifiserer kilden til avbruddet.

Unntak - en hendelse som oppstår som et resultat av et forsøk fra programmet på å utføre en kommando som av en eller annen grunn ikke kan fullføres. Eksempler på slike kommandoer inkluderer forsøk på å få tilgang til en ressurs uten tilstrekkelige privilegier eller tilgang til en manglende minneside.

Korrigerbare er slike eksepsjonelle situasjoner som fravær av nødvendig informasjon i RAM. Etter at årsaken til det korrigerbare unntaket er eliminert, kan programmet fortsette å kjøre. Korrigerbare eksepsjonelle situasjoner som oppstår i prosessen med å betjene operativsystemet regnes som normen.

Hovedoppgaven til filsystemet (FS) er å skjule funksjonene til I / O og gi programmereren en enkel abstrakt modell av filer, uavhengig av enheter. For å lese, opprette, slette, skrive, åpne og lukke filer, er det en omfattende kategori av systemanrop (opprett, slett, åpne, lukk, les, etc.).

Typer operativsystemer

Individuelle operativsystemer er utviklet for hver datamaskinmodell. Dessuten, for samme modell, er det som regel flere forskjellige operativsystemer med forskjellige avtale og annerledes muligheter og egenskaper. Så det er operativsystemer som kan kontrollere samtidig kjøring av flere programmer - multiprogram- eller bare en - enkeltprogram OS. Det er systemer som bare kan betjene én - enkeltbruker- eller flere personer samtidig - flerspiller OS. For å sikre driften av lokale og globale nettverk, utviklet Nettverk OS.

Flere forskjellige familier av operativsystemer er utviklet for IBM-kompatible personlige datamaskiner: MS DOS, Windows, OS/2, Unix og noen andre. Det enkleste operativsystemet vurderes enkelt bruker og enkeltprogram operativsystem MS DOS. Windows-, OS/2- og Unix-systemer er mer komplekse på grunn av deres multiprogrammeringsnatur og nettverksmulighetene de inkluderer. Den første versjonen av MS DOS-operativsystemet ble utviklet i 1981-1982. Som nevnt tidligere, i løpet av årene med MS DOS-eksistens, har et stort antall versjoner og modifikasjoner av dette systemet blitt utviklet. Den siste versjonen var MS DOS versjon 6.22. Det betydelig kraftigere og mer brukervennlige Windows-operativsystemet ble deretter utviklet, som i skrivende stund ble utgitt versjoner av Windows 95, Windows 98 og Windows ME. For de angitte versjonene av operativsystemer brukes ofte én felles betegnelse Windows 9.x... Windows heter og Nettverk operativsystemer Windows NT og Windows 2000, Windows XP. Merk at MS DOS viste seg å være så å si "absorbert", inkludert i Windows 9.x-operativsystemene.

Brukergrensesnitt

Samhandling mellom brukeren og operativsystemet utføres alltid i henhold til spesielle regler, på en måte som er karakteristisk for hvert operativsystem. Disse reglene dannes brukergrensesnitt, som er et spesielt tilfelle av det generelle grensesnittbegrepet diskutert ovenfor.

MERK FØLGENDE

Settet med standardavtaler, verktøy, metoder og regler for brukerinteraksjon med et bestemt programvaresystem kalles brukergrensesnittet (eller brukergrensesnittet) til systemet.

Det finnes følgende typer brukergrensesnitt for operativsystemer: tekst, tabell og grafikk grensesnitt. La oss analysere hovedfunksjonene til testbrukergrensesnittet som brukes i MS DOS-operativsystemet. Samspillet mellom brukeren og operativsystemet skjer i skjemaet dialog. Dette betyr at operativsystemet, etter lasting, gir et visst signal om dets beredskap til å motta instruksjoner, brukerkommandoer. I MS DOS-operativsystemet vises dette signalet på skjermen. en inndatamelding. Vanligvis er ledeteksten et > tegn, venstre hvorfra kan være noen tjenester, tilleggsinformasjon vises, for eksempel navnet på en diskenhet, gjeldende tid, gjeldende dato og noen andre data. Altså i invitasjonen

07-04-02 C: \>

viser gjeldende dato er 7. april 2002 og gjeldende diskenhet er C :. For å be om utførelse av en funksjon i operativsystemet, må brukeren gå inn fra tastaturet til høyre fra symbol> indikasjon, kommando operativsystem. Operativsystemkommandoen er skrevet i henhold til spesielle regler tekst, etter behandling som operativsystemet "forstår" nøyaktig hva brukeren krever av det, og utfører handlingen brukeren ber om.

MERK FØLGENDE

En operativsystemkommando er en tekst skrevet i henhold til spesielle regler, som er en instruksjon til operativsystemet om å utføre noen av dets funksjoner.

For eksempel kan du finne ut hvilken versjon av operativsystemet som er installert på datamaskinen ved å bruke følgende kommando:

07-04-02 C: \> ver

Som en påminnelse er kommandoen til høyre for invitasjonsskiltet>. I dette tilfellet er det ordet "ver" (fra versjon - versjon). Hvis operativsystemet MS DOS versjon 6.22 er installert på maskinen, vil utførelse av denne kommandoen vise svaret

MS DOS versjon 6.22

Utførelse av en kommando fra operativsystemet koker faktisk ned til kjøring av et program, som er en integrert del av operativsystemet, eller til et anrop fra systemdisken og den påfølgende kjøring av et tilleggsprogram. Slike tilleggsprogrammer som ikke er direkte en del av operativsystemet kalles vanligvis verktøy(nytte - nyttig, praktisk). Vanligvis utfører verktøy noen servicefunksjoner, for eksempel å sjekke kvaliteten på arbeidsflatene til magnetiske disker. Fraværet av noe verktøy på systemdisken som helhet svekker ikke driften til operativsystemet. Bare i dette tilfellet vil dens tilsvarende funksjon være utilgjengelig for utførelse. Men fraværet av noen komponent i operativsystemet tar hele systemet ut av arbeidstilstanden.

Hvis operativsystemet krever tilleggsinformasjon under utførelsen av kommandoen, vil det stille et spørsmål som brukeren må svare på. Dette spørsmålet og svaret er også utarbeidet i form av tekster med forhåndsavtalt form og innhold. Hvis det oppstår en ikke-standard situasjon mens du utfører kommandoen, vil operativsystemet generere og vise en informasjons- eller diagnostisk melding som beskriver den nåværende situasjonen. Hun vil også fortelle deg mulige måter for ytterligere handlinger av brukeren.

Etter vellykket eller mislykket fullføring av kommandoen, viser operativsystemet ledeteksten igjen og venter på neste brukerkommando. Dermed foregår dialogen mellom brukeren og operativsystemet i form av utveksling av tekstfraser. Det er derfor et grensesnitt av denne typen kalles et tekstgrensesnitt. Siden MS DOS-ledeteksten sammen med brukerkommandoen vanligvis opptar én linje på skjermen, ble denne linjen kalt kommandolinje, og tekstgrensesnittet har fått et annet navn - kommandolinjegrensesnitt. Merk at det populære Unix-nettverksoperativsystemet også bruker et kommandolinjegrensesnitt.

Praksisen med å jobbe med MS DOS-operativsystemet viste veldig raskt at tekstgrensesnittet for de fleste brukere er komplisert og upraktisk, siden brukeren må huske reglene for å skrive et tilstrekkelig stort antall kommandoer som er nødvendige for operasjonen. I tillegg må du angi fra tastaturet ganske lange sekvenser av tegn som utgjør kommandoen, og hvis du gjør en feil mens du skriver inn den (noe som skjedde ganske ofte), må du skrive inn kommandoene på nytt. Derfor begynte de å utvikle alle slags hjelpeprogrammer som skulle gi en mer brukervennlig måte å samhandle med operativsystemet på. Slike programmer kalles skjell.Å være i hovedsak overbygg over operativsystemet endrer skjell stilen og reglene for interaksjon mellom brukeren og operativsystemet, samtidig som de gir tilgang til kjernefunksjonene.

MERK FØLGENDE

Et skall er et hjelpeprogram som gir en mer brukervennlig måte å samhandle med operativsystemet på.

Vi understreker igjen at skjellene er ikke uavhengige programmer, de kan bare fungere sammen med operativsystemet de er laget for. Det er utviklet flere forskjellige skjell for MS DOS - Qdos, Dos Shell, Norton Commander, Volkov Commander, Windows 3.x, blant annet var de mest populære skallene Norton Commander (forkortet - NC), Volkov Commander (VC) og Windows 3. x. Ulike skjell bruker et annet brukergrensesnitt. Så Norton Commander og Volkov Commander skjell bruker tabell grensesnitt, hvis særegne er indikasjon eller valg kommando eller dens elementer i ferdig bord, i stedet for å skrive inn kommandotekst. Funksjonene til det tabellformede brukergrensesnittet diskuteres mer detaljert i det syvende kapittelet i denne opplæringen, som er viet til å utforske Norton Commander-skallet. Skjellene til Windows 3.x-familien, som inkluderer Windows 3.0, Windows 3.10, Windows 3.11, er forskjellige grafisk grensesnitt. En funksjon i dette grensesnittet er den brede bruken av betinget, lett å huske ikoner, tilordnet bestemte handlinger, programmer, enheter osv. Brukeren trenger bare å peke på ønsket ikon på en bestemt måte, og operativsystemet vil utføre handlingen knyttet til det. Det grafiske grensesnittet viste seg å være så vellykket at det ble det viktigste for operativsystemer Windows 9.x-familien, som erstattet MS DOS-operativsystemet og dets skall Windows 3.x.

MERK FØLGENDE

Windows 3.x er en familie av skall for MS DOS-operativsystemet, og Windows 9.x er en familie av frittstående operativsystemer. Det grafiske brukergrensesnittet diskuteres mer detaljert i kapittelet i opplæringen, som er viet til studiet av grensesnittet til Windows-operativsystemet.

Fil

En av de viktigste funksjonene til ethvert operativsystem er lagring og henting av informasjon på eksterne lagringsenheter. Vi minner om at eksterne lagringsenheter er en slags informasjonslagre, hvor programmer og data lagres i lang tid, til de trengs for å løse ethvert problem. Tenk deg nå at varer lagres på et eller annet lager uten noe system. Jo større lageret er, desto vanskeligere er det å finne riktig produkt. Eller ta for eksempel et skap som lagrer ulike dokumenter, bøker, rapporter, sertifikater osv. I fravær av en spesifikk lagringsorganisasjon kan det være svært vanskelig å finne de nødvendige dokumentene, spesielt hvis antallet er betydelig. tærende oppgave. Så, for lagring av informasjon, så vel som for lagring av varer, en viss system, lagringsorganisasjon, gir en rask og pålitelig måte å finne programmene og dataene du ønsker.

For å sikre pålitelig lagring og henting av informasjon på eksterne lagringsenheter programmer og data i operativsystemer er organisert i filer(å arkivere - registrere, lagre dokumenter i en bestemt rekkefølge).

MERK FØLGENDE

En fil er en navngitt samling av data som har en viss intern organisering, generell hensikt og okkuperer et bestemt område av et eksternt lagringsmedium.

Du kan tenke på en fil på en ekstern lagringsenhet som dokument i en koffert, i en skrivebordsskuff, i et arkivskap, og selve enheten er som en hel koffert, skuff, skap. Merk at dokumenter kan inneholde data eller planer (programmer) for å utføre handlinger.

Av definisjonen ovenfor følger det at filen har fornavn og tar en viss et sted på et eksternt lagringsmedium, for eksempel spesifikke sektorer og spor på en av diskenhetene. For å styrke den tidligere utviklede analogien, merker vi at dokumenter har navn, og i nærvær av et visst system tildeles et bestemt lagringssted til hvert dokument, som lar oss tegne en analogi mellom en fil og et separat dokument.

MERK FØLGENDE

Så en fil er enten et dokument eller et elektronisk program lagret på en av de eksterne enhetene - en magnetisk eller optisk disk, magnetbånd, etc.

Filen kan inneholde: et program i maskinkoder, en tekst til et program på et algoritmisk språk, en tekst til et dokument, en rapport, en lønnsliste, en artikkel, numeriske data, et opptak av en menneskelig tale eller en musikalsk melodi, en tegning, en illustrasjon, en tegning, et fotografi, en videofilm osv.

Fil handlinger

Følgende grunnleggende operasjoner kan utføres på filer: opprette, åpne, lukke, endre (redigere), kopiere, flytte, gi nytt navn og ødeleggelse.

§ Opprettelse filen utføres etter brukerens anvisning eller automatisk, ved hjelp av ulike programvaresystemer, som operativsystemer, skall, programmeringsverktøysystemer osv. Et navn tildeles den opprettede filen, plass tildeles den på diskmedier , og det er registrert i operativsystemet på en bestemt måte ... Den nyopprettede filen kan fylles med all informasjon. I noen situasjoner, tømme filer, det vil si filer som ikke inneholder noen data, men som er helt klare til å motta dem. Å lage en fil kan i overført betydning betraktes som å forberede et dokument og tildele et passende lagringssted for det. Og å lage en tom fil ligner på å velge et navn for et dokument og bestemme et sted å lagre det. I dette tilfellet blir dannelsen av innholdet i dokumentet utsatt i noen tid.

§ Åpning fil betyr å forberede filen til å fungere med et hvilket som helst programvaresystem. Spesielt forberedelsesprosessen inkluderer søk etter en fil på diskmedier og utarbeidelse av forskjellige hjelpetabeller, ved hjelp av hvilke informasjon enten legges inn i filen eller velges fra den. Som regel åpnes en fil automatisk av programvaresystemet som brukes til å jobbe med den. Å åpne en fil kan tenkes som å søke etter ønsket dokument i skapet og overføre det til skrivebordet for å lese eller gjøre endringer i dokumentet.

§ Lukking fil betyr å bryte forbindelsen mellom filen og programvaresystemet og lagre dens nåværende tilstand. Å lukke en fil, som å åpne den, utføres av programvaresystemet på spesielle instruksjoner fra brukeren, eller automatisk. Å lukke en fil ligner på å returnere et endret dokument til dets permanente plassering. Hvis du legger igjen et dokument på skrivebordet, kan det ved et uhell bli skadet eller ødelagt, og alle endringer som er gjort i det vil gå tapt.

§ Endring en fil anses å gjøre endringer i dataene som er dens innhold. Endringer som er gjort i filer som inneholder tekst kalles vanligvis redigering fil.

§ Kopiering fil betyr at en nøyaktig kopi av originalfilen opprettes på samme eller på en annen ekstern enhet eller lagringsmedium. Samtidig forblir originalen på sin gamle plass, og dermed viser det seg på eksterne enheter to helt identiske kopier av originalfilen. Å kopiere en fil kan tenkes å lage en kopi av et dokument og lagre det på et annet sted, for eksempel et annet skap. Dette kan for eksempel gjøres for å sikre at dokumentet oppbevares sikkert eller for et annet formål.

§ Flytte fil betyr at etter kopiering av filen til et annet sted, blir originalen ødelagt, som et resultat, bare en en kopi av den. Å flytte en fil kan tenkes å flytte et dokument fra ett lagringssted til et annet, for eksempel et annet skap.

§ Gi nytt navn fil betyr å tildele et nytt navn til filen, mens dens gamle navn er uopprettelig tapt.

§ Ødeleggelse(sletting) av en fil må utføres i tilfeller hvor foreldet informasjon lagret i filer roter opp et eksternt medium og muligheten til å skrive ny nyttig informasjon til dette mediet går tapt. I operativsystemer utføres sletting på en slik måte at det i mange tilfeller er mulig å gjenopprette en utilsiktet slettet fil. Du kan tenke deg at et dokument som er unødvendig i fremtiden kastes i papirkurven. Hvis et viktig dokument ved et uhell ble kastet bort, kan dette dokumentet bli funnet og fortsette å jobbe med det, etter å ha rotet grundig i kurven. Selvfølgelig, hvis innholdet i kurven ikke er fullstendig ødelagt.

Filattributter

Hver fil har en rekke karakteristiske egenskaper - attributter. De viktigste filattributtene er: navn, utvidelse, lengde, tidspunkt og dato for opprettelsen.

Filnavn.Navn, eller navnet på en fil, akkurat som navnet på en person, navnet på et dokument, en bok, tjener til å kunne skille en fil fra en annen, for å peke på ønsket fil. I forskjellige operativsystemer dannes filnavn i henhold til forskjellige regler. For eksempel, i MS DOS-operativsystemet er filnavnet en sekvens av bokstaver latin alfabet, tall og noen spesialtegn (~, _, -, $, &, @,%, ^,!, (.), (.), #, ","). Tittel kan inneholde fra en til åtte tegn og velges tilfeldig. Det er imidlertid lurt å velge navn på filene slik at brukeren enkelt kan huske nøyaktig hva som er lagret i denne filen. For eksempel kan en fil som inneholder en rapport for 4. kvartal kalles otchet4, en fil med en lønn - vedzarpl, og en fil med et bilde kan kalles bilde. Merk! I MS DOS-operativsystemet, filnavnet kan ikke inneholde mellomrom, bokstaver i det russiske alfabetet og punktum. I tillegg kan den ikke inneholde mer enn åtte tegn. Generelt sett er dette ganske betydelige begrensninger. For eksempel vil en fil som inneholder en virksomhets rapport for 4. kvartal, som vi kalte otchet4, fortrinnsvis hete «Rapport for 4. kvartal», i ekstreme tilfeller «Otchet za 4 kvartal», ved bruk av s.k. translitterasjon når ord på ett språk er skrevet med bokstaver på et annet. I operativsystemene Unix og Windows 9.x er restriksjoner på lengden på navnet, bruken av mellomrom og punktum i navnet fjernet. Og i Windows 9.x-operativsystemet kan i tillegg russiske bokstaver brukes i navnet. Dermed kan en fil i Unix ha navnet «Otchet za 4 kvartal», og i Windows 9.x er navnet «Rapport for 4. kvartal» tillatt.

Filutvidelse. I tillegg til navnet, hver fil kan ha eller ikke har utvidelse. Utvidelsen brukes til å karakterisere innholdet i en fil på en bestemt måte. For eksempel indikerer filtypene doc og txt at filen inneholder en slags dokument eller tekst, og utvidelsen bmp har en fil som inneholder et punktgrafikkbilde. Eventuell utvidelse er atskilt fra filnavnet med et punktum. På MS DOS kan en utvidelse inneholde fra ett til tre tegn, for eksempel otchet4.doc, vedzarpl.txt, picture.bmp, mens på Unix og Windows 9.x er mer enn tre tegn tillatt. Hvis det ikke er noen utvidelse, blir ikke punktum lagt inn i filnavnet. Navnet sammen med utvidelsen kalles fullt navn fil.

Hvis en fil opprettes ved hjelp av et hvilket som helst programvaresystem, mottar den som regel automatisk standardutvidelsen for dette systemet, og brukeren trenger bare å velge eller spesifisere bare navnet. Deretter gjenkjenner programvaresystemet "sine" filer med standardutvidelser. Operativsystemer gir en rekke standardutvidelser. Tabell 6.1 viser noen vanlige MS DOS- og Windows 9.x-utvidelser.

Tabell 6. 1. Noen MS DOS- og Windows 9.x-utvidelser

Filer med filtypen .com (vanlig) og . exe (execute) inneholder programmer på maskinspråk. Disse filene kalles ofte programfiler. Forskjell mellom .com- filer og . eks e-filer er knyttet til deres interne organisasjon. Disse forskjellene påvirker ikke måten vi håndterer filer på. Filer med filtypen .bat (batch) inneholder vilkårlige sekvenser av operativsystemkommandoer. Slike filer kalles vanligvis batch-filer. Brukt i tabell. 6.1 termin "Kjørbar fil" kombinerer begrepene "programfil" og "batchfil". Med andre ord betyr "kjørbar fil" at filen enten inneholder et maskinspråkprogram som kan kjøres direkte av datamaskinens prosessor (filer med .exe- og .com-utvidelsene), eller en sekvens av operativsystemkommandoer (en fil). med .bat-utvidelsen) som også kjøres, men bare ved å referere til de aktuelle programmene og verktøyene i operativsystemet.

Når du gjør endringer i filen, er det lurt å lagre den forrige versjonen av filen slik at du om nødvendig kansellere endringene og gå tilbake til den opprinnelige versjonen. Derfor mange programvaresystemer etter å ha gjort endringer i filen automatisk form reserve filen som inneholder den originale versjonen av filens innhold. Sikkerhetskopieringsfilen har samme navn som originalfilen, men alle filtypene erstattes av standard .bak-utvidelsen for sikkerhetskopifiler (tilbake-tilbake, tilbake). For eksempel, hvis det ble gjort endringer i otchet4.doc-filen, vil den nyeste versjonen av filen ha samme navn otchet4.doc, og en sikkerhetskopi av otchet4.bak-filen vil automatisk bli opprettet, som vil beholde den gamle versjonen av filinnholdet. Underveis legger vi merke til at hvis det gjøres endringer i et stort antall filer, samler det seg gradvis mange sikkerhetskopifiler på disken, så fra tid til annen må du "rydde opp" disken - ødelegge ikke lenger nødvendig eller utdaterte sikkerhetskopifiler.

I en rekke tilfeller leveres programvaredokumentasjon til kjøperen ikke på papir, men i form av tekstfiler på diskmedier. Vanligvis tildeles slike filer filtypen .doc (documet). I tillegg gir noen tekstredigerere automatisk "sine" filer (det vil si filer utarbeidet med deres hjelp) samme .doc-utvidelse. .txt-utvidelsen (tekst - tekst) er en annen vanlig variant av utvidelser knyttet til filer som inneholder ulike tekster. Og for filer med numeriske data er det praktisk å gi filtypen.dat (data - data).

Som nevnt tidligere har programmer ofte innebygde hjelpesystemer som kan nås mens programmet kjører. Et slikt system inneholder som regel all nødvendig hjelpeinformasjon i "help"-filer med filtypen .hip (help - help).

For å gi en annen viktig funksjon av operativsystemet - å utføre operasjoner på utveksling av data mellom programmet og forskjellige eksterne enheter - inneholder systemet en rekke programmer spesialisert for å administrere spesifikke eksterne enheter, som vanligvis kalles sjåfører(kjøre - å administrere). Drivere leveres enten med et sett med programmer og operativsystemfiler, eller med enheten de kontrollerer. Fraværet eller bruken av en driver som ikke samsvarer med enheten, gjør den ubrukelig. Derfor, når du kjøper en ekstern enhet, er det nødvendig å være oppmerksom på tilstedeværelsen av en driver - et program for å kontrollere denne enheten. De mest brukte driverne er tastatur, skjerm, skriver, mus osv. Filer som inneholder drivere har filtypene .exe eller .sys (system).

Noen ganger må programvaresystemer lagre mellomliggende, fungerende informasjon på diskenheter. Til dette formålet genereres spesielle filer, som ganske ofte får filtypen .tmp (midlertidig). Som regel blir midlertidige filer automatisk ødelagt etter at programmet avsluttes. Men det er situasjoner når slike filer fortsatt forblir på disken, og da kan de lett identifiseres av den spesifiserte utvidelsen og om nødvendig ødelegges.

Ulike grafiske redaktører tildeler også visse utvidelser til filer utarbeidet med deres hjelp. En slik utvidelse er utvidelsen .bmp (bitmap).

Fillengde. Den neste viktige egenskapen til filen er dens lengde. Fillengden er lik størrelsen på disken eller båndområdet som er okkupert av filen, og måles derfor i byte. Verdien av dette attributtet brukes til å bestemme muligheten for å plassere en fil på et ledig område av diskmedier og til andre formål.

Tidspunkt og dato da filen ble opprettet. Når filen først skrives til disk, samt når det gjøres endringer i filen ved hjelp av systemklokken (et spesialprogram inkludert i operativsystemet), registreres klokkeslett og dato for filskriving til diskenheten automatisk. Når datamaskinen er slått av, vedlikeholdes systemklokken av spesielle batterier eller andre strømkilder. Derfor holder systemklokken oversikt over tiden ganske nøyaktig. Dato- og klokkeslettattributter brukes til å identifisere de nyeste versjonene av en fil.

I tillegg til de vurderte grunnleggende filattributtene i MS DOS-operativsystemet, har filene ytterligere fire attributter - skrivebeskyttet, system, skjult og arkiv. Hver av disse attributtene har nøyaktig to tilstander - attributtet er aktivert eller attributtet er deaktivert.

Inkludert et attributt kun for lesing(noen ganger kalt et attributt adgangskontroll) betyr at filen ikke er tilgjengelig for å gjøre endringer i den. Det gjør det også vanskeligere å ødelegge en slik fil. Etter å ha slått av attributtet kun for lesing filen er tilgjengelig for alle operasjoner.

Egenskap systematisk vanligvis bare inkludert i kjerneoperativsystemfilene. Alle andre filer har attributtet systematisk, vanligvis av.

Egenskap skjult er inkludert for de filene som, når du viser listen over filer på diskenheten, ikke er inkludert i denne listen av operativsystemkommandoen. Resten av filene har en deaktivert attributtverdi skjult.

For å sikre påliteligheten til informasjonslagring på diskenheter, må du ha en eller to kopier av filer som inneholder viktig informasjon. For dette vil de organisere arkiv filer. Når du skriver en fil til et arkiv, skal attributtet arkiv skrur på. Dette betyr at en kopi av siste versjon av filen ligger i arkivet. Hvis du gjør noen endringer i en slik fil, vil attributtet arkiv slår av. Dette betyr at arkivet inneholder en utdatert versjon av filen (eller filen er ikke arkivert i det hele tatt). Spesielle arkiveringsprogrammer som sporer verdien av et attributt arkiv, kan oppdatere i arkivet bare de filene der endringer ble gjort. Dette lar deg optimere arbeidet til arkivere.

Hver av de vurderte attributtene er spesifisert med én bit. Disse bitene, sammen med litt tilleggsinformasjon, dannes byte med attributter.

Gruppenavnet på filene. Når du utfører operasjoner med filer, oppstår det noen ganger situasjoner der samme handling må utføres med en hel gruppe filer. Du må for eksempel omskrive (kopiere) flere filer fra C:-stasjonen til A:-stasjonen for senere å overføre disse filene til en annen maskin. Eller si, du vil ødelegge alle foreldede sikkerhetskopifiler for å frigjøre plass på diskenheten for opptak av nyttig informasjon. Selvfølgelig kan slike handlinger utføres sekvensielt, og spesifisere den samme ønskede handlingen for hver fil i gruppen. Denne tilnærmingen kan imidlertid være svært tidkrevende og vanskelig, spesielt hvis gruppen består av et stort antall filer.

MS DOS-operativsystemet gir en metode som forenkler kollektive handlinger med filer. Handlingen som skal utføres på en gruppe filer spesifiseres bare én gang, men handlingen er ikke ledsaget av det fulle navnet på en enkelt fil, men et spesielt navn som tillater operativsystemet fremheve, identifisere alle filene i gruppen og utfør deretter ønsket handling på dem. Dette navnet kalles gruppenavn, mønster eller maske.

Fellesskapsnavnet er dannet ved å bruke * og?-tegnene. *-tegnet som finnes i et gruppenavn tolkes av operativsystemet som "en hvilken som helst sekvens av tegn i navnet". Det vil si at dette symbolet tilsvarer et hvilket som helst antall symboler i navnet. Så alle navn som begynner med bokstaven "a" tilsvarer gruppenavnet a *: a1, azbuka, a2z4. Symbol? OS oppfattes som et enkelt tegn, det vil si at nøyaktig ett vilkårlig tegn i navnet tilsvarer det. For eksempel matcher malen otchet7.doc alle navn med .doc-utvidelsen, i navnet som nøyaktig ett tegn følger etter otchet-navnsegmentet, for eksempel otchet1.doc, otchet4.doc, otchet% .doc, otchet * . doc, osv. Tenk på noen flere eksempler:

§ ??. Txt - filer med navn på to bokstaver og filtypen .txt;

§ * .bak - filer med alle navn og filtype .bak;

§ progl. * - filer med navnet progl og eventuell filtype;

§ *.* - filer med alle navn og eventuelle utvidelser.

Katalog

For å lese innholdet i en fil, må du vite plasseringen på diskenheten. Hver fil opptar en bestemt gruppe sektorer på disken. Derfor kan plasseringen av filen spesifiseres ved å spesifisere sektor- og spornummer som er okkupert av filen. Imidlertid er denne metoden for å spesifisere plasseringen av filen veldig upraktisk, siden brukeren i dette tilfellet trenger å vite numrene til alle sektorene på disken som er tildelt filen. Som det ble funnet ut tidligere, for å øke effektiviteten av datautveksling, kombineres flere påfølgende sektorer til en klynge, og utvekslingen utføres samtidig av hele gruppen av sektorer. En slik utvekslingsorganisasjonsordning øker hastigheten på datautvekslingsoperasjoner med harddisker betydelig. I tillegg, for ikke å spesifisere tre separate tall (nummeret på arbeidsflaten, nummeret på sporet og nummeret på sektoren) som adressen til sektoren som klyngen starter fra, har en enkelt, solid nummerering blitt introdusert for alle diskklynger. For å bestemme klyngen som filen begynner i, er det nå tilstrekkelig å spesifisere bare ett tall - ordensnummeret til klyngen på disken.

Ethvert platemedie har flere servicebord, som inneholder all nødvendig informasjon om plasseringen av filene på dette diskmediet. Settet med alle tjenestetabeller disk filsystem... En av disse tabellene, som brukeren stort sett må forholde seg til, kalles en katalog (katalog).

MERK FØLGENDE

En katalog er en tabell i filsystemet til en disk som inneholder en liste over alle filer som er skrevet til den disken. For hver fil inneholder denne tabellen verdiene til alle dens attributter, samt nummeret på den første klyngen som er tildelt filen.

Med tanke på formålet kan en katalog sammenlignes med en innholdsfortegnelse i en bok, der et startsidenummer er angitt for hvert kapittel, eller med en liste over dokumenter som er lagret i et skap. Akkurat som i en bok, for å bestemme posisjonen til et bestemt kapittel, kan du bestemme hvilken side det starter på ved tittelen på kapittelet i bokens innhold, slik at operativsystemet, ved navnet på filen, finner klyngen der den starter i katalogen.

Tabell 6.2. Fragment av katalogen

Tabell 6.2 kan betraktes som et eksempel på et fragment av en katalog, med unntak av at informasjon i virkelige kataloger ikke er representert med symboler, men i form av tilsvarende maskinkoder. Attributtbyten i tabellen er i heksadesimal. Verdien av attributtbyte 00 16 gitt i den betyr at alle ikke-grunnleggende filattributter er slått av, og derfor er filene som finnes i katalogfragmentet vanlige filer.

Generelt sett skisserte det ovenfor et noe forenklet opplegg for filsystemoperasjonen når man søker etter og leser en fil fra en diskenhet. Faktisk er analogien mellom en katalog og en innholdsfortegnelse i en bok bare delvis på grunn av det faktum at klynger er allokert til en fil på disk ikke som en kontinuerlig matrise, men tilfeldig, mens i en bok er alle sidene i et kapittel plassert på rad. Tenk deg at et av kapitlene i en bok tar opp side 5,15,16, 17, 31, 123,124 i stedet for å oppta side 5,6,7,8,9,10,11 på rad. Slik diskontinuerlig tildelingen av klynger til filer er organisert for å optimalisere bruken av ledig diskplass under flere slettinger og skriving av filer.

For fortsatt å vite hvilke klynger og i hvilken rekkefølge som er tildelt for lagring av filen, gir filsystemet en annen tabell som er tilgjengelig på en hvilken som helst diskenhet. Denne tabellen kalles FETT(Filfordelingstabell - filallokeringstabell). Katalogen inneholder bare startklyngenummeret til filen. Og FAT-tabellen er tallene til alle de andre klyngene som er okkupert av filen. I det overveldende flertallet av tilfellene trenger ikke brukeren å jobbe med FAT-tabellen, siden den fylles ut når filen skrives og analyseres automatisk når den leses. En katalog og en eller to FAT-tabeller (FAT er vanligvis duplisert for pålitelighet) automatisk opprettes i prosessen med å formatere på alle diskmedier. Den automatisk opprettede katalogen kalles vanligvis rot. Rotkatalogen sammen med FAT-tabellene og startsektoren (null, start) på disken danner den systemområde.

Den enkle katalogstrukturen ovenfor, der alle filene danner én felles liste, kan gi tilfredsstillende drift av operativsystemet bare hvis små diskvolumer og begrenser det totale antallet filer som kan skrives til platen. For eksempel, på 1,44 MB disketter kan rotkatalogen inneholde informasjon om ikke mer enn 224 filer. Og når volumet på disken blir stort nok og derfor hundrevis og tusenvis av filer kan skrives på disken, fører en enkel katalogstruktur til en betydelig nedgang i prosessen med å søke etter en fil på disken eller katalogoverflyt. Se for deg en liste over tusenvis av titler som er lagret i et arkivskap. Det er helt åpenbart at det er veldig upraktisk å jobbe med en slik liste. I det virkelige liv, dokumenter i arkivskap gruppert For hvilken som helst grunn inn i mapper. Dessuten, i inventaret av innholdet i skapet, er ikke individuelle dokumenter angitt, men mapper. På samme måte har en katalog i operativsystemer en mer kompleks struktur. Vilkårlige grupper av katalogfiler kan kombineres til skjema underkataloger... På noen operativsystemer er underkataloger navngitt mapper... Faktisk er underkataloger, som rotkatalogen, tabeller på disken som inneholder informasjon om filene som er tilordnet en underkatalog. I motsetning til rotkatalogen, er plasseringen av underkataloger på disken ikke knyttet til systemområdet. Derfor kan størrelsene på underkataloger være ganske vilkårlige, noe som gjør det mulig å fjerne begrensningen på antall filer spesifisert i en underkatalog.

Underkataloger opprettes av brukere etter eget skjønn. Hver underkatalog har sitt eget navn (vanligvis uten utvidelse), som velges etter samme regler som filnavnet. Filer kan grupperes og inkluderes i en underkatalog i henhold til alle kriterier. For eksempel, i en egen underkatalog kalt WINDOWS, er det tilrådelig å samle alle filene relatert til operativsystemet. På samme måte er det tilrådelig å gruppere i en egen underkatalog alle filene som er nødvendige for driften av et hvilket som helst tekstredigeringsprogram eller spillprogram. Hvis flere brukere jobber etter tur på maskinen, er det fornuftig å organisere separate underkataloger for hver bruker, for eksempel bruker1, bruker2, bruker3, ... (bruker - bruker), og grupperer filene til den første brukeren i underkatalogen brukerl. , den andre i underkatalogen bruker2, og etc. I tillegg til å fjerne de kvantitative restriksjonene knyttet til bruken av én katalog, skaper dette en viss rekkefølge i lagringen av informasjon på disker.

Alle underkataloger i rotkatalogen er tilordnet det første nivået. I figur 6.2 er underkatalogene på første nivå Windows-underkataloger, brukerl, Programfiler. Rotkatalogen i forhold til underkatalogene på første nivå som er inkludert i den, kalles forelder, og underkataloger i forhold til roten vurderes datterselskap eller nestet og. Hver underkatalog på første nivå har på sin side samme struktur som roten. Det vil si at i filene som er tildelt en underkatalog, kan du velge hvilke som helst undergrupper og danne nye underkataloger fra dem. Derfor, i tillegg til vanlige filer, kan enhver underkatalog inneholde filer gruppert i underkataloger. Disse underkatalogene er på neste nivå. For eksempel kan eieren av underkatalogen userl gruppere alle rapporter utarbeidet av ham i en egen underkatalog kalt otcheti i denne underkatalogen, og for eksempel filer som inneholder informasjon om forretningskontakter kan samles i underkatalogen kontakti (fig. 6.2). Underkatalogene på første nivå anses som overordnede i forhold til underkatalogene på andre nivå som er inkludert i dem. Underkataloger på andre nivå fungerer som underordnede underkataloger på første nivå. Det følger at overordnede og underordnede underkataloger er relative. Underkatalogene på første nivå, på den ene siden, anses som underordnede av rotkatalogen, og på den andre siden som overordnede til underkatalogene på andre nivå. Underkataloger til det andre nivået kan ha underkataloger til det tredje nivået dannet inne i dem, og de på det fjerde nivået, osv. Dybden av nesting av underkataloger er ikke begrenset. En slik katalogstruktur kan tenkes som en innholdsfortegnelse i en bok, der en viss strukturering er introdusert - deler er uthevet, kapitler er uthevet i deler, kapitler er delt inn i avsnitt, avsnitt - i seksjoner osv. Hver av disse strukturelle enhetene kan betraktes som en underkatalog.

Ser man på fig. 6.2, vil du legge merke til at katalogen er strukturert som et tre. Rotkatalogen kan tilordnes til stammen til et tre, underkataloger fungerer som grener, og filer er bladene til treet. Denne katalogstrukturen kalles trelignende eller hierarkisk. Faktisk kommer navnene "rot" og "trelignende" fra denne analogien. Og navnet "hierarkisk" kommer fra begrepet "hierarki". Hierarki er ordningen av deler eller elementer av en helhet i rekkefølge fra høyeste til laveste. Hierarkiske strukturer er svært utbredt.

For eksempel er statens væpnede styrker hovedsakelig basert på vertikale kontrollbånd, det vil si i henhold til det hierarkiske prinsippet: hær - divisjon - regiment - kompani - peloton - tjenestemenn. Vi kan si at hæren ligner på rotkatalogen, militært personell ligner filer, og mellomenheter: divisjon, regiment, selskap, peloton er underkataloger på forskjellige nivåer. Høyere utdanningsinstitusjoner (universitet - fakultet - institutt - lærere) og mange andre organisasjoner har samme struktur.

Ris. 6.2. Katalogtrestruktur

MERK

Merk at det faktisk bare er én katalog på en hvilken som helst diskenhet - roten, resten er underkataloger på et eller annet nestenivå. Imidlertid kalles underkataloger ofte også kataloger, noen ganger refererer til de eksisterende underordningsforholdene for dem. Merk at brukeren selv oppretter eller ikke oppretter underkataloger, og deres tilstedeværelse, i prinsippet, er ikke nødvendig, mens root. Directory er nødvendig, og den opprettes automatisk. Merk også at når du oppretter en underkatalog, velger brukeren tilfeldig et navn på den, mens rotkatalogen i denne forstand ikke har noe navn i det hele tatt.

Banen til filen

Operativsystemet søker etter en fil i katalogen ved fullt navn. Dette betyr at i I prinsippet kan ikke samme katalog eller underkatalog inneholde to forskjellige filer med samme fulle navn. Som en påminnelse består det fulle navnet av filnavnet og filtypen. Det er heller ikke tillatt å ha to nestede underkataloger med samme navn i samme katalog eller underkatalog. For å forstå hvorfor dette er umulig, bør du vurdere følgende situasjon. Tenk deg at i en bestemt by er posttjenesten organisert som følger: etternavn, fornavn og patronymer, det vil si fulle navn, samt adressene til alle innbyggere i byen er i listene som er lagret i posten (analog av en katalog på en disk). Avsendere av korrespondanse til denne byen kjenner bare mottakernes fulle navn, og adressene deres er ukjente, og derfor er bare etternavnet, fornavnet og patronymet til mottakeren angitt på postsendinger til denne byen. I posten, i henhold til det fulle navnet spesifisert i posten, bestemmes mottakerens adresse i den tilsvarende listen, og denne varen leveres via den (analogt med søk etter en fil på disken av operativsystemet med navnet) . La oss nå anta at to forskjellige personer med samme fulle navn bor i denne byen på forskjellige adresser. Da vil den vurderte ordningen med posten føre til at adressater med samme etternavn, navn og patronymer vil motta utsendelser blandet – både egne og andres. Tilsvarende, hvis de fulle navnene på to filer sammenfaller, vil ikke operativsystemet være i stand til entydig å bestemme hvilken fil det skal skrives data til eller fra hvilken fil som skal leses, og vil velge dem tilfeldig.

Imidlertid, i diverse kataloger eller underkataloger kan ha filer eller underkataloger med de samme fullstendige navnene. Men for en entydig indikasjon på den nødvendige filen, er det nå ikke nok med ett fullt filnavn. For å skille filer med samme navn fra hverandre, må du også spesifisere underkatalogene de er plassert i. I det generelle tilfellet må du spesifisere ikke én underkatalog, men hele kjeden av underkataloger, gjennom hvilken du må gå fra rotkatalogen til underkatalogen som inneholder den ønskede filen for å komme til ønsket fil og bestemme plasseringen.

Kjeden av navn på underkataloger som skal gå gjennom, starter fra rotkatalogen og slutter med underkatalogen som inneholder filen, kalles omvei eller rute til filen.

MERK

I MS DOS- og Windows-operativsystemer er rotkatalogen i banen angitt med tegnet \. Det samme symbolet skiller navnene på underkataloger i kjeden, samt filnavnet fra navnet på underkatalogen den ligger i.

For filer som ligger i rotkatalogen (fig. 6.2), er banen kun betegnelsen på rotkatalogen \, og filene er indikert som følger:

\ command.com, \ config.sys, \ autoexec.bat

Filen fra underkatalogen userl har banen \ bruker1:

\ bruker1 \ bilde.bmp

Og banen til filer fra kontakti-underkatalogen må inneholde navnene på begge underkatalogene - \ user1 \ kontakti:

\ bruker1 \ kontakti \ ivanov.doc, \ bruker1 \ kontakti \ postavki.txt

Baner kan spesifiseres ikke bare til filer, men også til underkataloger. Så for kontakti-underkatalogen er banen \ bruker1.

Filspesifikasjon

En datamaskin inkluderer som regel flere forskjellige diskenheter, derfor, for å identifisere en fil unikt, må du angi hvilken enhet den er plassert på. Dette kan gjøres ved å spesifisere navnet på diskenheten som inneholder filen. Det er vanlig å plassere navnet på enheten før banen til filen. En filreferanse som inneholder: 1) enhetsnavn, 2) filbane, 3) fullt filnavn, kaltfull filspesifikasjon... Merk at i det generelle tilfellet er en spesifikasjon en oppregning av alle særtrekk. Hvis for eksempel en katalog hvis struktur er vist i fig. 6.2, er plassert på harddisken C :, så ser den fullstendige spesifikasjonen av postavki.txt-filen slik ut:

C: \ bruker1 \ kontakti \ postavki.txt

og hvis denne katalogen er på en diskett, det vil si på en diskenhet A :, vil spesifikasjonen skrives som følger:

A: \ bruker1 \ kontakti \ postavki.txt

Den komplette filspesifikasjonen definerer fullstendig og entydig den nødvendige filen, som faktisk kreves av operativsystemet for å nøyaktig utføre brukerkommandoer. Hvis imidlertid den minste feil er gjort i filspesifikasjonsposten, for eksempel at minst ett tegn mangler eller er forvansket, vil ikke operativsystemet kunne finne en slik fil.

Kontrollspørsmål

1. Hva kalles et operativsystem?

2. List opp hovedfunksjonene til operativsystemer.

3. Hvilken disk kalles systemdisken? Hvilke stasjoner kan være systemstasjoner?

4. Beskriv fremgangsmåten for å slå på og av den personlige datamaskinen.

5. Hva er bootstrap av operativsystemet? Hvordan virker det?

6. Angi mulig årsak til avslutningen av nedlastingen.

7. Hva er frysing? Hva bør du gjøre når du fryser?

8. Beskriv de mulige metodene for å utføre en omstart.

9. Hvilke operativsystemer finnes det?

10. Hva kalles et brukergrensesnitt?

11. Beskriv hovedtrekkene til tekst-, tabell- og grafiske grensesnitt.

12. Hvilken rolle spiller spørsmålet om innspill?

13. Hva er en operativsystemkommando?

14. Hva er et verktøy?

15. Hva kalles et skall? Hvilke skjell kjenner du?

16. Hva er en fil?

17. Hva kan være i filen?

18. Hvilke operasjoner kan utføres på filer?

19. Hva er et filattributt? Hva er hovedegenskapene?

20. Hvordan er filnavnet satt?

21. Hvilken rolle spiller utvidelsen og hvordan er den satt?

22. Gi en definisjon av begrepene "programfil", "batchfil", "kjørbar fil", "sikkerhetskopifil", "hjelpefil", "driver". Angi utvidelsene deres.

23. Hva er behovet og hvordan dannes gruppenavnet?

24. Hva er en klynge?

25. Hva er en katalog og hvilken informasjon inneholder den?

26. Hvordan søkes det etter en fil på en diskstasjon?

27. Hva er strukturen til katalogen?

28. Gi en definisjon av begrepene "rotkatalog", "underkatalog", "underkatalog på første nivå", "underkatalog på andre nivå", "overordnet katalog", "underkatalog for underordnet".

29. Hva er banen til filen og hvorfor bør den spesifiseres?

30. Hva er en filspesifikasjon?

4.1 Typer kompatibilitet

Spesifikke arkitektoniske og funksjonelle funksjoner til et hvilket som helst operativsystem bør direkte berøre bare systemprogrammerere og er kanskje ikke kjent for den gjennomsnittlige brukeren i det hele tatt. Mens noen ideer (for eksempel en objektorientert tilnærming) er utviklernes ansvar og bare indirekte påvirker sluttbrukeren, konseptet med flere applikasjonsmiljøer gir brukeren den etterlengtede muligheten til å kjøre programmer skrevet for andre OS og prosessorer på OS. En OS-egenskap som kjennetegner muligheten til å kjøre applikasjoner skrevet for andre OSer i OS kalles kompatibilitet.

Det er to fundamentalt forskjellige typer kompatibilitet som ikke bør forveksles: binær kompatibilitet og kildekompatibilitet. Applikasjoner lagres vanligvis på en datamaskin som kjørbare filer som inneholder binære bilder av kode og data. Binær kompatibilitet oppnås hvis du kan ta et kjørbart program som kjører i ett OS-miljø og kjøre det på et annet OS-miljø.

Kildekompatibilitet krever passende kompilatorer i programvaren til datamaskinen som programmet er ment å brukes på, samt kompatibilitet med bibliotek og systemanrop. I dette tilfellet er det nødvendig å rekompilere kildekodene til programmene til nye kjørbare moduler.

Derfor er kildekompatibilitet viktigst for applikasjonsutvikleren som eier kildekoden. For sluttbrukere er bare binær kompatibilitet av praktisk betydning, siden de kun i dette tilfellet kan, uten spesielle ferdigheter og evner, bruke programvareproduktet som leveres i form av binær kjørbar kode i forskjellige driftsmiljøer og på forskjellige datamaskiner. For en bruker som har kjøpt en programvarepakke for MS-DOS på en gang, er det viktig at han kan kjøre denne kjente pakken uten endringer eller begrensninger på sin nye maskin, som kjører for eksempel under Windows NT. Flere applikasjonsmiljøer sikrer bare kompatibiliteten til dette operativsystemet med applikasjoner skrevet for andre operativsystemer og prosessorer, på binært nivå, og ikke på kildekodenivå.

Hvorvidt et OS har binær- eller kildekompatibilitet avhenger av mange faktorer. Den viktigste av disse er arkitekturen til prosessoren som operativsystemet kjører på. For å oppnå binær kompatibilitet er det nok å oppfylle flere av følgende betingelser:

kall til API-funksjoner som applikasjonen inneholder må støttes av det gitte operativsystemet;

den interne strukturen til den kjørbare filen til applikasjonen må samsvare med strukturen til de kjørbare filene til det gitte operativsystemet.

Det er uforlignelig vanskeligere å oppnå binær kompatibilitet for operativsystemer designet for å kjøre på prosessorer med forskjellige arkitekturer. I tillegg til å observere forholdene ovenfor, er det også nødvendig å organisere emuleringen av binærkoden. For at en datamaskin skal kunne tolke maskininstruksjoner som i utgangspunktet er uforståelige for den, må spesiell programvare installeres på den - emulator.

Hensikten med emulatoren er å sekvensielt hente hver binær instruksjon til en prosessor, for eksempel Intel, dekryptere den programmatisk for å finne ut hva den gjør, og deretter utføre en tilsvarende subrutine skrevet i prosessorinstruksjoner, for eksempel Motorola.

Likevel er det en litt annen, mye mer effektiv vei ut av den beskrevne situasjonen – bruken av såkalte applikasjonsprogramvaremiljøer. En av komponentene som danner programvaremiljøet er settet med API-funksjoner som OS gir for sine applikasjoner. For å redusere utførelsestiden for utenlandske programmer, imiterer applikasjonsmiljøer kall til bibliotekfunksjoner. Effektiviteten til denne tilnærmingen bestemmes av det faktum at de fleste moderne programmer kjører under grafiske brukergrensesnitt (GUI) som Windows, UNIX, mens applikasjoner som regel bruker mesteparten av tiden på å utføre noen godt forutsigbare handlinger. De foreta kontinuerlig anrop til GUI-bibliotekene for vindusmanipulering og andre GUI-relaterte handlinger. Det er denne funksjonen til applikasjoner som lar applikasjonsmiljøer kompensere for den store mengden tid som brukes på å emulere et program én kommando om gangen. Et nøye designet programvaremiljø inneholder biblioteker som etterligner de interne GUI-bibliotekene, men er skrevet i den "native" koden til operativsystemet. Dermed oppnås en betydelig akselerasjon av kjøringen av programmer med API-en til et annet operativsystem. For å skille denne tilnærmingen fra den langsommere prosessen med å emulere kode én instruksjon om gangen, kalles den kringkaste.

Det skal imidlertid bemerkes at for at et program skrevet for ett OS skal kjøres under et annet OS, er det ikke nok bare å sikre API-kompatibilitet. Det kan godt hende at konseptene som ligger til grunn for ulike operativsystemer kolliderer med hverandre. For eksempel, i ett OS, kan en applikasjon få lov til å kontrollere I/O-enheter direkte, mens i et annet er handlinger privilegiet til operativsystemet. Det er ganske naturlig at hvert operativsystem har sine egne mekanismer for å beskytte ressurser, sine egne; algoritmer for håndtering av feil og unntak, en spesiell prosessstruktur og minnestyringsskjema, egen filtilgangssemantikk og grafisk brukergrensesnitt. Alle disse forskjellene bestemmes av spesifikasjonene til maskinvareplattformen som operativsystemet kjører på, av særegenhetene ved implementeringen, eller fastsatt av systemutviklerne som egenskaper som er iboende i dette systemet. For å sikre kompatibilitet er det nødvendig å organisere konfliktfri sameksistens innenfor ett OS av flere metoder for å administrere dataressurser.