Launching Two Versions of an App When Both Are Installed to the Same Location

With SVS, applications are typically launched the same as without SVS. That is, by clicking on a standard shortcut, using Start > Run, by clicking on a program file in Windows Explorer, etc. However, SVS also introduces some new possibilities that the standard Windows launch methods can't quite handle. One we hear about a lot from customers is the ability to have two versions of an app installed to the same location. It works. This article discusses both why it works, and how to set it up.

Editor's note: This article contains a lot of great background and explanation of SVS nuts n' bolts. If you want to get right to the solution described in the title, click here.

Introduction

SVS allows you to have multiple versions of an application deployed on the same machine. Usually, you can even have multiple versions actually up and running at the same time (tho some applications - such as recent versions of Windows Media Player - disallow concurrent use). Since each version will look into its own VSP first for files and registry keys that it needs, each will see and use the correct set of supporting files. Some customers also have a use case for two implementations of the same app version, but with different configurations -- for example, Outlook, to access two different Exchange systems at the same time. To SVS, this is essentially the same thing.

Figure A. Microsoft Excel 2000 and Excel 2003 both open at the same time.

Click to view.

This is dirt easy to set up when the different versions of the app are installed to different file system paths (or when the main executable names are different). That's the default, by the way, for Microsoft Office and Adobe Acrobat Reader, two of the examples that Symantec often demos. In fact, if the apps are at different paths, you usually don't need to do anything different from normal. Just capture each and you're off! (Acrobat Reader does require a minor tweak.) Even if the different app versions are installed to the same path by default, usually you're given a chance to change the install path via a prompt, a command line option or an installation config file. If you need to run multiple versions of an app, it will always be simplest and cleanest to put them at different file system paths. (Sometime you can rename the main executables without breaking the app; this accomplishes the same goal. Bottom line is, the shortcut targets must be different.)

But what about that situation where the app doesn't allow you to change the install path? Or when hard coded locations mean the app will break if you put it anywhere other than where the vendor meant it to be, or if you rename the main executable? We get that question often, and in that case there's a slight challenge. This article documents a solution.

Background: How SVS Handles Visibility of File System and Registry Objects

To understand why this is even an issue, it's important to understand how SVS handles visibility of files and registry keys. First, please review this definition of a "VSP" and "layer". When there are multiple versions of a file of the same name at the same path, a given process can only see one of them. (Unless, of course, it's an app written specifically to view duplicate objects on an SVS machine. This is simple with the newly available SVS SDK, and we have a tool in the works.) To determine which version of the file is visible to different processes, SVS keeps track of every process tree in Windows, and where each process tree was launched from. (SVS does track child processes as well, so that they have the same view of the system as the parent processes that launched them.)

[Additionally, SVS handles writes to the file system and registry the same way. That is, where a write goes depends on where the process tree doing the write was launched from. Josh Bernson recently posted a good tip on how to experiment with this and see it in action.]

As an example, let's say you have an application called AppA in a layer, and its main executable is C:\Program Files\AppA\AppA.exe. You also have a different application called AppB, in a different layer, and its main executable is C:\Program Files\AppB\AppB.exe. Lets say that each application requires a different version of hell.dll in the System32 directory and that each layer contains the correct .dll version for that app.

Figure B. Two applications, at different paths, but with a duplicate file name.

Click to view.

If you look at the two layers in SVS Admin, you will observe that each version of hell.dll is located at [WINDIR]\System32. So when you activate both layers on a workstation, there are actually two different versions of hell.dll live on the system! AppA.exe, and any child process it spawns, sees the .dll version in the AppA layer. AppB.exe, and any child process it spawns, see the .dll version in the AppB layer.

This is how SVS does file system conflict elimination. And it does the same thing for the registry. It's a simple approach that typically "just works" and doesn't require any special setup by the administrator.

The Problem

But now, the big question - If I look in C:\Windows\System32 in Windows Explorer, which version of hell.dll do I see? Windows Explorer is typically going to be a program in the base, [WINDIR]\explorer.exe. (By the "base," we mean all software on the box that is not in a layer - typically this will at least be Windows, plus any other conventionally installed software.) For purposes of determining which version of a duplicated file is visible, SVS handles the base as if it were in fact a layer. So, if there is also a version of hell.dll in the base, Windows Explorer - and any other process tree launched with a program in the base - will see that version.

If hell.dll does not exist in the base, Windows Explorer can see either the version in the AppA layer or the version in the AppB layer. If you need to explicitly control which version is visible, you have a couple options:

1. The best option is to just copy the needed version into the base. You do end up with three versions of the file, but every application sees the version it needs and the dependency is located with the app(s) that use it.
2. Another option could be to adjust the layer priority of the layer containing the .dll version that you want visible to the base, to a value just higher than the default. This article provides information on layer priorities. That would prevent having a third copy of the file, but keeping track of priorities that have been changed from the default could get confusing. And of course it affects everything in the layer, not just the one file at issue. Also, if a layer containing a dependency is deactivated, it may affect programs running from the base. So Altiris does not recommend changing layer priorities from the defaults.

Now that we've discussed how processes running from the base see files that are duplicated in different layers, perhaps you've figured out why it's a bit of a challenge to launch two different versions of an app from two different desktop shortcuts when both shortcuts have the same target. Shortcuts are actually run by explorer.exe!

Here's an example: You have two versions of AppX, 1.0 and 2.0. To function correctly, they must both be installed to C:\Program Files\AppX. Also, the main executable, main.exe, cannot be renamed without breaking the app. So you do your captures and figure out real quick that the shortcuts for the two different versions need to have different names, or you only see one of them on your desktop. You end up with layers that look like this:

Figure C. Two different versions of the same app, with the same shortcut target.

Click to view.

As described above, explorer.exe can only see one of those versions of main.exe. So, no matter which shortcut you click on, you either always get AppX 1.0 or you always get AppX 2.0.

[An academic point: The reason why it may be either version that comes up is because - by default - all application layers have the same priority. When two layers have the same priority, the search order is determined by activation order. The layer activated first has the higher priority in the search order. Layer activation order can change for a number of reasons and from machine to machine. You could make it deterministic which version launches by giving one layer a higher priority than the other. But of course that is not the goal. Again, this is just an academic point. Don't muck with layer priorities. They exist primarily for developers who need to create new layer types.]

The Solution

As said in the introduction, the key is that the shortcut targets must be different. That is, you must give explorer.exe a way to launch two unique process trees, so that SVS can handle their file system and registry activity correctly - both to ensure that each app sees the object versions it needs and to ensure that writes done by each app go back into the correct layer.

[A quick note here on what does not work to solve this problem. Launching each app from a uniquely named batch file doesn't cut it. Just as all shortcuts are executed by explorer.exe, all batch files are executed by cmd.exe. So you just take the problem one step further. You'll still end up always getting just one version of the app or the other. VBScript won't cut the cheese either; all VBScripts are executed by wscript.exe. Same issue.]

There are several options that will launch a unique process tree from a shortcut. We've provided an elegantly simple one using Symantec's' own WiseScript: runexe.exe. WiseScript lets you write a script and then compile it as a self-contained executable. So unlike a batch file or VBScript, the script itself is able to spawn a new process tree. And of course .exe's compiled with WiseScript can be readily renamed with no effect on the function. Runexe.exe is essentially an application launcher. Minimally so, but the key to solving your problem. All runexe.exe does is take the program you specify and launch it. For example:

runexe C:\Program Files\AppX\main.exe

If you are interested, or want to fiddle with it, the script looks like this:

item: Set Variable
  Variable=CMDLINE2
  Value=%CMDLINE%
end
item: Execute Program
  Pathname=%CMDLINE2%
end

Put runexe.exe in the layer with the app. You can copy it to the location of your choice in the layer, but keeping it with the application program files may be cleanest for you - your call. Manually adding a file to a layer like this can be done using the layer editing tools in SVS Admin or Wise, or by using Windows Explorer to copy it directly into the redirect area. Once runexe.exe is in the layer with the app, you can guarantee that it will see the version of main.exe that's in that same layer.

When you have two apps, as in Figure C above, put a copy of runexe.exe in each, and each will see the version of main.exe that's within it's same layer.

Using one of the tools mentioned for manually copying a file into a layer, rename each runexe.exe to something unique. (Note: If you do the rename using a tool in the base like Windows Explorer, and if you rename the file in its virtual location - e.g., C:\Program Files\AppX - the file will get copied to the base and you won't get the desired result.) 'Course, you could also rename before copying into the layer, too. For our example, let's rename the version of runexe.exe in the AppX 1.0 layer to RunAppX1.0.exe. For the version of runexe.exe that's in the AppX 2.0 layer, let's rename it to RunAppX2.0.exe. Now you have a way to create unique shortcuts that will each call a different version of AppX.

Click to view.

Figure D. Two versions of the same app, same main executable at the same path, using a compiled WiseScript to create unique shortcut targets.

To create the shortcuts, with the layers active use the conventional method of right clicking on the file and selecting Send To > Desktop (create shortcut). Then edit the shortcut properties to add the "C:\Program Files\AppX\main.exe" argument to the target line. (Note: The shortcuts will initially be created by explorer.exe in the base. After you run each the first time, SVS will automatically move them into the layers with the applications.)

Conclusion

We've informally tested this with multiple versions of several different applications, including Firefox, Windows Media Player, and the Blackberry desktop manager.

Figure E. Two versions of Windows Media Player, which insisted on being installed to the same directory. They both work.

Whether you use runexe.exe or some other method to launch the apps, having apps in different layers but installed to the same location is indeed a supported configuration and use of SVS 2.0. If you find a problem, let us know.

We'll likely provide a one-click option in a future release of Wise Package Studio to create unique program launch shortcuts that automatically get put into layers. There are a few reasons we want to do this, including having the launcher do things beside just run the app - things like validate a signature on the VSP, check for available licensing before allowing use of the app, etc. In the mean time, use this basic launcher to address the use case of two versions of an app at the same location.