Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Technique to Aid Code Portability

IP.com Disclosure Number: IPCOM000113929D
Original Publication Date: 1994-Oct-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 97K

Publishing Venue

IBM

Related People

Sethi, V: AUTHOR

Abstract

This disclosure talks in C/C++ terms, although it applies in principle to other development languages.

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

Technique to Aid Code Portability

      This disclosure talks in C/C++ terms, although it applies in
principle to other development languages.

      When building subsystems it is often necessary to keep client
data on a per-machine (global), per-process, and per-thread basis.
Such data might be stored in the data segments of the subsystems
executables and libraries.

      Various operating system platforms have different
characteristics in their handling of executable and Dynamic Link
Library (DLL) data segments.

      Under OS/2* executables and DLLs can have both non-shared and
shared data segments.  Where data goes is typically specified by
#pragma data_seg directives and via the .DEF file.

      With AIX* (and most UNIX**es), the data is naturally no-shared
and shared data must be achieved via shared memory calls (shmget()
etc.).

      Under Windows***, all data segments in DLLs are shared.
Nonshared data must be achieved by the use of locks, semaphores, and
keying on process/thread id.

      Clearly the above differences make it very difficult to write
"portable C code" that can be migrated across platforms with just a
recompile.

      Our invention is to provide an API set that isolates such OS
dependencies from the subsystem developer.

      Each component (i.e., executable or DLL within the subsystem)
would require a unique identifier, assigned at compile time.  It
would also make no references to global data objects in its portable
code.  Accesses to global/per-process/per-thread-of-process data
would be achieved via access functions listed below.  These would be
implemented for speed, as they might be expected to be used quite
often.
     typedef int cide; /* Component of subsystem ID, e.g.: video-DLL
*/
     void *DsegGetGlobalInit     (cid c, void *defDseg, size_t
lenDseg);
     void *DsegGetPerProcessInit (cid c, void *defDseg, size_t
lenDseg);
     void *DsegGetPerThreadInit  (cid c, void *defDseg, size_t
lenDseg);
     void *DsegGetGlobal    (cid c);
     void *DsegGetPerProcess(cid c);
     void *DsegGetPerThread (cid c);

      DsegGetGlobalInit() returns a pointer to the data segment that
is shared among all process in the system.  If we are making the
first call to this function, then a segment is created from the
default data supplied.

      DsegGetPerProcessInit() gives the per-process data segment.  If
we are making the first call for this process, then it creates a
segment from the default data.

DsegGetPerThreadInit() is as above, except on a per-thread basis.

      The calls without Init on the end can be made if we know there
is no danger of this being the first call.

      These calls do the querying of the current process-id (and
thread-id) within them, thus relieving the programmer from this sort
of key-by-id type of coding.

      Clearly the default segment could ha...