64bit Core fails to start ghci on Windows 10 Creator

[ndmitchell]

It just fails with:

---------------------------
ghc.exe - Application Error
---------------------------
The application was unable to start correctly (0xc0000142). Click OK to close the application. 
---------------------------
OK   
---------------------------

Do you need to upgrade the binaries?

[randen]

I don't have Windows 10 to check this, but is this the problem that should have been fixed with the Haskell Platform for Windows 8.0.2-a (the downloads now available at https://www.haskell.org/platform/#windows)?

[ndmitchell]

Yep, that's exactly the problem I'm referring to. However, I'm using 8.0.2-a and even when I double click the ghci located at C:\Program Files\Haskell Platform\8.0.2-a\bin it still fails with the error above.

[gbaz]

Ok, I think I've figured this out. The thing that is failing is not the "ghci" that is an alias to ghc in interactive mode [i.e. ghci from cmd still works] but the winghci wrapper (https://github.com/haskell/winghci) that we also redistribute. It may be an entirely other issue that fails with the same error code, as that error code seems to indicate a variety of different issues from a pure google of it.

I guess this should then be filed as an issue against that repo?

[ndmitchell]

This is nothing to do with WinGHCi - it's the ghci.exe that doesn't work. If I start ghci from cmd then it works, but if I start ghci.exe (or ghci-8.0.2.exe) by double clicking in Windows Explorer than I get the error above.

I did just test WinGHCi and that works just fine.

[gbaz]

agreed, its not winghci. i was just very confused.

[gbaz]

So I checked a prior platform on a prior system and saw how double clicking ghci launches ghc in interactive mode in a console -- had never interacted this way before (hence the confusion). I then downloaded the current ghc tarballs with the creators patch from ghchq and on double-clicking the ghci therein I got the same error. So I think this may be a codepath that was broken by the creators update that was less noticed and never patched? (Or perhaps the existing patch, which seems to have just changed the gcc executable, didn't recompile enough things with the fixed setup? I don't know the details). CC: @Mistuke who may be able to provide some insight...

[Mistuke]

Yes, it seems we missed one, the ghci wrapper also uses cwrapper.c which was the file that was affected by the Windows 10 creator's update. We don't have any interactive tests using a desktop session so we missed this.

The https://github.com/ghc/ghc/blob/master/driver/ghci/ghci.c needs a recompile for this to work. It'll be ok for 8.2 but I'm wondering what to do about 8.0.

[ndmitchell]

Confirmed - it's broken with stock 8.0.2, so not a platform issue.

[gbaz]

My personal suspicion is that this is probably a seldom-traversed codepath as it took until now for it to be noticed, but that may be waaay offbase. I'm not sure how much work ghchq has put into backwards compat for work like this in the past, or how much it may anticipate in the future. Either way I'll close this out from here and let it be trafficed on other tracs going forward, and leave it to the ghc team to figure out a plan from their end...

[Mistuke]

I don't think it's likely we'll re-spin the binaries again for this. There is a simple workaround, make a batch file containing ghci.exe --interactive and put it in the bin folder.

The code is fixed in HEAD and should already be ok for the current RC2 for 8.2. And yeah, this code path is not something our CI's would catch as all the tests are automated and you'd need a desktop session to see this particular bug.

But please make a ticket if you think we should backport the fix.

[ndmitchell]

Note that running ghci from the cmd prompt worked fine - I think double clicking is a corner case at best.