July, 2007

Late last week I needed to answer a question the other day about the number of successful downloads of Microsoft Keyboard Layout Creator.

So I went to the tool that gives those stats and I found out that (between the 1.3 and 1.4 versions) as of last week there have been

263,400,000

downloads of this tool!

Now that number gave me pause. Even though lots of those downloads may have been by people who never built a keyboard layout, and more than a few might be the same people downloading both versions of the tool or downloading to install on another machine, there are still a lot of downloads there.

Any way you look at it, a bunch of those downloads were done by people who built a new keyboard layout for themselves.

And a bunch of those downloads were done by people who ended up building keyboard layouts for others -- sometimes for whole language communities!

A few of those downloads were even done by people who work for Microsoft in the subsidiaries who used it to produce keyboard layouts that eventually made their way into Vista, and we were able to add more keyboard layouts than any prior version due to how much easier they were to create.

The number just staggered me.

It staggered me for another reason, too -- because of the small number of actual bug reports that have come up, most of which were to do with either limitations of MSKLC (or the underlying keyboard support in the USER subsystem) or straight out feature requests. The actual bug count has been quite small!

So while technically not The most robust software project I ever worked on (that project technically had fewer bugs!), and technically not the code I have worked on that the most people have run (pieces of Windows definitely qualify for that!), I can't help feeling like as a team we touched a lot more people in a much more significant way.

From Cathy and Simon and Kanya and Gary and Shu and Jenny and little old me, not to mention all of the people who reported issues during the beta and the people who helped sign packages in the early AM and even the people in management who approved the project, something really cool has been done.

263,400,000 times. :-)

This post brought to you by ∞ (U+221e, a.k.a. INFINITY)

Way back in the end of September 2005, I was explaining how if a function is not documented in the SDK or the DDK then there was really no way to enhance documentation.

Of course the point of that post (If it is not documented....) can mostly be ignored now, since as Aaron Margosis just pointed out to me, NtQueryDirectoryObject is now documented, right here!

Though the language of that documentation does not inspire confidence in the long-term future of the function. :-)

This post brought to you by ⚱ (U+26b1, a.k.a. FUNERAL URN)

It was over two years ago that I first pointed out the problems with Windows code page 20269 (Microsoft's somewhat lame attempt at an implementation of ISO 6937) in Not all code pages work right. 

And almost two years ago when I mentioned it again with some more detail in You probably don't want to use Microsoft's code page 20269.

But you may not want to go thinking that just because something is a bad idea out of step with the encoding industry with a bad MS implementation out there that people will avoid using it....

Just recently, in somewhat tangential response to Sometimes when you say 'the fix is in' you mean it in a good way, regular reader Cristian Secară commented:

Big countries, like Germany, France or Italy don't use subtitling in general, but there are also exceptions: in France for example, public programms uses voice doubling, while paid programms uses subtitling (VOST - version originale sous-titrée). Belgium and Holland uses subtitling. European Union directives forces the presence of special subtiling designed for audio impaired peoples. AFAIK scandinavian countries also uses subtitling.

Ok with that. But what I wanted to say is that – from my point of view – the real problem is that all these countries are, let's say, satisfied with the actual status quo: they either need no subtitling, or they are satisfied with the actual EBU subtitling format, which is based on the ancient telematic ISO/IEC 6937 standard that covers a limited number of languages. And I can't blaim them: if it ain't broke, why fix it ?

And just the other day someone was asking about the strange results that this code page provides, mainly in the context of entertainment devices such as television -- a place that people seemed to be embracing ISO 6937 despite all of its problems....

Because in the end, a lot of different folks seem to have embraced ISO 6937 despite all of its limitations and problems. Heralding our way into the next century is technology that seems quite stubbornly insistent on using the technologies of the last century. :-(

This post brought to you by À (U+00c0, a.k.a. LATIN CAPITAL LETTER A WITH GRAVE)

You may have read in Arial Unicode MS effectively [bites|sucks|blows] about how Microsoft MVP Omi Azad likes to point out bugs....

Regular reader Cristian Secară likes to do the same kind of thing. :-)

Just the other day, he sent the following to me:

With Google I'm not sure what to believe: just the other day Google was able to find words written with cedillas when searching them in pure ASCII (and vice versa), but today this no longer appears to work (maybe today they run an emergency server :). But as far as words with commas are involved, both live.com and Google will only find them when spelling exactly.

Also live.com fails to recognize the Romanian „ and ” curly quotation marks, but works as expected with the English “ and ” curly quotation marks. At the same time, Google works well with all of them.

I tend to do a lot of comparison/contrast type searches between search engines using various international features, so I know exactly what Cristi is talking about here. Google is constantly tweaking things (Windows Live search does too, but the changes that I notice seem to be more batched up and episodic).

I do find it disappointing that no one is doing a better job with the cedilla/comma below thing, though I have higher hopes for the Live Desktop Search since they have actually asked me about Romanian in the pat (I suspect they will do better on Vista than on prior versions, for the obvious reason that this is when the underlying updates were made!).

For what it is worth, I suspect that Live Desktop search will also do better with the Romanian quotes. :-)

Which is not to say that web search shouldn't do better here.

It should. For all of the various search engines.

Though until they start jumping through those Unicode normalization hoops, I suspect the extra language features may have to wait in line....

This post brought to you by ⺞ (U+2e9e, a.k.a. CJK RADICAL DEATH)

(Nothing technical, other than some blathering about a technical lead technicality) 

From a very young age, I have been a fan of pipes.

Though I admit it was mainly because my father would periodically quit smoking cigars to move back to pipes and then eventually quit smoking pipes to move back to cigars, and back again....

And the pipes smelled significantly better than the cigars he was smoking! :-)

But this most recent iteration of pipes -- the "pipe" model of management that things have re-organized into, I am not as big of a fan of.

Mainly because it means I will probably lose my Technical Lead title soon.

I sort of described the role here for those who haven't been around for years. The thing I have not really mentioned is why I care.

It is not because losing the title would be a demotion; it wouldn't. Just like getting the title was not a promotion.

It was just a recognition that what I was doing was not just development but also other work that spanned disciplines....

It is fun to point out how most devs think of it as program management while most PMs think of it as development, but it does outline a recognition that some of what I do is outside of what they do, so no one has to feel like I am stepping on toes or working outside of my job.

But once I lose the title, I'll be back to feeling like all of those things that I do that are not thought of as traditional development tasks are somehow not a core part of my job. The title just seemed like symbolic recognition that I was doing the job everybody wanted me doing, so fitting into the pipe will seem like a bit of a symbolic backslide.

So the job won't change because of it, my commitments will read the same way, and I won't hesitate to do what I believe is the right thing.

It just seems like it will be a little bit more of a struggle, and a little bit less of a feeling that my job is understood (or at least accepted).

Anyway, I am probably worried for nothing, to the extent that one could actually say I am worried. Which is not much. Just something I'm not especially looking forward to....

I have to wonder how I'd feel if some group offered me a job that wouldn't involve a title change, whether I'd take it. Does it bother me that much? I can honestly say I'm really not sure. Though it may be silly to read into that too deeply, since I also wonder whether I'd seriously consider a job offer from Apple given how they stock Limonata in the cafeteria!

By the way, I did try to smoke the actual pipe once. I decided the smell was not nearly as good when it wasn't second hand! :-)

This post brought to you by ǀ (U+01c0, a.k.a. LATIN LETTER DENTAL CLICK, a.k.a. LATIN LETTER PIPE)

MVP Omi Azad likes to send people from Microsoft email when he runs into bugs.

Usually they are our bugs, so it all works out.

Though this last mail was a bit different....

First he sent a screenshot of some Bengali text:

The bits in green were the problem. His words:

Don't go through the content of the image I attached. :-)

Just have a look at the green marked characters. They are not same as the other one. Green ones are not bottom aligned with the other ones, also not top aligned.

Is that a font conflict? I have more than one font installed in the system. This doesn't happen with IE7 but it happens with Firefox.

If face is not declared in the html, one screen should bring all the characters from the same default font. So why they are not rendering correctly in Vista? This doesn't happen on XP/2000.

But same problem happens with most of the Non-MS products. That is why I'm concern about it.

Just now I removed Arial Unicode MS font and things become perfect once again. What's is wrong?

Do you have any idea?

Well, I do have some ideas.

First, uninstall Arial Unicode MS!

I mean, really.

There are way too many applications that are using it as a default font, since they figure that will get them coverage of things.

And that is just a really bad idea, given the coverage of this font in terms of both characters and features will seldom be identical to the OS since it is not an OS font (it's an Office font).

Even Omi noticed that removing Arial Unicode MS made the problem go away in those various non-MS applications.

When you get down to it, you need to try and trust what Uniscribe is doing rather than trying to start with a font that may not be able to get it all done....

As a last resort font, it is okay. But as a first resort font? It bites. It sucks. It blows. For a whole lot of other reasons in addition to this one that ISVs are forcing on everyone....

And if you are an ISV, please consider not using it. Your users may really thank you for it!

This post brought to you by 𒁁 (U+12041, a.k.a. CUNEIFORM SIGN BAD)

It can be hard to act in a neutral manner.

As an example, you may recall how I talked about neutral locales and how they are automatically converted into full locales by NLS functions in Windows in this post. Using the same logic, if you pass LOCALE_NEUTRAL (which is to say, 0), it will handily be converted to 0x0400, which is to say, LOCALE_USER_DEFAULT.

In other words, no chance of 100% neutrality in NLS.

But it does not end there.

In the world of the resources, you can tag resources with a 0 to indicate that they are LANG_NEUTRAL or LOCALE_NEUTRAL. In fact, someone was just asking me the other day about how these neutral resources are used:

I am trying to build an application which has a .rc which will contain both English[US] dialogs/menus etc and also a similar set of copies of neutral resources. In my English[US] OS and locale, I expect loading of English resources, whereas, i find neutral resources being loaded.

I found from the link below that, when user locale and thread locale are same, the system resource loader will use language ID 0

http://www.microsoft.com/globaldev/handson/dev/muiapp.mspx

Though such a requirement of using English as well as Neutral resources is weird, I am looking for some solutions/suggestions/learnings to the problem without removal of either resource (not even to dlls). Also I am using Visual Studio 2003 - VC++

The text of that topic is indeed quite confusing. Here is the part that may make your head explode if you read it too many times:

To access the resources at run time, the resource DLL is loaded through the LoadLibrary API. EnumResourceLanguages can then be used to find the list of available languages for a given control/resource, and FindResourceEx to determine the location of the resource with the specified type, name, and language. Displaying a given language is then just a matter of selecting the right resources within the DLL. Language switching can be implemented by re-loading the newly selected resources and refreshing the client area.

It’s important to note that the Windows resource loader always defaults to the current user locale (the thread locale gets inherited from the currently logged in user's user locale - see Figure 1). GetThreadLocale allows querying of thread locale. In this method, predefined resource loading APIs (LoadIcon, LoadString, LoadCursor…) always return resources associated with this locale. For example, in the resource sample above, the French resources cannot be loaded by using LoadString if the system locale is set to English (0x0409). Actually this is not entirely true: a thread locale, once inherited – upon thread creation – is independent from the user locale, which means in this case the thread locale can be changed to French (0x040C) by using SetThreadLocale and calling LoadString to get the French string back.

// if our thread locale is English to start with…
g_hInst = LoadLibrary(_TEXT(“intl_res.dll”));
LoadString(g_hInst, IDS_ENUMSTRTEST,g_szTemp, MAX_STR);
// g_szTemp would then point to the English resources
// changing our thread locale to French. X
// Always make sure that French is in fact one of the
// valid languages returned by EnumResourceLanguages()
// Save a copy of the current thread-locale to set back later
Lcid = GetThreadLocale();
SetThreadLocale(MAKELCID(0x040c, SORT_DEFAULT));
LoadString(g_hInst, IDS_ENUMSTRTEST, g_szTemp, MAX_STR);
// g_szTemp would then point to the French resources

The catch here is that if the thread locale is the same as the currently selected user locale, system’s resource loader will by default use the language ID 0 (neutral). If the desired resource is defined as a neutral language, then this value will be returned. Otherwise, all of the language resources will be enumerated (in language ID order) and the first matching resource ID – regardless of its language – will be returned.

To clarify, consider an example (using our English – US and French – France resources) in which the user locale is set to Japanese, then: our original thread locale is Japanese (0x0411). The first call to LoadString will return English resources since 0x0411 version if our string ID cannot be found and English (0x0409) is enumerated before French (0x40C). Now, if the user locale to start with is French: our original thread locale is French (0x040C). Since the user locale and thread locale match, the system resource loader will use language ID 0 and will start enumerating resources and will once again return the English version!

The best way around this is to give up changing the thread locale in the first place. Resources can be manually loaded from within multilingual resource files by making calls to FindResourceEx . Another workaround is to define the resources within an owner-defined language tag. In the RC example above, the English section was defined as:

LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
    
This prevents the thread locale from being switched back to English US. However, defining the resources as:

LANGUAGE LANG_ENGLISH, SUBLANG_NEUTRAL
    
will guarantee the success of the SetThreadLocale call since there is no matching user locale for this language ID and the predefined resource loader APIs can still be used.

Again, your head may explode trying to parse what this text is saying.

Thankfully, however, the text is slightly incorrect in its assumption, or at least misleading in its language.

You see, the actual behavior boils down to the difference between FindResource and FindResourceEx.

Ignoring my Ex claims here, the only difference between the two is that the former calls the latter with a wLanguage value of 0.

But the meaning of a FindResource call (or the essentially identical FindResourceEx call with a wLanguage of 0) is, when the docs refer to the thread language, is not in any way at all guaranteed to be either the return of the dreaded GetThreadLocale or what that quoted resource page calls "language ID 0 (neutral)". That 0 to the world of MUI and the UI language means the default user UI language!

The behavioral interaction between thread locale and user locale can be made much clearer than above, with two simple statements:

• If they are the same, then start with the UI language;
• If they are not the same, then start with the thread locale.

And hopefully no head explosions. :-)

This behavior almost kind of makes sense in terms of keeping the balance between the old and new behaviors, and really only breaks the case where you wanted to use SetThreadLocale to change the UI language to be one that matches the user locale....

And how else could MUI have been bolted on to the existing FindResource and FindResourceEx with minimal code change way back in Windows 2000?

(Please pretend that is rhetorical; given the benefits of hindsight I can actually think of several designs that would probably have been better here; but this is the model we have!)

So where do the resources that are actually marked with LANG_NEUTRAL fit in?

Well, if the resource loader has its way, then they will show up somewhere on the list prior to simply giving up. But they cannot ever be directly loaded and will never be the first choice for what the resource loader tries to use, even when you ask for it (since the resource loader gives 0 this special meaning)....

So once again, we find that neutral has a different meaning that is not actually neutral!

This post brought to you by ⚲ (U+26b2, a.k.a. NEUTER)

It was over two years ago that I mentioned how code pages are really not enough. But it is still a problem that comes up all the time....

Ahmet's question is very representative of the situation:

I need help for an encoding issue while creating a text file. A customer of mine is creating a text file with some strings and integer values. He is calculating byte representation of the integer and writing it to a text file.

For example, integer value is 222 and string contains “ĞİÜ”. If the customer uses ISO-8859-9 to keep Turkish characters unchanged, binary repr. of 222 changes to question mark, instead of Ş. However, if he uses ISO-8859-1, 222 is written as Ş but the Turkish characters are changed to nearest characters, for example, Ğ changes to G, İ changes to I (however, strangely, Ü stands same).

This really shows the most fundamental problem with code pages and multilingual text, doesn't it?

There is no one code page that contain all the characters in Unicode, with the exception of:

• GB18030 (which promises a 1-to-1 mapping with Unicode),
• UTF-16 (which is what Microsoft calls "Unicode"), and
• UTF-8/UTF-32 (the other encoding forms of Unicode)

Any time you try to use some other code page, there are tens of thousands of characters that will not be able to survive the operation....

One last point of interest -- Ahmet's observation that Ü strangely is not affected. This is not all that strange, since both ISO 8859-1 and ISO 8859-9 both contain Ü in them -- these code pages really were designed to support various languages and that is a letter that happens to be used by several languages (in the case of this letter at a minimum both German and Turkish use it, though there are several others!).

This post brought to you by Ü (U+00dc, a.k.a. LATIN CAPITAL LETTER U WITH DIAERESIS)

To me, fractions will always have a special place. The teacher pointed out we all knew what ½ was, and we all knew what 0.5 was, and we all knew about division. Then he blew my mind when he pointed out they were not connected because they were multiple things to memorize, but because they really were the same thing.

Fractions are the first time I saw math operations as all being connected. And it mostly because that one teacher was the first one to teach it that way (and the book didn't, it was him). I hope the books are better now, since I think my old teacher is retired....

He also was the first person I remember telling me that fractions were our friends. I think I almost believed it at the time, as it got me realizing that math had the potential to be cool.

Thanks, Mr. Snodgrass!

Anyway, back to fractions.

In Unicode, there are a whole bunch of fractions encoded. Here they are in numeric order (something not even Shell number sorting will do for you!):

That last column is really interesting -- it is the name of the character in Unicode 1.0, prior to the merger with ISO 10646. Name changes were done to go along with particular preferences in 10646, which in most cases related to compatibility with other ISO standards that involved names nad inother cases involved particular conventions.

Though I have to wonder how we are going to get the next generation of kids interested in considering fractions to be their friends if we spend all of our time telling them that fractions are vulgar!

Now all of these characters are really thought to be compatibility characters -- the "right" way to do fractions is to use regular numbers and U+2044 (FRACTION SLASH) between them...

Which would perhaps explain why they are vulgar? :-)

Actually, the reason they are called vulgar is apparently that the reference glyphs use diagonal slashes rather than horizontal bars. Though the two different ways to write fractions are considered glyph variants of each other (as they should be, since they are). Which means that a font developer can use either way to show them.

There are other standards that actually do try to distinguish between them and encode both -- for example the ones in the DPRK (which caused for some interesting discussions in WG2 and UTC when the DPRK additions to Unicode were being discussed back in 2001, with interesting conversations about variations selectors, if memory serves. I do remember that no one from UTC wanted to encode that extra set of fractions.

In any case, I guess the moral of the story using the principles of logic is that your friends are vulgar (which actually was an alternate title I considered for this post)....

This post brought to you by  ⁄  (U+2044, a.k.a. FRACTION SLASH)

Serdar asked:

Hi,

Is it possible to call GetLocaleInfo in a different language? What I’m trying to do is as follows:

• Installed a Vista English machine.
• Installed German and Spanish language packs.
• UI language is set to English.
• Want to learn what “German” (language name) is in Spanish.

I believe I can do this by loading kernel32.dll and using FindResourceEx to find the language I want. However, I just wanted to learn whether there is a shorter way.

Thanks,
Serdar

A very good question. And although the FindResourceEx route will work, it has several challenges:

• The format of string resources (though I have mentioned code that Raymond has provided to make that easier)
• The strings are in a special internal format that uses $ delimiters around items with no documentation on the meaning or format

A much cooler way was suggested by Erik Fortune (the MUI development manager):

If GetLocaleInfo follows the UI language, you should(*) be able to set the thread language to “es-ES” and call GetLocaleInfo.

-- Erik

(*) I haven’t actually tried it and can think of a number of ways it might break, but it’s probably your best bet.

It actually does work (though Erik's response may seem to be a blatant contradiction to the first tester's axiom, though in truth the scenario was tested by others so the fact that he had not tried it was just a good reason for a disclaimer!).

All of the following LCType values for GetLocaleInfo/GetLocaleInfoEx can be expected to return localized results that could be impacted by changing a thread's UI language:

• LOCALE_SCOUNTRY
• LOCALE_SLANGDISPLAYNAME
• LOCALE_SLANGUAGE
• LOCALE_SSORTNAME

As a fun experiment if you have lots of UI languages installed, you can compare the first three values to the following values for that locale in that language:

• LOCALE_SNATIVECTRYNAME
• LOCALE_SNATIVELANGNAME

Any time the translation is different, you have found either a localization bug or a core bug! :-)

This post brought to you by ྅  (U+0f85, a.k.a. TIBETAN MARK PALUTA)

BLOG OWNER'S NOTE: All comments to this post are now moderated to keep the volume down. You can post to another blog if you have further comments....

If you don't care about Jet or DAO or Access then this is a post you can skip! 

This post is a reposting of an article written over seven years ago, and is still entirely true.

A few versions ago, the Access team started formally backing away from de-emphasizing DAO and once again was adding it to default references in new databases.

As a culmination of this slow change, the updated version of DAO that is specifically used by Access 2007 and ACE is now once again under active development.

Proof positive that rumors of DAO's (and Jet's) death were greatly exaggerated? :-)

Microsoft has clearly positioned ADO as the replacement to DAO.... many Microsoft representatives have gone to far as to state that DAO is DOA (Dead On Arrival, a term used in the US to describe people who are dead when an ambulance arrives hoping to take them to be saved). HOWEVER a lot of core functionality is supported in DAO that ADO/ADOx/JRO do not support, and might never actually support since Microsoft seems to be pushing customers in other directions. While Jet itself will not "die" it is clear that it is no longer a strategic platform, so there simply does not seem to be enough interest to make things work more effectively in Jet.

Here, for the full record, is a list of all of the capabilities DAO has that ADO does not:

• Running transactions that use multiple databases (works in DAO since transactions are at the Workspace level, fails in ADO since transactions are at the Connection level -- and Connections only support one database)
• Opening a table in a mode that keeps others from opening it read-write mode (works in DAO through use of the dbDenyWrite constant, fails in ADO at the table level since its closest analogue adModeShareDenyWrite only can be set at the Connection level).
• Opening a table in a mode that keeps others from opening it at all (works in DAO through use of the dbDenyRead constant, fails in ADO at the table level since its closest analogue adModeShareDenyRead only can be set at the Connection level).
• Creating users and groups in a way that allows you to recreate them in case an MDW file is lost (works in DAO using CreateUser/CreateGroup which allow you to specify PIDs, fails in ADO which does not allow you to specify PIDs).
• Securing Access project objects such as forms, reports, or macros (works in DAO through the Permissions property on Document objects, fails in ADOx because it does not properly map the expected constants for permissions to execute, read changes, and write changes to these object types).
• Ability to create a linked ODBC table that is updateable (works in DAO through its call to the SQLStatistics function, fails in ADO which makes no such call).
• Ability to create "Prevent Deletes" replicas (works in DAO by passing the value of &H4 to the CreateReplica call, fails in JRO, which has no such analogue).
• Method for determining folder information from Exchange/Outlook folders and columns (works in DAO through the Attributes of the TableDef/Field objects, fails in ADO since this information is not passed on).
• Capability to set and change Jet options without making registry changes (works in DAO through DBEngine.GetOption and DBEngine.SetOption, fails in ADO, which has no such analogue).
• Allowing the creation/change/deletion of any and all properties through the JPM -- also known as the Jet Property Manager (works in DAO through CreateProperty/Properties.Append, fails in ADO/ADOx/JRO for almost all properties since there is no hookup of the JPM to ADO).
• Forcing the locking mode of a database when working from within Access (works in DAO through the DAO.LockTypeEnum constants while using CurrentDb, fails through the ADO.LockTypeEnum constants while using CurrentProject.Connection).
• Retrieving implicit permissions on an object (works in DAO through the AllPermissions properties, fails in ADO which has no AllPermissions property and requires you to separately enumerate the user and all of their groups).
• Allowing a separate Jet session to run using a special object in the object model (works in DAO through the PrivDBEngine object, fails in ADO due to no analogous object).  

This post sponsored by Ｄ (U+ff24, a.k.a.FULLWIDTH LATIN CAPITAL LETTER D)

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)

(no, this post is not about a rap or hip hop song, or its lyrics, though I admit the title may have been inspired by one, just like last time)

Looking at Larry Osterman's post yesterday entitled How do I compare two different NetBIOS names?....

(A nice brief history of a feature with piss-poor international support that even to this day resists all efforts to improve, by the way!)

The actual question that prompted the "simplified" question that Larry covered was interesting on its own and I wanted to talk about it a bit.

There was a need to compare two computer names, but one of them was UTF-16 and the other (like all NetBIOS names) is in CP_OEMCP. And the question was how to do the comparison....

Obviously there are two possible ways:

1. Convert the UTF-16 name to CP_OEMCP and compare them;
2. Convert the CP_OEMCP name to UTF-16 and compare them.

In both comparisons, one is wanting to use that whole "uppercase+binary" kind of ignore case comparison that we all know and love.

Given the complications in doing the case insensitive binary comparison in an arbitrary code page, it is much better to go with choice #2 (where there is just the one case table to deal with and there is a handy CompareStringOrdinal function to do the actual comparison with).

In this particular case they were in a position to instead consider calling RtlEqualUnicodeString directly rather than CompareStringOrdinal or even RtlCompareUnicodeString, which has the bonus of being even faster (though it would be hard to call it enough times to notice the difference making the performance issue most likely theoretical, the function has the benefit of doing exactly what they are looking for (this is the whole issue I talk about in Is RtlCompareUnicodeString used correctly?, where the answer is that by and large, it isn't!).

Of course fixing the NetBIOS/computer name story to do better than an OEMCP world would be even better, but that seems a lot less likely. :-(

This post brought to you by ỗ (U+1ed7, a.k.a. LATIN SMALL LETTER O WITH CIRCUMFLEX AND TILDE)

Remember when I pointed out how One day, your huddled masses, yearning to breathe free, might have to speak English?

Well, as Raymond points out in this post, Germany looks to be even further along in their process of smacking down on immigrants who aren't learning the native language....

Of course the amazing part is the nature of the EU/non-EU distinction being made, especially with countries that are currently candidate countries, such as Turkey.

So let me get this straight.

If Sarkozy calms down and Turkey becomes a member, then suddenly Turkish is okay, but for now despite the huge immigrant population that was invited, they have no choice but to go learn German?

Sigh....

This post brought to you by U+206e, a.k.a. NATIONAL DIGIT SHAPES)

Sometimes, women confuse me.

The conversation was kind of rambling along between different topics. Randomly. Like associative linkage, but between different people.

Suddenly one of them asked me a question.

"You eat bell peppers, don't you?"

"Why yes," I responded, kind of surprised at the non sequitur. "I do."

"Red, yellow, and orange?"

"Yes, all of them. Though I like the red ones best."

"Can you tell the difference between how the three of them taste?"

I am momentarily surprised. Was this some kind of verbal trap?

Sometimes, women confuse me.

"Yes, " I said cautiously. "Can't everybody?"

One of them turned to the other with a meaningful look.

"I told you!" she laughed.

Then the food came and I never found out what the hell the thing with the peppers was all about.

I guess it isn't important.

But doesn't everyone think that different kinds of bell peppers taste different?

Sometimes, women confuse me.

This post brought to you by ⍾ (U+237e, a.k.a. BELL SYMBOL)