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

[Mikael Helbo Kjær]

Hi Steven

 

Hmm, I have no problem running code even without _NATIVE_WCHAR_T_DEFINED that uses the wchar_t type. I believe that there is a define like this in most relevant CRT files on windows (this was taken from a Windows SDK):

 

#ifndef _WCHAR_T_DEFINED

typedef unsigned short wchar_t;

#define _WCHAR_T_DEFINED

#endif

 

So that also explains why the code I write with wchar_t works. The Qt thing is mostly an ABI issue I believe (they try to stay ABI and API compatible across major versions and many many compilers/OSes).

 

Regards,

Mikael

 

 

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.

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