Frédéric Bohé
2010-Nov-04 10:53 UTC
[Nut-upsdev] [nut-commits] svn commit r2600 - in trunk: . clients common docs m4 server
On mer., 2010-10-20 at 20:45 +0000, Arjen de Korte wrote:> Author: adkorte-guest > Date: Wed Oct 20 20:45:01 2010 > New Revision: 2600 > URL: http://trac.networkupstools.org/projects/nut/changeset/2600 > > Log: > Remove code that used the (now obsoleted) gethostbyaddr in favor of the (IPv6 capable) getaddrinfo functionArjen, I am trying to merge the windows_port branch with trunk and I have some issues. First, getaddrinfo seems to be supported on Win32 platforms only since Windows XP. So I can compile binaries for Win32 but we will loose Win NT/2000/98 compatibility here. Second, it seems that inet_ntop is supported only since Windows Vista. Which remove Windows XP from the compatibility list. Of course we can try to provide equivalent functions but is this commit really worth the extra work ? Moreover, what will be the impact of this commit on other old systems ? Maybe we could simply revert this commit to avoid breakage. Regards, Fred --------------------------------------------------------------------------
Arjen de Korte
2010-Nov-04 12:03 UTC
[Nut-upsdev] [nut-commits] svn commit r2600 - in trunk: . clients common docs m4 server
Citeren Fr?d?ric Boh? <fredericbohe op eaton.com>:> I am trying to merge the windows_port branch with trunk and I have some > issues.I'm not sure if that's a good idea at the moment. If I'm not mistaken, we're about to release a new stable version soon.> First, getaddrinfo seems to be supported on Win32 platforms only since > Windows XP. So I can compile binaries for Win32 but we will loose Win > NT/2000/98 compatibility here.Windows NT and 98 is declared 'out of support' by Microsoft, so I don't think it makes sense to try to support those anymore. I don't think it is too much too ask that people run a somewhat recent version of Windows anyway (until now, we have not supported Windows at all). Windows 2000 does support getaddrinfo if you include the proper headers. According to the MSDN: "Support for getaddrinfo on Windows 2000 and older versions The getaddrinfo function was added to the Ws2_32.dll on Windows XP and later. To execute an application that uses this function on earlier versions of Windows, then you need to include the Ws2tcpip.h and Wspiapi.h files. When the Wspiapi.h include file is added, the getaddrinfo function is defined to the WspiapiGetAddrInfo inline function in the Wspiapi.h file. At runtime, the WspiapiGetAddrInfo function is implemented in such a way that if the Ws2_32.dll or the Wship6.dll (the file containing getaddrinfo in the IPv6 Technology Preview for Windows 2000) does not include getaddrinfo, then a version of getaddrinfo is implemented inline based on code in the Wspiapi.h header file. This inline code will be used on older Windows platforms that do not natively support the getaddrinfo function."> Second, it seems that inet_ntop is supported only since Windows Vista. > Which remove Windows XP from the compatibility list.Not at all. Even Windows 2000 has functions to get a human readable address, it's just not called inet_ntop.> Of course we can try to provide equivalent functions but is this commit > really worth the extra work ?Absolutely.> Moreover, what will be the impact of this commit on other old systems ?None. Both functions have been available since almost a decade on *NIX systems. In order to support IPv6, it is mandatory to use them. There is no excuse to write IPv4-only code anymore since in growing number of regions people have no alternatives but to use IPv6.> Maybe we could simply revert this commit to avoid breakage.No. It wouldn't relieve you of writing IPv6 compatible versions for Windows XP and Windows 2000. I would not be surprised if the majority of people still running older versions of Windows (pre-Vista) live in regions where IPv6 is common. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected)