subprocess and multiprocessing both have their own private modules for wrappers of win32 functions: Modules/_multiprocessing/win32_functions.c and PC/_subprocess.c.

It would be nice to group them in a common module (_win32?) that could be used throughout the stdlib.

+1

Agreed; I'm not personally the windows expert that should handle that consolidation though.

Big +1. I'll work up a patch.

Here's a patch replacing Modules/_multiprocessing/win32_functions.c and PC/_subprocess.c with a common PC/_windows.c. There's not much to the patch despite its size -- it just shuffles around the C code and does a few renames in the appropriate Python modules. All tests pass.

I left the copyright notice from PC/_subprocess.c at the top. No idea if that needs to stay or not.

Two high-level remarks about the patch:

• IMO there is no reason to put _windows.c in the PC directory. After all, there is no such distinction for posix-specific modules.
• wxPython already has a submodule named _windows.py. I wonder if this will cause problems.

For the first point, I just put it there since other Windows-only modules already exist there. _subprocess did, msvcrt and winreg currently do, and there's a few other Windows-only things in there. It's not a big deal, so I can move it into Modules if we want -- winreg and msvcrt should probably get moved as well (in another issue).

As for the name clash, I could shorten it to _win, but I'd rather not name it _win32. Microsoft got away from calling it the "Win32 API" and instead say "Windows API" now since it also covers 64-bit. It's just an internal name so I won't fight too hard on this.

I agree with Amaury that it would be better in Modules. In my experience, code that is in PC/ is a pain to discover.
A couple of nits about the patch:

• the functions in the PyMethodDef array could be sorted alphabetically
• the defint() macro isn't necessary, PyModule_AddIntMacro() should do the trick
• the "_win_handle_object" thing seems misguided, I would vote to remove it, and call CloseHandle() from Python code instead

PS: I don't think there's a problem with the "_windows" name, as long as wxPython doesn't depend on a *toplevel* module named "_windows".

I think there are some issues with the treatment of the DWORD type. (DWORD is a typedef for unsigned long.)

_subprocess always treats them as signed, whereas _multiprocessing treats them (correctly) as unsigned. _windows does a mixture: functions from _subprocess parse DWORD arguments as signed ("i"), functions from _multiprocessing parse DWORD arguments as unsigned ("k"), and the constants are signed.

So in _windows the constants GENERIC_READ, NMPWAIT_WAIT_FOREVER and INFINITE will be negative. I think this will potentially cause errors from PyArg_ParseTuple() when used as arguments to functions from _multiprocessing.

I think it is also rather confusing that some functions (eg CreatePipe()) return handles using a wrapper type which closes on garbage collection, while others (eg CreateNamedPipe()) return handles as plain integers.

(The code also needs updating because quite a few functions have since been added to _multiprocessing.win32.)

Attached is an up to date patch.

• code has been moved to Modules/_windows.c
• DWORD is uniformly treated as unsigned
• _subprocess's handle wrapper type has been removed (although
  subprocess.py still uses a Python implemented handle wrapper type)

I'm not familiar with Visual Studio. I ended up copying _socket.vcproj
to _windows.vcproj and editing it by hand. I also edited
_multiprocessing.vcproj and pythoncore.vcproj by hand.

I don't think we need the vcproj file, unless I missed something.

I don't think we need the vcproj file, unless I missed something.

_multiprocessing.win32 currently wraps closesocket(), send() and recv() so it needs to link against ws2_32.lib.

I don't know how to make _windows link against ws2_32.lib without adding a vcproj file for _windows unless we make pythoncore depend on ws2_32.lib. I presume this is why _socket and _select have their own vcproj files.

Maybe the socket functions could be moved directly to the top level of _multiprocessing instead since they are not really win32 functions. (And I suppose if that does not happen then _multiprocessing should also stop linking against ws2_32.lib.)

BTW why does _select link against wsock32.lib instead of ws2_32.lib?

It shouldn't. I noticed this and fixed this at CCP a while back but I wasn't in Python Committer mode at the time. _select needs fixing.

(fixed wsock32.lib in revision ab0aff639cfb)

New patch. Compared to the previous one:

• socket functions have been moved from _windows to _multiprocessing
• _windows.vcpoj has been removed (so _windows is part of pythoncore.vcproj)
• no changes to pcbuild.sln needed
• removed reference to 'win32_functions.c' in setup.py

(I am not sure whether/how setup.py is used on Windows.)

Lib/multiprocessing/connection.py | 124 +-
Lib/multiprocessing/forking.py | 31 +-
Lib/multiprocessing/heap.py | 6 +-
Lib/multiprocessing/reduction.py | 6 +-
Lib/subprocess.py | 104 +-
Lib/test/test_multiprocessing.py | 2 +-
Modules/_multiprocessing/multiprocessing.c | 83 +-
Modules/_multiprocessing/win32_functions.c | 823 ----------------
Modules/_windows.c | 1337 +++++++++++++++++++++++++++
PC/_subprocess.c | 697 --------------
PC/config.c | 6 +-
PCbuild/_multiprocessing.vcproj | 4 -
PCbuild/pythoncore.vcproj | 8 +-
setup.py | 1 -
14 files changed, 1568 insertions(+), 1664 deletions(-)

New patch. Compared to the previous one:

• socket functions have been moved from _windows to _multiprocessing
• _windows.vcpoj has been removed (so _windows is part of pythoncore.vcproj)
• no changes to pcbuild.sln needed
• removed reference to 'win32_functions.c' in setup.py

I think the module would be better named _win32, since that's the name
of the API (like POSIX under Unix).

Also, it seems there are a couple of naming inconsistencies renaming
(e.g. the overlapped wrapper is named
"_multiprocessing.win32.Overlapped")

Otherwise, I guess it's ok.

(I am not sure whether/how setup.py is used on Windows.)

Neither do I. It may be used under mingw or cygwin, but we don't
officially support these.

I think the module would be better named _win32, since that's the name
of the API (like POSIX under Unix).

Changed in new patch.

Also, it seems there are a couple of naming inconsistencies renaming
(e.g. the overlapped wrapper is named "_multiprocessing.win32.Overlapped")

I've fixed that one (and changed the initial comment at the beginning of _win32.c), but I can't see any other.

I also removed a duplicate of getulong().

pythoncore.vcproj)

> * no changes to pcbuild.sln needed
> * removed reference to 'win32_functions.c' in setup.py

I think the module would be better named _win32, since that's the name
of the API (like POSIX under Unix).

While there are many references to it being called Win32 API around the
web, at some point it became the Windows API.

at some point it became the Windows API.
You are right: http://en.wikipedia.org/wiki/Windows_API
How about _windowsapi or _winapi then, to ensure there are no clashes?

How about _windowsapi or _winapi then, to ensure there are no clashes?

I don't have any strong feelings, but I would prefer _winapi.

> How about _windowsapi or _winapi then, to ensure there are no clashes?

I don't have any strong feelings, but I would prefer _winapi.

Ditto here.

s/_win32/_winapi/g

sbt <shibturn@gmail.com> added the comment:

s/_win32/_winapi/g

Overlapped's naming is still lagging behind :-)

Other than that, a comment:

+ def Close(self):
+ if not self.closed:
+ self.closed = True
+ _winapi.CloseHandle(self)

Since Close() can be called at shutdown (through __del__), it should
probably cache its references to globals (because of the unpredictable
order of module cleanup), like this:

+ def Close(self, CloseHandle=_winapi.CloseHandle):
+ if not self.closed:
+ self.closed = True
+ CloseHandle(self)

Otherwise, looks good (I haven't tested).

Overlapped's naming is still lagging behind :-)

Argh. And a string in winapi_module too.

Yet another patch.

New changeset f3a27d11101a by Antoine Pitrou in branch 'default':
Issue bpo-11750: The Windows API functions scattered in the _subprocess and
http://hg.python.org/cpython/rev/f3a27d11101a

Thanks a lot for doing this! Patch now committed to 3.3 (after testing under Windows 7 64 bits).