Subject: Re: Leaked handles on Windows

Re: Leaked handles on Windows

From: Yang Tse <yangsita_at_gmail.com>
Date: Tue, 19 May 2009 13:11:20 +0200

2009/5/19, Vlad Dinulescu wrote:

> Yes, you are right. So just linking against iphlpapi.lib seems to be
> the best way after all.

Dynamic linking of iphlpapi allows the use of any version of PSDK or
WSDK to build c-ares and result in a library that works all the way up
from Win95 to the very last Version.

On the other, hand MS has already dropped Win9X support from newer
WSDK's, and the day will arrive they also drop support for W2K, this
means that if you want to build a c-ares library that can run on old
Windows versions you will need an old WSDK and an old VisualStudio
version in order to statically link iphlpapi.

Dynamic linking of iphlpapi allows building a Win32 c-ares library
even with compilers that have not yet cloned the iphlpapi.lib or that
will never do.

Dynamic linking of iphlpapi allows cross-compilation of a Win32 c-ares library.

Given all the above I have no option but to say that I'm against
static linking of iphlpapi in the officcial c-ares distribution as the
default option.

Even with all the above, if you feel that your specific interests are
better served with a statically linked iphlpapi maybe something could
be done that made that possible as an option.

I feel that you want the static linking of iphlpapi to simply avoid
calling ares_library_init() and ares_library_cleanup() and not have to
recompile your program.

Maybe for now, you could go that route but that would be something
specific to the c-ares dll you are building/distributing.

Once that ares_library_init() and ares_library_cleanup() exist, and
they already exist, nothing prevents c-ares from allowing the use of
third party crypto libraries for key generation.

-- 
-=[Yang]=-
Received on 2009-05-19