Browse Prior Art Database

Self-Adaptive Configuration for Multiplatform Support Executables

IP.com Disclosure Number: IPCOM000012962D
Original Publication Date: 2002-Jun-22
Included in the Prior Art Database: 2003-Jun-11
Document File: 5 page(s) / 56K

Publishing Venue

IBM

Abstract

During application execution, an application may need to know the file system location where it was installed. From that location the application can determine the file system locations of the various subcomponents of the application. There are numerous reasons why an application would need to know its file system location, or the location of its subcomponents. Here are just a few: The application needs to load images from an image directory. The application needs to read or write private data files such as configuration files, user preferences, etc. The application needs to write temporary files to the system, and would like to use its installation directory tree. The application needs to load one of its shared libraries. Rather than requiring a system environment change (such as PATH, LIBPATH or LD_LIBRARY_PATH), the application wants to explicitly load the library from its location. DETERMINING THE INSTALLATION DIRECTORY The solution involves modifying the application's main module (namely, the binary .EXE file) during the application's installation. The modification writes the main install directory into the binary .EXE. Later, when the application (.EXE) executes, it can locate the install directory by looking within its own data segment. More specifically, when the code for the .EXE is developed, a space in the data segment is reserved. This space (or fixed number of bytes) is large enough to hold a unique signature and directory location. Initially, when these bytes are reserved in the data segment, their contents contain the unique value (or signature). This unique signature allows the installation to locate the space within the data segment of the .EXE. The installation can then replace the portion of the reserved space with the directory name.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% of the total text.

Page 1 of 5

Self-Adaptive Configuration for Multiplatform Support Executables

   During application execution, an application may need to know the file system location where it was installed. From that location the application can determine the file system locations of the various subcomponents of the application. There are numerous reasons why an application would need to know its file system location, or the location of its subcomponents. Here are just a few:

The application needs to load images from an image directory. The application needs to read or write private data files such as configuration files, user preferences, etc. The application needs to write temporary files to the system, and would like to use its installation directory tree. The application needs to load one of its shared libraries. Rather than requiring a system environment change (such as PATH, LIBPATH or LD_LIBRARY_PATH), the application wants to explicitly load the library from its location.

DETERMINING THE INSTALLATION DIRECTORY The solution involves modifying the application's main module (namely, the binary .EXE file) during the application's installation. The modification writes the main install directory into the binary .EXE. Later, when the application (.EXE) executes, it can locate the install directory by looking within its own data segment.

More specifically, when the code for the .EXE is developed, a space in the data segment is reserved. This space (or fixed number of bytes) is large enough to hold a unique signature and directory location. Initially, when these bytes are reserved in the data segment, their contents contain the unique value (or signature). This unique signature allows the installation to locate the space within the data segment of the .EXE. The installation can then replace the portion of the reserved space with the directory name.

The chosen implementation for this solution is to provide a function API in a shared library that the installation utility will use to modify the application's main module (.EXE). The API consists of a function that accepts a filename (.EXE) and a data string (installation directory in this case). The function in the shared library, when called, will write the data string into the data segment of the file whose filename was specified, replacing the contents in the reserved bytes within the filename (.EXE). The use of a shared library allows the solution to be separated from the installation code, and reused with other installation programs or utilities.

Implemented in ANSI-C programming language, a common header file (.H) contains definitions used by both the application's main module (.EXE) and the shared library. Use of a singular header file with definitions shared between both reduces the chances of programmer error. Excepts form the common header file follow:

#define INSTALL_DIR_SIGNATURE "SA_INSTALL_DIR:"
#define INSTALL_DIR_SIGNATURE_LENGTH 15

1

Page 2 of 5

#define INSTALL_DIR_VALUE

"123456789012345678901234567...