Transparent locale-per-application support idea

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
dsp2003
Posts: 17
Joined: Sat Sep 05, 2009 10:23 am
Contact:

Transparent locale-per-application support idea

Post by dsp2003 »

This idea came out of discussion at #reactos-ru.

The introduction to the problem

Ever wondered why Windows so suck at locale-dependant application support, so it requires external hooks and hacks like AppLocale (emulates locale for non-unicode applications only) and NTLEA (emulates both locale AND regional settings) in order to run, for example, Japanese game under Western locale?

The Windows console suck not only at displaying and working with unicode, but even on the characters of the "native" codepage!

Unfortunately, the archivers (LZH, WinZip, WinRAR) and certain "old" formats like PKZIP do not follow unicode specifications either and use locale-specific codepages for filename encoding. Later opened in "wrong" locale, those archives might either be unextractable or look errorneous to the archiver itself!

The idea

Is there an simple way to fix this mess? Of course there is! The most easiest way is, actually, application-specific locale-to-unicode conversion for the output and unicode-to-locale conversion for the user input (yes, ANSI controls only).

How can this would look in ReactOS?

0. Introduce functionality into EXEcutable file properties (i.e. shell32) - "Locale" tab, somewhat similar to "Regional Settings" tab of intl.cpl.
1. On application startup, check for registry entry correspond to the application module name (for example, HKCU\ReactOS\LocalePatch\[AppName]\.
2a. If no specific info found, use default system settings.
2b. Or use the "Language" entry in VERSION_INFO resource for the app's codepage identification (hey, I think, the "Language" entry was designed for that in the first place, no? This would automatically fix many problematic applications even without extra user's effort).
2c. If found, use those user-specific application settings instead. Those include both language/codepage, timezone, digit/currency format etc. (yes, this is in the most common part with the AppLocale and NTLEA. But, unfortunately, they are way unstable and closed-source, and they break compatibility of many applications)

This would:

* Give maximum possible compatibility of many applications with vastly improved unicode support
* Easier way to simultaneously use applications with different locale settings without messing up the file system with unrecoverable filenames
* Make a history such monsters like AppLocale and NTLEA
* Optionally, make regional locks of some nasty applications useless

So, what do you think?

anyedge
Posts: 16
Joined: Wed Nov 14, 2007 3:17 am

Re: Transparent locale-per-application support idea

Post by anyedge »

I'm glad someone brought this up! I *literally* decided last night that I was going to start a topic about this exact issue sometime today. For Windows applications, I use Wine on my Ubuntu laptop. To run(for instance) Japanese programs, I can type LANG=ja_JP.utf8 wine /location/to/the/executable--which will work most of the time. Sometimes, I have to cd to the directory of the executable itself, then use the above with the name of the executable itself sans the location part. Again, this works for most Windows apps. There are still some(like LilliThrottle) that ONLY work for the Japanese version of Windows--and they will actually tell you that in almost exact verbatim.

If Reactos can achieve an elegant solution to this problem where the user would NOT have to reset his/her computer everytime they want to run an app in a different locale--then it will already have surpassed Windows in a very critical area.

To be honest, I'm not entirely sure I fully understand your idea, but then again I'm not a programmer. This is what I think you are saying:
Reactos should create a "Locale" variable for executable files and then patch them to switch between unicode and locale for output/input...right?

My question is, could this setup be used for executables that are already created(Starcraft 2, Titan Quest,etc.)? If so, how? If not, then maybe another alternative might *possibly* be needed? What do you think?

boomhauer
Posts: 18
Joined: Thu Aug 07, 2008 2:27 am
Contact:

Re: Transparent locale-per-application support idea

Post by boomhauer »

It is a good idea but unfortunately is pretty tough to implment.. I won't say impossible right off, but... ;)

The only way this could happen is for every app running in it's own specific codepage (that's what's important here, using the correct windows codepage), the OS will need to do conversions to mapped unicode characters for any and every place the app interacts with the OS. This is already done in a number of places with the existing windows api's, but then there are going to be a lot of other interactions where the app may bypass os level conversions and try to do things directly... and the result will be a mess of unprintable characters.

In reality I think MS would have implemented this if it were something that could be done... rebooting every time you change your system codepage is no fun for anyone ;)

PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Transparent locale-per-application support idea

Post by PurpleGurl »

Couldn't it be possible to make whatever modules/DLLs involved to reset without rebooting the whole machine? Or what about the user switching? Couldn't someone have user profiles in different languages? Then they could load a new user instance and switch between them, having desktops in whatever languages. There may be a simpler workaround, even in the Genuine Windows environment.

Jedi-to-be
Posts: 701
Joined: Sun Mar 16, 2008 11:26 am
Location: Russia, Stavropol
Contact:

Re: Transparent locale-per-application support idea

Post by Jedi-to-be »

dsp2003

I'd FAP on this!

Post Reply

Who is online

Users browsing this forum: Bing [Bot], DotBot [Crawler] and 5 guests