Windows DLLs should be working.
asuffield at suffields.me.uk
Mon Jan 11 00:31:58 EST 2010
On Mon, Jan 11, 2010 at 05:31:46AM +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.
> 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.
What we're (hypothetically) dealing with here is a COM component
calling code from these non-COM DLLs. I'm not sure you can expect that
to work right without wrapping everything in assemblies to express the
dependency. Documentation on this appears to be sparse.
> SxS is not inherently tied to any technology like COM or .NET. You can
> trivially deploy anything into SxS.
Handy to know; I wasn't sure about that one, never having tried it.
> 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.
Well, it's not a regression if you don't get dynamically-linked binary
support in that mode, since that's never worked before. There's no
reason why static linking wouldn't continue to work. I'm not sure if
there is any sensible way to dynamically link binaries in this
scenario (I can't think of one). It may be a "Windows doesn't do this"
The intersection of the sets "people who don't have administrator
privileges on this machine" and "people who want to compile
dynamically-linked binaries of things written in Haskell on this
machine" may be empty.
More information about the Cvs-ghc