Talk:Unreal mode

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Incorrectness of information here? 

message: 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)
thread_title:  Not really a bug 

message: 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)
replies: text: 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)
thread_title:  No sources 

message: 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)
replies: text: 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)

text: 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)

text: I doesn't take a lot of googling to find a WP:RS that says such things either . Someone not using his real name (talk) 08:59, 17 February 2014 (UTC)
thread_title:  Unreal mode on 80286?