1. Workplace Shell

The Workplace Shell (WPS) is probably the most distinctive OS/2 characteristic, and the one least likely to ever be reproduced on any other platform. The WPS is a customizable, object oriented desktop that is tightly integrated into the operating system. The complete customizable-ness of the WPS makes OS/2 an excellent integration platform where off-the-shelf applications and custom built applications can be combined with the WPS into a complete system to fit a particular user requirement. The default behavior of many of the WPS objects allow applications that are not WPS aware to still take advantage of some of the WPS features, such as drag and drop. And since the WPS is built on SOM (see below) it can be altered and enhanced with add-on programs that change the appearance and functions of existing desktop objects.

The object oriented design, along with extensive drag and drop support means the user works with objects on the desktop in order to accomplish tasks, applications as such blend into the desktop. WPS applications appear to the user as objects on the desktop which the user works with, rather than discrete applications that the user starts, works in and then closes.

SOM (System Object Model) is a framework that allows "objects" to be defined and distributed as a "library", that can be used by other programs. The "using" programs can create new objects based on already existing objects and optionally modify the functions and data variables inherited from parent class object. That by itself is no big deal; C++, Java, Object Rexx and Smalltalk are all object oriented languages that provide similar features. What makes SOM a big deal is that 1) the objects can be implemented in one language and used by a completely different language, 2) with careful programming the implementation of the object can change without requiring any changes, including a recompile, of the using programs, and 3) the objects that are used can reside in a different address space on the same OS/2 machine, on a different OS/2 machine, or on a different machine running a different operating system. Lets look at each one of these attributes.

SOM Objects can be implemented (programmed) in C or C++. This means that new objects could be programmed from scratch, or more interestingly, existing applications can have an "object oriented" wrapper applied that allows parts of the application to be used by other programs. SOM objects can be used by programs written in C, C++, Java and Object Rexx. Used here means not only instantiating the object, but also subclassing an object and overriding methods and variables, which means for example that a Java or Object Rexx program can create a new object (subclass) based on an existing object implemented in C. Functions implemented in one language and used in another language are not all that rare, for example Rexx (an interpreted language) is extended with C language programs. But to have objects that are implemented in one language and used in another, SOM (or CORBA, see below) is the only game in town.

As long as the implementor of the SOM object follows some basic rules, he can change an object (within reason) and still have the object work in the using programs, without the using programs even knowing the object was changed. This is the attribute that makes maintenance and upgrades of applications with SOM interfaces possible. An application can be enhanced or modified and new DLLs distributed and still not break all the other programs that may be using objects exposed by the applications.

Rexx is a powerful, relatively easy to use, interpreted language that is designed for scripting applications and basic automation tasks. Rexx is a standardized ANSI language and has been included as part of OS/2 since the beginning. IBM, Microsoft and a number of other commercial vendors sell or freely distribute Rexx interpreters for a wide variety of platforms, in addition to the open source Rexx interpreters that are widely available. Rexx interpreters are available for everything from DOS to mainframes, including all version of Windows, and most versions of Unix.

Rexx is designed to be easily enhanced with functions that are implemented in C. IBM and others have taken advantage of this to provide extensive Rexx interfaces to almost all aspects and parts of the operating system. Almost all the Control Program and many of the PM functions are Rexx enabled, along with the UPM (user logon and ID administration), Netbios, TCP/IP, DB2, Oracle, SQL Anywhere, mySQL, and dBase Rexx interfaces. It is hard to think of any aspect of OS/2 that cannot be scripted with a Rexx program.

The vast majority of OS/2 applications that provide scripting capabilities use Rexx as the scripting language, so much so that on OS/2 Rexx truly is the universal scripting language. The same language used for scripting the operating system is also the language used for scripting applications. There are (or were) at least three different commercial rapid application development (RAD) environments for Rexx in addition to IBM's outstanding freeware RAD.

With the appearance of Object Rexx in Warp 4, Rexx became a full featured object oriented language. Object Rexx brings also SOM to Rexx, meaning that Object Rexx can create Rexx objects from SOM objects, subclass those objects, override methods, etc. In addition to opening up a whole new interface between Rexx and the WPS this also opens up a whole new way to Rexx enable applications: applications can now publish their interface as SOM objects that can be used by Object Rexx or another other SOM enabled language.

IBM is the world's second largest publisher and it shows. The quality of documentation available for OS/2 is astounding. With very few exceptions IBM documentation (hence OS/2 documentation) is first rate. And with very few exceptions IBM's documentation is sufficient; you don't need to go to the bookstore and buy another book because you can't understand the OS/2 documentation or because it is not complete enough. A simple comparison between the Window's SDK manual and the OS/2 Control Program manual is illustrative. Every function call in the OS/2 Control Program Reference manual has an example, while I would be surprised if more than 30% of the function calls in the Window's SDK reference document had examples.

Where OS/2 shines is in consistency. It is very backwards compatible from release to release. It is very rare for an application to stop working with a new release of OS/2 - although not as rare for a fixpack to break an application. It is entirely realistic to use applications purchased 10 years ago on today's OS/2 - and I do. It is also realistic to download applications or applets written for OS/2 1.3, when OS/2 was a 16-bit operating system, and have those applications work fine on the very latest version of OS/2, i.e. eComStation. This feature alone makes OS/2 a significantly cheaper operating system to use than any other. It also means that documentation doesn't become obsolete, programming techniques discovered and published 8 or 9 years ago are still relevant (like <$Link U="http://www.edm2.com" T="EDM/2">), and it means that the operating system can be upgraded, if necessary, without having to upgrade applications. Compare that with Microsoft Windows.

It may seem strange to list non-OS/2 application support as a strength of OS/2, but it is. I still use an occasional DOS program and I still use a number of Win16 applications on a regular basis. They work fine for me, in some instances better than their Win32 counterparts. It is possible for me to continue to use DOS and Win16 applications because OS/2 supports DOS and Windows so well. It doesn't just run the applications, but it integrates the applications into the whole system: they are multitasked, can appear in a desktop window, and with interprocess communications they can be integrated to some extent with OS/2 applications.

The reason why OS/2 is so good at release to release compatibility, why the WPS is such a good design, why SOM was used to build the workplace shell and the SOM API was published and made available to developers, and why the documentation is available and is of good quality, is because OS/2 was built by IBM.

IBM has a mainframe mentality that permeates their thoughts and actions - or at least it used to. That mainframe mentality has been a curse when it comes to marketing, but is a blessing when it comes to designing and maintaining an operating system. Mainframes are used by companies that invest large amounts of money writing custom applications for their business. These companies can't and won't tolerate changes to their mainframes (hardware or software) that jeopardize their investment. They also generally will not upgrade the system unless there is a very good reason to do so, which means that older versions of mainframe operating systems are used for many many years after they are released. Mainframe vendors, if they want to keep their customers, 1) make sure that new releases of an operating system or its components don't break existing applications, 2) support previous releases for very long periods of time, and 3) make sure that new releases incorporate changes that are a very real benefit to the customer. The length of time that mainframe operating systems are in use, plus the difficulty of releasing upgrades without breaking existing applications, require a strongly centralized architecture and design of the operating system. OS/2 is the beneficiary of all this.