Voyager FAQ

From NikiWiki
Jump to: navigation, search

Voyager Frequently Asked Questions

Assembled by:

  • Adrian Gschwend, aka ktk
  • Cinc


  • OS/2: Everything is an object [tm]
  • MacOS X: Not everything is an object
  • Gnome: We once tried objects
  • KDE: We claim there are objects
  • Windows: There is no object


What is Voyager?

Voyager is the codename for the idea of having a replacement OS/2, or rather of the OS/2 Workplace Shell (WPS) on top of modern technology. This idea is the result of thinking a lot about what we can do in the future as current OS/2 and eComStation users. As many information in the Internet, this FAQ does not resemble the most recent status of the project for various reasons described later. But we still try to give you an impression of what we try to do with this project.

Before you continue you should probably consult:

Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must. Take it or leave it, it's our choice and we have our reasons.

How is this related to OS/2 and eCS?

A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the WPS, the Workplace Shell of OS/2, the multimedia subsystem (like IO procedures) and other areas which make OS/2 unique. The WPS has still unique concepts that are not implemented in any of the free and well-known desktops like Gnome or KDE. Our goal is to get the "WPS and OS/2 feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.

One of the main concerns of current OS/2 and eCS users is good backward compatibility. This is addressed below.

How is this related to MacOS X?

While explaining the idea of Voyager to people we often get the feedback, that this sounds a lot like MacOS X. Indeed there are concepts that are used in MacOS X as well.

  • The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called Taligent in the 90s which worked on an object oriented OS. The project was canceled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by NeXT which also has some ideas in common with OS/2s WPS.
  • MacOS X provides a powerful 2D engine called Quartz Extreme, we think this is the way to go today and Voyager has planned something like this utilizing Cairo as the 2D engine.

Unfortunately Apple didn't push the object orientation far enough in MacOS X. Not everything is an object as with the WPS, thus things that should (in our opinion) simply work, do not. As an example try to drag & drop an Address Book entry to the trash can. The entry itself is not a normal desktop object and thus can't be dropped to the trashcan. Also Objective C used by Apple does have some nice features but the object model of OS/2 (SOM) is still much further in terms of binary compatibility for example.

Is Voyager yet another Linux distribution?

No! Voyager is more than just repackaged Linux stuff with a pretty desktop (in fact it is more likely BSD stuff...). We will kill some sacred cows of the *nix camp like X as the graphics foundation or so called choice. You won't have ten editors for your config files, you won't have several window managers but one, you won't have a dozen file systems to choose from but only one or two. You get the picture... Since there's no decision for the kernel yet the rumors Voyager would use the Linux kernel are just - rumors. Voyager won't require you do recompile your kernel every few weeks or hunt down package dependency when installing new apps by providing a standard set of base libs.

I heard Voyager uses the Linux kernel

Read the answer to the previous question! For your convenience I highlighted the sentence which may interest you.

I type this very slowly so every OS/2 zealot going berserk may understand it: There is no decision about which kernel to use, yet. There's no decision about using the Linux kernel, there's not even a discussion about using the Linux kernel. Whenever somebody is telling you Voyager is using the Linux kernel just ignore that.

Will stop providing software for OS/2 and eCS now?

Definitely not! We will continue to provide essential software for OS/2 the next years. Voyager is in our opinion a great option for the future but we know very well that it will take some time until you can use that as full replacement for what you use now.

The best choice you can do at the moment is to work with eComStation, version 2 of eCS will provide some essential enhancements, many of the ideas are planned for Voyager as well. So one could say that Voyager could become something like eComStation 3.0 once.

How can I support Voyager?

There are several possibilities:

  • We definitely need skilled developers. We have a wide range of tasks available, please consult the Voyager page to get an impression and join the mailing list if you can contribute in some form.
  • Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfully motivated developers outside of the OS/2 and eCS community. This is essential for this project.
  • Buy eComStation. is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
  • Buy sponsoring units in the Mensys shop, we get 100% of the amount you donate there!
  • Present Voyager at your local user group. We need to spread the word to motivate people to contribute in any form.
  • Help out with the documentation of Voyager


Will Voyager support my OS/2 and eCS applications?

That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:

  • use a virtual machine like VirtualBox to run OS/2 or eCS in there. Will definitely work but is not a soft migration
  • implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
    • osFree has something in mind, see here as well.
    • There is a project at Sourceforge which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
  • implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailing list. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.

Another possiblity might come up with the design of Voyager, at the moment the most likely Glitz backend will be Xorg OpenGL drivers, so we would get drivers from the HW-vendors. This opens a new interesting approach for backward compatibility, that would involve the following steps:

  • compile Xorg on OS/2 with Innotek LIBC
  • get the binary only drivers to work (should work somehow in theory)
  • compile Glitz using Xorg backend
  • recompile GTK2 & all libraries used with Innotek LIBC
  • write a GRADD driver that renders using OpenGL, which means it would render into the OpenGL driver of Xorg. Like this it should even be possible to have a windowed PM in Glitz.

The benefit would be that we would also get HW acceleration in the current OS/2 or eCS.

In short one can say that binary compatibility is technically possible up to a certain point at least. One can debate about if this is useful or not.

Why something new? There is Gnome, KDE...

If you think KDE, GNOME... fit your needs , that's fine, just move on because you have found a solution for your personal computing needs. The people involved with Voyager so far don't think desktops other than the WPS which are available today fit their needs. Different people, different preferences.

Or to quote Larry Wall: "There's More Than One Way to Do It".

Why not X?

Short answer

Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.

And, we don't like X. Period. And finally we are not the only ones realizing that.

Long answer

We talk about X in terms of Xlib here, a library which was designed about 20 years ago when networks were slow, terminals common and processors did all the GFX (rendering) work. Now we have fast networks, fast computers, some graphic cards cost more than the CPU and remote access can be done with modern protocols like RDP or NX.

Since Apple started introducing eye candies in MacOS X everyone wants fancy 3D effects on his desktop too, no matter how useless they actually are. So one needs to get direct access to the hardware in X too, a concept that got introduced in form of the Direct Rendering Interface (DRI) mainly for 3D games. New desktop extensions like Xgl or Aiglx are using such techniques as well to get direct access to the hardware, without messing around with Xlib.

The two most popular toolkits GTK and Qt started moving their rendering to new engines as well like Cairo or Arthur. Depending on the backend of those rendering engines they also bypass Xlib and thus don't need it anymore except for things like window and input handling. Our point of view is that it would make more sense to replace those parts (window & input handling and other missing stuff) by a window manager on top of those rendering engines like Cairo instead. There was a prototype of this idea presented at Developers Workshop 2006, the project is called Neptune. Note that we don't necessarily will do it like this, if something better comes up, we will save us the work for sure.

There are people working on alternatives for Xlib as we know it right now. One of them is XCB, a project at This project can solve some of the problems we have with Xlib nowadays but it doesn't kill it completely.

This project is too big, you will fail

Maybe. But honestly without trying you won't know...


Under what license is Voyager released?

The source is dual licensed. It is covered by the CDDL and the LGPL.

Where can I download sourcecode?

The source can be found in a subversion tree on Trac provides a web interface for browsing. Currently you find the following.

Information how to download the source will follow. Note that some repositories are not available to the public right now because we want to design the prototypes on our own.

Should I still work on OS/2 and eCS applications?

Sure! OS/2 and eCS will be around for a very long time and Voyager will need quite some time to be mature enough to be usable. But if you intend to support the Voyager approach any time you should try to code in a portable way. Instead of using the OS/2-API use a portable runtime instead e.g. GLib, NPL or APL. Consider using a cross platform toolkit for the UI like DynamicWindows, GTK, XUL. Use only standard WPS methods without PM-specific tricks.

If you don't like the Voyager approach anyway, why do you ask in the first place ;)?

Whats next with Voyager - where are we?

Ask the oracle :-)

We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with and other software projects is that release plans never work as announced :)