Citeren Frédéric Bohé <[email protected]>:
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)
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
