"Shachar Shemesh" wine-devel@shemesh.biz 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
What exactly did you do and under what Windows flavour? I assume that was XP, can you reproduce the same thing under win9x, NT4 and win2k? I can't reproduce that neither under Windows95/98 nor under Windows2000. If that's an XP specific thing, I'd simply ignore it like an inadvertent brokeness introduced by an attempt to support more than 1 logged in user. In that case simply assume that GetUserDefaultLCID returns system locale local to the current user. That fact changes nothing for me.
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).
Again, you are just guessing. Run winword.exe under API tracer under NT and analyse the logs. You will see that it does not call A version of win32 APIs at all.
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.
It's 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.
Just replace en_US in your locale settings by ru_RU leaving hebrew settings untouched and you will see.
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.
What exactly side effects do you mean here?
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.
Yes, that's exactly the problem I'm talking about.