Talk:Unreal mode

Skip to table of contents

This is the talk page for discussing improvements to the Unreal mode article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.

Software: Computing Low‑importance

	This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

descriptor[edit]

Although not mentionned in the main article ATM, there was also the possibility of loading the descriptor part of the CPU segment registers by way of special so-called undocumented instructions on the 80286 - 386 and early 486, rather than switching to and fro between RM/PM. This opened the way to even more exotic "modes" than can be attained using the now standard technique. One very creative use of the capability is found in the 80286-specific code inside MS-DOS Himem.sys, allowing it not only to access the extended memory while staying in real mode all the time, using a REP MOVSW instreuction, but to do so with interrupts ALLOWED ! The trick is that not only are DS and ES pointing to extended memory, but also the CS selector is "desynchronised" so that an interrupt occurring in the middle of the move will return to some place different than the interrupted REP MOV itself, allowing the code to correct things, reload the "unreal" descriptors and resume the REP MOV where it left!!! Very ingenious, and I don't know the history of that piece of code but I doubt it originated inside of Microsoft in the 1st place. Rather from Intel ?

-- Ninho

Incorrectness of information here?[edit]

Either we don't have the same definition of "unreal mode" or something's wrong in the article...

From what I know it's perfectly possible to have INTs allowed.

For me the technique consists in altering only the LIMIT part of all DATA descriptors and setting them to 4G, then coming back in real mode (all this with INTs off). after setting PE=0 again and before allowing INTs, it's safe to reload all the segments touched with their previous values. The rules of real mode apply and and the BASE value gets REGISTER*16.

BUT the LIMIT value is not changed. THIS is the "bug" that allows it all.

So from this moment on it's just like normel real mode again. you can load and use 16bits segments addresses again and it works OK. So INTs that push/pop them work fine. Only thing is you can use a 32b offset with immediate or register, and it works.

See:

http://my.execpc.com/~geezer/osd/pmode/unreal.asm (google's second link, too bad wikipedia is the first)

In the code you see "pop es" and "pop ds" . This illustrates what I said.

So for me the 4th paragraph of the article is wrong.

Helloworld256 06:35, 15 January 2007 (UTC)[reply]

Just had a go at rewriting the opening paragraphs, did i screw up? This is my first major edit. Ripdog2121 18:49, 12 April 2007 (UTC)[reply]

The truth is, unreal mode might not work with interrupts enabled for the following reason. Unreal mode exploits the fact that x86 CPU caches the contents of the BASE and LIMIT inside hidden parts of the segment / selector registers. In protected mode, BASE can be any value from 0 to 4GB, but in real mode BASE is 16*(value of segment). This means, that any code which runs in real mode and modifies the segment registers (such as interrupts through push / pop) will flush the hidden part of the segment / selector registers and reload it to a valid real-mode value. This is the reason why the article states that unreal mode cannot be used with interrupts enabled. --193.226.6.226 21:11, 29 June 2007 (UTC)[reply]

NOT true, unreal mode can be used with interrupts enabled. Reloading the segment registers in real mode only affects the base, and not the limit, part of the descriptor caches. To get back to true real mode, you have to go to protected mode, set the selectors to a descriptor containing a valid base and limit for real mode, and go back to real mode. Interrupts must be disabled when switching to and from protected mode, but once in unreal mode, there is no reason to leave them disabled. System86 (talk) 14:12, 30 January 2008 (UTC)[reply]

System86: We agree. Thats what I said :D . Only the unregistered wikipedia user previous your post added incorrect info.Helloworld256 (talk) 20:13, 1 February 2008 (UTC)[reply]

Not really a bug[edit]

This article associates unreal mode with a x86 bug. Intel Programmers Reference clearly explains the hidden part of the segment / selector registers (i.e. the cache of the base and limit), how it gets loaded etc. A programmer should expect unreal mode if he is familiar with theses concepts.

= Agreed, a programmer could expect and should verify the behaviour. It certainly is no bug, but intelligent design. However... someone at Intel decided to misdocument or undocument the action of shadow descriptors in Real Mode, Intel manuals and many 3rd party books misrepresented the feature until, at least, the 80486s. Ninho (talk) 13:35, 26 June 2013 (UTC) Ninho[reply]

No sources[edit]

There are far too many unsourced claims in the article. Which DOS extender used unreal mode? Which DOS games used unreal mode? Which BIOS uses unreal mode, and for what purpose? How was Win95 different from Enhanced mode Windows 3.x, or 386 memory managers?

All "professional" DOS extenders I'm familiar with (DOS/4G, PharLap 386|DOS and TNT, etc.) either didn't use unreal mode at all, or provided alternative methods when running under DPMI/VCPI etc. The article does not spell this out, but it is obvious that any control software which switches between real and protected mode will likely set "standard" descriptor limits when going back to real mode, thus overwriting the "extended" descriptor limits. What's worse, even plain DOS with EMM386 ran in protected/V86 mode, thus user code could neither enter protected mode nor use LOADALL to muck with descriptor limits or attributes. Unreal mode was therefore never particularly useful in general DOS applications, only in system-level software such as HIMEM.SYS (and then only conditionally) or Windows. Codegen86 (talk) 13:53, 28 February 2011 (UTC)[reply]

I can tell you that Ultima VII and its Voodoo Memory used unreal mode. 'Wouldn't know how to put that in a reference though. AngusCA (talk) 20:27, 14 April 2014 (UTC)[reply]

http://www.os2museum.com/wp/?p=322 "In August 1988, HIMEM.SYS version 2.03 implemented a new method of copying memory on 386 compatible processors, using unreal mode (or Big Real mode as it’s called in the HIMEM source) when the processor isn’t already in protected (or more specifically, V86) mode." Dirk Wolfgang Glomp — Preceding unsigned comment added by 85.177.161.43 (talk) 10:49, 5 May 2014 (UTC)[reply]

Unreal mode on 80286?[edit]

The article contains a paragraph: "There is a time penalty for leaving protected mode on the 286, because the CPU must be reset. Undocumented features of the CPU, such as LOADALL[1], can be used to enter unreal mode more quickly." The first sentence is true but off topic, and the second one appears nonsensical in this context, because Intel 80286 processor does not support the unreal mode as described in the article. Indeed, 80286 does not allow creation of protected-mode descriptors with a limit larger than 64 KB, and it lacks 32-bit registers that are necessary for flat addressing. 129.112.109.245 (talk) 00:25, 31 May 2011 (UTC)[reply]

ACK, I also stumbled over these statements. I'm no expert, just a humble real mode assembler programmer (and that rarely in the last 15 years). Having said this I think LOADALL is the penalty, and not a way around it, because there is no other way (excl. reboot). And what you write sounds far more plausible for me. –89.204.153.227 (talk) 14:37, 18 July 2011 (UTC)[reply]

Long time since I last reviewed this page and associated article. Regarding the 80286, 'unreal' mode does not involve enlarged segment limits, obviously, but segment attributes can indeed be changed from the "official" RM defaults using LOADALL (limit, up/down expansion dictating how the limit is interpreted, privilege level whose modification affects e.g. Far Returns). In addition the segment base could be set to any byte address instead of 16-byte boundary. /Some/ of this, which is no less 'unreal' than the trivial 'big' real mode on ia32, could be and was indeed used (himem.sys, smartdrive).

Time allowing I'll reintroduce some of this material into the article. right now i'll be making a minor edit - replacing 80286 back into the frame. Ninho (talk) 12:43, 26 June 2013 (UTC) Ninho[reply]

A lot of this article is misleading: you can't do this on a 286 (for there's no way to switch back to real mode without CPU reset. Also, you're still limited to 16-bit offsets in whatever segment you've set up. Someone not using his real name (talk) 08:55, 17 February 2014 (UTC)[reply]

I doesn't take a lot of googling to find a WP:RS that says such things either [1]. Someone not using his real name (talk) 08:59, 17 February 2014 (UTC)[reply]