Keyboards under LUA

by Michael S. Kaplan, published on 2006/06/27 12:13 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/06/27/648618.aspx

People have been noticing that attempting install an MSKLC-generated keyboard layout on Vista has some problems. Say you take your handy dandy custom Bulgarian keyboard created by MSKLC:

You try to double click on the Bulg.msi file, and you may or may not get the LUA dialog:

However, whether you get it or not, and no matter which option you choose if you do, the final result is unfortunately the same. :-(

Now it may or may not be a bug that if you are running a recent enough build to get the LUA dialog that clicking "Allow" doesn't allow the install to proceed. We'll figure that out later.

Just run from an elevated command prompt, by right clicking on the Comand Prompt option on the Start Menu and choosing to Run as administrator:

you will then have a command prompt that you can run Bulg.msi from, and it will install just fine!

Now LUA (Least-privileged User Account) or UAC (User Account Control) is serving an important purpose here -- to make sure that you are okay with the changes this installer tries to make to your system -- a file in your system32 directory, and registry keys under KEY_LOCAL_MACHINE. So it is a pretty invasive little bugger, an MSKLC generated keyboard layout install. The key is making sure that you give it the right permissions to get its work done. :-)

Now the other question, the one I tabled earlier -- whether, if you say "Allow" to a LUA dialog should it still fail? I assume this would be a bug (the same thing happens if I run msiexec /i Bulg.msi from an unelevated command prompt). Probably someone ought to fix that. :-)

It's because your custom action (CA) is impersonating the invoking user, which is the default behavior unless you OR msidbCustomActionTypeNoImpersonate (0x0800) with the Attributes column in the CustomAction table. So, the CA will run with permissions of the non-elevated user which won't be able to write to locations that the RegisterKeyboard.E22081490D44493C878A575C57EFDC36 CA will attempt to do.

In fact, those custom actions should be deferred and should have corresponding commit (if necessary - probably not) and rollback CAs if they fail. Immediate custom actions should never modify machine state because they can't undo changes if an error occurs during the deferred installation (where machine state is supposed to be changed).

In fact, your MSI generation doesn't output the _Validation table and doesn't set the Template summary property to the correct language corresponding to the ProductLanguage property in the Property table. You should run ICE Validation (in Orca, from the Tools->Validate menu).

Hi Heath,

Ok, this is very good info. And the bug is definitely back on the MSKLC-generated install package, not on Vista.

Stuff to change for next version.... is there an OpenLanguage PM reading comments here? :-)

Thanks!

Instructions for installing MSKLC-generated keyboards in Vista very clear and useful. Sincere thanks!

Want an .msi to run English, French, Italian, German, Danish, Swedish, Spanish and Portuguesewithout changing layout? Didn't think so: go to http://tagg.org/zmisc/KbdPT01.htm...

Thanks again for this. I have to write stuff in English, French, Swedish and Italian, so the DOS "Run as administrator" work-around was great. Now I can do

~` !1 @2 #3 $4 %5 ^6 &7 *8 (9)0 _- += Qq Ww Rr Tt Yy Uu Ii Oo Pp {[ }] Aa Ss Dd Ff Gg Hh Jj Kk Ll :; "' Zz Xx Cc Vv Bb Nn Mm <, >. ?/ plus Á À Â Ã Å Ä Æ Ç Ð É È Ê Ë Í Ì Î Ï Ñ Ó Ò Ô Õ Ö Ø Œ Š Þ Ú Ù Û Ü Ý á à â ã å ä æ ç ð é è ê ë í ì î ï ñ ó ò ô õ ö ø œ ß š þ ú ù û ü ý ÿ ¡ ¿ ‘ ’ “ ” « » … ¹ ² ³ ¼ ½ ¾ ‰ ° ª ¶ § † ‡ ¬

without having to change keyboard layout. The *.msi download is at http://tagg.org/zmisc/KbdPT01.htm for the amusement of any other insane scribal polyglot.