Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#2505 closed bug (duplicate)

windows installer should not hijack filetype associations!

Reported by: claus Owned by:
Priority: normal Milestone:
Component: None Version: 6.8.3
Keywords: Cc: ndmitchell@…
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


the 6.8.3 installer does not respect or preserve existing filetype associations:

before installing, I had arranged for several things on my right-click menu for .hs files, such as edit with Vim (default), open with WinHugs, open with Ghci 6.6.1, open with Ghci 6.9.

during installation, the only options I have are install and start menu location.

after install, the additions I made manually are gone, including WinHugs and Ghci 6.6.1 (which installed themselves, but I had modified the entries), the edit with Vim default is replaced with open (calling ghci 6.8.3), only the separate edit with Vim (which remained they way Vim installed it) is left.

this is really part of a very old issue, #916, which degenerated into a general installer discussion and ultimately disappeared into _|_. this new ticket is only about the right-click menu, on which we had reached agreement in that older discussion: installers should (a) only add right-click entries, never lose existing ones and (b) even that should be optional during installation.

(now I remember why I preferred tarballs..)

Change History (4)

comment:1 Changed 7 years ago by NeilMitchell

  • Cc ndmitchell@… added
  • Component changed from Build System to None
  • Operating System changed from Unknown to Windows

Yep, sounds like a bug, and should be fixed.

comment:2 Changed 7 years ago by claus

Thanks. For future reference, when its installer time again, here are some excerpts of what various haskell installers have done to my registry in terms of file associations.

For starters, there seems to be no agreement about filetype, to the extent that not all windows tools know what is going on:

$ cmd /c assoc .hs

$ cmd /c ftype hs_auto_file
File type 'hs_auto_file' not found or no open command associated with it.

$ cmd /c ftype ghc_haskell
ghc_haskell="C:\ghc\ghc-6.8.3\bin\ghci.exe" "%1"

$ cmd /c ftype hugs_haskell
hugs_haskell="C:\Program Files\WinHugs\WinHugs.exe" "%1"

The ghc_haskell looks like the one I've tried to restore after ghc 6.8.3 installation (the information I get for Haskell Source File when editing filetypes via explorer Tools->Folder Options)

$ reg query HKLM\\SOFTWARE\\Classes\\ghc_haskell /s


    <NO NAME>   REG_SZ  Haskell Source File
    EditFlags   REG_DWORD       0x0
    BrowserFlags        REG_DWORD       0x8

    <NO NAME>   REG_SZ  C:\ghc\ghc-6.8.3\icons\hsicon.ico

    <NO NAME>   REG_SZ  edit


    <NO NAME>   REG_SZ  C:\vim\vim70\gvim.exe "%1"

    <NO NAME>   REG_SZ  open with ghci 6.8.3

    <NO NAME>   REG_SZ  "C:\ghc\ghc-6.8.3\bin\ghci.exe" "%1"


    <NO NAME>   REG_SZ  ghci

    <NO NAME>   REG_SZ  System

    <NO NAME>   REG_SZ  open with ghci 6.9

    <NO NAME>   REG_SZ  C:\ghc\ghc-6.9.20080514\bin\ghci.exe "%1"

    <NO NAME>   REG_SZ  open with WinHugs

    <NO NAME>   REG_SZ  "C:\Program Files\WinHugs\winhugs.exe" %1

Note that the shell default is edit which directly calls my editor, and that I like to have several GHC versions and WinHugs available there (the only reason that the "Edit With Vim" entry survived the GHC installer is that it is available for all fails, so stored elsewhere).

The hugs_haskell entry seems to be one that I partially restored after a WinHugs installer had taken over (also removing my previous preferences):

$ reg query HKLM\\SOFTWARE\\Classes\\hugs_haskell /s


    <NO NAME>   REG_SZ  Haskell Script
    EditFlags   REG_DWORD       0x0
    BrowserFlags        REG_DWORD       0x8

    <NO NAME>   REG_SZ  "C:\Program Files\WinHugs\WinHugs.exe",1

    <NO NAME>   REG_SZ  Edit

    <NO NAME>   REG_SZ

    <NO NAME>   REG_SZ  "C:\Program Files\WinHugs\WinHugs.exe" /edit "%1"

    <NO NAME>   REG_SZ

    <NO NAME>   REG_SZ  "C:\Program Files\WinHugs\WinHugs.exe" "%1"

    <NO NAME>   REG_SZ  open with ghci 6.6.1

    <NO NAME>   REG_SZ  C:\ghc\ghc-6.6.1\bin\ghci.exe "%1"

    <NO NAME>   REG_SZ  open with ghci 6.9

    <NO NAME>   REG_SZ  C:\ghc\ghc-6.9.20080514\bin\ghci.exe "%1"


    <NO NAME>   REG_SZ  ghci

    <NO NAME>   REG_SZ  System

Note that WinHugs believed at the time it should handle all editing of Haskell files..

The behaviour I'd like to see is that each installer adds its functions to the existing menu, for the existing filetype, with descriptive names like "Open with GHCi x.x", "Edit via WinHugs y.y", etc. Then I can choose which of these, if any, to call from the default open and edit functions, and changing defaults never looses any options. Unless there is no existing default action or filetype, overriding what is there should be optional (default: no override).

comment:3 Changed 7 years ago by igloo

  • difficulty set to Unknown
  • Resolution set to duplicate
  • Status changed from new to closed

I'm closing this as a duplicate of #916.

If someone has the knowledge and some time to spend, then what would be really nice is:

  • Something that generates an MSI installer
  • Something that generates an installer that can act as a slave to a HP installer, i.e. the HP installer asks the user where to install to etc and passes that info on to the GHC installer
  • Something that generates an installer that behaves as Claus, Neil et al have agreed a Windows installer should behave

comment:4 Changed 7 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple
Note: See TracTickets for help on using tickets.