Porting ACE and TAO to a New OS Platform

Porting ACE, TAO, and CIAO to a New OS Platform

ACE, TAO, and CIAO have been ported to many OS platforms. Porting ACE, TAO, and CIAO to new platforms is fairly easy. The following document describes the step-by-step process to use when porting the various components and layers in ACE to a new OS platform. Once ACE is ported, it is straightforward to port TAO and CIAO, as well.

Before starting a port that you plan to contribute back to the ACE+TAO+CIAO open-source community, we recommend that you do the following:

Read and follow the programming style guidelines we use when writing ACE, TAO, and CIAO code, which will make it much easier to integrate and maintain your port in the source tree.
Contact Douglas C. Schmidt and let him know that you're planning to contribute a port, which will make it make easier to work out the logistics of when/how the port will be integrated.

Create a `config.h` Header File for the Target OS Platform

A config-*.h header file exists in $ACE_ROOT/ace for each platform to which ACE has been ported. This file contains the portability macros for each particular configuration of ACE. A complete description of the existent macros can be found in the $ACE_ROOT/ace/README file.

Currently, you must edit this file by hand to port it to new OS platforms, though on some platforms it's possible to use the ACE autoconf script. It's a good idea to use the config-*.h files for platforms with similar characteristics as examples.

Port the `ACE_OS` Namespace

The ACE_OS namespace encapsulates most of variation between the different OS implementations, e.g., UNIX, Win32, and various real-time operating systems. It is the core of the ACE OS abstraction layer. Most work required to port ACE to a new OS platform resides in this namespace. There are many examples of how ACE has been ported to other operating systems in the ACE_OS class in the $ACE_ROOT/ace/OS_NS_*.{h,inl,cpp} files.

Optional features in pthreads are covered by ACE_HAS_* and/or ACE_LACKS_* macros, which are described in the $ACE_ROOT/ace/README file. Particular platform features, such as DCE pthreads calls that end in _np, should be bracketed by platform defines rather than by inventing more ACE_HAS_* or ACE_LACKS_* definitions.

An important part of porting ACE to a new platform is to map the threading API correctly. Currently, ACE has support for the following thread APIs:

UNIX International (UI) Threads (ACE_HAS_STHREADS) - Solaris 2, UnixWare.
POSIX Pthreads (ACE_HAS_PTHREADS) - drafts 4 [DCE], 6 [FSU], 7 [AIX], as well as the final standard (also called draft 10) [MIT, Linux, and Solaris].
Win32 Threads (ACE_HAS_WTHREADS) - Windows NT, Windows '95/98, and Windows CE
VxWorks Tasks (ACE_VXWORKS) - VxWorks

If your OS platform does not support any of these threading packages, you must port the ACE_OS::thr_* functions.

Port the C++ Wrapper Facade Components

After porting the ACE_OS namespace, the next step is to port all of the ACE C++ wrapper facade components, such as sockets, threads, synchronization mechanisms. A full list of the categories and classes can be found in the $ACE_ROOT/ACE-categories file. It is easiest to concentrate on porting one category at the time. The ACE release contain a regression test suite in the $ACE_ROOT/tests/ directory. These tests can be used to validate the correctness of the various ACE C++ wrapper facades as they are ported.

Port the Higher-level Framework Components of ACE

Having ported (and tested) all the components of the ACE OS adaptation layer and C++ wrapper facades, you can proceed to port the higher level components of ACE, such as the Reactor, Service Configurator, Connector, Acceptor, and Streams frameworks. At this point, it should be relatively easy to port the rest of ACE because most of the platform-dependent code is localized in the lower layers of ACE.

Port TAO and CIAO

After porting and successfully testing all the ACE framework components, it should be straightforward to port and install TAO and install CIAO because the bulk of their platform-dependent code is localized in ACE. Typically, the only problems that arise when porting TAO and CIAO is bugs and limitations with C++ compilers.

C++ Features Required to Port ACE, TAO, and CIAO

ACE, TAO, and CIAO have been ported to most C++ compilers. The following is a list of which C++ features a compiler must support in order to compile ACE and TAO:

Templates -- The C++ compiler must support templates. However, it need not support template member functions and of the advanced concepts outlined in Modern C++ Design.
Multiple inheritance and dynamic binding -- The C++ compiler must support multiple inheritance and dynamic binding.
Namespaces -- ACE+TAO+CIAO utilizes C++ namespaces, so the C++ compiler must support them.
ANSI casts and RTTI -- ACE+TAO+CIAO uses the ANSI C++ casts, so the C++ compiler must support them, which implies support for RTTI.

The following is a list of which C++ features that ACE, TAO, CIAO can take advantage of if a compiler supports them:

Exceptions -- The ACE library itself is ``exception neutral,'' i.e., it does not catch or throw C++ exceptions. However, you can use exceptions in code that uses ACE including throwing exceptions inside call back methods, as long as you provide the code to handle it. TAO requires the use of C++ exceptions, ACE_HAS_EXCEPTIONS must be defined.
STL -- Unfortunately many of the platforms that ACE supports don't have an STL library. Moreover, different versions of STL behave differently. ACE therefore does not depends on STL and does not use it internally. If your target platform(s) support STL you should be able to use it with ACE, TAO, and CIAO without problems, though your C++ compiler may have problems with it (this is beyond the scope of ACE, however).
If you are considering STL, you might consider STLport, which is a port of the SGI STL to numerous platforms that ACE, TAO, and CIAO also support.

Back to the ACE documentation page.
Back to ACE Documentation Home.