Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X andOpenSSL

[Simon Marlow]

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