Browse Prior Art Database

Transparently Separating Functions from a Large Dynamic Link Library

IP.com Disclosure Number: IPCOM000106313D
Original Publication Date: 1993-Oct-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 2 page(s) / 115K

Publishing Venue

IBM

Related People

Corn, VE: AUTHOR [+3]

Abstract

Described is a technique to break up a large OS/2* Dynamic Link library (DLL) into several smaller DLLs, without changing any existing applications that are dependant upon the existing DLL. This technique was developed during discussions to move the User Account Subsystem portion of LAN Services into the OS/2 base operating system.

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

Transparently Separating Functions from a Large Dynamic Link Library

      Described is a technique to break up a large OS/2* Dynamic Link
library (DLL) into several smaller DLLs, without changing any
existing applications that are dependant upon the existing DLL.  This
technique was developed during discussions to move the User Account
Subsystem portion of LAN Services into the OS/2 base operating
system.

      In Extended Edition 1.3, The Communications Manager (CM),
Database Manager (DBM), and LAN Server (LS) all share a common
dynamic link library, NETAPI.DLL.  When Extended Edition 1.3 was
split into Lan Services 2.0 and Extended Services 1.0 each product
shipped the same copy of NETAPI.DLL.  NETAPI.DLL contains most of the
Lan Services network related apis and is built as part of the LAN
Server build process.  Although NETAPI.DLL provides services to
subsystems other than LAN Server, NETAPI.DLL is part of the LAN
Server executables and as such has interfaces to the LAN Server code
that is not architected and is intolerant of mixing build levels.  As
a result, different levels of NETAPI.DLL can support different levels
of CM and DBM, but NETAPI.DLL must match the level of the LAN Server
code exactly.

      In early Lan Services testing, there was often a problem where
the build level of ES did not match the build level of LAN Server and
if ES were installed after LAN Server, the software would not
function.  This problem was solved by ensuring that the NETAPI.DLL
that came with LAN SERVER was always the version installed.  This was
an acceptable solution as long as we could ship the entire
NETAPI.DLL.

      When the User Account Subsystem (UAS) was moved to the OS/2
base, it was undesirable to ship the entire NETAPI.DLL, only the
necessary APIS.  The first solution was to create a junior version of
NETAPI.DLL for the base that only contained the UAS function.  This
approach was unacceptable because of the problems associated with
different versions of the same file.  An example is the Corrective
Service Disk process for the OS/2 base which would need to check for
LAN Services or Extended Services to determine whether or not to
update NETAPI.DLL.

      There are two conflicting requirements when splitting up a DLL:
1) The API function name should not change because a program should
be able to link to either NETAPI.DLL or the individual DLLs without a
code change.  2) The linker will not allow two DLLs with the same
function name to be statically linked into the same executable.  This
ambiguity is unacceptable because linker cannot determine which
functio...