You missed artifacts in ./PC/VC6 ./PC/VS7.1 ./PC/VS8.0 ./PC/VS9.0
On Mon, Dec 24, 2012 at 12:55 AM, brian.curtin
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/c903e4f1121d
changeset: 81005:c903e4f1121d
parent: 81003:e3d0417d8266
user:Brian Curtin br...@python.org
date:Sun Dec 23 16:53:21 2012 -0600
summary:
Fix #14470. Remove w9xpopen per PEP 11.
As stated in PEP 11, 3.4 removes code on Windows platforms where
COMSPEC points to command.com. The w9xpopen project in Visual Studio
was added to support that case, and there was a special case in subprocess
to cover that situation. This change removes the w9xpopen project from
the Visual Studio solution and removes any references to the w9xpopen
executable.
files:
Lib/subprocess.py| 32 --
PC/w9xpopen.c| 112 ---
PCbuild/pcbuild.sln |2 -
PCbuild/python.vcxproj |6 +-
PCbuild/w9xpopen.vcxproj | 287 ---
PCbuild/w9xpopen.vcxproj.filters | 13 -
Tools/msi/msi.py |2 -
7 files changed, 1 insertions(+), 453 deletions(-)
diff --git a/Lib/subprocess.py b/Lib/subprocess.py
--- a/Lib/subprocess.py
+++ b/Lib/subprocess.py
@@ -1029,23 +1029,6 @@
return Handle(h)
-def _find_w9xpopen(self):
-Find and return absolut path to w9xpopen.exe
-w9xpopen = os.path.join(
-os.path.dirname(_winapi.GetModuleFileName(0)),
-w9xpopen.exe)
-if not os.path.exists(w9xpopen):
-# Eeek - file-not-found - possibly an embedding
-# situation - see if we can locate it in sys.exec_prefix
-w9xpopen =
os.path.join(os.path.dirname(sys.base_exec_prefix),
-w9xpopen.exe)
-if not os.path.exists(w9xpopen):
-raise SubprocessError(
-Cannot locate w9xpopen.exe, which is needed for
-Popen to work with your shell or platform.)
-return w9xpopen
-
-
def _execute_child(self, args, executable, preexec_fn, close_fds,
pass_fds, cwd, env,
startupinfo, creationflags, shell,
@@ -1074,21 +1057,6 @@
startupinfo.wShowWindow = _winapi.SW_HIDE
comspec = os.environ.get(COMSPEC, cmd.exe)
args = '{} /c {}'.format (comspec, args)
-if (_winapi.GetVersion() = 0x8000 or
-os.path.basename(comspec).lower() == command.com):
-# Win9x, or using command.com on NT. We need to
-# use the w9xpopen intermediate program. For more
-# information, see KB Q150956
-#
(http://web.archive.org/web/20011105084002/http://support.microsoft.com/support/kb/articles/Q150/9/56.asp)
-w9xpopen = self._find_w9xpopen()
-args = '%s %s' % (w9xpopen, args)
-# Not passing CREATE_NEW_CONSOLE has been known to
-# cause random failures on win9x. Specifically a
-# dialog: Your program accessed mem currently in
-# use at xxx and a hopeful warning about the
-# stability of your system. Cost is Ctrl+C won't
-# kill children.
-creationflags |= _winapi.CREATE_NEW_CONSOLE
# Start the process
try:
diff --git a/PC/w9xpopen.c b/PC/w9xpopen.c
deleted file mode 100644
--- a/PC/w9xpopen.c
+++ /dev/null
@@ -1,112 +0,0 @@
-/*
- * w9xpopen.c
- *
- * Serves as an intermediate stub Win32 console application to
- * avoid a hanging pipe when redirecting 16-bit console based
- * programs (including MS-DOS console based programs and batch
- * files) on Window 95 and Windows 98.
- *
- * This program is to be launched with redirected standard
- * handles. It will launch the command line specified 16-bit
- * console based application in the same console, forwarding
- * its own redirected standard handles to the 16-bit child.
-
- * AKA solution to the problem described in KB: Q150956.
- */
-
-#define WIN32_LEAN_AND_MEAN
-#include windows.h
-#include stdio.h
-#include stdlib.h /* for malloc and its friends */
-
-const char *usage =
-This program is used by Python's os.popen function\n
-to work around a limitation in Windows 95/98. It is\n
-not designed to be used as a stand-alone program.;
-
-int main(int argc, char *argv[])
-{
-BOOL bRet;
-STARTUPINFO si;
-PROCESS_INFORMATION pi;
-DWORD exit_code=0;
-size_t cmdlen = 0;
-int i;
-char *cmdline, *cmdlinefill;
-
-if (argc 2) {
-if
