--- /dev/null
+<?xml version="1.0"?>
+<?xml-stylesheet type="text/xsl" href="../style/manual.xsl"?>
+<modulesynopsis>
+
+<name>mod_so</name>
+<status>Base (Windows>; Optional (Unix)</status>
+<identifier>so_module</identifier>
+<sourcefile>mod_so.c</sourcefile>
+<compatibility>Available in Apache 1.3 and later.</compatibility>
+
+<description>
+This module provides for loading of executable code and
+modules into the server at start-up or restart time.</description>
+
+<summary>
+
+ <p>On selected operating systems this module can be used to
+ load modules into Apache at runtime via the <a
+ href="../dso.html">Dynamic Shared Object</a> (DSO) mechanism,
+ rather than requiring a recompilation.</p>
+
+ <p>On Unix, the loaded code typically comes from shared object
+ files (usually with <samp>.so</samp> extension), on Windows
+ this may either the <samp>.so</samp> or <samp>.dll</samp>
+ extension. This module is only available in Apache 1.3 and
+ up.</p>
+
+ <p>In previous releases, the functionality of this module was
+ provided for Unix by mod_dld, and for Windows by mod_dll. On
+ Windows, mod_dll was used in beta release 1.3b1 through 1.3b5.
+ mod_so combines these two modules into a single module for all
+ operating systems.</p>
+
+ <p><strong>Warning: Apache 1.3 modules cannot be directly used
+ with Apache 2.0 - the module must be modified to dynamically
+ load or compile into Apache 2.0</strong>.</p>
+</summary>
+
+<section><title id="creating">Creating Loadable Modules
+for Windows</title>
+
+ <p><note>Note: the module name format changed for Windows
+ with Apache 1.3.15 and 2.0 - the modules are now named as
+ mod_foo.so</note>. While mod_so still loads modules with
+ ApacheModuleFoo.dll names, the new naming convention is
+ preferred; if you are converting your loadable module for 2.0,
+ please fix the name to this 2.0 convention.</p>
+
+ <p>The Apache module API is unchanged between the Unix and
+ Windows versions. Many modules will run on Windows with no or
+ little change from Unix, although others rely on aspects of the
+ Unix architecture which are not present in Windows, and will
+ not work.</p>
+
+ <p>When a module does work, it can be added to the server in
+ one of two ways. As with Unix, it can be compiled into the
+ server. Because Apache for Windows does not have the
+ <code>Configure</code> program of Apache for Unix, the module's
+ source file must be added to the ApacheCore project file, and
+ its symbols must be added to the
+ <code>os\win32\modules.c</code> file.</p>
+
+ <p>The second way is to compile the module as a DLL, a shared
+ library that can be loaded into the server at runtime, using
+ the <code><directive>LoadModule</directive></code>
+ directive. These module DLLs can be distributed and run on any
+ Apache for Windows installation, without recompilation of the
+ server.</p>
+
+ <p>To create a module DLL, a small change is necessary to the
+ module's source file: The module record must be exported from
+ the DLL (which will be created later; see below). To do this,
+ add the <code>AP_MODULE_DECLARE_DATA</code> (defined in the
+ Apache header files) to your module's module record definition.
+ For example, if your module has:</p>
+
+<example>
+ module foo_module;
+</example>
+
+ <p>Replace the above with:</p>
+<example>
+ module AP_MODULE_DECLARE_DATA foo_module;
+</example>
+
+ <p>Note that this will only be activated on Windows, so the
+ module can continue to be used, unchanged, with Unix if needed.
+ Also, if you are familiar with <code>.DEF</code> files, you can
+ export the module record with that method instead.</p>
+
+ <p>Now, create a DLL containing your module. You will need to
+ link this against the libhttpd.lib export library that is
+ created when the libhttpd.dll shared library is compiled. You
+ may also have to change the compiler settings to ensure that
+ the Apache header files are correctly located. You can find
+ this library in your server root's modules directory. It is
+ best to grab an existing module .dsp file from the tree to
+ assure the build environment is configured correctly, or
+ alternately compare the compiler and link options to your
+ .dsp.</p>
+
+ <p>This should create a DLL version of your module. Now simply
+ place it in the <samp>modules</samp> directory of your server
+ root, and use the <directive>LoadModule</directive>
+ directive to load it.</p>
+
+</section>
+
+<directivesynopsis>
+<name>LoadFile</name>
+<syntax>LoadFile <em>filename</em> [<em>filename</em>] ...</syntax>
+<default>none</default>
+<contextlist>
+<context>server config</context>
+</contextlist>
+<description>Link in the named object file or library</description>
+
+<usage>
+
+ <p>The LoadFile directive links in the named object files or
+ libraries when the server is started or restarted; this is used
+ to load additional code which may be required for some module
+ to work. <em>Filename</em> is either an absolute path or
+ relative to <a href="core.html#serverroot">ServerRoot</a>.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>LoadModule</name>
+<syntax>LoadModule <em>module filename</em></syntax>
+<default>none</default>
+<contextlist>
+<context>server config</context>
+</contextlist>
+<description>Links in the object file or library, and adds to the list
+of active modules</description>
+
+<usage>
+ <p>The LoadModule directive links in the object file or library
+ <em>filename</em> and adds the module structure named
+ <em>module</em> to the list of active modules. <em>Module</em>
+ is the name of the external variable of type
+ <code>module</code> in the file, and is listed as the <a
+ href="module-dict.html#ModuleIdentifier">Module Identifier</a>
+ in the module documentation. Example:</p>
+
+ <example>
+ LoadModule status_module modules/mod_status.so
+ </example>
+
+ <p>loads the named module from the modules subdirectory of the
+ ServerRoot.</p>
+</usage>
+
+</directivesynopsis>
+</modulesynopsis>
+
projects / apache / commitdiff