by Michael S. Kaplan, published on 2010/02/16 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/02/16/9964017.aspx
One of the very first bugs I ever fixed as a consultant for a customer was in an application that printed financial reports, It ran on Windows 95 and NT 4.0, which were the main version of Windows people were on then (the move from Win 3.1[1] on the client and NT 3.5[1] on the client (if not the server) was pretty complete with the customers I was dealing with).
The application had problems any time a user made the decimal separator more than one character. Like you can do still in Windows 7 just as you could in every prior version of Windows:
I looked at the documentation surrounding the LOCALE_SDECIMAL constant (here in its most recent form):
Character(s) used for the decimal separator, for example, "." in "3.14" or "," in "3,14". The maximum number of characters allowed for this string is four, including a terminating null character.
Now some things are different here (it used to not have a dedicated topic as the line of text was a part of the larger Locale Information Constants topic, and it did not used to mention that although it allowed four characters that one of them had to be the NULL), but the basic limitations have not changed since that time.
I fixed the bug in the code, by the way.
It was clear (to me at least, back then) that there was no use fighting the documented abilities of an operating system. Not supporting this configuration is a bug in the application, after all.
Now for just about as long as this feature has been around, there have been applications that have been tripping over it.
Not every application, mind you.
Just some of them.
In fact, the fancy Calculator in the new version of Windows is just such an application who sees its decimal handling broken when you make such a change.
Darn, and after all the work they did to support user preferences, to trip on this obscure one (which despite being around for so long is still not widely known).
Now, you may remember how I have talked about the pseudo locales like qps-ploc that test out extreme cases harder to readily test for in prior blogs like Walking off the end of the eighth bit. Well it just so happens that qps-ploc has two characters in its decimal separator to make this feature easier to test out and make sure it does not break you.
So you can look at this as your chance to find the bug that even folks at Microsoft missed, and fix it in your own code.
And just remember that this feature has now been around for over a decade and a half, so if it breaks you application then it is your application that is broken. And has been for some time.
Just FYI, but curiosity over whether some existing locale has ever used this feature is just an act of desperation to avoid doing the job. -)
Pseudo just made it easier for you to find the bug!
referenced by