www. O S N E W S .com
News Features Interviews
BlogContact Editorials

Introduction to OpenBinder and Interview with Dianne Hackborn
By Eugenia Loli on 2006-02-14 19:06:03
OpenBinder is the core technology that ex-Be engineers started at Be, Inc. as the "next generation BeOS", finished implementing at PalmSource as one of the key foundations of the Cobalt system, and is now being open-sourced running for Linux. Dianne Hackborn, a legendary engineer throughout the BeOS history and later a key engineer in the creation of PalmOS Cobalt, is describing OpenBinder below and then a mini-interview follows.

OpenBinder, Page 1/2

OpenBinder is a new approach to operating system design, in the same vein as a lot of other attempts at introducing a modern object oriented approach to operating system design. Usually, however, when this is done it is at the kernel level: creating an "object oriented kernel," which is significantly different than our current modern kernels. The Binder, in contrast, provides a rich object-oriented operating system environment that is designed to be hosted by today's traditional kernels.

An illustration of this can be see here where we show how you work with processes in the Binder, treating them as just another kind of Binder object. There are similar OO representations of shared memory, byte streams, files, etc. These all sit on top of traditional operating system services, for example when you do "new_process" the underlying OS calls (fork() and exec()) are used to create the process; however, the way the Binder presents these things to you provides a radically different, and hopefully richer, programming model. As an example, OpenBinder includes a traditional command line shell (called Binder Shell), that illustrates how using the Binder to implement such a core system service provides a much more powerful environment. At a high level, the Binder Shell can be compared to Microsoft's new shell.

The Binder is technology that was started at Be, as the foundation of a new set of graphics, user interface, and multimedia frameworks, for a next-generation operating system. When Palm acquired Be, all of this technology was ported to Palm's microkernel and used to create Cobalt. With the switch to Linux, it was then all ported to Linux, and OpenBinder is the result of work we did to get some of that technology open-sourced so that is available to others. (Unfortunately at this point the graphics, user interface, and multimedia frameworks, which were used to drive the development and design of the Binder, are not being open-sourced.)

Over the approx. 5 years of its life, the Binder has run on BeOS, Windows, the Cobalt kernel, and now Linux. The current OpenBinder distribution only runs under Linux, however it would not be hard to get it working again on the other kernels, and we have enough experience with it to be pretty confident that porting to other platforms should not be too hard. Also, for most of its life, the hardware target for the Binder (and everything built on top of it) was a 200 MHz ARM CPU, so it is relatively lightweight and already includes extensive optimization of the key code paths in the system.

1. Could you give us a real application example of Binder so our readers understand it better?

OpenBinder itself is not interesting to end users, but rather is a set of tools that other developers can use to implement rich operating system services and applications. An application-level example requires some higher-level piece of software implemented on top of it. There have been a number of such things implemented with the Binder, including a distributed display server and user-interface framework, componentized application model (like a document component model such as OpenDoc, but for putting together applications instead of documents), and a rich node-based multimedia framework. Unfortunately, these are not a part of OpenBinder at this point.

One example that is included with OpenBinder is called the Binder Shell. This implements a POSIX compatible shell (like bash and the Korn shell on Unix). It sits on top of the Binder framework, however, giving a much richer environment than you would get from a shell designed for traditional operating system services.

This page has a lot of detail on the shell, but here are some quick examples of the kinds of things it can do:

The shell sits on top of the Binder runtime, so all of its variables and data are dynamically typed via the Binder and it has access to the full OpenBinder component model. Because of this, the shell can easily instantiate any OpenBinder component and interact with it. As an example, here are some commands that instantiate an example component included with OpenBinder and call a method on it:

/$ s=$[new org.openbinder.samples.Service]
Result: sptr(0x80a0194 13SampleService)

/$ invoke $s Test
Result: int32_t(12 or 0xc)
In fact, the Binder Shell is just another VM for OpenBinder that lets you write Binder code in its particular language. When you write a script in the shell you are actually creating a Binder object, allowing you to do interesting things like write a function in the shell that gets invoked by another object in the system. For example, you can use standard POSIX shell syntax to write this function:
/$ function handleEntryCreated() {
	echo "Created: parent=" $1
	echo "Created: name=" $2
	echo "Created: entry=" $3
And then use the OpenBinder facilities to link yourself to the "/settings" directory (the link command takes advantage of a standard facility for connecting the output of one object to the input of another):
/$ n=$[inspect /settings org.openbinder.support.INode]
Result: sptr(0x8091dc4 8BCatalog)

/$ link $n $SELF @{EntryCreated->handleEntryCreated}
And now if someone changes the contents of that directory:
/$ echo >/settings/test "This is a test"
Your shell function will be invoked, resulting in the output:
Created: parent= SValue(sptr(0xb69063f4 8BCatalog))
Created: name= test
Created: entry= SValue(sptr(0x8081254 N18SDatumGeneratorInt12IndexedDatumE))
For a full-fledged example of writing a Binder component in shell, have a look here for the same test component we saw above but implemented entirely with BinderShell. (The component we used previously was implemented in C++ and can be found here).

Some examples of coding in C++ with OpenBinder can be seen here and OpenBinder includes a variety of high-level tools that make development much easier. For example, there is a built-in thread pool and a class called SHandler for accessing it that makes it very easy to do a number of common threading tasks (see here), a light-weight locking class with a sophisticated tool for detecting uses of it that can lead to deadlocks, reference counted objects with their own debugging tools for detecting and correcting leaked references (see here, and the obligatory string class, container classes, and other tools.

Of course, working with multiple processes is where you get the most out of OpenBinder, because like other distributed systems it takes care of all of the details of communicating between processes for you. For example, consider the first shell example we showed above of instantiating a sample component and then calling it. Here is C++ code that does the same thing, but runs the component in its own process:

sptr process = Context().NewProcess(
    SString("my empty process"));

sptr obj = Context().RemoteNew(
    SValue::String("org.openbinder.samples.Service"), process);

sptr srv = interface_cast(obj);
int32_t res = srv->Test();
With these few line of code, you have started a new process, found some code (that can be implemented in any language) by name and loaded it into the process, and performed an IPC from your process to execute that code and get a result back.

In addition, the object and its code will remain loaded for you only as long as you hold references on the object, and the process itself will be kept around only as long as it is needed, going away once all reference on it and its objects have been removed. In other words, if you were to put that code as-is into a function, it would not only do all of the starting and loading and calling, but correctly clean up everything for you as well when the function returns.

Table of contents

  1. OpenBinder, Page 1/2
  2. OpenBinder, Page 2/2

12  Comments - Printer friendly - Related stories

Tell a friend
Your full name:
Your email address:
Your friend's email:
Anti-spam measure:

News Features Interviews
BlogContact Editorials

WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?