Getting around the default system locale

by Michael S. Kaplan, published on 2005/11/09 08:27 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/11/09/490791.aspx


Last month, Duncan asked me:

Awhile ago, I was running an app that required me to run in Japanese mode, so I've been doing that for quite a while.

In the mean time, I downloaded some videos online that were named in Chinese (in terms of content at least, I have no idea what encoding it uses). So far, everything works fine.

I stopped using the app and decided to switch back to English (I got sick of seeing the YEN sign instead of forward slash anyhow), but now I can't seem to play those files anymore. Windows Media Player seems to be fine, but Real Player would complain that (for example), "_??^2.rpm" cannot be found.

Do you have any idea what's causing this? Does it have to do with the encoding of the filenames?

No Duncan, it is not the encoding of the filenames -- the filenames on Windows are in Unicode.

(I have definitely talked about the Yen as file path character in previously).

The problem is that the Real player is not using Unicode API functions to open the files, so when the Unicode name is converted to the default system code page, and if it does not contain the characters then they are converted to the default character (usually a question mark, definitely a question mark in this case).

So there is no way around this, other than changing the default system locale. Which does force you into that Ready... Set... Reboot! race.

Well, ok, there is one way, the AppLocale tool, which will let you change the setting for a single process. Some very excellent app compat work by Geoffrey Guo's team that takes the hack of an MSLU type layer and puts it on its ear by working a shim that does not require a recompile.

As an aside, I remember meeting with Geoffrey back before AppLocale was written when he was asking about how MSLU did some of its wrappers (since AppLocale would have to have wrappers as well, around some key functions), and I assumed it would go nowhere. Let me tell you that I have never been so happy to be proven wrong, and I will never doubt Geoffrey again!

Now it is awesome to have a tool to help with the case of applications that are not yet using Unicode.

But in the long run, the best way to handle the issue is to either:

If not for situations like the one Duncan is in, for the sake of more dire cirumstances such as languages that do not have a default system code page to represent them at all. Let's get these people to move to Unicode!

 

This post brought to you by "¦" (U+00a6, a.k.a. BROKEN BAR)


# Mihai on 9 Nov 2005 1:27 PM:

There are several problems with AppLocale (some of them I would almost call bugs :-)

referenced by

2007/01/17 Ungarbling the comments

go to newer or older post, or back to index or month or day