When changing behavior is like killing puppies

by Michael S. Kaplan, published on 2009/12/01 08:51 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2009/12/01/9930855.aspx

The other day, long time colleague Brian asked over on a large distribution list:

Does Windows automatically call SetThreadPreferredUILanguages(MUI_CONSOLE_FILTER, NULL, NULL) when launching a console app?  If not, why not?

Now SetThreadPreferredUILanguages is one of those functions that I primarily dislike for one reason and one reason only: its complexity.

I mean this is a function with a simple stated purpose:

Sets the thread preferred UI languages for the current thread.

Then of course there is a crucial note that hints at some more underlying complexity:

Note: This function is also used by the operating system to identify languages that are safe to use on the Windows console.

Then if you look at the info on the flags parameter you have MUI_COMPLEX_SCRIPT_FILTER and MUI_CONSOLE_FILTER and MUI_RESET_FILTERS and if you pass any of them you have to pass NULL for the parameters where you would set the list.

And if you look in the notes it talks about the various interactions that go on here with the various combinations of things.

There's a lot going on here in what is arguably an important setting. And a helluva lot of ways to call it.

Including a reset switch, apparently for if you have confused something in previous calls? :-)

Many people will make mistakes here, something I know indirectly because of the number of times that people ask me about how they should be calling it, often after having something not behave the way they expected it would.

Okay, off the soapbox, let's get back to Brian's question.

The simplest answer is NO and the reason is because that is what Windows does but that isn't very satisfying, is it?

A fuller answer (I've known Brian for years now, enough that I feel self conscious about the fact that he asked the question a month ago and I didn't notice that fact until yesterday and therefore a better answer than BECAUSE I'M THE MOMMY is indicated for a whole host of reasons.

Now the reason that MUI_CONSOLE_FILTER exists is that there are a whole bunch of languages that won't work well even if you use the cool way of Unicodizing the console discussed in Conventional wisdom is retarded, aka What the @#%&* is _O_U16TEXT?. And most people don't even do that.

Now if they do keep in mind that the rules for what a "safe" console language massively changes and SetThreadPreferredUILanguages with MUI_CONSOLE_FILTER doesn't really keep track of it as entirely effectively as one might wish, according to several who have tried it out after reading that blog. Though their language may be a bit less polite of course!

But that is not why Windows does not automatically call SetThreadPreferredUILanguages(MUI_CONSOLE_FILTER, NULL, NULL).

The reason Windows does not automatically call SetThreadPreferredUILanguages(MUI_CONSOLE_FILTER, NULL, NULL) is that not all console applications restrict the work they do to what they show in the console window! Some of them create huge log files, some of them send messages to other parts of the system or set registry keys, and so on. All operations that write data to places that can accept date in Thai or Telugu or Tamil or Tibetan or even languages that don't start with T that don't work so well in the console UI.

Automatically changing the behavior out from under all console applications would break any number of people who have been working under the rules that have existed for years.

Including the one group most interested in things not changing their behavior -- the sysadmins who live in the console with their hundreds or even thousands of scripts that run console applications....

In their view, changing behavior is the professional equivalent of killing puppies, really cute puppies. And there is no upside for that....

# Ranjit Iyer on 2 Dec 2009 7:59 PM:

# Maurits [MSFT] on 8 Dec 2009 8:41 AM:

referenced by

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