<div dir="ltr"><div>Thanks all for your replies. Just going through what Ben has said step by step: <br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My sense is that if you don't need the threaded runtime system it would<br>
probably be easiest to just try to make a modern GHC run on Windows XP.<br></blockquote><div><br></div><div>Happy to run non-threaded runtime. A good chunk of these machines will be single or dual core anyway.</div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As Tamar suggested, it likely not easy, but also not impossible. WinIO<br>
is indeed problematic, but thankfully the old MIO IO manager is still<br>
around (and will be in 9.2).<br></blockquote><div><br></div><div>"Is still around"? As in it's in the code base and just dead code, or can I trigger GHC to use the old IO manager with a GHC option?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The possible reasons for Windows XP incompatibility that I can think of<br>
off the top of my head are:<br>
<br>
 * Timers (we now use QueryPerformanceCounter)<br></blockquote><div><br></div><div>This page suggests that <a href="https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter">QueryPerformanceCounter</a> should run on XP. Is this incorrect?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 * Big-PE support, which is very much necessary for profiled builds<br></blockquote><div><br></div><div>I don't really need profiled builds</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 * Long file path support (mostly a build-time consideration as Haskell<br>
   build systems tend to produce very long paths)<br>
<br></blockquote><div><br></div><div>I don't need to build on Windows XP either. I just need to run on Windows XP so hopefully this won't be an issue. Although if GHC was modified for long file path support so it could build itself with long file path support presumably it will affect everything else it builds also.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There may be others, but I would start looking there. I am happy to<br>
answer any questions that might arise.<br>
<br></blockquote><div><br></div><div>I'm guessing the way forward here might be a patch with two options:</div><div><br></div><div>1. -no-long-path-support/-long-path-support (default -long-path-support)</div><div>2. -winxp</div><div></div><div><br></div><div>The winxp option shall:</div><div><br></div><div>- Require -no-long-path-support</div><div>- Conflicts with -threaded<br></div><div>- Conflicts with profiled builds</div><div>- Uses the old IO manager (I'm not sure if this is an option or how this is done).</div><div><br></div><div>What do you think (roughly speaking)?</div><div> </div></div></div>