<!-- $Id$ -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="Microsoft Word 97">
<META NAME="Template" CONTENT="C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\html
.dot">
<META NAME="GENERATOR" CONTENT="Mozilla/4.05 [en] (Win95; I) [Netscape]">
<TITLE>Porting ACE and TAO to a New OS Platform</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#FF0000">
<HR><P>
<H3>Porting ACE and TAO to a New OS Platform</H3><P>
The <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A>
framework and the <A
HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</A> ORB have been
ported to <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE-versions-i.html">many OS
platforms</A>. Porting ACE and TAO to new platforms is fairly easy.
The following document describes the step-by-step process to use when
porting the various <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">components
and layers</A> in ACE to a new OS platform. Once ACE is ported, it is
straightforward to port TAO, as well.<P>
<hr align=left width="50%"><P>
<H4>Create a <CODE>config.h</CODE> Header File for the Target OS Platform</H4>
A <CODE>config-*.h</CODE> header file exists in <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/">$ACE_ROOT/ace</A>
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 <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/README">$ACE_ROOT/ace/README</A>
file. <P>
Currently, you must edit this file by hand to port it to new OS
platforms. It's a good idea to use the <CODE>config-*.h</CODE> files
for platforms with similar characteristics as examples. Ultimately,
we plan to <A HREF="http://www.cs.wustl.edu/~othman/aceconf">auto
configure</A> these files. <P>
<hr align=left width="50%"><P>
<H4>Port the <CODE>ACE_OS</CODE> Class</H4>
The <CODE>ACE_OS</CODE> class encapsulates most of variation between
the different OS implementations, <EM>e.g.</EM>, UNIX, Win32, and
various real-time operating systems. It is the core class of the ACE
OS abstraction layer. Most work required to port ACE to a new OS
platform resides in this class. There are <EM>many</EM> examples of
how ACE has been ported to other operating systems in the
<CODE>ACE_OS</CODE> class in the
<CODE>$ACE_ROOT/ace/OS.{h,i,cpp}</CODE> files. <P>
Optional features in pthreads are covered by <CODE>ACE_HAS_*</CODE>
and/or <CODE>ACE_LACKS_*</CODE> macros, which are described in the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/README">$ACE_ROOT/ace/README</A>
file. Particular platform features, such as DCE pthreads calls that
end in <CODE>_np</CODE>, should be bracketed by platform defines
rather than by inventing more <CODE>ACE_HAS_*</CODE> or
<CODE>ACE_LACKS_*</CODE> definitions. <P>
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: <P>
<UL>
<LI> <B>UNIX International (UI) Threads</B>
(<CODE>ACE_HAS_STHREADS</CODE>) - Solaris 2, UnixWare. <P>
<LI> <B>POSIX Pthreads</B> (<CODE>ACE_HAS_PTHREADS</CODE>) - drafts 4
[DCE], 6 [FSU], 7 [AIX], as well as the final standard (also
called draft 10) [MIT, Linux, and Solaris]. <P>
<LI> <B>Win32 Threads</B> (<CODE>ACE_HAS_WTHREADS</CODE>) - Windows
NT, Windows '95/98, and Windows CE <P>
<LI> <B>VxWorks Tasks</B> (<CODE>VXWORKS</CODE>) - VxWorks <P>
</UL>
If your OS platform does not support any of these threading packages,
you must port the <CODE>ACE_OS::thr_*</CODE> functions. <P>
<hr align=left width="50%"><P>
<H4>Port the C++ Wrapper Components</H4>
After porting the <CODE>ACE_OS</CODE> class, the next step is to port
all of the ACE C++ wrapper components, such as sockets, threads,
synchronization mechanisms. A full list of the categories and classes
can be found in the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ACE-categories">$ACE_ROOT/ACE-categories</a>
file. It is easiest to concentrate on porting one category at the
time. The ACE release contain a <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/tests/README">one-button
test suite</A> in the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/tests/">$ACE_ROOT/tests/</A>
directory. These tests can be used to validate the correctness of the
various ACE C++ wrappers as they are ported. <P>
<hr align=left width="50%"><P>
<H4>Port the Higher-level Framework Components of ACE</H4>
Having ported (and tested) all the components of the ACE OS adaptation
layer and C++ wrappers, 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. <P>
<hr align=left width="50%"><P>
<H4>Port TAO</H4>
After porting and successfully testing all the ACE framework
components, it also should be relatively easy to port and <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/TAO-INSTALL.html">install</A>
TAO because all of its platform-dependent code is localized in ACE.
Typically, the only problems that arise when porting TAO is bugs with
C++ compilers. <P>
<HR><P>
<H3>C++ Features Required to Port ACE and TAO</H3>
ACE and TAO 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:
<UL>
<LI> <B>Templates</B> -- The C++ compiler must support templates.
However, it need not support template member functions nor must it
support template traits. <P>
<LI> <B>Multiple inheritance and dynamic binding</B> -- The C++
compiler must support multiple inheritance and dynamic
binding. <P>
</UL>
The following is a list of which C++ features that ACE and TAO can
take advantage of if a compiler supports them:
<UL>
<LI> <B>Exceptions</B> -- The ACE library itself is ``exception
neutral,'' <EM>i.e.,</EM> 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 can be configured to use C++ exceptions if ACE supports them,
<EM>i.e.</EM>, if <CODE>ACE_HAS_EXCEPTIONS</CODE> is defined. <P>
<LI> <B>RTTI and ANSI casts</B> -- If the OS platform supports RTTI
and the new ANSI
C++ casts, <EM>i.e.</EM>, <CODE>ACE_HAS_ANSI_CASTS</CODE> is
enabled, then the various <CODE>ACE_*_cast</CODE> macros will
utilize these casts. Otherwise, the macros will default to
"C-style" casts. <P>
<LI> <B>Namespaces</B> -- ACE does not utilize namespaces. However,
TAO will automatically take advantage of namespaces if the C++
compiler supports them, <EM>i.e.</EM>, if
<CODE>ACE_HAS_BROKEN_NAMESPACES</CODE> is <EM>not</EM> enabled. <P>
<LI> <B>STL</B> -- Unfortunately many of the platforms that ACE
supports don't have an STL library. Moreover, different versions
of STL behave differently. Therefore, ACE 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 and TAO without problems, though your C++
compiler may have problems with it (this is beyond the scope
of ACE, however). <P>
If you are considering STL, you might consider
<A HREF="http://www.stlport.org/">STLport</a>,
which is a port of the SGI STL to numerous platforms that ACE
and TAO also support. <P>
</UL>
<P><HR><P>
Back to the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE-documentation.html">ACE
documentation</A> page.<BR>
Back to <A HREF="index.html">ACE Documentation Home</A>.
<!--#include virtual="/~schmidt/cgi-sig.html" -->
</BODY>
</HTML>