IPHLPAPI.DLL issues on Windows Mobile targets and with IPv6 enumeration and

[bennylp]

Windows Mobile targets issue

Ticket #989 for release 1.5 changed the call to GetProcAddress() to always use ANSI string. This is broken for Windows Mobile.

There seems to be a difference with GetProcAddress() API signature between Windows (i.e. Win32) and Windows CE (e.g. Windows Mobile). On Windows, the API is declared as:

   FARPROC GetProcAddress(
     HMODULE hModule,
     LPCSTR lpProcName);

while on Windows CE:

   FARPROC GetProcAddress(
     HMODULE hModule,
     LPCWSTR lpProcName);

Notice the difference with lpProcName argument type. This means that on Windows, even on Unicode Windows, the lpProcName always takes ANSI format, while on Windows CE, the argument follows the UNICODE setting.

Because of this, yet a different Unicode treatment needs to be used when calling GetProcAddress() (i.e. not following PJLIB's Unicode setting)

IPv6 interface enumeration fails due to typo error in Windows targets

The PJLIB pj_enum_ip_interface() API enumerates all IP interfaces in the system with the specified address family. On Windows, the function should use GetAdaptersAddresses() Windows API if IPv6 is enabled, and fallback to use GetIpAddrTable() Windows API if GetAdaptersAddresses() fails.

However the GetAdaptersAddresses() was searched in the IPHLPAPI.DLL as "GetAdapterAddresses" (missing "s" after "Adapter"), causing the function to be failed to be loaded.

[bennylp]

Fixed in r3029

[bennylp]

Additional notes about r3029 fix above:

• it removed the restrictions that GetAdaptersAddresses() is only used when IPv6 is enabled. It is now used by default.
• on some Windows Mobile devices (Motorola Q), GetIpAddrTable() is not present in IPHLPAPI.DLL, but GetAdaptersAddresses() is. This fix solved this problem. Thanks Emil Sturniolo for the report.

[bennylp]

In r3030:

• fixed crash if GetAdaptersAddresses?() returns adapter with NULL "firstUnicastAddress". This happens when the interface is disabled.