Properties in jWPS

Object-oriented design is based on a few fundamental principles. One of the most basic is that there are object which have properties associated with them. So for example, an OS/2 might not allow copies of itself to be made, or it might not be printable (how would you print your mouse?) Not surprisingly, OS/2 WPS objects have properties. There are two basic ways that one may make properties available. Either have a set and get method for each property (OS/2 uses set/query pairs mostly, but it is the same idea), or have key/value pairs, where the key is usually an integer and the value varies as a property – maybe a string value for a title or logical value to control whether the object can be dragged). The plus with the first method is that is immediately clear which properties are there. The downside is that it does not scale well. Having 200 or so methods to set/get values is a nightmare. The latter method requires very few methods but many keys and a knowledge of what they can do. This is the best that can be done and the onus is then on the documentation to keep it clear.

OS/2 of course used not quite either of these systems, having certain set/get pairs for some properties, key value pairs for others and still an even more opaque system of bit switches for others. This should be explained (at least as I understand it) the programmers who wrote OS/2 were very savvy and were working on hardware we would consider minimal at best. The first versions of OS/2 were required to work on a 386 processor with 4 - 8 megabytes of memory. As such every bit of performance was squeezed out and there were (and possibly are) large chunks of the system that were hand-tweaked assembly code. This made OS/2 an enviable operating system and indeed it was the case that it ran DOS and Windows programs faster than on their native systems. It was said that only IBM had the expertise to pull off a coding feat like OS/2. It cost nearly a billion dollars all told and occupied a couple of hundred programmers for the better part of a decade. It won hands down most every award at the time for technology.

The downside of programming with this API is that, from an object-oriented perspective they were riding on the edge and sometimes crossed breaking encapsulation and a few other rules. This leaves those of us who write to the API with odd syntax rules, (a return value of true from a procedure either means that there was no error (it succeeded) or there was an error), no clear way to find if procdures fail (since in C unlike Java false is actually the value of zero, procedures that return a numeric value sometimes can't return whether they failed and resort to any of several different means of communicating this). Each call has to be handled differently. One of the early reasons for writing jWPS was actually to get some low-level access to OS/2, but then it became clear that the API was very muddled and I took it up as a project writing cleanly what I think OS/2 should have had from the start in Java.