by Michael S. Kaplan, published on 2008/12/04 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/12/04/9173920.aspx
VB expert and long time compatriot/comrade Bill McCarthy asked over in the Suggestion Box:
Hey Michka,
Can you tell us why ImmGetDescription seems to return zero length on Vista ? Is it broken ?
Thanks.
It's funny how many people still know me as Michka
Including me. :-)
Questions like this might bring up a "greatest hits" kind of issue in your mind.
I mean, after blogs like Sprechen Sie IME? and And you think finding presidential candidates is hard? Try getting the Vista IME candidate list!, it is obvious that I have tried to make a point of pointing out how TSF broke a bunch of IMM stuff.
Since it did break a couple of interesting edge cases....
This case is due to an issue I somewhat indirectly described in That's no gap, dear; that's a huge freaking chasm!, where I said:
There are now a huge ton of IMEs that do not follow that "E" prefix rule, since their support is entirely through TSF now.
You may wonder why I am pointing out this in particular....
I'll explain by revealing secret information. You know, like in the spirit of 15 million lines of Windows code revealed...., Here are two lines olf source from the ImmGetDescriptionW function:
if (!IS_IME_KBDLAYOUT(hKL))
return 0;
Wait, that won't help. I'll have to reveal one more line of source -- the definition of the IS_IME_KBDLAYOUT function:
#define IS_IME_KBDLAYOUT(hkl) ((HIWORD((ULONG_PTR)(hkl)) & 0xf000) == 0xe000)
Ah, so we have that same 0xE0000000 problem in our code too! :-(
And now that every single inbox IME uses TSF -- the Text Services Framework -- (one way or another), unless you install a version of Office that includes those hooks to make Text Service Framework TIPs look like old style IMEs, the ImmGetDescription function is pretty much gonna be determined to fail, since there is a lack of a process that tries to artificially put the HKL values into the place that the old architecure used to put them as a design principle.
In the end, the ImmGetDescription function looks like just another victim on the IMM side of the IMM to TSF migration....
This blog brought to you by ! (U+0021, aka EXCLAMATION MARK, aka Exclamation Point, aka Bang)
Bill_McC on 4 Dec 2008 10:13 PM:
Thanks Michka :)
That's weird. If I call ImmIsIME it returns true, yet ImmGetDescription calls to IS_IME_KBDLAYOUT which says it isn't IME. And this is on Vista, where I select Japanese keyboard with Microsoft IME, I think GetKeyboardLayoutList gives me the hKL as 0x04110411. No "E" there. Sure does seem broken.
But the good news now is if anyone searches for ImmGetDescription google lists this blog entry first (currently). ;)
Thanks again :)
Michael S. Kaplan on 5 Dec 2008 12:49 AM:
It (kind of) makes sense since ImmIsIME uses other techniques. But it does seem like (if nothing else) they horribly broke expectations in the move to make all the IMEs uses TSF instead of IMM (given the huge amount of IMM-based code out there)....
The fun part is that it looks like this broke because it never was changed -- this code pretty much looks the same from back when its assumptions were always true. Just goes to show us as great object lesson in software dependencies!
Michael S. Kaplan on 5 Dec 2008 1:14 AM:
And of course, any time! :-)