<div dir="auto"><div>Hi, </div><div dir="auto"><br></div><div dir="auto">>  XP. GHCJS seems to at least have a compiler based on GHC 8.6.</div><div dir="auto">> 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 dir="auto"><br></div><div dir="auto">This would be somewhat hard but not impossible for 8.0.. Which If I recalled drop XP for some linker functionality. The higher you go the more difficult it would become though.</div><div dir="auto"><br></div><div dir="auto">When you get to 9.0 you don't have much hope as there it's not just the linker, but the RTS itself heavily relies on functionality not available in XP, including how we manage memory and do synchronization. </div><div dir="auto"><br></div><div dir="auto">It's however not just GHC that would need patching but libraries such as process as well. That is not to say it's impossible, just you'd have to find ways to work around the bugs that caused us to change APIs to begin with... <br><br>I can't speak for the community, but I wouldn't want to re-introduce XP as a supported options in mainline. Parts of e.g. 9.0 (like winio) just won't work on XP. The design itself is centered around new APIs. So supporting XP means essentially a new design. </div><div dir="auto"><br></div><div dir="auto">Kind regards, </div><div dir="auto">Tamar <br><br><div data-smartmail="gmail_signature" dir="auto">Sent from my Mobile</div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Mar 24, 2021, 14:09 Clinton Mead <<a href="mailto:clintonmead@gmail.com">clintonmead@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" rel="noreferrer">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" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div></div>