[Date Prev][Date Next]
RE: NT Port of SLAPD
Where were you last month when we were asking for volunteers to do the NT
port? I have already committed an NT port of slapd and the ldif tools.
_Please_ don't overwrite what I've already done without careful
consideration. My implementation doesn't do dynamic loading of backend
modules, but I use native threads which I consider preferable to a
port of another thread package. There will need to be some thoughtful
merging of the two projects.
From: Eric Ma [mailto:email@example.com]
Sent: Monday, April 19, 1999 11:57 AM
Subject: NT Port of SLAPD
I work in Network Computer Inc and our development group will use slapd
to build part of our product. Specifically, we will be using slapd with
our own database backend on both the Solaris and NT platforms. I
understand there are specific license requirements for the use of
openldap source code and binaries. And we are implementing changes over
standard OpenLDAP releases so that we will comply with the license
requirements and our product-specific database backend will be separate
from the main SLAPD application so we don't need to release the source
code of our database backend when we ship our product. Our changes to
the main SLAPD application will, of course, will merged back into the
main OpenLDAP development, wherever appropriate.
At this point, we have identified two main areas for enhancement and
have had initial successes in their implementation. I understand
independant efforts have been made in these areas by different people
under OpenLDAP, so our work may have overlapped. My goal at this point
is to synchronize our changes with the main development in OpenLDAP.
I have done an initial NT port of SLAPD using Visial C++ 5.0. I have
also added dynamic loading of modules for database backends via shared
libraries on Solaris and via DLLs on NT. The purpose of the latter is
to separate our database backend from the main SLAPD applications so our
database backend is not governed by the OpenLDAP license and we don't
need to release its source code, etc. I have tried to minimize the
changes to OpenLDAP source and the diffs are listed below:
Changes for NT Port of SLAPD using Visual C++ 5.0:
errno.h: defines also EWOULDBLOCK
signal.h: defines SIGNAL as (void)
gives numeric values to SIGHUP, PIPE, USR1 and USR2
socket.h: rearranges some macros to define macro tcp_close as
string.h: ifdef's out definitions of strdup, strcasecmp and
strncasecmp for win32
because of prior declaration
syslog.h: defines openlog and syslog as (void)
ldap_cdefs.h: typedef void *caddr_t;
portable.h: a lot of changes to capabilities settings specific to win32
detach.c: disables detaching from terminal; so slapd always runs in
thr_posix.c: ldap_pvt_thread_kill becomes no op; pthread packages
does not define
daemon.c: remaps NT sockets to array of file descriptors, since NT does
allocate sockets between 0 and FD_SETSIZE, but any number
larger than FD_SETSIZE
lock.c: disables file locking for now
main.c: In main, also initializes socket DLL on win32
socket.c: function to initialize winsock2 (initwinsock)
Changes in SLAPD for dynamic module support:
dlfcn.h: Unix-style interface for shared library (dlopen, etc)
attr.c: exports attr_merge (via LDAP_F) to dynamic module
backend.c: in new_backend, add new backend type "ldmod" for dynamic
ch_malloc.c: exports ch_calloc and ch_strdup to dynamic module
dn.c: exports dn_normalize_case to dynamic module
entry.c: exports entry_free to dynamic module
ldmod.c: implements new backend "ldmod" for dynamic module
proto-slap.h: modifies prototypes of various functions by adding
LDAP_F for export
to dynamic module
result.c: exports functions to dynamic module
dlfcn.c: wraps win32 dynamic library loading with dlfcn interface
A few notes also:
1) In the slapd.conf file, the following lines load a certain dynamic
module /full_path_to_dll/mydll.dll (or .so on solaris)
2) Certain functions still need to be tagged LDAP_F for full dynamic
3) For now, I implemented a null module that does bind and some simple
searches; it is
dynamically loaded as a shared library on Solaris and DLL on win nt.
4) detach.c should implements a windows service but is a no-op for now.
5) None of the existing database backends have been ported yet (ldbm,
6) The pthread library being ported by CYGNUS and the hs_regex library
are being used.
7) More testing is needed.
8) openlog and syslog need to be implemented in terms of events to the
events viewer on
9) Depending on how signals are used, implement signals on win32.
That's about it.
Your comments are appreciated.