February, 2007

(This could probably get turned into a series with various terms....)

A very common question that comes up in internationalization circles is some variation on:

How can I get GB18030 characters to test in my application?

As questions go, it sounds like they are thinking more about repertoire than about text actually encoded as GB18030. Like their own little repertoire fence!

So the easy answer is to point out that since GB18030 is a PRC China standard that is completely tied to Unicode and thus any character that is a "Unicode character" is also a "GB18030 character". As fences go, it is not very limiting, after all....

That is also almost certainly not the answer they are looking for, since they weren't really asking the question in a very good way.

Let's take a step back and try and figure out what they might really be trying to ask.

Now it is all well and good to think that China cares tremendously about every single code point in Unicode from U+0001 to U+10ffff, but in practice we know that is not true. We know that they have priorities, just like we all do.

There are actually two meanings that are most commonly intended, and every single one of the 81 emails I have seen over the last year with the phrase "GB18030 characters" referred to one or both of these definitions.

Definition #1: "GB18030 Characters" is an alias for Unicode Extension B Characters. (Warning -- that link is to a 13mb PDF!)

This definition is from people who are looking to make sure that their application supports supplementary characters, like these ones in the Supplementary Ideographic Plane (more info on this name here). These characters are important to China, even though many of them are not actually used in China other than in very rare contexts, if at all.

This is not a foolish question, you know. I mean, this is a set of characters that Windows 2000, Microsoft Jet, SQL Server <= 2000, and lots of other products don't support. So if someone is asking about how to get characters to test in their application then this is a good thing. :-)

Definition #2:  "GB18030 Characters" is an alias for Chinese Minority Scripts, e.g. Mongolian, Tibetan, Uighur (which means Arabic), Yi, Phags-Pa, New Tai Lue, Tai Le, etc.

This definition is from people who are looking to make sure that their application supports the various scripts used throughout different minority languages in China. Now these characters are also important to China, if for no other reason than they want to be able to show the native speakers of the languages that use them that the scripts are important to China. There are several parts of the world where this phenomenon occurs, and in a future post I will talk about some of the side effects of it....

In any case, this is not a foolish question either, as the majority of these characters, in addition to not being supported in Windows 2000, Microsoft Jet, SQL Server <= 2000 and so on, are also not supported in Window XP, Server 2003, or even the .NET Framework 1.0 or 1.1 (they are not supported/supportable in the .NET Framework 2.0/3.0 either, unless you are running on Windows Vista).

So why do people ask the way that they do?

Well, usually they have GB18030 compliance of their product on their minds, and thus they want to know how to make sure that they are in fact compliant. The easiest way to do that is try out some of these characters.

Since the question is not foolish (even though it is ill-formed), I always try to find out what they are actually asking, so I can point them the right way....

This post brought to you by ꡀ (U+a840, a.k.a. PHAGS-PA LETTER KA)

Over in the Suggestion Box, Ritesh asked:

I do not know wheather it is right place to post my query but i am doing it hoping that u may find it a valid one .

Please find my query below:

If a font is having Latin script and it consists of languages like english, german, etc . Then if user input some unicodes belonging to latin script, and instead of using any default language, we want to force that we will use german, then how can we attian this by using uniscribe.

Another example in support of my question:

We know that hindi, marathi and nepalee, all belong to devanagri script and assuming that these all language are present in single font .Each language will be having the gpos and gsub rules according to the language so it can be a case that a cluster can give different glyphs based on language.

So my question is that, if i want to use nepalee instead of hindi on particular set of unicodes, then how can we attain that using Uniscribe or usp10.dll.

Thanks in advance.

Regards
Ritesh

This feature is indeed possible to support via Uniscribe, by making use of three new Uniscribe API functions mentioned in this post:

• ScriptItemizeOpenType (the update to ScriptItemize)
• ScriptShapeOpenType (the update to ScriptShape)
• ScriptPlaceOpenType (the update to ScriptPlace)

An example of the info to include for language specific information is given in Developing OpenType Fonts for Devanagari Script, particularly Appendix A (Writing System Tags) which includes the following table:

Note: both the script and language tags are case sensitive (script tags should be
lowercase, language tags are all caps) and must contain four characters (ie. you
must add a space to the three character language tags).

An analogous table exists for the standard scripts in this other Appendix, which takes care of situations like German and so forth....

This post brought to you by ᭴ (U+1b74, a.k.a. BALINESE MUSICAL SYMBOL RIGHT-HAND OPEN DUG)

Cory Nelson asked in the Suggestion Box:

I've often seen chat programs and thought "wouldn't it be wonderful if this supported per-language fonts like IE does?"

So here my question is: how does IE work this magic?

Internet Explorer, going all the way back to 4.0 I believe) has been doing this through MLang and it's IMLangFontLink interface's support of font linking.

This is something I previously mentioned here (not to be confused with either GDI font linking or font fallback, both of which are contrasted with each other here).

Easy! :-)

This post brought to you by ␐ (U+2410, a.k.a. SYMBOL FOR DATA LINK ESCAPE)

Thinking about the issues involved with à ≠ a (unless à = a) made me think back to other posts where I mused about possible improvements in the search experience, such as posts like What about search for kids?, to give an example.

No one from Google or Microsoft or anywhere else seems to be taking any of the suggestions I have made over the past couple of years (hell, they won't even fix bugs like this one so if they have no time to fix bugs then they clearly have no time to take suggestions!).

But let's pretend for just a moment that I am

• smart enough to think of good ideas,
• widely read enough that the right people might be reading, and
• influential enough to get the right people to think about implementing ideas

for a moment, even though only 33⅓% of it or less of those points might actually be true. :-)

Now the fundamental reason why someone who is French might want to be able to look for e and find é while a Swede might be bothered that looking for a would find å has nothing to do with greater sensitivity for language; it has to do with the same issue that drives the fact that You can't ignore diacritics when a language does not give them diacritic weight.

(This same point was made in the comments of the first post such the one from Wilhelm)

In the end, the French sort treats é as an e with a bit of extra weight on it just like someone speaking English might while the Swedes treat å like a whole different letter, just like the Polish will treat ą like a different letter and so on. The way people think about language drives not only how they might expect search to be able to work but also how annoyed they will be if their expectations are not met.

These preferences do not always align with the content language since on the Internet they could be searching for anything. Perhaps a Dane will be less annoyed about a mistake related to ä if the content is not Danish, but they may still be a little annoyed at being mistaken for Germans (or even worse for Americans!), even if the annoyance is subconscious.

Now currently, search engines let people choose preferred languages for content, but there is no notion of preferred language bias for search that is separate.

This is bad thing for MANY Latin script, Cyrillic script, really any script shared between languages with different ideas on how collation ought to work. And no one seems to be able to handle the notion. worse, no one seems to even realize the notion exists.

Yet with simple knowledge of the "language world view" that a person has it would be much easier to help them both find what they want and not be given results that clearly do not match.

Beyond that, and thinking to the questions Laurent raised, are there additional options that could be made available?

For both ideas, it is not a simple matter of wanting or not wanting to conditionally ignore diacritics; no one would disagree that if you do include the diacritic you probably want them preferred. The real question is how you feel about the non-diacritic letters in those cases,and how you feel about both kind of letters when you search without the diacritics.

Add to all of this the fact that very few people can describe their preferences here, for good measure.

Okay, now that I have some of the ingredients in the pot, I'll let them simmer in your minds for a bit. So if you were the one on the hook to talk to Yahoo or Google or Microsoft or whoever (or if they were reading here), what would you tell them? How would you tell them to try to improve the International search experience?

I am not going to claim that Microsoft is doing better here, because as far as I can tell, EVERYONE sucks at the moment. The search for the people who can do the right thing here for search is still on....

This is as topic I will be coming back to, in other collation-type contexts as well. :-)

This post brought to you by ä (U+00e4, a.k.a. LATIN SMALL LETTER A WITH DIAERESIS)

(You can probably skip this post, which has nothing technical though it gets positively anal retentive about a technicality!) 

Over on Lifetime, a Grey's Anatomy re-run from the first season (Save Me) was on. In this episode, a Jewish patient does not want a porcine heart valve due to Kashruth concerns. Yet she is happy to hear that there is the option of a bovine valve, instead.

I have trouble with the painting of the issue here. Rabbinic law is pretty clear that the dietary laws are separate from what is allowed in medicine, but if one as a matter of personal choice does not want to go that way then that is fine. But what are the odds that someone would feel so strongly about this yet not have any concern about the fact that the cow whose valve is being used was almost certainly not killed in the proper ritual manner to be considered "Kosher" either?

I guess one could claim there are degrees here, that using a non-Kosher bit of cow is not as bad as a never-Kosher bit of pig. But if one is truly extending the law to past what even those who try to interpret that law would extend it, should it not happen consistently? Is there a market for properly "slain by a Shochet" cows for use in transplants?

It would have at least been worth a joke -- like Alex commenting among the other doctors away from the patient that the cow was probably treif anyway....

Ah well, this isn't the show for accurate medical depiction, why should it be the one for accurate religious depiction? :-)

John Cowan's question about Unicode was a deceptively simple one that many people have likely wondered about in the past:

What's the etymology of "Unicode"?  Does the prefix represent unity
or uniformity?

It is the sort of thing that of course there were many opinions about. Mark Davis (president of Unicode) responded earliest and most amusingly:

Attested as far back as Gaius Plinius Caecilius Tertius, apparently derived from Indo-European *oino-kau-do ("one strike give"), *kau being related to such English words as: hew, haggle, hoe, hag, hay, hack, caudad, caudal, caudate, caudex, coda, codex, codicil, coward, incus. (I like the association with "haggle" myself.)

Mark

And Michael Everson responded "Universal".

While Jonathan Rosenne asked more cautiously "wasn't it unification?"

James Opstad volunteered:

Joe Becker came up with the term. I believe he intended it to mean "unified
encoding" but with echoes of "unique", but he can provide further
explication.

And Ken Whistler (the cool uncle of Unicode) suggested:

You'll have to ask Joe Becker for what all went into his
thinking about it, but I believe it is and was deliberately
ambiguous. The etymology is "uni-" + "code", with the
intent of "uni-" being to denote "one", and to connote
"unity", "uniformity", and "universality".

To which Asmus Freytag added:

as well as "unified" and "unique". Unified as in han-unification, for
example, and unique as in the ideal of having only one encoding and one
encoded value for each character..

There were a few distractions about UNIVAC and a Universal Telegraphic Phrase Book, and the father of Unicode (Joe Becker) responded rather quickly with the official answer, quoting a very old communication:

>From the archive:
--------------------------------
@Sender: Joseph D. Becker:OSBU North:Xerox
Date:  4 Dec 91 18:46:17 PST (Wednesday)
...
    Unique
    Nice
    International
    Consistent
    Official
    Desirable
    Encoding
...
Joe
--------------------------------

Then adding (in response to the many other posts):

... based on my recollection, from the ancient "Starving Students Handbook", of:
    The Perfect Meatloaf Recipe
      1. Serve the meatloaf
      2. Ask your guests what they think is in it
      3. Agree with anything they say

Nuff said? :-)

I will have to remember that meatloaf recipe, it reminds me in reverse about a serving of rattlesnake a few years back (a story for another day, perhaps)....

The mail I got read:

Hi

I'm Laurent Gébeau , FRench MVP on Windows. I met you at the last MVP summit in seattle, and learned a lot about localisations. Since that I love to read you blog , very instructive.

I'm actually using Vista on a daily basis, and got one issue : I'm not a very good man with ortograph, so I use to write words withouts accenst (é, è à ç ...).

And I can see that in Vista if I look for ete or ETE, it won't find été.

Another exemple (and that's the one which make me discover it : in control panel if I type reseau i don't find anything (should have been réseau).

Is it really expected (by design) or not really expected ? In my point of view I find this very bad .

I ve bugged it in beta of vista : # is 215797.

Thanks

Laurent 

This is for the most part completely by design, since there is a very elemental truth that

à != a

unless the comparison is done while ignoring diacritics, and sometimes not even then.

It is a challenge to balance on Windows the needs of users who want these distinctions to not be present and the ones who do (some in the latter group can even get quite offended by the abuse of language that ignoring the distinction appears to be, to them!).

One could argue that in search it makes sense to have the ability to ignore these distinctions as an option, irregardless of whether it is allowed in ordering or non-search identity questions. And indeed this is a very sensible idea for a search algorithm to consider, as an option. It is available in some applications such as Microsoft Word, and obviously it can be used programmatically in both managed and unmanaged code if you call the real collation functions from the NLS API or the SystemGlobalization namespace....

This post brought to you by à (U+00e0, a.k.a. LATIN SMALL LETTER A WITH GRAVE)

If you tune in here to read from time to time, you may recall some previous posts where I talked about repertoire fences, basically situations where one standard or one proposal (in those cases for code pages) was being used to get a better understanding of a different process.

This time I am going to extend that idea a little bit into some different areas.

First we will take ISO/IEC JTC1/SC2/WG2 N3168 (A Proposal to add new Hangul Jamo extended characters to BMP of UCS) -- before you click there, keep in mind this is an 83 page, 10.6 MB document!

Now this proposal is for 117 new Hangul Jamo to be used for a set of over 5000 Old Hangul found in an extensive review of many sources (the proposal specifically mentions that "We guess that there won't be many Old Hangul complex letters to be found in the future.", presumably due to the fact that the review was reportedly so extensive.

There are some technical issues in this current proposal which have been communicated to the Korean National Body to address. This would be for some future WG2 meeting, and I am actually not really going to talk about the proposal itself (which can wait for if and when an updated proposal would be submitted).

In the meantime, in looking at the proposal's 34 Choseong, 28 Jungseong, and 55 Jongseong new Jamo, it is clear that whether you want to encode these new complex Jamo or represent them as the separate, existing ones, that the presumably valid claim is that they all exist in historical data.

Now looking at Appendix B to the OpenType Hangul specification, of these 117 Jamo there are nine that are not included in the Appendix as sequences:

For what it is worth, these same sequences are missing from the Old Hangul collation tables, as well. And none of them currently exist as Jamo containing multiple components, either.

This would mean (assuming the evidence is sufficient for these nine "complex" Jungseong and Jongseong Jamo in the 72 pages of examples in the proposal) is that both the tables in Appendix B to the OpenType Hangul specification and in the Old Hangul collation data could stand to be augmented by these nine sequences, in order to allow for the proper collation and rendering of whatever percentage of the over 5000 Old Hangul syllables depend on them.

In the meantime, the storage of data would work properly, though the collation and rendering would not work as well as all the rest of the Old Hangul syllables.

For many this is a minor point given the current lack of a widely available font that makes use of Uniscribe's Old Hangul shaping engine.

But some people do have the font support, and other people may not want to wait when it comes to cataloging and storing data that makes use of such syllables. Which means storing valid data does not need to wait for the perfect font or for the perfect collation data (the current collation data will provide deterministic results and obviously the fonts will have some behavior, even if it is less than ideal (like in this previous post).

Yet another situation where repertoire fences can actually be used to allow the data in a proposal to assist in an implementation! :-)

This post brought to you by ᇰ (U+11f0, a.k.a. HANGUL JONGSEONG YESIEUNG)

Over on Channel 9, there is a very cool episode of Behind the Code, this one a conversation with Rico Mariani.

I actually got to be in the studio for this one (you can see me in the back in a purple shirt from time to time), which was an interesting experience. I even asked a question (not included in the posted version of the video), about the interesting performance consequences of that interesting set of threads related to performance of managed vs. unmanaged code that came up almost two years ago I pointed to here that involved Rico and Raymond Chen.

Definitely worth watching, and not just for his favorite data structure he talks about at the end. :-)

You can view or download the video here at Rico Mariani: Writing better, faster code.

Definitely worth a viewing or three!

This post brought to you by 𝇁 (U+1d1c1, a.k.a. MUSICAL SYMBOL LONGA PERFECTA REST)

Bart mentions over the Suggestion Box:

Continuing on the 'Wednesday, October 11, 2006 8:05 AM Michael S. Kaplan

Why can't the CP_ACP be UTF-8? ' topic.

We are currently looking into making something like unicows.dll.

Except that it intercepts calls to A functions and converts from UTF-8 instead of CP_ACP and calls the W functions. (and back ofcourse))

This is probably less work then converting our apps to use W functions. (third party components we can't replace is the biggest problem, that and delphi isn't strong on the WChar side)

Yep, Bart was following on to this post. :-)

As projects go, the one he is talking about sounds like a pretty interesting one. And not just because it is a much cooler version of the very MSLU project from my past, though I will admit that is a not insignificant part of it.

It is just amazing to think about in terms of how much easier it would be to accomplish, using the same automated means as the very first build of MSLU (the one that had none of the hundreds of special cases needed later to try to work around various Win9x bugs). I'd be able to focus on the more compelling side of the user messaging story, the sort of thing that there just wasn't time to do with unicows.dll.

I doubt I'd be able to convince anyone at Microsoft to sponsor it (not that I wouldn't be willing to try!), though in terms of how much work it would require, it would cost significantly less than trying to get the ANSI Win32 API to support UTF-8, a perennial topic of discussion it seems at times....

Assuming it wouldn't have to be written in Delphi of course, maybe I should ask Bart if he is hiring and take a short leave of absence? :-)

This post brought to you by 8 (U+0038, a.k.a. DIGIT EIGHT)

The question to the alias was something like this:

Hi

I hit a crash because of an argument exception. The text suggests a non-supported culture ID. I look at culture ID table and could not find ID 1124. This is an English W2K3 server with .Net 2.0. Any insight that caused this?

0:005> dc 00000000016612f8
00000000`016612f8  7881edd8 00000642 0000003e 00000034  ...xB...>...4...
00000000`01661308  00750043 0074006c 00720075 00200065  C.u.l.t.u.r.e. .
00000000`01661318  00440049 00310020 00320031 00200034  I.D. .1.1.2.4. .
00000000`01661328  00300028 00300078 00360034 00290034  (.0.x.0.4.6.4.).
00000000`01661338  00690020 00200073 006f006e 00200074   .i.s. .n.o.t. .
00000000`01661348  00200061 00750073 00700070 0072006f  a. .s.u.p.p.o.r.
00000000`01661358  00650074 00200064 00750063 0074006c  t.e.d. .c.u.l.t.
00000000`01661368  00720075 002e0065 00000000 00000000  u.r.e...........

So, I guess there are two problems here.

First -- don't use LCIDs, use locale names! LCIDs are provided for backwards compatibility with versions of Windows that only have LCIDs in them. Which brings us to the other problem....

Second - the locale in question that uses an LCID of 0x0464 is Filipino - Philippines (fil-PH), which was added in Vista and is not available in any version of Windows before Vista. So it will always fail if you try to ask for it by LCID in a version of Windows like Server 2003 (even if one added a custom culture for fil-PH, it still wouldn't have this LCID attached to it).

There is also an irony attached to all this, one that I will talk about soon. :-)

This post brought to you by ⵒ (U+2d52, a.k.a.TIFINAGH LETTER YAP)

(The Kramer vs. Kramer allusion doesn't work here really, something about the scansion I think?) 

You may recall when in two recent posts I wrote about two things that suck about CurrentUICulture.

Well, it turns out that the MapPoint Web Services SDK has managed to get half of the problem solved in their own version of the CultureInfo class contained in the MapPoint Web Service Class Library.

Their re-factored version has just two properties (Lcid and Name) certainly takes care of my concerns about the weight oft he object that I rambled on about in that first post.

Of course they managed to not only keep the screwed up name but add to the confusion by making its name identical to the other, different object while changing the case of 50% of the properties it supports.

And of course the docs with statements like "The default culture is English—United States." won't make a lifelong fan of me.... and neither will their puny list of Supported Languages.

I admit I was initially excited about an attempt to solve some of the problem, but I am not going to be shallow enough to find anyone or anything "classy" just because they shed a few pounds -- other flaws cannot be ignored....

This post brought to you by œ (U+0153, a.k.a. LATIN SMALL LIGATURE OE)

Developer Eric asked on one of the internal aliases:

The following code fragment to query the original filename of notepad.exe will set pValue to “NOTEPAD.EXE.MUI” on Vista. Is this expected? I’m apparently getting the original file name of the language resources. I was expecting to get “NOTEPAD.EXE”. Is this the standard for all MUI apps, or could some be built to return “APP.EXE” and others “APP.EXE.MUI” ?

dwSize= GetFileVersionInfoSize( “C:\\windows\\system32\\notepad.exe”, &dwHandle);
buf= malloc( dwSize);
GetFileVersionInfo( sPath, dwHandle, dwSize, buf);
VerQueryValue( buf, L"\\StringFileInfo\\040904b0\\OriginalFilename", (LPVOID*)&pValue, &uLen);

Thanks for any info.

To be honest I had no idea, but I forwarded it to the MUI dev team, and Sunggook knew the answer:

Yes, it is expected behavior on Vista with MUI’ized files.

The default behavior of GetFileVersionInfo return merged info of LN and MUI file. Fixed information from LN and variable from MUI. 

If you want to see LN file name like Notepad.exe, please use GetFileVersionInfoEx(FILE_VER_GET_NEUTRAL..).

And that does look to be the trick -- GetFileVersionInfoSizeEx/GetFileVersionInfoEx rather than GetFileVersionInfoSize/GetFileVersionInfo, using the appropriate flag to specify whether you want the language neutral resources or the localized ones....

Please note that GetFileVersionInfoSizeEx and GetFileVersionInfoEx are new for Vista and they only have Unicode versions, something that you will see more and more of as the team I am on communicates the need for this approach going forward, this way rather than this other way. :-)

This post brought to you by ꄰ (U+a130, a.k.a. YI SYALLABLE TUT)

(this post has no technical content and really no point, I am just going to blather about prime time soap operas a bit) 

So it looks like Comcast where I live finally deigned to pick up SoapNet. So some time over the next six months I'll be able to see those last few episodes of Beverly Hills 90210 and Melrose Place that I missed back when they were running on FX, before SoapNet got the exclusive for them.

The timing is interesting, as the showings of Dallas on SoapNet is just days (specifically this Friday and next Monday) away from what many consider the single biggest "jump the shark" moment -- that season cliffhanger where it turned out the whole season where Bobby was dead was actually a Pamela Barnes bad Mexican food nightmare - never mind the fact the stars all had lost their old hairdos, that unrelated plot points were not all dropped, that Victoria Principal's dream would not have covered the references in Knots Landing, and so on. It was just ridiculous, and no amount of work on the parts of the Katzman's horses and men were going to make it a clean shift. Final proof that bad writing does not redeem bad writing, and that two batches of dozens of wrongs don't make a right. :-)

Though technically for me, the actual shark jump moment happened after Pamela Barnes Ewing lost her fake Texas accent. And not just because it signaled the end of her time by the pool in every episode (though this was a factor given my age at the time, sorry!), but because it was the time that the whole point of the show shifted away from the whole Pam/Bobby marriage of the son and daughter of two families with a huge feud going on. It was never really a "Romeo and Juliet" type story except in a bit of the setup, but I doubt that the people who talked about it's Romeo and Juliet qualities ever really read the play anyway.

I guess the other weirdest moment for me in the show was when Ray Krebbs suddenly turned out to be Jock Ewing's illegitimate son. This was most weird given that Ray had previously been having an affair with Jock's granddaughter. They somehow decided to not talk about the fact that this meant Ray was sleeping with his niece (kind of a consummated version of the Luke/Leia relationship from Star Wars and the Empire Strikes Back). Did no one else notice this screwed up plot twist?

Now imagine if they had decided to be brave enough to USE that plot twist -- I mean, no one knew they were related, least of all them. So it would have been interesting as a plot development dealing with the screwed up consequences in the non Jerry Springer type venue of a prime time soap opera. I think they are just too chicken to take it quite that far....

I also guessed wrong about who shot J.R. possibly as I had a crush on Mary Crosby at the time (which lasted if I am remembering things properly until her appearance in the campy Ice Pirates) and could never imagine her doing such a thing at the time.

I guess you can see what I enjoyed most about Dallas -- spotting the mistakes of the writers within episodes, between episodes, within seasons, and between seasons. Though I can't imagine trying to do it all again and keep up with mistakes so I probably won't try to watch it again, especially since I have to work for a living and all. But I'll record those two episodes on Friday/Monday, just to see the whole "You look like you just saw a ghost" thing again....

This post brought to you by ䷿ (U+4dff, a.k.a. HEXAGRAM FOR BEFORE COMPLETION)

Some of you may recall the confusion surrounding localized paths in Vista that I mentioned not too long ago. The comments in that post made it clear that lots of folks had opinions about the design and that there was much confusion about how to get the localized information.

Well, confusion can now be over, as Ming Zhu, a dev on the Shell team, has stepped up and not only clarified the usage of SHGetLocalizedName but also provided some code to get the localized names as well.

I wanted to elevate his response

His comment and code are here, and I think this should help resolve some of the confusion here, if for no other reason than pointing to the right methods to be considering (namely IShellItem::GetDisplayName and IShellFolder::GetDisplayNameOf).

The methodology will work not only in Vista but in prior versions, too. Excellent! :-)

It might be nice to see the docs for SHGetLocalizedName fixed up to both make the limitations clearer (for most users this is NOT the function they want) and to point folks in the right direction for some of the more common needs people will likely have here. But for now I'll just bask in the glow of a great answer to a confusing question....

For the other questions raised in the comments from people wondering about the design, I think we can probably let go of those ones now (since it is too late to change the design anyway).

This post brought to you by ፨ (U+1368, a.k.a. ETHIOPIC PARAGRAPH SEPARATOR)