Browse Prior Art Database

Generating Shared Library Base Addresses using Hashed Product Prefixes

IP.com Disclosure Number: IPCOM000123341D
Original Publication Date: 1998-Sep-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 101K

Publishing Venue

IBM

Related People

Kloppmann, M: AUTHOR

Abstract

1. Area Of Invention This invention is from the area of software engineering, specifically the building of executable code consisting of of several dynamically linked libraries.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 49% of the total text.

Generating Shared Library Base Addresses using Hashed Product Prefixes

 1.  Area Of Invention
      This invention is from the area of software engineering,
      specifically the building of executable code consisting of
      of several dynamically linked libraries.

 2.  State-Of-The-Art
        The deliverables of a typical software product are
      separated into several executable files, which usually
      share a couple of shared libraries.  This is done to
      allow for sharing of common code across several
      instantiations of the executables.
        Different operating systems have different allocation
      strategies for this shared code.  There are operating
      systems where the address to which a shared library
      should be loaded (its base address) is statically
      determined when it is built (Windows NT is a
      representant of this class of operating systems;
      shared libraries are called DLLs there).  When,
      during run-time, the loader is not able to load the
      shared library to the address specified, it relocates
      it to another addres, thus effectively preventing
      sharing of the code.

   On Windows NT, the state of the art is one of the following:
  o  Products ignore the base addresses of DLLs completely and
     ship all their shared libraries with a default base
     address.  This has a couple of significant disadvantages:
     o  When a DLL is loaded whose base addess conflicts with
        the address of another DLL that was already loaded
        earlier, it has to be relocated to a new address chosen
        by the loader.  Relocation delays loading.
     o  In addition, a copy of the (relocated version of the) DLL
        has to be created in Windows NTs paging space.  For the
        original, not relocated DLL, the already existing copy
        on disk could be used when pages of the DLL had to be
        reloaded from disk into memory when they had been paged
        out; for the relocated version, this is not possible,
        so a copy of the relocated DLL is required.
     o  If a DLL can not be used at its original base address,
        but had to be relocated, Windows NT effectively stops
        sharing of it.  Every user of the DLL receives his own
        physical copy, which significantly increases the
        resources needed to run the system.
     o  End-users with very good system knowledge can manually
        re-base DLLs on their system, i.e. statically relocate
        them to disjunct address ranges.  This means they have
        to update DLLs that were shipped to them as part of a
        product.

  In theory, it would also be possible to administer base address
ranges via a central agency, but...