Feedback Search Top Backward
EDM/2

Road Map to the Work Place Shell

Written by David Campbell

 

The Work Place Shell

The Work Place Shell (WPS) is the new user interface introduced with OS/2 2.0. This article will begin a series of articles dedicated to explaining the operation and use of the WPS. In preparing this initial article, I was overwhelmed by the amount of material I would have liked to include. There are so many aspects of the WPS to discuss. For example, Installation and Maintenance, Programming new WPS Classes, and future enhancements.

Since the amount of material is so large, I will divide the topic into 2 or 3 articles. The first article will discuss Installation and Maintenance. The second article will discuss programming issues facing developers who wish to write classes for the WPS. The third article will discuss future enhancements to the WPS. With the first article I will attempt to cover the following topics:

  • Evolution of the User Interface

  • Configuration and Maintenance of the WPS

  • Suggestions for Implementing the WPS

Evolution of the User Interface

To better understand the WPS, it is necessary to be aware of the evolution of the user interface. The user interface has a very simple purpose, and that is to translate human initiated actions into computer operations and communicate these operations to the operating system. Traditionally their have been two different types of user interfaces. These include:

  1. Character User Interface (CUI)

  2. Graphical User Interface (GUI)

Early user interfaces were CUI. That is they could only display the characters defined in the ASCII set. Examples of this type of interface are the command line interfaces provided with DOS 3.3 and early implementations of UNIX and VMS. This was limiting, but it was the only choice primarily because of 2 hardware constraints. Early CPUs did not have the processing power to manage a GUI. Also, the video controllers and monitors were unable to display the high resolution necessary to implement a GUI.

The CUI evolved into the GUI. The GUI provided vastly superior capabilities. It was now possible to display on the screen different fonts, images, and other graphical data. This type of interface required more CPU processing power, but the power of CPUs was increasing and the cost of CPUs was decreasing, so it was an acceptable penalty. With most current GUIs, emphasis is still on the 'application'. That is to say, the user interacts with applications. These applications in turn interact with the data that the user requests.

The philosophy of this type of system is somewhat backward. The user should interface directly with the data, and the application should be evoked implicitly to act upon the data. This approach to user-data interaction lead to the development of object oriented user interfaces. The WPS is IBM's attempt at an object oriented user interface (OOUI). With the graphical interface, it became possible to represent 'objects' using icons. IBM has stated that that the current WPS is the template of future OOUIs. These future OOUIs will be grafted onto AIX and future operating systems. Therefore, the importance of becoming proficient at using this type of interface is obvious.

To summarize:

  • To implement an OOUI effectively, the video subsystem must be operating in graphical mode. This is necessary to display detailed images which represent objects.

  • An OOUI places emphasis on the data or object, whereas current CUIs and GUIs place emphasis on the application.

Configuration and Maintenance of the WPS

The user interface used by OS/2 is loaded by the base operating system at system startup. OS/2 can be configured to load any type of user interface. By default, the OS/2 installation procedure specifies the WPS as the user interface. In the config.sys file, there is a line which reads:


PROTSHELL=c:\os2\pmshell.exe

This line specifies the protected mode user interface. If you want to load another user interface, this is where you would place the new execution file.

Interestingly, another environment variable affects the WPS. This environment variable is 'RUNWORKPLACE'. This environment variable is also used to specify the shell.

The WPS is composed of objects. An object is an instance of a class. Each object is represented by an icon. Each class has its own methods, data, and class icon. The context menu of each class is different. The settings notebook of each class is different. Interacting with objects has several advantages. The operating system and user interface only have to be familiar with the classes. Each external device is represented as an object. For example, the keyboard, the mouse, the storage devices, and the printers. Each file and directory on storage devices are also represented by objects. Finally, each process and print job is represented by an object. In this way, the operating system has a common interface to everything it interacts with, because everything it interacts with is an object. The WPS is written using the System Object Model (SOM). SOM is written to help developers create classes more quickly, and from different languages. SOM forms a class hierarchy which is shown below.


 SOMObject
 +- SOMClass
 +- SOMClassMgr
 +- WPObject
    +- WPAbstract
    |  +- WPPrinter
    |  +- WPProgram
    |  +- WPShadow
    +- WPFileSystem
    |  +- WPDataFile
    |  |  +- WPProgramFile
    |  +- WPFolder
    |     +- WPDesktop
    |     +- WPDrives
    |     +- WPStartup
    +- WPTransient
       +- WPJob
       +- WPPort

Note: Please note that the above class hierarchy is not complete. I have only included the most significant classes. Also note the class WPProgramFile. This class is actually derived from WPDataFile NOT WPFileSystem as most of the IBM documentation states.

Due to the length of this article I will only discuss the classes which begin with WPObject. WPObject is the parent class of the 3 base classes:WPAbstract, WPFileSystem, and WPTransient. These 3 classes represent the foundation classes. Each base class is differentiated from the other base classes in the way in which the class data is maintained. Classes derived from WPAbstract classes store their instance data in the os2.ini file. Classes derived from WPFileSystem classes store their instance data as a file or directory on permanent storage. Classes derived from WPTransient classes do not store their instance data, therefore all WPTransient instance data is not maintained if the computer is restarted. This differentiation in storage types classifies WPAbstract and WPFileSystem as persistent, and WPTransient as being non-persistent.

Each of these classes has some very common implementations. For example, the typical user creates a folder which contains programs and files. This implementation utilizes 3 WPS classes, WPProgram, WPDataFile and WPFolder. The folder used is an instance of WPFolder. An instance of WPFolder represents a directory on a diskette or hardrive. A folder is used as a container for other objects. Each file in the folder is an instance of WPDataFile. An instance of WPDataFile represents a physical file which exists either on a diskette or a hardrive. Each of the programs within the folder is an instance of WPProgram. Notice this is not the same class as WPProgramFile. Notice also that you do NOT want to copy the execution file into the folder. An instance of WPProgram is a reference to an execution file. This reference is used to specify the name of the execution file to execute, any parameters, the startup directory, and other information. An instance of this class typically uses the ICON resource within the execution file.

To compare and contrast these 3 classes, we enumerate the settings notebook of each class. Notice the differences in the settings notebook for each class.

An instance of WPProgram has 5 pages in its settings notebook.

  1. Program
  2. Session
  3. Association
  4. Window
  5. General

An instance of WPDataFile has 4 pages in its settings notebook.

  1. Type
  2. Menu
  3. File
  4. General

An instance of WPFolder has 8 pages in its settings notebook.

  1. View
  2. Include
  3. Sort
  4. Background
  5. Menu
  6. File
  7. Window
  8. General

Maintaining the WPS is critical to satisfactory use of the user interface. Due to the power and flexibility of the WPS, maintenance can be a somewhat difficult task. Fortunately, their are ways to effectively maintain the WPS to provide outstanding performance and usability. The number 1 thing is to keep your os2.ini and os2sys.ini files backed up. This can be done using 'RUN' commands in the config.sys file. You can use a 'RUN=C:\OS2\XCOPY OS2.INI C:\TEMP\OS2.INI' this will copy the os2.ini file before the WPS starts. Once the WPS starts, it opens the os2.ini file. The os2.ini file remains open until the system is shutdown. Therefore, it is impossible to make copies of the os2.ini file while the WPS is executing.

Always properly shutdown the system. The WPS maintains several open files. Unexpectedly turning the computer off can have disastrous effects on the system configuration files.

The next item of maintenance is concerned with maintaining the active class list, file types, file associations, and object handles. I have written several utilities in REXX to perform these functions. Information on these utilities is presented in the next section.

Suggestions for Implementing the WPS

Learning to effectively use the WPS can be difficult. Upon initial introduction, the casual user tends to configure the WPS similar to the Microsoft Windows environment. For example, a software developer starts an editor to edit a source file. The user then saves the file and exits the editor. He then evokes the compiler to convert the source code to an executable file. He then runs the execution file.

Here is an alternative. Create a folder on your desktop titled source. Within this folder create several data files representing your source code. For each of the data files, set the TYPE to either C code or REXX or whatever. Then create a program object (WPProgram) for the compiler. On the associations page of the program object, select C code or REXX. Now when you select the open menu of the data file, you should see an editor and a compiler. Now, to open the file to be edited, select the editor from the open menu. To open the file to be compiled, select the compiler from the open menu. In this way, you are interacting more with the data than with the application. For example, the data file can have 2 actions performed on it, edit and compile. We have created an open menu which has these options!

I have created a set of REXX utilities for managing some of the aspects of the WPS. These utilities allow you to add a type, delete a type, enumerate all of the existing types, add an association, delete an association, enumerate all of the existing associations, get EA information, and set EA information. Several other utilities are needed, but I have not had the time to develop them. All of these utilities can be obtained via anonymous FTP from my machine:


campbell.saic.com      139.121.81.146

Please feel free to contact me if you have questions concerning this article or the WPS. I believe the WPS to be one of the most significant parts of OS/2 2.x. I also believe that without better understanding and knowledge of the WPS, OS/2 2.x's future is somewhat in doubt. It would be a shame for such a wonderful system to go unnoticed. Let's not let that happen!