Holy cow, I wrote a book!
DoesNotMatter wants to know
why AppLocale cannot just be added to the Compatibility property sheet
as a dropdown option.
One of the things about having a huge topic backlog is that if I
just wait long enough,
there's a good chance somebody else will answer it, and then
I don't have to write anything.
And more often than not, that somebody else is
who addressed this question in April 2010:
Not only is AppLocale not installed by default,
AppLocale does everything in its power to remind you that you shouldn't
be using it!
AppLocale is the emergency compact spare tire that you pull out of your
Its job is to get you home, at which point you can fix the problem properly.
You shouldn't be driving on your emergency compact spare as part of
your normal daily routine.
Why does changing the
code page require a logoff/logon cycle?
Because without it, you would have a
Frankenstein configuration situation,
where two programs think they're speaking the same language to each
other, but aren't.
This would happen if one program
was launched before you changed the locale, and the other
was launched after it.
Sure, if the communication was done through the clipboard
CF_TEXT data format, or via one of the
system-defined window messages that contain strings,
then the window manager can
convert from one code page to the other
(though it will have to
round-trip through Unicode).
But that's an awful lot of work for something that
isn't even a valid steady-state configuration.
And besides, it wouldn't even fix the other communication channels
between processes, such as custom clipboard formats or private
For example, suppose you have a copy of LitWare running,
and then you change the locale, and then you run another copy of
You then drag an object from the first copy of LitWare to the second.
If LitWare's custom data format uses ANSI strings,
then the first copy will encode the object name using the old locale,
and the second copy will decode it with the new locale.
And since this is a custom data format, there's nowhere the window
manager or OLE can step in and say, "Oh, wait, I know what you're
doing. There's a string embedded in that structure.
Let me convert it for you."
I encounter this problem myself with a Chinese-language program I use.
The program uses a Chinese code page rather than Unicode,
and I have to use AppLocale to get it to display anything other
than meaningless gibberish.
(And even then, it still displays what appears
to me to be mostly gibberish, but that part of the problem
is my own fault for not knowing how to read very much Chinese.)
I have to remember that I cannot copy/paste any Chinese characters
into or out of the program because the result will be garbage
due to the code page mismatch.
Mind you, you can just ignore the logoff reminder that appears
when you change the default locale
and continue running your Frankenstein configuration.
Just understand that you're now in a world where programs can no
longer communicate with each other reliably.