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.
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
