Wrong charcter encoding in winmm-tests

[Julian Rüger]

Hello everyone,

I ran the winmm-tests in wine today, with a german locale, and noticed
that the umlauts are displayed incorrectly. My terminal is in UTF-8 and
wine outputs ISO 8859-1.

I looked into the code and found out that ie. in wave.c,
wave_out_error() declares the strings as static char, and thus uses
waveOutGetErrorTextA() if I am not mistaken.

Should this be fixed or doesn't it matter in the tests?

Best regards,
Julian

[Julian Rüger]

> waveOutGetErrorTextA() if I am not mistaken.

Forget that part please ;)

So, the .po is UTF-8, the terminal is UTF-8 and my $LANG is de_DE.UTF-8,
but somewhere it is converted to 8859-1...

[Julian Rüger]

OK, I think I finally found out what's going on here:

in waveform.c waveOutGetErrorTextA() calls
WideCharToMultiByte(CP_ACP,.... with the ANSI codepage.
When I change that to CP_UTF8, it works as expected.

Is this fix OK, or does that break anything? Should I send a patch?

Thanks,
Julian

[Francois Gouget]

On Sun, 26 Feb 2012, Julian Rüger wrote:
> OK, I think I finally found out what's going on here:
>
> in waveform.c waveOutGetErrorTextA() calls
> WideCharToMultiByte(CP_ACP,.... with the ANSI codepage.
> When I change that to CP_UTF8, it works as expected.
>
> Is this fix OK, or does that break anything? Should I send a patch?

waveOutGetErrorTextA() is correct. As its name indicates it's supposed 
to return an ANSI string.

So I think it's the test that should be performing the apprpriate 
conversion (assuming we really care) but I can't remember the details 
right now. In particular I'm not sure if using CP_UNIXCP would be 
appropriate here. It might depend on the API used to write to stdout.

And starting from a Unicode string would be much much better too...
(in particular for languages like Japanese, etc.)

[Julian Rüger]

> So I think it's the test that should be performing the apprpriate 
> conversion (assuming we really care) but I can't remember the details

I suppose everyone running the tests should be able to figure it out and
set $LANG to en_US or something for the test.
But I think this is more widespread:

$ grep -d recurse "WideCharToMultiByte(CP_ACP" wine-git|wc -l
662
$ grep -d recurse "WideCharToMultiByte(CP_UTF8" wine-git|wc -l
45
> right now. In particular I'm not sure if using CP_UNIXCP would be 
> appropriate here. It might depend on the API used to write to stdout.
>
> And starting from a Unicode string would be much much better too...
> (in particular for languages like Japanese, etc.)

I guess UNIXCP is the current codepage the host os uses?
Like nl_langinfo(CODESET) from langinfo.h?

$ grep -d recurse "WideCharToMultiByte(CP_UNIXCP" wine-git|wc -l
72

Then shouldn't most or all of those CP_ACPs (and CP_UTF8s) be replaced
with CP_UNIXCP?

Best regards,
Julian

[Francois Gouget]

On Sun, 26 Feb 2012, Julian Rüger wrote:
[...]
> Then shouldn't most or all of those CP_ACPs (and CP_UTF8s) be replaced
> with CP_UNIXCP?

No. As I said, all the functions that end with an 'A' are supposed to 
return ANSI strings and thus must use CP_ACP. Remember that Wine is a 
Win32 API reimplementation so there are a lot of these Ansi functions.

Now the places where we actually have to deal with CP_UNIXCP are pretty 
rare. You'll have to dig deeper to find exactly why the wrong encoding 
is used in the winmm test. Maybe it is as simple as passing Ansi strings 
straight to the native printf implementation?