Hvorfor er nye computere ikke bagudkompatible?

Klaus Ulrik Mortensen spørger:

»Hvorfor er nye computere ikke bagudkompatible? Jeg har et spil fra 1997 - Championship Manager 97/98 - som jeg forleden fandt frem og ønskede at spille.

Min pc med Vista kunne af uransalige årsager ikke køre det. Løsningen var noget med boot-usb-nøgler. Meget besværligt og bøvlet.

Screenshot af Sid Meyers Civilization fra 1991.

Det samme gælder med andre gamle spil, Doom, Wolfenstein etc, som jo er bygget til meget små processorer og stiller latterlige små krav sammenlignet med dagens computerkraft. Alligevel virker de ikke uden problemer.«

Selvstændig programmør og blogger på ing.dk, Poul-Henning Kamp, svarer:

»Det er ikke, fordi det er umuligt, faktisk er det mere muligt, end det nogen siden har været før, fordi vi nu har processorkraft nok til at simulere hele computere i et program. F.eks. kører jeg ved festlige lejligheder 'RailRoad Tycoon' ved hjælp af et program, der kan simulere en PC-AT med MSDOS-5.1.

Det fine ved den måde at lave bagudkompabilitet på, er at det behøver slet ikke være samme slags computer: Gamle arkade spil kan kører på alt muligt fra PC'er til smartphones ved hjælp af 'MAME' og vi kan køre 50 år gamle GIER programmer på en laptop.

Hvis jeg var dig, ville jeg kigge mig om efter et eller andet PC-emulator program, der kan simulere en computer, der kan afvikle det operativsystem og spil, du har lagt på din USB nøgle.

Det er straks mere problematisk at lave bagudkompabilitet, når man taler om at gøre det direkte i et operativsystem, det rejser problemer på mange forskellige niveauer.

Selv små bitte forskelle i definitionen af et system-kald kan betyde utroligt meget kode-arbejde og derfor er det dyrt, ikke mindst når man skal teste, at det hele virker som det skal. (Specielt bliver det krydret, når man vil køre 32bit programmer under et 64bit OS, og det modsatte er stort set umuligt.)

Hvis man skal kunne køre alle gamle programmer, er det også umuligt at lukke de sikkerhedshuller, der var i de gamle operativsystemer.

Et af sikkerhedshullerne er f.eks direkte adgang til grafikkortet, noget stort set alle spil havde brug for tidligere, af hensyn til hastigheden.

Idag opfatter man direkte adgang til grafikkortet som et sikkerhedshul, fordi kriminelle, der har fået malware ind på en computer kan bruge det til at tegne f.eks. et NEM-ID login vindue.

Nogle gange er selve arkitekturen forandret så meget, at det ikke giver mening at være bagudkompatibel. Overvej f.eks. hvorledes Nortons 'TSR' regnemaskine til MSDOS skulle kunne virke under win7 ?

Endelig sker det temmeligt hyppigt, at producenter prøver at skubbe kunderne til at købe opdateringer og ny softwareprodukter ved med
vilje at forringe bagudkompatibiliteten. F.eks er mange Open
Source tekstbehandlingsprogrammer væsentligt bedre end MS Word til at forstå det gamle Word-2.0 filformat.«

Dokumentation

Læs mere og stil dine egne spørgsmål

Kommentarer (21)

Ja det har jeg selv en personlig erfaring med, og det er ikke kun helt gamle versioner af office der kan give problemer.

En af mine kolleger kunne pludselig ikke åbne hendes phd afhandling (1/2 år efter hun havde afleveret) fordi IT-afdelingen havde opgraderet MS-office i mellemtiden (vist nok Office 2003).

Da jeg så prøvede med OpenOffice, virkede det fint. Jeg ved stadig ikke hvad der gjorde at den nyere version af MS-office ikke kunne for der var ikke noget i dokumentet som jeg kunne se skulle give problemer, men der var tydelig vis et eller andet....

  • 0
  • 0

Ligesom IBM i gamle dage,
alle pc'er skulle være IBM kompatible, men IBM var det ikke selv

  • 0
  • 0

Moderne PC'ere er ikke længere fuldt IBM kompatible på hardware niveau. Man kan vel nærmest kalde dem Intel/AMD kompatible. Det skal man ikke græde over, for PC'en var en gammel og bøvlet arkitektur. Må den hvile i fred. Til gengæld håber vi på, at de to ovennævnte producenter kan forblive enige om standarderne fremover.

Så desværre, DOS spil er ikke længere understøttet på moderne hardware. De går nemlig direkte til hardware.

16 bit Windows spil (Win 3.1 og enkelte win95 spil) er måske supporteret under 32 bit Windows Vista / 7. Under 64 bit Windows 7 har man et såkaldt XP-mode, der kan emulere gammel PC hardware. Spil harmonerer dog dårligt med XP-mode.

32 bit Windows spil (Windows 2000 spil og nyere) bør i princippet altid virke selv under 64 bit Windows. Man er dog ofte nødt til at bruge særlige "kompatibilitets indstillinger" til dem.
Dvs. du højreklikker på programmet, vælger "kompatibilitet" og vælger en passende "kompabilitetstilstand" for programmet. Det er nemlig ofte dårlig programmering, der er skyld i kompatibilitetsproblemer. F.eks. at installeren tror der er for lidt lagerplads, hvis der er mere end X antal gigabyte ledig!? Eller installeren forventer helt bestemte versioner af Windows. Eller programmet forventer en vis grafikindstilling. Dvs. man skal bare "narre" dem til at installere og køre...

  • 0
  • 0

På en rimeligt moderne PC kan man, hvis man kører Windows, installere Oracle Virtualbox og installere den gamle DOS/Win98 eller hvad det nu er "indeni" og derefter den gamle software. Det virker fint - ofte er gammel software skrevet til maskiner der er 500 gange langsommere end den man sidder med. Det er mest RAM der sætter begrænsninger. Når man har en kørende maskine kan man kopiere den o.s.v. så man kan installere ting som potentielt bricker maskinen og bare starte en ny kopi hvis det går galt.

På Linux er der Virtualbox eller Quemu at vælge imellem.

http://www.oracle.com/technetwork/server-s...

Der er selvfølgeligt også MAME - http://mamedev.org/ - for 1000++ spil ;-)

  • 0
  • 0

Der er mange gode forslag i debatten på hvordan man får tingene til at virke, men hvis man ikke ønsker/har brug for at emulere en hel maskine kan jeg anbefale dosbox der emulerer... dos. Det har kostet mig nogle timer med de gamle klassikere;)

  • 0
  • 0

Selv små bitte forskelle i definitionen af et system-kald kan betyde utroligt meget kode-arbejde og derfor er det dyrt, ikke mindst når man skal teste, at det hele virker som det skal. (Specielt bliver det krydret, når man vil køre 32bit programmer under et 64bit OS, og det modsatte er stort set umuligt.)

Systemkald, er et princip der er ældre end dos - og langtfra er egnet til nutidens computere. Mange problemer, kan løses, hvis man definerer et højniveausprog, som ikke er hardwarelåst, og hvor man fra sproget ikke ved, om den underliggende platform er f.eks. 16, 32, eller 64 bits. Et sådant højniveau sprog, kan også have en binær specifikation og dermed gøre de binære koder kompatible - selv med andre processortyper, og andre indstruktionssæt. Operativsystemet, skal dog have en in-time compiler, der oversætter mellem de definerede binære koder, og computerens hardware. Det er mere effektivt, end at bruge systemkald, da alle programmer compileres til, at skrive direkte til hardwaren - som i gamle dage. Og det kan køre på enhver CPU, uanset akitektur, hvis man har en CPU-driver til den pågældende CPU indstalleret i operativsystemet. Selve oversættelsesopgaven, vil normalt klares af operativsystemet, og CPU driveren kun indeholde specifikationen, samt en lille bootloaderkode i maskinkode til CPU'en, der udgør en lille fortolker. Men, samtidigt opnås samme store sikkerhed (eller større), end i moderne operativsystemer. Et operativsystem med funktionskald, er et forældet operativsystem.

  • 0
  • 0

Et operativsystem med funktionskald, er et forældet operativsystem.

Spændende.

Hvilke ikke-forældede operativsystemer er pt. i drift ?

  • 0
  • 0

Der er mange gode forslag i debatten på hvordan man får tingene til at virke, men hvis man ikke ønsker/har brug for at emulere en hel maskine kan jeg anbefale dosbox der emulerer... dos. Det har kostet mig nogle timer med de gamle klassikere;)

Her er en ganske brugbar how-to:
http://www.alt-til-windows.dk/?Artikler/Sp...

Jeg genopdagede gode gamle "The Incredible Machine" i sidste uge.

Tak for "Railroad Tycoon" tippet. Det kommer til at koste mig et par hyggelige timer :D

  • 0
  • 0

[quote] Et operativsystem med funktionskald, er et forældet operativsystem.

Spændende.

Hvilke ikke-forældede operativsystemer er pt. i drift ?
[/quote]

De findes faktisk, men de fleste af disse systemer er teoretiske af natur. Problemet med at køre uden systemkald er at du satser alt på en enkelt aktie. Hvis din compiler har en fejl, så kan det nemt tage hele systemet ned. Ja, du kan få fuldstændigt sindsygt gode hastigheder, men hvad er prisen? Jeg er mere til den nuværende form, hvor du i hardware har et virtualiserende lag mellem applikationer og operativsystemet. Det fungerer temmelig godt som en sikring mod fejlagtige programmer, da kernen er beskyttet og kan slå det fejlbehæftede program ihjel.

Stort set samtlige af de systemer af den form, der ikke er teoretiske, er designet til at køre på minihardware (sensor nodes, embedded stuff etc). Se f.eks. TinyOS der, vistnok, ikke har systemkald i traditionel forstand.

Der findes dog også nogle nyere systemer, typisk drevet af to ting:

  1. Vi har virtualiserende teknologi i vores computere anyway. Vi kan derfor lave exo-kerner, eller kerner der stille et referencehardwarelag til rådighed for virtuelle maskiner. Se bare på en Amazon EC2 instans der er rent virtuel.

  2. UNIX har i det store og hele spillet "fallit" ved kun at være interessant for C-programmører. Mere avancerede sprog har ofte skulle lave krumspring for at kunne snakke med kernen.

Se f.eks. Mirage-projektet http://www.openmirage.org/ og HaLVM-projektet http://halvm.org/wiki/ der respektivt laver sådanne systemer for ML og Haskell.

  • 0
  • 0

Men jeg ville egentlig gerne køre pauseskærmen "Johnny Castaway", den er desværre kun opdateret til win XP.

Den er rigtig morsom, og den eneste pauseskærm, der er sjovere end det, man rent faktisk laver på 'putteren.

Jeg kører Ubuntu. På en Dualcore 64 bit ældgammel Dell. (6 år). Min nørd synes, jeg skal skifte til win 7.

Mvh
Tine- der forresten har BattleChess. Derfor blev min lille dreng skak- og computernørd. ;-D

  • 0
  • 0

Mange problemer, kan løses, hvis man definerer et højniveausprog, som ikke er hardwarelåst, og hvor man fra sproget ikke ved, om den underliggende platform er f.eks. 16, 32, eller 64 bits. Et sådant højniveau sprog, kan også have en binær specifikation og dermed gøre de binære koder kompatible - selv med andre processortyper, og andre indstruktionssæt.

Jens: Du lister fordelene i din anbefaling af mange lag på lag, adskillelser. Dine argumenter er rigtige, og du bør især fremhæve "frihedsgrader", at man kan flygte fra "møllesten om halsen" ved at opdele i mange lag af abstraktioner, fordi det øverste lag som man programmerer i, kan være meget let at ændre i.

Men: De mange abstraktioner kan medføre et mareridt af problemer med kompatibilitet, fordi hvert eneste lag typisk bliver opgraderet hver for sig, efterhånden som måneder og år vandrer ind i fremtiden. Leverandører svigter, så enkelt kan det være, de har måske typisk påstået i markedsføring at produktet vil blive vedligeholdt for evigt, og så går der måske kun tre år, og så er den hest helt død.

Det kan være klogere at kode forholdsvis direkte til en konkret hardware, og passe godt på den hardware i mange år, og så opstår der en dag hvor nogen laver en virtuel udgave af den hardware, og det får man måske meget billigt foræret, hvis man kan vente indtil da.

Hvis man dyrker en ekstrem grad af lagopdelte abstraktioner, da forudsætter det at man er en IT-driftsorganisation der har disciplin som stål, og kan tvinge leverandører til at levere perfekt kvalitet. Hvis man virkelig kan det, da kan man til gengæld tilbyde sine egne kunder store frihedsgrader og hurtige udviklingstider når de finder på nogle nye behov. Jeg har selv dyrket i den retning, og det virkede ikke i det lange løb. Jeg skriger, når en leverandør af et operativsystem (og alverdens andet) opgraderer på en måde, så der er detaljer i mine applikationer der pludselig ikke virker. Det er en katastrofe at skulle pille i gamle applikationer, programmørerne kan intet huske, reelt kan de ikke, og er måske slet ikke ansatte længere. Desuden: Når der er mange lag af abstraktioner, hvem er den skyldige, når en fejl opstår? I store organisationer kan der være mange eksperter fordelt på planeten, der hver især peger på de andre, og imens går tiden. Den situation har jeg oplevet for mange gange til at jeg holder af det.

Jeg vil hellere ansætte nogle eksperter der kan kode direkte til en stærk hardware, jeg vil lade dem arbejde indtil softwaren er perfekt, og samtidig forlange en lang liste af parametre der kan ændres via en simpel tekstfil, og det bliver dernæst de eneste mulige ændringer i den software, indtil jeg en dag i fremtiden kyler det på lossepladsen. Et ekstra krav fra mig er, at programmørerne koder til præcis den hardware der ender med at køre i drift, altså hardware der er toptunet og befinder sig i et helt rent kølerum, så undgår man alverdens problemer i en indkøringsfase, og hardwaren kan forventeligt holde således i mange år. Hvis kunderne dernæst forlanger ændringer, så vil jeg pege på listen af parametre, dér er jeres muligheder, venner, og hvis I vil mere end det, så overholder I ikke jeres aftale med os, om hvad applikationen skal kunne i dens levetid. Altså begrænsninger, men lave udgifter og måske aldrig en fejl.

Frihedsgrader er vigtige, en værdig kongstanke, fordi man kender til eksempler hvor en mangel på frihedsgrader koster dyrt. Alligevel, hvis man investerer stort i frihedsgrader, så ender det måske reelt med at kunderne alligevel ikke udnytter det. Når kunder kommer på banen med deres nye tanker om en applikation, da er der ofte forinden hændt et stort skifte i verdens teknologi, altså fuldstændig forfra.

  • 0
  • 0

Jeg skriger, når en leverandør af et operativsystem (og alverdens andet) opgraderer på en måde, så der er detaljer i mine applikationer der pludselig ikke virker.

Ja - tænk hvordan det ville være at være ingeniør, hvis gud hele tiden lavede om på naturlovene.

  • 0
  • 0

Jeg har ikke oplevet de helt store problemer med bagudkompabilitet. Jeg var lidt nervøs i år, fordi jeg skulle have ny bærbar computer og det ville blive en med 64 bit Windows 7. Jeg har i mange år ikke købt software, så noget af det software jeg har er enormt gammelt. Men så længe det virker, gider jeg ikke at skifte. F.eks. bruger jeg Officepakken 2000 Professional, fordi den fik jeg gratis. Jeg har set nogle af de nyere versioner, men de lignede ikke noget, jeg havde lyst til at bruge. (Altså den grafiske brugergrænseflade havde ændret sig til det værre - synes jeg). Jeg kan godt lide brugergrænsefladen i Office 2000 og programmerne kører for mig uden problemer. Nu bruger jeg også kun Word og Excel og sjældnere Powerpoint og jeg bruger efterhånden ikke programmerne så vældigt meget som tidligere.

Nå men, skiftet til den nye computer gik ikke så galt som jeg havde frygtet - alle programmer undtaget ét kunne installeres. Det program savner jeg godt nok lidt, men jeg klarer mig uden, ser det ud til. (Det er et statikprogram "WinBeam", til beregning af kræfter i vilkårlige bjælker).

Det eneste bortset fra ovenstående jeg har oplevet og som egentligt problem med bagudkompatibilitet er, at nogle af mine gamle Worddokumenter, går galt i byen, hvis jeg åbner dem idag. Men det ser primært - måske - ud til at være et problem med fonte. Jeg spiller ikke så meget, bortset fra en smule "arkadespil" en sjælden gang i mellem. For tiden "Luxor 1, 2 og 3". Har gennemført Luxor 1, og er i gang med 2'eren, hehehehehe.

  • 0
  • 0

Tine, at skifte til Windows 7 for at se en gammel screensaver er den sørgeligste grund til at skifte :)

Som jeg forstår det har WineHQ fået Johnny Castaway til at kører uden problemer under Linux.
http://appdb.winehq.org/objectManager.php?...

Lige hvad angår at wrappe det som en egentlig screensaver har de vist ikke fået til at virke, men det er måske heller ikke dit største ønske.

Selv har jeg også fået en arbejdscomputer med windows 7 64bit, og de programmer jeg har størst problemer med, er helt nyt software. En Linux Debian Minx kunne heldigvis installeres ved siden af uden problemer :)

  • 0
  • 0

Men jeg ville egentlig gerne køre pauseskærmen "Johnny Castaway", den er desværre kun opdateret til win XP. Den er rigtig morsom, og den eneste pauseskærm, der er sjovere end det, man rent faktisk laver på 'putteren. Jeg kører Ubuntu. På en Dualcore 64 bit ældgammel Dell. (6 år). Min nørd synes, jeg skal skifte til win 7. Mvh Tine- der forresten har BattleChess. Derfor blev min lille dreng skak- og computernørd. ;-D

sudo apt-get install dosbox -y

  • 0
  • 0

Det eneste bortset fra ovenstående jeg har oplevet og som egentligt problem med bagudkompatibilitet er, at nogle af mine gamle Worddokumenter, går galt i byen, hvis jeg åbner dem idag. Men det ser primært - måske - ud til at være et problem med fonte. Jeg spiller ikke så meget, bortset fra en smule "arkadespil" en sjælden gang i mellem. For tiden "Luxor 1, 2 og 3". Har gennemført Luxor 1, og er i gang med 2'eren, hehehehehe.

Win 7 har aldrig fået ordentligt fat om Type 1 fonte (Postscript fonte), sommetider kan de slet ikke bruges, sommetider er det bare Word, der ikke kan fordøje dem. Og Microsoft ser det ikke som et problem, da man jo bare kan køre en virtuel XP oven på Win 7. Det gør det lidt håbløst eller meget dyrt at bruge Win 7 til typografiske opgaver, da det halve fontbibliotek skal genanskaffes som OpenType.

  • 0
  • 0

Hvordan vil billedet se ud, hvis vi skyder et ekstra abstraktionslag ind mellem operativsystem og applikation?

Her tænker jeg på ting som Steam[1] og Googles Chrome browser med Native Client[2]; vil vi (nemt) kunne komme ud over problemerne med sikkerhed og ændrede funktions- og systemkald, hvis vi lægger sådan et lag mellem OS og applikation?

[1] http://store.steampowered.com/about/
[2] http://www.version2.dk/artikel/chrome-14-n...

  • 0
  • 0

Abstraktionslag placeret oven på et OS er den sikre vej til både skilsmisse og personlig ruin - med mindre man sælger "teknologien" ;-)

Abstraktionslag er blot at sætte sig solidt mellem to stole: Man bytter OS'ets velkendte mærkværdigheder ud med abstraktionslagets, oveni købet skal eens kode samtidigt tracke både OS'et og abstraktionslaget - selvfølgeligt "lækker" implementeringen ting igennem og der vil være nogle OS- features som bare ikke er i abstraktionslaget fordi de er for mærkelige til at have tilgængelige på alle OS'er som man gerne vil abstrahere fra.

Det er nemmere at placere de mærkelige ting i et særligt modul, som alle ved skal hackes når noget skal porteres, og skrive resten af koden direkte til det OS den skal køre på.

Hvis man ved man kan gøre det bedre end alle andre eller har usædvanlige krav er det bedre og renere helt at skrive sit eget custom OS!

  • 0
  • 0