[Nut-upsdev] [nut-commits] svn commit r2600 - in trunk: . clients common docs m4 server

[Arjen de Korte]

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)