[issue1706] Force WINVER 0x0500 (Windows 2000)

Christian Heimes added the comment: Applied in r60695 (trunk). I've updated the PEP, too. -- resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1706] Force WINVER 0x0500 (Windows 2000)

Martin v. Löwis added the comment: 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 o

[issue1706] Force WINVER 0x0500 (Windows 2000)

Christian Heimes added the comment: 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 d

[issue1706] Force WINVER 0x0500 (Windows 2000)

Christian Heimes added the comment: 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 b

[issue1706] Force WINVER 0x0500 (Windows 2000)

Martin v. Löwis added the comment: > 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, e

[issue1706] Force WINVER 0x0500 (Windows 2000)

Nick Coghlan added the comment: 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

[issue1706] Force WINVER 0x0500 (Windows 2000)

Martin v. Löwis added the comment: 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 in

[issue1706] Force WINVER 0x0500 (Windows 2000)

Nick Coghlan added the comment: 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 Win

[issue1706] Force WINVER 0x0500 (Windows 2000)

Nick Coghlan added the comment: 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

[issue1706] Force WINVER 0x0500 (Windows 2000)

Changes by Nick Coghlan: __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python

[issue1706] Force WINVER 0x0500 (Windows 2000)

Christian Heimes added the comment: 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 __ Tracker <[EMAIL PROTECTED]>

[issue1706] Force WINVER 0x0500 (Windows 2000)

Georg Brandl added the comment: So what's the resolution here? -- nosy: +georg.brandl __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mai

[issue1706] Force WINVER 0x0500 (Windows 2000)

Martin v. Löwis added the comment: "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

[issue1706] Force WINVER 0x0500 (Windows 2000)

Christian Heimes added the comment: 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_WIN2

[issue1706] Force WINVER 0x0500 (Windows 2000)

Martin v. Löwis added the comment: 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,

[issue1706] Force WINVER 0x0500 (Windows 2000)

New submission from Christian Heimes: 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 ---