Friday 3 October 2008

Adobe vs. Adobe: Acrobat, Reader go toe to toe

I have written a few blogs now on a specific application such as iTunes and  Adobe products, so you may think that I am beating up on Adobe by commenting again on their installations - their application packages.

Nothing personal. In fact, after 8 years or so of dealing with packaging and deploying repeated upgrades of Reader to over 100,000 desktops  I am delighted to say that things are much, much better than they used to be. Reverse engineering Acrobat and Reader to create a reasonable package for deployment used to keep me in gainful (even moderately well-paid) employment - so no complaints here.

However, I was asked by an associate to investigate some of the SoftGrid issues surrounding the deployment of Adobe Reader (which is fine) and as a passing comment, he mentioned that by the way, "Adobe Acrobat completely conflicts with Reader..."

You mean, "That two products from the same software vendor will cause application conflicts when installed on the same machine?" Incredible.
This of course should be said with a French accent, "Encrrrroiable!"

So, I had to a have a look .

First, let's take a look at what we mean by application conflicts.  I could not find any Google/Web definition so I thought I would cobble something together for the occasion. Where as Application Conflicts could be defined as, "At least two application installations that contain file and configurations that are mutually incompatible when installed on the same machine."

Now, of course of this definition is now a little out-dated, due to the recent advances in virtualisation technologies. So I might now add;

 "At least two application installations that contain file and configurations that are mutually incompatible when installed on the same operating system environment"
 
This means that two application installation routines contain files , registry settings and other configuration details that once put in place on the target machine breaks another application either on installation, un-installation or through an update process. 

The things to start looking for when investigating application conflicts include;
  • Different versions of files placed in the same target directory
  • Registry keys with different values
  • IniFile with different settings for similar sections
  • Environment variables that are set to different conflicting values
There is a quite a complex matrix of at least 16 values when just considering File level conflicts within an MSI  Installer package as you have consider file name, version, location and the MSI component... Hey, 4 x 4 = 16 for those not paying attention. 

So, when you have just a few packages with a few hundred files and registry settings you can easily generate 1000's of permutations and combinations. When you extrapolate these few package conflicts to an enterprise environment that includes many 1000's of applications - the possible range of application conflicts could range in the 100's of millions of permutations combinations of files and registry settings that may break other applications. Crazy, scary stuff.

So, here is a quick summary of Adobe Acrobat 9 versus Acrobat Reader 9.

Here is a list of the same files that Acrobat installs to one directory and Reader to another, different directory; vdk150.dll , AGM.dll, authplay.dll. Note: these files have different versions as well as being located in different target locations. 

And, there are over 30 files are the SAME version but installed in two different locations on the same machine for both Acrobat and Reader including;
  • A3DUtility.exe
  • ACE.dll
  • AcroBroker.exe
  • Acrofx32.dll
  • AcroTextExtractor.exe
  • AdobeCollabSync.exe
  • AdobeLinguistic.dll
  • AdobeXMP.dll
  • AGM.dll
These are core files for both Acrobat and Reader - why are the same versions of these files installed into two separate directories . If you have to install both these packages on the same machine, what will happen?

In addition, there are a further 340-odd registry settings that are shared between these two application installations that contain different values - which means that you need to ensure which application is more important and then decide to install that application last. This is required to ensure that your "most desired" application get the settings it needs to work properly. Who knows what will happen to the earlier installed version. And more interestingly (or worse depending on your viewpoint) what happens when the Adobe update process kicks in?

Fun stuff, eh?

No comments: