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:<br>
<br>* 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?<br>
<br>* 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.<br><br>* 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.<br>
<br>* 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.<br>
<br>* 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?<br>
<br>* All regressions except the test-{spawn,create} pass.<br><br>* 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.<br>
<br>On a final note, I'll mention that Windows7 impressed me. I think it's quite likely most people will be upgrading to it.<br><br>