<div dir="auto">In terms of net amount of work: I suspect ghcjs targeting either node or some sort of browser plug-in may be the most humane assuming associated browser / node suport on xp is turn key.  I think there were some genuine changes to the io manager (the Haskell code in base for doing efficient file system api stuff)  on windows plus a few other things.  There may have also been changes elsewhere that andreask and Tamar and ben gamari can speak to better. </div><div dir="auto"><br></div><div dir="auto">More broadly, there’s so many bug fixes and improvements that you’d miss out on if you don’t try to keep yourself current within the 3 most recent ghc major version releases wrt associated libraries. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 24, 2021 at 10:09 AM Clinton Mead <<a href="mailto:clintonmead@gmail.com">clintonmead@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div>I'm currently trying to bring my company around to using a bit of Haskell. One issue is that a number of our clients are based in South East Asia and need software that runs on Windows XP. <br></div><div><br></div><div>Unfortunately it seems the last version of GHC that produces executables that run on Windows XP is GHC 7.10. Whilst <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms/windows" target="_blank">this table</a> suggests the issue may only running GHC 8.0+ on Windows XP, I've confirmed that GHC 8.0 executables (even "Hello World") will not run on Windows XP, presumably because a non-XP WinAPI call in the runtime. </div><div><br></div><div>My first thought would be to restrict myself to GHC 7.10 features (i.e. 2015). This would be a slight annoyance but GHC 7.10 still presents a reasonable language. But my concern would be that increasingly I'll run into issues with libraries that use extensions post GHC 7.10, particularly libraries with large dependency lists.</div><div><br></div><div>So there's a few options I've considered at this point:</div><div><br></div><div>1. Use GHCJS to compile to Javascript, and then dig out a version of NodeJS that runs on Windows XP. GHCJS seems to at least have a compiler based on GHC 8.6.</div><div>2. Patch GHC with an additional command line argument to produce XP/Vista compatible executables, perhaps by looking at the changes between 7.10 -> 8.0, and re-introducing the XP approach as an option. </div><div><br></div><div>The issue with 1 is that is that as well as being limited by how up to date GHCJS is, this will increase install size, memory usage and decrease performance on Windows XP machines, which are often in our environments quite old and resource and memory constrained.</div><div><br></div><div>Approach 2 is something I'd be willing to put some work into if it was practical, but my thought is that XP support was removed for a reason, presumably by using newer WinAPI functions simplified things significantly. By re-adding in XP support I'd be complicating GHC once again, and GHC will effectively have to maintain two approaches. In addition, in the long term, whenever a new WinAPI call is added one would now have to check whether it's available in Windows XP, and if it's not produce a Windows XP equivalent. That might seem like just an extra burden of support for already busy GHC developers. But on the other hand, if the GHC devs would be happy to merge a patch and keep up XP support this would be the cleanest option.</div><div><br></div><div>But then I had a thought. If GHC Core isn't supposed to change much between versions is it? Which made me come up with these approaches:</div><div><br></div><div>3. Hack up a script to compile programs using GHC 9 to Core, then feed that Core output into GHC 7.10. OR</div><div>4. Produce a chimera style GHC by importing the GHC 9.0 API and the GHC 7.10 API, and making a version of GHC that does Haskell -> Core in GHC 9.0 and the rest of the code generation in GHC 7.10. </div><div><br>One issue with 4 will be that presumably that because I'm importing GHC 9.0 API and the 7.10 API separately, all their data types will technically be separate, so I'll need to basically deep copy the GHC 9.0 core datatype (and perhaps others) to GHC 7.10 datatypes. But presuming their largely similar this should be fairly mechanical.</div><div><br></div><div>So are any of these approaches (well, particularly 2 and 4) reasonable? Or am I going to run into big problems with either of them? Is there another approach I haven't thought of?</div><div><br></div><div>Thanks,</div><div>Clinton</div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>