[zeromq-dev] Any progress on 64-bit Windows build

[Steven McCoy]

2010/10/4 Mikael Helbo Kjær <mhk at designtech.dk>

>  About the MIB_IFROW::wszName field isn’t it just a question of how the
> WCHAR define ends up. If you expect a MBCS value and a string is UNICODE a
> conversion function (mbstowcs_s) is available AFAIK even with the
> /Zc:wchar_t- value set in the compiler no matter if the compiler treats
> wchar_t as a native type or a define to unsigned short (which is what is
> does with the above option set).
>
>
>
Really?  All the APIs are declared with wchar_t not WCHAR, only WCHAR has
the fallback to unsigned short.


#if !defined(_NATIVE_WCHAR_T_DEFINED)
typedef unsigned short WCHAR;
#else
typedef wchar_t WCHAR;
#endif


http://msdn.microsoft.com/en-us/library/ms684497(VS.85).aspx

Wouldn't lack of wchar_t imply the absence of all the related APIs?

The GetAdapterAddresses API returns an ANSI adapter name and the only way to
match this with GetIfEntry is to use wcstombs_s on the WCHAR type in its
result.

On a Chinese desktop with Unicode adapter names this works as expected so my
hypothesis is that GetIfEntry is just returning a wide up-converted version
of the ANSI name.  I could therefore simulate wcstombs_s by dropping the
high bytes.

Otherwise what changes are required to placate Qt's lack of support for a
wchar_t native type?  I only specify the data type in an optional module not
built with 0MQ so it should be moot for compatibility.

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101004/cb7f5f1c/attachment.htm>