Thoughts for a native (well, mingw) Window version of GAP

[fingolfin]

Since I am working on compiling GAP via Julia's binarybuilder, it was natural to also try and see what happens if I run the build for Windows, which in their case is based on mingw, not cygwin (so no POSIX code, just standard C library). I did this with the stable-4.11 branch but the same should apply for master.

Perhaps one day somebody else is interested in doing such a port, and then the findings below might help them. Also, if anybody is interested in pursuing such a project, I'll be happy to help out by answering questions about the GAP kernel and how it is used

Note that I only discuss what's needed to make the GAP kernel compile; but of course that's just the first step, afterwards one likely will have to make more changes to GAP code (e.g. to deal with difference in how paths work), and also to packages. But I think all of that is manageable once the kernel is up and running.

The files needing work, in ascending order of estimated effort required:

1. stream.c
   Here I run into a minor error because GAP's io.h was shadowing the system's io.h which got included by dirent.h. This can be resolved either via suitable include flags or renaming GAP's io.h.

2. system.c
   Here struct rusage and getrusage are not supported. The code using those could be stubbed out at first. I think GetProcessTimes can be used to replace it easily, though (see e.g. https://stackoverflow.com/q/5272470/928031)

3. iostream.c
   The first obstacle here was that termios.h is missing, so I wrapped that into an #ifdef HAVE_TERMIOS_H check. That then unsurprisingly revealed many missing functions. But let's look at the bigger picture: The code in this file handles launching subprocesses and communicating with them. This requires fork or posix_spawn, neither available on Windows. But the later is in fact quite similar to Windows' CreateProcess. There are examples for how to use this to communicate with a subprocess which one might be able to adapt.

   In a first iteration, one could probably just stub out the majority of this file: GAP can be started fine without support for subprocesses, it's some more advanced features and certain packages that won't work, but for first experiments, I think this stubbing is a great approach, to be able to more quickly find out how much work the GAP library really needs (and then perhaps other people can help with that, even if they might not have kernel programming skills).

4. sysfiles.c
   This file contains a portability layer for GAP, so unsurprisingly the majority of compatibility issues are in here. These include:

   • another use of fork, but simpler: here we launch a subprocess and wait for it to terminate; no real communication takes place (as before, this could also be stubbed out at first)
   • terminal control code using termios.h: it might actually be possible to completely get rid of this, or at least replace it with something simpler, depending on how one handles interactive input
   • POSIX IO functions like read, write, lseek etc. (why doesn't GAP use fread, fwrite? Well, these all malloc and we try to avoid that; of course a first iteration could still try to use them, but I think it'd make more sense to directly use native Windows API
   • realpath, getcwd, readlink, ... - used in SetupGAPLocation and find_yourself, so there is no point in finding directly alternatives for these calls, instead one should determine how to implement similar "find yourself" functionality on Windows; but this could be stubbed out at first (or even always)
   • mkdir, rmdir, lstat, mkdtemp, access: ought to be straight forward to deal with those...