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