10139N/A<!
DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
10139N/A<
TITLE>Apache module mod_so</
TITLE>
10139N/A<!-- Background white, links blue (unvisited), navy (visited), red (active) --> 10139N/A<
H1 ALIGN="CENTER">Module mod_so</
H1>
10139N/A<
p>This module provides for loading of executable code and modules into the
10142N/Aserver at start-up or restart time.</
p>
10139N/A><
STRONG>Status:</
STRONG></
A> Base (Windows); Optional (Unix)
10139N/A><
STRONG>Module Identifier:</
STRONG></
A> so_module
10139N/A><
STRONG>Compatibility:</
STRONG></
A> Available in Apache 1.3 and later.
10139N/A<
P>On selected operating systems this module can be used to load modules
10139N/AObject</
A> (DSO) mechanism, rather than requiring a recompilation.
10139N/AOn Unix, the loaded code typically comes from shared object files
10139N/A(usually with <
SAMP>.so</
SAMP> extension), on Windows this may either
10139N/Athe <
SAMP>.so</
SAMP> or <
SAMP>.dll</
SAMP> extension. This module is
10139N/Aonly available in Apache 1.3 and up.
10139N/A<
p>In previous releases, the functionality of this module was provided
10139N/Afor Unix by mod_dld, and for Windows by mod_dll. On Windows, mod_dll
10139N/Awas used in beta release 1.3b1 through 1.3b5. mod_so combines these
10139N/Atwo modules into a single module for all operating systems.
10139N/A<
P><
STRONG> Warning: Apache 1.3 modules cannot be directly used with
10139N/A Apache 2.0 - the module must be modified to dynamically load or
10139N/A compile into Apache 2.0</
STRONG>.</
P>
10139N/A<
LI><
A HREF="#loadfile">LoadFile</
A>
10139N/A<
LI><
A HREF="#loadmodule">LoadModule</
A>
10139N/A<
H2><
A NAME="creating">Creating Loadable Modules for Windows</
A></
H2>
10139N/A<
P><
STRONG>Note: the module name format changed for Windows with Apache
10139N/A new naming convention is preferred; if you are converting your loadable
10139N/A module for 2.0, please fix the name to this 2.0 convention.</
P>
10139N/A<
P>The Apache module API is unchanged between the Unix and Windows
10139N/A versions. Many modules will run on Windows with no or little change
10139N/A from Unix, although others rely on aspects of the Unix architecture
10139N/A which are not present in Windows, and will not work.</
P>
10139N/A<
P>When a module does work, it can be added to the server in one of two
10139N/A ways. As with Unix, it can be compiled into the server. Because Apache
10139N/A for Windows does not have the <
CODE>Configure</
CODE> program of Apache
10139N/A for Unix, the module's source file must be added to the ApacheCore
10139N/A project file, and its symbols must be added to the
10139N/A<
P>The second way is to compile the module as a DLL, a shared library
10142N/A that can be loaded into the server at runtime, using the
10139N/A <
CODE><
A HREF="#loadmodule">LoadModule</
A></
CODE>
10139N/A directive. These module DLLs can be distributed and run on any Apache
10139N/A for Windows installation, without recompilation of the server.</
P>
10139N/A<
P>To create a module DLL, a small change is necessary to the module's
10139N/A source file: The module record must be exported from the DLL (which
10139N/A will be created later; see below). To do this, add the <
CODE 10139N/A >AP_MODULE_DECLARE_DATA</
CODE> (defined in the Apache header files)
10139N/A to your module's module record definition. For example, if your module
10139N/A module AP_MODULE_DECLARE_DATA foo_module;
10139N/A<
P>Note that this will only be activated on Windows, so the module can
10139N/A continue to be used, unchanged, with Unix if needed. Also, if you are
10139N/A familiar with <
CODE>.DEF</
CODE> files, you can export the module
10139N/A record with that method instead.</
P>
10139N/A<
P>Now, create a DLL containing your module. You will need to link this
10139N/A the compiler settings to ensure that the Apache header files are
10344N/A correctly located. You can find this library in your server root's
10139N/A modules directory. It is best to grab an existing module .dsp file
10139N/A from the tree to assure the build environment is configured correctly,
10139N/A or alternately compare the compiler and link options to your .dsp.</
P>
10139N/A<
P>This should create a DLL version of your module. Now simply place it
10139N/A in the <
SAMP>modules</
SAMP> directory of your server root, and use
10139N/A the <
CODE><
A HREF="#loadmodule">LoadModule</
A></
CODE> directive to
10139N/A<
H2><
A NAME="loadfile">LoadFile</
A> directive</
H2>
10139N/A<!--%plaintext <?INDEX {\tt LoadFile} directive> --> 10139N/A><
STRONG>Syntax:</
STRONG></
A> LoadFile <
EM>filename</
em>
10139N/A><
STRONG>Context:</
STRONG></
A> server config<
BR>
10139N/A><
STRONG>Status:</
STRONG></
A> Base<
BR>
10139N/A><
STRONG>Module:</
STRONG></
A> mod_so<
P>
10139N/AThe LoadFile directive links in the named object files or libraries
10139N/Awhen the server is started or restarted; this is used to load
10139N/Aadditional code which may be required for some module to
10139N/Awork. <
EM>Filename</
EM> is either and absolute path or relative to <
A 10139N/A<
H2><
A NAME="loadmodule">LoadModule</
A> directive</
H2>
10139N/A<!--%plaintext <?INDEX {\tt LoadModule} directive> --> 10139N/A><
STRONG>Syntax:</
STRONG></
A> LoadModule <
EM>module filename</
EM><
BR>
10139N/A><
STRONG>Context:</
STRONG></
A> server config<
BR>
10818N/A><
STRONG>Status:</
STRONG></
A> Base<
BR>
10232N/A><
STRONG>Module:</
STRONG></
A> mod_so<
P>
10165N/AThe LoadModule directive links in the object file or library
10165N/A<
EM>filename</
EM> and adds the module structure named <
EM>module</
EM>
10139N/Ato the list of active modules. <
EM>Module</
EM> is the name of the
10139N/Aexternal variable of type <
CODE>module</
CODE> in the file, and is
10139N/AIdentifier</
a> in the module documentation. Example:
10139N/A<
P>loads the named module from the modules subdirectory of the