[Python-Dev] Handling support for newer OS features at run time

[Trent Nelson]

    The hackiest part of my WSAPoll patch is this:

--- a/PC/pyconfig.h     Sun Nov 18 10:42:42 2012 +0000
+++ b/PC/pyconfig.h     Sun Nov 18 17:27:29 2012 -0500
@@ -158,12 +158,12 @@
 /* set the version macros for the windows headers */
 #ifdef MS_WINX64
 /* 64 bit only runs on XP or greater */
-#define Py_WINVER 0x0501 /* _WIN32_WINNT_WINXP */
-#define Py_NTDDI NTDDI_WINXP
+#define Py_WINVER 0x0600 /* _WIN32_WINNT_WINXP */
+#define Py_NTDDI NTDDI_WIN6
 #else
 /* Python 2.6+ requires Windows 2000 or greater */
-#define Py_WINVER 0x0500 /* _WIN32_WINNT_WIN2K */
-#define Py_NTDDI NTDDI_WIN2KSP4
+#define Py_WINVER 0x0600 /* _WIN32_WINNT_WIN2K */
+#define Py_NTDDI NTDDI_WIN6
 #endif

    Basically, because of the way our build is currently configured, I
    had to bump the minimum supported Windows version from XP to Vista
    just to get access to the WSAPoll headers.

        (Issue: http://bugs.python.org/issue16507
         Patch: http://bugs.python.org/file28038/wsapoll.patch)

    Ideally, a Windows binary should make WSAPoll/select.poll()
    available if running on Vista or above, without impacting
    the ability to run on XP.

    I don't think we've currently got the ability to do this, right?
    Is there a precedent set anywhere else?  I suspect it's not as
    much of an issue on *NIX platforms as you'll typically compile
    from source.  Windows, not so much.

    Thoughts?  A single binary that dynamically loads applicable
    modules seems cleaner but will obviously take more work.  Other
    approach would be to start distributing multiple versions of
    Python based on the underlying Windows version.  Not the nicest
    approach.

        Trent.