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

Mikael Helbo Kjær mhk at designtech.dk
Mon Oct 4 09:21:06 CEST 2010

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):



typedef unsigned short wchar_t;




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).






Really?  All the APIs are declared with wchar_t not WCHAR, only WCHAR has the fallback to unsigned short.


typedef unsigned short WCHAR;
typedef wchar_t WCHAR;




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>

More information about the zeromq-dev mailing list