Wine and locales

[Dmitry Timoshkov]

"Shachar Shemesh" <wine-devel at 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.

-- 
Dmitry.