NT Port of SLAPD

[Eric Ma <ema@nc.com>]

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
closesocket win32
	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
the foreground
	thr_posix.c:   ldap_pvt_thread_kill becomes no op; pthread packages
does not define
		       pthread_kill
	daemon.c: remaps NT sockets to array of file descriptors, since NT does
not 
          	  allocate sockets between 0 and FD_SETSIZE, but any number
potentially
          	  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
module
	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.
	database ldmod
	module /full_path_to_dll/mydll.dll  (or .so on solaris)
2)  Certain functions still need to be tagged LDAP_F for full dynamic
support.
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,
shell, etc).
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 
    win32.
9)  Depending on how signals are used, implement signals on win32.

That's about it.

Your comments are appreciated.

Thanks.

Eric Ma
ema@nc.com