Title: Achtung
Bei bestimmten Betriebssystemen können mit diesem Modul mit Hilfe des Dynamic Shared Object-Verfahrens (DSO) während der Laufzeit Module geladen werden, ohne dass ein erneutes Kompilieren erforderlich ist.
Unter Unix stammt der geladene Code normalerweise aus
Shared Object-Dateien (meist mit der Endung .so). Unter
Windows lauten die Dateinamenserweiterungen .so
oder .dll.
Apache 1.3-Module können für Apache 2.0 nicht direkt geladen werden. Sie müssen für das dynamische Laden modifiziert oder beim Kompilieren in Apache 2.0 eingebunden werden.
Das Namensformat für Windows-Module wurde mit den
Apache-Versionen 1.3.15 und 2.0 geändert. Sie heißen jetzt
mod_foo.so.
mod_so lädt zwar weiterhin Module mit dem
Namensmuster ApacheModuleFoo.dll, die neue
Namenskonvention ist aber vorzuziehen. Die ladbaren Module sollten
bei der Anpassung für die Version 2.0 der neuen Konvention angepasst
werden.
Die Modul-API der Apache-Server für Unix und Windows unterscheiden sich nicht. Viele Unix-Module laufen unter Windows ohne oder mit nur geringfügigen Änderungen. Module, die auf Eigenarten des Betriebssystems Unix basieren, die unter Windows nicht vorhanden sind, funktionieren nicht.
Funktioniert ein Modul, dann kann es dem Server auf zwei Arten
hinzugefügt werden. Wie unter Unix kann es beim Kompilieren in den Server
eingebunden werden. Da Apache für Windows nicht das
Configure-Programm der Unix-Version enthält,
müssen die Quelldatei des Moduls der ApacheCore-Projektdatei
und deren Symbole der Datei os\win32\modules.c
hinzugefügt werden.
Das Modul kann aber auch als DLL kompiliert werden. Eine DLL ist eine
gemeinsam genutzte Bibliothek, die mit der Direktive
während der Ausführung in den Server geladen werden kann. Diese
Modul-DLLs können weitergegeben werden und funktionieren unter jeder
Windows-Installation des Apache-Servers.
Um eine Modul-DLL zu erzeugen, muss an der Quelldatei des Moduls
eine kleine Änderung vorgenommen werden: Der Moduldatensatz
muss aus der DLL exportiert werden (die später erzeugt wird, siehe unten).
Hierfür fügt man AP_MODULE_DECLARE_DATA
(definiert in den Apache Header-Dateien) der Datensatzdefinition
des Moduls hinzu. Zum Beispiel muss:
ersetzt werden durch:
Diese Änderung hat nur unter Windows Auswirkungen, unter
Unix kann das Modul bei Bedarf auch so verwendet werden.
Wenn Sie sich mit .DEF-Dateien auskennen, können
Sie das Modul auch mit dieser Methode exportieren.
Anschließend wird eine DLL mit dem Modul erzeugt. Hierfür muss die
Exportbibliothek libhttpd.lib eingebunden werden,
die beim Kompilieren der Bibliothek libhttpd.dll
erzeugt wird. Möglicherweise müssen auch die Compiler-Einstellungen
geändert werden, um sicherzustellen, dass die Apache Header-Dateien
gefunden werden. Die Bibliothek befindet sich im Modulverzeichnis des
Servers. Vorsichtshalber kann eine .dsp-Datei eines
vorhandenen Moduls benutzt werden, um sicherzustellen, dass die
Build-Umgebung korrekt konfiguriert ist. Alternativ können auch
Compiler- und Link-Optionen der .dsp-Datei verglichen
werden.
Nachdem die DLL-Version des Moduls erzeugt wurde, wird sie im
Verzeichnis modules unter der Server-Root platziert
und mit der
Die LoadFile-Direktive bindet beim Serverstart oder
Neustart die genannten Objektdateien oder Bibliotheken ein. Auf diese
Weise wird zusätzlicher Code geladen, der für bestimmte Module
erforderlich sein kann. Der Dateiname ist entweder ein
absoluter Pfad oder er wird relativ zur
ServerRoot angegeben.
Zum Beispiel:
Die LoadModule-Direktive bindet die mit
Dateiname angegebene Objektdatei oder Bibliothek ein
und fügt die Modulstruktur mit der Bezeichnung
module der Liste der aktiven Module hinzu. Module
ist der Name der externen Variablen vom Typ
module in der Datei und wird als
Modul-Bezeichner
in der Moduldokumentation aufgeführt. Beispiel:
Diese Anweisung lädt das angegebene Modul aus dem Verzeichnis
modules unter ServerRoot.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
