Summary

Presentation Manager applications differ in structure from conventional applications. Presentation Manager applications are composed of a number of windows, which represent objects upon which the application operates. Windows respond to events, communicated by way of messages passed to the windows from Presentation Manager or from other windows.

Windows may be either display windows, which operate on objects known as presentation spaces, or object windows, which operate on other objects such as databases or remote systems. Display windows have a visual manifestation on the screen, while object windows are typically hidden and act merely as addresses to which messages may be sent in order to initiate actions.

Windows are grouped into classes. Each class has similar characteristics and responds to messages in a similar way. Window classes must be registered to Presentation Manager. Some window classes are defined as public, and may be used by all applications in the system, while other window classes are defined privately by an application, and are available only to that application.

The response of a window to the messages it receives is determined by its window procedure. All windows of the same class share the same window procedure.

Messages are also grouped into classes; Presentation Manager defines a number of message classes, and applications may define their own classes for communicating events between windows in the application. Message classes are simply defined using integer constants, and are not required to be registered to Presentation Manager.

The structure of a Presentation Manager application is therefore that of a number of windows which communicate by way of messages. Since these messages normally constitute the only means of communication with a window and the objects upon which it acts, this application structure forms a good basis for the implementation of object-oriented software engineering principles. The use of such principles in Presentation Manager applications is discussed at length in OS/2 Version 2.0 - Volume 4: Application Development.

Workplace Shell applications are implemented using the System Object Model component of OS/2 V2.0. This is a language-independent environment for object-oriented programming, along with a set of utilities that enable the programmer to define object classes, and to implement them in non-OOP languages such as C.

A Workplace Shell application will typically consist of one or more objects, which are defined by the programmer using the SOM, and inheriting characteristics from the Workplace Shell's own existing classes.

The shell and all its objects run in OS/2 as a single process, which makes the shell and its objects vulnerable to a single object that is unresponsive or which abends. A well-designed Workplace Shell application should therefore be structured so that the bulk of its application logic runs in a separate process, communicating with the Workplace Shell objects that implements its user interface by means of OS/2 interprocess communication.

It is possible to write PM programs that integrate to some extent with the Workplace Shell environment, for example by supporting printing by direct manipulation, but such programs will never behave quite like properly designed Workplace Shell applications. Migrating existing PM applications to work better in the Workplace Shell environment is fairly straightforward, and good results can be obtained in many cases by exploiting the association facility of WPS. Fully migrating a PM program to become a SOM/WPS application may be possible in many cases, though this involves considerable redesign and programming.

We cannot give a clear recommendation as to which programming model - PM or WPS - to adopt for new applications. It will depend on many factors, such as the application itself, the needs and skills of the users, the skills of the programmers, and on any other applications that may be used at the same time. The decision must be made based on the nature of the application and the customer environment in which it is to be used.


[Back: Migrating Existing Applications]
[Next: Workplace Shell Implementation]