Q:

Do 16-bit programs run in Virtual 8086 Mode on a 32-bit OS?

I want to confirm a few things. I am making assembly language programs for 8086.
I am assembling using masm611 assembler. If i run and debug the 8086 16bit real mode program under command prompt in 32 bit windows, Does it use and modify the actual cpu registers and memory? Does the program run in virtual mode86 under windows 32bit?  
Also, if i debug the program using the CodeView debugger in PWB Microsoft Programmers’ Workbench as below:
PWB

Please confirm whether the register and memory values in the CodeView debugger are actual values in hardware and are changing. Also when i run the program in PWB it uses the actual hardware under windows 32 bit.

A:

When you run an MS-DOS program from the Windows command prompt under a 32-bit version of Windows it's run under NTVDM which uses virtual 8086 mode to emulate real mode. The program, when running, uses the CPU's registers as normal. However, it doesn't use memory in same way that code running in real mode would. 
Windows doesn't give NTVDM, and any program running under it, direct access to physical memory, just like it doesn't any other Windows application direct access. Instead accesses by the program to memory are translated from linear addresses to physical addresses through page tables. This means that if your MS-DOS application writes to memory location 074B:0000 the CPU will converts this to a linear address of 000074B0 and then through a page table look up converts it a completely different physical address chosen by Windows.  Windows also doesn't allow NTVDM, or the application running under it direct, access to device hardware, so any access to device memory will either be blocked or emulated by NTVDM.
I should also note that since the version of CodeView you're using is also an MS-DOS application its also running as an application in virtual 8086 mode using the same actual CPU registers as the program being debugged. This means that when CodeView displays the registers of the debugged program it's showing the values the were in the registers at the time the program stopped and CodeView took over. CodeView needs the registers for its own use, so the first thing it does when it gets control is to save the debugged programs registers in memory somewhere.

