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