A Brief History of Unreal Mode
Michal Necasek (via Joe Groff):
For the purposes of this discussion, unreal mode is a variant of the x86 real mode with non-standard segment limits and/or attributes, different from the processor state at reset. To recap, real mode on the 286 and later CPUs has much more in common with protected mode than with the real (and only) mode of the 8086. Notably, undefined opcodes raise exceptions, segment limit overruns cause general protection or stack faults, and (on the 386 and later) 32-bit registers and 32-bit addressing can be used—subject to limit checks.
[…]
As a general-purpose programming technique it is unusable, because it absolutely cannot function in V86 mode. Transitions to V86 mode always force real-mode compatible segment limits and attributes. That means unreal mode cannot be used together with EMM386 or other DOS memory managers utilizing V86 mode. Unreal mode also cannot be used in the DOS boxes of 386 Enhanced Mode Windows 3.x, in the DOS boxes of OS/2 2.x, Windows NT, or Windows 9x. That is an extremely serious drawback.
[…]
On the other hand, when unreal mode can be used, it is very useful. HIMEM.SYS uses unreal mode to speed up extended memory access, and perhaps more importantly, preserve normal interrupt latency. Firmware can and does use unreal mode for accessing memory beyond 1 MB during initialization; it avoids switching between real and protected mode, and in firmware there is no danger of segment limits being reset.
[…]
Unreal mode is almost certainly an accident of history, a side effect of the fact that the initial 386 design had no architected way of switching from protected mode back to real mode. Once the technique started being used, instead of clearly documenting how it works, Intel in its typical fashion documented only certain aspects of it, such that only programmers who already know about unreal mode find traces of it in the official documentation.
