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....
Ready? Here goes.
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!
# AC on 18 Mar 2005 8:15 AM:
# Matthew W. Jackson on 18 Mar 2005 8:39 AM:
# AC on 18 Mar 2005 11:20 AM:
# Joseph Petersen on 18 Mar 2005 6:05 PM:
# Frank Hogan on 18 Mar 2005 8:28 PM:
# Bryan on 22 Mar 2005 10:51 AM:
2005/03/29 Flag behavior for the NLS APIs
go to newer or older post, or back to index or month or day