python 2.7.12 on Linux behaving differently than on Windows

eryk sun eryksun at gmail.com
Tue Dec 6 21:55:10 EST 2016


On Tue, Dec 6, 2016 at 3:05 PM, Random832 <random832 at fastmail.com> wrote:
>
> The fact that Windows was launched at boot by running "win.com" (either
> in autoexec.bat or manually at the command line) created a *perception*
> that windows ran "on top of DOS", but running it really *replaced* DOS
> in memory, putting the CPU into protected mode and everything. The
> ability to boot into (or exit to) DOS was because people still did real
> work (and games) in DOS and the virtual environment of DOS-on-Windows
> didn't perform well enough to be sufficient.

Win16 (and Win32 if it thunked to Win16) called DOS INT 21h functions.
The virtual machine manager implemented some (or most) of these
functions in 32-bit protected mode (VxDs), but it had to maintain DOS
data structures in each VM (e.g. drive working directories; PSPs). It
was like an elaborate 32-bit DOS extender. Of course there was also a
lot of new functionality for Win32 programs such as preemptively
scheduled threads and memory-mapped files.

> I vaguely remember a version of cmd.exe that would run on Windows
> 98 floating around back in the day, but it certainly didn't come with
> the OS. It might have been a pirated Windows NT component.

cmd.exe was ported to Windows 9x, but never distributed with it. On
Windows 9x it lacked Unicode support. Obviously all of the functions
for NTVDM integration were omitted. Its `copy` command called CopyFile
instead of NT's CopyFileEx, so you couldn't Ctrl+C cancel copying a
large file. Reading from the console required custom support for
command-line editing and history -- features that are built into the
NT console. The command prompt would always wait for a child process
to exit, even for GUI apps, because it couldn't call NT's
NtQueryInformationProcess to get the PEB to peek at the subsystem
type.



More information about the Python-list mailing list