Application Compatibility

I was asked by a client today what the difference between a Microsoft MUI and a LIP. And, more importantly, "what were the application compatibility consequences of multi-language support?"

I thought I knew what a MUI was - the language and resource layer that you could add onto Windows XP and Server 2003 to fully support languages such as French, German and Spanish. I remember these resource packs well as when they initially appeared in my MSDN Select CD binder - I thought that they were a god-send. After spending nearly a year on getting Windows 2K to (properly) support Chinese (all three types including Big5) and Japanese (hiragana, katakana and Kanji) through 3rd party software such as Twin Bridge's IME, I was ready for anything.

And, Microsoft's own words, the MUI is defined as,

"Multilingual User Interface Pack is a set of language specific resource files that can be added to the English version of Windows Professional. When installed on the English version of Windows, MUI allows the user interface language of the operating system to be changed according to the preferences of individual users to one of the 33 supported languages".

OK, sounds pretty clear… Now, what is this LIP stuff?

Again, referencing TechNet, "Microsoft Windows XP Professional Language Interface Pack (LIP) is a high-quality, localized "skin" for emerging or minority language markets, such as Catalan, Lithuanian, and Thai.

And, what is the difference between a MUI pack and a LIP installation? Get ready as,

"The main difference is in the level of localization in comparison to MUI packages: LIP packages provide the desktop user with an approximately 80% localized user experience. In addition, LIP doesn't allow users to switch languages. Once a LIP is installed, all users using that machine will have the same User Interface (UI) language. "

So, in summary it looks like the MUI is a "switchable" comprehensive interface while the LIP is a 80% permanent installation.

References:

Windows XP Multi-lingual User Interface (MUI) FAQ's
http://www.microsoft.com/globaldev/DrIntl/faqs/MUIFaq.mspx#MUIques15

Application Compatibility and the Microsoft MUI
http://www.microsoft.com/globaldev/handson/dev/AppCompatInMUI.mspx

Microsoft LIP Frequently Asked Questions
http://www.microsoft.com/globaldev/DrIntl/faqs/lipfaq.mspx

Apologies for this late update to our core Patch Tuesday update. Here is a summary of the update ....

The November Patch Tuesday update from Microsoft follows the largest patch and security update in Microsoft’s history. This month there are six updates to Office, Active Directory and Microsoft’s Office application suite.

These six updates have a low impact, bar one patch to Excel which may cause compatibility issues for some applications. The main cause for concern here is that Excel is a primary if not essential element to many environments. For example most banking, trading floor and insurance platforms. Therefore any change must be tested rigorously.

Whilst there are few applications in our sample that are affected, the ChangeBASE AOK team recommends that the Excel update (MS09-067) requires particular attention in any environments where there is a significant dependency on this,

We have included a brief snap-shot of some of the results from our AOK Software that demonstrates some of the potential impacts on Microsoft Office deployments with the following picture.

Testing Summary
MS09-063 : : Marginal impact and negligible testing profile
MS09-064 : : Marginal impact and negligible testing profile
MS09-065 : : Marginal impact and negligible testing profile
MS09-066 : : Marginal impact and negligible testing profile
MS09-067 : : Moderate impact and negligible testing profile
MS09-068 : : Marginal impact and negligible testing profile

The full posting of these results can be found on;

http://www.changebase.com/News/NewsPage.aspx?page=20091110-01_PatchTuesday.xml&style=~/Style/PatchTuesday.xsl

Handling INI files can be a little tricky these days when you have to consider new security restrictions, virtualized environment restrictions (App-V and Citrix) and legacy applications that don't install the way they should... Or, more importantly stay installed the way they were intended to.

INI files are configuration files used to store application, user or machine information. They have been used for the past 10 years and have been used really well (by Microsoft) and abused by some (IBM's Lotus Notes) to store information and help configure applications.

There is a reasonable definition of INI Files located here;
http://encyclopedia2.thefreedictionary.com/INI+file

The reason I making this post is that INI files are causing some considerable issues with Windows 7, Citrix and App-V deployments. Application installations are installing and configuring INI files in semi or secure locations and either the user or the application is not able to properly read and/or write to these text based configuration stores. For example, under SoftGrid, the application will install correctly but when a user tries to run the application, critical information is either not stored or captured during the normal application loading/running process.

There are a few solutions;

1) Employ the MoveIniToRegistry Shim
Chris Jackson has an excellent posting on this technique found here
Http://blogs.msdn.com/cjacks/archive/2008/01/03/stock-viewer-shim-demo-application.asp

2) Use INIFileMapping
Frig (i.e. Hack) your local security settings and hope for the best (hint: turn off your mobile)

I prefer option 2, as the INI File Mapping allows use to replace your INI Files with entries (keys, names and values) in the Registry. This is great/useful as you can neatly avoid any local security restrictions as well as benefit from roaming profiles (e.g.. Not have to copy INI files on application start-up each time a new user logs onto a machine).

Microsoft has a great Knowledge Note/Support article which can be found here; http://support.microsoft.com/kb/102889

I won't replicate what has already been said in the Microsoft article but there are a few caveats;

INI File Mapping works great for Vista and SoftGrid - but DO NOT use for Citrix when actually installing applications. See the Microsoft support note here: http://support.microsoft.com/kb/186504
Your application needs to use the supported API's (GetPrivateProfileString and WritePrivateProfileString)
Note: you will find out really quickly if your application does not support INI File Mapping as your registry based settings will be ignored and your local INI file will be updated.

I was working my through some our compatibility checks this morning when I realized that it had been a few months since I last read the Application Compatibility cookbook. This is a rich-text of application compatibility resources and every once in a while, it's worth a re-read.

One section caught my eye - the Program Compatibility Assistant, which is part of the Windows 7 OS and monitors how applications install and how application behave in a run-time environment.

In Microsoft's own words;

"The Program Compatibility Assistant (PCA) is a feature in Windows Windows 7 and Windows Server 2008 that can make older programs that have compatibility problems work better in an automated manner. PCA monitors programs for known issues. If an issue is detected, PCA notifies the user of the problem and offers to apply solutions that will be effective before the user runs the program the next time."

There are a number of features to the PCA including;

Detecting Failures in Setup Programs
Detecting Program Failures under UAC
Detecting Program Failures While Trying to Launch Installers
Detecting Installers That Need to Be Run as Administrator
Detecting Legacy Control Panels That Might Need to Run as Administrator
Detecting Program Failures Due to Deprecated Windows Components
Detecting Unsigned Drivers on 64-Bit Platforms

I thought I had a pretty good handle on the installation, legacy control panel issues, administrator requirement scenarios and the 64-bit driver installation issues but the Deprecated components area needed some more research.

I have seen the PCA pop-up dialog boxes a number of times, most commonly to advise the user that the application in question required access to a DLL that is no longer available on Windows Vista; a prime example is an application having a dependency on MSVBM50.DLL.

This got me thinking; What algorithm is the PCA using to determine a missing/deprecated component?

Is it;

1) Comparing missing dependencies against a list known missing DLL's?
- If so, are these files documented somewhere?
2) Hooking in the EXE loader (NT.DLL) and logging all failed loads

My thinking is that this is a bit reactive. We should be able to, prior to deployment be able to determine which applications will experience runtime PCA issues relating to deprecated components.

I suggest the following analysis. Each package should have all of its dependencies listed for each file contained in the target application package against;

- The target operating system
- All deployed middleware
- What files are contained within the package

Remember, this not about Windows 7 compatibility, but about your build of Windows 7, your middleware in your environment and your packages.

References:

Microsoft Compatibility Assistant: http://msdn.microsoft.com/en-us/library/bb756937.aspx


Microsoft Application Compatibility Cook Book: http://www.microsoft.com/downloads/details.aspx?FamilyId=69C63073-FE3F-47C3-BAA5-B37943AFE227

This week I had the pleasure of working with some of the Microsoft Premier Field Engineers (PFE's) in an effort to further understand some of the application compatibility issues that might occur when sequencing for Microsoft App-V (formerly SoftGrid).

Quickly, the topic turned to compatibility issues surrounding Folder Redirection as this appeared to pose a serious compatibility problem for Adobe.

A quick scan of the web, raised a number of forum posting where numerous IT personnel could not get Acrobat or Reader 9 deployed to C# debugging and "file not found" issues.

For a few samples look here:

http://thinmaillist.blogspot.com/2008/08/thin-re-watch-out-with-adobe-acrobat_9472.html
http://www.adobeforums.com/webx/.59b5c03a

It looks like there were some pretty drastic solution paths explored here, especially for Citrix deployments. Yikes... I am really glad that I don't have to do this stuff anymore...

Before I dive too deep into the Adobe deployment problems, let's have a little introduction to Microsoft's Folder Redirection .

The idea of re-directing user local data folders onto the network was introduced with Windows XP and is defined as, "the automated re-routing of I/O (operations) from local standard folders to use a different, storage elsewhere on the network". Translated, this means that some standard user folders (i.e. My Pictures, My Documents) are redirected to store your files on a network server. This greatly increases the chances that your files (and Pictures) will get backed up in the laptop being nicked or knackered.

Windows Vista uses folder re-direction on the following directories; Contacts, Desktop, Documents, Downloads, Favorites, Music, Videos, Pictures, Searches, AppData, Links, Saved Games.

If your browser has a spell checker AppData would appear with a red underline, which is appropriate as the AppData folder is one which caused us and to my great surprise, Adobe quite a lot of trouble.

Through our trouble-shooting exercise it became Adobe Reader and Acrobat 9 were attempting to write user specific data to the AppData folder. This is fine and according to the Microsoft logo application development specifications, this is OK.

So, in an enterprise environment, a user will logon to their desktop or laptop and if their IT department has done their job, the AppData folder will be redirected to something like; \\servername\region\department\username\AppData

And, here is the big issue. As folder re-direction takes place prior to logon- the user will not have any mapped drives. So, the fully qualified path to the final resting place on the target server for AppData will be a UNC path.

Hint: It will be a UNC path.

As you can probably guess where I am going here;

Adobe Acrobat 9 and Adobe Reader can not store their AppData files onto a UNC path. After a little debugging through their code, it appears that there is a failure to "read from left to right" and correctly parse the full path.

Hence, the file not found, app crashes and C# debugger errors that present themselves to users upon application start-up.

So, I did little more digging and loading Flash and version 6,7 and 8 of Adobe Reader. All of these packages use the redirected folder "AppData" in the same way - and I am sure that they will experience the same issue.

I will write more on the Adobe issues in forthcoming posts. And, there will be plenty to write about as it looks like there are over 400 application level conflicts between Adobe Reader 9 and Acrobat 9.


References:

Folder Redirection has a brief mention here: http://en.wikipedia.org/wiki/Folder_redirection