Thread: hpl me plzzzz
View Single Post
Old Oct 29th, 2005, 9:56 AM   #32
lectricpharaoh
SEXY SHOELESS GOD OF WAR!
 
lectricpharaoh's Avatar
 
Join Date: Jun 2005
Location: Wet west coast of Canada
Posts: 1,188
Rep Power: 5 lectricpharaoh will become famous soon enough
Quote:
Originally Posted by ASMvsC++
And let me ask continue

I excute that code in DOS BOx
and some doc say DOS BOX pretend VM86 Mode
so in VM86 mode how can it run in that mode ( cuz u say it run in protect mode)
First, the term 'DOS box', when applied to current Windows machines, is often inacurate. Usually, it is not a DOS box at all, but a Windows 'console program'. These are regular Win32 programs that happen to start with a console window attached, and usually do not open any 'normal' (ie GUI) windows. However, you can open a console from a Windows GUI program, and use the entire Win32 API from a console program.

If this is the case with your program, it will be executing in protected mode, as normal. If it actually is a DOS program, it will almost certainly be running in V86 mode (which is actually a subset of protected mode), whether you're running it under Windows or not. Even DOS memory managers like EMM386 would run the CPU in V86 mode, and if you're using DPMI or a similar technology, you'll be running in V86 mode as well.

Lastly, even if you're not running in protected or V86 mode, you can still assemble (and usually execute) 32-bit instructions. All that happens is a prefix byte is generated to switch from 16-bit mode to 32-bit mode for the current instruction. In fact, if you look at the opcodes for most 16-bit instructions that have a 32-bit counterpart, they are the same; the CPU uses the current CPU mode and the presence/absence of override bytes to determine the 'size' of the instruction. Actually, two override bytes can be generated for any given instruction- one to override the operand size, as when using a 32-bit register, and another to override the address size, as when accessing a 32-bit segment. In fact, this latter allowed the 'flat mode' DOS trick used by certain programs, where the CPU was switched to p-mode, the segment limits on some/all of DS, ES, FS, and GS were set to greater than 64k, and then the CPU was switched back to real mode. The CPU would not load segment limits in real mode when segment registers were changed, allowing you to use address-size override bytes to access the whole of memory in real mode. Needless to say, this sort of hack was frowned upon for most real-world code, and impossible under p-mode, anyways, but it was used nonetheless.

The point of all this is you can't tell what mode you're in simply by what instructions are generated. Most, if not all, modern operating systems will be running so-called real mode programs in V86 mode, since switching between V86 and p-mode is (I believe) faster than between real mode and p-mode, as well as because V86 allows for things such as paging and privilege levels that simply are not supported under real mode.
__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick
lectricpharaoh is offline   Reply With Quote