wchar_t on GNU and Win32 - two worlds apart !

[Subhobroto Sinha]

Hello

The main problem is that wchar_t is 4 bytes on GNU, but 2 bytes on Windows !

Though Windows typedefs WCHAR as a wchar_t, but there a wchar_t is an "unsigned short", whereas on GNU it's "unsigned long"

So WCHAR serialized data from Windows will get messed if we use native GNU data types (because then the program will read 4 bytes instead where it should have read 2 bytes!).

Now you don't have to worry about WINE, as WINE defines the data type just as Windows and hence there's no problem with WINE's internationalization functions (MultiByte.. or WideChar... etc)

But as I am using pure C++, I have to use GLibc's library functions which expects wchar_t to be 4 bytes long and NOT 2 bytes.

So as a workaround I defined these two functions to convert from wchar_t and WCHAR to keep GNU's wcstombs() happy:

inline void Convert_wchar_t_ToWCHAR(const wchar_t* wszIn,WCHAR* wszOut)
{
  if(wszIn) while(*wszOut++=*wszIn++);
  else *wszOut=0;
}

and

inline void ConvertWCHARTo_wchar_t(const WCHAR* wszIn,wchar_t* wszOut)
{
  if(wszIn) while(*wszOut++=*wszIn++);
  else *wszOut=0;
}

As you can see, all the above two does is JUST copy the arrays from one data type to another.

As we are reading the data from a .lnk (and thus the wchar_t strings are 2 byte arrays in the file..), there's no harm done, as by copying the 2 byte array into a 4 byte array, there is no loss of information.

But, unfortunately, (but NOT always..), the function wcstombs fails.

I have attached the binary and source alongwith a .lnk which demonstrates this problem.

You just need to pass the .lnk filename to the binary on the command line, and it will spit out a few details at out about the .lnk

If you test the .lnk (DAEMON_TOOLS.LNK), you will see that the program crashes in the function:

unsigned int WineWorksShortcutResolver::UnicodeToANSI(const WCHAR* wszInUnicode,unsigned int uiLen,char* szOutANSI)

at the GLibc function:

wcstombs(..)

The most confusing thing is that this does not happen in case of any other .lnk that I have (which are not many..) !

Any suggestions ?

Regards

Subhobroto Sinha

[Dan Kegel]

Subhobroto Sinha wrote:
> If you test the .lnk (DAEMON_TOOLS.LNK), you will see that the program crashes in the function:
>
> unsigned int WineWorksShortcutResolver::UnicodeToANSI(const WCHAR* wszInUnicode,unsigned int uiLen,char* szOutANSI)
>
> at the GLibc function:
>
> wcstombs(..)

I'm way out of touch with Wine these days, but here's

1. If you want to get something useful done, switch to C.  Mixing
g++ and Winelib seems to be a bit tricky, and you might end up
spending all your time on that instead of solving the problem you
originally wanted to solve.

2. If you insist on using C++:
if the problem resists analysis, perhaps you could use Valgrind
to help track down the problem.  It's pretty easy to build the
wine edition of valgrind, and you don't need any special changes
to wine.  You can download valgrind's sources at http://valgrind.kde.org
Look for the 20031012-wine version.
- Dan

[Dan Kegel]

Dan Kegel wrote:
> I'm way out of touch with Wine these days, but here's

[ meant to say "my two bits"... obviously my mind is wandering... ]
> - If you want to get something useful done, switch to C.  Mixing
>
> g++ and Winelib seems to be a bit tricky, and you might end up
> spending all your time on that instead of solving the problem you
> originally wanted to solve.
> - If you insist on using C++:
>
> if the problem resists analysis, perhaps you could use Valgrind
> to help track down the problem.

3. Compile with MS Visual C++.  I run MSVC++ 4.0 on Wine just fine,
and I bet even newer versions will run the commandline versions
of the compilers ok on wine.

#3 really is the best option, since then your app will
run fine both on Windows and on Wine...

- Dan

[Chris Morgan]

> - If you insist on using C++:
>
> if the problem resists analysis, perhaps you could use Valgrind
> to help track down the problem.  It's pretty easy to build the
> wine edition of valgrind, and you don't need any special changes
> to wine.  You can download valgrind's sources at http://valgrind.kde.org
> Look for the 20031012-wine version.

In case there is trouble compiling valgrind the 20031012-wine version doesn't 
compile on my machine, debian unstable, 2.6.0-test11 kernel.  It has a 
handful of compile issues with kernel headers(I think) that are fixed in 
valgrind cvs.  Unfortunately the patch to make valgrind support wine doesn't 
apply cleanly to the cvs code.  I sent mail to Adam Gundy asking him if he 
has a newer patch or plans to release another valgrind-wine but he hasn't 
gotten back to me yet.

Chris

[Dimitrie O. Paun]

On December 27, 2003 01:11 pm, Subhobroto Sinha wrote:
> But as I am using pure C++, I have to use GLibc's library functions which
> expects wchar_t to be 4 bytes long and NOT 2 bytes.

Herein lies your problem. Mixing the two is not pretty, and I think
it should be avoided to maintain sanity. Just use our msvcrt for the
Unicode functions, it uses 2-byte wchar_t, so you can mix that freely
with the other Win32 functions.