[MLton] MinGW port

[Stephen Weeks]

Brent, I had a chance this morning to read through your patch to port
MLton to MinGW.  Thanks again for sending it -- it looks good, and not
too hard to integrate.  BTW, I definitely owe you a MLton t-shirt.
Please send me in private email your size (M, L, XL) and address and
I'll drop one in the mail.

I have a few issues I'd like to bring up on the list before I start in
on some of the stuff.  Nothing major, though.  Assuming all goes well,
I plan to get the code in this week.

* I think the name of the MLton.Platform.OS.t variant should be
  "MinGW", not "Mingwin".  We try to stick with whatever name the
  project uses for itself.

* For the x86 codegen, we no longer use reserveEsp for Cygwin.  I
  don't think there's any need for it on MinGW either.  Did you put it
  there for a reason or just to mimic the Cygwin case?

* In main/main.fun, you added a comment about the renaming of exe
  files that we do on Cygwin, but didn't add any code.  Is something
  missing? 

* In the C #ifdefs, sometimes you use __MINGW32__ and sometimes
  __MSVCRT__.  Is there a method to what you did, or could they all be
  replaced with __MINGW32__?

* Why did you include win32-resource.h?  It appears to be unused.

* I'm afraid I can't include the GPL'd code from the Labrea project
  for MLton.Syslog and from Cygwin for Posix.Io.Flock, ProcEnv.uname.
  Although MLton is currently released under the GPL, this is
  problematic for commercial users, because their code, which links
  with the MLton runtime, is also required to be GPL'd.  We hope to
  change our license some day, at least to include an exception for
  such situations.  The reason we have not done so already is that NEC
  holds the copyright on the original release of MLton, which was
  released under the GPL, and as yet has been unwilling to relicense.
  We are still hopeful they will, though, and don't want to pollute
  MLton with GPL'd code from other sources.  I apologize for any
  extra work this may have caused -- this information really belongs
  somewhere more accessible to potential contributors.

* There are a number of functions on Windows that don't make sense (or
  at least are unimplemented for now).  Here's a list I compiled as I
  read your patch. 

	MLton.Rusage.rusage
	OS.IO.poll
	Posix.FileSys.{chown,fpathconf,ftruncate,link,mkfifo,pathconf,readlink,
			symlink}
	Posix.IO.{dupfd,getfd,fsync,pipe,setfd}
	Posix.ProcEnv.{ctermid,getegid,geteuid},getgid,getgroups,getlogin,
			getpgrp,getpid,getppid,getuid,setenv,setgid,setpgid,
			setsid,setuid,sysconf,ttyname}
	Posix.SysDB.{Group.*,getgrgid,getgrnam,getpwuid}
	Posix.TTY.{TC.{getattr,sendbreak,setattr},drain,flow,flush,getpgrp,
			setpgrp}

  There are a number of things we could do for these functions.

   A. Remove them from the signature
   B. Raise SysErr in SML
   C. Treat as noop in SML
   D. Return -1 from C, hence causing SysErr to be raised
   E. Treat as a noop in C

   You chose (E).  I think the right choice is (B).  We would rather
   warn users that they have called an unimplemented function than
   silently continue.  I think (B) is better than (D) because we have
   better abstraction facilities in SML and can more concisely define
   the different behavior.  The reason I don't like (A) is that it
   leads to conditional compilation of SML code, since we will need to
   provide different versions of the basis for Windows and for Unix,
   and this will lead to conditional compilation of user code as well.

   Of course, we will need to document all the unimplemented functions
   in the user guide.  Since there are so many, and it might be
   confusing to users to have just a little bit of Posix defined,
   another reasonable alternative would be for us to cause all the
   Posix functions to fail on MinGW.  That is simpler to document and
   to think about.  It would encourage people to use the more portable
   OS structure.  One drawback is that a number of the functions work
   sensibly, and we are making code that uses them harder.  So, I
   suspect this is a bit overkill.

Any thoughts people have on any of theses issues are appreciated.