Thread: Vista/IPv6
On Windows Vista, IPv6 is enabled by default, and cannot be uninstalled, or disabled easily on the loopback adaptor. localhost is ::1 by default, and the enhanced 'security' makes it insanely difficult to edit the hosts file. This means that the regression tests fail to run, leaving a postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. Should we have initdb enable the ::1 pg_hba.conf trust entry by default on Vista? Any better options? Regards Dave
Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: > This means that the regression tests fail to run, leaving a > postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. > Should we have initdb enable the ::1 pg_hba.conf trust entry by default > on Vista? Any better options? The default installation has that. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: > >> This means that the regression tests fail to run, leaving a >> postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. >> Should we have initdb enable the ::1 pg_hba.conf trust entry by default >> on Vista? Any better options? >> > > The default installation has that. > > ... as long as it's present and turned on on the build machine. cheers andrew
On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote: > Peter Eisentraut wrote: > >Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: > > > >>This means that the regression tests fail to run, leaving a > >>postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. > >>Should we have initdb enable the ::1 pg_hba.conf trust entry by default > >>on Vista? Any better options? > >> > > > >The default installation has that. > > > > > > ... as long as it's present and turned on on the build machine. Let me pre-emt the discussion by saying that the msvc build does not detect ipv6 on the build machine (yet). Are you building with msvc or mingw on this machine? //Magnus
Andrew Dunstan wrote: > Peter Eisentraut wrote: >> Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: >> >>> This means that the regression tests fail to run, leaving a >>> postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. >>> Should we have initdb enable the ::1 pg_hba.conf trust entry by default >>> on Vista? Any better options? >>> >> >> The default installation has that. >> >> > > ... as long as it's present and turned on on the build machine. Something is broken then, because it clearly is turned on, yet the pg_hba.conf entry is commented out - hence my report. I assume it's initdb that's doing the check? Regards, Dave.
Magnus Hagander wrote: > On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote: >> Peter Eisentraut wrote: >>> Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: >>> >>>> This means that the regression tests fail to run, leaving a >>>> postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. >>>> Should we have initdb enable the ::1 pg_hba.conf trust entry by default >>>> on Vista? Any better options? >>>> >>> The default installation has that. >>> >>> >> ... as long as it's present and turned on on the build machine. > > Let me pre-emt the discussion by saying that the msvc build does not detect > ipv6 on the build machine (yet). Are you building with msvc or mingw on > this machine? msvc. Grrr. Eta to fix? Regards, Dave.
On Wed, Apr 11, 2007 at 03:33:21PM +0100, Dave Page wrote: > Magnus Hagander wrote: > > On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote: > >> Peter Eisentraut wrote: > >>> Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: > >>> > >>>> This means that the regression tests fail to run, leaving a > >>>> postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. > >>>> Should we have initdb enable the ::1 pg_hba.conf trust entry by default > >>>> on Vista? Any better options? > >>>> > >>> The default installation has that. > >>> > >>> > >> ... as long as it's present and turned on on the build machine. > > > > Let me pre-emt the discussion by saying that the msvc build does not detect > > ipv6 on the build machine (yet). Are you building with msvc or mingw on > > this machine? > > msvc. Grrr. > > Eta to fix? Eh. None, so far :-) Point being - if you build on a ipv6 enabled machine, will that binary then work at all on a non-ipv6 machine? Consider binaries distributed by the installer... Might as well think up the proper fix before we just band-aid it for the regression tests.. //Magnus
Magnus Hagander wrote: > On Wed, Apr 11, 2007 at 03:33:21PM +0100, Dave Page wrote: > >> Magnus Hagander wrote: >> >>> On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote: >>> >>>> Peter Eisentraut wrote: >>>> >>>>> Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: >>>>> >>>>> >>>>>> This means that the regression tests fail to run, leaving a >>>>>> postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. >>>>>> Should we have initdb enable the ::1 pg_hba.conf trust entry by default >>>>>> on Vista? Any better options? >>>>>> >>>>>> >>>>> The default installation has that. >>>>> >>>>> >>>>> >>>> ... as long as it's present and turned on on the build machine. >>>> >>> Let me pre-emt the discussion by saying that the msvc build does not detect >>> ipv6 on the build machine (yet). Are you building with msvc or mingw on >>> this machine? >>> >> msvc. Grrr. >> >> Eta to fix? >> > > Eh. None, so far :-) > Point being - if you build on a ipv6 enabled machine, will that binary then > work at all on a non-ipv6 machine? Consider binaries distributed by the > installer... Might as well think up the proper fix before we just band-aid > it for the regression tests.. > > Yes, it should. This was all tested back when we fixed Windows ipv6, around 8.1 timeframe. Look at the source of initdb and you'll see how it works. cheers andrew
Am Mittwoch, 11. April 2007 16:46 schrieb Magnus Hagander:
> Point being - if you build on a ipv6 enabled machine, will that binary then
> work at all on a non-ipv6 machine? Consider binaries distributed by the
> installer... Might as well think up the proper fix before we just band-aid
> it for the regression tests..
The check is done by initdb (not on the build machine) and it checks if
getaddrinfo("::1", ...) works. If that doesn't work then you don't have IPv6
for all practical purposes. So everything seems to be set up all right.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
> Am Mittwoch, 11. April 2007 16:46 schrieb Magnus Hagander:
>
>> Point being - if you build on a ipv6 enabled machine, will that binary then
>> work at all on a non-ipv6 machine? Consider binaries distributed by the
>> installer... Might as well think up the proper fix before we just band-aid
>> it for the regression tests..
>>
>
> The check is done by initdb (not on the build machine) and it checks if
> getaddrinfo("::1", ...) works. If that doesn't work then you don't have IPv6
> for all practical purposes. So everything seems to be set up all right.
>
>
There is a configure time and a runtime check. The code is below - note
the first #ifdef.
cheers
andrew
#ifdef HAVE_IPV6
/* * Probe to see if there is really any platform support for IPv6, and * comment out the relevant pg_hba line
ifnot. This avoids runtime * warnings if getaddrinfo doesn't actually cope with IPv6.
Particularly * useful on Windows, where executables built on a machine with IPv6 may * have to run on a machine
without. */ { struct addrinfo *gai_result; struct addrinfo hints; int err = 0;
#ifdef WIN32 /* need to call WSAStartup before calling getaddrinfo */ WSADATA wsaData;
err = WSAStartup(MAKEWORD(2, 2), &wsaData);
#endif
/* for best results, this code should match parse_hba() */ hints.ai_flags = AI_NUMERICHOST;
hints.ai_family= PF_UNSPEC; hints.ai_socktype = 0; hints.ai_protocol = 0; hints.ai_addrlen = 0;
hints.ai_canonname= NULL; hints.ai_addr = NULL; hints.ai_next = NULL;
if (err != 0 || getaddrinfo("::1", NULL, &hints, &gai_result) != 0) conflines =
replace_token(conflines, "host all all ::1",
"#host all all
::1"); }
#else /* !HAVE_IPV6 */ /* If we didn't compile IPV6 support at all, always comment it out
*/ conflines = replace_token(conflines, "host all all ::1",
"#host all all ::1");
#endif /* HAVE_IPV6 */
Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: > There is a configure time and a runtime check. The code is below - note > the first #ifdef. Yeah, the problem is that the msvc build has no intelligence to detect the IPv6 APIs to define HAVE_IPV6. So that needs to be developed. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: > >> There is a configure time and a runtime check. The code is below - note >> the first #ifdef. >> > > Yeah, the problem is that the msvc build has no intelligence to detect the > IPv6 APIs to define HAVE_IPV6. So that needs to be developed. > > The configure test just looks for a definition of struct sockaddr_in6. Taking a quick look It seems to me like this is unconditionally there in the MSVC WS2tcpip.h , so maybe we should just force it for MSVC. cheers andrew
On Wed, Apr 11, 2007 at 02:03:11PM -0400, Andrew Dunstan wrote: > Peter Eisentraut wrote: > >Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: > > > >>There is a configure time and a runtime check. The code is below - note > >>the first #ifdef. > >> > > > >Yeah, the problem is that the msvc build has no intelligence to detect the > >IPv6 APIs to define HAVE_IPV6. So that needs to be developed. > > > > > > The configure test just looks for a definition of struct sockaddr_in6. > Taking a quick look It seems to me like this is unconditionally there in > the MSVC WS2tcpip.h , so maybe we should just force it for MSVC. That was my question. I just built with ipv6 enabled using my msvc build on my primary machine which does *not* have ipv6, and it still passes regression tests fine. Given that we have a runtime check, is there any reason at all not to enable ipv6 on all builds on msvc? (FWIW, it's been in the platform SDK at least since Windows 2000) //Magnus
Magnus Hagander wrote: > On Wed, Apr 11, 2007 at 02:03:11PM -0400, Andrew Dunstan wrote: > >> Peter Eisentraut wrote: >> >>> Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: >>> >>> >>>> There is a configure time and a runtime check. The code is below - note >>>> the first #ifdef. >>>> >>>> >>> Yeah, the problem is that the msvc build has no intelligence to detect the >>> IPv6 APIs to define HAVE_IPV6. So that needs to be developed. >>> >>> >>> >> The configure test just looks for a definition of struct sockaddr_in6. >> Taking a quick look It seems to me like this is unconditionally there in >> the MSVC WS2tcpip.h , so maybe we should just force it for MSVC. >> > > That was my question. I just built with ipv6 enabled using my msvc build on > my primary machine which does *not* have ipv6, and it still passes > regression tests fine. > > Given that we have a runtime check, is there any reason at all not to > enable ipv6 on all builds on msvc? > > (FWIW, it's been in the platform SDK at least since Windows 2000) > > If we could use configure for MSVC this would have Just Happened (tm). I wonder how many other little bits we miss out on? Anyway, the obvious fix seems to be to add a line to src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h cheers andrew
On Wed, Apr 11, 2007 at 02:24:08PM -0400, Andrew Dunstan wrote: > Magnus Hagander wrote: > >On Wed, Apr 11, 2007 at 02:03:11PM -0400, Andrew Dunstan wrote: > > > >>Peter Eisentraut wrote: > >> > >>>Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: > >>> > >>> > >>>>There is a configure time and a runtime check. The code is below - note > >>>>the first #ifdef. > >>>> > >>>> > >>>Yeah, the problem is that the msvc build has no intelligence to detect > >>>the IPv6 APIs to define HAVE_IPV6. So that needs to be developed. > >>> > >>> > >>> > >>The configure test just looks for a definition of struct sockaddr_in6. > >>Taking a quick look It seems to me like this is unconditionally there in > >>the MSVC WS2tcpip.h , so maybe we should just force it for MSVC. > >> > > > >That was my question. I just built with ipv6 enabled using my msvc build on > >my primary machine which does *not* have ipv6, and it still passes > >regression tests fine. > > > >Given that we have a runtime check, is there any reason at all not to > >enable ipv6 on all builds on msvc? > > > >(FWIW, it's been in the platform SDK at least since Windows 2000) > > > > > > If we could use configure for MSVC this would have Just Happened (tm). I > wonder how many other little bits we miss out on? Well, if you can make that happen, certainly that'd be nice... (FWIW, I had ipv6 on my list of things to make happen, but I didn't realise it would cause this issue on a machine with ipv6 on it, since I don't have one) > Anyway, the obvious fix seems to be to add a line to > src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h Won't work, that hits both msvc and mingw. (assuming you maen pg_config.h.win32, since pg_config.h is a generated file) The proper fix is to put it in the msvc build sys, where it writes pg_config.h :-) It also needs a new lib for initdb. I have a patch for it, and it works here, I'm just asking if it's safe to enable it or if it may cause runtmie problems on platforms without ipv6. //Magnus
Magnus Hagander wrote: > >> Anyway, the obvious fix seems to be to add a line to >> src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h >> > > Won't work, that hits both msvc and mingw. (assuming you maen > pg_config.h.win32, since pg_config.h is a generated file) > > The proper fix is to put it in the msvc build sys, where it writes > pg_config.h :-) Is that not what I suggested? > It also needs a new lib for initdb. I have a patch > for it, and it works here, I'm just asking if it's safe to enable it or if > it may cause runtmie problems on platforms without ipv6. > > Which new lib? That seems odd since what we do on MinGW does work. cheers andrew
Andrew Dunstan wrote: > Magnus Hagander wrote: >> >>> Anyway, the obvious fix seems to be to add a line to >>> src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h >>> >> >> Won't work, that hits both msvc and mingw. (assuming you maen >> pg_config.h.win32, since pg_config.h is a generated file) >> >> The proper fix is to put it in the msvc build sys, where it writes >> pg_config.h :-) > > Is that not what I suggested? I thought you meant put it in the actual .h file that is used to generate pg_config.h from. Apologies for my misunderstanding. >> It also needs a new lib for initdb. I have a patch >> for it, and it works here, I'm just asking if it's safe to enable it >> or if >> it may cause runtmie problems on platforms without ipv6. >> >> > > Which new lib? That seems odd since what we do on MinGW does work. The winsock libs. Our mingw build links them explicitly to all binaries, the msvc build only links it to the ones that actually need it. And with ipv6 support, initdb suddenly needs it. //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> The proper fix is to put it in the msvc build sys, where it writes
> pg_config.h :-) It also needs a new lib for initdb. I have a patch
> for it, and it works here, I'm just asking if it's safe to enable it or if
> it may cause runtmie problems on platforms without ipv6.
Try it and find out ;-) ... that's what we have a buildfarm for.
regards, tom lane
Magnus Hagander wrote: > (FWIW, I had ipv6 on my list of things to make happen, but I didn't > realise it would cause this issue on a machine with ipv6 on it, since > I don't have one) The IPv6 support is finely tuned to deal with all kinds of combinations of API support, library support, and kernel support, or lack thereof, on the build system and on the host system. I suggest that you just use the logic that we have or emulate it, respectively. If it doesn't work, we will find out soon enough. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > >> The proper fix is to put it in the msvc build sys, where it writes >> pg_config.h :-) It also needs a new lib for initdb. I have a patch >> for it, and it works here, I'm just asking if it's safe to enable it or if >> it may cause runtmie problems on platforms without ipv6. >> > > Try it and find out ;-) ... that's what we have a buildfarm for. > > Well, on the buildfarm the build host is the test host, so that doesn't quite take care of Magnus' concern. But that said, I do think it will probably Just Work - we did a lot of work during 8.1 to make sure it would, and I see no reason yet to think that work won't apply. cheers andrew
On Wednesday 11 April 2007 12:24, Andrew Dunstan wrote: > If we could use configure for MSVC this would have Just Happened (tm). I > wonder how many other little bits we miss out on? CMake anyone? wt -- Warren Turkal (w00t)
On Wed, Apr 11, 2007 at 11:06:12PM -0600, Warren Turkal wrote: > On Wednesday 11 April 2007 12:24, Andrew Dunstan wrote: > > If we could use configure for MSVC this would have Just Happened (tm). I > > wonder how many other little bits we miss out on? > > CMake anyone? IIRC, cmake is a replacement for make, not for configure. Or did I miss something? And it would require rewriting all the unix makefiles in cmake format, and it was one of the major requirements for this undertaking that this would not be required. //Magnus
On Thu, Apr 12, 2007 at 12:24:58AM +0200, Peter Eisentraut wrote: > Magnus Hagander wrote: > > (FWIW, I had ipv6 on my list of things to make happen, but I didn't > > realise it would cause this issue on a machine with ipv6 on it, since > > I don't have one) > > The IPv6 support is finely tuned to deal with all kinds of combinations > of API support, library support, and kernel support, or lack thereof, > on the build system and on the host system. I suggest that you just > use the logic that we have or emulate it, respectively. If it doesn't > work, we will find out soon enough. The point is still what happens when you distribute a binary built on a system with ipv6 to a system that doesn't have it. Anyway. It seems reasonably safe, since I can build with ipv6 on my machine without the ipv6 driver, and it still works. Dave will have to test if it actually works on a machine that *has* ipv6 :-) So. Changes applied. //Magnus
Magnus Hagander wrote: > On Thu, Apr 12, 2007 at 12:24:58AM +0200, Peter Eisentraut wrote: >> Magnus Hagander wrote: >>> (FWIW, I had ipv6 on my list of things to make happen, but I didn't >>> realise it would cause this issue on a machine with ipv6 on it, since >>> I don't have one) >> The IPv6 support is finely tuned to deal with all kinds of combinations >> of API support, library support, and kernel support, or lack thereof, >> on the build system and on the host system. I suggest that you just >> use the logic that we have or emulate it, respectively. If it doesn't >> work, we will find out soon enough. > > The point is still what happens when you distribute a binary built on a > system with ipv6 to a system that doesn't have it. > > Anyway. It seems reasonably safe, since I can build with ipv6 on my machine > without the ipv6 driver, and it still works. Dave will have to test if it > actually works on a machine that *has* ipv6 :-) > > So. Changes applied. Thanks - I can test a Vista build on a non-ipv6 machine when I'm back in the office - possibly tomorrow, certainly Monday. Regards, Dave
Hi. From: "Dave Page" <dpage@postgresql.org> >> So. Changes applied. Umm, I think that you should correspond here. It seems to have been left. I remember it. src/include/pg_config.h.win32 /* Define to 1 if you have support for IPv6. */ // #define HAVE_IPV6 1 What do you think? Regards, Hiroshi Saito > > Thanks - I can test a Vista build on a non-ipv6 machine when I'm back in > the office - possibly tomorrow, certainly Monday. > > Regards, Dave
Am Donnerstag, 12. April 2007 09:04 schrieb Magnus Hagander: > The point is still what happens when you distribute a binary built on a > system with ipv6 to a system that doesn't have it. I think the problem is that you appear to have an ambiguous and overly coarse definition of a "system with ipv6". -- Peter Eisentraut http://developer.postgresql.org/~petere/
Am Donnerstag, 12. April 2007 08:56 schrieb Magnus Hagander: > IIRC, cmake is a replacement for make, not for configure. Or did I miss > something? CMake might be considered a replacement for Automake. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Thu, Apr 12, 2007 at 10:58:26AM +0200, Peter Eisentraut wrote: > Am Donnerstag, 12. April 2007 09:04 schrieb Magnus Hagander: > > The point is still what happens when you distribute a binary built on a > > system with ipv6 to a system that doesn't have it. > > I think the problem is that you appear to have an ambiguous and overly coarse > definition of a "system with ipv6". Possibly :-) I just want to make sure it doesn't break for our end users, no matter what the definition is. //Magnus
On Thu, Apr 12, 2007 at 05:14:06PM +0900, Hiroshi Saito wrote: > Hi. > > From: "Dave Page" <dpage@postgresql.org> > > >>So. Changes applied. > > Umm, I think that you should correspond here. > It seems to have been left. I remember it. > > src/include/pg_config.h.win32 > /* Define to 1 if you have support for IPv6. */ > // #define HAVE_IPV6 1 > > What do you think? It's defined ni the msvc build script, see http://archives.postgresql.org/pgsql-committers/2007-04/msg00148.php //Magnus
>> src/include/pg_config.h.win32 >> /* Define to 1 if you have support for IPv6. */ >> // #define HAVE_IPV6 1 >> >> What do you think? > > It's defined ni the msvc build script, see > http://archives.postgresql.org/pgsql-committers/2007-04/msg00148.php It is a meaning with win32.mak. Then, It is the outside of the msvc tool. Regards, Hiroshi Saito
On Thursday 12 April 2007 00:56, you wrote: > IIRC, cmake is a replacement for make, not for configure. Or did I miss > something? CMake also has configure functionality. > And it would require rewriting all the unix makefiles in cmake format, > and it was one of the major requirements for this undertaking that this > would not be required. The CMakeLists.txt files can coexist with the current Makefiles. You could just do out of tree builds to keep from overwriting the original Makefiles during the generation. Of course, generating MSVC project files wouldn't overwrite the Makefiles in any case. wt -- Warren Turkal (w00t)
On Fri, Apr 13, 2007 at 12:44:41AM -0600, Warren Turkal wrote: > On Thursday 12 April 2007 00:56, you wrote: > > IIRC, cmake is a replacement for make, not for configure. Or did I miss > > something? > > CMake also has configure functionality. > > > And it would require rewriting all the unix makefiles in cmake format, > > and it was one of the major requirements for this undertaking that this > > would not be required. > > The CMakeLists.txt files can coexist with the current Makefiles. You could > just do out of tree builds to keep from overwriting the original Makefiles > during the generation. Of course, generating MSVC project files wouldn't > overwrite the Makefiles in any case. That would mean maintainig two sets of build files. That's never going to work. The only option if we were to go with that is, IMHO, to move *everything* over to it. And I don't think you'll get a lot of people supporting that ;) //Magnus
On Thu, Apr 12, 2007 at 08:46:09PM +0900, Hiroshi Saito wrote: > >>src/include/pg_config.h.win32 > >>/* Define to 1 if you have support for IPv6. */ > >>// #define HAVE_IPV6 1 > >> > >>What do you think? > > > >It's defined ni the msvc build script, see > >http://archives.postgresql.org/pgsql-committers/2007-04/msg00148.php > > It is a meaning with win32.mak. Then, It is the outside of the msvc tool. I see. But - does it work when build with MSVC6? IIRC, MSVC6 pre-dates windows 2000 and the windows IPV6 support. Can you verify that it works if you manually add this #define and build with MSVC6? //Magnus
Hi. From: "Magnus Hagander" <magnus@hagander.net> > I see. > > But - does it work when build with MSVC6? IIRC, MSVC6 pre-dates windows > 2000 and the windows IPV6 support. > > Can you verify that it works if you manually add this #define and build > with MSVC6? I don't have IPV6 test environment recently.... However, It has the compile environment of VC6, and it is finished finely. Then, win32.mak is not the thing of only VC6. And VC 7.1, VC8, and they will be used. It should be then supported IPV6 at least. What confirmed #DEFINE of IPV6 and built it by VC6 has passed the test of IPV4 further again. Therefore, you should make it effective. Regards, Hiroshi Saito
Hiroshi Saito wrote: > Hi. > > From: "Magnus Hagander" <magnus@hagander.net> > >> I see. >> >> But - does it work when build with MSVC6? IIRC, MSVC6 pre-dates windows >> 2000 and the windows IPV6 support. >> >> Can you verify that it works if you manually add this #define and build >> with MSVC6? > > I don't have IPV6 test environment recently.... However, It has the > compile environment of VC6, and it is finished finely. Then, win32.mak > is not the thing of only VC6. And VC 7.1, VC8, and they will be used. It > should be then supported IPV6 at least. > What confirmed #DEFINE of IPV6 and built it by VC6 has passed the test > of IPV4 further again. Therefore, you should make it effective. I have applied a change for this. //Magnus