Foreword

A long time ago Active Directory and Windows Installer technology were quite new. Group Policy based software installations was the greatest thing since setup.exe and Windows system administrators wished that software vendors would ship their products as msi packages. Some vendors adopted new Windows Installer technology early and some even succeeded to provide useful msi packages for system admins to deploy. Some vendors were not that successful and you could face problems like missing Install Source when software was installed from CD or msi packages that couldn't be deployed with GPO Sofware Installations extension. Administrators made furious repackaging with the few tools that were available at the time. Fortunately repackaging and msi authoring products got better and better and more software was available as an msi packages. 

Shipping the software as an msi package is very vague definition. Worst case is when the msi package has been authored so badly that the install - or uninstall - totally mess up the computers. If a product won't get installed - or uninstalled - the value of the msi package for administrator is close to nothing.

When working with enterprise scale software deployments it is always a pleasure to meet a well authored msi package. Sometimes you can see that software vendor has done their homework and put some effort to provide smooth installations. Enterprise admins don't need fancy user interfaces and setup wizards but a working silent installation and full customization possibilities. If a software vendor provides a good deployment guide then the deployment process can be almost a pleasure.

When I have a new msi package at hand I always open it with InstEd, which is an excellent (and free) msi editor. A quick look to a few tables like Property, File, Registry and Custom Action tells a lot about the package. Sometimes I'll discover the horrible truth that the msi package is nothing but a wrapper and is loaded with tons of custom actions. Sometimes the package, however, is even better than what you expected.

User Interface language in Tracker Software PDF-XChange Viewer

Recently I was preparing a version of Tracker Software's PDF-XChange for deployment. Among other things, PDF-XChange contains a pdf-exporting print driver and pdf viewer application called, surprisingly, PDF-XChange Viewer. Viewer application has been localized into many different languages as well as in Finnish. The language support is built into the software so you can select UI language on the fly, which is of course a nice feature.

What has always disturbed me is that Viewer selects the default UI language based on System Locale - which is wrong. In our environment Windows user interface and all the applications are in English by default but the System Locale is set to Finnish. If a program uses System Locale infromation for the UI language this results in strange two language mixup. We also have users who don't know Finnish too well to find out where to change the UI language so English should be default. If user decides to change the UI language in PDF-XChange Viewer - or say in Microsoft Office - it is completely fine but it is the user who makes the decision - not the program.

Picture 1: PDF-XChange Menu item: Edit | Preferences in Finnish

Picture 2: PDF-XChange User Interface Language selection

I had previously noticed that the Viewer msi didn't have any logic to set the default language so I was quite happy to see that the new version introduced VDEFLANGID property which defines the REG_DWORD registry value "HKLM\SOFTWARE\Tracker Software\PDFViewer\International\LocalID". 

Picture 3: PDF-XChange MSI package Registry Table and the use of VDEFLANGID Property 

So clearly there was a property you could use to set the default language. The problem was that I had no idea what should that value be. So I installed PDF-XChange into a test machine, set the UI language to 'English (Default)' and checked the above mentioned registry value. Like always when inspecting changes some software makes to the system I also had Process Monitor running while doing the changes. I was happy to see that UI language selection process first checks if a user had registry value "HKCU\Software\Tracker Software\PDFViewer\International\LocaleID" and if it is missing then the equivalent value was read under local machine hive "HKLM\SOFTWARE\Tracker Software\PDFViewer\International\LocaleID" and copied into user's registry hive. Whatever UI language choice users makes after that the value was written under the HKCU hive. A great example how the default setting (or a preference) and user's setting should be implemented.

After I had changed the Viewer UI language to English I looked at the LocaleID registry value with regedit and noticed it had a value 0xffffffff. 

 

Picture 4: User Interface Language under Current User's Regisrty

So I was quite sure that the VDEFLANGID Property should be 0xffffffff to get the UI language in English by default. I opened msi package with InstEd, created a new transform, added the value to property, saved mst and finally did a test deployment using command prompt launched up as a Local System account.

You sharp-eyed readers may already have noticed a small anomaly here. Viewer application uses registry value LocaleID but the msi creates a value LocalID. I didn't notice this while I was editing the msi and I was quite dumbfounded to notice that the UI language setting had actually no effect. Viewer's UI was still in Finnish although it should have been in English. So I once again launched Process Monitor and after setting up the filter for PDFXCview.exe I almost instantly noticed the problem. As we can see from the picture below there was no such value as LocaleID in the registry (NAME NOT FOUND) - but with Registry Editor I could see that I had value named LocalID in the regisrty. 

Picture 5: Process Monitor and NAME NOT FOUND for LocaleID

I manually created a new registry value with correct name LocaleID and deleted PDFViewer registry branch from user's registry hive to mimic the situation where user hasn't used Viewer before. The next time I started PDF-XChange I was happy to see that the UI language was finally set into English and Process Monitor proved myself that the registry value was read.

 

Picture 6: LocaleID correctly spelled under HKLM

Picture 7: Process Monitor and SUCCESS for LocaleID

So I edited the previously built mst file with InstEd and added the LocaleID registry value name fix into it. 

Picture 8: PDF-XChange MSI opened in InstEd and LocaleID fixed using MST

I made a new test installation and at last the default UI language selection was working and I was finally ready to deploy the program. There was still some Finnish localization left in the Viewer's Menus Shortcut information (VAIHTO when there should be SHIFT), but I guess we can live with it. 

Picture 9: PDF-XChange User Interface Language in English - almost completely...

I reported the LocalID bug to the vendor, even got a reply and found out that the spelling error was fixed in the latest release.

Have a nice new packaging year,

Mikko Järvinen