summaryrefslogtreecommitdiff
path: root/etc
diff options
context:
space:
mode:
authorschmidt <douglascraigschmidt@users.noreply.github.com>1998-09-03 19:55:18 +0000
committerschmidt <douglascraigschmidt@users.noreply.github.com>1998-09-03 19:55:18 +0000
commit5ff0d6797080121bf919b1a2fae1f000a52b4801 (patch)
tree0d9c721e68adbb67e855a30ebb8066942e1e25b6 /etc
parente6f3e525227dd4ff0ee4c1ac981a0058484314b4 (diff)
downloadATCD-5ff0d6797080121bf919b1a2fae1f000a52b4801.tar.gz
*** empty log message ***
Diffstat (limited to 'etc')
-rw-r--r--etc/ACE-guidelines.html697
-rw-r--r--etc/ACE-porting.html184
-rw-r--r--etc/ACE-subsets.html684
-rw-r--r--etc/ACE-tutorials.html83
4 files changed, 0 insertions, 1648 deletions
diff --git a/etc/ACE-guidelines.html b/etc/ACE-guidelines.html
deleted file mode 100644
index b3b3d13cc37..00000000000
--- a/etc/ACE-guidelines.html
+++ /dev/null
@@ -1,697 +0,0 @@
-<!-- $Id$ -->
-
-<html>
- <head>
- <title>ACE Software Development Guidelines</title>
- <link rev=made href="mailto:levine@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>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>The program <strong><code>main</code></strong> function should
- always be declared with arguments, e.g.,
- <pre>
- int
- main (int argc, char *argv[])
- {
- [...]
-
- return 0;
- }
- </pre><p>
-
- It should also return 0 on successful termination, and non-zero
- otherwise.<p>
-
- <li>Avoid use of floating point types (float and double) and operations
- unless absolutely necessary. Not all ACE platforms support them.
- Therefore, wherever they are used, ACE_LACKS_FLOATING_POINT
- conditional code must be also be used.<p>
- </ul>
-
- <li><strong>Code Documentation</strong><p>
- <ul>
- <li>Use comments and whitespace (:-) liberally.<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>Comments, especially in header files, must follow the
- <a href=http://www.dscpl.com.au>OSE</a> Tools format requirements.
- Please see the ``Classinfo Tools'' section of the
- <a href=http://www.dscpl.com.au>OSE</a> ``Tools Manual''
- for these requirements.<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>Always insert a <strong><code>/**/</code></strong> between an
- <strong><code>#include</code></strong> and
- <strong><code>filename</code></strong>, as shown in the above
- example. This avoids dependency problems with Visual C++.<p>
-
- <li>Be very careful with names of macros and enum values. 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 #define <code>OK</code>, <code>SUCCESS</code>,
- <code>ERROR</code>, and so on.<p>
- </ul>
-
- <li><strong>C++ Syntax and Constructs</strong><p>
- <ul>
- <li><strong><code>for</code></strong> loops should look like:
- <pre>
- for (size_t i = 0; i &lt; Options::instance ()-&gt;spawn_count (); ++i)
- spawn ();
- </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 ACE_ASSERT:)
- <pre>
- for (size_t i = 0; i &lt; Options::instance ()-&gt;spawn_count (); ++i)
- {
- ACE_ASSERT (spawn () == 0);
- }
- </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>
-
- <li>Avoid unnecessary parenthesis. We're not writing Lisp :-)<p>
-
- <li>Put inline member functions in a <strong><code>.i</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.i"
- #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.i"
- #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 .i 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><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!<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;.
-
- ACE_INET_Addr &object_addr (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>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 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 function-style casts,
- <em>e.g.</em>, <code>int (foo)</code>. Instead, use
- one of the ACE cast macros:
-
- <pre>
- return ACE_static_cast(size_t, this-&gt;count_) &gt; that-&gt;size_;
- </pre><p>
-
- The general usage guidelines for the four styles of casts are:<p>
- <ul>
- <li><strong>ACE_const_cast</strong>: use to cast away
- constness, or volatile-ness.<p>
- <li><strong>ACE_static_cast</strong>: use to cast between
- compatible types, such as downcasting a pointer or narrowing
- an integer.<p>
- <li><strong>ACE_reinterpret_cast</strong>: use only when
- ACE_static_cast is not suitable.<p>
- <li><strong>ACE_dynamic_cast</strong>: avoid, unless you really
- want to type check at run-time.<p>
- </ul>
-
- <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>
- </ul>
-
- <li><strong>I/O</strong><p>
- <ul>
- <li>Use <strong><code>ACE_DEBUG</code></strong> for printouts,
- and <strong><code>ACE_OS::scanf/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>
- </ul>
-
- <li><strong>UNICODE conformity</strong><p>
-
- <ul>
- <li>Define strings as <strong><code>ASYS_TCHAR</code></strong> if
- they need to be passed into system API. It expands to
- <code>wchar_t</code> only when
- <code>ACE_HAS_MOSTLY_UNICODE_APIS</code> is defined.<p>
-
- <li>Use <strong><code>ASYS_TEXT</code></strong> and
- <strong><code>ASYS_WIDE_STRING</code></strong> for format
- strings and other string arguments passed to
- <code>ACE_DEBUG</code> or <code>ACE_ERROR</code>. For
- example,<p>
- <pre>
- void
- ACE_FOO::ace_bar (int err, ASYS_TCHAR *astr)
- {
- ACE_TRACE ("ACE_FOO::ace_bar");
-
- ACE_DEBUG ((LM_DEBUG, ASYS_TEXT ("From ACE_FOO::ace_bar")));
-
- if (err)
- ACE_ERROR ((LM_ERROR,
- ASYS_TEXT ("(%P) Printing this string %s\n"),
- astr));
- }
- </pre>
- <p>
- This is because ACE also support platforms which use UNICODE
- in most of their APIs. On these platforms, ACE also uses
- UNICODE as its system string type.<p>
-
- <li><strong><code>ACE_TRACE</code></strong> handles conversion
- between char strings and UNICODE strings automatically.<p>
-
- <li>Other helper macros include
- <strong><code>ASYS_MULTIBYTE_STRING</code></strong> and
- <strong><code>ASYS_ONLY_MULTIBYTE_STRING</code></strong>. See
- the end of <a href="../ace/OS.h">OS.h</a> for more details.<p>
-
- </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>
-
-</ul>
-
-
-<hr>
-<h3><a href="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">ACE</a>
- Usage Guidelines</h3>
-<ul>
- <li>Always use <strong><code>ACE_OS</code></strong> (static)
- member functions instead of bare OS system calls.<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 run-time type identification (RTTI). Some platforms
- do not support it.<p>
-
- <li>Do not use exception handling. Some platforms do not support it.
- And, it imposes an execution speed penalty.<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>Avoid using the C++ Standard Template Library (STL) in our
- applications. Some platforms do not support it yet.<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>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.<p>
-</ul>
-
-
-<hr>
-<h3>Script Guidelines</h3>
-<ul>
- <li>In general, it's best to write scripts in perl.<p>
-
- <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>If your perl script relies on features only available
- in never 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>
-</ul>
-
-
-<hr>
-<h3><a href="http://www.cs.wustl.edu/~schmidt/rules.html">ACE
- Design Rules</a></h3>
-
-
-<hr> <P>
- <font size=-1>
- Last modified <!--#echo var="LAST_MODIFIED" -->.<p>
- </font>
-
-</body>
-</html>
diff --git a/etc/ACE-porting.html b/etc/ACE-porting.html
deleted file mode 100644
index 42b82c380ed..00000000000
--- a/etc/ACE-porting.html
+++ /dev/null
@@ -1,184 +0,0 @@
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="Generator" CONTENT="Microsoft Word 97">
- <META NAME="Template" CONTENT="C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\html
-.dot">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.05 [en] (Win95; I) [Netscape]">
- <TITLE>Porting ACE and TAO to a New OS Platform</TITLE>
-</HEAD>
-<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#FF0000">
-
-<HR><P>
-<H3>Porting ACE and TAO to a New OS Platform</H3><P>
-
-The <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A>
-framework and the <A
-HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</A> ORB have been
-ported to <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE-versions-i.html">many OS
-platforms</A>. Porting ACE and TAO to new platforms is fairly easy.
-The following document describes the step-by-step process to use when
-porting the various <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE-overview.html">components
-and layers</A> in ACE to a new OS platform. Once ACE is ported, it is
-straightforward to port TAO, as well.<P>
-
-<hr align=left width="50%"><P>
-<H4>Create a <CODE>config.h</CODE> Header File for the Target OS Platform</H4>
-
-A <CODE>config-*.h</CODE> header file exists in <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/">$ACE_ROOT/ace</A>
-for each platform to which ACE has been ported. This file contains
-the portability macros for each particular configuration of ACE. A
-complete description of the existent macros can be found in the <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/README">$ACE_ROOT/ace/README</A>
-file. <P>
-
-Currently, you must edit this file by hand to port it to new OS
-platforms. It's a good idea to use the <CODE>config-*.h</CODE> files
-for platforms with similar characteristics as examples. Ultimately,
-we plan to <A HREF="http://squall.tn.cornell.edu/aceconf">auto
-configure</A> these files. <P>
-
-<hr align=left width="50%"><P>
-<H4>Port the <CODE>ACE_OS</CODE> Class</H4>
-
-The <CODE>ACE_OS</CODE> class encapsulates most of variation between
-the different OS implementations, <EM>e.g.</EM>, UNIX, Win32, and
-various real-time operating systems. It is the core class of the ACE
-OS abstraction layer. Most work required to port ACE to a new OS
-platform resides in this class. There are <EM>many</EM> examples of
-how ACE has been ported to other operating systems in the
-<CODE>ACE_OS</CODE> class in the
-<CODE>$ACE_ROOT/ace/OS.{h,i,cpp}</CODE> files. <P>
-
-Optional features in pthreads are covered by <CODE>ACE_HAS_*</CODE>
-and/or <CODE>ACE_LACKS_*</CODE> macros, which are described in the <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/README">$ACE_ROOT/ace/README</A>
-file. Particular platform features, such as DCE pthreads calls that
-end in <CODE>_np</CODE>, should be bracketed by platform defines
-rather than by inventing more <CODE>ACE_HAS_*</CODE> or
-<CODE>ACE_LACKS_*</CODE> definitions. <P>
-
-An important part of porting ACE to a new platform is to map the
-threading API correctly. Currently, ACE has support for the following
-thread APIs: <P>
-
-<UL>
-<LI> <B>UNIX International (UI) Threads</B>
- (<CODE>ACE_HAS_STHREADS</CODE>) - Solaris 2, UnixWare. <P>
-
-<LI> <B>POSIX Pthreads</B> (<CODE>ACE_HAS_PTHREADS</CODE>) - drafts 4
- [DCE], 6 [FSU], 7 [AIX], as well as the final standard (also
- called draft 10) [MIT, Linux, and Solaris]. <P>
-
-<LI> <B>Win32 Threads</B> (<CODE>ACE_HAS_WTHREADS</CODE>) - Windows
- NT, Windows '95/98, and Windows CE <P>
-<LI> <B>VxWorks Tasks</B> (<CODE>VXWORKS</CODE>) - VxWorks <P>
-</UL>
-
-If your OS platform does not support any of these threading packages,
-you must port the <CODE>ACE_OS::thr_*</CODE> functions. <P>
-
-<hr align=left width="50%"><P>
-<H4>Port the C++ Wrapper Components</H4>
-
-After porting the <CODE>ACE_OS</CODE> class, the next step is to port
-all of the ACE C++ wrapper components, such as sockets, threads,
-synchronization mechanisms. A full list of the categories and classes
-can be found in the <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ACE-categories">$ACE_ROOT/ACE-categories</a>
-file. It is easiest to concentrate on porting one category at the
-time. The ACE release contain a <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/tests/README">one-button
-test suite</A> in the <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/tests/">$ACE_ROOT/tests/</A>
-directory. These tests can be used to validate the correctness of the
-various ACE C++ wrappers as they are ported. <P>
-
-<hr align=left width="50%"><P>
-<H4>Port the Higher-level Framework Components of ACE</H4>
-
-Having ported (and tested) all the components of the ACE OS adaptation
-layer and C++ wrappers, you can proceed to port the higher level
-components of ACE, such as the Reactor, Service Configurator,
-Connector, Acceptor, and Streams frameworks. At this point, it should
-be relatively easy to port the rest of ACE because most of the
-platform-dependent code is localized in the lower layers of ACE. <P>
-
-<hr align=left width="50%"><P>
-<H4>Port TAO</H4>
-
-After porting and successfully testing all the ACE framework
-components, it also should be relatively easy to port and <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/TAO-INSTALL.html">install</A>
-TAO because all of its platform-dependent code is localized in ACE.
-Typically, the only problems that arise when porting TAO is bugs with
-C++ compilers. <P>
-
-<HR><P>
-<H3>C++ Features Required to Port ACE and TAO</H3>
-
-ACE and TAO have been ported to most C++ compilers. The following is
-a list of which C++ features a compiler must support in order to
-compile ACE and TAO:
-
-<UL>
-<LI> <B>Templates</B> -- The C++ compiler must support templates.
- However, it need not support template member functions nor must it
- support template traits. <P>
-
-<LI> <B>Multiple inheritance and dynamic binding</B> -- The C++
- compiler must support multiple inheritance and dynamic
- binding. <P>
-</UL>
-
-The following is a list of which C++ features that ACE and TAO can
-take advantage of if a compiler supports them:
-
-<UL>
-<LI> <B>Exceptions</B> -- The ACE library itself is ``exception
- neutral,'' <EM>i.e.,</EM> it does not catch or throw C++
- exceptions. However, you can use exceptions in code
- that uses ACE including throwing exceptions inside call back
- methods, as long as you provide the code to handle it.
- TAO can be configured to use C++ exceptions if ACE supports them,
- <EM>i.e.</EM>, if <CODE>ACE_HAS_EXCEPTIONS</CODE> is defined. <P>
-
-<LI> <B>RTTI and ANSI casts</B> -- If the OS platform supports RTTI
- and the new ANSI
- C++ casts, <EM>i.e.</EM>, <CODE>ACE_HAS_ANSI_CASTS</CODE> is
- enabled, then the various <CODE>ACE_*_cast</CODE> macros will
- utilize these casts. Otherwise, the macros will default to
- "C-style" casts. <P>
-
-<LI> <B>Namespaces</B> -- ACE does not utilize namespaces. However,
- TAO will automatically take advantage of namespaces if the C++
- compiler supports them, <EM>i.e.</EM>, if
- <CODE>ACE_HAS_BROKEN_NAMESPACES</CODE> is <EM>not</EM> enabled. <P>
-
-<LI> <B>STL</B> -- Unfortunately many of the platforms that ACE
- supports don't have an STL library. Moreover, different versions
- of STL behave differently. Therefore, ACE does not depends on
- STL and does not use it internally.
- If your target platform(s) support STL you should be able to
- use it with ACE and TAO without problems, though your C++
- compiler may have problems with it (this is beyond the scope
- of ACE, however). <P>
-
- If you are considering STL, you might consider
- <A HREF="http://corp.metabyte.com/~fbp/stl/index.html">STLport</a>,
- which is a port of the SGI STL to numerous platforms that ACE
- and TAO also support. <P>
-</UL>
-
-<P><HR><P>
-
-Back to the <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ACE-documentation.html">ACE
-documentation</A> page.
-
-<!--#include virtual="/~schmidt/cgi-sig.html" -->
-</BODY>
-</HTML>
diff --git a/etc/ACE-subsets.html b/etc/ACE-subsets.html
deleted file mode 100644
index a6bc60e8457..00000000000
--- a/etc/ACE-subsets.html
+++ /dev/null
@@ -1,684 +0,0 @@
-<HTML>
-
-<HEAD>
-<TITLE>ACE Subsets</TITLE>
-
-<BODY text = "#000000"
-link="#000fff"
-vlink="#ff0f0f"
-bgcolor="#ffffff">
-
-<HR>
-<H3>Proposal for Splitting ACE into Multiple Libraries</H3>
-
-The following is a draft of our proposal for spliting ACE into
-multiple libraries, each of which will contain a smaller subset of the
-overall ACE functionality. The primary motivations for subsetting ACE
-are:
-
-<UL>
-<LI> <EM>Principle of parsimony</EM> -- <EM>i.e.</EM>, developers
- should incur time/space overhead for components they use, rather
- than for all the components in the ACE framework. <P>
-
-<LI> <EM>Simplify the learning curve</EM> -- <EM>i.e.</EM>, developers
- only need to learn how to program components that they actually
- use. <P>
-</UL>
-
-The main design goals of this proposal are as follows: <P>
-
-<OL>
-<LI> Support the original libACE as before. Thus, for users who
-want to use the existing ACE library as is, there will be
-no changes, i.e., just link with <CODE>libACE</CODE> as usual. <P>
-
-<LI> Allow ACE (and TAO) programmers to use smaller subsets of the
-entire <CODE>libACE</CODE> library. These subsets will include the
-following libraries: <P>
-
-<DL>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif"> <CODE>libACE_OS</CODE>
--- This library contains the OS adaptation layer and its supporting
-classes. All other ACE libraries will depend on
-<CODE>libACE_OS</CODE> and it will depend on <EM>no</EM> other ACE
-libraries. <P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif">
-<CODE>libACE_Utils</CODE> -- This library contains the various ACE
-container classes and other miscellaneous classes, such as Singleton,
-auto_ptr, timers, etc. This library will depend only on
-<CODE>libACE_OS</CODE>.<P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif">
-<CODE>libACE_Logging</CODE> -- This library contains the various ACE
-logging and tracing classes. This library will depend only on
-<CODE>libACE_OS</CODE>. <P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif">
-<CODE>libACE_Threads</CODE> -- This library contains the ACE
-thread/process management and synchronization classes. This library
-will depend only on <CODE>libACE_OS</CODE>. <P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif">
-<CODE>libACE_Demux</CODE> -- This library contains the ACE Reactor and
-Proactor classes. This library will depend on <CODE>libACE_OS</CODE>
-and <CODE>libACE_Thread</CODE>. <P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif">
-<CODE>libACE_Connection</CODE> -- This library contains the ACE
-Connection components, i.e., Acceptor, Connector, and Svc_Handler.
-This library will depend on <CODE>libACE_OS</CODE>,
-<CODE>libACE_Thread</CODE>, and <CODE>libACE_Demux</CODE>. <P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif">
-<CODE>libACE_Sockets</CODE> -- This library contains the ACE C++
-wrappers for sockets. This library will depend on
-<CODE>libACE_OS</CODE>. <P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif"> <CODE>libACE_IPC</CODE>
--- This library contains all the ACE C++ wrappers for the other types
-of IPC and FILE I/O other than sockets. This library will depend on
-<CODE>libACE_OS</CODE> and <CODE>libACE_Sockets</CODE>. <P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif">
-<CODE>libACE_Svcconf</CODE> -- This library contains the ACE C++
-wrappers for the Service Configurator. This library will depend on
-<CODE>libACE_OS</CODE>, <CODE>libACE_Demux</CODE>,
-<CODE>libACE_Thread</CODE>, and <CODE>libACE_Sockets</CODE>. <P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif">
-<CODE>libACE_Streams</CODE> -- This library contains the ACE Streams
-classes. This library will depend on <CODE>libACE_OS</CODE>,
-<CODE>libACE_Demux</CODE>, and <CODE>libACE_Thread</CODE>. <P>
-
-<DT> <img alt="o" src="gifs/misc/redball.gif">
-<CODE>libACE_Memory</CODE> -- This library contains the ACE C++
-wrappers for shared memory and memory-mapped files. This library will
-depend on <CODE>libACE_OS</CODE>.<P>
-
-</DL>
-</OL>
-
-In addition, we will create <CODE>libACE_TAO</CODE>, which contains
-just the core set of components in ACE that are required to support
-TAO. This library is targeted at embedded systems developers who want
-to minimize the footprint of ACE+TAO. <P>
-
-Note that the ACE library subsets described above are intended as a
-guideline, <EM>not</EM> a complete specification. The actual
-partitioning of files in the final ACE library subsets may differ
-somewhat in order to improve footprint and simplify common
-use-cases. <P>
-
-<HR><P>
-<H3>Configuration Management</H3>
-
-Configuration management for the ACE library subsets described above
-will be organized as follows:
-
-<OL>
-<LI> A single source tree with a single "version" for the source
- tree. <P>
-
-<LI> Releases of libACE and its "subsets" will be atomic, <EM>i.e.</EM>,
- all or nothing. <P>
-</OL>
-
-<HR><P>
-<H3>Classes in Each ACE Library Subset</H3>
-
-Below, we describe the classes in each ACE library subset.
-
-<H4>libACE_OS</H4>
-
-This library contains the OS adaptation layer and its supporting
-classes. The classes in this library should not depend on any other
-ACE library subsets. All of the other libraries will depend on this
-library. The following classes are included in this library.
-
-<PRE><CODE>
-ACE.cpp
-ACE.h
-ACE.i
-config.h
-Basic_Types.cpp
-Basic_Types.h
-Basic_Types.i
-OS.cpp
-OS.h
-OS.i
-Version.h
-</PRE></CODE>
-
-<H4>libACE_Utils</H4>
-
-This library contains the following ACE container classes and other
-miscellaneous classes.
-
-<PRE><CODE>
-ARGV.cpp
-ARGV.h
-ARGV.i
-Array.cpp
-Array.h
-Array.i
-Auto_Ptr.cpp
-Auto_Ptr.h
-Auto_Ptr.i
-Containers.cpp
-Containers.i
-Containers.h
-Date_Time.cpp
-Date_Time.h
-Date_Time.i
-Dynamic.cpp
-Dynamic.h
-Dynamic.i
-Filecache.cpp
-Filecache.h
-Free_List.cpp
-Free_List.i
-Free_List.h
-Get_Opt.cpp
-Get_Opt.h
-Get_Opt.i
-Hash_Map_Manager.cpp
-Hash_Map_Manager.h
-High_Res_Timer.cpp
-High_Res_Timer.h
-High_Res_Timer.i
-Managed_Object.cpp
-Managed_Object.h
-Managed_Object.i
-Map_Manager.cpp
-Map_Manager.h
-Map_Manager.i
-Object_Manager.cpp
-Object_Manager.i
-Object_Manager.h
-Profile_Timer.cpp
-Profile_Timer.h
-Profile_Timer.i
-Registry.cpp
-Registry.h
-Singleton.cpp
-Singleton.h
-Singleton.i
-SString.cpp
-SString.h
-SString.i
-System_Time.cpp
-System_Time.h
-Time_Request_Reply.cpp
-Time_Request_Reply.h
-Time_Value.cpp
-Time_Value.h
-Time_Value.i
-Timer_Hash.cpp
-Timer_Hash.h
-Timer_Hash_T.cpp
-Timer_Hash_T.h
-Timer_Heap.cpp
-Timer_Heap.h
-Timer_Heap.i
-Timer_Heap_T.cpp
-Timer_Heap_T.h
-Timer_Heap_T.i
-Timer_List.cpp
-Timer_List.h
-Timer_List.i
-Timer_List_T.cpp
-Timer_List_T.h
-Timer_List_T.i
-Timer_Queue.cpp
-Timer_Queue.h
-Timer_Queue.i
-Timer_Queue_Adapters.cpp
-Timer_Queue_Adapters.h
-Timer_Queue_Adapters.i
-Timer_Queue_T.cpp
-Timer_Queue_T.h
-Timer_Queue_T.i
-Timer_Wheel.cpp
-Timer_Wheel.h
-Timer_Wheel.i
-Timer_Wheel_T.cpp
-Timer_Wheel_T.h
-Timer_Wheel_T.i
-</PRE></CODE>
-
-<H4>libACE_Logging</H4>
-
-This library contains the various ACE logging and tracing classes.
-
-<PRE><CODE>
-Dump.cpp
-Dump.h
-Dump_T.cpp
-Dump_T.h
-Log_Msg.cpp
-Log_Msg.h
-Log_Msg.i
-Log_Priority.h
-Log_Record.cpp
-Log_Record.h
-Log_Record.i
-Trace.cpp
-Trace.h
-Trace.i
-</PRE></CODE>
-
-<H4>libACE_Threads</H4>
-
-This library contains the ACE thread/process management and
-synchronization classes.
-
-<PRE><CODE>
-Activation_Queue.h
-Activation_Queue.cpp
-Atomic_Op.i
-Future.h
-Future.cpp
-Method_Object.h
-Method_Object.cpp
-Process.cpp
-Process.h
-Process.i
-Process_Manager.cpp
-Process_Manager.h
-Process_Manager.i
-Sched_Params.cpp
-Sched_Params.h
-Sched_Params.i
-Synch.cpp
-Synch.h
-Synch.i
-Synch_Options.cpp
-Synch_Options.h
-Synch_Options.i
-Synch_T.cpp
-Synch_T.h
-Synch_T.i
-Thread.cpp
-Thread.h
-Thread.i
-Thread_Manager.cpp
-Thread_Manager.h
-Thread_Manager.i
-Token.cpp
-Token.h
-Token.i
-</PRE></CODE>
-
-<H4>libACE_Demux</H4>
-
-This library contains the ACE Reactor and its associated classes,
-including the ACE Connection components.
-
-<PRE><CODE>
-Event_Handler.cpp
-Event_Handler.h
-Event_Handler.i
-Event_Handler_T.cpp
-Event_Handler_T.h
-Event_Handler_T.i
-Handle_Set.cpp
-Handle_Set.h
-Handle_Set.i
-Priority_Reactor.cpp
-Priority_Reactor.i
-Priority_Reactor.h
-Proactor.h
-Proactor.i
-Proactor.cpp
-Reactor.cpp
-Reactor.h
-Reactor.i
-Reactor_Impl.h
-Select_Reactor.cpp
-Select_Reactor.h
-Select_Reactor.i
-WFMO_Reactor.cpp
-WFMO_Reactor.h
-WFMO_Reactor.i
-XtReactor.cpp
-XtReactor.h
-</PRE></CODE>
-
-<H4>libACE_Connection</H4>
-
-This library contains the ACE Connection components, i.e., Acceptor,
-Connector, and Svc_Handler.
-
-<PRE><CODE>
-Acceptor.cpp
-Acceptor.h
-Acceptor.i
-Asynch_Acceptor.cpp
-Asynch_Acceptor.h
-Asynch_Acceptor.i
-Asynch_IO.cpp
-Asynch_IO.h
-Asynch_IO.i
-Connector.cpp
-Connector.h
-Connector.i
-Dynamic_Service.cpp
-Dynamic_Service.h
-Dynamic_Service.i
-Strategies.cpp
-Strategies.h
-Strategies.i
-Strategies_T.cpp
-Strategies_T.h
-Strategies_T.i
-Svc_Handler.cpp
-Svc_Handler.h
-Svc_Handler.i
-</PRE></CODE>
-
-<H4>libACE_Sockets</H4>
-
-This library contains the ACE C++ wrappers for sockets.
-
-<PRE><CODE>
-IPC_SAP.cpp
-IPC_SAP.h
-IPC_SAP.i
-LOCK_SOCK_Acceptor.cpp
-LOCK_SOCK_Acceptor.h
-LSOCK.cpp
-LSOCK.h
-LSOCK.i
-LSOCK_Acceptor.cpp
-LSOCK_Acceptor.h
-LSOCK_Acceptor.i
-LSOCK_CODgram.cpp
-LSOCK_CODgram.h
-LSOCK_CODgram.i
-LSOCK_Connector.cpp
-LSOCK_Connector.h
-LSOCK_Connector.i
-LSOCK_Dgram.cpp
-LSOCK_Dgram.h
-LSOCK_Dgram.i
-LSOCK_Stream.cpp
-LSOCK_Stream.h
-LSOCK_Stream.i
-SOCK.cpp
-SOCK.h
-SOCK.i
-SOCK_Acceptor.cpp
-SOCK_Acceptor.h
-SOCK_Acceptor.i
-SOCK_CODgram.cpp
-SOCK_CODgram.h
-SOCK_CODgram.i
-SOCK_Connector.cpp
-SOCK_Connector.h
-SOCK_Connector.i
-SOCK_Dgram.cpp
-SOCK_Dgram.h
-SOCK_Dgram.i
-SOCK_Dgram_Bcast.cpp
-SOCK_Dgram_Bcast.h
-SOCK_Dgram_Bcast.i
-SOCK_Dgram_Mcast.cpp
-SOCK_Dgram_Mcast.h
-SOCK_Dgram_Mcast.i
-SOCK_IO.cpp
-SOCK_IO.h
-SOCK_IO.i
-SOCK_Stream.cpp
-SOCK_Stream.h
-SOCK_Stream.i
-
-</PRE></CODE>
-
-<H4>libACE_IPC</H4>
-
-This library contains all the ACE C++ wrappers for the other types of
-IPC and FILE I/O other than sockets. This library will depend on the
-<CODE>libACE_Socket</CODE> library.
-
-<PRE><CODE>
-
-Addr.cpp
-Addr.h
-Addr.i
-DEV.cpp
-DEV.h
-DEV.i
-DEV_Addr.cpp
-DEV_Addr.h
-DEV_Addr.i
-DEV_Connector.cpp
-DEV_Connector.h
-DEV_Connector.i
-DEV_IO.cpp
-DEV_IO.h
-DEV_IO.i
-FIFO.cpp
-FIFO.h
-FIFO.i
-FIFO_Recv.cpp
-FIFO_Recv.h
-FIFO_Recv.i
-FIFO_Recv_Msg.cpp
-FIFO_Recv_Msg.h
-FIFO_Recv_Msg.i
-FIFO_Send.cpp
-FIFO_Send.h
-FIFO_Send.i
-FIFO_Send_Msg.cpp
-FIFO_Send_Msg.h
-FIFO_Send_Msg.i
-FILE_Addr.cpp
-FILE_Addr.h
-FILE_Addr.i
-FILE.cpp
-FILE.h
-FILE.i
-FILE_Connector.cpp
-FILE_Connector.h
-FILE_Connector.i
-FILE_IO.cpp
-FILE_IO.h
-FILE_IO.i
-INET_Addr.cpp
-INET_Addr.h
-INET_Addr.i
-IO_SAP.cpp
-IO_SAP.h
-IO_SAP.i
-IOStream.cpp
-IOStream.h
-IOStream_T.cpp
-IOStream_T.h
-IOStream_T.i
-Pipe.cpp
-Pipe.h
-Pipe.i
-Signal.cpp
-Signal.h
-Signal.i
-
-SPIPE_Addr.cpp
-SPIPE_Addr.h
-SPIPE_Addr.i
-SPIPE.cpp
-SPIPE.h
-SPIPE.i
-SPIPE_Acceptor.cpp
-SPIPE_Acceptor.h
-SPIPE_Acceptor.i
-SPIPE_Connector.cpp
-SPIPE_Connector.h
-SPIPE_Connector.i
-SPIPE_Stream.cpp
-SPIPE_Stream.h
-SPIPE_Stream.i
-SV_Message.cpp
-SV_Message.h
-SV_Message.i
-SV_Message_Queue.cpp
-SV_Message_Queue.h
-SV_Message_Queue.i
-SV_Semaphore_Complex.cpp
-SV_Semaphore_Complex.h
-SV_Semaphore_Complex.i
-SV_Semaphore_Simple.cpp
-SV_Semaphore_Simple.h
-SV_Semaphore_Simple.i
-SV_Shared_Memory.cpp
-SV_Shared_Memory.h
-SV_Shared_Memory.i
-TLI.cpp
-TLI.h
-TLI.i
-TLI_Acceptor.cpp
-TLI_Acceptor.h
-TLI_Acceptor.i
-TLI_Connector.cpp
-TLI_Connector.h
-TLI_Connector.i
-TLI_Stream.cpp
-TLI_Stream.h
-TLI_Stream.i
-TTY_IO.cpp
-TTY_IO.h
-Typed_SV_Message.cpp
-Typed_SV_Message.h
-Typed_SV_Message.i
-Typed_SV_Message_Queue.cpp
-Typed_SV_Message_Queue.h
-Typed_SV_Message_Queue.i
-UNIX_Addr.cpp
-UNIX_Addr.h
-UNIX_Addr.i
-UPIPE_Addr.h
-UPIPE_Acceptor.cpp
-UPIPE_Acceptor.h
-UPIPE_Acceptor.i
-UPIPE_Connector.cpp
-UPIPE_Connector.h
-UPIPE_Connector.i
-UPIPE_Stream.cpp
-UPIPE_Stream.h
-UPIPE_Stream.i
-</PRE></CODE>
-
-<H4>libACE_Svcconf</H4>
-
-This library contains the ACE C++ wrappers for the Service
-Configurator component.
-
-<PRE><CODE>
-Parse_Node.cpp
-Parse_Node.h
-Parse_Node.i
-Service_Config.cpp
-Service_Config.h
-Service_Config.i
-Service_Main.cpp
-Service_Manager.cpp
-Service_Manager.h
-Service_Manager.i
-Service_Object.cpp
-Service_Object.h
-Service_Object.i
-Service_Record.cpp
-Service_Record.h
-Service_Record.i
-Service_Repository.cpp
-Service_Repository.h
-Service_Repository.i
-Service_Types.cpp
-Service_Types.i
-Service_Types.h
-Shared_Object.cpp
-Shared_Object.h
-Shared_Object.i
-Svc_Conf.h
-Svc_Conf_l.cpp
-Svc_Conf_y.cpp
-Svc_Conf_Tokens.h
-</PRE></CODE>
-
-<H4>libACE_Streams</H4>
-
-This library contains the ACE Streams classes.
-
-<PRE><CODE>
-IO_Cntl_Msg.cpp
-IO_Cntl_Msg.h
-IO_Cntl_Msg.i
-Message_Block.cpp
-Message_Block.h
-Message_Block.i
-Message_Queue.cpp
-Message_Queue.h
-Message_Queue.i
-Message_Queue_T.cpp
-Message_Queue_T.h
-Message_Queue_T.i
-Module.cpp
-Module.h
-Module.i
-Multiplexor.cpp
-Multiplexor.h
-Multiplexor.i
-Stream.cpp
-Stream.h
-Stream.i
-Stream_Modules.cpp
-Stream_Modules.h
-Stream_Modules.i
-Task.cpp
-Task.h
-Task.i
-Task_T.cpp
-Task_T.h
-Task_T.i
-</PRE></CODE>
-
-<H4>libACE_Memory</H4>
-
-This library contains the ACE C++ wrappers for shared memory and
-memory-mapped files.
-
-<PRE><CODE>
-Malloc.cpp
-Malloc.h
-Malloc.i
-Malloc_T.cpp
-Malloc_T.h
-Malloc_T.i
-Mem_Map.cpp
-Mem_Map.h
-Mem_Map.i
-Memory_Pool.cpp
-Memory_Pool.h
-Memory_Pool.i
-Obstack.cpp
-Obstack.h
-Read_Buffer.cpp
-Read_Buffer.h
-Read_Buffer.i
-Shared_Memory.h
-Shared_Memory_MM.cpp
-Shared_Memory_MM.h
-Shared_Memory_MM.i
-Shared_Memory_SV.cpp
-Shared_Memory_SV.h
-Shared_Memory_SV.i
-</PRE></CODE>
-
-<HR><P>
-Back to the <A HREF="ACE.html">ACE</A> home page.
-
-<!--#include virtual="/~schmidt/cgi-sig.html" -->
-</BODY>
-</HTML>
diff --git a/etc/ACE-tutorials.html b/etc/ACE-tutorials.html
deleted file mode 100644
index 63df8e7df59..00000000000
--- a/etc/ACE-tutorials.html
+++ /dev/null
@@ -1,83 +0,0 @@
-<TITLE>ACE Beginners' Guide</TITLE>
-<BODY text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff">
-
-<HR><P>
-<H3>The Beginners' Guide to ACE</H3>
-
-The <A HREF="http://www.cs.wustl.edu/~schmidt/ACE-members.html">ACE
-development team</A> is creating a set of tutorials to help ACE
-newcomers learn how to use the framework effectively. <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/etc/tutorials/index.html">Follow
-this link to the tutorials.</A> <P>
-
-<HR>
-<H3>Developing New Tutorials</H3>
-
-Here are some general guidelines for creating tutorials: <P>
-
-<UL>
-<LI> Choose a topic that you know very well or are just learning.
-<P>
- This isn't really a conflict...
-<P>
- If you know a topic very well, you're likely to know what is most
- important to the novice and what can be left until later. If you're
- just learning a topic, then you know what questions you have that
- must be answered before you can continue.
-<P>
-<LI> Keep it simple.
-<P>
- Don't try to use a lot of really cool ACE features along the way. Stick
- to the basic stuff and show that. Try to use a minimum of ACE objects
- that are not the direct target of the tutorial.
-<P>
- (For instance, don't get all caught up in ACE_Singleton<> if you're
- trying to show how to use an ACE_Reactor.)
-<P>
- If you want to show something really cool that happens to depend on
- another ACE feature, do a tutorial on that other feature first! I've
- found that folks will tend to get stuck on *anything* they don't
- understand even if it isn't directly relevant to what you're trying
- to teach.
-<P>
-<LI> Document the heck out of it!
-<P>
- There's no such thing as too much documentation. Don't worry about
- repeating yourself along the way. Assume that the reader knows nothing
- at all about the topic at hand and explain even the parts that you feel
- are painfully obvious.
-<P>
- If you feel that sticking a bunch of comments in the code makes it harder
- to read then stick in a label and document at the end of the file or
- something. Alternately, create both a well-documented version and a
- sparsely-documented version. Then folks can choose between 'em.
-<P>
-<LI> Over-teach it.
-<P>
- If there's a tutorial created for a topic that you feel strong in,
- create another one anyway. Everybody tends to code a little differently.
- Perhaps your tutorial style will "feel" better to some newcomers
- than an existing tutorial. You won't hurt anybody's feelings if
- you present the same material in a different way.
-<P>
-<LI> Steal existing code.
-<P>
- The ultimate form of code reuse :-) Seriously... grab one or more
- of the existing ACE tests or examples. Then strip it down to the
- bare bones & add heaps of comments. I don't think the software-police
- will be coming after anyone for that!
-</UL>
-<P>
-If this thing takes off, I'll start to organize the tutorials into
-groups. For now, lets concentrate on quantity & quality. Organization
-can come later...
-<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>