Wine and locales

David Lee Lambert lamber45 at cse.msu.edu
Wed Aug 4 13:05:44 CDT 2004


On Wed, Aug 04, 2004 at 11:20:57AM +0300, Shachar Shemesh wrote:
> David Lee Lambert wrote:
> >On Wed, Jul 28, 2004 at 10:13:15PM -0700, Alexandre Julliard wrote:
> >>"Dmitry Timoshkov" <dmitry at baikal.ru> writes:

> >>I don't see how the settings would be different, surely LC_CTYPE is
> >>always going to control the ASCII->Unicode mapping on Unix, so why
> >>shouldn't it do that on Wine?  If the issue is that users change their
> >>setup without understanding the results, then surely adding even more
> >>config parameters that they need to get right is not going to improve
> >>the situation.
> >
> >1.  ANSI->Unicode translation for programs that use the ANSI calls,  as 
> >has been discussed in this thread.
> >
> Ok.
> 
> >2.  Unicode->codepage translation on standard output, and 
> >codepage->Unicode translation on standard input.  ...
> > 
> Why should we set it differently than 1?

(1) is when a program talks to what it thinks is a version of Windows 
according to the author's understanding of a the codepage.  (2) and (3) 
are how are how Wine talks to the rest of the system.

What codepage should be used under a utf8 locale, such as most of the 
setups on Redhat WS 9?  There are no Windows programs that actually pass 
utf8 data to the Xxxx*A calls;  if a program wants to use Unicode,  it 
will use the wide character APIs.  (MS Word, PAF 5, IE 6...)

(I know I said UTF16 before.  I haven't actually tried a UTF16-only setup,  
and UTF16 is not compatible with the C library because it uses \0 in 
normal text, etc.)

> Name one such filesystem, please. EXT and reiser never cared, as far as 
> I know. VFAT has to translate names stored in UTF-16. Are you saying the 
> kernels<2.4 didn't have the "iocharset" option?

I have some files stored on a Windows ME box with names containing 
accented characters,  which show up fine in Explorer and the MS-DOS prompt 
on that system and on other WinME systems accross the network.   
In Linux the filenames appear to be encoded in CP437 when I use 'smbmount' 
whith no options.  The manpage says that iocharset= (Linux side) and 
codepage= (Server side) are only supported in kernel 2.4 and above.  
However,  on my system that runs kernel 2.4.x, the problem persists even 
when I pass options "iocharset=utf8,codepage=cp437" I get a message about 
CP437 not being supported,  even though I have a kernel module cp437.o .

By the way,  Explorer and command.com only allow me to enter directories 
with 8-bit-character-names on the local system.  Under Linux,  I can enter 
said directory using tab completion, even though the characters don't show 
up.

> > This is all through 
> >GetLocaleInfo(), whose first argument is an LCID returned by either 
> >GetUserDefaultLocale or GetSystemDefaultLocale.
> >
> You can also pass "LOCALE_SYSTEM_DEFAULT" instead, but that doesn't 
> matter. In any case, there are "user overrides" here, which we may, one 
> day, want to implement. Everything is laid out in the table that started 
> this thread.
> 
> >5.  The MultiByteToWideChar() and WideCharToMultiByte() functions,  which 

> What do we need to do with these? They get an explicit codepage to 
> convert to/from. Funny though it may sound, these functions are not 
> affected by locale.

Right.

> I don't agree. Mixing default codepages across simultaneously running 
> programs is not possible on Windows, and sounds horribly difficult to 
> implement. Clipboard handling and cross-file using are two examples of 
> things that are likely to go horribly wrong if we tried.

If a program does a an ANSI call,  it gets changed to Unicode.  If that 
data gets passed back to another program using an ANSI call, it gets 
converted to the target codepage,  as much as possible.  If Wine is doing 
console output to a non-Unicode codepage,  it gets converted there too.

I'm not sure about mixing codepages under Windows, but input-method 
switching is easy.

> Having one setting applicable to all running processes sounds good 
> enough. I don't object to a config setting overriding what LC_CTYPE 
> says, but I don't see a use for it either.

Let's say I want to run an Arabic dictionary program and Spanish 
dictionary program as I'm typing a report in Word.  Furthermore,  the 
arabic dictionary program would use ANSI calls and expects to run on 
Arabic windows (with MS-ARAB encoding);  the Spanish program would use 
LATIN1.  Word uses wide-character calls.  How would I run all these 
programs at the same time under Wine?

(I'm not saying I actually have such a set of programs.  Actually,  I own 
a copy of a standalone program that allows typing of Arabic programs on 
Western windows,  and also have access to systems where Office XP with the 
Arabic and US-International input methods is installed.)

-- 
resume at  http://www.cse.msu.edu/~lamber45/resume.htm
PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey




More information about the wine-devel mailing list