COM / ActiveX Installation Hell & Solutions

COM / ActiveX Installation Hell & Solutions

With COM (Common Object Model), Microsoft designed a great way for developers to create modular software components that can be easily shared with others no matter what programming language they use. The popularity of COM has created a huge software middle-ware market and today it is the preferred method of component distribution, replacing older methods such C Libraries, DLL, and source code.

While COM makes life easier for middle-ware vendors, it can present a barrage of problems for developers who are trying to deploy their applications. Before COM components can be used, they must first be installed - and this is where the problems begin.

Typically a COM component installation process looks like this, with points of failure highlighted in red.

Locate Windows System Directory. This may vary from machine to machine, some installers may place DLLs in c:\windows\system instead of c:\winnt\system32, etc.

Check Windows System Directory for presence of a file with the same name as your COM component.

If file exists, check DLL for a "DLL version" number and compare with DLL version number of our COM component

If file has no "DLL version" number, then compare file Last-modified time with the last-modified time of our COM component

If DLL file in Windows System Directory is newer than our file, then don't install and hope everything works. It may be that the file exists, but is not registered in the system registry - there is no way check for this case - in which case your application may fail .

Extract the COM DLL file to the Windows System Directory. Replacing an older version of a COM control with a newer one that is not 100% backwards compatible may cause other applications to fail.

If write permission to the file is not allowed, then one of the two is probably true:

The DLL is use by another application . In this case you need to setup a Copy-on-reboot operation. You also need to instruct your installer to continue after reboot so that the COM component can be registered after it has been copied. To do this you need to:

Setup a StartUp Shortcut to run your installer.

Access to the StartUp Shortcut may be restricted.

ii.

The system may have restricted file access to the windows system directory. In this case, you need to instruct the user to log in as Administrator in order to install your software.

The extract operation could fail because of limited disk space on the windows system drive. Even if the system initially reported there was enough disk space, it may have changed since you last checked - or the system was over estimating availability based on compression. In this case you need to have kept a backup of the old COM component so it can be restored and you can back-out of the installation gracefully.

Register the COM DLL. On many corporate and educational systems, access to the system registry is restricted to read-only access. In this case the COM registration will fail - maybe without reporting an error.

If COM registration fails, the only option is to back-out of the registration. In this case you need to copy the old COM DLL backup to its original location. Since system registry access is restricted, COM registration of the old DLL may fail.

After the old DLL has been replaced, the user must be instructed to log in as Administrator and try again. There is no guaranteed way to know before installation begins if it will fail.

Uninstalling COM Components is an even more error-prone method. There is no reliable way to detect if other applications are still using shared components you installed, so the only safe thing to do is leave the component behind on uninstall. Microsoft has created some guidelines that would allow safe uninstallation of COM controls if all applications adhered to them, but almost no installer does.

Installed COM components are easily "corrupted". Successful installation of a COM component can be easily corrupted causing your application to fail. Some of the main causes for COM failure after installation include:

Another Application installer overwrites your COM control with an older version - Many installers do not properly check version numbers before copying files to the Windows System directory. This is the one of the top sources of problems for COM developers, it is very likely to happen to you and there is little you can do to prevent it.

Another Application installer overwrites your COM control with a newer version that is not 100% backwards compatible. There are many instances where this problem arises.

Another Application uninstaller removes/moves/renames the COM control DLL file which your application needs to run.

Another Application Uninstaller unregisters your COM control from the system registry.

Another Application modifies your COM registry keys to an incompatible setting.

The user inadvertently changes files or registry keys associated with your COM control.

The user recovers from a crash or virus attack by using a system restore of the registry or windows directory. In this case the COM control may become unregistered.

The user restores your application, but not the system registry after a system reinstall.

The Solution: "Thin" Installation

There is only one foolproof solution to COM installation. Don't do it.

Thinstall allows you to deploy applications and COM controls in a "pre-installed" state. In this state, applications contain their own virtual registry and virtual file system so it is not necessary to install anything on the users computer. There are many advantages for deploying software this way:

Administrator rights are never required. Because no system registry changes are needed to use COM components, your software can be installed and run without Administrator rights - even on systems with restricted file system and registry access.

No possibility of causing other applications to fail. Because your application does not modify any files in the Windows system directory and does not make any changes to the system registry, there is no way for your application to cause other applications installed on the system to fail.

No possibility of other application installs/uninstall breaking your application. Because your application is deployed and run as a single EXE file, you eliminate almost all dependencies on outside files and registry keys.

Install process becomes trivial. Now your application can be copied to a new location or computer and run without needing a reinstall process. You can place a single EXE on a network drive and users can run it directly without installation. If the operating system is reinstalled with a blank registry your application will not be effected.

Uninstall process becomes trivial. To uninstall your application simply delete it. There is no chance to cause other applications to fail by accidentally deleting DLLs or registry keys needed by other applications.

No source code changes needed. Thinstall loads almost all 32bit Windows applications and COM files without source changes, including 3 ^rd party COM components.

How does it Work?

Thinstall acts as a "Thin Virtual Machine" that transparently merges a virtual system environment with the real system environment. The Thinstall Virtual Machine, only 100-200k in size, consists of 3 core technologies:

The Virtual Operating System ( VOS). The VOS allows you to load and run COM and DLL and EXE files directly from your package file, bypassing Windows normal loading procedures for DLL loading and COM object creation.

The Virtual File System (VFS). The VFS is a compressed read-only file system that is transparently merged with the real file system. The VFS exists as a section of your EXE and prevents your COM controls from being modified or replaced.

The Virtual Registry (VREG). The VREG transparently merges virtual registry keys with the real system registry. The VREG makes it appear as though your registry keys have been installed into the system registry, when they always remain as part of your EXE. To make virtual registry creation easier, Thinstall has COM recording abilities that allow you to gather all the registry keys needed by a COM component before deploying it.

Thinstall application builder packages the VOS, VFS, and VREG along with your application EXE, DLLs, data files, and registry keys into a single compressed EXE. When your application is running, virtual files and registry keys will override system files and registry keys where they might collide, otherwise the application can access any system files and registry keys it normally could.

For more information about Thinstall, click on this link.