On Mon, 2010-01-11 at 05:31 +0100, Lars Viklund wrote: > > If you want to get this working with COM, then building an assembly > > out of the DLLs is probably mandatory. So that's looking like the way > > to go.
Yes, we'll want to be able to make and use assemblies. Not just for COM, it's the general modern windows linker system. > If memory serves me right, you can register a COM DLL anywhere on the > system, it's just that modern DLLs tend to be placed SxS. Right, because with COM the GUID is registered in the Win32 registry and that points to a specific file location. With COM the dll is loaded explicitly at runtime using that file location from the registry. So it completely bypasses the normal linker lookup rules (indeed that's probably why they did it that way since the traditional Win32 linker lookup rules are so limited). > SxS is not inherently tied to any technology like COM or .NET. You can > trivially deploy anything into SxS. Yes, any assembly which is just one or more dlls with an xml manifest. > Also, do not forget people who do not have administrative priviledges. > If it turns out it's impossible to install a private GHC into a > directory you have rights to, I would consider that a major regression. Yes. Sadly the the SxS location is global and there is no per-user equivalent. So we cannot in general rely on it. I think the eventual model we'll have to use on windows will be like this: By default ghc --make Hello.hs -o Hello.exe will continue to use static linking. When using Cabal or some other build manager and you ask to make a deployable (relocatable) image using shared libs then it would copy over stored versions of assemblies for the dependent packages into a subdir and use a manifest so that the built programs can find the assemblies. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
