[cvsnt] Re: DLLs again

Tony Hoyle tony.hoyle at march-hare.com
Sun Jun 11 00:07:49 BST 2006

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.

Gerhard Fiedler wrote:
> IMO one either makes sure that the DLL interface stays the same -- or lets
> programs use the DLL of the version that they need. You said that the
> problem is that sometimes Windows decides that a DLL with a different path
> but same name that is already in memory can be used instead of the one with
> the exact path requested. Well... so change the name if you change the DLL
> interface, and everything is well. If the interface of protocol.dll build
> 2230 is not compatible with the interface of protocol.dll build 2151, then

That's a lot harder than it sounds - there's no support for anything 
like that in visual studio so you'd have to rebuild the project files 
for each release (which is a bit of a chicken and egg situation even if 
you scripted it).  You can't just rename a DLL - it stores its 'real' 
name internally and uses that.

We already do that on the Unix builds but of course the build system is 
designed to work that way.  On Windows we'd have to write it from scratch.

Once we get to VS2005 the Manifests contain the checksums of the 
libraries that the programs use - which is *supposed* to fix DLL Hell 
once and for all (it remains to be seen if it does this time...).  Until 
that time we have to use suboptimal solutions.


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook