Walter Nicholls wrote:
>
>> There's a dilemma here, known as "Windows DLL hell". Since we have no
>> control over installations, we can't prevent somebody from
>> _downgrading_ the installed DLLs. If the DLL names in svn-1.x are the
>> same as in svn-1.x+1, the newer stuff will break.
>
> No control over installations? I'm sure some overwhelming percentage
> of Windows users use the official Subversion MSI packages.
That's funny, given that there _are_ no official Subversion MSI packages. :)
> You can't prevent someone overwriting the dlls, but I don't think you
> need to worry about that scenario. If the official Sibversion
> installer installs C:\Program files\Subversion\bin\libsvn-1.dll then
> the end users heads be on it if they attempt to overwrite that with an
> earlier OR later version without using the corresponding installer.
A newer version should never be a problem. An older one could be.
> If you were to install the DLLs in c:\windows\system32 then DLL hell
> would be a problem. So don't do that!
Of course not. Perish the thought!
> I don't even think you need to include the major version number in the
> file name. Just looking in my C:\program files\Subversion\bin\
> directory, there is:
> intl.dll, intl3_svn.dll, libapr.dll, libapriconv.dll,
> libaprutil.dll ... svn.exe, svnadmin.exe, svndumpfilter.exe ...
See? You've already got mixed versions, "intl.dll" shouldn't be there. :)
And yes, we do need to include the major version in the name, at least.
That's project policy. In fact, it's APR's project policy too, and I
think it's a bug that APR's build doesn't put those names in the APR
DLLS....
> In fact the only files in here with any kind of version numbers in the
> filename are the BDB ones (libdb42.dll, libdb43.dll)
Indeed. And a good thing, too; because of that, it's impossible to load
the wrong BDB libary at runtime.
> I don't have any DLL hell problems with libapr.dll. And why isn't that
> "svn1.exe" or "svn-1.2.1.exe" then? I have a couple of scripts that
> parse svn.exe output, they could equally break if I downgraded say to
> svn 1.1
Executables are a different beast. The thing about DLLs is that, if
program A loads DLL D, and you then run program B that depends on a
(possibly quite different) DLL that also happens to be called D, B will
blindly try to link to the already-loaded D. Bang!
(O.K., this is not strictly true on newer versions of Windows, but it's
true for 99% of the installed base.)
> I can run two versions of Subversion by installing one in c:\program
> files\svn1.1 and another in c:\program files\svn1.2\ or the like
Exactly. And you can't do this safely with DLLs.
> The issue of MSVC6 vs VS.NET (vs Borland C++ builder vs...) is
> possibly a good one - although I would have expected that could be
> solved by defining the calling conventions properly. That may be more
> work thatn any wants to do though.
It's not about calling conventions, the problem is the runtime those
DLLs link to -- specifically, the format of the malloc heap. They're
incompatible.
> Perhaps the biggest problem is that with open-source products like
> this, people can create their own custom builds and break something
> that way.
So? We _want_ to support that, and I don't see it as being a problem --
therefore we'll put version numbers and runtome IDs in the DLL names,
thus avoiding possible clashes.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 18 05:35:35 2005