The WPS Class List

In the "Workplace Shell" object, XFolder creates a page called "WPS Classes" with which you may influence the WPS class list.

In order to use this page successfully, it might be helpful to have a general understanding of what WPS classes actually do. The following information is supposed to assist you in this.

You have probably heard many times that the OS/2 Workplace Shell is "object-oriented". This term suggests that -- opposed to other user interfaces, such as that of Windows 3.1 -- everything the Workplace Shell deals with is supposed to be an "object": this applies, for example, to files, folders, printers, drives etc. All these objects have certain common characteristics, such as context menus and settings notebooks, but differ in certain others: e.g. what you see in a context menu is different depending on the selected object.

In order to better be able to handle these common and different characteristics, the WPS uses "classes". This term has been taken from object-oriented programming; a class is, so-to-say, an abstract concept for an object. A class is therefore not visible on the Desktop, it thus does not "exist" in the same sense as objects do, but it contains all the information about properties and capabilities of an object.

Now, every object on the Desktop is a so-called "instance" of a class. The names of most of the WPS classes start with "WP": for example, a printer is an instance of the "WPPrinter" class, a folder one of the class "WPFolder", a datafile of "WPDataFile" and so on.

The reason for the power and flexibility of the class concept is that the different classes may descend from each other. A class which is descended from an other class inherits all of its properties and capabilities. It is thus possible to make certain features of the user-interface more abstract, according to the old principle: the best way to handle complexity is abstraction.

One can also apply the concept of classes to things in the "real" world to clarify it: for example, think of several classes named "Animal", "Mammal", "Dog", and "Bird". The classes "Mammal" and "Bird" would then be descendants of the "Animal" class, while "Dog" would descend from "Mammal". Your own dog would then be an instance of the "Dog" class, so-to-say. Its behavior would be determined by the classes "Animal", "Mammal", and "Dog" altogether.

The WPS now contains many classes, which make up a very thoughtful inheritance hierarchy. The following excerpt from the WPS class list may make the general structure more lucid (where the lines signify inheritance):

   WPObject
     ├── WPAbstract
     │     ├── WPPrinter
     │     ├── WPProgram
     │     └── WPShadow
     ├── WPFileSystem
     │     ├── WPDataFile
     │     │      ├── WPIcon
     │     │      └── WPProgramFile
     │     └── WPFolder
     │            ├── WPDesktop
     │            └── WPStartup
     └── WPTransient

You see that all classes are descendants of WPObject. This is the so-called "root class" of all WPS classes and contains all the features that are common to all WPS objects: as mentioned before, e.g. context menus and settings notebooks. However, the WPObject class is too abstract to have instances of it: this class was only implemented to have other descendant classes. Objects of this class will not function.

WPObject has only three descendant classes. All these classes are -- like WPObject -- only meant to be abstract parent classes, of which no objects should exist directly.

WPAbstract is the common parent class for so-called "abstract" objects, i.e. those objects which do not physically exist on disk, but only store their data in OS2.INI and OS2SYS.INI. The most well-known examples for this are the above-shown classes WPPrinter for printer objects, WPProgram for program objects, and WPShadow for shadows. All these objects do appear in folders, but are not visible if you enter DIR at the command line, for example.
By contrast, WPFileSystem is the common superclass for objects which do exist physically in a file system of a drive. There are two subtypes: folders (WPFolder class) and data files (WPDataFile). In turn, there are several subclasses of WPDataFile, like WPIcon for icon files (.ICO extension) and WPProgramFile for program files (e.g. .EXE extension). All data files for which no more specific subclass exists are instances of WPDataFile.
Finally, WPTransient is used by the WPS for objects which need not save their data at all, but only exist temporarily for representing something. Examples of this are print jobs in a printer object and all the devices in Warp 4's Hardware Manager.

The WPS also offers an exceptional mechanism called class replacements. This feature is used extensively by XFolder to hook all of its features into the WPS by replacing a number of WPS classes. For ecample, the XFolder class itself replaces the WPFolder class to implement the new folder features. Such a replacement class must always be a descendant of the class which it should replace; "replacing" the class then means that the WPS will always use the replacement class whenever the original class would normally be used. As a result, if you have XFolder installed, all folders of your system are no longer instances of WPFolder, but of XFolder. But since XFolder is a descendant of WPFolder, only those folder characteristics change for which XFolder provides additional functionality.

All WPS classes reside in dynamic link libraries (file extension .DLL). For example, most of the default WPS classes reside in the large PMWP.DLL file in the \OS2\DLL directory. All XFolder classes reside in XFLDR.DLL in the XFolder installation directory.

Using this feature enables programmers to implement new features for a class without having to know in detail how a certain class works internally. As was said before, this is an outstanding and powerful concept, which still only OS/2 offers.

Please note that if you attempt to deregister certain OS/2 system classes (which you normally shouldn't do anyway), this will probably have no effect if the DLL containing that class contains other WPS classes which are still registered. This applies especially to the OS/2 Warp 4 Multimedia classes: all those are contained in MMPARTS.DLL, and as long as one of these classes is still registered, all the multimedia classes will still be loaded, even if they don't appear in the WPS class list.

Again, this is only a short introduction to the WPS class list. If you open the "WPS classes" page in the "Workplace Shell" object, all of the classes installed on your system will be displayed. Regularily, these will be more than 100 classes, which will appear in a tree structure. Using context menus, you may register and replace classes here and also deregister classes and undo class replacements.

Please note that you should be very careful when manipulating the WPS class list. With the aid of this page you may render your OS/2 system unusable in seconds!

Press the "Help" button on that page to receive more detailed information.