Voyager

IBM Redbooks

 * SG24-4630-00 OS/2 Warp (PowerPC Edition) A First Look
 * SG24-4639-00 OS/2 Warp (PowerPC Edition) Graphical Subsystem

We do have the first one digitaly, but not the second one. In case anyone finds that, let us know.

Darwin Documentation
There is plenty of documentation available about Darwin, a good start is Kernel Programming, which gives a nice overview about the design of the kernel.

Technologies to study

 * glitz - OpenGL interface for Cairo, so one could run Cairo directly on OpenGL, see Xegl for a diagram.
 * Glitz: Hardware Accelerated Image Compositing Using OpenGL and as PDF
 * The State of Linux Graphics, comments and more comments.
 * GNUstep.org

Design Decissions
Creating a binary compatible OS/2 clone may be tempting but is not strictly necessary. Important is the user experience. Which toolkit should be used for primary development?

2D API

 * See Cairo above. Cairo has a PDF-like engine which seems to be inspired by Quartz of MacOS X.
 * Cairo runs on almost everything, including OS/2 and X but also directly on OpenGL hardware with Glitz. So one could use it as a complete GPI replacement without the need of X one day.

Toolkits

 * GTK+
 * GnuStep (look at Apples programs to see what's possible. Yes I know Apple uses Cocoa not Gnustep)
 * other?

SOM
Dropping SOM for something better? Creating a poor mans SOM kernel isn't too difficult.

Backward Compatibility
The question about backward compatibility is indeed a good one, it's risky to break with the current OS/2 API for religious reasons but one should have a look at that more from a technical point of view. The OS/2 API is not really modern anymore, programming directly on PM is much more work than using a modern toolkit like GTK+.

At the moment it's unfortunately unlikely that PM and WPS source get released by IBM.

Options:


 * implement parts of PM and GPI on top of the new 2D API and try to integrate it with the toolkit choosen (same look & feel, clipboard support, D&D, etc. That's a lot of work, the question is if this is really necessary. We would have to do the same for supporting other toolkits like qt (which is a requirement).
 * Use a VM and run OS/2 or eCS inside the VM. There are very promising opensource VMs like
 * XEN
 * QEMU

XEN seems to be the most promising one at the moment because it will support dual core CPUs in the future so one can run the guest OS on a separate CPU core. So far one had to alter the guest OS in sourcecode but that changes at the moment because they integrate parts of QEMU sourcecode inside XEN to emulate those parts (memory allocation and such stuff).

Questions

 * one good thing about OS/2 are the fast interactions when you click somewhere, like opening a folder or getting the focus on a window. Why is that like this? We should try to keep that stuff fast.