Unreal mode (nogle gange også Big Real Mode, 32 bit Real Mode, Flat Real Mode ) er en metode, der implementerer evnen til at adressere op til 4 gigabyte hukommelse fra den rigtige tilstand af Intel 80386-processoren og højere , i stedet for 1 megabyte tilgængelig i rigtig tilstand . I modsætning til navnet er denne metode ikke en processortilstand .
Det blev aktivt brugt i nogle MS-DOS- applikationer i begyndelsen af 1990'erne, herunder nogle spil (for eksempel i Ultima VII [1] ). Bruges også ved udførelse af SMM -kode [2] .
På grund af tilstandens popularitet var Intel nødt til at understøtte den i efterfølgende processorer, selvom den forblev udokumenteret [3] .
MS-DOS- kernen kører i 16-bit processortilstand , ægte eller V86.
For at fjerne grænsen på 1 MiB adresseplads (pålagt af 16-bit processor real mode adressering), er en beskyttet tilstand nødvendig (hvor 16 MiB RAM bliver tilgængelig, for at få en større mængde - op til 4 GiB, en 32-bit beskyttet tilstand er nødvendig, som dukkede op i 80386 processorer).
For at udvikle programmer under DOS, der kræver en stor mængde hukommelse, skulle man således enten programmere i beskyttet tilstand og bruge DOS- og DPMI-extenderen (som Doom f.eks. er skrevet ), eller bruge en udokumenteret processorfunktion. Udvikling af beskyttet tilstand krævede brug af et helt værktøjssæt og en debugger designet til dette, og normalt forbundet med en specifik DOS-extender. Disse pakker var dyre, ikke så populære som almindelige DOS-udviklingsmiljøer og blev derfor ofte forladt. En udokumenteret funktion tillod al hukommelse at blive brugt fra en applikation udviklet i et normalt DOS-udviklingsmiljø, såsom Borland C++ .
Denne funktion består i, at du kortvarigt kan gå ind i 32-bit beskyttet tilstand, indlæse segmentbeskrivelser der med grænser, der overstiger 64K, og derefter afslutte tilbage til 16-bit reel tilstand. Når du afslutter, gemmes værdien af grænsen, der overstiger 64K, grænsen nulstilles ikke, når du forlader sig selv. Derefter kan du ved hjælp af 32-bit instruktioner eksplicit skrevet i assembler få adgang til hele maskinens hukommelse direkte i forhold til segmentet med den "forkerte" grænse.
Muligheden for en sådan adressering følger direkte af de tekniske specifikationer 80386 , hvori to muligheder herfor er fremkommet. Den første er en dokumenteret overgang fra beskyttet tilstand til reel tilstand ved at rydde PE-flaget i CR0-registret (dets forgænger, 80286 , ignorerede forsøg på at rydde dette flag i dets 16-bit version af CR0, kaldet MSW). Den anden er muligheden for at indstille segmentstørrelsen lig med størrelsen af hele det tilgængelige fysiske adresserum (på grund af det faktum, at registrenes bitbredde er lig med adressebussens bitbredde).
Tilstedeværelsen af "skyggeregistre " til cachelagring af karakteristika for segmenterne, der er knyttet til segmentregistrene, og tillader dig at "huske" tilstanden af segmentregistret, der var indstillet i beskyttet tilstand, selv efter skift tilbage til reel, blev dokumenteret for 80286, hvor de også kan bruges (denne gang på en virkelig udokumenteret måde) til at få adgang til al fysisk hukommelse fra real mode, dog ikke i form af lineær adressering, som i 80386, men gennem 64 KB "windows" segmenter.
Denne metode kan ikke bruges til kode- eller stakadressering [4] i DOS-baserede multitasking-miljøer og i vinduet "Virtual 8086" i Windows -operativsystemet , inklusive NTVDM . Desuden er Unreal mode ikke kompatibel med EMM386 - sidstnævnte fungerer ved at skabe en enkelt V86 mode virtuel maskine og sætte alle DOS ind i den. Fuldstændige virtuelle maskiner, såsom Virtual PC og VMware Workstation , fungerer normalt uden problemer.