2011/3/24 Vincent Torri wrote:
> for wince, it's better to not compile Windows desktop stuff. I have attached
> one possible fix. There are other ways to do the same thing (at the
> beginning of the function: #ifdef _WIN32_WCE return return ARES_ENOTFOUND;
> #elif defined WIN32 etc...)
One thing is achieving compilability, and a different one is make
things actually work...
We have already said that that you are the Windows CE expert around here.
But googling a bit around I was capable of finding out that Windows CE
actually has a HOSTS file capability in its registry
(http://support.microsoft.com/kb/199370). So if you wish to make
c-ares work successfully on Windows CE you'll have to take that in
account.
Docs describing pertaining registry keys are in the "Host Name"
section of Windows CE "TCP/IPv4 Configurable Registry Settings"
(http://msdn.microsoft.com/en-us/library/ms884977.aspx).
You'll need to fully replace existing file_lookup() functions in
ares_gethostbyname.c and ares_gethostbyaddr.c with functions specific
for Windows CE, that opens HKEY_LOCAL_MACHINE\Comm\Tcpip\Hosts,
iterates over all existing hosts subkeys fetching info from 'Aliases',
'ipaddr', and 'ipaddr6' in order to compare them to further return
appropriate result.
> There is still the problem of getservbyport().
No more time here today to find out that info, but
We must be sure first wether the SERVICES file info is not available
at all in no place in no version of Windows CE. But, no more time here
today to find out that info.
> And I'm wondering what I
> should do for get_res_nt() in ares_init.c. I can write a similar function
> for Windows CE. Btw, on Windows, you should check if UNICODE is used or not
> for the functions RegEnumKeyEx() and al.
I don't have the need for it, an no one before has raised the UNICODE
issue regarding Windows registry keys for c-ares. In any case remember
that all strings used inside c-ares are c-style ANSI strings. So, if
Windows CE registry is UNICODE you'll have to convert them before
passing them to other functions.
> PS: I've added a small autotools patch too
> AM_CONFIG_HEADER([ares_config.h ares_build.h])
>+AC_CONFIG_MACRO_DIR([m4])
> AM_MAINTAINER_MODE
Given tha modern libtool versions barf if AC_CONFIG_MACRO_DIR is not
used even when Makefile.am properly defines ACLOCAL_AMFLAGS I've
committed next change to avoid breakage of old autoconf versions
https://github.com/bagder/c-ares/commit/e49ce8f97330789dc74d7e32d5d7b8828a7d557f
> AM_INIT_AUTOMAKE
>+m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
I'm against introducing AM_SILENT_RULES macro. I sincerly beleive it
should be dropped from automake.
-- -=[Yang]=-Received on 2011-03-25