There is one issue which I don't know the implications of:

Running tests from 'tests/runtime-errors' ...
make compile
make run
/bin/sh: line 0: ulimit: stack size: cannot modify limit: Invalid argument
 ... testing 'stackoverflow.bytecode': => passed
 ... testing 'syserror.bytecode': => passed
 ... testing 'syserror.native': => passed

As far as I can tell, you cannot alter the stack size in Cygwin (at least not with ulimit). Does that have implications for this test? If not, shall I put a test using uname for Cygwin to short-circuit the command just to remove the erroneous looking output?

The commits seem fine so far -- I would have merged them without your warning.

The ulimit call here is designed to make sure that there is a limit to the stack. The implemented test should succeed no matter what this limit is (so having the default limit is fine if ulimit does not exist), but it would fail if there was no limit with a dynamically-growing stack (the program would loop for a very long time, and possibly OOM instead of having the expected behavior). If you know for sure that Cygwin never uses a dynamically-growing call stack, then just disabling ulimit is fine, otherwise it should be replaced by something of similar effect.

Hmm - Cygwin certainly has a default limit, but I don't know how it's arrived at. For example, the machine I'm on (fairly old Cygwin) has ulimit -s = 2025 but in a VM on the same machine with a newer Cygwin it has ulimit -s = 2033. Does ulimit give a known value if the stack is unlimited which could be tested for? Equally, if a Cygwin comes along with an unlimited stack, we're going to notice that suddenly the testsuite hangs, so maybe disabling the ulimit for Cygwin with just a comment in the Makefile as to why is enough?

On Linux, you can set ulimit -s unlimited, and if the stack size is unlimited then ulimit -s will print unlimited. I would assume that Cygwin would also return unlimited if the stack size was unlimited. This mean you could change the Makefile to only skip the test if ulimit -s prints unlimited, either just on Cygwin or on all systems.

75a000d added to eliminate the ulimit call on Cygwin. Also a minor bit of tidying in make -f Makefile.nt [dist]clean

Right - this is all ready-to-go as far as I'm concerned. The deprecated_module_use test fails at the moment but will start passing when #370 is merged (I've checked).
Would you like me to rebase before merging?

The commits look reasonably atomic. I'll wait for #370 to be merged (it's still waiting on some further changes if I understand correctly) and merge this one then.

Rebased in order to include a small fix for #319

OK - hopefully that really is the last change appropriate to this PR! A small revision to the third commit (1cc554f) to include .runner scripts. The last commit re-enables a disabled test (lib-threads/sockets.ml) and adds support for a lib-threads/signal.ml - Windows may not have signals, but it does have a reliable way to send CTRL+C to a console program.
CANKILL seems very confusing - especially as Cygwin does have the ability to kill native Windows processes (though not in a Posix way) - given that the only remaining use of this is lib-threads/signal2.ml, I changed the way .precheck works to pass on the TOOLCHAIN variable and explicitly disable the test when running on msvc or mingw (TOOLCHAIN is the same value between 32 and 64-bit)

About copyright headers: we recently decided that they are not needed in testsuite/test so please do not add any.

Could you pull all the .gitignore and .gitattributes files up to the top directory? Our current doctrine is that it's better to have all the information centralized in one file.

OK for merge after the .gitignore and .gitattributes contents are moved.

.gitattributes & .gitignore updated as requested, and rebased onto trunk.