The Workplace Shell has been implemented in such a way that the whole shell and all its objects, be they system supplied or user developed, run as a single OS/2 process. This has some very significant implications:
This is a problem familiar to PM programmers, and as with PM, the solution is to start a second thread for the long-running code. Typical situations where this problem can arise include retrieving data from a database or communicating with a host system.
The recommended solution to these problems is to split an application into two parts: one part, consisting of one or more WPS objects running in the WPS process, the other part containing most of the application logic running as a separate OS/2 process. The two parts communicate using the interprocess communications (IPC) facilities of OS/2.
To avoid the problems above, it is best to put as little of the application as possible into the WPS objects themselves. Clearly some functions must be there - for example the code to create and handle an object's context menu, or to handle direct manipulation - and we have found it best also to code PM dialog and window creation and their dialog and window procedures within the WPS objects. Other application functions, such as database access, communications and calculation, should be put in a separate process.
This structure approximates to the Model-View design approach favored by object-oriented programmers. Our recommendation effectively places the View in the WPS process and the Model in a separate process.
The Workplace Shell documentation provides no guidance on good and bad ways of implementing an application using IPC between the shell process and the application processing thread. OS/2 Version 2.0 - Volume 4: Application Development includes a discussion of this and describes one approach that has been tried, along with programming examples.