Browse Prior Art Database

Handling Dormant Workplace Shell Objects

IP.com Disclosure Number: IPCOM000117073D
Original Publication Date: 1995-Dec-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 152K

Publishing Venue

IBM

Related People

Nash, SC: AUTHOR

Abstract

The OS/2* workplace shell puts objects into a dormant state when they are not currently in use by any program and not displayed on the screen. It does this in order to free the memory resources associated with the object, since dormant objects reside on disk and not in main memory. This optimizes overall system resource consumption by the shell at the cost of added programming complexity, since any code that uses workplace shell objects must take account of this possible dormant state by keeping persistent handles for any objects that may become dormant, and explicitly locking objects for the duration of their use. This programming complexity may be acceptable for a language such as C, but is not acceptable for use of workplace shell objects from a high-level scripting language such as Object REXX.

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

Handling Dormant Workplace Shell Objects

      The OS/2* workplace shell puts objects into a dormant state
when they are not currently in use by any program and not displayed
on the screen.  It does this in order to free the memory resources
associated with the object, since dormant objects reside on disk and
not in main memory.  This optimizes overall system resource
consumption by the shell at the cost of added programming complexity,
since any code that uses workplace shell objects must take account of
this possible dormant state by keeping persistent handles for any
objects that may become dormant, and explicitly locking objects for
the duration of their use.  This programming complexity may be
acceptable for a language such as C, but is not acceptable for use of
workplace shell objects from a high-level scripting language such as
Object REXX.

      Object REXX uses proxy objects to provide access to and from
SOM.  Every REXX object for which SOM access is required has a SOM
proxy object, and every SOM object for which REXX access is required
has a REXX proxy object.  Since REXX subclasses of SOM classes can be
created, some composite objects may have both a REXX object part and
a SOM object part, with the objects's methods and data being divided
between these object parts.  All these associations between REXX
objects and SOM objects are maintained in correlation tables held by
the object REXX domain server, with REXX objects identified by their
object references and SOM objects identified by their memory
addresses.

      When a REXX proxy object or a composite object's REXX part
receives a message destined for a SOM object, it uses the domain
server to find the associated SOM object and invoke the appropriate
method.  Similarly, the domain server passes on messages received by
SOM proxy objects and SOM object parts to the associated REXX
objects.

      Whenever an object reference is passed from REXX on a SOM
method invocation, the domain server finds the associated SOM object
and substitutes it for the REXX object passed.  Similarly, the domain
server replaces SOM objects by their associated REXX objects when
REXX methods are invoked from SOM.  The domain server also converts
other argument types (e.g., strings, integers, floating-point
numbers) between their REXX and SOM representations.

      This processing is entirely transparent to REXX and SOM
programmers, who see all objects in the appropriate native form.

The Workplace Shell Object Model

      The OS/2 Workplace Shell uses SOM as its object model.
However, workplace shell objects differ in some important respects
from regular SOM objects.  Whereas regular SOM objects reside at a
fixed address in memory, and are identified by memory addresses,
workplace shell objects can reside either in memory or on disk.

Disk-resident objects are used for persistence of the workplace shell
desktop across a system restart, and also to free scarce memory
re...