[Openmcl-devel] Windows versions of CCL available for smoke-testing

[Gary Byers]

32- and 64-bit versions of Clozure CL for Windows are now available in svn:

<http://svn.clozure.com/publicsvn/openmcl/trunk/windows>

The 64-bit version's been available for a while; the 32-bit version's 
brand new (and still contains some known runtime bugs, along with all
of the unknown ones.)  We only have a few (real or virtual) Windows
boxes available, so it'd be helpful if people with (a) interest (b)
some time and (c) access to real or virtual Windows boxes could
take this for a ride around the block, kick the tires, etc.

As of yesterday, the win32 version could compile itself successfully
3 times out of 4 and crashed the 4th time.  The win64 version hasn't
had a random unexpected crash in a few months, but AFAIK I've been
the only person using it much.  As much as anything, it'd be interesting
to see if this general impression (the win32 port is at the outer bounds
if usability, the win64 port is generally a lot closer) is confirmed or
refuted by other people's experience.

Both version should run under XP or Vista (but almost certainly not under
anything older than XP.)  XP is several years old now, and XP with a
recent "service pack" is somewhat different from earlier version.  Most
of the Win32 development's been done under a fairly recent (SP3) version
of XP; it'd be interesting to know whether it works on eariler versions.

The 64-bit version requires a 64-bit version of Windows (XP64, Vista 64.
maybe some server OS versions.)  It's currently the case that the 32-bit
version of CCL doesn't run under 64-bit OS releases.  We understand why
it doesn't, and hope to remove this restriction ASAP.

I don't use SLIME; I honestly don't know whether or not there are socket
or other issues that'd prevent SLIME from working.  (If there are, please
let us know and we'll try to give priority to fixing them.)

Some things that we do know:

- Windows has a very different model of file permissions and sharing
   than Unix systems do.  On Unix, it's well-defined, meaningful, and
   useful to (for instance) delete a file that you have open; Windows
   generally doesn't allow that sort of thing.  (One consequence of this
   is that calling REBUILD-CCL with any options that'd cause the kernel
   to be rebuilt can't work the way things are currently implemented,
   since the lisp kernel has been opened by the OS.)  There are other
   consequences, some of which can be addressed and improved and some
   of which can't: this is a very different OS.

- Most Windows functions and utilities that deal with pathnames can
   accept either forward or backward slashes as directory separators.
   CCL pathname/namestring functions don't (yet) deal with backslashes
   or with some other Windows namestring conventions.  (When a Windows
   function returns a namestring, any backslashes in that namestring
   are converted to forward slashes before lisp pathanme code sees it.)

- The lisp kernel is built with the Cygwin tools (www.cygwin.com), though
   we don't use any Cygwin libraries.  To build the 32-bit kernel, you'd
   need (at least) the 'make', 'gcc', 'm4', 'mingw" and "w32api" packages
   and their dependencies; the 64-bit kernel also needs a 64-bit toolchain
   available from the mingw-w64 project:

   <http://sourceforge.net/projects/mingw-w64/>

- We haven't done any work yet on Windows GUI programming (examples,
   bridges, ...).  On Win32, there's at least on low-level FFI change
   that'll be needed to support this (Win32 functions follow a "pascal-like"
   calling sequence, in which the callee pops its arguments off of the
   stack before returning.  The way that we do foreign function calls, I
   don't think that we care about this, but I'm pretty sure that we
   need to extend DEFCALLBACK to meet the caller's expectations.  (Perhaps
   we should call that extension DEFPASCAL ...)

Andreas Bogk did a lot of early work on the Win64 port, and the Win32 
version has gotten as far as it has as quickly as it has largely because 
Matt Emerson's ia32 compiler backend and runtime are as good as they are.

Again and especially in the case of the 32-bit port, "as far as it's
gotten" is "somewhere around the outer bounds of usability."  You'll
likely find that it crashes in mysterious and non-repeatable ways (it's
likely still on the wrong side of those outer bounds ...), and at this
point the most interesting questions are "does it run at all?" and "if
not, what OS version are you using ?".