Wine and locales

Shachar Shemesh wine-devel at shemesh.biz
Wed Jul 28 07:59:27 CDT 2004


Dmitry Timoshkov wrote:

>You are trying to persuade yourself by taking into account only the look
>of the Windows. Please write a test app how I did and see what data
>GetSystemDefaultLCID and GetUserDefaultLCID return.
>  
>
Just did:
GetUserDefaultLCID: 0409
GetSystemDefaultLCID: 040d

>>Open the folder containing the file in Explorer (a unicode application) 
>>- the name is still Russian. Now try to open the file in Word (a 
>>non-unicode application).
>>    
>>
>
>Word is a *unicode* application when it's running under NT. It uses
>a sophisticated system of API pointers for that task in order to run
>under Win9x and NT.
>  
>
No, it is not. Well, it's more complicated than that, obviously. 
"Unicode" and "ANSI" applications are just compile time macros, as you 
well know. An application can easily use both sets of APIs, by calling 
"ExtTextOutA" or "ExtTextOutW" explicitly.

As far as Word processing goes, Word is obviously a Unicode application. 
There is no other way for it to display Hebrew and Russian in the same 
document. It does not rely on system APIs for that (as the fact BiDi 
works there better than it does on Wine shows). For display purposes, I 
guess it does exactly what you say it does - call ExtTextOutA on Win9x, 
and delay link and call ExtTextOutW on NT. There is simply no other way 
(as you correctly state) for it to display mixed languages.

However, whenever using APIs for internal purposes is concerned, Word is 
an ANSI application. It does call CreateFileA, and does fail on (at 
least Hebrew) file names that are outside the system default locale (as 
I call it, explained in my previous email).

>>The question is not whether confusion will arise from using different 
>>system and user locale. The question is whether it's supported, and 
>>whether we should support it as well.
>>    
>>
>
>It can't be supported in any sane manner since characters can't be
>mapped between incompatible charsets like hebrew and russian,
>
True, but not always relevant.

> and
>therefore characters from those charsets can't be displayed
>simultaneously by a not unicode application.
>
Again, true, but not everyone need to display stuff. Also, if I select a 
Hebrew codepage (system locale), I'm implying I don't want non-unicode 
apps to display Russian.

> That's exactly what
>you are trying to accomplish. Just realize that.
>  
>
No, it's not. The reason my personal computer is configured as it is is 
because I need to access Hebrew from ANSI applications, but having the 
user locale (which you call the system locale) set to Hebrew has some 
undesirable side effects. I therefor have this mixed setting. No 
problems for me, as I'm not using any characters that belong to the 
English locale that are outside the ASCII range.

>>Please do report the results of the above test. If they are anything 
>>other than what I have said, I'll be glad to amend my understanding of 
>>Windows.
>>    
>>
>
>Your understanding of Windows is based on conclusions you made by
>observing visual effects, not API behaviour.
>  
>
See beginning of this email for contradicting evidence. Don't take my 
word for it, however. Even if you don't want to touch the settings as 
explained in my previous email, set what you call the "system locale" 
(and I call the "user locale") to English, and run the API test again. I 
believe you will see that the two differ.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/




More information about the wine-devel mailing list