[cvsnt] Re: DLLs again

Gerhard Fiedler lists at connectionbrazil.com
Sat Jun 10 15:08:58 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.

Tony Hoyle wrote:

> Flávio Etrusco wrote:
>> I didn't follow the discussion _much_ closely, so forgive if I'm BSing,
>> but IMHO the question is: why does the cvsnt running as _client_ need
>> to to follow the registry setting instead of just using the local DLLs?
> CVSNT isn't the only user of cvsapi - there are currently at least 5 of
> them and they can't all be put in the same directories. 
> There is no requirement for the DLLs loaded by it to be local to
> anything.

The problem with this approach that I recently encountered is as follows.

TortoiseCVS needs a defined version of the client, since it sends commands
to it and parses the output. Both change between versions (sometimes more,
sometimes less), so I guess it's reasonable that TortoiseCVS expects a
certain version of cvs.exe to interact with. To make sure that it uses the
correct version, it installs that version. That used to work fine, at least
here and up to now.

But I have also a command line cvsnt installation in a different directory
on my system. I didn't specifically install that as a server and it doesn't
run as a server -- I just ran the installer, unselected the protocols I'm
not interested in, and that's it. This installation still works fine (build

So when I installed the latest version of TCVS, it installed cvsnt build
2230 in its directory. And boom... cvs.exe 2230 did not work with the DLLs
provided by 2151. I only could make it work by using the cvs.exe.local
file. (The simcvs.exe approach suffers from the drawback that TCVS would
then run with an arbitrary version of cvs.exe -- which probably would only
be acceptable if the interface details of cvs.exe didn't change between
versions. Which of course they do, in unpredictable ways, as there is no
formal interface spec.)

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
how about naming protocol.dll build 2230 protocol-build2230.dll and
protocol.dll build 2151 protocol-build2151.dll? After all, naming both
protocol.dll gives the (wrong) impression that they are interchangeable and
present the same API. Which apparently they don't -- or else cvs.exe build
2230 wouldn't have a problem with protocol.dll build 2151.

This would make pretty much everybody happy; nothing gets broken, every
client gets the DLLs it needs, and DLLs with the same name are actually


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