Since r60696, WINVER is forced to _WIN32_WINNT_WIN2K. This has two problems:
- Vs8 (and before) does not define _WIN32_WINNT_WIN2K. It should be
replaced with 0x500.
- When WINVER is set to 0x500, vc6 gives a long warning because at the
time, windows nt 5.0 was only at beta stage. Moreover, there are other
clashes between winsock.h and winsock2.h, that show up when WINVER is 0x500.

To correct this, I propose:
- To replace _WIN32_WINNT_WIN2K and similar constants by their values.
- That 0x500 is not the required value, but the *maximum* value
necessary when targeting win2k. VC6 can set it to 0x400.

I'll try a patch later tonight.

Attached a patch to compile trunk with vc6 and vs8.
Most tests pass with these two compilers.

Tests needed for vs7 and vs9!

Ithink this patch still conflicts with issue 1763 - SHGetFolderPathW is
(apparently) only available on W2k. So I don't see why we *shouldn't*
mandate W2k-or-better platform headers. VC6 users should install the W2k
SDK, or the W2k3 SDK (or any later SDK that still supports VC6).

Is it permitted to allow python compile with older compilers, even with
some functions missing?

This patch already skips some functions not included with VC6:
socket.ioctl, msvcrt.getwch &co.
Even socket.RCVALL_IPLEVEL is not available on my installation of VS8
(Professional Edition).

Even if the result is only a subset of the official python (as shown
when running the test suite), it may still be useful, when embedded in
legacy applications for example, where installing a new SDK is not
always possible.

> Is it permitted to allow python compile with older compilers, even with
> some functions missing?

It's certainly ok that Python may not have some functions on "some
system". Even though there might not be any precedence, I think this
extends to "some compilers on the same system".

Amaury Forgeot d'Arc wrote:
> Is it permitted to allow python compile with older compilers, even with
> some functions missing?

When a user compiles her own Python binary she is most probably
experienced enough to notice the difference. We can't hold the hand of
every user who strolls off the official path. New features was one of
reasons for the migration to VS 2008. Legacy support shouldn't stop us
from introducing new features.

So yes, it's permitted to build Python with old compilers but users must
not expect full support of all features.

Christian

I tried PSDK Feb 2003 downloadable from
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm
and this two issues went away.

>- When WINVER is set to 0x500, vc6 gives a long warning because at the
>time, windows nt 5.0 was only at beta stage. Moreover, there are other
>clashes between winsock.h and winsock2.h, that show up when WINVER is
>0x500.

Next, I tried to compile Modules/socketmodule.h's _MSC_VER >= 1300 part
but this didn't work.

#if _MSC_VER >= 1300
# include <winsock2.h>
# include <ws2tcpip.h>
# include <MSTcpIP.h> /* for SIO_RCVALL */
# define HAVE_ADDRINFO
# define HAVE_SOCKADDR_STORAGE
# define HAVE_GETADDRINFO
# define HAVE_GETNAMEINFO
# define ENABLE_IPV6
#else
# include <winsock.h>
#endif

I didn't investigate too much, but it seems
#include <windows.h>
#include <winsock2.h>
causes another conflicts between winsock.h and winsock2.h
this time.

> Next, I tried to compile Modules/socketmodule.h's _MSC_VER >= 1300 
> part but this didn't work.

Which compiler are you using? And which errors did you get?

>Which compiler are you using? And which errors did you get?

VC6 + PSDK2003Feb. The error was same to
http://svn.haxx.se/users/archive-2006-10/0557.shtml

E:\Microsoft\PSDK\Include\ws2tcpip.h(593) : error C2632: 'int'
followed by 'int' is illegal 

>causes another conflicts between winsock.h and winsock2.h
>this time.

This was not true. This error happened because pyconfig.h defines
socklen_t to int on VC6. I could fix this and build python with VC6 +
winsock2. Probably this is way to go. (Attached patch as ocean.zip)

regrtest.py passed other than test_float (this is because VC6 doesn't
support NaN comparation, I don't care)

# I'm still missing my 500MB disk space occupied by PSDK2003Feb though ;-)

Follow up r60882.

Failed to compile py3k again, created patch for
three branches. You can close issue1720 and issue1700463
because they are duplicated issues.

# I merged Amaury's patch, I hope this patch also
# works for VS8.

I don't know why, but
/D "MODULE_NAME=\"sqlite3\""
is troublesome. VC6 IDE expands this to
#define MODULE_NAME " sqlite3".

To workaround this, I used
/D MODULE_NAME=\"sqlite3\"
instead in sqlite3.dsp.

_wstat64 does not exist in VC6, so used GetFileAttributesW instead.

First, thank you for keeping these patches up to date.

- The patch for 2.5 is OK for me. We could just add the a paragraph that
appears in your patch for trunk (PC/VC6/readme.txt):
+_msi
+    _msi.c. You need to install Windows Installer SDK to build this module.

- I worked on your patch for trunk/ and py3k/ to allow compilation with
a stock VC6 *without* a modern PlatformSDK installed (i.e NTDDI_VERSION
is not defined)
This is relevant only for socketmodule; with a stock VC6, IPV6 is not
available, WSAIoctl is not exposed, and getaddrinfo() is emulated.

- Replacing _wstat with GetFileAttributesW is good thing: stat("nul")
says that the file exists!
But it is not enough: try to "import con" or "import nul", before and
after your patch. Fun in both cases (if you "import con", type some
chars, and press ^Z)

- The patches also work for VS8.0 (I just had to update the list of .c)

I will try to come with updated files, and test them with VS2003 Express
(VS7.1).

Thank you for progress!

>- The patch for 2.5 is OK for me. We could just add the a paragraph that
>appears in your patch for trunk (PC/VC6/readme.txt):
>+_msi
>+    _msi.c. You need to install Windows Installer SDK to build this
>module.

I agree.

>- I worked on your patch for trunk/ and py3k/ to allow compilation with
>a stock VC6 *without* a modern PlatformSDK installed (i.e NTDDI_VERSION
>is not defined)
>This is relevant only for socketmodule; with a stock VC6, IPV6 is not
>available, WSAIoctl is not exposed, and getaddrinfo() is emulated.

I'm not sure which is better way now. (with or without modern PSDK)
From cleaness of code, I think with modern PSDK is better.
http://archives.devshed.com/forums/development-94/error-building-python-bindings-with-ms-visual-c-6-0t-2074150.html
show subversion already seems to require modern PSDK to build it, if 
python uses modern PSDK and winsock2, workaround for socklen_t is not
needed anymore. clean. (this workaround itself is quite easy though)
Of cause, Amaury wants to go without modern PSDK, there is no strong
reason I will disturb it.

>- Replacing _wstat with GetFileAttributesW is good thing: stat("nul")
>says that the file exists!
>But it is not enough: try to "import con" or "import nul", before and
>after your patch. Fun in both cases (if you "import con", type some
>chars, and press ^Z)

Interesting. Current release25-maint branch has same issue, but
python2.5.2 doesn't have this issue. "import con" fails with following
message. Something changed from latest release?

>>> import con
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: 指定されたモジュールが見つかりません。

# It says "specified module cannot be found" in Japanese. Maybe is this
win32 error message via FormatMessage()?

I just committed r64214, that can compile with vc6.
When compiled with a separate SDK, socket.ioctl is available.
With the stock vc6, the function is disabled

Committed r64215 on py3k branch.
Now both trunk and py3k compile with VC6, VS8 and VS9.
I cannot run VS7.1; I will do 2.5 shortly.

I also filed issue3099 about the funny "import nul".

Thank you for commit. I ziped patch for remaining issue.
# Probably need to add _multiprocessing module, but not done yet.

> Probably need to add _multiprocessing module, but not done yet.

Yes, and I also forgot to "svn add" the new .vcproj in VS8.0 :-(

I have committed remaining VC6 patch. (I postponed _multiprocessing
module support addition because I sometimes experiences nasty error
message "pipe was closed" or "resource is not enough" in
test_multiprocessing. I cannot reproduce it by simply running only
test_multiprocessing, it occurs in regrtest. :-(

Can I close this entry?

Sure. Feel free to commit any further changes to these build files directly.