by Michael S. Kaplan, published on 2007/07/13 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/07/13/3837355.aspx
It has been not quite a year since I first explained What the hell is up with Timor-Leste.
Well, the other day a developer named Julie (not associated with any other developer named Julie who I have previously known) sent me some mail as she was having problems loading some of the Timor-Leste info via GetGeoInfo.
Basically all of the localized content like the GEO_FRIENDLYNAME and GEO_OFFICIALNAME SYSGEOTYPE values, for a specific GEOID value. The one for Timor-Leste.
Hmmm, I wondered. Did somebody break this?
The comment in the .RC file seemed intact:
// Resources are in <= 0xffff, so this one will be clipped to 16 bits, however
// GetGeoInfo(0x6f60e7) will still return the correct value
0x6f60e7, L"$$$$$Democratic Republic of Timor-Leste" // this one is out of bounds !!
The bit in purple was added years ago (I was investigating it at the time I wrote that first blog post) and the bit in green was added by another developer earlier this year to clarify the [expected] behavior.
I had never added dev unit tests for this even when I was looking at it, but I did talk to a tester at the time and she verified that it was not being caught by automation. Though she said she'd follow up on that, the tester who I had originally talked to was no longer in the group, so I didn't know what the test coverage situation was. Suddenly I realized that this is how things get missed. :-(
Then I looked at the code and noticed an interesting head check that then developer Julie (another Julie, the one who runs our org, and the one who put in the purple comment!) put in way back in the end of 2000:
// Make sure we're not hitting the GEO ID that is out of bounds.
//
// !!! NOTE !!! This is needed because the East Timor Geo Id
// is out of bounds and wraps to 0x60e7.
//
if (ResourceID == 0x60e7)
{
return (0);
}
So it was basically failing the call and had been doing so for as long as GEO support has been in Windows XP -- just for the localized name entries.
Which ironically would have worked had this check never been added, due to the way LoadString and Win32 string tables silently truncate entries into a USHORT.
And which was missed by a lot of people after that, each of whom assumed that the comment meant the issue had been investigated and determined to not be a problem. :-)
You can see this bug in Regional Options, when you look at the Region settings, which are missing an entry for Timor-Leste:
(the screenshot is XP SP2 but the behavior is the same in Server 2003 and Vista)
So anyway, I sent mail to the first Julie (the one who asked me the question), explaining that there was this problem and that I'd get the bug reported for a future version.
And a blog post describing the whole story, which you are reading now.
I mean, how often does one developer Julie report a bug caused by code written by a different developer Julie? :-)
The interesting question is how to work around this problem. Perhaps another day....
This post brought to you by J (U+004a, a.k.a. LATIN CAPITAL LETTER J)
referenced by