[MLton] MinGW port

[Brent Fulgham]

--- Stephen Weeks <sweeks@sweeks.com> wrote:

> Thanks again for sending it -- it looks good, and
not
> too hard to integrate.

Great!  I tried to generate it off a very recent set
of sources to reduce conflicts.

> 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.

Wow -- didn't even know that was a possibility. 
Thanks!

> * 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.

Fine.
 
> * 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?

Just copying Cygwin.

> * 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? 

I'll review it.  I believe I was trying to stop the
files from being renamed from "test.exe" to "test",
but probably did not get that completed.

> * 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__?

I used __MSVCRT__ any place a change was not MinGW
specific, with the idea (since MinGW uses the
Microsoft
C runtime libraries) that these changes would be
proper for a straight Visual C++ build of MinGW.  I
followed this approach based on how windows ports of
other software were done.

The __MINGW32__ #ifdefs are there for things that do
not apply to a native Visual Studio build of MLton.

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

Hmm.  This was the the start of an implementation of
resource limits that I did not complete (yet).  Some
of the #define's may need to be moved to one of the
other header files if you end up removing it.

> * 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.

The MLton.Syslog stuff is not a big deal.  Too bad
about the Flock and Uname sources...

> * 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. 

Most of these are items that either were not critical
to trying to bootstram MLton, or did not have an
obvious analog under Windows.

* MLton.Rusage.rusage:  Not available in Windows,
though some of the functionality has analogs that
could be used to implement natively.  This work needs
to be completed.

* OS.IO.poll:  I couldn't find an analog.  May need
several elements of MLton to be ported to win32
behavior.  Signals are a real problem in this regard
(though the basic use MLton makes of signals means a
lot could be easily mimicked in Win32).
 
*
Posix.FileSys.{chown,fpathconf,ftruncate,link,mkfifo,
  pathconf,readlink, symlink}:  We should be able
to implement almost all of these, except the symlink
stuff.  Symlinks could be mimicked using "short cuts".

* Posix.IO:  Some of this is because Win32 sockets 
don't work the way UNIX socket stuff works.  Also, 
pipes are not the same.

* Posix.ProcEnv:  Mostly due to win32 
incompatibilities.  I tried to emulate the getgid, 
getuid stuff using the win32 analogs.  setenv should
be easy to implement.

* Posix.SysDB.{Group.:  Similar to the last group.  
Windows was not built from the ground up to be 
multi-user, so lots of kludges that I didn't play with

yet.

* Posix.TTY.{TC.}:  This was just done to allow things
to compile.  I did not investigate getting the TTY
to work properly.
 
>   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). 

Yes.  (E) is good for trying to build the thing the
first time.  For end users it is unacceptable.

> I think (B) is better than (D) because we have
> better abstraction facilities in SML and can more
> concisely define the different behavior.

I agree that (B) would be a better option.  I think it
is appropriate to raise an error on an unimplemented
function.

> 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.

I vote for option (C), which would be to document
that the functions are not available, then provide
the working implementations we have to that the
Intelligenci can secretly use them for nefarious
ends!

If we just don't document the versions that exist,
we can slowly include more functionality until the
POSIX layer works.

I think some of the critical MLton tools make use of
the POSIX layer, don't they?  How can these tools
work in a native Win32 environment (unless they
all use the OS layer?)

-Brent