Windows Installer RC

[Claus Reinke]

> What kind of integration do you mean? What is it you would be looking
> for or looking to avoid? You've mentioned previously the issue of
> "stealing" file extensions etc. That'd be a good one to test. Is there
> anything else?

I thought I had made that quite clear in all those previous reports
about GHC and WinHugs installers, as linked from the HP windows
installer ticket. In particular, Neil and I started summarizing that stuff
here: http://haskell.org/haskellwiki/Installers (in 2006.., also linked from
the HP windows installer ticket).

Here are a couple of batch files to illustrate (WARNING: I'm not
a .bat/registry expert, so read&check these before executing them,
as I am giving no warranties on anything, and line-wrapping is the
least of the possible issues, use at your own risk; I'm providing these
scripts for illustration only, because the text explanations are still not
being understood and followed, as it appears):

We'll use the suffix .no-hs, to avoid messing up our haskell settings.

Variant A (state of the art Haskell installer ping pong: no agreement on
anything, whoever runs last, wins)

    REM for kicks, try associating .no-hs with an editor before you start this

    REM here comes GHCi
    assoc .no-hs
    ftype no-ghc-haskell
    assoc .no-hs=no-ghc-haskell
    ftype no-ghc-haskell="c:\ghc\ghc-6.11.20090320\bin\ghci.exe" "%%1"

    REM here comes WinHugs
    assoc .no-hs
    ftype no-hugs-haskell
    assoc .no-hs=no-hugs-haskell
    ftype no-hugs-haskell="c:\Program Files\WinHugs\winhugs.exe" "%%1"

    REM hooray? not really
    reg query HKLM\Software\Classes\.no-hs /s
    reg query HKLM\Software\Classes\no-ghc-haskell /s
    reg query HKLM\Software\Classes\no-hugs-haskell /s

At the end of this, no-ghc-haskell is associated with GHCi, while
no-hugs-haskell is associated with WinHugs, but the .no-hs suffix
is claimed by no-hugs-haskell only: GHCi is not available, nor are
any previous settings for .no-hs. This is what I've been arguing
against for more years that I dare to remember.

Variant B (not perfect, but better; we assume that we have agreed
on a common standard filetype, no-haskell):

    REM again, try associating .no-hs with an editor before running this, but via ftype no-haskell

    assoc .no-hs
    ftype no-haskell

    REM we're still forcing the association here, so we need to agree on a standard:-(
    assoc .no-hs=no-haskell
    reg add HKLM\Software\Classes\no-haskell /v "" /t REG_SZ /d "Haskell Source File"

    REM adding GHCi
    reg add HKLM\Software\Classes\no-haskell\shell\open_with_ghci_6.11.20090320 /v "" /t REG_SZ /d
"open with GHCi 6.11.20090320"
    reg add HKLM\Software\Classes\no-haskell\shell\open_with_ghci_6.11.20090320\command /v "" /t
REG_SZ /d "c:\ghc\ghc-6.11.20090320\bin\ghci.exe \"%%1\""

    REM adding WinHugs
    reg add HKLM\Software\Classes\no-haskell\shell\open_with_WinHugs /v "" /t REG_SZ /d "open with
WinHugs"
    reg add HKLM\Software\Classes\no-haskell\shell\open_with_WinHugs\command /v "" /t REG_SZ /d
"\"c:\Program Files\WinHugs\winhugs.exe\" \"%%1\""

    REM both GHCi and WinHugs are available, as are previous actions on this filetype
    REM the first such action is the default, which users can change easily, without losing actions
    reg query HKLM\Software\Classes\.no-hs /s
    reg query HKLM\Software\Classes\no-haskell /s

After this, .no-hs is associated with no-haskell, both WinHugs and GHCi are
available(*), and any previous actions associated with no-haskell have been
preserved (indeed, if you run this twice, you should be prompted for each
overwrite). If there were no previous actions, GHCi is the default, if there
were previous actions, the previous default is preserved.

Does this make my complaints and suggestions clearer?
Claus

(*) There does seem to be something wrong with the escaping of spaces
    in file parameters for GHCi here - the registry entry looks the same as
    for .hs, but unlike the real .hs binding for GHCi, this one complains
    about an unrecognised input. But that is independent of the point at hand.