Do you think it's a good idea to force Win2k compatibility by defining
WINVER 0x0500 in PC/pyconfig.h? It fixed the problem with Tcl/Tk, #1601.

http://msdn2.microsoft.com/en-us/library/aa383745.aspx

#define WINVER 0x0500
#define _WIN32_WINNT 0x0500

It's definitely not good to define it unconditionally in PC/pyconfig.h,
as that would affect any extensions compiled for Python.

I'm -0 on defining it conditionally for the compilation of Python
itself. I dislike having to constrain Python to Windows 2000; IMO,
windows version dependencies should be resolved at runtime. However,
that option is probably still available with WINVER set.

The macros don't restrain us to Win2k but they prevent us from using
APIs which are not compatible with Windows 2000. It's a compile time
option to conditionally exclude new features from the header files.

#ifndef NTDDI_VERSION
#define NTDDI_VERSION NTDDI_WIN2KSP4
#endif
#ifndef WINVER
#define WINVER 0x0500
#endif
#ifndef _WIN32_WINNT
#define _WIN32_WINNT WINVER
#endif

"The macros don't restrain us to Win2k but they prevent us from using
APIs which are not compatible with Windows 2000." --- That's what I
meant by "constrain"/restrain: we can't use API that was added in XP
directly. For functions, that is a good thing, because the binary
wouldn't work on W2k. For enumeration values and structure definition,
it's a bad thing, as we would need to duplicate them if we wanted to
call the functions dyanmically that take such values.

So what's the resolution here?

Georg Brandl wrote:
> So what's the resolution here?

We don't have a resolution yet. I may need the WINVER for the patch
#1763 but I've to investigate the patch before I can submit it.

Christian

I thought WINVER defaulted to something like 0x0400 (i.e. you can't use
things specifically defined for even Win2k without setting it, let alone
things first defined for XP).

I know I had to force it to 0x0500 recently for a non-Python project to
get access to the function that permits a non-blocking attempt to
acquire a critical section. That project is stuck using VC6 though -
current MS compilers may default it to something more recent.

I just checked the current PC/pyconfig.h: with the current settings in
that file, the core is already limited to using NT4 compatible Win32 API
calls. Unless the specific source file takes steps to override it (i.e.
setting WINVER before including python.h), no Win2k or XP API calls
should be permitted outside the 64-bit builds (as those only became
possible with the advent of 64-bit support in XP, they set WINVER to
0x0501).

The reason this didn't avoid the Tcl/Tk problem is because the actual
setting of WINVER and _WIN32_WINNT is guarded by the Py_BUILD_CORE
preprocessor definition - which isn't set for separately built extension
modules like _tkinter.

Would setting these by default for extension modules (i.e. removing the
Py_BUILD_CORE guard) really be such a bad thing? The individual #ifdef
guards would still be there to allow extension module authors to
override it if they know what they're doing, but the default behaviour
would be to require that extension modules be compatible with every
version of Windows that that particular version of Python is compatible
with.

The defaulting of WINVER is indeed a compiler things; the problems
started when we moved to VS 2008 (so VC6 would certainly have a
different default).

Setting WINVER for extension modules wouldn't have helped with the Tcl
problem: Tcl/Tk itself gets compiled independent of Python -
Py_BUILD_CORE had no effect here. It *does* have effect on _tkinter,
since _tkinter is part of Py_BUILD_CORE.

Setting WINVER for all extension modules would be bad style. Some
modules may fail to compile - it's up to the module author to decide
what API level to build against.

Given that whether or not Py_BUILD_CORE is defined flips the direction
of the DLL exports/import for the main python DLL, I don't see how it
could be defined for the separately compiled extension modules like
_tkinter, _sqlite3, _ctypes, _socket, _ssl, etc.

As far as I can tell (not having a VS2008 installation set up), that
means the build process for those other DLLs is currently going to be
using whatever setting for WINVER and _WIN32_WINNT the compiler decides
to provide.

Perhaps it would be worth having an additional Py_SET_WINVER definition
to make it easy for an extension module to request that Python set those
two values? And then set that for the modules that are part of the
normal Windows build?

> Given that whether or not Py_BUILD_CORE is defined flips the direction
> of the DLL exports/import for the main python DLL, I don't see how it
> could be defined for the separately compiled extension modules like
> _tkinter, _sqlite3, _ctypes, _socket, _ssl, etc.

You are right, it's not.

As you found, the original issue reported here could be closed:
WINVER *is* already defined in pyconfig.h. I'm still -1 for defining
it generally. So to define WINVER for the extension modules that
are part of the core, it would be best to define it in pyd.vsprops,
and pyd_d.vsprops, not in a header file.

Regards,
Martin

Martin v. Löwis wrote:
> As you found, the original issue reported here could be closed:
> WINVER *is* already defined in pyconfig.h. I'm still -1 for defining
> it generally. So to define WINVER for the extension modules that
> are part of the core, it would be best to define it in pyd.vsprops,
> and pyd_d.vsprops, not in a header file.

I require WINVER set to Win2k for patch #1763
(os.path.get_shellfolders()). The necessary API methods aren't declared
for the standard WINVER.

What do you think about a new macro Py_BUILD_CORE_MODULE for the pyd
property file?

#if defined(Py_BUILD_CORE) || defined(Py_BUILD_CORE_MODULE)
#define NTDDI_VERSION NTDDI_WIN2KSP4
#define WINVER 0x0500
#define _WIN32_WINNT WINVER
#endif

Nick Coghlan wrote:
> I know I had to force it to 0x0500 recently for a non-Python project to
> get access to the function that permits a non-blocking attempt to
> acquire a critical section. That project is stuck using VC6 though -
> current MS compilers may default it to something more recent.

I assume they don't. I wasn't able to access a Win2k+ API method with
VS2008.

Ah, so you propose raise WINVER, compared to what it is currently; I now
eventually understand this issue.

Raising it to 0x0500 is fine with me. Please add a note to PEP 11 that
NT 4 and older won't be supported anymore from 2.6 on. NT4 extended
support ended on 31.12.2004, so we probably don't need a phase with
advance warnings.

+1 on Py_BUILD_CORE_MODULE.

Applied in r60695 (trunk).

I've updated the PEP, too.