Arthur has mentioned that the use of sockets in libreduce
does not work properly under Windows. He has suggested an
alternative using pipes. I am planning to provide this via a
configure option soon.
Now the discussion about Windows reminded me that there are
several points always unclear to me, and I think it is worth
discussing this here semi-publicly:
The main question is: What is the role of Cygwin for Reduce?
In particular, when I go to the supermarket and buy a PC
with a preinstalled Windows edition, am I
1. able to use the prebuilt Windows package on Sourceforge
without further installations?
2. able to get a working Reduce via
svn co ...
3. Are the separate editions for pure Windows vs. Cygwin?
These questions are in fact related by the socket/pipe
issue, because I need to know if I should check for Windows
or (or and?) Cygwin in the configure step.
Good and proper question for us to get an answer to on the record here! For merely USING a pre-built Reduce the CSL (and when it becomes available the PSL version too) are ordinary native Windows applications where you should not need anything else installed to make them work. Well right now there may be an issue relating to gnuplot which at present you need to fetch and put where it has to be for yourself - said inconvenience being in part a consequence of what I see as an ugliness in sourceforge policy about source availability... But anyway to run a ready-built Reduce there is no need to have cygwin or any "odd" stuff installed.
To rebuild from source you could download a source snapshot, but to get the latest version you will be fetching using subversion. To use subversion and to use the build process on Windows you need a bourne-again shell, gnu make, autoconf, gcc, libtool and a bunch of other things. This is set up to be done using a cygwin shell. So to go "./configure...;make" you have to be running a cygwin shell. The normal behaviour then is to use gcc with the command-lien option "-mno-cygwin" which instructs it to build using the "mingw" option built into the standard gcc there, and this avoids use of cygwin-specific libraries in favour of using Microsoft versions.
Hypothetically it MIGHT be possible to build under mingw/msys - indeed that ough to be ok maybe, but I have not tested and am not about to. And maintaining support for an extra build environment is something that would add extra effort.
If you install the cygwin-hosted snapshot of the 64-bit mingw (which is not really quite production-quality yet, but is usable when you are lucky!) it is possible to use that to build a 64-bit windows version, which again is native 64-bit windows and the binary should not need anything beyond windows itself. I have not tried that for several months and do not guarantee it is still OK and certainly do not guarantee that it is easy for an arbitrary person to use! Roll on when mingw64 is folded into cygwin via a "-m64 -mno-cygwin" option (ha ha ha dream on).
For windows it is necessray to create a reduce.exe that is linked as a windowed executable and a reduce.com linked as a console application. People who worry about that can do web searches on the issue of remaining connected to consoles etc.
In UNUSUAL circumstances somebody might want to make a genuine cygwin reduce to run on windows using an X server there. There are only two rational uses of that I can imagine. (a) to debug some X11 code if windows is what you have to run on and (b) to use a remore X terminal or Unix machine but run reduce over a network link on a windows computer. Both seem obscure to me, but there is a configure option to enable it.
At ONE stage I could use cygwin and gnu make but cause it all to use the command-line version of Microsoft's C compiler. I have not tried that for ages and striongly suggest use of gcc. I imagine that reduce coudl be compiled using Visual Studio but then all the rest of the make framework etc would fall away and I am not keen on that. But somebody else who wanted to work on CSL might like Visual Studio and if they are going to do something that interests me I might help!
In my configure.ac scripts I arrange that WIN32 is defined on any windows variant (including 64-bit!). So I am used to "#ifdef WIN32". My configure scripts are probably not good and secure against attempts at cross-compilation - sorry!