How to set Windows compatibility settings for App-V package, the easy way

There is a Compatiblity -tab in the Windows Explorer when you take the properties from a executable or a shortcut, which can then be used to set certain pre-defined compatibility mode settings for a program:

It might not be so intuitive, however, to set those same settings for virtual applications as you probably have discovered when trying to set compatibility for applications running in App-V “bubble”. In this post, I will demonstrate how to utilize OSD scripting to do what you would normally do through Windows Explorer UI.

As a sidenote, compatibility settings that you can set through Explorer is a subset of all possible settings or “application lies” that you can do using Windows application compatibility shims. Those individual shims can also be applied to virtual environment, but that discussion is outside the scope of this article. If you are intersted on reading more on those, I would recommend you familiarize yourself with a FAQ entry at Aaron’s site which gives pointers on using shims with App-V.

Where are the compatibility setting stored in?

Right, so when we go into settings some compatiblity settings – like pretending that we run the application on Windows XP SP3 – where do those settings gets stored in? As they are not stored in alternate stream for the file itself (which would be neat, though), they must go somewhere so that Windows will know to apply the settings on starting that executable..

The answer of course – like in so many occasions – is the Windows registry. There are actually two separate places for compatiblity mode settings, both in HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. Otherwise it would not be possible for users with normal accounts to set any compatibility settings if they would only be stored on the machine side. To be more specific, the settings are stored under the following key (for user):

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

And as we can see from the screenshot, what we basically have over there is a path to the executable (for which we are setting compatibility mode to) along with compatibility setting flags as value data:

Each selection in the Explorer’s UI has one corresponding flag, and multiple flags can be combined to enable multiple compatibility settings. And regardless of if we set compatibility setting from the executable file itself or from application’s shortcut, it’s the path to the executable file that gets written into registry; this point will be important to remember later on when we define compatibility mode for App-V virtualized applications.

Let’s see our earlier example of Exact Audio Copy and it’s compatibility settings (note that this particular application does not need any compat settings, only demostrating the idea here!); we had the XP SP3 enabled but we want to specify that Windows themes should be disabled for the duration of its runtime as well:

This will result of multiple flags in the registry (each separated with space):

Okay, now we know how to set the compatibility mode settings from the registry for an executable. We still need to have a quick reference for all the flags for references (as they don’t seem to be documented anywhere at the Microsoft’s site):

• Windows 95 = WIN95
• Windows 98/ME = WIN98
• Windows NT SP5 =NT4SP5
• Windows 2000 = WIN2000
• Windows XP SP2 = WINXPSP2
• Windows XP SP3 = WINXPSP3
• Windows Server 2003 SP1 = WINSRV03SP1
• Windows Server 2008 SP1 = WINSRV08SP1
• Windows Vista = VISTARTM
• Windows Vista SP1 = VISTASP1
• Windows Vista SP2 = VISTASP2
• Windows 7 = WIN7RTM
• Run in 256 colors = 256COLOR
• Run in 640 x 480 screen resolution = 640X480
• Disable visual themes = DISABLETHEMES
• Disable desktop composition = DISABLEDWM
• Disable display scaling on high DPI settings = HIGHDPIAWARE
• Run this program as an administrator =RUNASADMIN

Setting compatibility to App-V virtual applications

Like noted in the beginning, setting compatibility mode for applications that you run from virtual environment is not as straightforward as popping up that file properties -dialog in the Sequencer during monitoring mode and ticking required boxes. No, only thing this will do is to write those settings, like discussed already, into the registry of the Sequencer and subsequently getting cached in the virtual registry. The problem is, Windows will not be able to peek inside the virtual registry when you execute your virtual applications on the client and so any settings you might have carried along from the Sequencer won’t be effective.

Another obvious idea, setting compatibility mode through application shortcut created by the App-V Client is equally bad idea: all the shortcuts for App-V virtualized applications point to sfttray.exe binary. This is the launcher application that the Client uses for starting virtual application and so if you change any one shortcut created by App-V, you will change them all because the compatiblity mode will be applied against sfttray.exe and not your target binary (remember, Windows only sees that sfttray.exe as being the program called when you edit the shortcut)!

Well, if you can’t do it in the virtual registry, and you shouldn’t do it through shortcuts on the client, what can you do then?

The answer is to utilize OSD scripting so that the setting will be applied to the physical registry before application gets a chance to launch. For this purpose we will need to create a script that is started by App-V Client, having the following settings:

• TIMING=”PRE”
• EVENT=”LAUNCH”
• PROTECT=”FALSE” (so that we can affect the real registry instead of virtual copy)
• WAIT=”TRUE” (so that the application is not started before our registry modification is done)

For the purpose of writing the settings, we can use HREF type scripting as we can utilize Windows’ reg.exe program with single line of command to do the bidding:

REG.EXE ADD “HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers” /v “q:\path\to\the\exeuctable.exe” /t REG_SZ /d “WINXPSP3 DISABLETHEMES”

This command will write path to our virtual application to the appropriate registry key (and create all the required registry keys in-between if not present already), along with the necessary compatibility flags. You should of course adjust the command to match your actual path to the application in the Q: (or what ever the virtual drive happens to have as drive letter in your environment) as well as the flags specific to that application:

As I mentioned before, it is very important to have actual path to the executable you intend to apply settings for; and in the context of App-V this has the special significance in that you may have something called a “VFS sequence”. These are the packages that have the application installed to the original path (C:\Program Files\… , usually) instead of being installed to the Q: drive on the Sequencer machine as is the best practise. Regardless of the reasons why you may have done this, you should be aware that even thought the application thinks that it lives somewhere else, all the actual I/O will end up going into Q: drive at the Client; for application compatibility settings purposes this means that you will need to use that actual Q: -based path as the executable path in the registry value and not the C:\Program Files\… -path!
Otherwise the Windows won’t apply compatibility shim to your application as Windows will always see your application by the Q: -path, as can be easily verified by using Process Explorer and looking at the properties of any virtual application; it should have Q:\… as an executable path.

To accommodate for this requirement, you should look at the package after sequencing and find your target executable under Q:\package root\VFS\… -path in the Sequencer machine. This is the path you will then need to use in the reg.exe -command above.

As an example for this scenario, in the LiveLink package (common accessory application for SAP and one that I have found out needs WINVISTA compatibility setting in Windows 7, otherwise it crashes) that has been packaged as a VFS sequence, the alviewer.exe file is in the \livelink.001\VFS\CSIDL_PROGRAM_FILES\IXOS\bin -directory even though it will be virtualized over C:\Program Files (x86)\IXOS\bin (as I have x64 machine) using VFS technology:

If I were to use C:\Program Files\IXOS\bin\alviewer.exe (for 32-bit machines) or C:\Program Files (x86)\IXOS\bin\alviewer.exe (for 64-bit machines) as a value name in AppLayer -key, none of the compat settings would be applied. I need to use Q:\livelink.001\VFS\CSIDL_PROGRAM_FILES\IXOS\bin\alviewer.exe -path instead because that is how the Windows will see the process.

—

Hopefully this post helped you to understand how application compatibility settings can be easily added for App-V packaged virtual applications, without having to resort to complex shim database tricks!