by Michael S. Kaplan, published on 2006/08/19 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/08/19/706950.aspx
Regular reader Mark Brooks asked in the Suggestion Box:
What's up with Timor-Leste?
How did it get such an outlier GEOID here: http://msdn.microsoft.com/library/en-us/intl/nls_locations.asp
Yes Mark, it is hard to look at the items in the Table of Geographic Locations and understand really any of the random assignments, let alone the one strange one at the end for Timor-Leste (0x6F60E7). How on earth could that not be a typo on the page or a mistake of some sort? :-)
But as I first mentioned back in the post GEOID -- The LCIDs maligned little brother...., the actual values come from a huge database that is used by MapPoint -- and you will see many similarities to the GeoCountry values. The actual database has many more entries than either table gives, and really allows projects that are mapping every country and region to be covered.
How else to support the MapPoint Location Server and MapPoint Web Service? :-)
Anyway, we don't assign the IDs, we just consume them. We want to add an item to the list, so we ask them what the value is, and they tell us. Once in a while, we ask for something that had no ID, and they assign one (via their own process) and tell us what it is.
It just so happens in this case that Timor-Leste has a large number for its value, that's all.
Not that it did not cause a bit of a fuss at the time. You see, we store a lot of the localized string values in kernel32.dll (technically its satellite kernel32.dll.mui files), and as you may know of STRINGTABLE Resources, the actual string ID is limited to 16 bits.
In fact, you can think of it as another reason that the LoadString function is evil -- ID values are UINTs, yet the actual size limit is USHORTs, and the value you pass is truncated, so that if you load up 0x6F60E7 you actually get the string at 0x60E7.
But you don't have to be too horrified at a massive bug here -- the resource compiler actually does the same type of truncation so you will find what you need.
Lucky for us, we don't have something with an ID value of 0x60E7 assigned to it that we support with the GEOID functions, or we'd have to change our whole resource loading mechanism!
Though to be honest, I figure it is only a matter of time. Every new version of Windows adds new entries, so one day we'll hit a conflict. Maybe this blog post can help remind people on the team that we need to get the ID values early, just in case.... :-)
This post brought to you by ጡ (U+1321, a.k.a. ETHIOPIC SYLLABLE THU)
Andrew Cook on 12 Dec 2007 11:18 AM:
The link to LoadString is b0rken; apparently MSDN changed how their search page works while you weren't looking and the link isn't direct but goes through that search page.
Direct link to MSDN2 article: http://msdn2.microsoft.com/en-us/library/ms647486.aspx
Michael S. Kaplan on 12 Dec 2007 11:47 AM:
The problem is that I have hundreds of links like that, and fixing them every time MSDN changes again is not a road I want to go down.... :-(
referenced by