use of system objects, object class replacement, system hooks, and other means to create an evolutionary upgrade to the OS/2 Workplace Shell.
Most of Object Desktop is written to the Workplace Shell API. It exploits a number of unique specializations of this API, as well as a few obscure system hooks rarely seen in OS/2 programs. One interesting result of the Object Desktop implementation is that there are no executables! Object Desktop is made up entirely
of dynamic link libraries, which are registered either directly or indirectly via the Workplace Shell object-class registration mechanism (WinRegisterObjectClass). Registering a Workplace Shell object class results in an entry being placed in the OS/2 system INI database. The OS/2 Workplace Shell interrogates this database on system start-up and demand loads the corresponding object classes via dynamic linking. Hence, the only executable that runs is the installation program, and thereafter the operating system directly invokes the object code when necessary.
Changing the OS/2 Shell
The most common way to enhance the OS/2 Workplace Shell is by adding new object types to the system class hierarchy. Programming in this environment necessitates using IBM's SOM and Workplace Shell APIs. SOM programming fully supports object-oriented capabilities such as inheritance, polymorphism, and encapsulation, as well as binary replacement of base classes.
To create a new class, you genera
te a SOM interface definition language (IDL) file and run it through the SOM precompiler. The precompiler emits C or C++ bindings with empty functions for each object method, private and public header files, and other optional project components. The parent class for the newly generated object class is specified in the SOM IDL file, which, in the case of Workplace Shell objects, is one of the preexisting classes defined by the default OS/2 Workplace Shell. Each overridden method is also specified in the IDL file, along with public and private methods and data.
After the components of the SOM/Workplace Shell project have been generated, OS/2 API or Workplace Shell method code is inserted in each of the overridden methods. The structure of the Workplace Shell methods provides the necessary entry points for creating new windows as necessary, and for creating new threads and initializing resources. For example, a wpInitData method is provided; it's analogous to a C++ object constructor. The Workplace Shell
process calls this method whenever a new object is awakened or created. In other cases where new object views may be desired, a programmer can override the base method wpOpen, which is called by the shell whenever a new view is generated for the user to interact with.
Although there are several object types in the Workplace Shell (
see the figure
), there are several reasons for using the WPFolder class as a parent class. Contained objects are saved and restored in a safe and portable manner. File system back-notification of object changes is provided via wpAddToContent and wpDeleteFromContent methods. WPFolder supports background bit maps to customize appearance, custom colors and fonts are saved with no extra effort, and drag-and-drop operations such as copy and delete are supported. And the context menus of contained objects are invoked and dispatched.
WPTransient objects are used within Object Desktop to display temporary objects that do not correspond to any object
normally on the OS/2 Desktop. This includes displaying the contents of an Object Archive (i.e., a ZIP file), which is really just a view of a database. In fact, the use of WPTransient objects as temporary placeholders to database query entries is fairly common.
Class Replacement
Probably the most powerful capability exposed by the Workplace Shell API is replacing classes in the SOM/Workplace Shell class hierarchy. Class replacement enables programmers to add behavior to all classes derived from a particular class. The Workplace Shell group originally developed this capability by creating a customized SOM class manager object. (SOM version 2.x has this capability in the somSubstituteClass class manager method).
Class replacement is difficult to describe since there is no analog in other object models to pull examples from, and since "replacement" isn't really what happens. The mechanism is actually more
like an "insertion" into the object
class hierarch
y.
A new class is derived from a parent class in the Workplace Shell class hierarchy. The new class is given specialized behavior -- new private and public data and methods may be added to the new class. A one-time call to the OS/2 WinReplaceObjectClass API is made, replacing the original parent class with the new class. After restarting the system, all classes derived from the original parent class, including instance objects of that parent class, gain the behaviors of the new class.
This mechanism may be hard to visualize, but the results are astounding. As the figure above implies, MyNewClass does not actually replace the parent class WPFolder as much as it sneaks into the class pecking order right after WPFolder. The result is that any behavior added to MyNewClass is propagated down to the classes derived from WPFolder, such as WPDrives and WPNetwork. This is how a number of Workplace Shell enhancements are implemented, including the IBM Multimedia Viewer, Lotus cc:Mail, and some object-lev
el security add-ons.
To see class replacement in action, install the Multimedia Viewer from the Warp BonusPak. Then, all objects derived from WPDataFile (which includes any file on your system) will gain the menu choice Create LTReference, which can be used to create a reference for the data object (an image or other multimedia data type) in a new type of folder called a "light table."
Advice for Enhancing the UI
Developing an object that enhances the UI implies that the code is always active, which is a challenge to minimizing system impact. Products intended to be add-ons must work with the same performance features and stability as the system they are installed on. System requirements should not be greatly affected.
The best way to ensure system stability is to use OS exception handlers in all object methods. The OS/2 and Win32 APIs allow for structured exception handlers to be added to programs or objects, giving programs the ability to self-diagnose memory violat
ions, to recover gracefully from stray pointers, and so on. If your objects or objects you interact with use semaphores -- a universal trait in a multithreaded environment -- exception handlers are a necessity to ensure that resources acquired are freed even when a memory violation occurs.
When implementing a system add-on, use the least common denominator of API features for maximum compatibility. While it is tempting to use features that may appear only on one particular flavor of an operating system, don't succumb. Use the set of APIs that maximize your potential market.
In terms of forward and backward compatibility, an interesting option surfaces when using a flexible object model like IBM's SOM or another CORBA-compliant object model. With these types of systems, it is easier to write objects that adapt to the environment they encounter. For example, in OS/2 2.11 there is no provision for folder objects to have animated icons. Users of Stardock's Object Desktop, however, would like to have
support for this new feature in the OS/2 Warp user interface. By taking advantage of SOM, Object Desktop objects are able to discover that a particular interface is implemented by base functionality when running under OS/2 Warp, and then dynamically overriding the corresponding methods on the fly.
After investigating the various ways you can enhance the OS/2 Warp user interface, and the care you must take to write applications that seamlessly blend with the operating environment, you have to answer a fundamental question: Is it worth it?
There are obvious advantages to developing applications in this manner. Complete forward and backward compatibility is guaranteed by the IBM System Object Model, which allows for changes to base class code without recompiling. Because of this capability, Workplace Shell developers enjoy receiving new features for free as versions of the OS are released with changes to base classes. Another advantage to SOM/Workplace Shell programming is a more elaborate and fle
xible architecture for developing adaptable code.
Workplace Shell objects also present a more powerful set of capabilities to end users. Most OS/2 applications are written to the Presentation Manager API alone. These programs miss out on exposing links to shell objects altogether. To gain similar features to shell objects, developers have to laboriously code drag and drop, settings notebook, and other UI nuances instead of inheriting them. What's more, as IBM adds the intended OpenDoc and Taligent code bases to the Workplace Shell, Presentation Manager applications will have to be revised to keep up. Workplace Shell objects will inherit these features for free.
illustration_link (7 Kbytes)
The Workplace Shell object types are organized by their persistence characteristics.
WPTransient objects have no persistence; they exist only during the lifetime of the machine state (Workplace Shell process state).
WPAbstract objects store object settings in the OS/2 INI files, and WPFolder and WPDataFile objects store object settings in extended attributes inside the OS/2 file system.
illustration_link (19 Kbytes)
Class replacement in the OS/2 Workplace Shell enables programmers to insert their new classes anywhere in the
class hierarchy, allowing all derived classes to inherit the new behavior.
Kurt Westerfeld develops software products for Stardock Systems, Inc. You can reach him on the Internet at
kwester@mail.os2bbs.com
.
Extending OS/2's User Interface
