Duncan Coutts wrote:
On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:
Suppose for a moment that GHC did dynamically link gmp.dll, or indeed
HSbase.dll. Where exactly would these files go?
I'd install them in the same directory as ghc.exe because this directory has
to be on the %PATH% for the command ghc to work so Windows would find these
DLLs the same way.
As you say, it doesn't work for more than one version of GHC.
And it doesn't work when names clash. If there is some lingering old
version of gmp.dll in the windows system directory or in any other
directory on the %PATH% (earlier than ghc's bin dir) then that dll gets
picked up instead and everything breaks.
For developing apps, it would surely be fine if the DLLs were just stored in
the ghc directory ie c:\ghc\ghc-6.4.2\bin then when you come to distribute
your app, you'd simply just copy all the dlls the app needs as well as the
exe into the installation directory of the app. When the app runs, Windows
will first look in the app's directory and therefore find the correct set of
DLLs.
Yes, it's fine for distributing applications but not much good for
libraries.
It's true that multiple versions of ghc could not coexist, but this already
is the case at the moment: if you type "ghc" at a Windows command prompt
Windows searches the one and only PATH variable to locate it so you can't
have more than one version in any case, unless you create multiple user
accounts and modify the user's PATH variables to point to the various
versions of ghc.
I use several versions of GHC at once on windows and switch between them
in a console window just by doing: set PATH=...
Windows is very well set up for distributing isolated applications
but I can't see how to do it for libraries. COM works by a runtime
loading mechanism and a single entry point per dll and registering
the location in the win32 registry.
Shared components are a bad idea imho because it's almost certain that
someone elses's app would use a different version of a DLL - this is where
real DLL Hell comes in! (and probably why .NET abandoned DLLs and (raw) COM
in favour of assemblies)
They are pretty inevitable if you want to distribute Haskell libraries
rather than applications.
I'm not sure we can just say "don't do that".
As long as the DLLs are stored in the same directory as the exe everything
should be ok - it's only when people try to share DLLs by putting them
somewhere else that versioning problems can arise.
Indeed.
This issue is the main source of problems that users have with the
Gtk2Hs packages that I build for Windows. I do not yet have any
satisfactory solution.
Gtk+ comes as a collection of .dll files. Remember that I am
distributing a Haskell library here, not an application. Users want to
use my library to compile their own applications, eg for tasks on a
university course.
So where do I put the Gtk+ .dlls? At the moment I seem to have no choice
but to put them on the %PATH%. And thus the breakage ensues. Old
versions of Gtk+ that people have on their systems can interfere. Lots
of naughty apps seem to install libz.dll into the windows system
directory. The list seems endless. Each of these dll problems results in
the Haskell GUI apps that users compile failing to start due to missing
or mismatched dll imports.
The "solution" to this problem is to use COM - COM assigns a unique identifier
to an API, and you're only supposed to replace a DLL if you implement all the
interfaces that the old DLL implemented, plus possibly some new ones.
The reason libz & co. cause problems is because they are changing APIs without
any kind of version tracking at all.
.NET has a different solution to these issues. Assemblies can be installed
globally, but when binding to an assembly the .NET runtime checks various
constraints on which versions are compatible with each other before linking.
So, in the absence of any runtime version checking like COM or .NET, it seems
the only safe thing to do is put a GUID in the name of the DLL itself, or at the
very least include a version number in the filename.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
