From: Rich Bowen Date: Mon, 4 Mar 2002 02:55:47 +0000 (+0000) Subject: Conversion to xml X-Git-Tag: 2.0.33~39 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=861329037770450bfbc26506df84c116679c0d82;p=apache Conversion to xml git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93691 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_so.xml b/docs/manual/mod/mod_so.xml new file mode 100755 index 0000000000..2c510b9249 --- /dev/null +++ b/docs/manual/mod/mod_so.xml @@ -0,0 +1,157 @@ + + + + +mod_so +Base (Windows>; Optional (Unix) +so_module +mod_so.c +Available in Apache 1.3 and later. + + +This module provides for loading of executable code and +modules into the server at start-up or restart time. + + + +

On selected operating systems this module can be used to + load modules into Apache at runtime via the Dynamic Shared Object (DSO) mechanism, + rather than requiring a recompilation.

+ +

On Unix, the loaded code typically comes from shared object + files (usually with .so extension), on Windows + this may either the .so or .dll + extension. This module is only available in Apache 1.3 and + up.

+ +

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.

+ +

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.

+ + +
Creating Loadable Modules +for Windows + +

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. 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.

+ +

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.

+ +

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 + Configure 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 + os\win32\modules.c file.

+ +

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 LoadModule + directive. These module DLLs can be distributed and run on any + Apache for Windows installation, without recompilation of the + server.

+ +

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 AP_MODULE_DECLARE_DATA (defined in the + Apache header files) to your module's module record definition. + For example, if your module has:

+ + + module foo_module; + + +

Replace the above with:

+ + module AP_MODULE_DECLARE_DATA foo_module; + + +

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 .DEF files, you can + export the module record with that method instead.

+ +

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.

+ +

This should create a DLL version of your module. Now simply + place it in the modules directory of your server + root, and use the LoadModule + directive to load it.

+ +
+ + +LoadFile +LoadFile filename [filename] ... +none + +server config + +Link in the named object file or library + + + +

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. Filename is either an absolute path or + relative to ServerRoot.

+ + + + +LoadModule +LoadModule module filename +none + +server config + +Links in the object file or library, and adds to the list +of active modules + + +

The LoadModule directive links in the object file or library + filename and adds the module structure named + module to the list of active modules. Module + is the name of the external variable of type + module in the file, and is listed as the Module Identifier + in the module documentation. Example:

+ + + LoadModule status_module modules/mod_status.so + + +

loads the named module from the modules subdirectory of the + ServerRoot.

+ + + + +