summaryrefslogtreecommitdiff
path: root/ACE/docs
diff options
context:
space:
mode:
Diffstat (limited to 'ACE/docs')
-rw-r--r--ACE/docs/ACE-FMM.html283
-rw-r--r--ACE/docs/ACE-SSL.html45
-rw-r--r--ACE/docs/ACE-bug-process.html176
-rw-r--r--ACE/docs/ACE-categories.html753
-rw-r--r--ACE/docs/ACE-configuration.txt180
-rw-r--r--ACE/docs/ACE-development-process.html181
-rw-r--r--ACE/docs/ACE-guidelines.html1328
-rw-r--r--ACE/docs/ACE-lessons.html270
-rw-r--r--ACE/docs/ACE-porting.html198
-rw-r--r--ACE/docs/ACE-subsets.html196
-rw-r--r--ACE/docs/CE-status.txt51
-rw-r--r--ACE/docs/CVS.html889
-rw-r--r--ACE/docs/README.tutorials7
-rw-r--r--ACE/docs/Symbol_Versioning.html230
-rw-r--r--ACE/docs/ace_guidelines.vsmacrosbin0 -> 65536 bytes
-rw-r--r--ACE/docs/exceptions.html655
-rw-r--r--ACE/docs/index.html101
-rw-r--r--ACE/docs/msvc_notes.txt132
-rw-r--r--ACE/docs/run_test.txt172
-rw-r--r--ACE/docs/svn/config102
-rw-r--r--ACE/docs/svn/svn-prefs.reg56
-rw-r--r--ACE/docs/usage-bugzilla.html102
-rw-r--r--ACE/docs/wchar.txt128
23 files changed, 6235 insertions, 0 deletions
diff --git a/ACE/docs/ACE-FMM.html b/ACE/docs/ACE-FMM.html
new file mode 100644
index 00000000000..0430b7b9a7d
--- /dev/null
+++ b/ACE/docs/ACE-FMM.html
@@ -0,0 +1,283 @@
+<!-- $Id$ -->
+
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+ <head>
+ <title>ACE FMM</title>
+ </head>
+
+ <body bgcolor=#ffffff>
+<center>
+<font face=helvetica size=5>ACE Frequently Made Mistakes</font>
+
+<br>
+<br>
+<table border=0 cellpadding=3 cellspacing=1 width=550>
+
+<tr>
+<td align=right valign=top>
+ <b>symptom</b>
+</td>
+<td align=left valign=top>
+ ACE_Task::getq() returns the error
+ <b>resource temporarily unavailable</b>
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>probable cause</b>
+</td>
+<td align=left valign=top>
+ Your Task is a subclass of ACE_Task&lt;ACE_NULL_SYNCH&gt; and
+ you are using it in a multithreaded program.
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>solution</b>
+</td>
+<td align=left valign=top>
+ Try using ACE_Task&lt;ACE_MT_SYNCH&gt;
+ instead so that the associated Message_Queue
+ is configured for access by multiple threads.
+</td>
+<tr><td colspan=2><hr noshade></td></tr>
+
+<tr>
+<td align=right valign=top>
+ <b>symptom</b>
+</td>
+<td align=left valign=top>
+ ACE_Task::wait() throws an assert violation
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>probable cause</b>
+</td>
+<td align=left valign=top>
+ When you activate()d your Task, you specified
+ THR_DETACHED, which causes wait() to be unable to perform what you
+ want it to.
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>solution</b>
+</td>
+<td align=left valign=top>
+ Make sure you specify the flag THR_JOINABLE when activating
+ your ACE_Task object.
+</td>
+<tr><td colspan=2><hr noshade></td></tr>
+
+
+
+<tr>
+<td align=right valign=top>
+ <b>symptom</b>
+</td>
+<td align=left valign=top>
+ Apparent race conditions when spawning threads (or activating Tasks)
+ from within a constructor.
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>probable cause</b>
+</td>
+<td align=left valign=top>
+ You are not guaranteed to have a valid <b>this</b> pointer
+ until the constructor has exited. Threads spawned from
+ a constructor are free to run
+ immediately, and may attempt to use an invalid <b>this</b> pointer.
+
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>solution</b>
+</td>
+<td align=left valign=top>
+ Move your Task activations and other thread-spawning activites
+ <b>out</b> of the constructor.
+</td>
+<tr><td colspan=2><hr noshade></td></tr>
+
+
+
+<tr>
+<td align=right valign=top>
+ <b>symptom</b>
+</td>
+<td align=left valign=top>
+ Compiler issues warnings/erros regarding using too few template
+ arguments, such as "'ACE_Svc_Handler' : too few template arguments".
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>probable cause</b>
+</td>
+<td align=left valign=top>
+ Instead of using the appropriate macro, you supplied an actual class
+ name as a parameter. This will fail depending upon platform and compiler,
+ due to the way templates are handled.
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>solution</b>
+</td>
+<td align=left valign=top>
+ Instead of instantiating a template class like <b>ACE_Svc_Handler&lt;<u>ACE_SOCK_Stream</u>, ACE_NULL_SYNCH&gt;</b>, use the form of <b>ACE_Svc_Handler&lt;<u>ACE_SOCK_STREAM</u>, ACE_NULL_SYNCH&gt;</b> which circumvents the platform peculiarities by using the macro. This also applies to some other template classes.
+</td>
+<tr><td colspan=2><hr noshade></td></tr>
+
+
+
+<tr>
+<td align=right valign=top>
+ <b>symptom</b>
+</td>
+<td align=left valign=top>
+ Unable to compare ACE_thread_t variables (such as ACE_Thread::self())
+ using operator== ().
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>probable cause</b>
+</td>
+<td align=left valign=top>
+ On some platforms, thread ids are numeric, and on some, they aren't. On some
+ implementations, simple a == b comparisons
+ are legal and sane. Some are not.
+
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>solution</b>
+</td>
+<td align=left valign=top>
+ Use the <b>ACE_OS::thr_equal()</b> function to reliably compare thread
+ ids, regardless of platform.
+</td>
+<tr><td colspan=2><hr noshade></td></tr>
+
+<tr>
+<td align=right valign=top>
+ <b>symptom</b>
+</td>
+<td align=left valign=top>
+ ACE_Reactor::run_event_loop() does not seem to function correctly
+ for a Reactor created in your application.
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>probable cause</b>
+</td>
+<td align=left valign=top>
+ You have not set the ACE_Reactor::instance() to refer to your new reactor.
+ run_event_loop only functions on the reactor currently installed as the
+ global Singleton.
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>solution</b>
+</td>
+<td align=left valign=top>
+ Use the <b>ACE_Reactor::instance(ACE_Reactor *,
+ int delete_reactor = 0)</b> static method to install your reactor as the global
+ Singleton before calling run_event_loop().
+</td>
+<tr><td colspan=2><hr noshade></td></tr>
+
+
+
+
+
+<tr>
+<td align=right valign=top>
+ <b>symptom</b>
+</td>
+<td align=left valign=top>
+Infinite recursion when you invoke ACE_Reactor::remove_handler()
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>probable cause</b>
+</td>
+<td align=left valign=top>
+You are invoking remove_handler() from within handle_close() (or a
+method invoked by handle_close()) but you have not specified the
+DONT_CALL flag.
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>solution</b>
+</td>
+<td align=left valign=top>
+Be sure to <b>OR</b> in the DONT_CALL flag in this situation.<br>
+e.g. --<br>
+<ul><pre>
+int MyHandler::handle_close (ACE_HANDLE handle,
+ ACE_Reactor_Mask close_mask)
+{
+ ...
+ my_reactor_-&gt;remove_handler( this,
+ ACE_Event_Handler::READ_MASK |
+ ACE_Event_Handler::DONT_CALL );
+ ...
+ return 0;
+}
+</pre></ul>
+
+</td>
+<tr><td colspan=2><hr noshade></td></tr>
+
+<!--
+
+<tr>
+<td align=right valign=top>
+ <b>symptom</b>
+</td>
+<td align=left valign=top>
+
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>probable cause</b>
+</td>
+<td align=left valign=top>
+
+</td>
+</tr>
+<tr>
+<td align=right valign=top>
+ <b>solution</b>
+</td>
+<td align=left valign=top>
+
+</td>
+<tr><td colspan=2><hr noshade></td></tr>
+
+-->
+<tr>
+<td align=center colspan=2>
+<font size=2>maintained by <a href="mailto:bob@werken.com">bob@werken.com</a></font>
+</td>
+</tr>
+
+</table>
+</center>
+Back to <A HREF="index.html">ACE Documentation Home</A>.
+</body>
+</html>
+
diff --git a/ACE/docs/ACE-SSL.html b/ACE/docs/ACE-SSL.html
new file mode 100644
index 00000000000..b3ba856bbc5
--- /dev/null
+++ b/ACE/docs/ACE-SSL.html
@@ -0,0 +1,45 @@
+<HTML>
+<!-- $Id$ -->
+<Title>ACE+SSL</TITLE>
+
+ <BODY text = "#000000"
+ link="#000fff"
+ vlink="#ff0f0f"
+ bgcolor="#ffffff">
+
+ <HR><P>
+ <H3>What is ACE+SSL?</H3>
+ <p>ACE plus SSL is an addition to the core classes which allow the use
+ of the Secure Socket Layer with the ACE framework. The following
+ are the core classes conditionally compiled in when you run
+ <code>make ssl=1</code>:</p>
+ <ul>
+ <li>ACE_SSL contains the interface to the ssl library OpenSSL.
+ <li><code>ACE_SSL_SOCK_Stream</code> uses an interface and
+ behavior nearly identical to <code>ACE_SOCK_Stream</code>,
+ only with the additional ssl layer functionality.
+ <li><code>ACE_SSL_SOCK_Acceptor</code>/<code>Connector</code>
+ are again similar to their <code>ACE_SOCK</code> counterparts.
+ </ul>
+
+ <p>The SSL/TLS library we use is OpenSSL which is available at
+ <A HREF="http://www.openssl.org/">http://www.openssl.org/</A>.
+ This library must be installed in order to use ACE+SSL. We
+ cannot answer all of the questions you may have about OpenSSL,
+ but hopefully through using the ACE+SSL interface your questions
+ will be reduced.</p>
+
+ <H3>How do I get ACE+SSL?</H3>
+ <p>Due to the relaxation of export restrictions we have gained
+ permission to distribute ACE+SSL along with the normal ACE
+ distribution. It can be found in $ACE_ROOT/ace/SSL. An SSL
+ pluggable transport for can be found in
+ $ACE_ROOT/TAO/orbsvcs/orbsvcs/SSLIOP.
+
+
+ <HR><P>
+ Back to <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">
+ ACE</A> home page. <P>
+ <!--#include virtual="/~schmidt/cgi-sig.html" -->
+ </BODY>
+</HTML>
diff --git a/ACE/docs/ACE-bug-process.html b/ACE/docs/ACE-bug-process.html
new file mode 100644
index 00000000000..ec3699165ec
--- /dev/null
+++ b/ACE/docs/ACE-bug-process.html
@@ -0,0 +1,176 @@
+<!-- $Id$ -->
+
+<HTML>
+ <TITLE>ACE, TAO, and CIAO Bug Fixing Policies</TITLE>
+ <BODY text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff">
+
+<HR>
+<H3>ACE, TAO, and CIAO Bug Fixing Policies</H3>
+
+As <A HREF="http://www.dre.vanderbilt.edu/ACE/">ACE</A>, <A
+HREF="http://www.dre.vanderbilt.edu/TAO/">TAO</A>, and <A
+HREF="http://www.dre.vanderbilt.edu/CIAO/">CIAO</A> have grown in
+popularity the volume of mail on the <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">mailing
+lists</A> and USENET newsgroup <A
+HREF="news:comp.soft-sys.ace">comp.soft-sys.ace</A> has grown
+considerably. While this increase is healthy, and a natural
+consequence of the larger number of ACE, TAO, and CIAO users, it is
+straining the resources of the researchers in the <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE-members-i.html">DOC
+group</A> at <A
+HREF="http://www.cs.wustl.edu/~schmidt/doc-center.html">Washington
+University</A>, <A HREF="http://zen.uci.edu">UC Irvine</A> and <A
+HREF="http://www.dre.vanderbilt.edu">ISIS</A> to respond to all the
+traffic immediately. Prompt bug fixes from the DOC group also
+discourage the creation of a larger community of <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE-members.html">users</A> and
+<A
+HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.htlm">commercial
+support companies</A> who have deep knowledge of how ACE, TAO, and
+CIAO work and can help provide bug fixes and new features. <P>
+
+To ensure the continued growth and maturation of ACE, TAO, and CIAO,
+and to allow the user and vendor communities to evolve, please make it
+a point to abide by the following policies:
+
+<UL>
+
+<LI> All bug reports to the <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">mailing
+lists</A> should be submitted using the appropriate bug report form in
+<A HREF="../PROBLEM-REPORT-FORM">$ACE_ROOT/PROBLEM-REPORT-FORM</A>
+(for ACE), <A
+HREF="../TAO/PROBLEM-REPORT-FORM">$TAO_ROOT/PROBLEM-REPORT-FORM</A>
+(for TAO), <A
+HREF="../TAO/CIAO/PROBLEM-REPORT-FORM">$CIAO_ROOT/PROBLEM-REPORT-FORM</A>
+(for CIAO). Please use these forms since bug reports that are not
+submitted in this form are likely to fall through the cracks. Here is
+our policy for addressing these bug reports: <P>
+
+<OL>
+
+<LI> If a report is from someone <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE-sponsors.html">sponsoring</A>
+our work we will respond to it in a very timely manner. Please
+contact <A HREF="mailto:schmidt@cs.wustl.edu">me</A> if you'd like to
+become a sponsor. <P>
+
+<LI> If it's a bug report along with a fix we will try to apply this
+in a timely manner. In general, people who submit good bug reports
+with fixes tend to get much better help from the core DOC group team,
+irrespective of whether they are sponsors or not since they are
+helping our overall effort move ahead. <P>
+
+<LI> If it's a bug report that prevents ACE, TAO, or CIAO from working
+on a major platform used by ourselves or our sponsors we'll try to fix
+it as time permits. <P>
+
+</OL>
+
+<LI> You should also consider entering your bug report into our <A
+HREF="http://deuce.doc.wustl.edu/bugzilla/index.cgi">bug tracking
+database</A> so that it's archived for future processing. As usual,
+we try to address these bugs as time permits, but may not get to them
+for a while unless it affects our work or the work of our
+sponsors. <P>
+
+We encourage bug reports for those without support to be posted
+initially to the <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE users</A>
+(<A HREF="mailto:ace-users@cs.wustl.edu">ace-users@cs.wustl.edu</A>),
+<A HREF="http://www.cs.wustl.edu/~schmidt/TAO-mail.html">TAO users</A>
+(<A HREF="mailto:tao-users@cs.wustl.edu">tao-users@cs.wustl.edu</A>),
+and <A HREF="http://www.cs.wustl.edu/~schmidt/CIAO-mail.html">CIAO
+users</A> (<A
+HREF="mailto:ciao-users@cs.wustl.edu">ciao-users@cs.wustl.edu</A>)
+mailing lists, where the open-source user community may already have
+developed, or have an interest in developing, a solution. <P>
+
+<LI> While the core DOC group development team participates in this
+mailing list, we cannot response to all postings. Therefore, if you
+post something and don't get a reply, please do the following:<P>
+
+<UL>
+<LI>
+ Check to see whether your posting made it to the list, which you
+ can see by checking out the <A
+ HREF="http://groups.google.com/groups?q=comp.soft-sys.ace&ie=UTF-8&oe=UTF-8&hl=en">comp.soft-sys.ace</A> newsgroup to see if your posting is visible. <P>
+
+<LI> If it's not visible, please make sure you're
+ <A HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">subscribed
+to the mailing
+ list(s)</A> you sent the report to since we have a "members only" posting
+ requirement to minimize spam. <P>
+
+<LI> If it is visible and you haven't received a reply this probably means
+ that either no one knows the answer or no one has time to answer it.
+ As always, if you need more predictable help please contact one of
+ <A
+HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html">commercial
+support</a> companies for ACE+TAO.<P>
+
+</UL>
+
+<LI> If you find a problem with a version of TAO that was released by
+ <A HREF="http://www.theaceorb.com/">OCI</A> then please report it
+ to <A
+ HREF="mailto:taosupport@ociweb.com">taosupport@ociweb.com</A>
+ since their version of TAO is different from the DOC group's
+ version of TAO and thus they provide their own support. <P>
+
+<LI> If it's a general question about how to use ACE, TAO, or CIAO
+feature we'll try to respond as time permits, though we will also rely
+on the experience of the open-source user community to field these
+types of questions, as well. You should first check out the <A
+HREf="http://www.theaceorb.com/faq/">online FAQ</A> to see if your
+question has already been answered. If you require consulting support
+for ACE, TAO, or CIAO, please contact one of the companies that
+provides <A
+HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html">commercial
+support</A>.<P>
+
+</UL>
+
+Naturally, we encourage other ACE, TAO, and CIAO users to continue to
+help provide fixes and advice in response to postings on the mailing
+lists and newsgroup. If you have a patch that fixes a problem you've
+found with our software here's the process for submitting it:
+
+<OL>
+<LI> Use the latest contents of our CVS repository, i.e., what's available from <P>
+
+ <A HREF="http://cvs.doc.wustl.edu/">http://cvs.doc.wustl.edu/</A> <P>
+
+<LI> Create a ``unified diff'' and put this into Bugzilla at <P>
+
+ <A HREF="http://deuce.doc.wustl.edu/bugzilla/index.cgi">http://deuce.doc.wustl.edu/bugzilla/index.cgi</A> <P>
+
+ and send an email to the appropriate <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">mailing
+list(s)</A> and/or <A HREF="news:comp.soft-sys.ace">newsgroup</A>
+newsgroup summarizing what the problem was and you've done to fix the
+problem, i.e., use the <A HREF="../ChangeLog"</A>ChangeLog</A>
+format. <P>
+
+<LI> Ideally, you could also create (or augment) a test program that
+ validates your patch and integrate it into the <A
+HREF="../tests">ACE_ROOT/tests</A> directory. <P> </OL>
+
+Please be sensitive to the fact that the core <A
+HREF="http://www.dre.vanderbilt.edu/">DOC group</A> team is
+<EM>very</EM> busy, so we often don't have time to address problems
+reported by non-sponsors. If you'd like an immediate response, please
+contact <A HREF="mailto:schmidt@cs.wustl.edu">me</A> about becoming a
+sponsor or contact one of the companies that provides <A
+HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html">
+commercial support</A> for ACE, TAO, and CIAO. <P>
+
+<HR><P>
+Back to the <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A> page.<BR>
+Back to <A HREF="index.html">ACE Documentation Home</A>.
+
+<!--#include virtual="/~schmidt/cgi-sig.html" -->
+</BODY>
+</HTML>
diff --git a/ACE/docs/ACE-categories.html b/ACE/docs/ACE-categories.html
new file mode 100644
index 00000000000..2d6e46223a8
--- /dev/null
+++ b/ACE/docs/ACE-categories.html
@@ -0,0 +1,753 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+<!-- $Id$ -->
+<head>
+<title>ACE Class Categories</title>
+</head>
+<body>
+
+<BODY text = "#000000"
+link="#000fff"
+vlink="#ff0f0f"
+bgcolor="#ffffff">
+
+<HR><P>
+<h3><a href = "http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</a> Class Categories</h3>
+
+This document groups each file in <A
+HREF="../ace">$ACE_ROOT/ace</A>
+into its appropriate class category and provides a link to the C++
+source code and <A
+HREF="http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/">HTML
+versions</A> of the relevant manual pages</A>. <P>
+
+<b>[ACE]</b>
+<ul>
+<b>[Containers]</b>
+<ul>
+<li><a href = "../ace/Array.cpp">Array.cpp</a></li>
+<li><a href = "../ace/Array.h">Array.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Array.html">[doxygen]</a></b>
+<li><a href = "../ace/Array.inl">Array.inl</a></li>
+<li><a href = "../ace/Containers.cpp">Containers.cpp</a></li>
+<li><a href = "../ace/Containers.inl">Containers.inl</a></li>
+<li><a href = "../ace/Containers.h">Containers.h</a></li>
+<li><a href = "../ace/Hash_Map_Manager.cpp">Hash_Map_Manager.cpp</a></li>
+<li><a href = "../ace/Hash_Map_Manager.h">Hash_Map_Manager.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Hash__Map__Manager.html">[doxygen]</a></b>
+<li><a href = "../ace/Filecache.cpp">Filecache.cpp</a></li>
+<li><a href = "../ace/Filecache.h">Filecache.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Filecache.html">[doxygen]</a></b>
+<li><a href = "../ace/Free_List.cpp">Free_List.cpp</a></li>
+<li><a href = "../ace/Free_List.inl">Free_List.inl</a></li>
+<li><a href = "../ace/Free_List.h">Free_List.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Free__List.html">[doxygen]</a></b>
+<li><a href = "../ace/Managed_Object.cpp">Managed_Object.cpp</a></li>
+<li><a href = "../ace/Managed_Object.h">Managed_Object.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Managed__Object.html">[doxygen]</a></b>
+<li><a href = "../ace/Managed_Object.inl">Managed_Object.inl</a></li>
+<li><a href = "../ace/Map_Manager.cpp">Map_Manager.cpp</a></li>
+<li><a href = "../ace/Map_Manager.h">Map_Manager.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Map__Manager.html">[doxygen]</a></b>
+<li><a href = "../ace/Map_Manager.inl">Map_Manager.inl</a></li>
+<li><a href = "../ace/Object_Manager.cpp">Object_Manager.cpp</a></li>
+<li><a href = "../ace/Object_Manager.inl">Object_Manager.inl</a></li>
+<li><a href = "../ace/Object_Manager.h">Object_Manager.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Object__Manager.html">[doxygen]</a></b>
+<li><a href = "../ace/SString.cpp">SString.cpp</a></li>
+<li><a href = "../ace/SString.h">SString.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SString.html">[doxygen]</a></b>
+<li><a href = "../ace/SString.inl">SString.inl</a></li>
+</ul>
+<b>[Concurrency]</b>
+<ul>
+<li><a href = "../ace/Activation_Queue.h">Activation_Queue.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Activation__Queue.html">[doxygen]</a></b>
+<li><a href = "../ace/Activation_Queue.cpp">Activation_Queue.cpp</a></li>
+<li><a href = "../ace/Atomic_Op.inl">Atomic_Op.inl</a></li>
+<li><a href = "../ace/Future.h">Future.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Future.html">[doxygen]</a></b>
+<li><a href = "../ace/Future.cpp">Future.cpp</a></li>
+<li><a href = "../ace/Method_Request.h">Method_Request.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Method__Request.html">[doxygen]</a></b>
+<li><a href = "../ace/Method_Request.cpp">Method_Request.cpp</a></li>
+<li><a href = "../ace/Process.cpp">Process.cpp</a></li>
+<li><a href = "../ace/Process.h">Process.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Process.html">[doxygen]</a></b>
+<li><a href = "../ace/Process.inl">Process.inl</a></li>
+<li><a href = "../ace/Process_Manager.cpp">Process_Manager.cpp</a></li>
+<li><a href = "../ace/Process_Manager.h">Process_Manager.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Process__Manager.html">[doxygen]</a></b>
+<li><a href = "../ace/Process_Manager.inl">Process_Manager.inl</a></li>
+<li><a href = "../ace/Sched_Params.cpp">Sched_Params.cpp</a></li>
+<li><a href = "../ace/Sched_Params.h">Sched_Params.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Sched__Params.html">[doxygen]</a></b>
+<li><a href = "../ace/Sched_Params.inl">Sched_Params.inl</a></li>
+<li><a href = "../ace/Synch.cpp">Synch.cpp</a></li>
+<li><a href = "../ace/Synch.h">Synch.h</a></li>
+<li><a href = "../ace/Synch.inl">Synch.inl</a></li>
+<li><a href = "../ace/Synch_Options.cpp">Synch_Options.cpp</a></li>
+<li><a href = "../ace/Synch_Options.h">Synch_Options.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Synch__Options.html">[doxygen]</a></b>
+<li><a href = "../ace/Synch_Options.inl">Synch_Options.inl</a></li>
+<li><a href = "../ace/Synch_T.cpp">Synch_T.cpp</a></li>
+<li><a href = "../ace/Synch_T.h">Synch_T.h</a></li>
+<li><a href = "../ace/Synch_T.inl">Synch_T.inl</a></li>
+<li><a href = "../ace/Thread.cpp">Thread.cpp</a></li>
+<li><a href = "../ace/Thread.h">Thread.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Thread.html">[doxygen]</a></b>
+<li><a href = "../ace/Thread.inl">Thread.inl</a></li>
+<li><a href = "../ace/Thread_Manager.cpp">Thread_Manager.cpp</a></li>
+<li><a href = "../ace/Thread_Manager.h">Thread_Manager.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Thread__Manager.html">[doxygen]</a></b>
+<li><a href = "../ace/Thread_Manager.inl">Thread_Manager.inl</a></li>
+<li><a href = "../ace/Token.cpp">Token.cpp</a></li>
+<li><a href = "../ace/Token.h">Token.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Token.html">[doxygen]</a></b>
+<li><a href = "../ace/Token.inl">Token.inl</a></li>
+</ul>
+<b>[Config]</b>
+<ul>
+<li><a href = "../ace/config.h">config.h</a></li>
+<li><a href = "../ace/Basic_Types.cpp">Basic_Types.cpp</a></li>
+<li><a href = "../ace/Basic_Types.h">Basic_Types.h</a></li>
+<li><a href = "../ace/Basic_Types.inl">Basic_Types.inl</a></li>
+<li><a href = "../ace/Version.h">Version.h</a></li>
+</ul>
+<b>[Connection]</b>
+<ul>
+<li><a href = "../ace/Acceptor.cpp">Acceptor.cpp</a></li>
+<li><a href = "../ace/Acceptor.h">Acceptor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Acceptor.html">[doxygen]</a></b>
+<li><a href = "../ace/Acceptor.inl">Acceptor.inl</a></li>
+<li><a href = "../ace/Asynch_Acceptor.cpp">Asynch_Acceptor.cpp</a></li>
+<li><a href = "../ace/Asynch_Acceptor.h">Asynch_Acceptor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Asynch__Acceptor.html">[doxygen]</a></b>
+<li><a href = "../ace/Asynch_Acceptor.inl">Asynch_Acceptor.inl</a></li>
+<li><a href = "../ace/Asynch_IO.cpp">Asynch_IO.cpp</a></li>
+<li><a href = "../ace/Asynch_IO.h">Asynch_IO.h</a></li>
+<li><a href = "../ace/Asynch_IO.inl">Asynch_IO.inl</a></li>
+<li><a href = "../ace/Connector.cpp">Connector.cpp</a></li>
+<li><a href = "../ace/Connector.h">Connector.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Connector.html">[doxygen]</a></b>
+<li><a href = "../ace/Connector.inl">Connector.inl</a></li>
+<li><a href = "../ace/Dynamic_Service.cpp">Dynamic_Service.cpp</a></li>
+<li><a href = "../ace/Dynamic_Service.h">Dynamic_Service.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Dynamic__Service.html">[doxygen]</a></b>
+<li><a href = "../ace/Dynamic_Service.inl">Dynamic_Service.inl</a></li>
+<li><a href = "../ace/Strategies.cpp">Strategies.cpp</a></li>
+<li><a href = "../ace/Strategies.h">Strategies.h</a></li>
+<li><a href = "../ace/Strategies.inl">Strategies.inl</a></li>
+<li><a href = "../ace/Strategies_T.cpp">Strategies_T.cpp</a></li>
+<li><a href = "../ace/Strategies_T.h">Strategies_T.h</a></li>
+<li><a href = "../ace/Strategies_T.inl">Strategies_T.inl</a></li>
+<li><a href = "../ace/Svc_Handler.cpp">Svc_Handler.cpp</a></li>
+<li><a href = "../ace/Svc_Handler.h">Svc_Handler.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Svc__Handler.html">[doxygen]</a></b>
+<li><a href = "../ace/Svc_Handler.inl">Svc_Handler.inl</a></li>
+</ul>
+<b>[IPC]</b>
+<ul>
+<b>[IO_SAP]</b>
+<ul>
+<li><a href = "../ace/IO_SAP.cpp">IO_SAP.cpp</a></li>
+<li><a href = "../ace/IO_SAP.h">IO_SAP.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IO__SAP.html">[doxygen]</a></b>
+<li><a href = "../ace/IO_SAP.inl">IO_SAP.inl</a></li>
+<br>
+<b>[DEV_SAP]</b>
+<ul>
+<li><a href = "../ace/DEV.cpp">DEV.cpp</a></li>
+<li><a href = "../ace/DEV.h">DEV.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DEV.html">[doxygen]</a></b>
+<li><a href = "../ace/DEV.inl">DEV.inl</a></li>
+<li><a href = "../ace/DEV_Connector.cpp">DEV_Connector.cpp</a></li>
+<li><a href = "../ace/DEV_Connector.h">DEV_Connector.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DEV__Connector.html">[doxygen]</a></b>
+<li><a href = "../ace/DEV_Connector.inl">DEV_Connector.inl</a></li>
+<li><a href = "../ace/DEV_IO.cpp">DEV_IO.cpp</a></li>
+<li><a href = "../ace/DEV_IO.h">DEV_IO.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DEV__IO.html">[doxygen]</a></b>
+<li><a href = "../ace/DEV_IO.inl">DEV_IO.inl</a></li>
+<li><a href = "../ace/TTY_IO.cpp">TTY_IO.cpp</a></li>
+<li><a href = "../ace/TTY_IO.h">TTY_IO.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TTY__IO.html">[doxygen]</a></b>
+</ul>
+<b>[FILE_SAP]</b>
+<ul>
+<li><a href = "../ace/FILE.cpp">FILE.cpp</a></li>
+<li><a href = "../ace/FILE.h">FILE.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FILE.html">[doxygen]</a></b>
+<li><a href = "../ace/FILE.inl">FILE.inl</a></li>
+<li><a href = "../ace/FILE_Connector.cpp">FILE_Connector.cpp</a></li>
+<li><a href = "../ace/FILE_Connector.h">FILE_Connector.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FILE__Connector.html">[doxygen]</a></b>
+<li><a href = "../ace/FILE_Connector.inl">FILE_Connector.inl</a></li>
+<li><a href = "../ace/FILE_IO.cpp">FILE_IO.cpp</a></li>
+<li><a href = "../ace/FILE_IO.h">FILE_IO.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FILE__IO.html">[doxygen]</a></b>
+<li><a href = "../ace/FILE_IO.inl">FILE_IO.inl</a></li>
+</ul>
+</ul>
+<b>[IPC_SAP]</b>
+<ul>
+<li><a href = "../ace/IPC_SAP.cpp">IPC_SAP.cpp</a></li>
+<li><a href = "../ace/IPC_SAP.h">IPC_SAP.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IPC__SAP.html">[doxygen]</a></b>
+<li><a href = "../ace/IPC_SAP.inl">IPC_SAP.inl</a></li>
+<br>
+<b>[Addr]</b>
+<ul>
+<li><a href = "../ace/Addr.cpp">Addr.cpp</a></li>
+<li><a href = "../ace/Addr.h">Addr.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Addr.html">[doxygen]</a></b>
+<li><a href = "../ace/Addr.inl">Addr.inl</a></li>
+<li><a href = "../ace/DEV_Addr.cpp">DEV_Addr.cpp</a></li>
+<li><a href = "../ace/DEV_Addr.h">DEV_Addr.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DEV__Addr.html">[doxygen]</a></b>
+<li><a href = "../ace/DEV_Addr.inl">DEV_Addr.inl</a></li>
+<li><a href = "../ace/FILE_Addr.cpp">FILE_Addr.cpp</a></li>
+<li><a href = "../ace/FILE_Addr.h">FILE_Addr.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FILE__Addr.html">[doxygen]</a></b>
+<li><a href = "../ace/FILE_Addr.inl">FILE_Addr.inl</a></li>
+<li><a href = "../ace/INET_Addr.cpp">INET_Addr.cpp</a></li>
+<li><a href = "../ace/INET_Addr.h">INET_Addr.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__INET__Addr.html">[doxygen]</a></b>
+<li><a href = "../ace/INET_Addr.inl">INET_Addr.inl</a></li>
+<li><a href = "../ace/SPIPE_Addr.cpp">SPIPE_Addr.cpp</a></li>
+<li><a href = "../ace/SPIPE_Addr.h">SPIPE_Addr.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE__Addr.html">[doxygen]</a></b>
+<li><a href = "../ace/SPIPE_Addr.inl">SPIPE_Addr.inl</a></li>
+<li><a href = "../ace/UNIX_Addr.cpp">UNIX_Addr.cpp</a></li>
+<li><a href = "../ace/UNIX_Addr.h">UNIX_Addr.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UNIX__Addr.html">[doxygen]</a></b>
+<li><a href = "../ace/UNIX_Addr.inl">UNIX_Addr.inl</a></li>
+<li><a href = "../ace/UPIPE_Addr.h">UPIPE_Addr.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UPIPE__Addr.html">[doxygen]</a></b>
+</ul>
+<b>[FIFO_SAP]</b>
+<ul>
+<li><a href = "../ace/FIFO.cpp">FIFO.cpp</a></li>
+<li><a href = "../ace/FIFO.h">FIFO.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO.html">[doxygen]</a></b>
+<li><a href = "../ace/FIFO.inl">FIFO.inl</a></li>
+<li><a href = "../ace/FIFO_Recv.cpp">FIFO_Recv.cpp</a></li>
+<li><a href = "../ace/FIFO_Recv.h">FIFO_Recv.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO__Recv.html">[doxygen]</a></b>
+<li><a href = "../ace/FIFO_Recv.inl">FIFO_Recv.inl</a></li>
+<li><a href = "../ace/FIFO_Recv_Msg.cpp">FIFO_Recv_Msg.cpp</a></li>
+<li><a href = "../ace/FIFO_Recv_Msg.h">FIFO_Recv_Msg.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO__Recv__Msg.html">[doxygen]</a></b>
+<li><a href = "../ace/FIFO_Recv_Msg.inl">FIFO_Recv_Msg.inl</a></li>
+<li><a href = "../ace/FIFO_Send.cpp">FIFO_Send.cpp</a></li>
+<li><a href = "../ace/FIFO_Send.h">FIFO_Send.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO__Send.html">[doxygen]</a></b>
+<li><a href = "../ace/FIFO_Send.inl">FIFO_Send.inl</a></li>
+<li><a href = "../ace/FIFO_Send_Msg.cpp">FIFO_Send_Msg.cpp</a></li>
+<li><a href = "../ace/FIFO_Send_Msg.h">FIFO_Send_Msg.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__FIFO__Send__Msg.html">[doxygen]</a></b>
+<li><a href = "../ace/FIFO_Send_Msg.inl">FIFO_Send_Msg.inl</a></li>
+</ul>
+<b>[SOCK_SAP]</b>
+<ul>
+<li><a href = "../ace/LOCK_SOCK_Acceptor.cpp">LOCK_SOCK_Acceptor.cpp</a></li>
+<li><a href = "../ace/LOCK_SOCK_Acceptor.h">LOCK_SOCK_Acceptor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LOCK__SOCK__Acceptor.html">[doxygen]</a></b>
+<li><a href = "../ace/LSOCK.cpp">LSOCK.cpp</a></li>
+<li><a href = "../ace/LSOCK.h">LSOCK.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK.html">[doxygen]</a></b>
+<li><a href = "../ace/LSOCK.inl">LSOCK.inl</a></li>
+<li><a href = "../ace/LSOCK_Acceptor.cpp">LSOCK_Acceptor.cpp</a></li>
+<li><a href = "../ace/LSOCK_Acceptor.h">LSOCK_Acceptor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__Acceptor.html">[doxygen]</a></b>
+<li><a href = "../ace/LSOCK_Acceptor.inl">LSOCK_Acceptor.inl</a></li>
+<li><a href = "../ace/LSOCK_CODgram.cpp">LSOCK_CODgram.cpp</a></li>
+<li><a href = "../ace/LSOCK_CODgram.h">LSOCK_CODgram.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__CODgram.html">[doxygen]</a></b>
+<li><a href = "../ace/LSOCK_CODgram.inl">LSOCK_CODgram.inl</a></li>
+<li><a href = "../ace/LSOCK_Connector.cpp">LSOCK_Connector.cpp</a></li>
+<li><a href = "../ace/LSOCK_Connector.h">LSOCK_Connector.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__Connector.html">[doxygen]</a></b>
+<li><a href = "../ace/LSOCK_Connector.inl">LSOCK_Connector.inl</a></li>
+<li><a href = "../ace/LSOCK_Dgram.cpp">LSOCK_Dgram.cpp</a></li>
+<li><a href = "../ace/LSOCK_Dgram.h">LSOCK_Dgram.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__Dgram.html">[doxygen]</a></b>
+<li><a href = "../ace/LSOCK_Dgram.inl">LSOCK_Dgram.inl</a></li>
+<li><a href = "../ace/LSOCK_Stream.cpp">LSOCK_Stream.cpp</a></li>
+<li><a href = "../ace/LSOCK_Stream.h">LSOCK_Stream.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__LSOCK__Stream.html">[doxygen]</a></b>
+<li><a href = "../ace/LSOCK_Stream.inl">LSOCK_Stream.inl</a></li>
+<li><a href = "../ace/SOCK.cpp">SOCK.cpp</a></li>
+<li><a href = "../ace/SOCK.h">SOCK.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK.html">[doxygen]</a></b>
+<li><a href = "../ace/SOCK.inl">SOCK.inl</a></li>
+<li><a href = "../ace/SOCK_Acceptor.cpp">SOCK_Acceptor.cpp</a></li>
+<li><a href = "../ace/SOCK_Acceptor.h">SOCK_Acceptor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Acceptor.html">[doxygen]</a></b>
+<li><a href = "../ace/SOCK_Acceptor.inl">SOCK_Acceptor.inl</a></li>
+<li><a href = "../ace/SOCK_CODgram.cpp">SOCK_CODgram.cpp</a></li>
+<li><a href = "../ace/SOCK_CODgram.h">SOCK_CODgram.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__CODgram.html">[doxygen]</a></b>
+<li><a href = "../ace/SOCK_CODgram.inl">SOCK_CODgram.inl</a></li>
+<li><a href = "../ace/SOCK_Connector.cpp">SOCK_Connector.cpp</a></li>
+<li><a href = "../ace/SOCK_Connector.h">SOCK_Connector.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Connector.html">[doxygen]</a></b>
+<li><a href = "../ace/SOCK_Connector.inl">SOCK_Connector.inl</a></li>
+<li><a href = "../ace/SOCK_Dgram.cpp">SOCK_Dgram.cpp</a></li>
+<li><a href = "../ace/SOCK_Dgram.h">SOCK_Dgram.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Dgram.html">[doxygen]</a></b>
+<li><a href = "../ace/SOCK_Dgram.inl">SOCK_Dgram.inl</a></li>
+<li><a href = "../ace/SOCK_Dgram_Bcast.cpp">SOCK_Dgram_Bcast.cpp</a></li>
+<li><a href = "../ace/SOCK_Dgram_Bcast.h">SOCK_Dgram_Bcast.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Dgram_Bcast.html">[doxygen]</a></b>
+<li><a href = "../ace/SOCK_Dgram_Bcast.inl">SOCK_Dgram_Bcast.inl</a></li>
+<li><a href = "../ace/SOCK_Dgram_Mcast.cpp">SOCK_Dgram_Mcast.cpp</a></li>
+<li><a href = "../ace/SOCK_Dgram_Mcast.h">SOCK_Dgram_Mcast.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Dgram__Mcast.html">[doxygen]</a></b>
+<li><a href = "../ace/SOCK_Dgram_Mcast.inl">SOCK_Dgram_Mcast.inl</a></li>
+<li><a href = "../ace/SOCK_IO.cpp">SOCK_IO.cpp</a></li>
+<li><a href = "../ace/SOCK_IO.h">SOCK_IO.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__IO.html">[doxygen]</a></b>
+<li><a href = "../ace/SOCK_IO.inl">SOCK_IO.inl</a></li>
+<li><a href = "../ace/SOCK_Stream.cpp">SOCK_Stream.cpp</a></li>
+<li><a href = "../ace/SOCK_Stream.h">SOCK_Stream.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SOCK__Stream.html">[doxygen]</a></b>
+<li><a href = "../ace/SOCK_Stream.inl">SOCK_Stream.inl</a></li>
+</ul>
+<b>[SPIPE_SAP]</b>
+<ul>
+<li><a href = "../ace/SPIPE.cpp">SPIPE.cpp</a></li>
+<li><a href = "../ace/SPIPE.h">SPIPE.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE.html">[doxygen]</a></b>
+<li><a href = "../ace/SPIPE.inl">SPIPE.inl</a></li>
+<li><a href = "../ace/SPIPE_Acceptor.cpp">SPIPE_Acceptor.cpp</a></li>
+<li><a href = "../ace/SPIPE_Acceptor.h">SPIPE_Acceptor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE__Acceptor.html">[doxygen]</a></b>
+<li><a href = "../ace/SPIPE_Acceptor.inl">SPIPE_Acceptor.inl</a></li>
+<li><a href = "../ace/SPIPE_Connector.cpp">SPIPE_Connector.cpp</a></li>
+<li><a href = "../ace/SPIPE_Connector.h">SPIPE_Connector.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE__Connector.html">[doxygen]</a></b>
+<li><a href = "../ace/SPIPE_Connector.inl">SPIPE_Connector.inl</a></li>
+<li><a href = "../ace/SPIPE_Stream.cpp">SPIPE_Stream.cpp</a></li>
+<li><a href = "../ace/SPIPE_Stream.h">SPIPE_Stream.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SPIPE__Stream.html">[doxygen]</a></b>
+<li><a href = "../ace/SPIPE_Stream.inl">SPIPE_Stream.inl</a></li>
+</ul>
+<b>[TLI_SAP]</b>
+<ul>
+<li><a href = "../ace/TLI.cpp">TLI.cpp</a></li>
+<li><a href = "../ace/TLI.h">TLI.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TLI.html">[doxygen]</a></b>
+<li><a href = "../ace/TLI.inl">TLI.inl</a></li>
+<li><a href = "../ace/TLI_Acceptor.cpp">TLI_Acceptor.cpp</a></li>
+<li><a href = "../ace/TLI_Acceptor.h">TLI_Acceptor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TLI__Acceptor.html">[doxygen]</a></b>
+<li><a href = "../ace/TLI_Acceptor.inl">TLI_Acceptor.inl</a></li>
+<li><a href = "../ace/TLI_Connector.cpp">TLI_Connector.cpp</a></li>
+<li><a href = "../ace/TLI_Connector.h">TLI_Connector.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TLI__Connector.html">[doxygen]</a></b>
+<li><a href = "../ace/TLI_Connector.inl">TLI_Connector.inl</a></li>
+<li><a href = "../ace/TLI_Stream.cpp">TLI_Stream.cpp</a></li>
+<li><a href = "../ace/TLI_Stream.h">TLI_Stream.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__TLI__Stream.html">[doxygen]</a></b>
+<li><a href = "../ace/TLI_Stream.inl">TLI_Stream.inl</a></li>
+</ul>
+</ul>
+<b>[UPIPE_SAP]</b>
+<ul>
+<li><a href = "../ace/UPIPE_Acceptor.cpp">UPIPE_Acceptor.cpp</a></li>
+<li><a href = "../ace/UPIPE_Acceptor.h">UPIPE_Acceptor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UPIPE__Acceptor.html">[doxygen]</a></b>
+<li><a href = "../ace/UPIPE_Acceptor.inl">UPIPE_Acceptor.inl</a></li>
+<li><a href = "../ace/UPIPE_Connector.cpp">UPIPE_Connector.cpp</a></li>
+<li><a href = "../ace/UPIPE_Connector.h">UPIPE_Connector.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UPIPE__Connector.html">[doxygen]</a></b>
+<li><a href = "../ace/UPIPE_Connector.inl">UPIPE_Connector.inl</a></li>
+<li><a href = "../ace/UPIPE_Stream.cpp">UPIPE_Stream.cpp</a></li>
+<li><a href = "../ace/UPIPE_Stream.h">UPIPE_Stream.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__UPIPE__Stream.html">[doxygen]</a></b>
+<li><a href = "../ace/UPIPE_Stream.inl">UPIPE_Stream.inl</a></li>
+</ul>
+<b>[Misc]</b>
+<ul>
+<li><a href = "../ace/IOStream.cpp">IOStream.cpp</a></li>
+<li><a href = "../ace/IOStream.h">IOStream.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IOStream.html">[doxygen]</a></b>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IOStream_T.html">[doxygen]</a></b>
+<li><a href = "../ace/IOStream_T.inl">IOStream_T.inl</a></li>
+<li><a href = "../ace/Pipe.cpp">Pipe.cpp</a></li>
+<li><a href = "../ace/Pipe.h">Pipe.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Pipe.html">[doxygen]</a></b>
+<li><a href = "../ace/Pipe.inl">Pipe.inl</a></li>
+<li><a href = "../ace/Signal.cpp">Signal.cpp</a></li>
+<li><a href = "../ace/Signal.h">Signal.h</a></li>
+<li><a href = "../ace/Signal.inl">Signal.inl</a></li>
+</ul>
+</ul>
+<b>[Logging and Tracing]</b>
+<ul>
+<li><a href = "../ace/Dump.cpp">Dump.cpp</a></li>
+<li><a href = "../ace/Dump.h">Dump.h</a></li>
+<li><a href = "../ace/Dump_T.cpp">Dump_T.cpp</a></li>
+<li><a href = "../ace/Dump_T.h">Dump_T.h</a></li>
+<li><a href = "../ace/Log_Msg.cpp">Log_Msg.cpp</a></li>
+<li><a href = "../ace/Log_Msg.h">Log_Msg.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Log__Msg.html">[doxygen]</a></b>
+<li><a href = "../ace/Log_Msg.inl">Log_Msg.inl</a></li>
+<li><a href = "../ace/Log_Priority.h">Log_Priority.h</a></li>
+<li><a href = "../ace/Log_Record.cpp">Log_Record.cpp</a></li>
+<li><a href = "../ace/Log_Record.h">Log_Record.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Log__Record.html">[doxygen]</a></b>
+<li><a href = "../ace/Log_Record.inl">Log_Record.inl</a></li>
+<li><a href = "../ace/Trace.cpp">Trace.cpp</a></li>
+<li><a href = "../ace/Trace.h">Trace.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Trace.html">[doxygen]</a></b>
+<li><a href = "../ace/Trace.inl">Trace.inl</a></li>
+</ul>
+<b>[Memory]</b>
+<ul>
+<b>[Mem_Map]</b>
+<ul>
+<li><a href = "../ace/Mem_Map.cpp">Mem_Map.cpp</a></li>
+<li><a href = "../ace/Mem_Map.h">Mem_Map.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Mem__Map.html">[doxygen]</a></b>
+<li><a href = "../ace/Mem_Map.inl">Mem_Map.inl</a></li>
+</ul>
+<b>[Shared_Malloc]</b>
+<ul>
+<li><a href = "../ace/Malloc.cpp">Malloc.cpp</a></li>
+<li><a href = "../ace/Malloc.h">Malloc.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Malloc.html">[doxygen]</a></b>
+<li><a href = "../ace/Malloc.inl">Malloc.inl</a></li>
+<li><a href = "../ace/Malloc_T.cpp">Malloc_T.cpp</a></li>
+<li><a href = "../ace/Malloc_T.h">Malloc_T.h</a></li>
+<li><a href = "../ace/Malloc_T.inl">Malloc_T.inl</a></li>
+<li><a href = "../ace/Memory_Pool.cpp">Memory_Pool.cpp</a></li>
+<li><a href = "../ace/Memory_Pool.h">Memory_Pool.h</a></li>
+<li><a href = "../ace/Memory_Pool.inl">Memory_Pool.inl</a></li>
+</ul>
+<b>[Shared_Memory]</b>
+<ul>
+<li><a href = "../ace/Shared_Memory.h">Shared_Memory.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Shared__Memory.html">[doxygen]</a></b>
+<li><a href = "../ace/Shared_Memory_MM.cpp">Shared_Memory_MM.cpp</a></li>
+<li><a href = "../ace/Shared_Memory_MM.h">Shared_Memory_MM.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Shared__Memory__MM.html">[doxygen]</a></b>
+<li><a href = "../ace/Shared_Memory_MM.inl">Shared_Memory_MM.inl</a></li>
+<li><a href = "../ace/Shared_Memory_SV.cpp">Shared_Memory_SV.cpp</a></li>
+<li><a href = "../ace/Shared_Memory_SV.h">Shared_Memory_SV.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Shared__Memory__SV.html">[doxygen]</a></b>
+<li><a href = "../ace/Shared_Memory_SV.inl">Shared_Memory_SV.inl</a></li>
+</ul>
+<b>[Utils]</b>
+<ul>
+<li><a href = "../ace/Obstack.cpp">Obstack.cpp</a></li>
+<li><a href = "../ace/Obstack.h">Obstack.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Obstack.html">[doxygen]</a></b>
+<li><a href = "../ace/Read_Buffer.cpp">Read_Buffer.cpp</a></li>
+<li><a href = "../ace/Read_Buffer.h">Read_Buffer.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Read__Buffer.html">[doxygen]</a></b>
+<li><a href = "../ace/Read_Buffer.inl">Read_Buffer.inl</a></li>
+</ul>
+</ul>
+<b>[Misc]</b>
+<ul>
+<li><a href = "../ace/ARGV.cpp">ARGV.cpp</a></li>
+<li><a href = "../ace/ARGV.h">ARGV.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__ARGV.html">[doxygen]</a></b>
+<li><a href = "../ace/ARGV.inl">ARGV.inl</a></li>
+<li><a href = "../ace/Auto_Ptr.cpp">Auto_Ptr.cpp</a></li>
+<li><a href = "../ace/Auto_Ptr.h">Auto_Ptr.h</a></li>
+<li><a href = "../ace/Auto_Ptr.inl">Auto_Ptr.inl</a></li>
+<li><a href = "../ace/Date_Time.cpp">Date_Time.cpp</a></li>
+<li><a href = "../ace/Date_Time.h">Date_Time.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Date__Time.html">[doxygen]</a></b>
+<li><a href = "../ace/Date_Time.inl">Date_Time.inl</a></li>
+<li><a href = "../ace/Dynamic.cpp">Dynamic.cpp</a></li>
+<li><a href = "../ace/Dynamic.h">Dynamic.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Dynamic.html">[doxygen]</a></b>
+<li><a href = "../ace/Dynamic.inl">Dynamic.inl</a></li>
+<li><a href = "../ace/Get_Opt.cpp">Get_Opt.cpp</a></li>
+<li><a href = "../ace/Get_Opt.h">Get_Opt.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Get__Opt.html">[doxygen]</a></b>
+<li><a href = "../ace/Get_Opt.inl">Get_Opt.inl</a></li>
+<li><a href = "../ace/Registry.cpp">Registry.cpp</a></li>
+<li><a href = "../ace/Registry.h">Registry.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Registry.html">[doxygen]</a></b>
+<li><a href = "../ace/Singleton.cpp">Singleton.cpp</a></li>
+<li><a href = "../ace/Singleton.h">Singleton.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Singleton.html">[doxygen]</a></b>
+<li><a href = "../ace/Singleton.inl">Singleton.inl</a></li>
+<li><a href = "../ace/System_Time.cpp">System_Time.cpp</a></li>
+<li><a href = "../ace/System_Time.h">System_Time.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__System__Time.html">[doxygen]</a></b>
+</ul>
+<b>[Name_Service]</b>
+<ul>
+<li><a href = "../ace/Local_Name_Space.cpp">Local_Name_Space.cpp</a></li>
+<li><a href = "../ace/Local_Name_Space.h">Local_Name_Space.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Local__Name__Space.html">[doxygen]</a></b>
+<li><a href = "../ace/Local_Name_Space_T.cpp">Local_Name_Space_T.cpp</a></li>
+<li><a href = "../ace/Local_Name_Space_T.h">Local_Name_Space_T.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Name__Options.html">[doxygen]</a></b>
+<li><a href = "../ace/Name_Proxy.cpp">Name_Proxy.cpp</a></li>
+<li><a href = "../ace/Name_Proxy.h">Name_Proxy.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Name__Proxy.html">[doxygen]</a></b>
+<li><a href = "../ace/Name_Request_Reply.cpp">Name_Request_Reply.cpp</a></li>
+<li><a href = "../ace/Name_Request_Reply.h">Name_Request_Reply.h</a></li>
+<li><a href = "../ace/Name_Space.cpp">Name_Space.cpp</a></li>
+<li><a href = "../ace/Name_Space.h">Name_Space.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Name__Space.html">[doxygen]</a></b>
+<li><a href = "../ace/Naming_Context.cpp">Naming_Context.cpp</a></li>
+<li><a href = "../ace/Naming_Context.h">Naming_Context.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Naming__Context.html">[doxygen]</a></b>
+<li><a href = "../ace/Registry_Name_Space.cpp">Registry_Name_Space.cpp</a></li>
+<li><a href = "../ace/Registry_Name_Space.h">Registry_Name_Space.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Registry__Name__Space.html">[doxygen]</a></b>
+<li><a href = "../ace/Remote_Name_Space.cpp">Remote_Name_Space.cpp</a></li>
+<li><a href = "../ace/Remote_Name_Space.h">Remote_Name_Space.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Remote__Name__Space.html">[doxygen]</a></b>
+</ul>
+<b>[OS Adapters]</b>
+<ul>
+<li><a href = "../ace/ACE.cpp">ACE.cpp</a></li>
+<li><a href = "../ace/ACE.h">ACE.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/namespaceACE.html">[doxygen]</a></b>
+<li><a href = "../ace/ACE.inl">ACE.inl</a></li>
+<li><a href = "../ace/OS.cpp">OS.cpp</a></li>
+<li><a href = "../ace/OS.h">OS.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/namespaceACE__OS.html">[doxygen]</a></b>
+<li><a href = "../ace/OS.inl">OS.inl</a></li>
+</ul>
+<b>[Reactor]</b>
+<ul>
+<li><a href = "../ace/Event_Handler.cpp">Event_Handler.cpp</a></li>
+<li><a href = "../ace/Event_Handler.h">Event_Handler.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Event__Handler.html">[doxygen]</a></b>
+<li><a href = "../ace/Event_Handler.inl">Event_Handler.inl</a></li>
+<li><a href = "../ace/Event_Handler_T.cpp">Event_Handler_T.cpp</a></li>
+<li><a href = "../ace/Event_Handler_T.h">Event_Handler_T.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Event__Handler__T.html">[doxygen]</a></b>
+<li><a href = "../ace/Event_Handler_T.inl">Event_Handler_T.inl</a></li>
+<li><a href = "../ace/Handle_Set.cpp">Handle_Set.cpp</a></li>
+<li><a href = "../ace/Handle_Set.h">Handle_Set.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Handle__Set.html">[doxygen]</a></b>
+<li><a href = "../ace/Handle_Set.inl">Handle_Set.inl</a></li>
+<li><a href = "../ace/Priority_Reactor.cpp">Priority_Reactor.cpp</a></li>
+<li><a href = "../ace/Priority_Reactor.inl">Priority_Reactor.inl</a></li>
+<li><a href = "../ace/Priority_Reactor.h">Priority_Reactor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Priority__Reactor.html">[doxygen]</a></b>
+<li><a href = "../ace/Proactor.h">Proactor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Proactor.html">[doxygen]</a></b>
+<li><a href = "../ace/Proactor.inl">Proactor.inl</a></li>
+<li><a href = "../ace/Proactor.cpp">Proactor.cpp</a></li>
+<li><a href = "../ace/Reactor.cpp">Reactor.cpp</a></li>
+<li><a href = "../ace/Reactor.h">Reactor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Reactor.html">[doxygen]</a></b>
+<li><a href = "../ace/Reactor.inl">Reactor.inl</a></li>
+<li><a href = "../ace/Reactor_Impl.h">Reactor_Impl.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Reactor__Impl.html">[doxygen]</a></b>
+<li><a href = "../ace/Select_Reactor.cpp">Select_Reactor.cpp</a></li>
+<li><a href = "../ace/Select_Reactor.h">Select_Reactor.h</a></li>
+<li><a href = "../ace/Select_Reactor.inl">Select_Reactor.inl</a></li>
+<li><a href = "../ace/WFMO_Reactor.cpp">WFMO_Reactor.cpp</a></li>
+<li><a href = "../ace/WFMO_Reactor.h">WFMO_Reactor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__WFMO__Reactor.html">[doxygen]</a></b>
+<li><a href = "../ace/WFMO_Reactor.inl">WFMO_Reactor.inl</a></li>
+<li><a href = "../ace/XtReactor.cpp">XtReactor.cpp</a></li>
+<li><a href = "../ace/XtReactor.h">XtReactor.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__XtReactor.html">[doxygen]</a></b>
+</ul>
+<b>[Service_Configurator]</b>
+<ul>
+<li><a href = "../ace/DLL.cpp">DLL.cpp</a></li>
+<li><a href = "../ace/DLL.h">DLL.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__DLL.html">[doxygen]</a></b>
+<li><a href = "../ace/Parse_Node.cpp">Parse_Node.cpp</a></li>
+<li><a href = "../ace/Parse_Node.h">Parse_Node.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Parse__Node.html">[doxygen]</a></b>
+<li><a href = "../ace/Parse_Node.inl">Parse_Node.inl</a></li>
+<li><a href = "../ace/Service_Config.cpp">Service_Config.cpp</a></li>
+<li><a href = "../ace/Service_Config.h">Service_Config.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Service__Config.html">[doxygen]</a></b>
+<li><a href = "../ace/Service_Config.inl">Service_Config.inl</a></li>
+<li><a href = "../ace/Service_Manager.cpp">Service_Manager.cpp</a></li>
+<li><a href = "../ace/Service_Manager.h">Service_Manager.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Service__Manager.html">[doxygen]</a></b>
+<li><a href = "../ace/Service_Manager.inl">Service_Manager.inl</a></li>
+<li><a href = "../ace/Service_Object.cpp">Service_Object.cpp</a></li>
+<li><a href = "../ace/Service_Object.h">Service_Object.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Service__Object.html">[doxygen]</a></b>
+<li><a href = "../ace/Service_Object.inl">Service_Object.inl</a></li>
+<li><a href = "../ace/Service_Repository.cpp">Service_Repository.cpp</a></li>
+<li><a href = "../ace/Service_Repository.h">Service_Repository.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Service__Repository.html">[doxygen]</a></b>
+<li><a href = "../ace/Service_Repository.inl">Service_Repository.inl</a></li>
+<li><a href = "../ace/Service_Types.cpp">Service_Types.cpp</a></li>
+<li><a href = "../ace/Service_Types.inl">Service_Types.inl</a></li>
+<li><a href = "../ace/Service_Types.h">Service_Types.h</a></li>
+<li><a href = "../ace/Shared_Object.cpp">Shared_Object.cpp</a></li>
+<li><a href = "../ace/Shared_Object.h">Shared_Object.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Shared__Object.html">[doxygen]</a></b>
+<li><a href = "../ace/Shared_Object.inl">Shared_Object.inl</a></li>
+<li><a href = "../ace/Svc_Conf.h">Svc_Conf.h</a></li>
+<li><a href = "../ace/Svc_Conf_l.cpp">Svc_Conf_l.cpp</a></li>
+<li><a href = "../ace/Svc_Conf_y.cpp">Svc_Conf_y.cpp</a></li>
+<li><a href = "../ace/Svc_Conf_Tokens.h">Svc_Conf_Tokens.h</a></li>
+</ul>
+<b>[Streams]</b>
+<ul>
+<li><a href = "../ace/IO_Cntl_Msg.cpp">IO_Cntl_Msg.cpp</a></li>
+<li><a href = "../ace/IO_Cntl_Msg.h">IO_Cntl_Msg.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__IO__Cntl__Msg.html">[doxygen]</a></b>
+<li><a href = "../ace/IO_Cntl_Msg.inl">IO_Cntl_Msg.inl</a></li>
+<li><a href = "../ace/Message_Block.cpp">Message_Block.cpp</a></li>
+<li><a href = "../ace/Message_Block.h">Message_Block.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Message__Block.html">[doxygen]</a></b>
+<li><a href = "../ace/Message_Block.inl">Message_Block.inl</a></li>
+<li><a href = "../ace/Message_Queue.cpp">Message_Queue.cpp</a></li>
+<li><a href = "../ace/Message_Queue.h">Message_Queue.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Message__Queue.html">[doxygen]</a></b>
+<li><a href = "../ace/Message_Queue.inl">Message_Queue.inl</a></li>
+<li><a href = "../ace/Message_Queue_T.cpp">Message_Queue_T.cpp</a></li>
+<li><a href = "../ace/Message_Queue_T.h">Message_Queue_T.h</a></li>
+<li><a href = "../ace/Message_Queue_T.inl">Message_Queue_T.inl</a></li>
+<li><a href = "../ace/Module.cpp">Module.cpp</a></li>
+<li><a href = "../ace/Module.h">Module.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Module.html">[doxygen]</a></b>
+<li><a href = "../ace/Module.inl">Module.inl</a></li>
+<li><a href = "../ace/Stream.cpp">Stream.cpp</a></li>
+<li><a href = "../ace/Stream.h">Stream.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Stream.html">[doxygen]</a></b>
+<li><a href = "../ace/Stream.inl">Stream.inl</a></li>
+<li><a href = "../ace/Stream_Modules.cpp">Stream_Modules.cpp</a></li>
+<li><a href = "../ace/Stream_Modules.h">Stream_Modules.h</a></li>
+<li><a href = "../ace/Stream_Modules.inl">Stream_Modules.inl</a></li>
+<li><a href = "../ace/Task.cpp">Task.cpp</a></li>
+<li><a href = "../ace/Task.h">Task.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Task.html">[doxygen]</a></b>
+<li><a href = "../ace/Task.inl">Task.inl</a></li>
+<li><a href = "../ace/Task_T.cpp">Task_T.cpp</a></li>
+<li><a href = "../ace/Task_T.h">Task_T.h</a></li>
+<li><a href = "../ace/Task_T.inl">Task_T.inl</a></li>
+</ul>
+<b>[System_V_IPC]</b>
+<ul>
+<b>[System_V_Message_Queues]</b>
+<ul>
+<li><a href = "../ace/SV_Message.cpp">SV_Message.cpp</a></li>
+<li><a href = "../ace/SV_Message.h">SV_Message.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Message.html">[doxygen]</a></b>
+<li><a href = "../ace/SV_Message.inl">SV_Message.inl</a></li>
+<li><a href = "../ace/SV_Message_Queue.cpp">SV_Message_Queue.cpp</a></li>
+<li><a href = "../ace/SV_Message_Queue.h">SV_Message_Queue.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Message__Queue.html">[doxygen]</a></b>
+<li><a href = "../ace/SV_Message_Queue.inl">SV_Message_Queue.inl</a></li>
+<li><a href = "../ace/Typed_SV_Message.cpp">Typed_SV_Message.cpp</a></li>
+<li><a href = "../ace/Typed_SV_Message.h">Typed_SV_Message.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Typed__SV__Message.html">[doxygen]</a></b>
+<li><a href = "../ace/Typed_SV_Message.inl">Typed_SV_Message.inl</a></li>
+<li><a href = "../ace/Typed_SV_Message_Queue.cpp">Typed_SV_Message_Queue.cpp</a></
+li>
+<li><a href = "../ace/Typed_SV_Message_Queue.h">Typed_SV_Message_Queue.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Typed__SV__Message__Queue.html">[doxygen]</a></b>
+<li><a href = "../ace/Typed_SV_Message_Queue.inl">Typed_SV_Message_Queue.inl</a></li>
+</ul>
+<b>[System_V_Semaphores]</b>
+<ul>
+<li><a href = "../ace/SV_Semaphore_Complex.cpp">SV_Semaphore_Complex.cpp</a></li>
+<li><a href = "../ace/SV_Semaphore_Complex.h">SV_Semaphore_Complex.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Semaphore__Complex.html">[doxygen]</a></b>
+<li><a href = "../ace/SV_Semaphore_Complex.inl">SV_Semaphore_Complex.inl</a></li>
+<li><a href = "../ace/SV_Semaphore_Simple.cpp">SV_Semaphore_Simple.cpp</a></li>
+<li><a href = "../ace/SV_Semaphore_Simple.h">SV_Semaphore_Simple.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Semaphore__Simple.html">[doxygen]</a></b>
+<li><a href = "../ace/SV_Semaphore_Simple.inl">SV_Semaphore_Simple.inl</a></li>
+</ul>
+<b>[System_V_Shared_Memory]</b>
+<ul>
+<li><a href = "../ace/SV_Shared_Memory.cpp">SV_Shared_Memory.cpp</a></li>
+<li><a href = "../ace/SV_Shared_Memory.h">SV_Shared_Memory.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__SV__Shared__Memory.html">[doxygen]</a></b>
+<li><a href = "../ace/SV_Shared_Memory.inl">SV_Shared_Memory.inl</a></li>
+</ul>
+</ul>
+<b>[Timers]</b>
+<ul>
+<li><a href = "../ace/High_Res_Timer.cpp">High_Res_Timer.cpp</a></li>
+<li><a href = "../ace/High_Res_Timer.h">High_Res_Timer.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__High__Res__Timer.html">[doxygen]</a></b>
+<li><a href = "../ace/High_Res_Timer.inl">High_Res_Timer.inl</a></li>
+<li><a href = "../ace/Profile_Timer.cpp">Profile_Timer.cpp</a></li>
+<li><a href = "../ace/Profile_Timer.h">Profile_Timer.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Profile__Timer.html">[doxygen]</a></b>
+<li><a href = "../ace/Profile_Timer.inl">Profile_Timer.inl</a></li>
+<li><a href = "../ace/Time_Request_Reply.cpp">Time_Request_Reply.cpp</a></li>
+<li><a href = "../ace/Time_Request_Reply.h">Time_Request_Reply.h</a></li>
+<li><a href = "../ace/Time_Value.h">Time_Value.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Time__Value.html">[doxygen]</a></b>
+<li><a href = "../ace/Timer_Hash.cpp">Timer_Hash.cpp</a></li>
+<li><a href = "../ace/Timer_Hash.h">Timer_Hash.h</a></li>
+<li><a href = "../ace/Timer_Hash_T.cpp">Timer_Hash_T.cpp</a></li>
+<li><a href = "../ace/Timer_Hash_T.h">Timer_Hash_T.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__Hash__T.html">[doxygen]</a></b>
+<li><a href = "../ace/Timer_Heap.cpp">Timer_Heap.cpp</a></li>
+<li><a href = "../ace/Timer_Heap.h">Timer_Heap.h</a></li>
+<li><a href = "../ace/Timer_Heap_T.cpp">Timer_Heap_T.cpp</a></li>
+<li><a href = "../ace/Timer_Heap_T.h">Timer_Heap_T.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__Heap__T.html">[doxygen]</a></b>
+<li><a href = "../ace/Timer_List.cpp">Timer_List.cpp</a></li>
+<li><a href = "../ace/Timer_List.h">Timer_List.h</a></li>
+<li><a href = "../ace/Timer_List_T.cpp">Timer_List_T.cpp</a></li>
+<li><a href = "../ace/Timer_List_T.h">Timer_List_T.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__List__T.html">[doxygen]</a></b>
+<li><a href = "../ace/Timer_Queue.cpp">Timer_Queue.cpp</a></li>
+<li><a href = "../ace/Timer_Queue.h">Timer_Queue.h</a></li>
+<li><a href = "../ace/Timer_Queue.inl">Timer_Queue.inl</a></li>
+<li><a href = "../ace/Timer_Queue_Adapters.cpp">Timer_Queue_Adapters.cpp</a></li>
+<li><a href = "../ace/Timer_Queue_Adapters.h">Timer_Queue_Adapters.h</a></li>
+<li><a href = "../ace/Timer_Queue_Adapters.inl">Timer_Queue_Adapters.inl</a></li>
+<li><a href = "../ace/Timer_Queue_T.cpp">Timer_Queue_T.cpp</a></li>
+<li><a href = "../ace/Timer_Queue_T.h">Timer_Queue_T.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__Queue__T.html">[doxygen]</a></b>
+<li><a href = "../ace/Timer_Queue_T.inl">Timer_Queue_T.inl</a></li>
+<li><a href = "../ace/Timer_Wheel.cpp">Timer_Wheel.cpp</a></li>
+<li><a href = "../ace/Timer_Wheel.h">Timer_Wheel.h</a></li>
+<li><a href = "../ace/Timer_Wheel_T.cpp">Timer_Wheel_T.cpp</a></li>
+<li><a href = "../ace/Timer_Wheel_T.h">Timer_Wheel_T.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Timer__Wheel__T.html">[doxygen]</a></b>
+</ul>
+<b>[Token_Service]</b>
+<ul>
+<li><a href = "../ace/Local_Tokens.cpp">Local_Tokens.cpp</a></li>
+<li><a href = "../ace/Local_Tokens.h">Local_Tokens.h</a></li>
+<li><a href = "../ace/Local_Tokens.inl">Local_Tokens.inl</a></li>
+<li><a href = "../ace/Remote_Tokens.cpp">Remote_Tokens.cpp</a></li>
+<li><a href = "../ace/Remote_Tokens.h">Remote_Tokens.h</a></li>
+<li><a href = "../ace/Remote_Tokens.inl">Remote_Tokens.inl</a></li>
+<li><a href = "../ace/Token_Collection.cpp">Token_Collection.cpp</a></li>
+<li><a href = "../ace/Token_Collection.h">Token_Collection.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Token__Collection.html">[doxygen]</a></b>
+<li><a href = "../ace/Token_Collection.inl">Token_Collection.inl</a></li>
+<li><a href = "../ace/Token_Manager.cpp">Token_Manager.cpp</a></li>
+<li><a href = "../ace/Token_Manager.h">Token_Manager.h</a></li>
+<b><a href = "http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Token__Manager.html">[doxygen]</a></b>
+<li><a href = "../ace/Token_Manager.inl">Token_Manager.inl</a></li>
+<li><a href = "../ace/Token_Request_Reply.cpp">Token_Request_Reply.cpp</a></li>
+<li><a href = "../ace/Token_Request_Reply.h">Token_Request_Reply.h</a></li>
+<li><a href = "../ace/Token_Request_Reply.inl">Token_Request_Reply.inl</a></li>
+<li><a href = "../ace/Token_Invariants.h">Token_Invariants.h</a></li>
+<li><a href = "../ace/Token_Invariants.inl">Token_Invariants.inl</a></li>
+<li><a href = "../ace/Token_Invariants.cpp">Token_Invariants.cpp</a></li>
+</ul>
+</ul>
+
+<P><HR><P>
+
+Back to the <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE-documentation.html">ACE
+documentation</A> page.
+
+<!--#include virtual="/~schmidt/cgi-sig.html" -->
+</body>
+</html>
diff --git a/ACE/docs/ACE-configuration.txt b/ACE/docs/ACE-configuration.txt
new file mode 100644
index 00000000000..50738880854
--- /dev/null
+++ b/ACE/docs/ACE-configuration.txt
@@ -0,0 +1,180 @@
+* $Id$ *
+
+================================================================
+Configuring ACE Using the `configure' Script
+================================================================
+
+QuickStart
+----------
+GNU Autoconf support in ACE is still under development. However it is
+a small subset of Autoconf support in ACE has been made available for
+testing and feedback purposes. To use Autoconf support in ACE, do
+something like the following:
+
+ cd ACE_wrappers
+ mkdir objdir
+ cd objdir
+
+Then:
+ Bourne Shell: CXX=c++ ../configure
+ C Shell: env CXX=c++ ../configure
+make
+
+Description
+-----------
+To help speed development, the work being done by the ACE
+Configuration Project is being slowly introduced into the official ACE
+distribution. Some of the functionality in the work created by the
+ACE Configuration Project has been removed so that ACE may be built in
+the usual fashion. Once the ACE Configuration Project work stabilizes
+on more platforms that removed functionality may be added to ACE.
+
+Currently the configure script contains most of the tests that are
+necessary to properly configure ACE on most platforms. However, there
+are still some autoconf tests that are missing. As such, you may
+encounter and most likely will have compilation problems. Please
+report any problems to the contacts listed at the end of this
+document.
+
+The `configure' script that is currently being used has been modified
+from the ACE Configuration Project's `configure' script to prevent
+makefiles from being automatically generated since there are still
+some issues that must be addressed before automatically generated
+makefiles are incorporated into the official ACE distribution.
+
+A listing of available configure script options can be shown by
+entering:
+
+ ./configure --help
+
+at the command line. The output should look something like the
+following:
+
+
+Usage: configure [options] [host]
+Options: [defaults in brackets after descriptions]
+Configuration:
+ --cache-file=FILE cache test results in FILE
+ --help print this message
+ --no-create do not create output files
+ --quiet, --silent do not print `checking...' messages
+ --version print the version of autoconf that created configure
+Directory and file names:
+ --prefix=PREFIX install architecture-independent files in PREFIX
+ [/usr/local]
+ --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
+ [same as prefix]
+ --bindir=DIR user executables in DIR [EPREFIX/bin]
+ --sbindir=DIR system admin executables in DIR [EPREFIX/sbin]
+ --libexecdir=DIR program executables in DIR [EPREFIX/libexec]
+ --datadir=DIR read-only architecture-independent data in DIR
+ [PREFIX/share]
+ --sysconfdir=DIR read-only single-machine data in DIR [PREFIX/etc]
+ --sharedstatedir=DIR modifiable architecture-independent data in DIR
+ [PREFIX/com]
+ --localstatedir=DIR modifiable single-machine data in DIR [PREFIX/var]
+ --libdir=DIR object code libraries in DIR [EPREFIX/lib]
+ --includedir=DIR C header files in DIR [PREFIX/include]
+ --oldincludedir=DIR C header files for non-gcc in DIR [/usr/include]
+ --infodir=DIR info documentation in DIR [PREFIX/info]
+ --mandir=DIR man documentation in DIR [PREFIX/man]
+ --srcdir=DIR find the sources in DIR [configure dir or ..]
+ --program-prefix=PREFIX prepend PREFIX to installed program names
+ --program-suffix=SUFFIX append SUFFIX to installed program names
+ --program-transform-name=PROGRAM
+ run sed PROGRAM on installed program names
+Host type:
+ --build=BUILD configure for building on BUILD [BUILD=HOST]
+ --host=HOST configure for HOST [guessed]
+ --target=TARGET configure for TARGET [TARGET=HOST]
+Features and packages:
+ --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
+ --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
+ --with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
+ --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
+ --x-includes=DIR X include files are in DIR
+ --x-libraries=DIR X library files are in DIR
+--enable and --with options recognized:
+ --enable-static[=PKGS] build static libraries [default=no]
+ --enable-shared[=PKGS] build shared libraries [default=yes]
+ --with-gnu-ld assume the C compiler uses GNU ld [default=no]
+ --disable-libtool-lock force libtool not to do file locking
+ --enable-debug enable debugging [default=yes]
+ --enable-exceptions enable C++ exception handling [default=yes]
+ --enable-fast enable -fast flag, e.g. Sun C++ [default=no]
+ --enable-inline enable code inlining [default=yes]
+ --enable-log-msg-prop enable threads inheriting
+ ACE_Log_Msg properties from parent
+ thread [default=yes]
+ --enable-logging enable ACE logging macros [default=yes]
+ --enable-malloc-stats enable malloc statistics
+ collection [default=no]
+ --enable-optimize enable additional optimizations [default=yes]
+ --enable-probe enable ACE_Timeprobes [default=no]
+ --enable-profile enable profiling [default=no]
+ --enable-purify Purify all executables [default=no]
+ --enable-quantify Quantify all executables [default=no]
+ --enable-reentrant enable reentrant functions [default=yes]
+ --enable-repo use GNU template repository
+ GNU C++ with repo patches and
+ EGCS only [default=no]
+ --enable-rtti enable run-time type
+ identification
+ *Currently only for Sun C++ [default=no]
+ --enable-static-obj-mgr enable static Object_Manager [default=yes]
+ --enable-threads enable thread support [default=yes]
+ --enable-verb-not-sup enable verbose ENOTSUP reports [default=no]
+ --enable-trace enable ACE tracing [default=no]
+ --enable-xt-reactor build support for the XtReactor [default=no]
+ --with-x use the X Window System
+ --with-gperf compile the gperf program [default=yes]
+ --with-tli-device[=DEV] device for TCP on TLI [default=/dev/tcp]
+
+To enable debugging and disable code inlining, for example, just enter
+the following on the command line:
+
+ ./configure --enable-debug --disable-inline
+
+This will generate a configuration header file `ace/config.h' to be
+used when compiling ACE that will enable ACE debugging macros and
+disable code inlining during compilation of ACE.
+
+Once the `ace/config.h' header has been created you will have to
+select a platform macros file. Please read the ACE installation
+documents for more information about this.
+
+----------------------------------------------------------------
+Caveats
+----------------------------------------------------------------
+The `configure' script will check for libraries that contain certain
+functions. If it finds a library that isn't listed in your
+platform_macros.GNU file you will have to add that library to the list
+of libraries to link against.
+
+Shared library generation when using ACE Autoconf support is different
+from the stock ACE shared library generation mechanism. The Autoconf
+supported shared library mechanism does not yet fully support all of
+the platforms ACE's stock shared library mechanism supports. As such,
+you may encounter problems if an attempt is made to build a shared
+library when using ACE's autoconf support.
+
+Remember that the stock ACE build procedure is always available. If
+your attempts to use ACE's Autoconf support are unsuccessful then
+contact the parties listed below, and use ACE stock build procedure as
+described in ACE-INSTALL.html.
+
+----------------------------------------------------------------
+Contacts
+----------------------------------------------------------------
+If you do have problems please e-mail the ACE Configuration Project
+maintainer at:
+
+ Ossama Othman <ossama@uci.edu>
+
+or send mail to the ACE mailing list.
+
+For more information take at a look at the ACE Configuration Project
+web page at:
+
+ http://www.cs.wustl.edu/~othman/aceconf
+
diff --git a/ACE/docs/ACE-development-process.html b/ACE/docs/ACE-development-process.html
new file mode 100644
index 00000000000..8a67701ed7c
--- /dev/null
+++ b/ACE/docs/ACE-development-process.html
@@ -0,0 +1,181 @@
+<!-- $Id$ -->
+
+<html>
+ <head>
+ <title>ACE+TAO Development and Release Process</title>
+ <link rev=made href="mailto:levine@cs.wustl.edu">
+ </head>
+
+<body text = "#000000"
+link="#000fff"
+vlink="#ff0f0f"
+bgcolor="#ffffff">
+
+<hr>
+<h3>The ACE+TAO Development and Release Process</h3>
+
+To improve the quality of our software and minimize development
+effort, we try to follow the structured development and release
+process described below.<p>
+
+An important concept to keep in mind is <em>risk</em>. Before you
+commit <em>any</em> change to ACE+TAO, please consider the effects
+that it will have. Could it possibly cause a build failure, on any
+platform? Could it possibly cause different run-time behavior? And
+so on. If so, it is your responsibility to adequately build and test
+with the change, in order to verify that it has no unintended
+effects.<p>
+
+Please keep in mind the cost of committing a mistake. It may take you
+only a few seconds to fix, but its cost to the group may be much
+larger. With our large group, workspace updates and builds are likely
+to happen at any time. If one break, it can take hours to rebuild it.
+And each developer that was waiting for a successful build would be
+blocked for the duration of the broken build, the fix, and the
+rebuild.<p>
+
+<hr>
+<h3>The ACE+TAO+CIAO Development Process</h3>
+
+The ACE+TAO+CIAO development process looks like:<p>
+<ol>
+ <li>Every change to ACE+TAO must have a bug report. <em>Change</em>
+ includes fixes, enhancements, updates, and so on.
+ <li><a href="http://deuce.doc.wustl.edu/bugzilla/index.cgi">Create a
+bug report</a>.
+ <li>Accept the bug report if you are going to implement the change.
+ <li>Implement the change in your workspace(s).
+ <li>Test the change sufficiently to demonstrate that it both does
+ what is intended, and doesn't break anything. The test may be
+ as simple as building and running the ACE+TAO tests on one platform.
+ Or as complicated as rebuilding and test all of ACE+TAO on
+ all platforms that we have.
+ <li>Create an appropriate ChangeLog entry.
+ <li>Commit the change using a ChangeLogTag commit message.
+ <li>Respond to the requester of the change, if any. Please do this
+ <em>after</em> committing your change.
+ <li>Make sure that the requester is listed in the THANKS file.
+ <li>Update the bug report to indicate resolution.
+ <li>Monitor the next round of build/tests for problems with your change.
+ <li>Respond immediately to reports of problems with your changes.
+</ol>
+
+<p><hr>
+<H3>Bug Lifecycles</H3>
+<P>
+
+A bug should typically follow this life cycle:<p>
+<center><table cellpadding=5 border=0>
+<tr>
+ <td>Submitter:</td>
+ <td>Enters problem</td>
+<tr>
+ <td>Bugmaster:</td>
+ <td>Assigns</td>
+<tr>
+ <td>Owner:</td>
+ <td>Accepts</td>
+<tr>
+ <td>Owner:</td>
+ <td>Reproduces problem - if it needs a new test, write it and
+ put it in the regression tests.
+ If it can't be reproduced, set to Resolved/CANT_FIND.<br>
+ If it's a duplicate, set it to Resolved/DUPLICATE.
+ Fix code, commit changes, set to Resolved.</td>
+<tr>
+ <td>Submitter:</td>
+ <td>Tests it again; set to Verified (pass) or Reopened (fail)</td>
+<tr>
+ <td>Owner:</td>
+ <td>After next release is done, re-test; sets to Closed or Reopened.</td>
+</table></center>
+
+<p><hr>
+<H3>The Role of the Build Czar</H3>
+<P>
+
+At all times, we'll have a build czar. The role may be shared by
+multiple people. The build czar is responsible for ensuring that the
+next kits are clean, <em>i.e.</em>, it builds and runs cleanly on all
+platforms. The status of all ACE+TAO builds is tracked automatically
+<A HREF="http://tao.doc.wustl.edu/scoreboard/"</A>online</A>.<p>
+
+A comprehensive summary of the build czar's role is available <A HREF="http://www.cs.wustl.edu/~bugzilla/">online</A>.
+This role is briefly summarized below:<p>
+<ul>
+ <li>Remind people to check build logs. Developers are still
+ responsible for verifying that their changes are clean.
+ <li>Fix minor problems caused by compilation errors. More complex
+ problems should be fixed by the developers who caused them. The
+ build czar should help track down the guilty parties.
+ <li>Freeze the CVS repository when it's decided to no more
+ non-critical changes will be accepted for the next kits.
+ The build czar has the final say over when the freeze is
+ implemented. The tendency to implement a freeze sooner than
+ later is intentional, desirable, beneficial, and the "Right Thing"[TM]
+ to do.
+ <li>Verifies that the final round of builds/tests are clean.
+ <li>Creates the kits.
+ <li>Unfreezes the CVS repository.
+ <li>Sends email to appropriate news groups announcing the new kits.
+ <li>Passes the mantle on to the next build czar.<p>
+</ul>
+
+If another developer interferes with the build czar's duties, the
+build czar has the unilateral authority to pass the mantle to the
+violator. This is also intentional, desirable, beneficial, and the
+Right Thing[TM] to do.<p>
+
+<p><hr>
+<H3>The ACE+TAO+CIAO Release Process</H3>
+<P>
+
+Minor releases of ACE+TAO+CIAO occur periodically, typically twice a
+year. Minor releases have two-digit numbers, <EM>e.g.,</EM> 5.3.
+Major releases are released infrequently, typically once a year.
+Major releases are 1-digit numbers, <EM>e.g.,</EM>5, that include
+substantially new functionality. Both major and minor releases are
+carefully tested on all platforms the ACE+TAO run on. In particular,
+we do not put out major or minor releases of ACE+TAO+CIAO until all the
+compilations and regression tests work successful on all the platform
+we support. <P>
+
+Between major/minor releases, we release betas periodically,
+<EM>e.g.,</EM> once a month, so that ACE+TAO+CIAO users can download
+and test our latest work in progress. ACE+TAO+CIAO beta kits have
+three-digit numbers, <EM>e.g.,</EM> 5.3.1. Betas are often not as
+stable as the major or minor releases, but they often contain
+important fixes that aren't in the official releases. Although we try
+to ensure the quality of betas, they may not compile cleanly on all
+platforms, nor will they necessarily pass all of the tests on all
+platforms. They will, however, compile cleanly and pass most tests on
+most platforms. As usual, we endeavor to fix any problems that arise
+as quickly as possible. Naturally, if you require 100% predictable
+stability and support, please contact one of the companies that
+provides <A
+HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html">
+commercial support</A> for ACE+TAO.<P>
+
+The first beta following a major/minor release is called a
+<EM>bug-fix-only</EM> (BFO) beta. As the name implies this beta will
+have only fixes for the major or minor releases just made. Types of
+fixes and checkins that are allowed to go in for the BFO include, bug
+fixes in the implementation, fixes to the build systems like
+Makefiles, project files, and MPC files, adding new tests and
+examples, fixes to the documentation etc. Fixes that are definitely
+not allowed include, changes to the public interface, refactoring
+implementations, removing files from the repository, adding new files
+into the repository etc. The idea is to allow commercial support
+vendors to stabilize the major or minor release for their product
+offerings. <p>
+
+<hr><p>
+ <font size=-1>
+ Last modified
+<!--#echo var="LAST_MODIFIED" -->.<p>
+ </font><hr>
+
+Back to <A HREF="index.html">ACE Documentation Home</A>.
+
+</body>
+</html>
diff --git a/ACE/docs/ACE-guidelines.html b/ACE/docs/ACE-guidelines.html
new file mode 100644
index 00000000000..834b6dcaeea
--- /dev/null
+++ b/ACE/docs/ACE-guidelines.html
@@ -0,0 +1,1328 @@
+<!-- $Id$ -->
+
+<html>
+ <head>
+ <title>ACE Software Development Guidelines</title>
+ <link rev=made href="mailto:ace-users@cs.wustl.edu">
+ </head>
+
+<body text = "#000000"
+link="#000fff"
+vlink="#ff0f0f"
+bgcolor="#ffffff">
+
+<hr>
+<h3>ACE Software Development Guidelines</h3>
+
+<ul>
+ <li><strong>General</strong><p>
+ <ul>
+ <li>Every text file must end with a newline.<p>
+
+ <li>Use spaces instead of tabs, except in Makefiles. Emacs users
+ can add this to their <strong>.emacs</strong>:
+
+ <pre>(setq-default indent-tabs-mode nil)</pre></p>
+
+ Microsoft Visual C++ users should do the following:
+
+ <pre>
+ Choose: Tools -- Options -- Tabs
+ Then Set: "Tab size" to 8 and "Indent size" to 2, and
+ indent using spaces.
+ </pre><p>
+
+ <li>Do not end text lines with spaces. Emacs users can add this to
+ their <strong>.emacs</strong>:
+
+ <pre>(setq-default nuke-trailing-whitespace-p t)</pre>
+
+ <strong>Note for Microsoft Visual Studio .NET Users:</strong>
+ <p>There is a macro project <code>(ace_guidelines.vsmacros)</code>
+ located in <code>$ACE_ROOT/docs</code> that replaces tabs with spaces
+ and removes trailing spaces each time you save a file.</p>
+
+ <li>Try to limit the length of source code lines to less than 80
+ characters. Users with 14 inch monitors appreciate it when
+ reading code. And, it avoids mangling problems with email
+ and net news.<p>
+
+ <li>Try to avoid creating files with excessively long names (45 characters).
+ Moreover, ensure that the names of generated files e.g. <code>MakeProjectCreator</code>,
+ <code>tao_idl</code> do not also go beyond that limit. Some operating
+ systems cannot handle very long file names correctly.<p>
+
+ <li>If you add a comment to code that is directed to, or
+ requires the attention of, a particular individual:
+ <strong>SEND EMAIL TO THAT INDIVIDUAL!</strong>.<p>
+
+ <li>Every program should have a "usage" message. It should be
+ printed out if erroneous command line arguments, or a
+ <strong><code>-?</code></strong> command line argument, are
+ provided to the program.<p>
+
+ <li>A program entry point <code>main</code> can take any of the
+ three forms:
+ <p><pre>
+ int main (int argc, char *argv[])
+ int wmain (int argc, wchar_t *argv[])
+ int ACE_TMAIN (int argc, ACE_TCHAR *argv[])
+ </pre></p>
+ Of them, the entry point <code>main</code> always gives you
+ the command line argument in char strings form. The entry
+ point <code>wmain</code> currently can only be used under
+ Win32 and it returns the command line arguments in <code>wchar</code>
+ strings format. Defining the <code>ACE_TMAIN</code> as the
+ program entry point is the more portable form. The command
+ line arguments are given in char strings in most cases,
+ or <code>wchar</code> strings when <code>ACE_USES_WCHAR</code> is defined.
+ See <code>$ACE_ROOT/docs/wchar.txt</code> for more information
+ on ACE support on <code>wchar</code>.<p>
+
+ <li>The program entry point function, in any form mentioned above, must
+ always be declared with arguments, <em>e.g.</em>,
+ <pre>
+ int
+ ACE_TMAIN (int argc, ACE_TCHAR *argv[])
+ {
+ [...]
+
+ return 0;
+ }
+ </pre><p>
+
+ If you don't use the <code>argc</code> and/or <code>argv</code>
+ arguments, don't declare them, <em>e.g.</em>,
+ <pre>
+ int
+ ACE_TMAIN (int, ACE_TCHAR *[])
+ {
+ [...]
+
+ return 0;
+ }
+ </pre><p>
+
+ Please declare the second argument as <code>ACE_TCHAR *[]</code>
+ instead of <code>ACE_TCHAR **</code> or <code>char *[]</CODE>.
+ Ancient versions of MSC++
+ complained about <code>ACE_TCHAR **</code> and <code>char
+ *[]</CODE> is not Unicode-compliant.<p>
+
+ <code>main</code> must also return 0 on successful
+ termination, and non-zero otherwise.<p>
+
+ <li>Avoid use of floating point types (<code>float</code> and
+ <code>double</code>) and operations
+ unless absolutely necessary. Not all ACE platforms support them.
+ Therefore, wherever they are used, <code>ACE_LACKS_FLOATING_POINT</code>
+ conditional code must be also be used.<p>
+
+ <li>Avoid including the string "<code>Error</code>" in a source
+ code filename. GNU Make's error messages start with
+ "<code>Error</code>". So, it's much easier to search for
+ errors if filenames don't contain "<code>Error</code>".<p>
+
+
+ <li>Narrow interfaces are better than wide interfaces. If there
+ isn't a need for an interface, leave it out. This eases maintenance,
+ minimizes footprint, and reduces the likelihood of interference
+ when other interfaces need to be added later. (See the
+ <a href="#ACE_Time_Value example">ACE_Time_Value</a> example
+ .<p>
+
+ <li> Never use <CODE>assert()</CODE> macros or related constructs
+ (such as abort()) calls in core ACE, TAO, and CIAO
+ library/framework code. These macros are a major problem for
+ production software that uses this code since the
+ error-handling strategy (i.e., abort the process) is
+ excessive. Instead, extract out the expressions from
+ assert() macros and use them as
+ precondition/postconditions/invariants in the
+ software and return any violations of these
+ conditions/invariants via exceptions or error return values.
+ It's fine to use <CODE>assert()</CODE> macros et al. in test
+ programs, but make sure these tests never find their way into
+ the core ACE, TAO, and CIAO library/framework code base. <P>
+
+ </ul>
+
+ <li><strong>Code Documentation</strong><p>
+ <ul>
+ <li>Use comments and whitespace (:-) liberally. Comments
+ should consist of complete sentences, <em>i.e.</em>, start
+ with a capital letter and end with a period.<p>
+
+ <li>Insert a CVS/RCS keyword string at the top of every source file,
+ Makefile, config file, <em>etc</em>. For C++ files, it is:
+ <pre>
+ // $<!-- -->Id$
+ </pre>
+ It is not necessary to fill in the fields of the keyword string,
+ or modify them when you edit a file that already has one. CVS
+ does that automatically when you checkout or update the file.<p>
+
+ To insert that string at the top of a file:
+ <pre>
+ perl -pi -e \
+ 'if (! $o) {printf "// \$<!-- -->Id\$\n\n";}; $o = 1;' <em>file</em>
+ </pre><p>
+
+ <li>Be sure to follow the guidelines and restrictions for use of the
+ documentation tools for ACE
+ header files, which must follow the
+ <a href="http://www.doxygen.org/">Doxygen</a>
+ format requirements.
+ The complete documentation for Doxygen is available in the
+ <a href="http://www.stack.nl/~dimitri/doxygen/download.html#latestman">Doxygen
+ manual</a>.
+ For an example header file using Doxygen-style comments,
+ please refer to <a href="../ace/ACE.h">ACE.h</a>.<p>
+
+ <LI>All binary options for ACE and TAO should be specified in
+ terms of the integral values 0 and 1, rather than "true" and
+ "false" or "yes" and "no". All TAO options should be
+ documented in the <A HREF="../TAO/docs/Options.html">online
+ TAO options document</A>. <P>.
+
+ </ul>
+
+ <li><strong>Preprocessor</strong><p>
+ <ul>
+ <li>Never #include standard headers directly, except in a few
+ specific ACE files, <em>e.g.</em>, OS.h and stdcpp.h. Let
+ those files #include the correct headers. If you do not do
+ this, your code will not compile with the Standard C++ Library.<p>
+
+ <li>Always follow a preprocessor <strong><code>#endif</code></strong>
+ with a <strong><code>/* */</code></strong> C-style comment. It
+ should correspond to the condition in the matching
+ <strong><code>#if</code></strong> directive. For example,
+ <pre>
+ #if defined (ACE_HAS_THREADS)
+ # if defined (ACE_HAS_STHREADS)
+ # include /**/ &lt;synch.h&gt;
+ # include /**/ &lt;thread.h&gt;
+ # define ACE_SCOPE_PROCESS P_PID
+ # define ACE_SCOPE_LWP P_LWPID
+ # define ACE_SCOPE_THREAD (ACE_SCOPE_LWP + 1)
+ # else
+ # define ACE_SCOPE_PROCESS 0
+ # define ACE_SCOPE_LWP 1
+ # define ACE_SCOPE_THREAD 2
+ # endif /* ACE_HAS_STHREADS */
+ #endif /* ACE_HAS_THREADS */
+ </pre><p>
+
+ <li>Be sure to put spaces around comment delimiters, e.g.,
+ <strong><code>char * /* foo */</code></strong> instead of
+ <strong><code>char */*foo*/</code></strong>. MS VC++
+ complains otherwise.<p>
+
+ <li>Always insert a <strong><code>/**/</code></strong> between an
+ <strong><code>#include</code></strong> and
+ <strong><code>filename</code></strong>, for system headers and
+ <strong><code>ace/pre.h</code></strong> and
+ <strong><code>ace/post.h</code></strong> as
+ shown in the above example. This avoids dependency problems
+ with Visual C++ and prevents Doxygen from including the
+ headers in the file reference trees. <p>
+
+ <li>Be very careful with names of macros, <code>enum</code> values, and variables
+ It's always best to prefix them with something like <code>ACE_</code>
+ or <code>TAO_</code>. There are too many system headers out
+ there that <code>#define</code> <code>OK</code>, <code>SUCCESS</code>,
+ <code>ERROR</code>, <code>index</code>, <code>s_type</code>,
+ and so on.<p>
+
+ <li>When using macros in an arithmetic expression, be sure to test
+ that the macro is defined, using <code>defined(<em>macro</em>)</code> before specifying
+ the expression. For example:
+<pre>
+#if __FreeBSD__ &lt; 3
+</pre>
+
+will evaluate true on any platform where <code>__FreeBSD__</code> is
+not defined. The correct way to write that guard is:
+<pre>
+#if defined (__FreeBSD__) && __FreeBSD__ &lt; 3
+</pre>
+
+If using g++, problems like this can be flagged as a warning by using the "<code>-Wundef</code>" command line option.
+
+ <li>Try to centralize <code>#ifdef</code>s with <code>typedef</code>s
+ and <code>#define</code>s. For example, use this:
+ <pre>
+ #if defined(ACE_PSOS)
+ typedef long ACE_NETIF_TYPE;
+ # define ACE_DEFAULT_NETIF 0
+ #else /* ! ACE_PSOS */
+ typedef const TCHAR* ACE_NETIF_TYPE;
+ # define ACE_DEFAULT_NETIF ASYS_TEXT("le0")
+ #endif /* ! ACE_PSOS */
+ </pre><p>
+
+ instead of:
+
+ <pre><p>
+ #if defined (ACE_PSOS)
+ // pSOS supports numbers, not names for network interfaces
+ long net_if,
+ #else /* ! ACE_PSOS */
+ const TCHAR *net_if,
+ #endif /* ! ACE_PSOS */
+ </pre><p>
+
+ <li>Protect header files against multiple inclusion with this
+ construct:
+ <pre>
+ #ifndef FOO_H
+ #define FOO_H
+
+ [contents of header file]
+
+ #endif /* FOO_H */
+ </pre><p>
+
+ This exact construct (note the <code>#ifndef</code>)
+ is optimized by many compilers such they only open the
+ file once per compilation unit. Thanks to Eric C. Newton
+ &lt;ecn@smart.net&gt; for pointing that out.<p>
+
+ If the header <code>#include</code>s an ACE library header,
+ then it's a good idea to include the <code>#pragma once</code>
+ directive:
+ <pre>
+ #ifndef FOO_H
+ #define FOO_H
+
+ #include "ace/ACE.h"
+ #if !defined (ACE_LACKS_PRAGMA_ONCE)
+ # pragma once
+ #endif /* ACE_LACKS_PRAGMA_ONCE */
+
+ [contents of header file]
+
+ #endif /* FOO_H */
+ </pre><p>
+
+ <code>#pragma once</code> must be protected, because some
+ compilers complain about it. The protection depends on
+ <code>ACE_LACKS_PRAGMA_ONCE</code>, which is defined in
+ some ACE config headers. Therefore, the protected
+ <code>#pragma once</code> construct should only be used after
+ an <code>#include</code> of an ACE library header. Note that
+ many compilers enable the optimization if the <code>#ifndef</code>
+ protection construct is used, so for them, <code>#pragma once</code>
+ is superfluous.<p>
+
+ <strong>No</strong> code can appear after the final
+ <code>#endif</code> for the optimization to be effective and
+ correct.<p>
+
+ <li><p>Files that contain parametric classes should follow this style:
+ <pre>
+ #ifndef FOO_T_H
+ #define FOO_T_H
+
+ #include "ace/ACE.h"
+ #if !defined (ACE_LACKS_PRAGMA_ONCE)
+ # pragma once
+ #endif /* ACE_LACKS_PRAGMA_ONCE */
+
+ // Put your template declarations here...
+
+ #if defined (__ACE_INLINE__)
+ #include "Foo_T.inl"
+ #endif /* __ACE_INLINE__ */
+
+ #if defined (ACE_TEMPLATES_REQUIRE_SOURCE)
+ #include "Foo_T.cpp"
+ #endif /* ACE_TEMPLATES_REQUIRE_SOURCE */
+
+ #if defined (ACE_TEMPLATES_REQUIRE_PRAGMA)
+ #pragma implementation "Foo_T.cpp"
+ #endif /* ACE_TEMPLATES_REQUIRE_PRAGMA */
+
+ #endif /* FOO_T_H */
+</pre></p>
+ <p>
+ Notice that some compilers need to see the code of the template,
+ hence the <code>.cpp</code> file must be included from the
+ header file.
+ </p>
+ <p>
+ To avoid multiple inclusions of the <code>.cpp</code> file it
+ should also be protected as in:
+ <pre>
+ #ifndef FOO_T_CPP
+ #define FOO_T_CPP
+
+ #include "Foo_T.h"
+ #if !defined (ACE_LACKS_PRAGMA_ONCE)
+ # pragma once
+ #endif /* ACE_LACKS_PRAGMA_ONCE */
+
+ #if !defined (__ACE_INLINE__)
+ #include "ace/Foo_T.inl"
+ #endif /* __ACE_INLINE__ */
+
+ // put your template code here
+
+ #endif /* FOO_T_H */
+</pre></p>
+ <p>Finally, you may want to include the template header file from a
+ non-template header file (check
+ <code>$ACE_ROOT/ace/Synch.h</code>); in such a case the template
+ header should be included <strong>after</strong> the inline
+ function definitions, as in:</p>
+ <p><pre>
+ #ifndef FOO_H
+ #define FOO_H
+
+ #include "ace/ACE.h"
+ #if !defined (ACE_LACKS_PRAGMA_ONCE)
+ # pragma once
+ #endif /* ACE_LACKS_PRAGMA_ONCE */
+
+ // Put your non-template declarations here...
+
+ #if defined (__ACE_INLINE__)
+ #include "Foo.inl"
+ #endif /* __ACE_INLINE__ */
+
+ #include "Foo_T.h"
+
+ #endif /* FOO_H */
+</pre></p></li>
+
+ <li>Avoid <code>#include &lt;math.h&gt;</code> if at all possible.
+ The <code>/usr/include/math.h</code> on SunOS 5.5.1 through 5.7
+ defines a struct name <strong>exception</strong>, which complicates
+ use of exceptions.<p>
+
+ <li>On a <code>.cpp</code> file always include the corresponding
+ header file <em>first</em>, like this:<p>
+<pre>
+ // This is Foo.cpp
+
+ #include "Foo.h"
+ #include "tao/Bar.h"
+ #include "ace/Baz.h"
+
+ // Here comes the Foo.cpp code....
+</pre><p>
+
+ In this way we are sure that the header file is self-contained
+ and can be safely included from some place else.
+
+ <li>In the TAO library <strong>never</strong> include
+ <code>&lt;corba.h&gt</code>, this file should only be included
+ by the user and introduces cyclic dependencies in the library
+ that we must avoid.<p>
+
+ <li>Never include a header file when a forward reference will do,
+ remember that templates can be forward referenced too.
+ Consult your favorite C++ book to find out when you must include
+ the full class definition.<p>
+ </ul>
+
+ <li><strong>C++ Syntax and Constructs</strong><p>
+ <ul>
+ <li><strong><code>for</code></strong> loops should look like:
+ <pre>
+ for (unsigned int i = 0; i &lt; count; ++i)
+ ++total;
+ </pre>
+ Though, I prefer to always wrap the body of the loop in braces,
+ to avoid surprises when other code or debugging statements are
+ added, and to maintain sanity when the body consists of a macro,
+ such as an <code>ACE_ASSERT</code> without a trailing semicolon:
+ <pre>
+ for (unsigned int i = 0; i &lt; count; ++i)
+ {
+ ACE_ASSERT (++total &lt; UINT_MAX;)
+ }
+ </pre><p>
+
+ Similarly, <strong><code>if</code></strong> statements should have
+ a space after the "<strong>if</strong>", and no spaces just after
+ the opening parenthesis and just before the closing parenthesis.<p>
+
+ <li>If a loop index is used after the body of the loop, it
+ <strong>must</strong> be declared before the loop. For example,
+
+ <pre>
+ size_t i = 0;
+ for (size_t j = 0; file_name [j] != '\0'; ++i, ++j)
+ {
+ if (file_name [j] == '\\' && file_name [j + 1] == '\\')
+ ++j;
+
+ file_name [i] = file_name [j];
+ }
+
+ // Terminate this string.
+ file_name [i] = '\0';
+ </pre><p>
+
+ <li>Prefix operators are generally more efficient than postfix
+ operators. Therefore, they are preferred over their postfix
+ counterparts where the expression value is not used.<p>
+
+ Therefore, use this idiom for iterators, with prefix operator
+ on the loop index:
+ <pre>
+ ACE_Ordered_MultiSet&lt;int&gt; set;
+ ACE_Ordered_MultiSet_Iterator&lt;int&gt; iter(set);
+
+ for (i = -10; i &lt; 10; ++i)
+ set.insert (2 * i + 1);
+
+ </pre>
+ rather than the postfix operator:
+ <pre>
+ for (i = -10; i &lt; 10; i++)
+ set.insert (2 * i + 1);
+ </pre><p>
+
+ <li>Prefer using <strong> <code> if (...) else .... </code> </strong>
+ instead of <strong> <code> ?: </code> </strong> operator. It is a lot
+ less error prone, and will help you avoid bugs caused due to the
+ precedence of <strong> <code> ?: </code> </strong>, compared with other
+ operators in an expression.
+
+ <li>When a class provides <code>operator==</code>, it must also provide
+ <code>operator!=</code>. Also, both these operators must be
+ <code>const</code> and return <code>bool</code>.
+
+ <li>Avoid unnecessary parenthesis. We're not writing Lisp :-)<p>
+
+ <li>Put inline member functions in a <strong><code>.inl</code></strong>
+ file. That file is conditionally included by both the
+ <strong><code>.h</code></strong> file, for example:<p>
+
+ <pre>
+ class ACE_Export ACE_High_Res_Timer
+ {
+ [...]
+ };
+
+ #if defined (__ACE_INLINE__)
+ #include "ace/High_Res_Timer.inl"
+ #endif /* __ACE_INLINE__ */
+ </pre><p>
+
+ and <strong><code>.cpp</code></strong> file:<p>
+
+ <pre>
+ #define ACE_BUILD_DLL
+ #include "ace/High_Res_Timer.h"
+
+ #if !defined (__ACE_INLINE__)
+ #include "ace/High_Res_Timer.inl"
+ #endif /* __ACE_INLINE__ */
+
+ ACE_ALLOC_HOOK_DEFINE(ACE_High_Res_Timer)
+ </pre><p>
+
+ <strong>NOTE:</strong> It is very important to ensure than an
+ inline function will not be used before its definition is seen.
+ Therefore, the inline functions in the .inl file should be arranged
+ properly. Some compilers, such as <code>g++</code> with the
+ <code>-Wall</code> option, will issue warnings for violations.<p>
+
+ <li>Some inlining heuristics:<p>
+ <ul>
+ <li>One liners should almost always be inline, as in:
+<pre>
+ACE_INLINE
+Foo::bar ()
+{
+ this-&gt;baz ();
+}
+</pre><p>
+
+ <li>The notable exception is virtual functions, which should
+ generally not be inlined.<p>
+
+ <li>Big (more than 10 lines) and complex function (more than one if ()
+ statement, or a switch, or a loop) should not be inlined.<p>
+
+ <li>Medium sized stuff depends on how performance critical it is.
+ If you know that it's in the critical path, then make it
+ inline. When in doubt, profile the code.<p>
+ </ul>
+
+ <li><code>ACE_Export</code> must be inserted between the
+ <code>class</code> keyword and class name for all classes that
+ are exported from libraries, as shown in the example above.
+ <strong>However</strong>, do <strong>not</strong> use
+ <code>ACE_Export</code> for template classes or classes that
+ are not used out of the ACE library, for example.!<p>
+
+ <li>Mutators and accessors should be of this form:<p>
+
+ <pre>
+ void object_addr (const ACE_INET_Addr &);
+ // Sets &lt;object_addr_&gt; cache from &lt;host&gt; and &lt;port&gt;.
+
+ const ACE_INET_Addr &object_addr const (void);
+ // Returns the &lt;ACE_INET_Addr&gt; for this profile.
+ </pre><p>
+
+ instead of the "set_" and "get_" form.<p>
+
+ <li>Never use <strong><code>delete</code></strong> to deallocate
+ memory that was allocated with <strong><code>malloc</code></strong>.
+ Similarly, never associate <strong><code>free</code></strong> with
+ <strong><code>new</code></strong>.
+ <strong><code>ACE_NEW</code></strong> or
+ <strong><code>ACE_NEW_RETURN</code></strong> should be used to
+ allocate memory, and <strong><code>delete</code></strong> should
+ be used to deallocate it. And be careful to use the correct form,
+ <strong><code>delete</code></strong> or
+ <strong><code>delete []</code></strong> to correspond to the
+ allocation.<p>
+
+ <li>Don't check for a pointer being 0 before deleting it. It's
+ always safe to delete a 0 pointer. If the pointer is visible
+ outside the local scope, it's often a good idea to 0 it
+ _after_ deleting it. Note, the same argument applies to
+ free().<p>
+
+ <li>Always use <strong><code>ACE_NEW</code></strong> or
+ <strong><code>ACE_NEW_RETURN</code></strong> to allocate memory,
+ because they check for successful allocation and set errno
+ appropriately if it fails.<p>
+
+ <li>Never compare or assign a pointer value with <strong>NULL</strong>;
+ use <strong>0</strong> instead. The language allows any pointer to
+ be compared or assigned with <strong>0</strong>. The definition
+ of <strong>NULL</strong> is implementation dependent, so it is
+ difficult to use portably without casting.<p>
+
+ <li>Never cast a pointer to or from an <strong><code>int</code></strong>.
+ On all currently supported ACE platforms, it is safe to cast
+ a pointer to or from a <strong><code>long</code></strong>.<p>
+
+ <li>Be very careful when selecting an integer type that must be a
+ certain size, <em>e.g.</em>, 4 bytes. <strong>long</strong> is
+ not 4 bytes on all platforms; it is 8 bytes on many 64-bit
+ machines. ACE_UINT32 is always 4 bytes, and ACE_UINT64 is
+ always 8 bytes.<p>
+
+ <li>If a class has any virtual functions, and its destructor is
+ declared explicitly in the class, then the destructor should
+ <strong>always</strong> be virtual as well. And to support
+ compiler activities such as generation of virtual tables and,
+ in some cases, template instantiation, the virtual destructor
+ should <strong>not be inline</strong>. (Actually, any non-pure
+ virtual function could be made non-inline for this purpose. But,
+ for convenience, if its performance is not critical, it is usually
+ easiest just to make the virtual destructor non-inline.)<p>
+
+
+ <li><a name="ACE_Time_Value example">Avoid default arguments</a>
+ unless there's a good reason. For an example of how they got
+ us into a jam is:
+ <pre>
+ ACE_Time_Value (long sec, long usec = 0);
+ </pre>
+
+ So, <code>ACE_Time_Value (2.5)</code> has the unfortunate
+ effect of coercing the 2.5 to a long with value 2. That's
+ probably not what the programmer intended, and many compilers
+ don't warn about it.<p>
+
+ A nice fix would be to add an <code>ACE_Time_Value (double)</code>
+ constructor. But, that would cause ambiguous overloading
+ due to the default value for the second argument of
+ <code>ACE_Time_Value (long sec, long usec = 0)</code>.
+ We're stuck with <code>ACE_Time_Value</code>, but now we
+ know that it's easy to avoid.<p>
+
+ <li>Constructor initializers must appear in the same order as
+ the data members are declared in the class header. This avoids
+ subtle errors, because initialization takes place in the order
+ of member declaration.<p>
+
+ <li>Initialization is usually cleaner than assignment, especially
+ in a conditional. So, instead of writing code like this:
+
+ <pre>
+ ssize_t n_bytes;
+
+ // Send multicast of one byte, enough to wake up server.
+ if ((n_bytes = multicast.send ((char *) &reply_port,
+ sizeof reply_port)) == -1)
+ </pre>
+
+ Write it like this:
+
+ <pre>
+ ssize_t n_bytes = multicast.send ((char *) &reply_port,
+ sizeof reply_port)
+
+ // Send multicast of one byte, enough to wake up server.
+ if (n_bytes == -1)
+ </pre><p>
+
+ But, beware if the initialization is of a static variable.
+ A static variable is only initialized the first time its
+ declaration is seen. Of course, we should avoid using
+ static (and non-constant) variables at all.<p>
+
+ <li>It is usually clearer to write conditionals that have
+ both branches without a negated condition. For example,<p>
+
+ <pre>
+ if (test)
+ {
+ // true branch
+ }
+ else
+ {
+ // false branch
+ }
+ </pre><p>
+
+ is preferred over:<p>
+
+ <pre>
+ if (! test)
+ {
+ // false test branch
+ }
+ else
+ {
+ // true test branch
+ }
+ </pre><p>
+
+ <li>If a cast is necessary, avoid use of C-style "sledgehammer"
+ casts. Use standard C++ casts
+ (e.g. <code>static_cast&lt;int&gt; (foo)</code>) instead.<p>
+
+ <li>In general, if instances of a class should not be copied,
+ then a private copy constructor and assignment operator should
+ be declared for the class, but not implemented. For example:
+
+ <pre>
+ // Disallow copying by not implementing the following . . .
+ ACE_Object_Manager (const ACE_Object_Manager &);
+ ACE_Object_Manager &operator= (const ACE_Object_Manager &);
+ </pre><p>
+
+ If the class is a template class, then the
+ <code>ACE_UNIMPLEMENTED_FUNC</code> macro should be used:
+
+ <pre>
+ // = Disallow copying...
+ ACE_UNIMPLEMENTED_FUNC (ACE_TSS (const ACE_TSS&lt;TYPE&gt; &))
+ ACE_UNIMPLEMENTED_FUNC (void operator= (const ACE_TSS&lt;TYPE&gt; &))
+ </pre><p>
+
+ <code>ACE_UNIMPLEMENTED_FUNC</code> can be used with non-template
+ classes as well. Though for consistency and maximum safety, it
+ should be avoided for non-template classes.<p>
+
+ <li>Never use <code>BOOL</code>, or similar types.
+ (<code>ACE_CDR::Boolean</code> and
+ <code>CORBA::Boolean</code> are acceptable). Use the
+ standard C++ <code>bool</code> for boolean variables, instead.<p>
+
+ <li>Functions should always return -1 to indicate failure, and
+ 0 or greater to indicate success.<p>
+
+ <li>Separate the code of your templates from the code for
+ non-parametric classes: some compilers get confused when
+ template and non-template code is mixed in the same file.<p>
+
+ <li>It's a good idea to specify the include path (with <code>-I</code>)
+ to include any directory which contains files with template
+ definitions. The Compaq Tru64 cxx <code>-ptv</code> compiler option
+ may help diagnose missing template instantiation problems.<p>
+
+ <li>When referring to member variables and functions, use
+ <code>this-&gt;</code><em>member</em>. This makes it clear to the
+ reader that a class member is being used. It also makes it crystal
+ clear to the compiler which variable/function you mean in cases
+ where it might make a difference. <p>
+
+ <li>Don't use template template arguments, this C++ construct is not
+ supported by the HP aCC 3.70 compiler at this moment. For example the
+ following template decleration is one that just doesn't work.
+ <pre>
+ template&lt;typename S_var, size_t BOUND, template &lt;typename&gt; class Insert_Policy&gt; class A {};
+ </pre>
+
+ <li><strong>I/O</strong><p>
+ <ul>
+ <li>Use <strong><code>ACE_DEBUG</code></strong> for printouts,
+ and <strong><code>ACE_OS::fprintf ()</code></strong> for
+ file I/O. Avoid using iostreams because of implementation
+ differences across platforms.<p>
+ <li>After attempting to open an existing file, always check for success.
+ Take appropriate action if the open failed.<p>
+ <li>Notice that <strong><code>ACE_DEBUG</code></strong> and
+ <strong><code>ACE_ERROR</code></strong> don't support
+ <code>%ld</code> of any other multicharacter format.<p>
+ </ul>
+
+ <li><strong>WCHAR conformity</strong><p>
+
+ <ul>
+ <li>For ACE, use <code>ACE_TCHAR</code> instead of char for strings and <code>ACE_TEXT()</code>
+ around string literals. Exceptions are <code>char</code>
+ arrays used for data and strings that need to remain as 1
+ byte characters.
+
+ <li>If you have a char string that needs to be converted to <code>ACE_TCHAR</code>,
+ use the <code>ACE_TEXT_CHAR_TO_TCHAR()</code> macro. If you have a <code>ACE_TCHAR</code>
+ string that needs to be converted to a <code>char</code> string, use the
+ <code>ACE_TEXT_ALWAYS_CHAR()</code> macro
+
+ <li>Do not use the Win32 <code>TCHAR</code> macros. The wide character-ness of ACE
+ is separate from UNICODE and _UNICODE.
+
+ <li>For TAO, don't use <code>ACE_TCHAR</code> or <code>ACE_TEXT</code>. The CORBA specification
+ defines APIs as using char. So most of the time there is no need
+ to use wide characters.
+ </ul><P>
+
+ <li><strong>Exceptions</strong><p>
+
+ <ul>
+ <li>There are many ways of throwing and catching exceptions. The
+ code below gives several examples. Note that each method has
+ different semantics and costs. Whenever possible, use the
+ first approach.<p>
+
+ <pre>
+ #include "iostream.h"
+
+ class exe_foo
+ {
+ public:
+ exe_foo (int data) : data_ (data)
+ { cerr &lt;&lt; "constructor of exception called" &lt;&lt; endl; }
+ ~exe_foo ()
+ { cerr &lt;&lt; "destructor of exception called" &lt;&lt; endl; }
+ exe_foo (const exe_foo& foo) : data_ (foo.data_)
+ { cerr &lt;&lt; "copy constructor of exception called"
+ &lt;&lt; endl; }
+ int data_;
+ };
+
+
+ void
+ good (int a)
+ {
+ throw exe_foo (a);
+ };
+
+ void
+ bad (int a)
+ {
+ exe_foo foo (a);
+ throw foo;
+ };
+
+ int main ()
+ {
+ cout &lt;&lt; endl &lt;&lt; "First exception" &lt;&lt; endl
+ &lt;&lt; endl;
+ try
+ {
+ good (0);
+ }
+ catch (exe_foo &foo)
+ {
+ cerr &lt;&lt; "exception caught: " &lt;&lt; foo.data_
+ &lt;&lt; endl;
+ }
+
+ cout &lt;&lt; endl &lt;&lt; "Second exception" &lt;&lt; endl
+ &lt;&lt; endl;
+ try
+ {
+ good (0);
+ }
+ catch (exe_foo foo)
+ {
+ cerr &lt;&lt; "exception caught: " &lt;&lt; foo.data_
+ &lt;&lt; endl;
+ }
+
+ cout &lt;&lt; endl &lt;&lt; "Third exception" &lt;&lt; endl
+ &lt;&lt; endl;
+ try
+ {
+ bad (1);
+ }
+ catch (exe_foo &foo)
+ {
+ cerr &lt;&lt; "exception caught: " &lt;&lt; foo.data_
+ &lt;&lt; endl;
+ }
+
+ cout &lt;&lt; endl &lt;&lt; "Fourth exception" &lt;&lt; endl
+ &lt;&lt; endl;
+ try
+ {
+ bad (1);
+ }
+ catch (exe_foo foo)
+ {
+ cerr &lt;&lt; "exception caught: " &lt;&lt; foo.data_
+ &lt;&lt; endl;
+ }
+
+ return 0;
+ }
+ </pre>
+
+ Output is: <p>
+
+ <pre>
+ First exception
+
+ constructor of exception called
+ exception caught: 0
+ destructor of exception called
+
+ Second exception
+
+ constructor of exception called
+ copy constructor of exception called
+ exception caught: 0
+ destructor of exception called
+ destructor of exception called
+
+ Third exception
+
+ constructor of exception called
+ copy constructor of exception called
+ destructor of exception called
+ exception caught: 1
+ destructor of exception called
+
+ Fourth exception
+
+ constructor of exception called
+ copy constructor of exception called
+ destructor of exception called
+ copy constructor of exception called
+ exception caught: 1
+ destructor of exception called
+ destructor of exception called
+
+ </pre>
+
+ </ul><p>
+
+ <li><strong>Compilation</strong><p>
+ <ul>
+ <li>Whenever you add a new test or example to ACE or TAO, make
+ sure that you modify the MPC file in the parent directory.
+ This will make sure that your code gets compiled on a
+ regular basis.<p>
+ </ul><p>
+</ul>
+
+<hr>
+<h3><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">ACE</a>
+ Shared Libary Guidelines</h3>
+ <ul>
+ <li>
+ <p>
+ Create a separate export macro for each dynamic library. A
+ header file containing the export macro and additional
+ support macros should be generated by using the <a
+ href="../bin/generate_export_file.pl">ACE_wrappers/bin/generate_export_file.pl</a> Perl script.
+ </p>
+ </li>
+ <li>
+ <p>
+ Make sure that your classes, structures and free functions
+ are annotated with this export macro. The only exceptions
+ are pure template classes, structures and free functions.
+ </p>
+ <p>
+ Only classes (and structures, free functions, etc) that are
+ part of the library public interface must be exported
+ (e.g. declared with an export macro). Those that are only
+ meant to be used internally need not be exported,
+ particularly for g++ <code>&gt;=</code>4.0 since doing so
+ defeats some neat optimizations. Here's a common case in
+ where an export macro is generally used unnecessarily:
+ </p>
+ <blockquote>
+ <pre>
+class FooExport Foo
+{
+public:
+ virtual void kung_fu () = 0;
+};
+
+class FooExport Bar : public Foo
+{
+public:
+ virtual void kung_fu () { ... }
+};
+
+class FooExport FooFactory
+{
+public:
+ Foo * make_foo ()
+ {
+ // Assume that this implementation is hidden from
+ // the application and is consequently out of line.
+ return new Bar();
+ }
+};
+ </pre>
+ </blockquote>
+ <p>
+ Here the application is only meant to invoke operations
+ through a pointer or reference to the abstract base class
+ "<code>Foo</code>" created by the "<code>FooFactory</code>",
+ not the "<code>Bar</code>" subclass. In this case,
+ exporting "<code>Bar</code>" is unnecessary. If your
+ concrete class is meant to be used outside of the shared
+ library (e.g. as a template parameter, within a
+ <code>dynamic_cast&lt;&gt;</code>, etc) you must then export
+ it. Otherwise, avoid doing so if you can.
+ </p>
+ </li>
+ <li>
+ <p>
+ Make sure that you specify that you are creating a dynamic
+ library in your <a href="../MPC/README">MPC</a> file by adding
+ a <code>sharedname</code> tag.
+ </p>
+ </li>
+ <li>
+ <p>
+ Make sure that you add the <code>FOO_BUILD_DLL</code>
+ preprocessor symbol to the <code>dynamicflags</code> of the
+ MPC project that is used to build a library. Note that the
+ export files are setup such that when this macro is defined,
+ the symbols are exported, otherwise they are imported. The
+ default behaviour is to set up for import so that clients of
+ your library don't need to worry about arcane build flags
+ like <code>FOO_BUILD_DLL</code> in their build setup. This
+ ties back to the first item.
+ </p>
+ </li>
+ <li>
+ <p>
+ When you specify the order of libraries to link to, make
+ sure that the dependent libraries come after the libraries
+ which depend on them, i.e., your link line should always
+ contain <code>-lDependsOnFoo -lFoo</code>. Note that this
+ is not a requirement on GNU/Linux but linkers on other
+ platforms are not as forgiving.
+ </p>
+ </li>
+ <li>
+ <p>
+ Use the <code>ACE_SINGLETON_DECLARE</code> macro to declare
+ a class as a singleton. Declare exported (i.e. default
+ visibility) singleton templates prior to typedefs that
+ reference them. This prevents g++ 4.0 from silently making
+ their visibility hidden (see <a
+ href="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=2260">Bug 2260</a> for details).
+ </p>
+ </li>
+ <li>
+ <p>
+ Avoid inlining virtual functions in classes that must be
+ exported since doing so can cause RTTI related problems
+ (e.g. <code>dynamic_cast&lt;&gt; failures</code>) when using
+ g++ &gt;= 4.0 due to our use of that compiler's "visibility
+ attribute" support that is tied in to the export macros.
+ This includes virtual destructors automatically created by
+ the compiler when you don't declare one. Make sure you
+ define a no-op out-of-line virtual destructor if your base
+ class has a virtual destructor since you may otherwise run
+ into the mentioned RTTI problems.
+ </p>
+ </li>
+ </ul>
+
+
+<hr>
+<h3><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">ACE</a>
+ Usage Guidelines</h3>
+<ul>
+ <li>Always use the <strong><code>ACE_OS</code></strong>
+ namespace functions instead of bare OS system calls.<p>
+
+ <li>As a general rule, the only functions that should go into the
+ <strong><code>ACE_OS</code></strong> namespace are ones that
+ have direct equivalents on some OS platform. Functions that
+ are extensions should go in the
+ <strong><code>ACE</code></strong> namespace.<p>
+
+ <li>Use the <strong><code>ACE_SYNCH_MUTEX</code></strong> macro,
+ instead of using one of the specific mutexes, such as
+ <strong><code>ACE_Thread_Mutex</code></strong>. This provides
+ portability between threaded and non-threaded platforms.<p>
+
+ <li>Avoid creating a static instance of user-defined (class) type.
+ Instead, either create it as an
+ <strong><code>ACE_Singleton</code></strong>,
+ <strong><code>ACE_TSS_Singleton</code></strong>, or as an
+ <strong><code>ACE_Cleanup</code></strong> object. See the
+ <strong>ACE</strong>
+ <a href="../ace/Singleton.h"><code>Singleton.h</code></a>,
+ <a href="../ace/Object_Manager.h"><code>Object_Manager.h</code></a>, and
+ <a href="../ace/Managed_Object.h"><code>Managed_Object.h</code></a>
+ header files for more information.<p>
+
+ Static instances of built-in types, such as
+ <strong><code>int</code></strong> or any pointer type, are fine.<p>
+
+ Construction of static instance of a user-defined type should
+ <em>never</em> spawn threads. Because order of construction of
+ statics across files is not defined by the language, it is usually
+ assumed that only one thread exists during static construction.
+ This allows statics suchs as locks to be safely created. We do not
+ want to violate this assumption.<p>
+
+ <li>Do not use C++ exception handling directly. Some platforms do
+ not support it. And, it can impose an execution speed penalty.
+ Instead use the TAO/ACE try/catch macros.<p>
+
+ <li>Because ACE does not use exception handling, dealing with
+ failures requires a bit of care. This is especially true
+ in constructors. Consider the following approach:
+
+ <pre>
+ ACE_NEW_RETURN (this-&gt;name_space_, LOCAL_NAME_SPACE, -1);
+
+ if (ACE_LOG_MSG-&gt;op_status () != 0)
+ ....
+ </pre>
+
+ This snip of code is from
+ <a href="../ace/Naming_Context.cpp"><code>ACE_Naming_Context</code></a>.
+ All failed constructors in ACE (should) call ACE_ERROR. This sets
+ the thread-specific <strong>op_status</strong>, which can be checked
+ by the caller. This mechanism allows the caller to check for a failed
+ constructor without the requiring the constructor to throw
+ exceptions.<p>
+
+ <LI>Another consequence of ACE's avoidance of exception handling is
+ that you should use <CODE>open()</CODE> methods on classes that
+ perform initializations that can fail. This is because <CODE>open()</CODE>
+ returns an error code that's easily checked by the caller,
+ rather than relying on constructor and thread-specific status
+ values. <P>
+
+ <li>Avoid using the C++ Standard Template Library (STL) in our
+ applications. Some platforms do not support it yet. It is
+ safe to use the STL generic algoritms. The following have been
+ used already and don't seem to cause any portability issues:
+ <pre>
+ std::swap
+ std::for_each
+ std::fill
+ std::generate
+ std::transform
+ std::copy
+ </pre><p>
+
+ <li>Be <em>very</em> careful with <code>ACE_ASSERT</code>. It
+ must only be used to check values; it may never be used to
+ wrap a function call, or contain any other side effect. That's
+ because the statement will disappear when ACE_NDEBUG is enabled.
+ For example, this code is BAD:
+ <pre>
+ ACE_ASSERT (this-&gt;next (retv) != 0); // BAD CODE!
+ </pre>
+
+ Instead, the above should be coded this way:
+
+ <pre>
+ int const result = this-&gt;next (retv);
+ ACE_ASSERT (result != 0);
+ ACE_UNUSED_ARG (result);
+ </pre><p>
+
+ <li>Never put side effects in <code>ACE_DEBUG</code> code:
+ <pre>
+ ACE_DEBUG ((LM_DEBUG,
+ "handling signal: %d iterations left\n",
+ --this-&gt;iterations_)); // BAD CODE!
+ </pre>
+
+ Note that this won't work correctly if <code>ACE_NDEBUG</code> is
+ defined, for the same reason that having side-effects in
+ <code>ACE_ASSERT</code>s won't work either, <em>i.e.</em>, because
+ the code is removed.<p>
+
+ <li>Be <strong>very</strong> careful with the code that you put
+ in a signal handler. On Solaris, the man pages document systems
+ calls as being Async-Signal-Safe if they can be called from signal
+ handlers. In general, it's best to just set a flag in a signal
+ handler and take appropriate action elsewhere. It's also best
+ to avoid using signals, especially asynchronous signals.<p>
+
+ <li>Immediately after opening a temporary file, unlink it. For
+ example:
+ <pre><code>
+ ACE_HANDLE h = open the file (filename);
+
+ ACE_OS::unlink (filename);
+ </code></pre><p>
+
+ This avoids leaving the temporary file even if the program crashes.<p>
+
+ <li>Be sure to specify the <code>THR_BOUND</code> thread creation
+ flag for time-critical threads. This ensures that the thread competes
+ for resources globally on Solaris. It is harmless on other platforms.<p>
+</ul>
+
+
+<hr>
+<h3><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">Other
+ ACE</a> and
+ <a href="http://www.cs.wustl.edu/~schmidt/TAO-overview.html">TAO</a>
+ Guidelines</h3>
+<ul>
+ <li>When enhancing, updating, or fixing ACE or TAO, always:<p>
+ <ol>
+ <li>Test your change on at least one platform. All changes
+ <strong>must</strong> be tested with egcs before commiting.
+ That means you may need to test on at least two platforms.<p>
+ <li>An an entry to the appropriate ChangeLog. TAO and some
+ ACE subdirectories, such as <a href="../ASNMP">ASNMP</a>,
+ <a href="../apps/JAWS">JAWS</a>, and
+ <a href="../apps/gperf">gperf,</a> have their
+ own ChangeLogs. If you don't use one of those, use the
+ <a href="../ChangeLog">ChangeLog</a> in the top-level
+ <a href="..">ACE_wrappers</a> directory.<p>
+ <li>Commit your change using a message of this form:<p>
+<code>
+ChangeLogTag: Thu Jul 22 09:55:10 UTC 1999 David L. Levine
+ &lt;levine@cs.wustl.edu&gt;
+</code><p>
+ <li>If the change is in response to a request by someone else:
+ <ol>
+ <li>Make sure that person is acknowledged in
+ <a href="../THANKS">ACE_wrappers/THANKS</a>, and<p>
+ <li>Respond to that person.<p>
+ </ol>
+ </ol>
+
+ <li>Never add copyrighted, confidential, or otherwise restricted
+ code to the ACE or TAO distributions without written permission
+ from the owner.<p>
+</ul>
+
+
+<hr>
+<h3><a href="http://www.cs.wustl.edu/~levine/CVS.html">CVS</a>
+ Usage Guidelines</h3>
+<ul>
+ <li>Always make sure that a change builds and executes correctly
+ on at least one platform before checking it into the CVS repository.
+ All changes <strong>must</strong> be tested with g++ before commiting.
+ That means you may need to test on at least two platforms.<p>
+</ul>
+
+
+<hr>
+<h3>Script Guidelines</h3>
+<ul>
+ <li>In general, it's best to write scripts in Perl. It's
+ OK to use Bourne shell. Never, never, never use csh, ksh,
+ bash, or any other kind of shell.<p>
+
+ <li>Follow the Perl style guide guide as closely as
+ possible. <code>man perlstyle</code> to view it.
+
+ <li>Don't specify a hard-coded path to Perl itself. Use
+ the following code at the top of the script to pick up
+ perl from the users <code>PATH</code>:<br>
+ <pre>
+eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}'
+ & eval 'exec perl -S $0 $argv:q'
+ if 0;
+ </pre><p>
+
+ <li>Never, never, never start the first line of a script
+ with "<code>#</code>", unless the first line is "<code>#! /bin/sh</code>".
+ With just "<code>#</code>", t/csh users will spawn a new shell.
+ That will cause their <code>.[t]cshrc</code> to be
+ processed, possibly clobbering a necessary part of
+ their environment.<p>
+
+ <li>If your Perl script relies on features only available
+ in newer versions of Perl, include the a statement similar
+ to the following:<br>
+ <pre>
+ require 5.003;
+ </pre>
+
+ <li>Don't depend on <strong><code>.</code></strong> being
+ in the user's path. If the script spawns another executable
+ that is supposed to be in the current directory, be sure the
+ prefix its filename with <strong><code>.</code></strong>.<p>
+</ul>
+
+
+<hr>
+<h3>Software Engineering Guidelines</h3>
+<ul>
+ <li><strong>Advise</strong>: Keep other developers informed of problems
+ and progress.<p>
+
+ <li><strong>Authorize</strong>: We have contractual obligations to not
+ unilaterally change interfaces. If you need to change or remove an
+ interface, get an OK.<p>
+
+ <li><strong>Minimize</strong> risk: Test all changes. Solicit review of
+ changes.<p>
+
+ <li><strong>Revise</strong> only when necessary: Every change has risk,
+ so avoid making any change unless there is a good reason for it.<p>
+
+ <li><strong>Normalize</strong>: Factor out commonality. For example,
+ maintain a data value in only one place.<p>
+
+ <li><strong>Synthesize</strong>: Build stubs and scaffolding early to
+ simulate the complete system. Maintain a checked-in version of the
+ system that cleanly builds and tests at all times.<p>
+
+ <li><strong>Be available</strong>: Breaking compilation in one
+ platform or another should be avoided (see above),
+ but it is bound to happen when so many platforms are in use.
+ Be available after making a change,
+ if you won't be available for at least 48 hours after the change
+ is made then don't make it!<p>
+</ul>
+
+
+
+<hr>
+<h3><a href="http://www.cs.wustl.edu/~schmidt/rules.html">ACE
+ Design Rules</a></h3>
+
+
+<hr><p>
+ <font size=-1>
+<!-- hhmts start -->
+Last modified: Wed Nov 23 11:00:44 CST 2005
+<!-- hhmts end -->
+ </font><p>
+
+
+
+Back to <A HREF="index.html">ACE Documentation Home</A>.
+
+</body>
+</html>
diff --git a/ACE/docs/ACE-lessons.html b/ACE/docs/ACE-lessons.html
new file mode 100644
index 00000000000..4448644ae68
--- /dev/null
+++ b/ACE/docs/ACE-lessons.html
@@ -0,0 +1,270 @@
+<HTML>
+
+<!-- $Id$ -->
+<HEAD>
+<TITLE>Lessons Learned Building Reusable OO Telecommunication Software</TITLE>
+</HEAD>
+
+<BODY text = "#000000"
+link="#000fff"
+vlink="#ff0f0f"
+bgcolor="#ffffff">
+
+<HR>
+<H3>Lessons Learned Building Reusable OO Telecommunication Software Frameworks</H3>
+
+<DT>Douglas C. Schmidt
+<DT>Department of Computer Science
+<DT>Washington University, St. Louis
+<DT><A HREF="http://www.cs.wustl.edu/~schmidt/">http://www.cs.wustl.edu/~schmidt/</A>
+<DT><A HREF="mailto:schmidt@cs.wustl.edu">schmidt@cs.wustl.edu</A>
+
+<P>The following article appeared in the Lucent Bell Labs ``Multiuse
+Express'' magazine, Vol. 4, No. 6, December, 1996. <P>
+
+<P><HR><P>
+
+<H3>The Distributed Software Crisis</H3>
+
+Developing complex software systems is expensive and error-prone.
+Object-oriented (OO) programming languages [Stroustrup:91,Gosling:96],
+components [Box:97], and frameworks [Lewis:95] are heavily touted
+technologies for reducing software cost and improving software
+quality. When stripped of their hype, the primary benefits of OO stem
+from the emphasis on <EM>modularity</EM> and <EM>extensibility</EM>,
+which encapsulate volatile implementation details behind stable
+interfaces and enhance software reuse. <P>
+
+Developers in certain well-traveled domains have successfully applied
+OO techniques and tools for years. For instance, the Microsoft MFC
+GUI framework and OCX components are <EM>de facto</EM> industry
+standards for creating graphical business applications on PC
+platforms. Although these tools have their limitations, they
+demonstrate the productivity benefits of reusing common frameworks and
+components.<P>
+
+Software developers in more complex domains like telecom have
+traditionally lacked standard off-the-shelf middleware components. As
+a result, telecom developers largely build, validate, and maintain
+software systems from scratch. In an era of deregulation and stiff
+global competition, this in-house development process is becoming
+prohibitively costly and time consuming. Across the industry, this
+situation has produced a ``distributed software crisis,'' where
+computing hardware and networks get smaller, faster, and cheaper; yet
+telecom software gets larger, slower, and more expensive to develop
+and maintain. <P>
+
+The challenges of building distributed software stem from
+<EM>inherent</EM> and <EM>accidental</EM> complexities [Brooks:87]
+associated with telecom systems: <P>
+
+<UL>
+<LI> Inherent complexity stems from the fundamental challenges of
+ developing telecom software. Chief among these is detecting and
+ recovering from network and host failures, minimizing the impact of
+ communication latency, and determining an optimal partitioning of
+ service components and workload onto processing elements throughout
+ a network. <P>
+
+<LI> Accidental complexity stems from limitations with tools and
+ techniques used to develop telecom software. A common source of
+ accidental complexity is the widespread use of algorithmic
+ decomposition, which results in non-extensible and non-reusable
+ software designs and implementations. <P>
+</UL>
+
+The lack of extensibility and reuse in-the-large is particularly
+problematic for complex distributed telecom software. Extensibility
+is essential to ensure timely modification and enhancement of services
+and features. Reuse is essential to leverage the domain knowledge of
+expert developers to avoid re-developing and re-validating common
+solutions to recurring requirements and software challenges. <P>
+
+While developing high quality reusable software is hard enough,
+developing high quality extensible and reusable telecom software is
+even harder. Not surprisingly, many companies attempting to build
+reusable middleware fail -- often with enormous loss of money, time,
+and marketshare. Those companies that do succeed, however, reap the
+benefits resulting from their ability to develop and deploy complex
+applications rapidly, rather than wrestling endlessly with
+infrastructure problems. Unfortunately, the skills required to
+successfully produce telecom middleware remain something of a "black
+art," often locked in the heads of expert developers. <P>
+
+<P><HR><P>
+
+<H3>Lessons Learned Building Reusable OO Communication Software Frameworks</H3>
+
+Over the past decade, I've worked with many companies (including
+Motorola Iridium, Ericsson, Siemens, Bellcore, Kodak, and McDonnell
+Douglas) building reusable OO communication software [Schmidt:96]. In
+these projects, we've applied a range of OO middleware tools including
+OMG <A HREF="http://www.cs.wustl.edu/~schmidt/corba.html">CORBA</A>
+(an emerging industry standard for distributed object computing) and
+the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A>
+framework (a widely used C++ framework that implements many strategic
+and tactical design patterns for concurrent communication software).
+The following are lessons learned from developing and deploying
+reusable OO communication software components and frameworks in
+practice: <P>
+
+<UL>
+<LI> <B><EM> Successful reuse-in-the-large requires non-technical
+prerequisites -- </EM></B><P>
+
+ Many political, economical, organizational, and psychological
+ factors can impede successful reuse in telecom companies. I've
+ found that reuse-in-the-large works best when (1) the marketplace is
+ competitive (i.e., time-to-market is crucial, so leveraging existing
+ software substantially reduces development effort), (2) the
+ application domain is non-trivial (i.e., repeatedly developing
+ complete solutions from scratch is too costly), and (3) the
+ corporate culture is supportive of an effective reuse process (e.g.,
+ developers are rewarded for taking the time to build robust reusable
+ components). When these prerequisites <EM>don't</EM> apply, I've
+ found that developers often fall victim to the "not-invented-here"
+ syndrome and rebuild everything from scratch. <P>
+
+<LI> <B><EM> Iteration and incremental growth is essential </EM></B> -- <P>
+
+ Expanding on the corporate culture theme, I've observed that it's
+ crucial for software managers to openly support the fact that good
+ components, frameworks, and software architectures take time to
+ craft and hone. For reuse to succeed in-the-large, management must
+ have the vision and resolve to support the incremental evolution of
+ reusable software. In general, an 80% solution that can be evolved
+ is often preferable to trying to achieve a 100% solution that never
+ ships. Fred Brook's observation that ``Plan to throw the first one
+ away, you will anyway'' [Brooks:75] applies as much today as it did
+ 20 years ago. <P>
+
+<LI> <B><EM> Integrate infrastructure developers with application developers
+</EM></B> -- <P>
+
+ Truly useful components and frameworks are derived from solving real
+ problems, e.g., telecommunications, medical imaging, avionics, OLTP,
+ etc. Therefore, a time honored way of producing reusable components
+ is to generalize from working systems and applications. In
+ particular, resist the temptation to create ``component teams'' that
+ build reusable frameworks in isolation from application teams. I've
+ learned the hard way that without intimate feedback from application
+ developers, the software artifacts produced by a component team
+ won't solve real problems and will not be reused. <P>
+
+<LI> <B><EM> Industry ``standards'' are not panaceas -- </EM></B> <P>
+
+ Expecting emerging industry standards (like CORBA or TINA) to
+ eliminate telecom software complexity today is very risky. For
+ instance, although some CORBA ORB implementations are suited for
+ certain telecom tasks (such as managing network elements), the
+ semantics of higher level OMG services (such as the Common Object
+ Services) are still too vague, under-specified, and non</EM></B>
+ -interoperable. Although CORBA isn't yet suited to address certain
+ demanding real-time performance and reliability requirements in the
+ telecom domain, over the next 2 years we'll see CORBA-based products
+ emerge that support such features [Schmidt:96].<P>
+
+<LI> <B><EM> Beware of simple(-minded) solutions to complex software problems
+-- </EM></B> <P>
+
+ Apply simple solutions to complex problems that sound too good to be
+ true typically are... For example, translating code entirely from
+ high-level specifications or using trendy OO design methodologies
+ and programming languages is no guarantee of success. In my
+ experience, there's simply no substitute for skilled software
+ developers, which leads to the following final ``lesson learned.''
+<P>
+
+<LI> <B><EM> Respect and reward quality developers </EM></B> -- <P>
+
+ Ultimately, reusable components are only as good as the people who
+ build and use them. Developing robust, efficient, and reusable
+ telecom middleware requires teams with a wide range of skills. We
+ need expert analysts and designers who have mastered design
+ patterns, software architectures, and communication protocols to
+ alleviate the inherent and accidental complexities of telecom
+ software. Moreover, we need expert programmers who can implement
+ these patterns, architectures, and protocols in reusable frameworks
+ and components. In my experience, it is exceptionally hard to find
+ high quality software developers. Ironically, many telecom
+ companies treat their developers as interchangeable, "unskilled
+ labor" who can be replaced easily. I suspect that over time,
+ companies who respect and reward their high quality software
+ developers will increasingly outperform those who don't. <P>
+</UL>
+
+<P><HR><P>
+<H3>Concluding Remarks</H3>
+
+Developing reusable OO middleware components and frameworks is not a
+silver bullet. Software is inherently abstract, which makes it hard
+to engineer its quality and to manage its production. The good news,
+however, is that OO component and framework technologies are becoming
+mainstream. Developers and users are increasingly adopting and
+succeeding with object-oriented design and programming.<P>
+
+On the other hand, the bad news is that (1) existing OO components and
+frameworks are largely focused on only a few areas (e.g., GUIs) and
+(2) existing industry standards still lack the semantics, features,
+and interoperability to be truly effective throughout the telecom
+software domain. Too often, vendors use industry standards to sell
+proprietary software under the guise of open systems. Therefore, it's
+essential for telecom companies to work with standards organizations
+and middleware vendors to ensure the emerging specifications support
+true interoperability and define features that meet telecom software
+needs.<P>
+
+Finally, to support the standardization effort, it's crucial for us to
+capture and document the patterns that underlie the successful telecom
+software components and frameworks that do exist. Likewise, we need
+to reify these patterns to guide the creation of standard frameworks
+and components for the telecom domain. I'm optimistic that the next
+generation of OO frameworks and components will be a substantial
+improvement over those we've worked with in the past.<P>
+
+For more information on building reusable OO communication software
+frameworks with CORBA and ACE, see the following WWW URLs:<P>
+
+<A HREF="http://www.cs.wustl.edu/~schmidt/corba.html">http://www.cs.wustl.edu/~schmidt/corba.html</A><p>
+<A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">http://www.cs.wustl.edu/~schmidt/ACE.html.</A>
+
+<P><HR><P>
+<H3>References</H3>
+
+[Box:97] Don Box, "Understanding COM," Addison-Wesley,
+ Reading, MA, 1997.<P>
+
+[Brooks:75] Frederick P. Brooks, "The Mythical Man-Month,"
+ Addison-Wesley, Reading, MA, 1975.<P>
+
+[Brooks:87] Frederick P. Brooks, "No Silver Bullet: Essence and
+ Accidents of Software Engineering," IEEE Computer, Volume
+ 20, Number 4, April 1987, 10-19.<P>
+
+[Gosling:96] The Java Programming Language, Addison-Wesley,
+ Reading, MA, 1996.<P>
+
+[Lewis:95], Ted Lewis et al., "Object Oriented Application
+ Frameworks," IEEE Computer Society Press, 1995.<P>
+
+[OMG:95] Object Management Group, The Common Object Request Broker:
+ Architecture and Specification 2.0, July, 1995.<P>
+
+[Schmidt:96] Douglas C. Schmidt, "A Family of Design Patterns for
+ Application-Level Gateways," Theory and Practice of Object
+ Systems, Wiley and Sons, 1996.<P>
+
+[Schmidt:97] Aniruddha Gokhale, Douglas C. Schmidt, Tim Harrison, and
+ Guru Parulkar, "Towards Real-time CORBA," IEEE Communications
+ Magazine, Volume 14, Number 2, February 1997.<P>
+
+[Stroustrup:91] Bjarne Stroustrup, The C++ Programming Language, 2nd
+ Edition, Addison-Wesley, Reading, MA, 1991.<P>
+
+<P><HR><P>
+Back to <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">
+ACE</A> home page.<BR>
+Back to <A HREF="index.html">ACE Documentation Home</A>.
+<!--#include virtual="/~schmidt/cgi-sig.html" -->
+</BODY>
+</HTML>
diff --git a/ACE/docs/ACE-porting.html b/ACE/docs/ACE-porting.html
new file mode 100644
index 00000000000..24421d943d4
--- /dev/null
+++ b/ACE/docs/ACE-porting.html
@@ -0,0 +1,198 @@
+<!-- $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, TAO, and CIAO to a New OS Platform</H3><P>
+
+<A HREF="http://www.dre.vanderbilt.edu/ACE">ACE</A>, <A
+HREF="http://www.dre.vanderbilt.edu/TAO">TAO</A>, and <A
+HREF="http://www.dre.vanderbilt.edu/CIAO">CIAO</A> have been
+ported to <A HREF="http://www.dre.vanderbilt.edu/versions.html">many
+OS platforms</A>. 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 <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 and CIAO, as well.<P>
+
+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:
+
+<UL>
+<LI> Read and follow the <A HREF="ACE-guidelines.html">programming style
+ guidelines</A> 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. <P>
+
+<LI> Contact <A HREF="mailto:d.schmidt@vanderbilt.edu">Douglas
+ C. Schmidt</A> 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. <P>
+</UL>
+
+<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="../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="../ace/README">$ACE_ROOT/ace/README</A> file. <P>
+
+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 <A
+HREF="../configure.ac">autoconf script</A>. It's a good idea to use
+the <CODE>config-*.h</CODE> files for platforms with similar
+characteristics as examples.
+
+<hr align=left width="50%"><P>
+<H4>Port the <CODE>ACE_OS</CODE> Namespace</H4>
+
+The <CODE>ACE_OS</CODE> namespace 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 of the ACE OS
+abstraction layer. Most work required to port ACE to a new OS
+platform resides in this namespace. 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_NS_*.{h,inl,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="../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 Facade Components</H4>
+
+After porting the <CODE>ACE_OS</CODE> 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 <A
+HREF="ACE-categories.html">$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="../tests/README">regression test suite</A>
+in the <A HREF="../tests/">$ACE_ROOT/tests/</A> directory. These
+tests can be used to validate the correctness of the various ACE C++
+wrapper facades 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++ 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. <P>
+
+<hr align=left width="50%"><P>
+<H4>Port TAO and CIAO</H4>
+
+After porting and successfully testing all the ACE framework
+components, it should be straightforward to port and <A
+HREF="../TAO/TAO-INSTALL.html">install</A> TAO and <A
+HREF="../TAO/CIAO/CIAO-INSTALL.html">install</A> 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. <P>
+
+<HR><P>
+<H3>C++ Features Required to Port ACE, TAO, and CIAO</H3>
+
+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:
+
+<UL>
+<LI> <B>Templates</B> -- The C++ compiler must support templates.
+ However, it need not support template member functions and of
+ the advanced concepts outlined in <A
+ HREF="http://www.moderncppdesign.com/"> Modern C++ Design</A>. <P>
+
+<LI> <B>Multiple inheritance and dynamic binding</B> -- The C++
+ compiler must support multiple inheritance and dynamic
+ binding. <P>
+
+<LI> <B>Namespaces</B> -- ACE+TAO+CIAO utilizes C++ namespaces, so the
+ C++ compiler must support them.<P>
+
+<LI> <B>ANSI casts and RTTI</B> -- ACE+TAO+CIAO uses the ANSI C++
+ casts, so the C++ compiler must support them, which implies
+ support for RTTI.<P>
+
+</UL>
+
+The following is a list of which C++ features that ACE, TAO, CIAO 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>STL</B> -- 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). <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,
+ TAO, and CIAO 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>
diff --git a/ACE/docs/ACE-subsets.html b/ACE/docs/ACE-subsets.html
new file mode 100644
index 00000000000..ef2a1e0dcd1
--- /dev/null
+++ b/ACE/docs/ACE-subsets.html
@@ -0,0 +1,196 @@
+<!-- $Id$ -->
+
+<html>
+ <head>
+ <title>ACE+TAO Subsetting</title>
+ <link rev=made href="mailto:ace-users@cs.wustl.edu">
+ </head>
+
+<body text = "#000000"
+ link="#000fff"
+ vlink="#ff0f0f"
+ bgcolor="#ffffff">
+
+<hr><p>
+<H2>ACE+TAO Subsetting</H2>
+
+<p>
+We are involved in ongoing activities to subset ACE+TAO to make them
+more flexible and to reduce their memory footprint for embedded
+systems. This document describes what we've done thus far, what we're
+planning to do next, and how to leverage our efforts to minimize the
+size of your ACE+TAO applications. </P>
+
+<hr>
+<h3>Contents</h3>
+<ul>
+ <li><a href="#pastwork">Past Work</a>
+ <li><a href="#futurework">Future Work</a>
+</ul>
+
+<hr>
+<h3><a name="pastwork">Past Work</a></h3>
+<p>
+
+Previous ACE+TAO subsetting efforts were mainly concerned with
+breaking up ACE into multiple libraries. Although this was a worthy
+goal, the existing component definitions in <a
+href="../ace/ace.mpc">ace.mpc</a> are too tightly coupled. Even if
+ACE was compiled into multiple libraries, therefore, applications
+would still have to link almost every one of them.</p>
+
+<p>
+Potentially more satisfying results can be obtained through the use of
+namespaces, e.g., ACE_OS, and/or breaking up large cpp's into smaller
+ones to decrease the size of object files, and statically linking them
+into the application.</p>
+
+<p>
+In fact, this technique was applied systematically to ACE_OS in 2003,
+and resulted in a <a
+href="http://www.dre.vanderbilt.edu/Stats/footprint.shtml">10-15%
+decrease in overall footprint</a> for statically linked applications.
+Interestingly, these techniques also helped reduce <a
+href="http://www.dre.vanderbilt.edu/~isisbuilds/auto_compile_logs/CP_Metrics/metrics/">compilation
+times by ~50%</a>.</p>
+
+<p>
+Another very powerful technique for reducing the size of shared
+libries is <a href="../apps/soreduce/README">The Shared Library
+Reduction (<CODE>soreduce</CODE>) tool</a>. <code>soreduce</code>
+also benifits from the techniques listed above and should give
+results comparable to static linking. In fact, when deploying multiple
+applications, use of shared libraries with <code>soreduce</code> will
+result in smaller overall footprint than static linking.</p>
+
+<hr>
+<h3><a name="futurework">Future Work</a></h3>
+<p>
+
+Depending on funding and contributions from the ACE community, future
+work on subsetting in ACE can be divided into two thrusts: <P>
+
+<UL>
+
+<LI> <B>Code refactoring</B>, which helps to reduce the coupling
+between applications and ACE C++ wrappers and frameworks. The amount
+of coupling that's in ACE currently yields larger compiled size for
+executable applications, increased link times, and indirect dependency
+on a large amounts of code that may not be needed for many embedded
+applications. <P>
+
+<LI> <B>Functionality Refactoring</B>, which enables application
+developers to choose lightweight reusable classes and frameworks,
+rather than monolithic and heavyweight implementations, to decrease
+compilation times, link times, and compiled memory footprint of
+embedded applications. <P>
+
+</UL>
+
+Our ideas for performing each of these thrusts is described in detail
+below.
+
+<h4>ACE Code Refactoring</H4>
+
+ACE is currently designed in such a way that application developers
+must link many classes and methods of ACE with their application, even
+if they use a small number of classes and functions in their
+application. As a result, static memory resource utilization is
+unnecessarily high for common use cases. This section describes
+techniques to address the existing code structuring complexities in
+ACE, which were originally driven by the poor quality of C++ tools
+that were available in the 1990's. For example, early C++ compilers
+in the embedded domain lacked support for namespaces, which forced
+developers to write classes that had a number of utility functions
+useful for network programming. Now that modern C++ compilers have
+better support for standard C++, we propose the following
+optimizations to ACE: <P>
+
+<UL>
+
+<LI> We will identify ACE classes and utility functions that serve a
+ common goal, and move them into a namespace of their own. Since C++
+ allows a single namespace to be reopened in multiple translation
+ units, we plan to split the operations into multiple C++ source
+ files, giving the linker a chance to choose a smaller sized object
+ files while creating an executable. <P>
+
+<LI> Currently, ACE inlines many of its methods, which tradesoff run-time
+ performance for larger footprint. We propose to examine the contents
+ of inlined files in ACE, and evaluate whether inlining is required in
+ every instance. ACE aggressively inlined functions to get better
+ performance from the tool chains, but this has lead to increased code
+ coupling within ACE, as well as increased coupling between
+ applications that use ACE. We will evaluate the tradeoffs associated
+ with inlining and performance of certain functions and selectively
+ inline those methods. These optimizations are described further in
+ <A
+HREF="http://www.amazon.com/exec/obidos/tg/detail/-/0201379503/104-7731669-1857527?v=glance">Efficient
+C++: Performance Programming Techniques</A> by Dov Bulka and
+ David Mayhew.
+</UL>
+
+We expect that we will be able to reduce footprint by ~25-30% for ACE
+applications, and a ~15-20% reduction in compile and link time of
+applications. <P>
+
+<H4>Functionality Refactoring</H4>
+
+ This section proposes to address additional compile-time and memory
+footprint problems that can be solved by functionality refactoring.
+During the past decade, ACE has been designed and built based on many
+unique requirements from users around the globe. Though this input
+enhanced the flexibility of ACE and increased the visibility of ACE,
+it also led to functionality "clumping," i.e., many classes in ACE
+have functionality associated with them that are not required for many
+applications. For example, the ACE_Svc_Handler serves as an event
+handler for the ACE Reactor framework, serves as a handler to
+implement the thread-per-connection strategies, and can be dynamically
+loaded from shared libraries using the ACE Service Configurator
+framework, which in turn depends on the ACE Reactor framework. Though
+all these dependencies and functionalities are required for some
+applications, they yield excessive coupling and overhead for
+applications (such as clients) that only want to use the ACE
+Acceptor/Connector framework to connect and send messages to remote
+servers. <P>
+
+ To address the issues of tight-coupling outlined above, we propose
+to refactor the code and functionality of the existing ACE frameworks
+and wrapper classes to offer finer-grained components that can be
+selectively included by embedded applications. Our initial efforts
+would focus on the following key ACE frameworks:
+<UL>
+<LI> Logging
+<LI> Service Configurator
+<LI> Object Manager
+<LI> Reactor
+<LI> Framework Component
+<LI> Thread Manager
+<LI> Proactor
+</UL>
+
+We propose to apply the techniques we have mentioned above. As a
+result, we expect that we will be able to reduce footprint by another
+~20-25% for certain classes of ACE applications, and a ~15-20%
+reduction in compile- and link-time of applications. <P>
+
+ Collectively, the optimizations we propose above will greatly
+reduce the memory footprint and speedup the compilation and link time
+for ACE-based applications. <P>
+
+<p> Anyone interested in contributing time or funding to these efforts
+should please contact <a
+href="mailto:d.schmidt@vanderbilt.edu">d.schmidt@vanderbilt.edu</a>.
+If you have questions about ACE and/or ACE subsetting and footprint
+reduction please post these questions to the <A
+HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE mailing
+list</A>.</p>
+
+<P><HR><P>
+Back to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A>
+home page.<BR>
+Back to <A HREF="index.html">ACE Documentation Home</A>.
+
+<!--#include virtual="/~schmidt/cgi-sig.html" -->
+</BODY>
+</HTML>
diff --git a/ACE/docs/CE-status.txt b/ACE/docs/CE-status.txt
new file mode 100644
index 00000000000..3b618df0980
--- /dev/null
+++ b/ACE/docs/CE-status.txt
@@ -0,0 +1,51 @@
+/**
+@page wince ACE on Windows CE status
+
+Last updated Tuesday 15-November-2005 by Steve Huston <shuston@riverace.com>
+
+@subsection ce_status Status
+
+As of ACE 5.5, Riverace supports ACE on Windows CE building with Microsoft
+Visual Studio 2005 and targeting the Pocket PC 2003 SDK and Windows Mobile 5.
+OCI supports TAO 1.3 on at least Windows CE 3 with the PocketPC 2002 SDK.
+Contact the individual support provider for complete information regarding
+these platforms as well as the supported hardware targets.
+
+@subsection ce_evc eMbedded Visual C++ Projects
+
+Whereas previous ACE versions had separate ACE and ACE_OS eMbedded Visual C++
+project files, the project and workspace arrangement is now the same as
+for other Windows versions. The project and workspace files themselves are
+generated using the MakeProjectCreator tool when the ACE kit is prepared.
+Both EVC3 and EVC4 use the same project and workspace files.
+
+Developers working with sources checked out from CVS must generate the
+project and workspace files locally using MPC. The autobuild system's
+generate_makefile and generate_workspace commands can be used for this.
+
+@subsection ce_vc8 Visual Studio 2005 Projects
+
+The ACE release process generates the needed Visual Studio 2005 solution and
+project files with "_WinCE" appended to the name (e.g. ACE_WinCE.vcproj) to
+distinguish them from both Win32-targeted VC8 projects (ACE_vc8.vcproj) and
+Visual Studio 2003 projects (ACE.vcproj). The files are generated with
+the "Pocket PC 2003 SDK (ARMV4)" and "Windows Mobile 5.0 Pocket PC SDK
+(ARMV4I)" platforms defined. To add additional platforms, the files must be
+regenerated using MPC.
+
+@subsection ce_wchar Unicode/WChar
+
+ACE on WindowsCE automatically has ACE_HAS_WCHAR and ACE_USES_WCHAR turned
+on. Thus ACE_TCHAR and ACE_TEXT() are the wide char versions.
+
+@subsection ce_tests Running the Test Suite on Windows CE
+
+The ACE test suite in ACE_wrappers/tests is used on Windows CE as well as
+on dekstop Windows. The test suite tools are being extended to use a
+product called Pocket Controller, Enterprise edition from Soft Object
+Technologies, Inc. (www.soti.net) that can script the actions needed to
+copy the test files to a PocketPC device, run the test, and copy the log
+files back to the build machine for analysis and reporting to the
+scoreboard.
+
+*/
diff --git a/ACE/docs/CVS.html b/ACE/docs/CVS.html
new file mode 100644
index 00000000000..b986f9dec0a
--- /dev/null
+++ b/ACE/docs/CVS.html
@@ -0,0 +1,889 @@
+<!-- $Id$ -->
+
+<html>
+<head>
+ <title>CVS Minimal Help</title>
+ <link rev=made href="mailto:levine@cs.wustl.edu">
+<!-- Changed by: David Levine, 26-Mar-1997 -->
+</head>
+
+<body text = "#000000"
+ link = "#000fff"
+ vlink = "#ff0f0f"
+ bgcolor = "#ffffff">
+<hr><p>
+<center>
+ <h1>CVS Minimal Help</h1>
+ <h2><a href="mailto:levine@cs.wustl.edu">David L. Levine</a></h2>
+ <font size=-1>
+ Last modified Monday, 30-Sep-2002 11:15:16 CDT.
+ </font>
+</center>
+<h2>&nbsp</h2>
+
+This page contains the minimum (and then some) commands necessary to
+access and update <a href="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</a>
+through <a href="file:/project/doc/pkg/cvs/cvs-1.10/doc/cvs.ps">CVS</a>
+version control. The intended audience is local ACE developers, so
+it's not by any means a general introduction to CVS. And some HTML
+links and other references are local only.<p>
+
+The information here is based on CVS versions 1.9 and 1.10.5 and later.<p>
+
+Notes to emacs users: the emacs Tools/Version Control (or vc) pulldown
+has CVS commands: it's well worth checking out. And, see the
+<a href="#Preliminaries">Preliminaries</a> section for a handy
+addition to your .emacs file.<p>
+
+If you'd like to update your CVS workspace remotely, see
+<a href="http://www.cs.wustl.edu/~nanbor/">Nanbor Wang</a>'s&nbsp&nbsp
+<a href="http://www.cs.wustl.edu/~nanbor/CVSUP/">CVSup</a>&nbsp page.<p>
+
+Please <a href="mailto:levine@cs.wustl.edu">email me</a> any corrections or
+suggestions!<p>
+
+
+<font size="+2"><strong>Contents:</strong></font>
+<ol>
+ <li><a href="#The Model">The Model</a>
+ <li><a href="#Preliminaries">Preliminaries</a>
+ <li><a href="#Getting started with ACE on CVS">Getting
+ started with ACE on CVS</a>
+ <li><a href="#Windows NT setup">Windows NT setup</a>
+ <li><a href="#Checking in changes">Checking in changes</a>
+ <li><a href="#Workspace update">Workspace update</a>
+ <li><a href="#Adding/removing files/directories">Adding/removing
+ files/directories</a>
+ <li><a href="#Modules">Modules</a>
+ <li><a href="#ChangeLog updates">ChangeLog updates</a>
+ <li><a href="#File revisions">File revisions</a>
+ <li><a href="#File reversion">File reversion</a>
+ <li><a href="#Renaming a file">Renaming a file</a>
+ <li><a href="#Local version control">Local version control</a>
+ <li><a href="#Branches">Branches</a>
+ <li><a href="#Remote repositories">Remote repositories</a>
+ <li><a href="#Exporting from CVS">Exporting from CVS</a>
+ <li><a href="#ACE_wrappers-frozen workspace">ACE_wrappers-frozen
+ workspace</a>
+ <li><a href="#ACE release bug-fix branch">ACE release bug-fix branch</a>
+ <li><a href="#Warning messages/problems">Warning messages/problems</a>
+ <li><a href="#For more info on CVS">For more info on CVS</a>
+</ol>
+
+
+<hr><p>
+<h3>1. <a name="The Model">The Model</a></h3>
+The following terms are used in the discussion in this web page:<br>
+<ul>
+ <li><em>Repository</em>: The master store of all versions of all
+ controlled files.<p>
+ <li><em>Workspace</em>: A user's collection of controlled files.
+ The user may modify these files at will.<p>
+ <li><em>Check out</em>: Retrieve one or more files from the
+ repository, and place them in a workspace. Any version of any
+ file may be retrieved; typically, that will be the latest version.<p>
+ <li><em>Check in, or commit</em>: Update the latest version of
+ one or more files in the repository. This is done from a workspace.<p>
+ <li><em>Module</em>: Directory.
+</ul>
+
+Our use of CVS fits into the
+<a href="http://www.cs.wustl.edu/~levine/ACE_wrappers/docs/ACE-development-process.html">ACE development process</a>.<p>
+
+
+<hr><p>
+<h3>2. <a name="Preliminaries">Preliminaries</a></h3>
+<p>The <code>CVSROOT</code> environment variable listed below is <font
+color=red> <strong><blink>required</blink></strong></font>. If you
+want to use CVS from within emacs, you'll have to restart it from a
+shell that has <code>CVSROOT</code> defined.<p>
+
+Emacs users might want to add <var>(setq vc-follow-symlinks t)</var>
+to your .emacs file to instruct emacs to follow symlinks to
+version-controlled plain files.<p>
+
+For lack of a better place to put the following, I'll put it here.
+It's a good idea to insert a CVS/RCS keyword string at the top of
+every file that you place under CVS control. This includes source
+files, Makefiles, config files, <em>etc</em>. It will embed in the
+file a concise record of the filename, last update time, revision
+number, and last user who updated it. For C++ files, the keyword
+string is:
+ <pre>
+ // $<!-- -->Id$
+ </pre>
+It's not necessary to fill in the fields of the keyword string,
+or modify them when you edit a file that already has one. CVS
+does that automatically when you checkout or update the file.<p>
+
+On Unix systems, you might want to create a file called <code>.cvsrc</code>
+in your home directory with the following contents:
+<pre><code>
+co -P
+update -P
+</code></pre>
+That will cause CVS to prune empty directories on checkout or update.
+<p>
+
+
+<hr><p>
+<h3>3. <a name="Getting started with ACE on CVS">Getting started with ACE on CVS</a></h3>
+Note: the first three steps are for UNIX platforms. See the
+<a href="#Windows NT setup">Windows NT setup</a> section for
+setup information for Windows NT.
+<ol>
+ <li>% <code>setenv CVSROOT /project/cvs-repository </code> ####
+ site-specific location<p>
+ <li>cd to the directory that you want your ACE_wrappers workspace
+ to be under.<p>
+ <li>% <code>setenv ACE_ROOT `pwd` </code> #### to set the ACE_ROOT
+ environment<p>
+ <li>Change your umask to something like 022 <strong>if</strong> you want
+ others to be able to view your workspace.<p>
+ <li>% <code>cvs checkout ACE_wrappers</code><p>
+ <li>Add the ace/config.h and include/makeinclude/platform_macros.GNU
+ symlinks. For example, for Sun C++ on SunOS 5.5:
+ <pre><code>
+ % ln -s config-sunos5.5.h ace/config.h
+ % ln -s platform_sunos5_sunc++.GNU include/makeinclude/platform_macros.GNU
+ </code></pre><p>
+ <li>Hack away in your own workspace. All files have user write
+ permission.
+</ol><p>
+
+
+<hr><p>
+<h3>4. <a name="Windows NT setup">Windows NT setup</a></h3>
+Thanks to <a href="http://www.cs.wustl.edu/~brunsch/">Darrell Brunsch</a>
+and <a href="http://www.cs.wustl.edu/~irfan/">Irfan Pyarali</a> for
+providing this NT setup information. (It contains a site-specific
+<code>CVSROOT</code>.)<p>
+
+You can use the CVS client under Windows NT to keep a local repository
+of ACE. To set it up, follow these steps:<P>
+<ol>
+ <li>Find or create a directory in your path (I just created a utils
+ directory and added it to my path).<p>
+ <li>Download the files cvs.exe, patch.exe, and win32gnu.dll. They're
+ in a zip file on
+ <a href="http://download.cyclic.com/pub/cvs-1.10.5/windows/">Cyclic
+ Software's download site.</a> (Cyclic Software hsa been acquired
+ by SourceGear Corporation.)<p>
+
+ Alternatively, <a href="http://www.wincvs.org">WinCVS</a> provides
+ a graphical front-end on Windows. <strong>NOTE: </strong>if
+ you use WinCVS, beware that it enables read-only checkout by
+ default. So be sure not to check out that way if you want to
+ edit files.<p>
+
+ Thanks to <a href="http://www.riverace.com">Steve Huston</a> for that
+ note.<p>
+ <li>Be sure that the <a href="http://www.sourcegear.com/CVS">SourceGear</a>
+ cvs utilities precede any
+ <a href="http://www.cygnus.com/misc/gnu-win32/">Cygnus
+ GNU-Win32 utilities</a> in your path, something like this:<p>
+
+ <pre>
+ d:\utilities\cvs;D:\utilities\gnuwin32\b18\H-i386-cygwin32\bin
+ </pre>
+ <li>Add to your environment: <BR>
+ <code>LOGNAME = </code><em>username</em><br>
+ <code>CVSROOT = ace.cs.wustl.edu:/project/cvs-repository</code><br>
+</ol>
+Please note that this approach uses a remote shell. So, your
+account must be able to rsh to the server machine.<p>
+
+For an alternative approach that uses CVS pserver instead of rsh,
+please see Darrell's <a
+href="http://tao.cs.wustl.edu/howto/use_win32_pserver.html">CVS
+pserver page for Win32</a>.<p>
+
+
+<hr><p>
+<h3>5. <a name="Checking in changes">Checking in changes</a></h3>
+By convention, any repository change should be documented in
+an appropriate ChangeLog. The ChangeLog entry should start with
+a line of this form:
+<pre>
+ ChangeLogTag: <em>date</em> <em>name</em> &lt;<em>email address</em>&gt;
+</pre><p>
+
+In all examples below, <code>ChangeLog</code> refers to appropriate
+ChangeLog.<p>
+
+<h4>5.1. Command line</h4>
+ To enter your workspace changes into the master repository from
+ the command line::<p>
+<pre>
+ % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file(s)/directori(es)</em> ChangeLog
+</pre><p>
+
+<h4>5.2. From emacs</h4>
+ To checkin one file or directory to the repository:<p>
+<ol>
+ <li><code>C-x v v </code>(vc-next-action) to check the file or directory
+ in<p>
+ <li>Insert the ChangeLogTag, using the first line of your ChangeLog entry<p>
+ <li><code>C-c C-c </code> to finish checkin
+</ol><p>
+
+
+<hr><p>
+<h3>6. <a name="Workspace update">Workspace update</a></h3>
+To update your workspace from the master repository, to pick up changes
+by others:<p>
+ <blockquote>% <code>cvs update ACE_wrappers</code></blockquote><p>
+
+cvs will print out a line for each directory that it enters
+(by default, it will recurse through the directory tree; to
+disable this and only update one directory, add <code>-l</code>
+after <code>update</code>).<p>
+
+cvs will print out a line for each file that differs from what is
+in the repository. This first character indicates the file status:
+<ul>
+ <li><code>U</code> the file was brought <strong>up-to-date</strong>, so
+ now it agrees with what is in the repository
+ <li><code>P</code> same as <code>U</code>, except used by CVS server
+ when it sends a patch instead of the entire file
+ <li><code>M</code> the file is <strong>modified</strong> in your
+ workspace with respect to the repository; without any
+ other message, it means that the file was not modified
+ by this update operation. If changes were
+ successfully merged (without conflict), then cvs will
+ note on the previous lines.
+ <li><code>C</code> the file needs to be updated, but a
+ <strong>conflict</strong> was detected. The file now
+ contains the differences, demarcated with
+ <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code> and
+ <code>&gt;&gt;&gt;&gt;&gt;&gt;&gt;</code>. The
+ unmodified file was moved to <em>.#file.revision</em>.
+ You'll need to edit the file to resolve the
+ differences. I get a lot of false positives on files
+ that I know I didn't modify locally: for those cases,
+ I just remove the file and rerun update.
+ <li><code>A</code> or <code>R</code> The file has been
+ <strong>added</strong> or <strong>removed</strong>
+ to/from your workspace, but the add or
+ remove has not yet been committed.
+ <li><code>?</code> the file is <strong>private</strong> to your
+ workspace: it does not exist in the repository
+</ul>
+
+To show what update would do to the currently directory (recursively),
+without actually doing it:
+<blockquote>% <code>cvs -n update <strong>.</strong></code></blockquote>
+<blockquote>
+ The -q option to update suppresses the ``Updating'' message for each
+ directory:
+ <blockquote>%
+ <code>cvs -nq update <strong>.</strong></code></blockquote>
+</blockquote>
+
+To get the status of the current directory (recursively) with respect to
+the repository:
+<blockquote>% <code>cvs status <strong>.</strong></code></blockquote>
+
+To get the status of a single file with respect to the repository,
+with symbolic tags displayed:
+<blockquote>% <code>cvs status -v <em>file</em></code></blockquote>
+
+To show local (in current workspace) changes to one or more files,
+relative to the versions that they were checked out from:
+<blockquote>% <code>cvs diff <em>file(s)/directori(es)</em></code>
+</blockquote>
+
+To show local (in current workspace) changes to one or more files,
+relative to the latest versions in the repository:
+<blockquote>% <code>cvs diff -rHEAD <em>file(s)/directori(es)</em></code>
+</blockquote><p>
+
+
+<hr><p>
+<h3>7. <a name="Adding/removing files/directories">Adding/removing files/directories</a></h3>
+Adding one or more text files requires two steps:
+<pre>
+ % cvs add <em>file . . .</em>
+ % cvs commit <em>file . . .</em>
+</pre><br>
+The commit may be done later, on the entire directory, etc.
+Note that cvs <strong>add</strong> is not recursive, so
+that the files in each directory of a hierarchy must be
+added in separate commands. Also, only files in the current
+directory can be added.<p>
+
+Binary files require the <code>-kb</code> option to <code>cvs add</code>:
+<pre>
+ % cvs add -kb <em>file . . .</em>
+ % cvs commit <em>file . . .</em>
+</pre><br>
+If not applied during the <code>add</code> operation, <code>-kb</code>
+can be applied using <code>cvs admin -kb</code>.<p>
+
+Removing files is similar, except the cvs <strong>remove</strong>
+command is used instead of the <strong>add</strong> command:
+<pre>
+ % cvs remove <em>file . . .</em>
+ % cvs commit <em>file . . .</em>
+</pre><p>
+
+An add of an empty directory doesn't require a commit.<p>
+
+Removing a directory is more problematic. There is no CVS command to
+remove (or rename) a directory: it has to be done behind CVS' back,
+directly in the repository. This is by design; a CVS command can't be
+used to irrevocably destroy information. Therefore, never remove a
+directory. You can safely remove all of the files in it, using the
+above steps.
+
+To just remove a directory from a workspace (without removing it from
+the repository): first, remove the directory and all of its files
+using usual OS commands. Second, run
+<pre>
+ % cvs update -P <em>directory-path </em>
+</pre><br>
+to prune the directory from the workspace.<p>
+
+
+<hr><p>
+<h3>8. <a name="Modules">Modules</a></h3>
+Instead of referring to ``ACE_wrappers'' above, you can refer
+to a module, such as ace, tests, performance-tests, and so on.
+To get a list of known modules, use the -c option to checkout:
+<blockquote>% <code>cvs checkout -c</code></blockquote><p>
+
+<strong>IMPORTANT</strong>: if a subdirectory is added to ACE, it
+<strong>must</strong> be added to the list of known modules in
+<code>$CVSROOT/CVSROOT/modules</code>! If you don't want to edit that
+file, please tell <a href="mailto:levine@cs.wustl.edu">David</a>. The
+<code>CVSROOT</code> files are under RCS control. emacs' VC tools
+handle them the same way that they handle CVS-controlled files. So,
+you can check them out and back in with <code>C-x v v</code>.<p>
+
+To add an entirely new module:
+<ol>
+ <li>Create the directories/files.<p>
+ <li>Add the module to <code>$CVSROOT/CVSROOT/modules</code>, as
+ mentioned above.<p>
+ <li>Create a new directory in <code>$CVSROOT</code>, owned by the appropriate
+ group and with sufficient (probably group write+setuid) permissions.<p>
+ <li>Change to the directory just above the top-level directory for
+ the module in your workspace.<p>
+ <li><code>cvs checkout <em>new module name</em></code><p>
+ <li>Add all of the new directories/files in the module, as described
+ <a href="#Adding/removing files/directories">above</a>, then commit.
+</ol>
+
+
+<hr><p>
+<h3>9. <a name="ChangeLog updates">ChangeLog updates</a></h3>
+To automatically update the ChangeLog, use the emacs command:
+<pre>
+ C-u C-x v a
+</pre>
+Thanks to James Hu &lt;jxh@cs.wustl.edu&gt; for this useful tidbit.<p>
+
+To set a specific host address in your ChangeLog entries, add a line
+like this to your <code>~/.emacs</code>:
+<pre>
+ (setq mail-host-address "cs.wustl.edu")
+</pre><p>
+
+To set a specific name in your ChangeLog entries, add a line like
+this to your <code>~/.emacs</code>:
+<pre>
+ (setq user-full-name "my full name")
+</pre>
+Otherwise, CVS uses the name (GECOS field) from your passwd entry.<p>
+
+
+<hr><p>
+<h3>10. <a name="File revisions">File revisions</a></h3>
+File revisions in and below the current directory may be tagged with:
+<pre>
+ % cvs tag <em>tag</em> <strong>.</strong>
+</pre><p>
+
+To retrieve an old revision of a file, use the -r option to cvs
+<strong>update</strong>:
+<pre>
+ % cvs update -r<em>tag file</em>
+</pre>
+The revision tags of a file can be viewed
+with the cvs <strong>log</strong> command.<p>
+
+Or, to retrieve the file and/or directory versions as of a
+certain date and time, use the -D option to cvs <strong>update</strong>,
+for example:
+<pre>
+ % cvs update -D "last Saturday" OS.{h,i,cpp}
+</pre>
+
+<strong>NOTE: </strong>The -r and -D options are ``sticky''; they will
+apply to the file(s)/directories until overwritten with another revision
+tag or date, or until disabled.
+They are disabled by using the update -A option, which also checks out
+the latest revision:
+<pre>
+ % cvs update -A <em>file</em>
+</pre><p>
+
+To change the log message for a particular revision of a file:<p>
+<pre>
+ % cvs admin -m<em>revision</em>:"<em>new message</em>" <em>file</em>
+</pre><p>
+
+
+<hr><p>
+<h3>11. <a name="File reversion">File reversion</a></h3>
+There are a few ways to revert a file to the last revision that is in
+the repository, if you want to abandon your changes to it:
+
+<ul>
+ <li>The easiest way to abandon your changes <strong>in your
+ workspace</strong> is to use the emacs command <code>C-x v u </code>
+ (vc-revert-buffer). Or from the shell, you could remove the
+ file and update it with <code>cvs update <em>file</em></code>.<p>
+
+ <li><strong>Do not remove a revision from the cvs repository
+ directly.</strong> To revert a revision that you made, use the
+ following command to revert the change in your workspace and
+ check in the reverted version:
+<pre>
+ % cvs update -j<em>after_change</em> -j<em>before_change</em> <em>file</em>
+</pre>
+ For example, if the version containing the version you want to
+ revert is 4.10, then, <em>after_change</em> should be
+ <code>4.10</code> and <em>before_change</em> should be
+ <code>4.9</code>.<p>
+
+ <strong>NOTE:</strong> this doesn't seem to work with CVS version 1.10.<p>
+
+ Make sure the patch succeeded (if you are not reverting a change
+ you made long time ago, most likely it will succeed) before
+ checking in the reverted version.<p>
+
+ Also make sure the you add a ChangeLog entry explaining why
+ you reverted the change.
+</ul>
+
+<hr><p>
+<h3>12. <a name="Renaming a file">Renaming a file</a></h3>
+There are three ways to rename a CVS-controlled file. The first
+preserves the revision log, but it must be accessed by either the
+original or new name, depending on what you want to see. And
+revision numbers will start over at 1.0 unless set with the
+<code>-r</code> option. It's all done in the user's workspace:
+<pre>
+ Add ChangeLog entry containing:
+ Renamed <em>OLD</em> to <em>NEW</em>
+ % mv <em>OLD</em> <em>NEW</em>
+ % cvs remove <em>OLD</em>
+ % cvs add <em>NEW</em>
+ % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>OLD</em> <em>NEW</em> ChangeLog
+</pre><br>
+
+The second method maintains the revision log in one place and the
+revision number sequence. It makes fetching old releases of the
+module more difficult, which may be an advantage or disadvantage
+depending on local circumstances. It is more dangerous because the
+repository is modified directly; see the warning in the cvs info page
+about other users accessing the history file while it is being moved:
+<pre>
+ % cd $CVSROOT/<em>MODULE</em>
+ % mv <em>OLD</em>,v <em>NEW</em>,v
+</pre><br>
+
+The third method is to copy the history file in the repository.
+Instead of moving the history file, as in the second method above,
+copy it. It's not necessary to prevent others from accessing the
+file. The cvs info pages show other steps, to remove the old tags
+from the new history file. While technically correct, I don't think
+that's necessary for our purposes.<p>
+
+While the first method is the safest, it has the distinct disadvantage
+of hindering access of old versions. If that's not a problem for a
+particular file, then it is the preferred approach. As Carlos would
+probably say if you asked him, ``it's the right thing to do.''<p>
+
+If easy access to old versions is desired, I would use the third
+approach: copy the history file in the repository.<p>
+
+
+<hr><p>
+<h3>13. <a name="Local version control">Local version control</a></h3>
+All version control with CVS is done through the master repository.
+CVS doesn't provide any facility for local checkpoints. If you want
+local version control in your workspace, there's nothing to stop you
+from using RCS or SCCS locally (but it might confuse emacs' version
+control). The preferred approach is to create a branch, and
+checkpoint as much as you want on that branch. When the time comes to
+make the changes public, just merge the branch. See the <a
+href="#Branches">Branches</a> section of this page, and the cvs man
+page, for instructions on creating and using a branch.<p>
+
+
+<hr><p>
+<h3>14. <a name="Branches">Branches</a></h3>
+To create a branch, you must first create a tag to identify the
+branch. Then, you can checkout on that branch. There are various
+ways to go about doing this, but these steps show how when starting
+from scratch:
+
+<pre>
+ % cvs rtag -b <em>branch_tag</em> <em>module(s)</em>
+ % cvs checkout -r <em>branch_tag</em> <em>module(s)</em>
+</pre>
+
+It's not necessary to checkout all the files in a directory or module
+on the branch, but it's probably the easiest and least confusing
+approach in the long run. <strong>Note</strong> that it's usually
+tricky to tag individual files on a branch because CVS won't
+be able to identify which module they're in. By way of example,
+to checkout just <code>ace/OS.h</code> on a branch, you'd have to do
+this, assuming that you're already in the <code>ace</code> directory:
+<pre>
+ % cd ..
+ % cvs rtag -b <em>branch_tag</em> ace/OS.h
+ % cvs checkout -r <em>branch_tag</em> ace/OS.h
+ % cd ace
+</pre>
+This can be done after modifying files, and CVS will retain your
+modifications. However, if you don't trust CVS, it's best to backup
+your files first.<p>
+
+Checkouts on a branch are sticky, and will apply until the head
+version of the file(s) have been checked out with the <code>-A</code>
+option to <code>cvs update</code>. Presumably, this will be done
+after merging the branch to the main trunk. See the
+<a href="#Old file revisions">Old file revisions</a> section of this
+page for similar discussion of sticky tags.<p>
+
+To merge an entire branch to the main trunk, use the <code>-j</code>
+(for <em>join</em>) option to <code>cvs checkout</code>. That just
+merges in your workspace; the repository can then be updated from the
+workspace using <code>commit</code> as usual:
+<pre>
+ Add ChangeLog entry containing:
+ merged <em>branch_tag</em>
+ % cvs checkout -P -Aj <em>branch_tag</em> <em>file(s)/directori(es)</em>
+ % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file(s)/directori(es)</em> ChangeLog
+</pre>
+(The <code>-A</code> is needed if you are in the workspace that has
+the checkouts on the branch. It updates the workspace to the latest
+versions on the main trunk. So, <strong>don't</strong> use it if
+you want to keep working on the branch.)<p>
+
+To merge any changes on the main trunk to a branch, the first time:
+<pre>
+ Add ChangeLog entry containing:
+ merged main trunk changes
+ % cvs update -jHEAD <em>file(s)/directori(es)</em>
+ % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file(s)/directori(es)</em> ChangeLog
+ % cvs tag <em>merged_foo_branch</em> <em>file(s)/directori(es)</em>
+</pre>
+
+<strong>AFTER MERGING, APPLY A LABEL TO THE SOURCE BRANCH,
+as shown above.</strong>
+For example, if you merged from the main trunk to a branch,
+apply a new label to the main trunk. You can use that label
+later to merge any subsequent changes on the main trunk. The
+<code>cvs</code> info pages have a good example of this.
+Briefly:
+
+<pre>
+ Add ChangeLog entry containing:
+ merged main trunk changes
+ % cvs update -j<em>merged_foo_branch</em> -jHEAD <em>file(s)/directori(es)</em>
+ % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file(s)/directori(es)</em> ChangeLog
+ % cvs tag <em>merged_foo_branch_again</em> <em>file(s)/directori(es)</em>
+</pre>
+
+
+Note that any files created on the branch won't be visible on
+the main trunk, even after the merge. I'm not sure of right
+way to take care of this, but I follow these steps for each
+file created on the branch:<p>
+<ol>
+ <li>In the repository, move the RCS file from the <var>Attic</var>
+ directory up to its parent directory.
+ <li>Edit the RCS file, replacing the "dead" state with "Exp".
+ <li>Merge from the branch to the main trunk:
+ <pre>
+ Add ChangeLog entry containing:
+ merged <em>branch_tag</em>
+ % cvs update -Aj <em>branch_tag</em> <em>file</em>
+ % cvs commit -m "ChangeLogTag: `head -1 ChangeLog`" <em>file</em> ChangeLog
+ </pre>
+</ol>
+
+To create a file on a branch, in a directory that has not been
+checked out on the branch:
+<ol>
+ <li>Add the file and commit it to the main branch
+ <li>Create the branch tag on the file, and check the file out
+ on the branch.
+ <li>Remove the file, cvs remove the file, and commit the removal.
+ <li>Check the file out on the branch.
+</ol>
+Alternatively, the recommended procedure is to simply check the
+entire directory out on the branch, then create the file.<p>
+
+In general, deleting branch tags is not recommended. But it's often
+necessary, especially when getting started with branches. The
+<code>-d</code> option to <code>cvs rtag</code> can be used to delete
+a branch tag.<p>
+
+The use of a branch for maintaining a release is illustrated
+in the section on the <a href="#ACE release bug-fix branch">ACE
+release bug-fix branch</a>.<p>
+
+
+<hr><p>
+<h3>15. <a name="Remote repositories">Remote repositories</a></h3>
+Before setting up a repository for remote access, be sure to see
+the <a href="file:/project/doc/pkg/cvs/cvs-1.10/doc/cvs.ps">CVS
+documentation</a>. There are important security considerations.<p>
+
+An easy way to access a remote repository is via rsh. These steps
+ought to get you going:
+<ol>
+ <li>Install cvs on the local system, if it doesn't already have it.<p>
+ <li>Add yourself to an <code>.rhosts</code> file on the remote machine
+ of a user that can access the repository.<p>
+ <li>Set your <code>CVSROOT</code> environment variable to:<br>
+ <pre>
+ <em>remote user</em>@<em>remote host</em>:<em>remote repository</em>
+ </pre>
+</ol>
+Then, you can issue cvs commands just as you would on the remote machine.<p>
+
+If you have ssh on your client machine, you can use ssh instead of
+rsh. Just set your <code>CVS_RSH</code> environment variable to
+<code>ssh</code>. You don't need to add an <code>.rhosts</code>
+entry with ssh, so it's the best alternative for remote repository
+access.<p>
+
+Another way to access to remote cvs repository is to run cvs in
+client-server mode. To use this feature, first check if you have your
+<code>HOME</code> environment variable set properly. Then, set your
+<code>CVSROOT</code> to:<p>
+<pre>
+ :pserver:your_user_id@ace.cs.wustl.edu:/project/cvs-repository
+</pre><p>
+Then, do a cvs login as
+<pre>
+ % cvs login
+</pre><p>
+Type in your password when CVS prompts you to enter your password.
+This will create a file call "<code>.cvspass</code>" in your home
+directory (as defined by <code>$HOME</code>) that contains the
+encripted password for the server. You can now perform regular CVS
+operation directly.<p>
+
+<strong>Notice:</strong> It's not difficult to decode the passwords in
+<code>.cvspass</code> file. Therefore, never use cvs in client-server
+mode in a unsafe environment. (Where others can read your .cvspass
+file.)<p>
+
+To speed up client-server mode operations, it might help to use
+the <code>cvs</code> <code>-z</code> option. It requires that
+<code>gzip</code> be on your search path on both the client and
+server. An example use is:<p>
+<pre>
+ % cvs -z 1 update
+</pre><p>
+
+Thanks to <a href="http://www.cs.wustl.edu/~nanbor/">Nanbor Wang</a>
+and <a href="http://www.cs.wustl.edu/~brunsch/">Darrell Brunsch</a>
+for figuring out and providing this documentation for cvs
+client-server mode.<p>
+
+
+<hr><p>
+<h3>16. <a name="Exporting from CVS">Exporting from CVS</a></h3>
+There are two different strategies for exporting CVS-controlled files,
+such as for code releases. The first, preferred approach is to use
+the cvs <strong>export</strong> command to stage a version of the
+controlled files to a non-controlled directory. This version will
+not have any of the CVS files in it. THe second approach is to
+create a release from a user's CVS-controlled workspace.<p>
+
+To use cvs <strong>export</strong>, either a date or revision
+tag must be specified. It's usually a good idea to tag the sources
+with a revision tag and use that. So, the steps would be:<br>
+<pre>
+ % cd <em>root of directory tree</em>
+ % cvs tag <em>tag</em> <strong>.</strong>
+ % cd <em>staging directory</em>
+ % cvs export -r <em>tag</em>
+ % find . -print | cpio -o -H tar | gzip -9 &gt; <em>tar filename</em>
+</pre>
+
+To tag and create a release in the form of a gzip'ped tar file
+from a user's workspace:
+<pre>
+ % cd <em>root of directory tree</em>
+ % cvs tag <em>tag</em> <strong>.</strong>
+ % find . -name CVS -prune -o -print | cpio -o -H tar | gzip -9 &gt; <em>tar filename</em>
+</pre>
+
+The relative advantage of the first, export approach is that you will
+be sure that only CVS-controlled files will be released. However, it
+requires the extra step and creation of the staging area.<p>
+
+This extra step is one reason why we don't currently stage releases of
+ACE. Instead, they are built from Doug's personal workspace. That
+workspace is visible on the web, so that ACE users can track the very
+latest changes without any explicit action by Doug. If we were to
+stage it, to make any change visible would require an explicit move to
+the staging area.<p>
+
+
+<hr><p>
+<h3>17. <a name="ACE_wrappers-frozen workspace">ACE_wrappers-frozen workspace</a></h3>
+
+This section applies to the DOC group at Wash. U. only:<p>
+
+There's now a ``frozen'' ACE in
+<strong>/project/cvs-repository/ACE_wrappers-frozen/</strong>.
+It contains the latest official release of ACE.<p>
+
+There are complete g++ 2.7.2.1 and Sun C++ 4.2 builds in the
+<strong>build</strong> directory below the directory noted above.
+To use one of these builds, set or prepend to these environment variables:<p>
+<table border>
+<tr>
+<th>Compiler</th>
+<th>set <strong>WRAPPER_ROOT</strong> to:</th>
+<th>prepend to <strong>LD_LIBRARY_PATH</strong>:</th>
+<tr>
+<td>g++</td>
+<td>/project/cvs-repository/ACE_wrappers-frozen/build/SunOS5_g++</td>
+<td>/project/cvs-repository/ACE_wrappers-frozen/build/SunOS5_g++/ace</td>
+<tr>
+<td>Sun C++</td>
+<td>/project/cvs-repository/ACE_wrappers-frozen/build/SunOS5_sunc++-4.2</td>
+<td>/project/cvs-repository/ACE_wrappers-frozen/build/SunOS5_sunc++-4.2/ace</td>
+</table><p>
+
+
+<hr><p>
+<h3>18. <a name="ACE release bug-fix branch">ACE release bug-fix branch</a></h3>
+
+This section applies to the DOC group at Wash. U. only:<p>
+
+The ``main line'' CVS branch will (continue to) be the ``new features''
+branch. If you want the very latest and greatest ACE at all times, no
+changes to the use of your workspace are required. Just
+<code>cvs update</code> it as usual.<p>
+
+Bug fixes to the official release will go on a branch. For the ACE
+4.2 release, for example, this branch is name
+<strong>ACE-4_2</strong>. (CVS does not allow periods in branch names
+or any other tags.) To use it, do this in your workspace:
+<pre>
+ % cd ..
+ % cvs checkout -r ACE-4_2 ACE_wrappers
+</pre>
+
+From that point on, all updates and commits in that workspace
+will be from/to the <strong>ACE-4_2</strong> branch.<p>
+
+
+<hr><p>
+<h3>19. <a name="Warning messages/problems">Warning messages/problems</a></h3>
+<dl>
+<blockquote>
+
+ <dt><pre>cvs update: conflict: <em>foo </em>is modified but no longer in the repository<br>
+U <em>bar</em></pre>
+ <dd>That might indicate that file <em>foo</em> was renamed to <em>bar</em>.
+ If so, <em>foo</em> should be removed from the current workspace. (And
+ that warning will not reoccur for the workspace, because its CVS will
+ have removed <em>foo</em> from the workspace entries and checked out
+ <em>bar</em>.)<p>
+
+ <dt><pre>cvs update: [<em>time</em>] waiting for <em>user</em>'s lock in <em>repository</em></pre>
+ <dd>Check for lock files and directories in the <code>$CVSROOT/CVSROOT</code>
+ and lock files anywhere in the <code>$CVSROOT</code> hierarchy. Remove
+ ones that no longer appear to be in use and retry. Lock files and
+ directories have names starting with ``.#'', I think.<p>
+
+ <dt>Why does a file in the repository not have group and/or other read
+ permission?<p>
+ <dd>Because it didn't have those permissions when it was added to the
+ repository. To fix it, those permissions can be added to the ,v file in
+ the repository. To avoid it, those permissions should be added to the
+ file before it is created/committed the first time.<p>
+
+ <dt>Why does CVS keep removing group/and or other read permission from a
+ file in my workspace?<p>
+ <dd>Because your umask is something like 7 or 77. Change it to something
+ like 22. If you don't want to change it for everything, then alias cvs;
+ in t/csh:<br>
+ <blockquote>% <code>alias cvs '(umask 22; \cvs \!*)'</code></blockquote>
+ <p>
+ Also, the file will have to have mode 644 before you commit it. So if
+ your editor removes group/other read permission, you'll have to ``fix''
+ that as well.<p>
+
+ <dt>I modified Makefile in my workspace so I don't build static or shared
+ ACE libraries. But, I forgot about it and commited the modified
+ Makefile to the repository. Help?<p>
+ <dd>You'll have to correct the Makefile and commit your corrections.<p>
+
+ Instead of modifying your makefile, try these commands to build the
+ ACE static and shared libraries, respectively:
+ <blockquote>% make <code>static_libs_only=1</code></blockquote>
+
+ <blockquote>% make <code>shared_libs_only=1</code></blockquote>
+
+</blockquote>
+</dl><p>
+
+
+<hr><p>
+<h3>20. <a name="For more info on CVS">For more info on CVS</a></h3>
+Please see these sources for more information on CVS:
+<ul>
+ <li>David Discher's <a href="http://dpd.dpdtech.com/cvs/">Quick N
+ Dirty CVS HOW-TO</a> is really helpful.<p>
+
+ <li>Please check out David G. Grubbs' great, comprehensive <a
+ href="http://cellworks.washington.edu/pub/docs/cvs/cvs-FAQ/cvsfaq0.html">"The
+ CVS FAQ"</a>.<p>
+
+ <li><a href="http://www.loria.fr/~molli/cvs-index.html">CVS Bubbles</a>
+ is a collection of useful CVS information and links.<p>
+
+ <li>Commercial support for CVS is available from <a
+ href="http://www.sourcegear.com/CVS">SourceGear Corporation</a>.
+ Their web pages are very helpful.<p>
+
+ <li>Terris Linenbach has an interesting, brief discussion of
+ source code management on-line at <a
+ href="http://devguy.com/fp/ProgrammersCanvas">Programmers'
+ Canvas</a>. Programmers' Canvas is a pattern language,
+ also quite interesting.
+</ul>
+
+<p><hr>
+<p>Back to
+<a href="http://www.cs.wustl.edu/~levine">David L. Levine's home page</a>.
+<p>
+
+
+
+<font size=-1>
+Last modified 11:15:16 CDT 30 September 2002.
+<br>
+[an error occurred while processing this directive]
+[an error occurred while processing this directive]
+<p>
+</font>
+
+
+
+</body>
+</html>
diff --git a/ACE/docs/README.tutorials b/ACE/docs/README.tutorials
new file mode 100644
index 00000000000..8c84c98b1b5
--- /dev/null
+++ b/ACE/docs/README.tutorials
@@ -0,0 +1,7 @@
+# $Id$
+
+ACE tutorials can be found in the following directories:
+
+. examples/C++NPv1 - C++ Network Programming Volume 1 examples.
+. examples/C++NPv2 - C++ Network Programming Volume 2 examples.
+. examples/APG - ACE Programmer's Guide examples
diff --git a/ACE/docs/Symbol_Versioning.html b/ACE/docs/Symbol_Versioning.html
new file mode 100644
index 00000000000..6d4dcdddd51
--- /dev/null
+++ b/ACE/docs/Symbol_Versioning.html
@@ -0,0 +1,230 @@
+<!-- $Id$ -->
+
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+ <head>
+ <title>Symbol Versioning in ACE</title>
+ </head>
+
+ <body>
+ <h1>Symbol Versioning in ACE</h1>
+
+ <p>
+ To provide a means for ACE-based application developers to avoid
+ symbol conflicts when multiple versions of ACE are linked to an
+ application ACE supports <em>versioned namespaces</em>. When
+ enabled (disabled by default), ACE's versioned namespace support
+ causes all ACE symbols (classes, free functions, etc) to be
+ placed within a C++ namespace of the form "<code>namespace
+ ACE_5_5_1</code>". For example, the <code>ACE_Reactor</code>
+ would end up being placed in the versioned namespace like so:
+ </p>
+
+ <blockquote>
+ <code>
+<pre>
+ namespace ACE_5_5_1
+ {
+ class ACE_Reactor
+ {
+ ...
+ };
+ }
+ using namespace ACE_5_5_1;
+</pre>
+ </code>
+ </blockquote>
+
+ <p>
+ Notice that a <code>using</code> clause exposes the ACE types
+ embedded in the versioned namespace back to the global
+ namespace. This maximizes source code compatibility. ACE
+ itself does this through the use of two macros:
+ </p>
+ <ul>
+ <li>
+ <code>ACE_BEGIN_VERSIONED_NAMESPACE_DECL</code><br>
+ <ul>
+ <li>
+ Expands to "<code>namespace ACE_VERSIONED_NAMESPACE NAME
+ {</code>", where
+ <code>ACE_VERSIONED_NAMESPACE_NAME</code> by defaults to
+ namespace name of the form
+ <code>ACE_<em>major</em>_<em>minor</em>_<em>beta</em></code>.
+ Users may override the default by defining the
+ <code>ACE_VERSIONED_NAMESPACE_NAME</code> preprocessor
+ symbol in their <code><strong>ace/config.h</strong></code>
+ header file.
+ </li>
+ </ul>
+ </li>
+ <li>
+ <code>ACE_END_VERSIONED_NAMESPACE_DECL</code>
+ <ul>
+ <li>
+ Expands to "<code>} using namespace
+ ACE_VERSIONED_NAMESPACE_NAME;</code>", where
+ <code>ACE_VERSIONED_NAMESPACE_NAME</code> is described
+ above.
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <h2>Things ACE-based Application Developers Should Know</h2>
+ <p>
+ Every effort has been made to make the versioned namespace
+ support in ACE as transparent as possible, including transparent
+ versioned symbol support in the ACE_Service_Configurator when
+ the ACE_Service_Configurator macros, such as <em>e.g.</em>,
+ <code>ACE_FACTORY_DECLARE</code>, are used appropriately. No
+ changes to service configurator directives are necessary. For
+ example, the <code>ACE_Service_Configurator</code> will
+ transparently mangle the factory function name in a service
+ configurator directive on-the-fly, meaning it will only load a
+ "versioned" factory function name. This allows multiple service
+ object factory functions, for example, to coexist in the same
+ process space.
+ </p>
+ <p>
+ There is, however, at least one caveat with respect to source
+ code compatibility: any forward declarations of ACE symbols must
+ also be placed within the versioned namespace. For example, if
+ you have a forward declaration for <code>ACE_Reactor</code> in
+ your application code, you will need to place it within the
+ configured ACE versioned namespace as follows:
+ </p>
+ <blockquote>
+ <code>
+<pre>
+ ACE_BEGIN_VERSIONED_NAMESPACE_DECL
+ class ACE_Reactor;
+ ACE_END_VERSIONED_NAMESPACE_DECL
+</pre>
+ </code>
+ </blockquote>
+ <p>
+ This must only be done once, as these macros hide the versioned
+ namespace name details from the application. Alternatively, you
+ could place the forward declaration in a namespace that is an
+ alias of the ACE versioned namespace, <em>e.g.</em>:
+ </p>
+ <blockquote>
+ <code>
+<pre>
+ namespace Foo = ACE_VERSIONED_NAMESPACE_NAME;</code>
+ namespace Foo {
+ class ACE_Reactor;
+ }
+ using namespace Foo;
+</pre>
+ </code>
+ </blockquote>
+ <p>
+ Versioned namespace support in ACE may be enabled by adding
+ <code>versioned_namespace=1</code> to your MPC
+ <code><strong>default.features</strong></code> file.
+ </p>
+
+ <h2>Things ACE Developers Should Know</h2>
+ <p>
+ ACE developers should place all ACE symbols that are potentially
+ exposed to the user, including forward declarations in a
+ versioned namespace using the
+ <code>ACE_BEGIN_VERSIONED_NAMESSPACE_DECL</code> and
+ <code>ACE_END_VERSIONED_NAMESPACE_DECL</code> macros. Free
+ functions that are declared to have a C calling convention
+ (<em>i.e.</em>, <code>extern "C"</code>) should have their names
+ mangled using the <code>ACE_PREPROC_CONCATENATE</code>
+ preprocessor. For example:
+ </p>
+ <blockquote>
+ <code>
+<pre>
+ void ACE_func (void) { ... }
+ ...
+ ACE_func(); // Call ACE_func()
+</pre>
+ </code>
+ </blockquote>
+ <p>
+ becomes:
+ </p>
+ <blockquote>
+ <code>
+<pre>
+ #if (defined (ACE_HAS_VERSIONED_NAMESPACE) \
+ && ACE_HAS_VERSIONED_NAMESPACE == 1) \
+ && !(defined (_MSC_VER) && _MSC_VER <= 1200)
+ // MSVC++ 6's preprocessor can't handle macro expansions
+ // required by the versioned namespace support. *sigh*
+
+ # define ACE_FOO_FUNC_NAME ACE_PREPROC_CONCATENATE(ACE_VERSIONED_NAMESPACE_NAME, _ACE_foo_func)
+
+ #else
+
+ # define ACE_FOO_FUNC_NAME ACE_foo_func
+
+ #endif /* ACE_HAS_VERSIONED_NAMESPACE == 1 */
+
+ ...
+ void ACE_FOO_FUNC_NAME (void) { ... }
+
+ ACE_FOO_FUNC_NAME(); // Call mangled ACE_foo_func().
+</pre>
+ </code>
+ </blockquote>
+ <p>
+ The <code>ACE_PREPROC_CONCATENATE</code> is used rather than a
+ straight <code>##</code> preprocessor concatenation since in the
+ latter case preprocessor symbols like
+ <code>ACE_VERSIONED_NAMESPACE_NAME</code> will not be expanded
+ if they are concatenated. <code>ACE_PREPROCE_CONCATENATE</code>
+ forces the preprocessor to expand them during the argument
+ prescan by calling a macro that itself calls another that
+ performs the actual concatenation.
+ </p>
+ <h3>General Guidelines</h3>
+ <ul>
+ <li>
+ Versioned namespace macro/support must be added to all new files
+ added to ACE.
+ </li>
+ <li>
+ Do not place include directives between
+ <code>ACE_BEGIN_VERSIONED_NAMESPACE_DECL</code> and
+ <code>ACE_END_VERSIONED_NAMESPACE_DECL</code> macros. Doing
+ so will cause nested namespace to be created, which is not
+ the desired affect.
+ </li>
+ <li>Be aware of preprocessor conditional blocks when placing the
+ versioned namespace macros. For example, if you open
+ versioned namespace within a given preprocessor condition
+ block, you'll most likely want to close it in the same
+ block.
+ </li>
+ <li>
+ If necessary, reopen and close the versioned namespace
+ multiple times in the same file by using the macros multiple
+ times to address the concerns described in the above two
+ items.
+ </li>
+ <li>
+ The <code>$ACE_ROOT/bin/fuzz.pl</code> script has a sanity
+ checking test for versioned namespaces that may be of use when
+ debugging nested namespace issues, and for detecting
+ <code>BEGIN</code>/<code>END</code> mismatches.
+ </li>
+ </ul>
+ <p>
+ Versioned namespace support in ACE may be enabled by adding
+ <code>versioned_namespace=1</code> to your MPC
+ <code><strong>default.features</strong></code> file.
+ </p>
+ <hr>
+ <address><a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a></address>
+<!-- Created: Fri Mar 17 08:35:50 PST 2006 -->
+<!-- hhmts start -->
+Last modified: Fri Mar 17 20:47:41 PST 2006
+<!-- hhmts end -->
+ </body>
+</html>
diff --git a/ACE/docs/ace_guidelines.vsmacros b/ACE/docs/ace_guidelines.vsmacros
new file mode 100644
index 00000000000..2218c1a14ba
--- /dev/null
+++ b/ACE/docs/ace_guidelines.vsmacros
Binary files differ
diff --git a/ACE/docs/exceptions.html b/ACE/docs/exceptions.html
new file mode 100644
index 00000000000..e014a807601
--- /dev/null
+++ b/ACE/docs/exceptions.html
@@ -0,0 +1,655 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<!-- $Id$ -->
+<html> <head>
+<title>Using ACE Exception Handling Macros to Enhance CORBA Portability</title>
+</head>
+
+<body text="#000000" link="#0000ff" vlink="#cc0000" bgcolor="#ffffff">
+<Hr><P>
+<h3>Using ACE Exception Handling Macros to Enhance CORBA Portability</h3>
+
+<P>CORBA <CODE>Environment</CODE> arguments provide a way to handle
+exceptions when native c++ exception handling is unavailable or
+undesirable. However, writing portable code using both native C++
+exception handling and <CODE>CORBA::Environment</CODE> objects is very
+hard. If you plan to write portable code that must run on platforms
+that do not have native C++ exceptions, therefore, we recommend you
+use the ACE exception macros. This document explains how these macros
+can help alleviate much of the accidental complexity. However, keep
+in mind macros cannot solve all problems perfectly. </P>
+
+<P>Before reading the rest of this document, we recommend you check
+out pages 307 through to 322 in the book, <A
+HREF="http://cseng.aw.com/bookdetail.qry?ISBN=0-201-37927-9&ptype=0">Advanced
+Corba Programming with C++</A> by <A
+HREF="http://www.triodia.com/staff/michi-henning.html">Michi
+Henning</A> & <A HREF="http://www.iona.com/hyplan/vinoski/">Steve
+Vinoski</A>. Likewise, we recommend that you read the Error Handling chapter from the
+<A HREF="http://www.theaceorb.com/product/">TAO Developer's Guide</A>.
+
+<P><HR><P>
+<h3>Table of Contents</h3>
+<ul>
+ <li><a href="#nutshell">ACE Try Macros in a Nutshell</a>
+ <li><a href="#examples">Examples</a>
+ <li><a href="#general">General Guidelines for Exception Handling</a>
+ <li><a href="#transition">Transition from ACE_TRY_ENV usage to the
+ ACE_ENV_ARG macros</a>
+ <li><a href="#caveats">Some Caveats</a>
+</ul>
+
+<HR><P>
+<h3><a name="nutshell">ACE Exception Macros in a Nutshell</h3>
+
+<P>This section explains some simple rules of writing programs for
+platforms with and without native exception support using ACE's
+exception macros.
+</P>
+<P>ACE exception macros are modelled like C++ language exceptions and
+can be used like them, but with a small difference. These macros
+rely on the CORBA::Environment variable to handle exceptions
+on platforms that do not support exception
+handling. (Please note that native exceptions can be turned on
+or off at COMPILE time as an option to your make)
+The exception macros have been modelled with some extra rules to
+ensure this works even on
+platforms without native exception support. See some <a
+href="#examples">quick examples</a> on how to use ACE exception
+macros.
+</P>
+<ol>
+ <li><P><em>Declaration of CORBA::Environment Parameter at Methods</em><br>
+ On platforms lacking native exceptions, all CORBA methods take an
+ extra parameter added at the end of their argument list. This
+ last parameter holds the CORBA::Environment variable.
+ However, on systems with native exceptions, no such extra method
+ parameter is added.<br>
+ In order for both configurations to work with the same source code,
+ following macros are defined. In native exception configurations,
+ they all resolve to <em>empty</em>.</p>
+ <ul>
+ <li><p><em>ACE_ENV_ARG_DECL</em></p>
+ in the pseudo exception configuration resolves to
+ <pre>
+ , CORBA::Environment ACE_TRY_ENV
+ </pre>
+ It is used for declaring the extra Environment parameter
+ at CORBA methods that take one or more regular parameters.
+ The fact that the comma is part of the macro substitution
+ caters for the hiding of this added argument when native
+ exceptions are used. However, by the same virtue its
+ usage is a bit peculiar -<br>
+ Example: a CORBA IDL defined method
+ <pre>
+ void mymethod (in boolean b);
+ </pre>
+ may be declared as follows in C++:
+ <pre>
+ void mymethod (CORBA::Boolean b ACE_ENV_ARG_DECL);
+ </pre>
+ Notice the missing comma before the ACE_ENV_ARG_DECL.
+ This notation is necessary because when using native exceptions,
+ also the presence of the comma before the (non-existent)
+ CORBA::Environment parameter must be hidden.</p>
+ </li>
+ <li><p><em>ACE_ENV_SINGLE_ARG_DECL</em></p>
+ is similar to <code>ACE_ENV_ARG_DECL</code>, but is used when
+ the method takes no other parameters. It is necessary as a
+ separate macro because it does not contain the leading comma
+ that <code>ACE_ENV_ARG_DECL</code> does.
+ Example: a CORBA IDL defined method
+ <pre>
+ void mymethod ();
+ </pre>
+ may look like this in C++:
+ <pre>
+ void mymethod (ACE_ENV_SINGLE_ARG_DECL);
+ </pre>
+ <li><p><em>ACE_ENV_ARG_DECL_WITH_DEFAULTS</em>,
+ <li><em>ACE_ENV_SINGLE_ARG_DECL_WITH_DEFAULTS</em></p>
+ are similar to the above two macros but add a default value
+ to the parameter declaration. In case of TAO, the default value
+ is <code>TAO_default_environment()</code>.<p>
+ Notice that these macros are only used at the declaration
+ of methods (usually in header files), not at their definition
+ (usually in implementation files.) At the definition,
+ instead use the corresponding macro without "_WITH_DEFAULTS".
+ Example: the CORBA IDL defined method
+ <pre>
+ void mymethod ();
+ </pre>
+ in the C++ header file looks like this:
+ <pre>
+ void mymethod (ACE_ENV_SINGLE_ARG_DECL_WITH_DEFAULTS);
+ </pre>
+ and in the C++ implementation file may look something like:
+ <pre>
+ void mymethod (ACE_ENV_SINGLE_ARG_DECL)
+ {
+ // ...
+ }
+ </pre>
+ </ul>
+
+ <br>
+ </li>
+
+ <li><P><em>Passing the CORBA::Environment Parameter into Method Calls</em><br>
+ Now that we've seen how to declare methods with Environment
+ parameters, let's see how to invoke such methods.</p>
+ <ul>
+ <li><p><em>ACE_ENV_ARG_PARAMETER</em></p>
+ in the pseudo exception configuration resolves to
+ <pre>
+ , ACE_TRY_ENV
+ </pre>
+ and is written as the last parameter of a method call that takes
+ one or more regular parameters. Again we need to omit the
+ comma that would normally precede this last parameter, as the
+ comma is already part of the macro definition. For example,
+ the CORBA IDL method
+ <pre>
+ void mymethod (in boolean b);
+ </pre>
+ would be invoked as follows:
+ <pre>
+ some_var.mymethod (bparam ACE_ENV_ARG_PARAMETER);
+ </pre>
+ </ul>
+
+ <ul>
+ <li><p><em>ACE_ENV_SINGLE_ARG_PARAMETER</em></p>
+ is similar to <code>ACE_ENV_ARG_PARAMETER</code> but is used
+ for calling methods that don't take any regular parameters.
+ Our example of a CORBA IDL method
+ <pre>
+ void mymethod ();
+ </pre>
+ we would invoke as follows:
+ <pre>
+ some_var.mymethod (ACE_ENV_SINGLE_ARG_PARAMETER);
+ </pre>
+ </ul>
+ <br>
+ </li>
+
+ <li><P><em>Definition of the CORBA::Environment variable </em><br>
+ We have seen how to declare methods with the CORBA::Environment
+ parameter, and how to invoke such methods. However, where does
+ the variable to pass into methods as the CORBA::Environment
+ parameter come from in the first place?</p>
+ <P>An environment variable can be defined in the needed scope
+ (for example, in the main program, or in a more local scope)
+ by the statement</p>
+ <pre>
+ ACE_DECLARE_NEW_CORBA_ENV;
+ </pre>
+ <P>You can then invoke the methods on the servant from the client
+ side as
+ <pre>
+ object_reference->func_name (x, y ACE_ENV_ARG_PARAMETER);
+ </pre>
+
+ Even if you are interested in making calls within the client
+ side, you can define your method like this
+ <pre>
+ int AN_OBJ::foobar (int a, int b ACE_ENV_ARG_DECL);
+ </pre>
+
+ <li><P><em>Throwing exceptions:</em><br>
+ Use <code>ACE_THROW</code> and <code>ACE_THROW_RETURN</code> to
+ throw exceptions. They should never be used within a try
+ block; please use <code>ACE_TRY_THROW</code> instead.
+ </P>
+ </LI>
+
+ <li><P><em>Propagating exceptions:</em><br>
+ To simulate native exceptions on platforms without native
+ exception handling, <em>every</em> function call that may
+ throw exceptions must be followed by <code>ACE_CHECK</code> or
+ <code>ACE_CHECK_RETURN</code>.</p>
+
+ <p><a name="exc-func">Exception-throwing functions include the
+ following categories:</p>
+
+ <ol>
+ <li><p>Any function that takes a
+ <code>CORBA_Environment</code> argument.</p>
+ </li>
+
+ <li><p><code>ACE_NEW_THROW_EX</code>. Notice that you
+ <em>should not</em> use <code>ACE_NEW_THROW</code>,
+ <code>ACE_NEW_THROW_RETURN</code>,
+ <code>ACE_NEW_TRY_THROW</code> anymore because they don't
+ work right with ACE try macros. Instead, use
+ <code>ACE_NEW_THROW</code> with appropriate ACE_CHECK*
+ macros.</p>
+ </li>
+
+ <li><P><code>ACE_GUARD_THROW_EX</code>,
+ <code>ACE_READ_GURAD_THROW_EX</code>, and
+ <code>ACE_WRITE_THROW_EX</code>.
+
+ <li><p><code>ACE_TRY</code> blocks. Follow every
+ <code>ACE_ENDTRY</code> with appropriate ACE_CHECK*
+ macros.</p>
+ <li>
+ </ol>
+
+ <P>You should pass <code>ACE_TRY_ENV</code> to these
+ functions.
+ </p>
+
+ <P>Be very careful not to combine exception throwing functions
+ in one statement like this:
+ </P>
+ <pre>
+ x = obj1->callme (ACE_ENV_SINGLE_ARG_PARAMETER)
+ + obj2->dare_me (ACE_ENV_SINGLE_ARG_PARAMETER);
+ ACE_CHECK;
+ </pre>
+ <P>This example may work differently when native exception
+ handling is enabled/disabled.
+ </p>
+ </LI>
+
+ <li><P><em>Catching exceptions:</em><br>
+ Use <code>ACE_TRY</code> to catch exceptions if there's an
+ <code>ACE_TRY_ENV</code> available. Otherwise, you should use
+ <code>ACE_DECLARE_NEW_CORBA_ENV</code> to create one at
+ <em>proper</em> scope. The use of
+ <code>ACE_TRY_NEW_ENV</code> is considered depricated because it
+ can't deal with the case when you have multiple <code>TRY</code>
+ blocks in the scope of <code>ACE_TRY_NEW_ENV</code>. If there are
+ more than one try blocks in a function, use <code>ACE_TRY_EX</code>
+ for all subsequence try blocks to avoid name clashing of labels.
+ </p>
+ <ul>
+ <li><P>Within a <code>ACE_TRY</code> block, use the variable
+ <code>ACE_TRY_ENV</code> to pass down the
+ <code>CORBA_Environment</code> (see <a
+ href="#try_env">this</a> example.)
+ </p>
+ </LI>
+
+ <li><P>Follow <em>every</em> exception throwing function with
+ <code>ACE_TRY_CHECK</code>. If you are using a TRY block
+ within another try block add a <code>ACE_TRY_CHECK</code>
+ at the end of this TRY block ie. after
+ <code>ACE_ENDTRY</code>.
+ </p>
+ </LI>
+
+ <li><P>Use <code>ACE_CATCH</code> to catch exceptions of certain
+ type.
+ </p>
+ </LI>
+
+ <li><P><code>ACE_CATCHANY</code> catches <em>any</em> exceptions
+ of type <code>CORBA_Exception</code>. The caught
+ exception is stored in a variable call
+ <code>ACE_ANY_EXCEPTION</code>.
+ </p>
+ </LI>
+
+ <li><p><code>ACE_CATCHALL</code> emulate the <code>catch
+ (...)</code> c++ statement. It is identical to
+ <code>ACE_CATCHANY</code> on platforms without native
+ exception support. You can not access the caught
+ exception within the <code>ACE_CATCHALL</code> block.</p>
+
+ <li><P>Use <code>ACE_RE_THROW</code> to rethrow the same exception
+ within a <code>ACE_CATCH</code> or
+ <code>ACE_CATCHANY</code> block.
+ </p>
+ </LI>
+
+ <li><P>A <code>ACE_TRY</code> block must be terminated with
+ a <code>ACE_ENDTRY</code> statement.
+ </p>
+ </LI>
+
+ <li><P>Throw an exception within a <code>ACE_TRY</code>
+ block or <code>ACE_CATCH</code> block using
+ <a href="#ace_try"><code>ACE_TRY_THROW</code></a>.
+ </p>
+ </LI>
+ </ul>
+ </li>
+
+ <li><p><em>Printing out exceptions.</em> Use <code>ACE_PRINT_EXCEPTION
+ (EX,INFO)</code> to print out an exception. The macro takes two
+ arguments, a reference to an exception (EX) and a <code>char
+ *</code> string (INFO) which provides more information on the
+ exception. Since there's no portable way to print out
+ exceptions, you can redefine ACE_PRINT_EXCEPTION to fit your
+ need (or define it to null.) <em>You should always print out
+ the exception itself, not the CORBA_Environment that carries the
+ exception.</em></p>
+ </li>
+
+ <li><P><em>Name of CORBA::Environment variable</em><br>
+ A function that may throw a CORBA::Exception needs a
+ CORBA::Environment variable to pass up exceptions (to throw in
+ the C++ sense) and to gather (catch () in the C++ sense)
+ exceptions from functions it called. By default, ACE exception
+ macros assume that the variable is named <code>ACE_TRY_ENV</code>.
+ <code>ACE_TRY_ENV</code> itself is also a macro which can be
+ redefined.
+ </pre>
+
+ <P>
+ You can redefine the name of the variable to
+ something else to avoid name clashing. Alternatively, there's
+ another macro (<code>ACE_ADOPT_CORBA_ENV</code>) that allow you
+ to use another variable name as the default CORBA::Environment
+ <em>within</em> a function.
+ </P>
+ </LI>
+
+</ol>
+
+<HR><P>
+<h3>Examples</h3><a name="examples">
+
+Refer to <a href="../ace/CORBA_macros.h"><code>
+$ACE_ROOT/ace/CORBA_macros.h</code></a> for complete definitions of
+macros discussed here.
+
+<ul>Examples on using ACE try macros:
+ <li><p>
+ <pre>
+ <a name="try_env">
+ ACE_TRY // Use ACE_DECLARE_NEW_CORBA_ENV to create ACE_TRY_ENV
+ // if you got undefined symbol warning here.
+ {
+ some_operation (arg1, arg2 ACE_ENV_ARG_PARAMETER);
+ ACE_TRY_CHECK;
+
+ .
+ .
+ if (whatever)
+ ACE_TRY_THROW (CORBA::BAD_PARAM ());
+
+ some_other_operation (arg1, arg2, arg3 ACE_ENV_ARG_PARAMETER);
+ ACE_TRY_CHECK;
+ }
+ <a name="ace_try">
+ ACE_CATCH (CORBA_some_exception, ex)
+ {
+ // error handling.
+ if (still_has_error)
+ ACE_TRY_THROW (CORBA::NOWAY ());
+ }
+ ACE_CATCHANY
+ {
+ // error handling.
+ // then rethow the exception.
+ ACE_RE_THROW;
+ }
+ ACE_ENDTRY;
+ ACE_CHECK;
+ </pre>
+ </p>
+ </li>
+
+ <li><p><code>ACE_TRY</code> and also declares a label for internal
+ use. To avoid defining the same label multiple times within a
+ function, use <code>ACE_TRY_EX</code> with different labels for
+ different try blocks instead. For example,<br>
+
+ <pre>
+ ACE_TRY_EX (block_1)
+ {
+ some_operation (arg1, arg2 ACE_ENV_ARG_PARAMETER);
+ ACE_TRY_CHECK_EX (block_1);
+
+ some_other_operation (arg1, arg2, arg3 ACE_ENV_ARG_PARAMETER);
+ ACE_TRY_CHECK_EX (block_1);
+ }
+ ACE_CATCH (CORBA_some_exception, ex)
+ {
+ // error handling.
+ }
+ ACE_CATCHANY
+ {
+ // error handling.
+ }
+ ACE_ENDTRY;
+ ACE_CHECK_RETURN (-1);
+
+ // Some other operation here
+ // .
+ // .
+ // .
+ // .
+
+ ACE_TRY_EX (block_2)
+ {
+ foo (arg ACE_ENV_ARG_PARAMETER);
+ ACE_TRY_CHECK_EX (block_2);
+
+ bar (arg1, arg2 ACE_ENV_ARG_PARAMETER);
+ ACE_TRY_CHECK_EX (block_2);
+ }
+ ACE_CATCH (CORBA_some_exception, ex)
+ {
+ // error handling.
+ }
+ ACE_CATCHANY
+ {
+ // error handling.
+ }
+ ACE_ENDTRY;
+ ACE_CHECK_RETURN (-1);
+ </pre>
+ </p>
+
+ <li><p>You may want to make a different series of calls after you
+ encounter/catch an exception. Here is what we recommend.
+
+ <pre>
+ ACE_TRY
+ {
+ // Calls that can raise an exception
+ some_call1 (arg1, arg2 ACE_ENV_ARG_PARAMETER);
+ ACE_TRY_CHECK;
+ .
+ .
+ .
+ ACE_TRY_CHECK;
+ }
+ ACE_CATCH (CORBA_some_exception, ex)
+ {
+ // Caught an exception, so we need to make some other calls
+ // to continue..
+
+ ACE_TRY_EX (block1) // basically a label
+ {
+ some_other_call1 (arg1,.. ACE_ENV_ARG_PARAMETER);
+ ACE_TRY_CHECK_EX (block1);
+ }
+ ACE_CATCH (CORBA_some_other_exception, ex1)
+ {
+ // Handle the exception here..
+ }
+ ACE_ENDTRY;
+ ACE_CHECK_RETURN (-1); // Needed to catch uncaught exceptions
+ }
+ ACE_ENDTRY;
+ ACE_CHECK_RETURN (-1);
+ </pre>
+ </p>
+
+ <li><p>Be <em>VERY</em> wary of <code>ACE_CATCHALL</code>. It catches
+ exceptions of any type. If your program depends on it, then,
+ more often than not, there're something wrong with it.
+ </P>
+ </li>
+
+ <li><p>Instead of depending on <code>ACE_CATCHALL</code>, use
+ <code>auto_ptr</code> style mechanism to prevent memory leaks
+ from exceptions.
+ </p>
+ </li>
+</ul>
+
+<HR><P>
+<h3><a name="general">General Guidelines for Exception Handling</h3>
+<ul>
+ <li><p>Don't catch an exception just to rethrow it. Exceptions cost
+ you performance.
+ </p>
+ </li>
+
+ <li><p>When exceptions occur, make sure an object's is still in
+ a valid state or change to a state that can be safely
+ destructed.
+ </p>
+ </li>
+
+ <li><p>Watch out for side effect in the expression which may cause
+ exceptions. In the following example, what should
+ <code>i</code> be if an exception does occur?<br>
+<pre>
+ ACE_TRY
+ {
+ obj[i++] = foo_bar_method (a, b ACE_ENV_ARG_PARAMETER);
+ }
+</pre></p>
+ </li>
+
+ <li><p>Make sure an exception doesn't cause resource leak (memory,
+ socket, ...) (hint: Use auto_ptr to avoid memory leak,
+ and ACE_Guard for locks.)
+ </p>
+ </li>
+
+ <li><p>Don't catch any exception that you don't know how to handle.</p>
+ </li>
+
+ <li><p>Never throw an exception from destructor (unless you know what
+ it implies.)</p>
+ </li>
+
+ <li><p>Use exceptions to provide more information about the error.</p>
+ </li>
+
+ <li><p>Rethrow a different exception only to provide <em>more</em>
+ information. Do not catch an exception just to rethrow, say,
+ <code>unknow_exception</code>.</p>
+ </li>
+</ul>
+
+<HR><P>
+<H3><a name="transition">Transition from ACE_TRY_ENV usage
+ to the ACE_ENV_ARG macros</h3>
+
+<P>Before TAO version 1.2.2, IDL defined methods were declared using
+direct mentions of <code>CORBA::Environment ACE_TRY_ENV</code>.
+The problem with this approach was that the ACE_TRY_ENV had
+to be passed into ORB core method calls even when native exceptions
+are supported. The TAO internal usage of the ACE_ENV_ARG family of
+macros fixes this.</p>
+
+<p>For people who want to continue to use their old code that uses the
+old <code>ACE_TRY_ENV</code> macros, they can define
+<CODE>ACE_ENV_BKWD_COMPAT</CODE> in their <code>config.h</code> file.
+
+<P>CORBA applications that do not need support for emulated exceptions
+can use direct C++ exception handling and omit the CORBA::Environment
+parameter entirely.<BR>
+On the other hand, applications that shall support environments without
+C++ exceptions (such as all applications that are part of to TAO itself)
+should use the ACE_ENV_ARG macros.<BR>
+The script <code>$ACE_ROOT/bin/subst_env.pl</code> can assist in the
+conversion from the direct ACE_TRY_ENV usage to the ACE_ENV_ARG macros.
+Here is a list of the substitutions that the script does. For context,
+two sample IDL methods are used:
+<PRE>
+ void noargs ();
+ void withargs (in boolean b);
+</pre>
+At each example, first the <em>old usage</em> is given, then its
+<code>subsitution</code>.
+</p>
+
+<H4>Method declaration</h4>
+
+<UL>
+ <li><P><em>void noargs (CORBA::Environment &amp;);</em></P>
+ <P><code>void noargs (ACE_ENV_SINGLE_ARG_DECL_NOT_USED);</code></P>
+ </li>
+ <li><P><em>void noargs (CORBA::Environment &amp;ACE_TRY_ENV);</em></P>
+ <P><code>void noargs (ACE_ENV_SINGLE_ARG_DECL);</code></P>
+ </li>
+ <li><P><em>void noargs (CORBA::Environment &amp;ACE_TRY_ENV = TAO_default_environment ());</em></P>
+ <P><code>void noargs (ACE_ENV_SINGLE_ARG_DECL_WITH_DEFAULTS);</code></P>
+ </li>
+ <li><P><em>void withargs (CORBA::Boolean b, CORBA::Environment &amp;);</em></P>
+ <P><code>void withargs (CORBA::Boolean b ACE_ENV_ARG_DECL_NOT_USED);</code></P>
+ </li>
+ <li><P><em>void withargs (CORBA::Boolean b, CORBA::Environment &amp;ACE_TRY_ENV);</em></P>
+ <P><code>void withargs (CORBA::Boolean b ACE_ENV_ARG_DECL);</code></P>
+ </li>
+ <li><P><em>void withargs (CORBA::Boolean b, CORBA::Environment &amp;
+ ACE_TRY_ENV = TAO_default_environment ());</em></P>
+ <P><code>void withargs (CORBA::Boolean b ACE_ENV_ARG_DECL_WITH_DEFAULTS);</code></P>
+ </li>
+</ul>
+
+<H4>Method invocation</h4>
+
+<UL>
+ <li><P><em>noargs (ACE_TRY_ENV);</em></P>
+ <P><code>noargs (ACE_ENV_SINGLE_ARG_PARAMETER);</code></P>
+ </li>
+ <li><P><em>withargs (bparam, ACE_TRY_ENV);</em></P>
+ <P><code>withargs (bparam ACE_ENV_ARG_PARAMETER);</code></P>
+ </li>
+</ul>
+
+<HR><P>
+<H3><a name="caveats">Caveats</H3>
+
+<P>As we already mentioned no set of macros can cover all cases
+and preserve the semantics between native C++ exceptions and the
+<CODE>CORBA::Environment</CODE> based mapping.
+Some of the problems that our macros are described below:
+<P>
+
+<UL>
+ <LI><P>Using the macros in loops can produce problems with
+ <CODE>break</CODE> and <CODE>continue</CODE> statements, for
+ example:
+ </P>
+ <PRE>
+ for (int i = 0; i < 10; ++i)
+ {
+ ACE_TRY
+ {
+ if (x[i] == 0)
+ continue; // will *not* work
+ if (x[i] == -1)
+ break; // will *not* work either
+ }
+ ACE_CATCH (CORBA::Exception, ex)
+ {
+ }
+ ACE_ENDTRY;
+ ACE_CHECK;
+ }
+ </PRE>
+ </LI>
+</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>
diff --git a/ACE/docs/index.html b/ACE/docs/index.html
new file mode 100644
index 00000000000..18de311d5c7
--- /dev/null
+++ b/ACE/docs/index.html
@@ -0,0 +1,101 @@
+<html>
+
+<!-- $Id$ -->
+<head>
+<title>ACE Documentation Home</title>
+</head>
+
+<body text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff">
+
+<hr>
+
+<h1>ACE Documentation Home</h1>
+
+Everything you've always wanted to know about ACE, but were afraid to
+ask. <P>
+
+<hr>
+
+<h3>ACE Documentation</h3>
+
+<ul>
+ <li><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">Overview of ACE</a> -
+ a high-level view.
+ <li><A
+ HREF="http://www.cs.wustl.edu/~schmidt/ACE-documentation.html">ACE online documentation</a>.
+ <li><A
+ HREF="http://www.flyingdonkey.com/ace/">Translations for much of the ACE documentation</a>.
+ <LI><A HREF="http://www.cs.wustl.edu/~schmidt/ACE/">Books on ACE</A>.
+</ul>
+
+<hr>
+
+<h3>ACE Structure</h3>
+
+<ul>
+ <li><a href="ACE-categories.html">Class Categories</a> - Listing of some of the classes
+ in ACE.
+ <li>ACE Inheritance Tree <a href="ACE-inheritance.pdf">[pdf]</a> <a href=
+ "ACE-inheritance.ps.gz">[ps.gz]</a>
+ <li><a href="ACE-subsets.html">ACE Subsets</a> - Outline of some of our ideas
+ for subsetting the ACE library.
+</ul>
+
+<hr>
+
+<h3>Technical Papers and Tutorials</h3>
+
+<ul>
+ <li><a href="http://www.cs.wustl.edu/~schmidt/ACE-papers.html">Technical Papers</a> -
+ Postscript versions of many ACE papers.
+ <li>Tutorial on C++ Network Programming with Patterns, Frameworks, and ACE<a href="http://www.cs.wustl.edu/~schmidt/PDF/ACE-tutorial.pdf">[pdf]</a>
+ <a href="http://www.cs.wustl.edu/~schmidt/ACE-tutorial.ps.gz">[ps.gz]</a>
+ <!-- Bob's original can always be found at: http://dox.netwrench.com/acedox/fmm/ -->
+ <li><a href="ACE-FMM.html">ACE FMM</a> - ACE &quot;Frequently Made Mistakes&quot;
+</ul>
+
+<hr>
+
+<h3>Bug Reports</h3>
+
+<ul>
+ <li><a href="ACE-bug-process.html">Bug Fixing Policies</a> - Our policies for
+ handling bug reports about ACE, TAO, and CIAO.
+ <li><a href="usage-bugzilla.html">Bug Tracking System</a> - Short description of our
+ Bugzilla bug tracking system.
+</ul>
+
+
+<hr>
+
+<h3>ACE Development</h3>
+
+<ul>
+ <li><a href="ACE-development-process.html">Development and Release Process</a> - The process we use
+ to develop and release the ACE, TAO, and CIAO software.
+ <li><a href="CVS.html">Overview of CVS</a> - How to use the source
+ control system we use for ACE, TAO, CIAO, etc.
+ <li><a href="ACE-guidelines.html">Style Guide</a> - How to write
+ compliant ACE, TOA, and CIAO code.
+ <li><a href="ACE-porting.html">Porting</a> - What to do to port to a new platform.
+ <li><a href="exceptions.html">Exception Macros</a> - How to use the ACE TRY
+ macros properly (note that these macros are now deprecated).
+
+</ul>
+
+<hr>
+
+<h3>Other Stuff</h3>
+
+<ul>
+ <li><a href="ACE-lessons.html">Lessons</a> - Lessons we have learned while
+ building ACE.
+ <li><a href="ACE-SSL.html">ACE+SSL</a> - What is ACE+SSL and how to get it.
+ <li><a href="Symbol_Versioning.html">Symbol versioning</a> - How to do symbol versioning
+ with ACE+TAO.
+ <li><a href="CE-status.txt">CE-status.txt</a> - The status of ACE on Windows CE.
+ <li><a href="../ACEXML/docs/readme.txt">ACEXML</a> - A SAX2-based XML parser ACE uses and provides.
+</ul>
+
+</body>
+</html>
diff --git a/ACE/docs/msvc_notes.txt b/ACE/docs/msvc_notes.txt
new file mode 100644
index 00000000000..a0965a3e8bc
--- /dev/null
+++ b/ACE/docs/msvc_notes.txt
@@ -0,0 +1,132 @@
+/**
+@page msvc Miscellaneous Notes for ACE/TAO and Microsoft Visual C++
+
+Here are just some random information about ACE/TAO with Microsoft Visual
+C++. This is more a collection of ideas right now, so it may not be as
+polished as other ACE documentation.
+
+@subsection msvc_configurations Configurations
+
+MSVC workspace and solution files come with several configurations. The
+main two are Debug and Release. Debug produces libraries and
+executables with debugging symbols and doesn't enable inlining. The
+Release configuration enables optimizations and leaves out debugging
+symbols. All projects contain both configurations. If you want to
+build static or mfc versions of th elibrary you need to use different
+project and solution files. Project files with _Static extension
+denote workspaces for building static libraries.
+
+Different configurations produce different libraries and executables. For
+example, Debug versions of dynamic libraries are always named *d.dll (like
+aced.dll) and the executables are placed in the current directory. Release
+versions of dynamic libraries are named *.dll (such as ace.dll) and their
+executables are usually placed in the Release subdirectory. Other common
+suffixes include *sd.lib for Static Debug and *s.lib for Static Release.
+
+Projects only use the same configuration versions of the libraries. The Debug
+version of an ACE example only uses debug version of ACE library.
+
+@subsection msvc_otheroptions How to Set Other Options
+
+Other compile time options are set or unset via the config.h file. For
+example, to turn on a compile time definition, #define it at the beginning of
+config.h. Unsetting a definition just requires #define ACE_FOO 0 or a #undef
+at the end of the file (after including config-win32.h). Different macros
+require different techniques.
+
+@subsection msvc_libraries ACE/TAO Libraries
+
+I don't think we have any documents really giving any info on what libraries
+are produced by the MSVC project files.
+
+So unlike the Unix platforms, Win32 libraries do not have a prefix of "lib",
+instead it is used as an extension. For example, the debug version of the
+dynamic ace library is aced.lib (which is a stub for aced.dll). The three
+ACE libraries are:
+
+- ace
+- ACE_RMCast
+- ACE_SSL
+- ACE_TMCast
+
+And for TAO we have the main TAO library and several sub libraries which
+contain extra features of TAO that aren't always needed (such as the POA
+in TAO_PortableServer).
+
+And finally we have the orbsvcs libraries. Each ORB service is contained
+in its own library. More libraries may be needed to be linked in, since
+some services require the use of others (such as TAO_AV requiring
+TAO_CosTrading and TAO_CosProperty).
+
+The *.lib and *.dll files are located in ACE_wrappers/lib. You need
+to point your PATH to $ACE_ROOT/lib for running the applications.
+
+I hesitate to put down explicit instructions on what libraries need to be
+linked in, considering that the libraries are being split apart more and more
+for footprint purposes. For most ACE stuff, you will only need to link in
+ace.lib. For plain TAO clients TAO.lib is enough. TAO servers also require
+TAO_PortableServer.lib for the POA. If the TAO application uses Dynamic Anys,
+TAO_DynamicAny.lib is also needed. Then if any of the ORB Services are used,
+more libraries are needed. For example, a client that uses the Name Service
+would need to link TAO_CosNaming.lib.
+
+And note that the release versions of the libraries are listed above. For
+debug configurations the libraries would be aced.lib, TAOd.lib, etc.
+
+@subsection msvc_external_projects External ACE/TAO Projects
+
+It is a little difficult for us to list how exactly one should create
+projects that use ACE/TAO but are external to the ACE_wrappers tree. Since
+most projects we create are in that tree, we can make assumptions about
+directory structure that doesn't always apply for external projects. In
+other words, we have ideas how they should work, but they usually remain
+a bit, um, untested. :-)
+
+There are three main dependencies a project would have on ACE/TAO.
+
+- Include paths: Since all the headers use a subdirectory way of referring
+ to include files (such as "ace/OS.h" instead of just "OS.h"). In order
+ to make this work either the path to ACE_wrappers (and ACE_wrappers\TAO and
+ ACE_wrappers\TAO\orbsvcs, etc.) to the additional include paths of the
+ project or in MSVC. I believe it is a better idea to add them to the global
+ MSVC directories. That way the path to ACE on a machine doesn't get hard
+ coded into the project itself (this should make it easier to move the
+ project between machines where ACE is installed in different places).
+
+- Libraries and library paths: Depending on what features are needed,
+ different libraries are needed to be linked in. (This is covered more in
+ an above section). These libraries are specified in the project, but can
+ be specified in different ways. The first is the hard coded way (a full
+ path, such as "C:\ACE_wrappers\ace\aced.lib"). The second is listing only
+ the library (such as "aced.lib") and then specify the path either in the
+ project or via MSVC global settings. Just like for the include paths, MSVC
+ global settings is probably the more robust way of specifying this.
+
+- TAO_IDL: TAO's IDL compiler resides in ACE_wrappers\bin. If the external
+ project contains IDL files, then a custom build configuration can be used
+ to automatically call TAO_IDL. Note that the location of the release
+ version of the compiler is in ACE_wrappers\bin\Release (although it doesn't
+ matter which version you use, they both produce the same output). If
+ ACE_wrappers\bin is included in the path, then the build command can just
+ refer to tao_idl and it can be found via the path. The other options are
+ to refer to tao_idl via an absolute hard coded path or to add
+ ACE_wrappers\bin to the MSVC's global executable path settings. Either
+ way the bin directory must be in the path or in the global settings so
+ tao_idl can find aced.dll.
+
+So I guess in summary we would recommend adding most of the settings to Visual
+C++'s global settings (include paths, library paths, and executable paths)
+and just refer to the libraries without any paths.
+
+@subsection msvc_aceroot ACE_ROOT
+
+ACE_ROOT is an interesting environment variable. Even though it is heavily
+used on Unix (in fact, ACE/TAO will not compile without it) it really isn't
+needed for MSVC. The reason for this is that we were interested in making
+configuration and setup really easy for Visual C++ on Windows. In retrospect
+it might have made quite a few things easier to specify if ACE_ROOT was
+required. One thing you might notice is that TAO_IDL will display a message
+if ACE_ROOT isn't set, but it is only a problem if the IDL file includes
+<orb.idl> and you don't use -I to specify where orb.idl is.
+
+*/ \ No newline at end of file
diff --git a/ACE/docs/run_test.txt b/ACE/docs/run_test.txt
new file mode 100644
index 00000000000..9889a9222e3
--- /dev/null
+++ b/ACE/docs/run_test.txt
@@ -0,0 +1,172 @@
+/**
+@page run_test_howto How to write a run_test.pl
+
+ACE/TAO's auto_builds expect run_test.pl's to follow some guidelines
+that are needed to keep the auto_builds from hanging and to make
+sure the run_test.pl works on all platforms
+
+- The run_test must not hang or block.
+- The run_test must clean up any temporary files when it is done.
+- The run_test must not require any user input
+- The run_test should return a non-zero value if the test failed
+
+Following is an example
+
+@subsection example Example
+
+@verbatim
+eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}'
+ & eval 'exec perl -S $0 $argv:q'
+ if 0;
+
+# $Id$
+# -*- perl -*-
+
+use lib '../../../bin';
+use PerlACE::Run_Test;
+
+$status = 0;
+
+$server_ior = PerlACE::LocalFile ("server.ior");
+unlink $server_ior;
+
+$SV = new PerlACE::Process ("server", "-o $server_ior");
+$CL = new PerlACE::Process ("client", "-k file://$server_ior");
+
+$SV->Spawn ();
+
+if (PerlACE::waitforfile_timed ($server_ior, 5) == -1) {
+ print STDERR "ERROR: cannot find file <$server_ior>\n";
+ $SV->Kill ();
+ exit 1;
+}
+
+$client = $CL->SpawnWaitKill (60);
+
+if ($client != 0) {
+ print STDERR "ERROR: client returned $client\n";
+ $status = 1;
+}
+
+$server = $SV->TerminateWaitKill (5);
+
+if ($server != 0) {
+ print STDERR "ERROR: server returned $server\n";
+ $status = 1;
+}
+
+unlink $server_ior;
+
+exit $status;
+@endverbatim
+
+@subsection details Example Details
+
+@verbatim
+eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}'
+ & eval 'exec perl -S $0 $argv:q'
+ if 0;
+
+# $Id$
+@endverbatim
+
+This is the standard header stuff. The eval is a trick used
+to get the perl script to run if it a unix shell treats it as
+a shell script.
+
+The CVS ID string is the usual one we put in.
+
+@verbatim
+use lib '../../../bin';
+use PerlACE::Run_Test;
+@endverbatim
+
+The use lib line is used to tell Perl where the PerlACE modules are.
+It should be a relative path to the bin directory.
+
+And PerlACE::Run_Test is a module to be used by all run_test.pl's.
+It does a couple of things, including parsing some common command
+line arguments (like -Config and -ExeSubDir) and also brings in
+the PerlACE::Process module.
+
+@verbatim
+$status = 0;
+
+$server_ior = PerlACE::LocalFile ("server.ior");
+
+unlink $server_ior;
+@endverbatim
+
+Because of the way tests work on chorus, we need to have a fully
+qualified path to all *.ior and *.conf files. We unlink the file
+immediately because we use PerlACE::waitforfile_timed later.
+
+@verbatim
+$SV = new PerlACE::Process ("server", "-o $server_ior");
+$CL = new PerlACE::Process ("client", " -k file://$server_ior ");
+
+$SV->Spawn ();
+@endverbatim
+
+The PerlACE::Process is constructed with an executable and
+arguments. @note Unlike the old Process module, the process
+isn't started until one of the Spawn methods is used.
+
+@verbatim
+if (PerlACE::waitforfile_timed ($server_ior, 5) == -1) {
+ print STDERR "ERROR: cannot find file <$server_ior>\n";
+ $SV->Kill ();
+ exit 1;
+}
+@endverbatim
+
+The PerlACE::waitforfile_timed method waits until the file is
+created. In this way, we know when to start the client. If
+no IOR file is used, then you'd need to use Perl's sleep
+method.
+
+@verbatim
+$client = $CL->SpawnWaitKill (60);
+
+if ($client != 0) {
+ print STDERR "ERROR: client returned $client\n";
+ $status = 1;
+}
+@endverbatim
+
+Here is an example of starting the client. SpawnWaitKill will start
+the process and wait for the specified number of seconds for the
+process to end. If the time limit is reached, it will kill the
+process and return -1.
+
+The return value of SpawnWaitKill is the return value of the
+process, unless it timed out. You don't need to check for the
+timeout, since SpawnWaitKill will print out a timeout error.
+Instead, just check for != 0.
+
+@verbatim
+$server = $SV->TerminateWaitKill (5);
+
+if ($server != 0) {
+ print STDERR "ERROR: server returned $server\n";
+ $status = 1;
+}
+@endverbatim
+
+Here is the termination of the server. Servers are usually terminated
+either by TerminateWaitKill or just WaitKill. TerminateWaitKill is
+used when the server doesn't shut down itself. WaitKill is used when
+it does (such as when the client calls a shutdown method). Once
+again, we check the return status.
+
+
+@verbatim
+unlink $server_ior;
+
+exit $status;
+@endverbatim
+
+And finally, we unlink any files that were created and then just
+exit with $status.
+
+*/ \ No newline at end of file
diff --git a/ACE/docs/svn/config b/ACE/docs/svn/config
new file mode 100644
index 00000000000..c52ebb693a2
--- /dev/null
+++ b/ACE/docs/svn/config
@@ -0,0 +1,102 @@
+### This file configures various client-side behaviors.
+###
+### The commented-out examples below are intended to demonstrate
+### how to use this file.
+
+### Section for authentication and authorization customizations.
+### Set store-auth-creds to 'no' to avoid storing your subversion
+### credentials in the auth/ area of your config directory.
+### It defaults to 'yes'. Note that this option only prevents
+### saving of *new* credentials; it doesn't invalidate existing
+### caches. (To do that, remove the cache files by hand.)
+# [auth]
+# store-auth-creds = no
+
+### Section for configuring external helper applications.
+### Set editor to the command used to invoke your text editor.
+### This will override the environment variables that Subversion
+### examines by default to find this information ($EDITOR,
+### et al).
+### Set diff-cmd to the absolute path of your 'diff' program.
+### This will override the compile-time default, which is to use
+### Subversion's internal diff implementation.
+### Set diff3-cmd to the absolute path of your 'diff3' program.
+### This will override the compile-time default, which is to use
+### Subversion's internal diff3 implementation.
+### Set diff3-has-program-arg to 'true' or 'yes' if your 'diff3'
+### program accepts the '--diff-program' option.
+# [helpers]
+# editor-cmd = editor (vi, emacs, notepad, etc.)
+# diff-cmd = diff_program (diff, gdiff, etc.)
+# diff3-cmd = diff3_program (diff3, gdiff3, etc.)
+# diff3-has-program-arg = [true | false]
+
+### Section for configuring tunnel agents.
+# [tunnels]
+### Configure svn protocol tunnel schemes here. By default, only
+### the 'ssh' scheme is defined. You can define other schemes to
+### be used with 'svn+scheme://hostname/path' URLs. A scheme
+### definition is simply a command, optionally prefixed by an
+### environment variable name which can override the command if it
+### is defined. The command (or environment variable) may contain
+### arguments, using standard shell quoting for arguments with
+### spaces. The command will be invoked as:
+### <command> <hostname> svnserve -t
+### (If the URL includes a username, then the hostname will be
+### passed to the tunnel agent as <user>@<hostname>.) If the
+### built-in ssh scheme were not predefined, it could be defined
+### as:
+# ssh = $SVN_SSH ssh
+### If you wanted to define a new 'rsh' scheme, to be used with
+### 'svn+rsh:' URLs, you could do so as follows:
+# rsh = rsh
+### Or, if you wanted to specify a full path and arguments:
+# rsh = /path/to/rsh -l myusername
+### On Windows, if you are specifying a full path to a command,
+### use a forward slash (/) or a paired backslash (\\) as the
+### path separator. A single backslash will be treated as an
+### escape for the following character.
+
+### Section for configuring miscelleneous Subversion options.
+# [miscellany]
+### Set global-ignores to a set of whitespace-delimited globs
+### which Subversion will ignore in its 'status' output.
+# global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store
+### Set log-encoding to the default encoding for log messages
+# log-encoding = latin1
+### Set use-commit-times to make checkout/update/switch/revert
+### put last-committed timestamps on every file touched.
+# use-commit-times = yes
+### Set enable-auto-props to 'yes' to enable automatic properties
+### for 'svn add' and 'svn import', it defaults to 'no'.
+### Automatic properties are defined in the section 'auto-props'.
+enable-auto-props = yes
+
+### Section for configuring automatic properties.
+### The format of the entries is:
+### file-name-pattern = propname[=value][;propname[=value]...]
+### The file-name-pattern can contain wildcards (such as '*' and
+### '?'). All entries which match will be applied to the file.
+### Note that auto-props functionality must be enabled, which
+### is typically done by setting the 'enable-auto-props' option.
+# [auto-props]
+*.cpp=svn:eol-style=native
+*.h=svn:eol-style=native
+*.inl=svn:eol-style=native
+*.html=svn:eol-style=native
+*.sh=svn:eol-style=native;svn:executable
+*.py=svn:eol-style=native;svn:executable
+*.pl=svn:eol-style=native;svn:executable
+*.mpc=svn:eol-style=native
+*.mpb=svn:eol-style=native
+*.mpt=svn:eol-style=native
+*.hpp=svn:eol-style=native
+*.cdp=svn:eol-style=native
+*.xsd=svn:eol-style=native
+*.txt=svn:eol-style=native
+Change?og*=svn:eol-style=native
+*.am=svn:eol-style=native
+*.ac=svn:eol-style=native
+*.lst=svn:eol-style=native
+*.pm=svn:eol-style=native
+
diff --git a/ACE/docs/svn/svn-prefs.reg b/ACE/docs/svn/svn-prefs.reg
new file mode 100644
index 00000000000..3a243318590
--- /dev/null
+++ b/ACE/docs/svn/svn-prefs.reg
@@ -0,0 +1,56 @@
+GEDIT4
+
+[HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Servers\groups]
+
+[HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Servers\global]
+"#http-proxy-host"=""
+"#http-proxy-port"=""
+"#http-proxy-username"=""
+"#http-proxy-password"=""
+"#http-proxy-exceptions"=""
+"#http-timeout"="0"
+"#http-compression"="yes"
+"#neon-debug-mask"=""
+"#ssl-authority-files"=""
+"#ssl-trust-default-ca"=""
+"#ssl-client-cert-file"=""
+"#ssl-client-cert-password"=""
+
+[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auth]
+"#store-auth-creds"="no"
+
+[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\helpers]
+"#editor-cmd"="notepad"
+"#diff-cmd"=""
+"#diff3-cmd"=""
+"#diff3-has-program-arg"=""
+
+[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\miscellany]
+"#global-ignores"="*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store"
+"#log-encoding"=""
+"#use-commit-times"=""
+"#template-root"=""
+"enable-auto-props"="yes"
+
+[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\tunnels]
+
+[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auto-props]
+"*.cpp"="svn:eol-style=native"
+"*.h"="svn:eol-style=native"
+"*.inl"="svn:eol-style=native"
+"*.html"="svn:eol-style=native"
+"*.sh"="svn:eol-style=native;svn:executable"
+"*.py"="svn:eol-style=native;svn:executable"
+"*.pl"="svn:eol-style=native;svn:executable"
+"*.mpc"="svn:eol-style=native"
+"*.mpb"="svn:eol-style=native"
+"*.mpt"="svn:eol-style=native"
+"*.hpp"="svn:eol-style=native"
+"*.cdp"="svn:eol-style=native"
+"*.xsd"="svn:eol-style=native"
+"*.txt"="svn:eol-style=native"
+"Change?og*"="svn:eol-style=native"
+"*.am"="svn:eol-style=native"
+"*.ac"="svn:eol-style=native"
+"*.lst"="svn:eol-style=native"
+"*.pm"="svn:eol-style=native"
diff --git a/ACE/docs/usage-bugzilla.html b/ACE/docs/usage-bugzilla.html
new file mode 100644
index 00000000000..8d0e1a0d342
--- /dev/null
+++ b/ACE/docs/usage-bugzilla.html
@@ -0,0 +1,102 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+ <!-- $Id$ -->
+ <head>
+ <title>DOC Center Bug Tracking System Usage</title>
+ </head>
+
+ <body text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff">
+ <h1>DOC Center Bug Tracking System Usage</h1>
+
+ <p>
+ The
+ <a href="http://www.dre.vanderbilt.edu">
+ Center for Distributed Object Computing</a> uses the
+ <a href="http://www.mozilla.org/projects/bugzilla/">Bugzilla</a>
+ bug tracking system to keep track of existing problems and
+ enhancement requests.
+
+ <p>
+ To streamline our development process, you can now use it to
+ enter problem reports or make a request for a particular feature
+ that you'd like to see integrated into
+ <a href="http://www.dre.vanderbilt.edu/ACE">ACE</a>,
+ <a href="http://www.dre.vanderbilt.edu/TAO">TAO</a> or <a
+ href="http://www.dre.vanderbilt.edu/CIAO">CIAO</a>.
+
+ <p>
+ You can also use it to track the status of a particular bug or
+ enhancement. In addition, the bug tracking system can be used
+ to add comments and attachments that contain solutions or simple
+ test cases.
+
+ <p>
+ The bug tracking system is located at the following web site:
+ <samp>
+ <a href="http://deuce.doc.wustl.edu/bugzilla/index.cgi">
+ http://deuce.doc.wustl.edu/bugzilla/index.cgi
+ </a>
+ </samp>
+
+ <p>
+ If all you want to do is browse through the bugs in our bug
+ tracking system or view bug summary reports, then you can use
+ the bug tracking system right away. However, if you want to be
+ able to submit bug reports then you will have to create a bug
+ tracking system account.
+
+ <p>
+ Upon entering a bug or enhancement request for the first time,
+ you will be asked to enter an e-mail address. Once you've done
+ that, you will be mailed a password that you can use to log on
+ to the bug tracking system. You will only be asked to do this
+ once. Any changes to bug reports you submit will be mailed to
+ the e-mail address you provide.
+
+ <p>
+ Once you've logged on, you will have the ability to enter bug
+ reports and modify existing ones. Other than adding comments,
+ fixes and attachments, please do not modify bug reports you
+ haven't submitted.
+
+ <p>
+ The bug tracking system is fairly straightforward to use. When
+ entering bug reports or enhancement requests, enter as much
+ information as possible. Most of the bug form fields provide
+ help if you are unsure what a particular field is used for.
+
+ <p>
+ For more information about using Bugzilla, and about bug
+ reporting in general, please see the following web sites:
+
+ <p>
+ <blockquote>
+ <samp>
+ <a href="http://www.mozilla.org/bugs">
+ http://www.mozilla.org/bugs/
+ </a><br>
+ <a href="http://www.mozilla.org/quality/bug-writing-guidelines.html">
+ http://www.mozilla.org/quality/bug-writing-guidelines.html
+ </a>
+ </samp>
+ </blockquote>
+
+ <p>
+ Keep in mind that the Bugzilla installation at the above web
+ site is <em>not</em> the same Bugzilla installation at the
+ Center for Distributed Object Computing. All bug reports and
+ enhancement requests for ACE and TAO should be done at the
+ Center for Distributed Object Computing's Bugzilla web site.
+
+
+
+ <hr>
+ <address><a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a></address>
+<!-- Created: Wed Aug 18 14:45:31 EDT 1999 -->
+<!-- hhmts start -->
+Last modified: Wed Nov 14 21:36:32 Pacific Standard Time 2001
+<!-- hhmts end -->
+ <br>
+ Back to <a href="index.html">ACE Documentation Home</a>.
+ </body>
+</html>
diff --git a/ACE/docs/wchar.txt b/ACE/docs/wchar.txt
new file mode 100644
index 00000000000..14c0d9e5ce0
--- /dev/null
+++ b/ACE/docs/wchar.txt
@@ -0,0 +1,128 @@
+/**
+@page wchar Wide Character/Unicode support in ACE
+
+Here's a first stab at some sort of documentation for the magic
+wide-character (wchar) stuff in ACE. It should be possible to compile
+ACE with wchar support on most platforms that ACE runs on. In some
+cases, we don't enable wchar support by default since it increases the
+footprint a bit. If you run into any problems, please use the
+$ACE_ROOT/PROBLEM-REPORT-FORM to let us know.
+
+@subsection wchar_overview Overview
+
+There are three different wchar configurations that ACE can use. These are
+no support mode, regular support mode, and full support mode (well, those are
+the best names I can come up with for now).
+
+@subsection wchar_nosupport No Support
+
+By default, ACE will not use wchar_t at all. This is for platforms where
+wchar_t does not exist or support for it is pretty flakey.
+
+@subsection wchar_regular Regular Support
+
+If ACE_HAS_WCHAR is defined, then ACE classes will be expanded to have extra
+methods which take in wchar_t strings. Note that all the methods available
+with No Support are also available here. This is the default in Windows
+right now, and has been tested to work on Linux and VxWorks (well, only been
+tested to compile/link of VxWorks).
+
+@subsection wchar_full Full Support
+
+Full support is turned on if ACE_HAS_WCHAR and ACE_USES_WCHAR are defined.
+Like Regular Support, both char and wchar_t versions of some methods are
+available, but unlike Regular Support, other methods that have char arguments
+or return values may have wchar_t arguments or return values.
+
+This has only been tested in Windows, and is the default for Windows CE.
+
+@subsection wchar_othermacros Other Important Macros
+
+In addition to the ACE_HAS_WCHAR and ACE_USES_WCHAR mentioned above, there
+are several other macros that are important when using wide character support
+in ACE.
+
+These other macros are used in code to conditionally switch between char and
+wchar_t. ACE_TCHAR is a char normally and wchar_t when ACE_USES_WCHAR is
+defined. ACE_TEXT ("foo") expands to "foo" normally and L"foo" when
+ACE_USES_WCHAR is defined.
+
+ACE_TEXT_CHAR_TO_TCHAR and ACE_TEXT_WCHAR_TO_TCHAR are used when a string
+that is always a char or wchar_t string needs to be converted to a ACE_TCHAR
+string. On the same note, ACE_TEXT_ALWAYS_CHAR is used when a string is
+ACE_TCHAR * and needs to be a char * string.
+
+ACE_TEXT_WIDE ("foo") is unique in that it always maps to L"foo". It is not
+a conditional macro.
+
+For string constants in code, ACE_TEXT and ACE_LIB_TEXT are used to put the
+Unicode prefix (Usually 'L') before the string when needed. By default both
+are controlled by ACE_USES_WCHAR.
+
+All ACE code except for the ACE library should use ACE_TEXT. ACE_LIB_TEXT
+was introduced as a short-term fix for backwards compatibility purposes.
+This allows ACE_TEXT to be overriden to act just like TEXT in Microsoft
+Windows while not affecting ACE's interface. In the future ACE_LIB_TEXT and
+this backwards compatibility will be deprecated and removed.
+
+Finally, on Windows there are a bunch of ACE_TEXT_Apicall type macros which
+are used to choose the correct version of a Win32 API function depending on
+ACE_USES_WCHAR. I'm hoping to remove these by adding a new ACE_OS_Win32
+class to perform the same task, but until then these ugly macros get the job
+done.
+
+@subsection wchar_logmsg ACE_Log_Msg support
+
+One of the more troublesome aspect of supporting wide and Ansi strings is
+the fact that the format strings for ACE_DEBUG and family always had to have
+ACE_TEXT (or ACE_LIB_TEXT) around them.
+
+Now this should not be the case, since ACE_Log_Msg was extended to support
+both types of format strings concurrently. This is okay, but when strings
+are printed out via the format_string, care has to be taken.
+
+It is interesting how Unix and Windows treats the format specifiers
+differently, based on their history. Win32 uses %s, %c, %S and %C, whereas
+Linux seems to use %s, %c, %ls, and %lc. And they even treat %s and %c
+differently. The route ACE takes is a bit of a mixture of both:
+
+- %c: prints out an Ansi character
+- %C: prints out an Ansi string
+- %s: prints out an ACE_TCHAR string
+- %w: prints out a Wide character
+- %W: prints out a Wide string
+
+An example, which will also function correctly even when ACE_USES_WCHAR is
+defined:
+
+@verbatim
+void print (char *a_str, wchar_t *w_str, ACE_TCHAR *t_str)
+{
+ ACE_DEBUG ((LM_DEBUG,
+ "%C %s %W\n",
+ a_str,
+ t_str,
+ w_str));
+}
+@endverbatim
+
+@subsection wchar_win32macros Relation to Win32's UNICODE and _UNICODE macros
+
+It used to be that in previous versions of ACE that the Win32 macros affected
+ACE in some way. This has been all removed in favor of the ACE_USES_WCHAR
+and ACE_HAS_WCHAR macros. Along with this, the definition of some of the
+Win32 string types (LPTSTR, LPCSTR, etc.) have been also removed. Since this
+isn't a direct concern of ACE, they will have to be defined separately if
+they are needed on non-Win32 platforms.
+
+The way I'd recommend doing this is to add the typdefs to config.h.
+
+@subsection wchar_legacy Legacy Support
+
+Most of the old macros (ACE_HAS_UNICODE, ACE_HAS_MOSTLY_UNICODE_APIS) are
+ignored by default by ACE, since the new macros replaced them. If
+ACE_LEGACY_MODE is defined, there is an attempt to map them to the new scheme
+by just ACE_HAS_UNICODE == ACE_HAS_WCHAR and ACE_HAS_MOSTLY_UNICODE_APIS ==
+ACE_USES_WCHAR.
+
+*/
View Lorry Controller Status