![]() |
Subject: Windows versions of CCL available for smoke-testing Newsgroups: gmane.lisp.openmcl.devel Date: Thursday 9th October 2008 02:28:25 UTC (over 9 years ago) 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 ?". |
||