Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I notice an interesting thing happens when you give the old mem.exe command to an XP command prompt:

Switch to Real Mode

The shell switches from Protected Mode to Real Mode as you can tell from the change in directory name (and the memory structure displayed). Is it the Windows exe loader that is doing this or cmd.exe? Is there a way to switch back to Protected Mode?

share|improve this question

migrated from Nov 9 '12 at 0:41

This question came from our site for professional and enthusiast programmers.

Looks like a bug to me. Switch back and forth at will with cd \progra~1 vs cd "\program files". – Hans Passant Nov 8 '12 at 19:26

mem.exe is a 16bit application carried forward from 16bit windows for compatibility. Thus it runs in the 16bit VM1 within 32bit windows and displays memory as such. (It does not exist in 64bit windows as the 16bit VM is not included).

The shifting of the prompt to show the short file name is one of the inconsistencies of cmd.exe triggered by running a child WoW process.

But cmd.exe is not running in "real mode" because real mode does not exist for 32 or 64bit processes.

1 The 16bit Windows-on-Windows subsystem makes use of one of the 16bit execution modes of x86/x64 processors to provide an isolated environment, much as VMWare (et al) do to host a complete machine.

share|improve this answer
You seem to be suggesting cmd starts a WOW VM and launches mem.exe inside of that. When the command exits cmd is still in protected mode. Ok, how does cmd know it needs to run mem.exe in a WOW? And why does cmd change its prompt to 8 character mode? – Tyler Durden Nov 8 '12 at 19:05
@TylerDurden 1. Windows knows to run an exe in 16bit WOW by looking at its file header. 2. Change of prompt to short path is something I've seen cmd do, but never been able to understand the conditions, might be something happening in [GetCurrentDirectory][… API. – Richard Nov 8 '12 at 19:10
Changing the current directory to the short equivalent happens because 16-bit programs do not support long file names. – Raymond Chen Nov 8 '12 at 20:43
To put it another way: the current directory has to change because the WOW VM can't handle the long file names, and it just so happens that Windows doesn't bother to change it back afterwards. I don't know whether there's a technical reason why it would be difficult to change it back. It may just be that it wasn't considered worth the programmer's time. – Harry Johnston Nov 12 '12 at 3:00
Incidentally, if you want a 16-bit shell, you can run – Harry Johnston Nov 12 '12 at 3:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .