On Fri, Mar 25, 2011 at 7:06 PM, Yang Tse <yangsita_at_gmail.com> wrote:
> 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...
>
on the other hand, if it does not compile, i really doubt i could one day
make c-ares working on a Windows CE device... My first aim is to make it
compile while taking note about what has to be fixed later.
>
> We have already said that that you are the Windows CE expert around here.
>
expert... You should better say that i'm probably the most experienced user
of Windows CE compared to other c-ares developers / users as there are not
one Windows CE developer / user on that ML :-)
>
> 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).
>
>
I searched a lot before sending my previous mail. I even looked at
PocketPutty source code... (
http://teamforge.net/viewvc/viewvc.cgi/pocketputty/). But it seems that my
search keywords were not good.
> 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.
>
Ok, I'll try to write a patch. Thanks for the link.
>
> > 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.
>
I'll try to ask that on Windows CE forums. I found some.
>
> > 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.
Not only registry functions. A lot of functions of the win32 API (mainly
when a string is passed as a parameter of the function) have 2 versions of
the function. An "ANSI" one (with suffix 'A') and a unicode one (with suffix
'W'). For example, see
http://msdn.microsoft.com/en-us/library/ms724862%28VS.85%29.aspx
At the end, in the 'Requirement' section:
Unicode and ANSI names* RegEnumKeyExW* (Unicode) and *RegEnumKeyExA* (ANSI)
By default:
* with mingw, UNICODE macro is not defined, hence the ANSI version of the
functions is used
* with Visual Studio, UNICODE macro is defined, hence the UNICODE version
of the functions is used
* with cegcc, UNICODE macro is defined, hence the UNICODE version of the
functions is used
I don't know if c-ares provides Visual Studio solutions and projects, but
that must be taken into account. In my Windows port of some libraries, I
have 2 conversion functions Multibyte <---> Wide Characters to deal with
that.
In the project i'm involed in, i decided to have no UNICODE support at all
for Windows XP and above, and only UNICODE support for Windows CE.
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.
>
yes, i know that :-) Here is what i wrote:
http://trac.enlightenment.org/e/browser/trunk/PROTO/evil/src/lib/evil_util.c#L18
in case it interests you.
>
> > 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
>
I understand now why the autotools don't behave as usual with your project
if you override their macros :-)
Vincent Torri
Received on 2011-03-25