The Long Road

From EDM2
Jump to: navigation, search

by Sheila Harnett

OS/2 2.0, 2.1, 2.x, Workplace ...

The Workplace Shell debuted with the OS/2 2.0 operating system. Since that time, it has undergone many changes. Some of these changes affect the way your Workplace Shell applications look and feel, and some affect the way they interact with the Workplace Shell's API. With OS/2 2.1 now evolving and the debut of Workplace, it becomes important for us to share these changes with you. To that end, we bring you this column - a dedicated column brought to you to discuss issues and provide tips and techniques pertaining specifically to the Workplace Shell.

This first article describes some of the coming changes to the programming interface, as well as coming attractions for the Workplace platforms.

Developers' Connections into the Workplace Shell

Depending on your objectives, several levels of programming interfaces exist from which objects in the Workplace Shell can be manipulated. One level is made up of Win APIs (WinCreateObject, WinQueryObject, WinSetObjectData, and so forth) that you can start from a separate process; from a process other than the Workplace Shell's process.

Another level is comprised of the REXX wrappers for these Win APIs. If you use these RexxUtil functions in your application, you introduce the requirement that REXX be installed on the machine on which your application will be run. Keep in mind that REXX currently is a selectively installable option. Future releases of the Workplace Shell will feature new, additional Win APIs, along with new RexxUtil wrappers for these new Win APIs (WinMoveObject, WinCopyObject, and so forth). These improvements will make it easier for applications to customize the organization of the desktop.

The third level of access into the Workplace Shell API requires knowledge of object-oriented programming principles and, more specifically, the System Object Model (SOM). SOM provides for the language-independent specification of a class's interface and structure. SOM also provides tools for the generation of language-specific usage and implementation bindings that you can use to compile the overall application. By using SOM, the Workplace Shell can provide you with the power of an object-oriented programming paradigm, as well as binary compatibility between releases.

SOM allows you to subclass existing Workplace Shell classes, override existing methods to provide special processing, and introduce new methods. By subclassing SOM's class manager, the Workplace Shell lets you actually replace a system-provided class with a user-defined class. Workplace Shell applications that aim to control or restrict interaction with objects in the user-interface can extensively use class replacement.

Workplace Shell Class Descriptions - SOM 1.0 vs. SOM 2.0

As many of you are aware, SOM 2.0 followed SOM 1.0 as the next product in the System Object Model line. For SOM 1.0, the class specification language is called Object Interface Definition Language (OIDL). SOM 2.0 introduced an implementation of CORBA's Interface Definition Language (IDL) for class description. The Workplace Shell's classes have used SOM 1.0 through the shipping of the most current OS/2 Toolkit - OS/2 2.1.

SOM 2.0 is coming to the Workplace Shell, or perhaps it's the other way around. In preparation for this, Beta versions of SOM 2.0 IDL class descriptions for the Workplace Shell classes have been shipping with The Developer Connection for OS/2 CD-ROM. In the future, .IDL files will replace .SC files in the Toolkit. C and C++ bindings for the Workplace Shell API will continue to be shipped with the Toolkit. The SOMobjects Toolkit ships a utility called CTOI that facilitates the conversion of .CSC files to .IDL files for existing SOM applications.

The next logical step in the evolution of the Workplace Shell is to ship as a SOM 2.0 application, which will require that several of the SOM 2.0 runtimes ship with the base of OS/2. After the Workplace Shell debuts as a SOM 2.0 application (in a future release of OS/2), you will be able to take advantage of the additional capabilities and frameworks shipped with the SOM 2.0 SOMobjects Toolkit.

Inter-Process Operability a la DSOM

As a SOM 1.0 application, the Workplace Shell imposed the restriction that method invocations could only be performed on objects from the process in which the objects were created. That is, the only way to write an application that invoked Workplace Shell methods was to write a subclass, register the class, and have the Workplace Shell load the code for the subclass on its process. The only alternative was to use the set of Win APIs from a separate process.

To address the interprocess operability problem, SOM 2.0 introduced a framework (classes and runtimes) called Distributed SOM (DSOM). As a SOM 2.x application, the Workplace Shell will be able to interact with DSOM services; providing the ability to invoke methods on Workplace Shell objects from client DSOM applications' processes.

To achieve this, the Workplace Shell will, on demand, start up a DSOM server that will run under the Workplace Shell process. This server will field remote method invocation requests from other processes, execute the methods on the server, and return any results to the DSOM daemon so that they can be passed back into the caller's process. Figure 1 shows some of the objects that could interact during a remote method invocation. Proxy objects in the client process represent objects in the Workplace Shell process (WP01, WP02, WP03 and WP04). The client application invokes Workplace Shell methods directly on the proxy objects, and the proxy for the Workplace Shell Server coordinates with the DSOM services and daemon and the actual Server object to execute the method invocations on the Workplace Shell process. Workplace Shell class objects also will be remotely accessible.


Figure 1. Interaction between objects during a remote method invocation.

Initial DSOM support in the shell will not provide for Workplace Shell objects themselves to exist in separate processes. However, Workplace Shell objects will be able to interact with objects in other processes from the Workplace Shell process. You can achieve this by creating a Workplace Shell subclass whose methods invoke code that interacts with DSOM as a client. Figure 2 shows this interaction. Object DF is an instance of a subclass of the Workplace Shell class. WPDataFile. While DF is not in a process separate from that of the Workplace Shell process, its methods can become client DSOM applications. As such, they can communicate with proxies for other objects that reside in different processes. In Figure 2, assume Object C is running in a process different than the Workplace Shell process.

A proxy for that object can reside in the Workplace Shell process and act for object C. For simplicity, other DSOM-related objects associated with this interaction do not appear in the figure (for example, the Server object and its proxy for the ClassC process, the Object Adapter, and so forth).


Figure 2. Creating a WPS subclass whose methods interact with DSOM.

An Evolving API

For the next release of OS/2, the Workplace Shell is undergoing changes to both its user interface and its programming interface. One of the items directed at improving the functions of the programming interface will be to provide improved documentation for existing public methods, make certain private methods public, as well as to introduce new public methods. A preview of several of the types of methods that fall into either of these categories follows:

  • Methods to notify a folder when its contents have changed
  • Methods to manipulate a folder's sort, include, and details view attributes
  • Methods to better integrate user-defined views into the Workplace Shell
  • Methods to refresh the details (system- and user-defined) of an object and any details views in which the object can appear
  • Methods to query the folder in which an object resides
  • Methods to lock an object/class so it will not be unloaded
  • Methods to more easily retrieve objects from handles, object IDs, pathnames, and so forth
  • Methods to manipulate the system settings (OS/2 System Setup objects)
  • More comprehensive setup string processing for the remote control of objects

Further API improvements planned for future releases involve the creation of thread-safe utility classes for use by Workplace Shell applications, improvements to better separate objects' state from their views, public classes for the specification, and modification of default view behaviours (that is, a PM Container view of a WPFolder), and additional notification methods (intended to be overridden) so that user-defined classes can more fully control the use of their instances.

Watch this Space!

While this article provided future directions, additional articles in this column will feature how-tos, tips, and discussions of issues related to Workplace Shell application development. So, watch this space. Also, check out the Workplace Shell samples that have been shipping on the accompanying CD-ROM.

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation