Object-oriented OSes are almost here -- as always
Dick Pountain
How hard do you laugh when you hear that "there is an object-oriented OS in your future"? It's not that the words are
necessarily
untrue. Unfortunately, however, OOOSes remain stubbornly stuck in your future, not your present.
Why should you care? How about better integration. Microsoft Office users already take for granted the ability to drag an Excel graph into a Word document. Now picture this: You need a widget diagram for your monthly report. Click on the search button and ask for widgets. Soon the search returns an icon for the report "Widgets in the 1990s" by Fred Smith in the Manchester office. You open it, drag his diagram into your document window, and attach an electronic Post-It note to his report, thanking him for the loan. Computer user
s now only dream of this seamless, content-addressable data access, but an OOOS is the way there.
Which OOOS aspects are in this fantasy? Well, the reason you could locate that widget diagram is that Fred's report is a compound document -- a collection of objects whose multiple attributes are made visible to the search software -- rather than a file that is just a named bag of bits and makes sense only to the application that created it.
Your search could reach Manchester because Fred's compound document is stored in a distributed object store encompassing not just his own hard disk, nor even just his office LAN, but the whole company's WAN. It doesn't matter whether he's running the same hardware (or even OS) as you because a Common Object Request Broker Architecture-compliant (CORBA) ORB broadcast your search in a platform-neutral format. You didn't need to explicitly log on to any network or run a communications program because in this
persistent object store
, you access objects by sp
ecifying their names or attributes, neither knowing nor caring where they are physically stored.
Finally, you could drag the diagram from his document into yours because both documents conform to the same object-embedding interface. This might be OpenDoc or Microsoft's OLE (see the sidebar "Signs to Cairo"). By the time this scenario is realized, maybe they'll have stopped squabbling and be compatible with one another.
Portrait of an OOOS
The purest form of an OOOS could hardly be simpler in concept: A small microkernel talks to the computer hardware, and the rest of the OS consists of replaceable modules, or objects. Outside the kernel code, there's no distinction between the OS, utilities, and applications. Everything is an object. A generic architecture for such an OOOS might look
like the figure
.
Objects are bundles of data with associated code that can act on the data. Anything from a business letter to the word processor that edits it can
be structured like this. Program execution occurs when objects exchange messages, causing the kernel to execute their code. The kernel provides such low-level hardware-dependent services as memory allocation and protection, task scheduling, and communication (both process-to-process and remote). The kernel of an OOOS should be multitasking so that many objects can execute simultaneously. It should support automatic garbage collection of dead objects to avoid memory leaks.
An object manager uses kernel services to dynamically create and destroy transient objects and to preserve objects that will be needed in the future (e.g., user documents) in the persistent object store, a repository of objects available to all applications. When a program invokes an object's unique object identifier (OID), the object manager fetches it from the store into RAM.
In a fully distributed OOOS, an ORB translates requests for OIDs into network messages that find objects and transparently relocates them onto the local s
ystem. ORBs maintain indexes of various object attributes, so they're closer to a database manager than a conventional file system. An OOOS will update objects using transaction-based semantics, with commit and rollback so that any action can be undone. Remote communication will operate on a fault-tolerant store-and-forward basis, transmitting data when a link can be established and hiding delays from the user.
OOOS support for inheritance -- creating new objects by modifying old ones -- can save programmers from reinventing the wheel and users from wasting storage space. For the designers of OOOSes, however, inheritance is a headache. Child objects frequently execute code belonging to their parent, but that parent may live elsewhere on the network.The most difficult technical challenge for an OOOS is to avoid massive and unpredictable network overload due to tangled inheritance webs. The solution may lie in message-optimization schemes that group interdependent objects close to one another, dynamically
migrating them where necessary.
Program objects under an OOOS will be finer-grained. A word processor would not be a single object, but a spelling checker or a search engine might be. The same spelling-checker object would check reports, presentations, or spreadsheets.
Real OOOS
The most pure OOOSes thus far are on personal digital assistants (PDAs), where engineers started from scratch with little legacy code. RAM-based persistent object storage (eliminating battery-powered rotating magnetic storage media -- and the conventional file system) is a feature of Apple's Newton and General Magic's Magic Cap. The code reuse under a properly designed inheritance hierarchy reduces the size of software -- a major consideration for PDA vendors when everything has to fit into 4 MB of ROM.
On the desktop, going to a full OOOS means making compromises to preserve legacy code and data, especially over the file system. Because all our existing data is in conventional files on conv
entional magnetic media, it has made commercial sense to continue supporting these rather than taking the radical step to a persistent object store.
For example, NextStep, the nearest thing to an OOOS in widespread use, is built on the Mach microkernel and employs a conventional Unix file system. However, the rest of the superstructure of NextStep is a hierarchy of Objective-C objects, fully available to the applications programmer.
IBM's OS/2 Warp is object-oriented to a much shallower degree. The Workplace Shell user interface (UI) is a programmer-accessible object hierarchy, but the lower levels of the OS are quite conventional.
In 1992, IBM, Apple, and Hewlett-Packard set up Taligent to develop a new OOOS from the four years of research Apple had put into Pink. Last May, Taligent announced it had abandoned producing a whole OS and would instead release a cross-platform object-oriented
framework
(containing prefabricated application parts) called CommonPoint. In July, Taligent sh
ipped CommonPoint source code to its sponsors to start porting to their own OSes (IBM's AIX and OS/2, Apple's Copland, and HP's HP-UX; versions for Windows 95 and NT will follow).
CommonPoint contains 100 such frameworks (including complete working and extensible text and graphics editors and presentation and communications programs), built from thousands of object classes. Taligent also has an interactive, drag-and-drop GUI building tool called cpConstructor and plans for a highly sophisticated development environment.
CommonPoint may score over OLE 2.0/Visual Basic in its persistent object store (built on the native OS file system), so that applications objects remain alive at run time rather than being frozen at compile time: Programmers maintaining a delivered application can extend it using inheritance. On the downside, CommonPoint is very expensive and very, very large.
It's the long wait for Taligent that has caused a widespread feeling that object technology has failed to catch on. T
he fact is, OOOSes are just around the corner.
Isn't this where we came in?
illustration_link (8 Kbytes)
In a pure object-oriented OS (OOOS), everything above the kernel is a replaceable object, and files are abandoned in favor of persistent objects that are transparently moved between memory and mass storage.
Dick Pountain is a BYTE contributing editor based in London. You can reach him on the Internet or BIX at
dickp@bix.com
.
OO Meets OS
