python 2.7.12 on Linux behaving differently than on Windows

[eryk sun]

On Tue, Dec 6, 2016 at 2:51 AM, Nathan Ernst <nathan.ernst at gmail.com> wrote:
> On Mon, Dec 5, 2016 at 8:44 PM, Steve D'Aprano <steve+python at pearwood.info>
> wrote:
>> On Tue, 6 Dec 2016 10:09 am, eryk sun wrote:
>>
>> > The default Windows shell is "cmd.exe", and it's informally called the
>> > "Command Prompt",
>>
>> Thanks for the correction, I always mix up cmd/command . exe/com. I fear
>> this won't be the last time either -- I wish there was a good mnemonic for
>> which is which.

There are a few executables that end in .com: chcp.com, format.com,
mode.com, more.com, and tree.com. These are 32-bit / 64-bit PE/COFF
binaries, the same as any other Windows executable.

> Ify ou're running on Windows 10, at least, you can soon purge that memory.
> command.com doesn't exist (may never have existed on Win2k, XP, Vista, 7,
> 8, 8.1 or 10). If I try and run either "command" or "command.com" from
> Win10, both say command cannot be found.

Only 32-bit versions of Windows include the NT Virtual DOS Machine
(ntvdm.exe) for running 16-bit DOS programs. Such programs expect a
8086 real-mode execution environment, in which the DOS kernel hooks
interrupt 0x21 for its system-call interface. To provide this
environment, NTVDM uses a virtual 8086 mode monitor that's built into
the 32-bit kernel.

x86-64 long mode doesn't allow switching the CPU to v86 mode, so NTVDM
isn't available in 64-bit Windows. In this case the kernel's entry
point for VDM control is hard coded to return STATUS_NOT_IMPLEMENTED
(0xC0000002), as the following disassembly shows:

    lkd> u nt!NtVdmControl
    nt!NtVdmControl:
    fffff801`ffff4710 b8020000c0      mov     eax,0C0000002h
    fffff801`ffff4715 c3              ret

> IIRC, command.com was a relic of Win9x running on top of DOS and was a
> 16-bit executable, so inherently crippled (and probably never support by
> the NT kernel).

COMMAND.COM is a 16-bit DOS program, which was the "DOS prompt" in
Windows 3.x and 9x. The versions of Windows that ran on DOS had a
complicated design (in 386 Enhanced Mode) that used a virtual 8086
monitor that ran in 32-bit protected mode. As far back as Windows 3.1,
Microsoft started replacing some DOS system services with
functionality implemented in 32-bit VxDs. Some among us may recall the
big performance improvement that 32-bit disk access provided in
Windows for Workgroups 3.11.

In Windows 9x most DOS system calls were implemented in 32-bit
protected mode VxDs; they even reflected calls in v86 mode up to the
32-bit implementation. Thus much of the implementation underlying the
Win32 API used 32-bit code in protected mode. That said, initially in
Windows 95 there were still a lot of Win32 API calls that ended up
executing real-mode 16-bit DOS calls in the system VM. The book
"Unauthorized Windows 95" analyzes this in detail.

> Whereby cmd.exe coexisted but ran in a 32-bit context.

cmd.exe (command prompt) is a Windows application -- for the most
part, though it does go beyond the Windows API to peek at the NT
process environment block (PEB) of child processes. It was ported to
but never distributed with Windows 9x. On Windows 9x you instead had
an actual DOS prompt that ran COMMAND.COM in virtual 8086 mode.