When is it a backcompat break and when is it fulfilling not-yet-fulfilled technology?

by Michael S. Kaplan, published on 2005/03/18 09:35 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/03/18/398572.aspx

The other day when I pointed out that Backcompat is the father of the NLS APIs, there was a fairly straightforward case where the desire for a functionality conflicted with the need to not change the behavior of an API (for some values of straightforward; I know that the people who want a change would not necessarily agree with the assessment!).

In the spirit of hallway conversations and hypothetical questions that make one think of the scene in Broadcast News where Albert Brooks, Lois Chiles, and others are standing around asking hypothetical questions (e.g. "Would you tell a source that you loved them just to get some information?" or "They allow us to have cameras at an execution in Florida. Do you broadcast tape of the guy in the chair when they turn on the voltage?"), people came up with other questions in an attempt to find grayer areas.

This kind of question is made more fun (if less relevant) by the fact that the "what if?" factor allows them to not always be possible. If you know what I mean.

I thought that (if people were still reading around here!) I'd to find out what they thought about a particular hypothetical, as it did intrigue me more than the others and I had a much easier time seeing both sides of the argument....

The NLS APIs that are based on data fields that can be overridden in Regional Options will accept the LOCALE_NOUSEROVERRIDE flag, which tells the API to ignore any user preferences and instead go to the data directly. Since looking at the user preferences can require a quick look in the registry it will always (due to the laws of physics and of common sense) be a little slower, a difference which can even get noticeable if you are calling enough NLS APIs. Thus it is a commonly known performance optimization if the user overrides are not needed to pass the LOCALE_NOUSEROVERRIDE flag.

Note that this flag is only needed for the current user default locale. The reason is that we do not save the override values when the user default locale changes -- so passing the flag in the other cases would make a more intelligent (or maybe more Jeff Spicoli-like!) set of APIs mention to the caller "Um, dude? I have no overrides to bypass. So I was totally going to do that anyway!"

OK, fine. Now the hypothetical: what if the overrides were all stored -- what if they were available and there were a real chance to use them?

The default for the APIs has always been to "use the user overrides if they pass the user default local and the flag is not passed". If this changed to "use the user overrides if the flag is not passed", then the API would have more sensible behavior for the scenario of other locales where the user actually had an override, but on the other hand it would slow down the default case of the API for all other locales by a measurable factor.

They could have always passed the LOCALE_NOUSEROVERRIDE flag to counter that, but on the other hand they did not need to.

You would enable a whole new generation of applications to behave more intuitively, or on the other hand you might slow down an older generation of applications.

And you would enable a technology that the APIs and the flag suggest, on the other hand changing the documented method by which the APIs work.

See the conflict? I think people tended to be almost evenly divided, in the end!

So what do you think -- would it be fulfilling an unfulfilled technology? Or causing a backcompat break of staggering proportions? Maybe you, the readers, can break the tie....

This question brought to you by "؟" (U+061f, ARABIC QUESTION MARK)
A character that has been itching to sponsor but was waiting for me to shut up and ask a question already!

Just go ahead and mention in the documentation NOW that, in the future, this API may use user-overrides for non-default locales.

Then, perhaps in Longhorn, or the version after, this feature could be added. If it breaks a major application, you guys could bend over backwards (as usual) to provide appcompat fixes, but it seems to me like worst-case scenario is some programs will slow down. It wouldn't be the first time. (Happens all the time on Mac, although they have a very different approach to "compatability").

If it were a big problem, either manually fixing the application or manually tweaking the appcompat settings would both be viable fixes. (It is still possible to use a tool to manually set appcompat settings, right?)

It's not like you're doing something that the API didn't imply you *might* do.

Anyway, no matter what, I'd still say change the documentation now, in case you ever need to make this decision in the future. It'd be really easy to say, "Current versions of Windows do not support user overrides on any locale other than the default, but this is likely to change in a future version." Even if you never add this feature, at least you'll keep developers on their toes.

I guess this topic is not as interesting as you thought it was going to be. Maybe you people have to get out more rather than hanging out in the hallways.

For the question you pose: I am more sympathetic to AC's second post. I doubt any of my clients are worthy of appcompat but some of them will be just as broken!

I will explain my applications, if that helps. I usually do not pass the flag because even though I will often use all locales I like picking of the user's choices on the one. But the applications would not scale well to having to check all locales for overrides.

I am assuming that one day this may not be theoretical. So when that happens, please make the new behavior an opt-in flag or a new API, like the other backcompat issue you raised.

Joseph is right. Not too many people want to take the bait.

I started off agreeing with Matthew but Joseph's post has me on the fence. I don't think I have code that will be hurt too much either way but I am not sure. I've definitely never tested code with the new behavior in mind. I'd probably feel safer with a new flag.