The main goal of the project is to port a recent version of OpenOffice to OpenVMS Alpha and ia64. To achieve this goal we decided to use the features first introduced in the OpenVMS versions for the DII COE project. This means the new features introduced in the CRTL (improved "standards" compatibility and UNIX style file paths) and the unix commands and utilities provided by the GNV kit. As a result, OpenOffice will only become available on OpenVMS versions supporting these new features.
We participate in field tests and provide as much feedback as we can on the new features in the CRTL and the GNV kit.
We will improve, add new features to some GNV tools and add new tools when needed.
We help others to add ODS-5 and UNIX style file path support to their ported applications.
We write how-to documents on how to port open source software to OpenVMS.
Status of the project
Porting OpenOffice is really hard, and not only because of the sheer amount of source files (100,000+). Even getting OpenOffice compiled on Solaris 9 took some serious effort! The hardest part is that you see so little progress on the outside. When you finally see the OpenOffice.org logo, you're 99.9% done.
Our first problem was getting the sources on an OpenVMS ODS-5 disk with all the filenames intact. There is, as far as we know, no tool, supporting ODS-5 filenames, to get source files from a CVS server so we downloaded a tar.gz file.
GNV gzip did not handle ODS-5 names properly, but that was a minor problem (a file named xxx^.tar.gz;1 would become xxx^.tar.;1 after gunzipping). We fixed this and our version of gzip is now part of the latest GNV kit.
GNV tar could not untar the OpenOffice tar file. We are porting POSIX.2 PAX to OpenVMS. With PAX you can read and write tar and cpio files. We use PAX to untar the OpenOffice sources. We will submit our version of PAX for a future release of the GNV kit.
We have a port of m4, a UNIX macro language interpreter, used by many open source build tools like automake, autoconf and libtool.
We are writing a document on how to port open source software to OpenVMS. Hopefully more people will participate in the writing of this document.
But this was just to get us started.
What part of OpenOffice did we really port:
We have a working version of dmake, the primary OpenOffice build tool, but we need to do some of this work again because of all the changes in OpenOffice 2.0 and OpenVMS 8.3.
What still needs to be done
Although we only have two people doing some programming work in their spare time, we have achieved quite a lot, but we have unfortunately very little to show for it. Partially this is because of the strange OpenOffice build environment. It is somewhat strange for UNIX people but completely strange for us OpenVMS people.
And then there are the new CRTL features and the feature switches. This took a while to understand.
And don't forget that, in the beginning, many of the GNV tools didn't quite work the way they should.
We still need:
An ODS-5 extended filename aware CVS client with UNIX style file path support, And preferably also a CVS server with these features.
Tools like automake, autoconf and libtool.
All the GNV tools still need to be tested for ODS-5 extended filename and UNIX style file path support. Tools like zip and bzip2 still need some work.
A tcsh shell. Hunter Goatley ported tcsh to OpenVMS using POSIX for OpenVMS a very long time ago, so, as far as we know, no ODS-5 extended filename support.
All the standard tools that are missing from the GNV kit and/or have an outdated version in the GNV kit.
Although the DEC compilers are most probably the best compilers on the market, a OpenVMS port of gcc 3.2.2 or better with ODS-5 extended filename and UNIX style file path support would really help our project.
More standard compliant functions in the CRTL, we desperately need fork and a proper working version of vfork and while we don't have those, we need good workarounds.