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" <[EMAIL PROTECTED]> 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
