Safe Installation of Object-Oriented Class Libraries Common to Multiple Software Products

Safe Installation of Object-Oriented Class Libraries Common to Multiple
Software Products

      Disclosed is a technique for insuring that, when multiple
software products include the same object-oriented class libraries,
and those products are to be installed on the same system, the
installation process for a product containing an outdated library
file does not replace an existing, newer library file installed by
another product.

      The importance and popularity of Object Oriented Programming
Systems (OOPS) has produced a variety of programming languages and
systems.  Using these systems, large, reusable class libraries can be
developed.  These libraries can serve as the foundation for a variety
of software products.  In order for these products to operate on a
customer's system, however, that system must have the class library's
files (such as dynamically linked library files, or DLLs) installed
on the system.  One solution to this problem would be for the
software product to prerequisite the class library.  With this
approach, the customer is responsible for purchasing and installing
it before installing that software product.  This solution is
probably acceptable for small product vendors when the class library
is not freely distributable.  In some cases, however, it is
preferable for the software products based on a class library to
"bundle together" the class library and the software product into a
single installable product.  For example, if the class library is
freely distributable or when the software product vendor expects a
large market share, then the vendor may prefer to simplify the
installation process for the customer by incorporating the class
library into the product.

      If multiple software products incorporate the same class
library, then the following problem arises: how can the installation
process for each product insure that, when it installs a class
library file (such as a DLL) onto a customer's system, it is not
replacing the same file (installed there by some other, unknown
software product) of a newer version? If such a replacement occurred
(where an older version of a file replaced a newer version of a
file), then other software products on the system might cease to
function properly.  This is not a problem if the files are installed
into separate directories for each product.  However, when different
products choose to install into common directories, such as /usr/lib
on AIX*, then special installation processing must be done.  This
invention presents a solution to this problem, for files installed on
AIX systems using the standard installp facility.

      This invention consists of a script, called apdev, that insures
that software products developed using particular class libraries
properly install those libraries on customers' AIX systems.  The
apdev script is intended to be used by software vendors when
preparing installation packages for their products.  It is a script
...