[MLton] Windows 7 x64 vs MLton r7999

[Wesley W. Terpstra]

Since there's a MLton release coming up, I thought it would be a good idea
to check out how/if MLton works on Windows 7 (RC1) which is due out in a few
months. The good news is that it mostly works (!). Some caveats:

* A self-compile of MLton trips over the use of "mlton -stop f" in
mlton/Makefile to determine dependencies. The problem is that this
(correctly) includes paths like c:/program files
(x86)/mlton/lib/mlton/sml/basis/build/sources.mlb. GNU make cannot handle
paths with spaces in their names. I imagine this is also a problem with
Windows XP, but I have a German WinXP so it is called
"C:/Programme/MLton/..." which doesn't trigger this problem. One solution
might be to make a -stop f that doesn't include anything pulled from
$(SML_LIB). This corresponds to the gcc "-MM" option which is actually what
we want in the context where -stop f is used in the Makefile. Another option
would be to simply remove the -stop f from mlton/Makefile (I did this to get
the build done, and it worked after removing the offending line).
Suggestions?

* msys uses an rxvt.exe which does not work under Windows7. Using msys
-norxvt fixed this. I'll either modify the msys.bat to disable rxvt.exe or
find a fixed rxvt.exe.

* Windows7 complains vehemently about installing MLton-7999.msi because it's
from an "unknown publisher". I need to learn how to sign MSI files; this
might require acquiring an official MLton signing certificate.

* Windows7 appears to treat some file extensions as dangerous. If you try to
create a file with the extension ".exe" or ".bat" in the install location of
MLton, you will get permission denied errors. This doesn't seem to be a
problem in the c:/Documents and Settings/Username/... path area. This means
that you can't build ML programs in your msys home directory, nor the
examples in the documentation directory. I think the first case is a
problem, and I am looking into moving the home directory to c:/Documents and
Settings/Username/MLton. The second case seems quite reasonable to me; we
can't compile examples in /usr/share/doc/examples either.

* I noticed that we don't strip executables created by MLton. On windows
this can reduce the file size from 322k to 232k for hello-world. I can't
imagine that the C debugging symbols are very useful anyway. Perhaps we
should strip by default?

* All regressions except the test-{spawn,create} pass.

* I'm investigating including a Win64 toolchain in the MSI with a MLton
cross-target. Then users could build 64-bit applications as simply as
'-target win64'. The main downside seems to be the increased msi file size.
I propose we provide two packages: a win32 only version and a win32/64
version. Both would default to outputting win32 and be win32 hosted.

On a final note, I'll mention that Windows7 impressed me. I think it's quite
likely most people will be upgrading to it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20090704/bed222f4/attachment.htm