Unix on Windows

Individuals unfortunate enough to be forced to use a Windows machine can make life more bearable with the following bits of software ...

GnuWin32 is a project which ports lots and lots of GNU utilities to win32; their packages include:
- coreutils (ls, cp, mv, mkdir, rm, rmdir ...)
- cygutils (handy and mostly windows-specific stuff, plus cal)
- diff (including cmp, diff3, sdiff)
- file
- find (including xargs)
- grep
- less
- patch
MinGW is 'Minimalist GNU [Compiler Collection Toolchain] for Windows'; it's a port of the GCC toolchain to Windows. It's a native port, in that the binaries it produces use msvcrt.dll as their libc, rather than something that tries to be a unix emulation layer - mingw is a toolchain for Windows, not an emulation layer, a porting framework, or anything like that (for which, see Cygwin). MinGW comes as a rather complex set of packages, but the ones you need are gcc-core (the compiler itself), binutils (as, ld, and all those freaky tools for making libraries and stuff), mingw-runtime (header files for msvcrt, plus a library for POSIX libc things not in msvcrt), and w32api (the header files for the Windows API). If you want to compile some language 'foo' that isn't C, you'll also need gcc-foo; at present, there's ada, C++ (aka g++), fortran 77 (aka g77), java and objective C (aka objc). There are also packages for make, binutils, gdb, and a bunch of other tools.
MSys
Lots of unix utilities have Windows binaries:
- gzip
- bzip (although the GnuWin32 version is probably more recent)
bash
- Ideally, we'd build bash from scratch, using genuine sources. MinGW will do the compilation, but bash has a unix-style build system, so we need to run a configure script, and to do that, we need, er, bash. Well, we can bootstrap with Mr Kemp's bash! First up, create C:\tmp to keep it happy, and make sure you've got sed and the other tools a configure script needs installed. Now, set your CONFIG_SHELL environment variable to a unix-style path to the location of the bash binary. Then run bash on the configure script. You should pass configure a build parameter, since it probably won't be able to work out the build type itself; this takes the form --build=CPU-pc-OS, where CPU is i586 for a Pentium and i686 for a Pentium Pro, and OS is windows32 for a non-NT Windows, and windowsnt for an NT windows. Sadly, i can't get this to work; 'source configure' gives me:
```
test: too many arguments
test: too many arguments
rm: cannot lstat `conftest*': Invalid argument
bash": error: cannot run /bin/sh ./support/config.sub
rm: cannot lstat `core.*': Invalid argument
rm: cannot lstat `*.core': Invalid argument
```
  The complaints about things with * in are due to different handling of globbing on unix and Windows - a pattern which doesn't match anything evaluates to an empty list on unix, but evaluates to the pattern on Windows. These problems can be kludged around by creating (using 'touch') a file which will definitely match the pattern immediately prior to the line which applies the pattern (which, in this configure script, is always 'rm *.foo', so this is safe). There are further problems where bash and some of the external programs it runs have different ideas about line-ending conventions. Having identified which variables are affected, clean them up with code like:
```
x=`echo $x | tr -d [:cntrl:]`
```
  Fuck, can't reproduce that; now i just get:
```
 or ..r: cannot find sources in configure
```
  Another time, another time ...
- Note to self: is the solution to throw away he Kemp make and the GW32 tools, and use sh and tools from MSys? That is what MSys is for, so maybe it's been engineered to avoid these problems. If not using MSys, we need a make from somewhere after configure's done - see http://unxutils.sourceforge.net/ and http://lists.gnu.org/archive/html/make-w32/. Or use MS nmake? Will that work?