Active GUI element

Static GUI element

Code

WPS object

File/Path

Command line

Entry-field content

[Key combination]

more

(with help from Bart van Leeuwen, Adrian Gschwend, and Bob St.John)

A common refrain from OS/2 users is, "At this moment, things don't look good for our beloved operating system."

They don't? you say. We have the eComStation 1.2 media refresh, there's an alpha for eComStation 2.0, there are things on the way like ACPI and bootable JFS. . . eComStation is easily the best OS/2 ever, and still getting better!

Even so, there remain issues we can't ignore. The main issue is probably this: near the end of December 2005, IBM stops selling OS/2, and at the end of next year Big Blue will stop supporting it. To be fair: how much truly new stuff has come from IBM for OS/2 lately? There are updates to some device drivers, and the kernel is being maintained. But that too will stop.

Most likely, IBM can never release the source code of OS/2. So we are stuck with limitations of the current code. A few examples:

• Real Unicode (something different than code pages, really important to the Far East user, a large growing market) isn't available.
• Exchange of data/information with other people who use different systems or platforms currently is quite difficult, and it seems as though it is becoming more difficult all the time.
• There is no real support for multiple users on the same system. And if this feature becomes available, there is no real security to separate users and roles.
• Known problems, such as those with the WPS, will never be solved.
• A maximum memory capacity of 4 GiB. At this time, this seems to be enough, but Moore's law indicates a doubling every one and a half year. We will hit this limitation. Not if, but when.
• 64 bit processors. The kernel has been changed so it can run (in 32 bit mode) on current 64 bit processors. However, there is no guarantee that this will continue to run on future processors.
• Generally, hardware support is an important issue. We cannot simply continue use our current hardware indefinitely.

In other words: at the moment things are quite good but the future is uncertain. Which is why we need to be spending time thinking of how we can address these issues.

Some people have been thinking about this for some time now, including people who are closely involved with the development of the current eComStation product and other software. At Warpstock Europe 2005, Adrian Gschwend from netlabs.org presented the ideas under the name "Project Voyager."

These are some of the concepts:

• Try to keep those things of OS/2 that we love so much: the WPS, the object oriented desktop, REXX, etc.
• Don't spend time and energy in creating things that are available to us from other sources; don't start developing a new kernel. (Choose an existing kernel, like one from Apple, Linux, BeOS, etc.)
• Use open standards that are available on other platforms, to maximize the possibilities to exchange. Some examples are UTF-8, Cairo, GTK+, qt.
• Create an environment to which current software developers can compile their software. High level software should be easily portable. For low level software, recreating the OS/2 API is being considered. This might even lead to a level of binary compatibility.

These ideas have been discussed with Serenity Systems (Bob St.John) and the product manager of the current eComStation line (Bart van Leeuwen). The current plan has Adrian focusing on the new product while Bart focuses on the continuity of the current product line. Bob will oversee. This way, the current eComStation will be positioned to support current requirements while being consistent and compatible with the first version(s) of the new line.

Within the OS/2 community there is a lot of knowledge. For instance, with XWorkplace, a large part of the WPS has been rewritten. In fact, it was being rewritten until the author couldn't continue due to bugs, design issues, and lack of documentation of the current OS/2 implementation. We can even attract developers from outside of the OS/2 community, as the project is very tempting and unique. In fact, this strategy has already successfully motivated developers to work on Voyager and with the choice for open standards, we can use technologies and code currently available for other platforms.

Please note that all this is still in the planning phase. Lots of choices still have to be made, there isn't much built yet. It'll take at least about 3 years before something usable will be delivered by the project. Until then (and some time after the first complete version of Voyager), we have the current eComStation 1.2R and the upcoming eComStation 2.0 (and maybe even more versions). If you want to support project Voyager at this point, you can do a few things:

• Follow eComStation 1.2 and 2.0 (and next versions). This way, you'll fill the time until project Voyager reaches its targets. Moreover, part of the revenues of the current eComStation line will be used to fund the new developments.
• Sponsor netlabs.org through "sponsor units," available at Mensys.
• For developers: join the team that works on Voyager.
• For application developers: continue developing software for the current eCS while preparing for portability. There will be quite some time in which both lines of eCS are available to ease migration of your applications.

The ultimate goal of project Voyager is to deliver an eComStation which continues to support OS/2 technologies and OS/2 application software to the greatest extent possible. This way, eComStation remains the perfect way to transition from OS/2 into the future.