Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle <tony.hoyle at march-hare.com> writes: > Anthony Williams wrote: > >> You could still modify the DLL names, or load them at runtime from the CVSNT >> install dir. The problem only manifests with the control panel applet, since >> it is a DLL loaded into another process; the main EXE always finds the correct >> versions of the DLLs it needs, since the directory containing the EXE is >> searched before the path. >> > The openssl lib is renamed, but that's because it passes FILE* objects > around, which means it needs to be compiled using the same compiler that the > calling application is using otherwise it falls over. OTOH I'm leaning > towards using the internal Win32 SSL (Schannel) in the future so that > sserver works more seamlessly (SSPI can already use schannel if it's > configured). > > Iconv and Expat shouldn't have that issue, since they just pass pointers to > text around mostly (except for cygwin versions - WinCVS was hit by that > problem re. tcl.dll... they're not binary compatible with the win32 versions > even though they have the same name). > > If you have a non-cygwin iconv that's causing problems it'd be interesting > to see what the problem actually is with it, since there's nothing special > about the cvsnt one other than being recompiled in visual studio for > efficiency (the same goes for expat really.. it's only in the source tree as > it's a required component for the Unix installs). The problem with expat.dll is the names of the exports. In one version they're mangled like @some_function at 4, in the other, they're not (just exported as some_function). I forget which version does which. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk