Apparent character loss in Windows implementation

["Jack Emmerichs" <beamrider1@hotmail.com>]

We have just succeeded in creating a Windows (Windows XP Professional SP2)  
implementation of the current stable version (2.3.32) by building all the 
source code (back end, openSSL, OpenLDAP, etc.) within the MinGw Windows 
build environment in order to enable the ppolicy options.  We are using the 
standard BDB back-end.  Oddly enough, it seems to have worked, and I can 
execute the slapd.exe file, which seems to run normally.

I know Windows is a non-standard environment, but as I understand it, the 
underlyling OpenLDAP code is suppose to work correctly.  Whether we have 
achieved that or not remains to be seen.

The test database we are using has a standard test Manager account in a 
database structure defined as dn="cn=Manager,dc=my-domain,dc=com".  In 
trying to attach a browser to the LDAP, I seem to be getting a connection to 
the database, but something seems to be stripping the initinal character 
from the db structure definition leaving the decoded "dc" component as: 
"c=my-domain,dc=com".

Here is the trace of the attempted connection to the LDAP:

slapd starting
> > > slap_listener(ldap:///)
connection_get(420): got connid=0
connection_read(420): checking for input on id=0
ber_get_next
ber_get_next: tag 0x30 len 49 contents:
ber_get_next
do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:
> > > dnPrettyNormal: <cn=Manager, dc=my-domain,dc=com>
<<< dnPrettyNormal: <cn=Manager,dc=my-domain,dc=com>, 
<cn=manager,dc=my-domain,d
c=com>
do_bind: version=3 dn="cn=Manager,dc=my-domain,dc=com" method=128
do_bind: v3 bind: "cn=Manager,dc=my-domain,dc=com" to 
"cn=Manager,dc=my-domain,d
c=com"
send_ldap_result: conn=0 op=0 p=3
send_ldap_response: msgid=1 tag=97 err=0
ber_flush: 14 bytes to sd 420
connection_get(420): got connid=0
connection_read(420): checking for input on id=0
ber_get_next
ber_get_next: tag 0x30 len 69 contents:
ber_get_next
do_search
ber_scanf fmt ({miiiib) ber:
> > > dnPrettyNormal: <dc=my-domain,dc=com>
<<< dnPrettyNormal: <dc=my-domain,dc=com>, <dc=my-domain,dc=com>
ber_scanf fmt (m) ber:
ber_scanf fmt ({M}}) ber:
=> bdb_search
bdb_dn2entry("dc=my-domain,dc=com")
=> bdb_dn2id("dc=my-domain,dc=com")
<= bdb_dn2id: got id=0x01000000
entry_decode: "c=my-domain,dc=com"
<= entry_decode: str2ad(orsName): AttributeDescription contains 
inappropriate ch
aracters
<= entry_decode: slap_str2undef_ad(orsName): AttributeDescription contains 
inapp
ropriate characters
send_ldap_result: conn=0 op=1 p=3
send_ldap_response: msgid=2 tag=101 err=80
ber_flush: 28 bytes to sd 420

The problem is about seven lines up from the end of the trace.  It has the 
flavor of trying to insert a newline into the full dn=... text and having 
Unix insert a single expected character while Windows inserts two 
characters, thereby overlaying the first character of the following text.

Does anybody know of any gotchas in a Windows environment related to this 
problem, or any other information about it?  The build options we used were:

OPENLDAPCONF="--disable-static --enable-shared --enable-dynamic 
--enable-lmpasswd --enable-bdb --disable-ldap --disable-ldbm --disable-meta 
--disable-monitor --disable-null --disable-sql --enable-ppolicy"

Any suggestions, including a known impossibility of getting this to work, 
would be appreciated.

Thanks.

JFE.

_________________________________________________________________
Get a preview of Live Earth, the hottest event this summer - only on MSN 
http://liveearth.msn.com?source=msntaglineliveearthhm