On Sun, Jan 10, 2010 at 05:24:17PM +1100, Ben Lippmeier wrote: > I haven't pushed a patch to do this yet because the DLLs for the > runtime and libraries currently require manual installation. After > building GHC I've been doing a find . -name "*.dll" and copying > all the results to c:\Windows\System32. I'm not sure if there is a > nicer way to do this yet, does anyone know offhand?
Not really, and it probably shouldn't be done. Windows does not have the same approach to libraries that unix platforms do. On a unix system we talk about 'shared libraries', which accurately describes the central point of the concept: a common library which is shared by multiple applications. In order to make this work, we have the concept of versioned sonames, which identify unique ABIs. This lets us store a single copy of each one in a well-known location, for all applications to share. Windows doesn't approach things from this angle. DLLs are not used with the primary intent of sharing code between applications. Rather, they are intended as a system for one piece of software to use proprietary code written by another developer, without sharing any source. While it is technically possible to use them like shared libraries, there's no expectation of this. The lack of stable ABIs and tight coupling between libraries and applications means that it doesn't really work when people try. Initially Microsoft tried to push this approach anyway, but it just led to a lot of versioning problems. This class of issues used to be called "DLL hell" by commentators. This approach was abandoned around the win2k era, and now windows applications are expected to place copies of all the DLLs that they use in the same directory as the application. This is gratuitously wasteful of disk space and memory, but since a Windows system is not intended to do more than one thing at a time, it is not seen as a problem. Every application bundles a duplicate copy of all its dependencies. Security updates have to be redone for every application that ships the library, dramatically increasing the amount of work for sysadmins. The only exception to this is device drivers and COM controls (and dotnet which is loosely based on the COM system), which have their own Byzantine system for dealing with the ABI problem. Bottom line is, while it is possible to install the libraries into the \windows\system32 tree, this would be abnormal and unexpected. There's two ways you can go from here. The first approach is the one described above: a 'development environment' package (probably the Haskell platform) installs everything into some private directory under \Program Files\, and provides a specialised system (cabal) to find the libraries and link applications against them. As the final stage of the application building process, those DLLs are then copied into the application's installer, to be deposited in the same directory as the executables when installed. It's questionable as to whether this is really beneficial compared to static linking. The other approach is only available on XP and later: you create something called a 'side-by-side assembly', which is basically a library package for COM. I don't think you can do it with free tools - it's normally done with Visual Studio. I'm also not sure how well it works with thing like GHC which don't target COM or dotnet. They're installed into \windows\winsxs\ and applications have to write an XML manifest in order to access them. This is Microsoft's current vision for the future (they're pushing it hard with dotnet, and use it for their major redistributable library bundles), but it's likely to be harder to make this work, and unclear whether there are any benefits. It may be that the best way to do things on Windows (at least for now) is just to link Haskell code statically, and only use DLL support for FFI - ie, how things currently work. _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
