Dear SBCL developers and users:
There are a couple of things about SBCL for Windows that deserve to be
posted here, or so I think.
1. It turned out that a few last versions of my MSI installer for
32-bit Windows (up to, but not including, today's build 126.96.36.199.267)
are uninstallable at least on _some_ 32-bit systems (Microsoft Windows
Installer complains on "unsupport CPU type").
The problem was caused by my _local_ build scripts, which build both 32
and 64-bit SBCL and update online information (github wiki and
forknews.html). While there is (probably/hopefully) nothing wrong with
make-windows-installer.sh in SBCL sources, my autobuild scripts were
passing the wrong -arch / -platform option to WiX. I was unable to
detect it because both 64-bit and 32-bit Wine _and_ real 64-bit Windows
were not complaining.
If anyone have seen this problem on 32-bit Windows, and decided to
postpone testing SBCL/Win32 until it is able to install (at least),
today is the next moment to give it a chance again: current binaries for
`188.8.131.52.267.kovalenko.wth' are installable on both 32-bit and 64-bit
2. 64-bit SBCL/Windows is now able to give useful backtraces. Due to the
same changes in code, 32-bit version produces correct backtraces even
when built with -fomit-frame-pointer (building SBCL runtime with this
optimization in older versions made backtraces _unreliable_ on 32-bit
On Windows/AMD64, what we receive in %RBP (when C calls into Lisp) is
useless most of the times, and may be useful only by chance.
OS-specific functions for walking the stack and building frame sequence
don't rely _only_ on RBP for functions present in executable image: they
(StackWalk64 and RtlVirtualUnwind, for example) analyze function
prologues and unwind tables in the image.
My method of getting reliable backtrace on this platform is based on a
specific feature of current safepoint-based SBCL code:
* every call_into_lisp, except the topmost one, is done from the
SBCL is perfectly able to backtrace Lisp frames. When exception handler
call into Lisp, I reconnect the frame pointer chain using the
information taken from the exception context (and saved in struct
3. I decided to heed the advice of Alastair Bridgewater: get rid of CRT
`lowio' file descriptors, at least for generic I/O purposes (of course,
I don't touch SB-POSIX here: this package uses CRT `lowio' functions
intensively, for the obvious reason: lowio layer `emulates' POSIX).
For core fd-streams (and for sb-bsd-sockets) my builds don't use CRT
descriptors anymore. It was not that easy (run-program is especially
tricky in this respect), but it's the necessary precondition of
eventually moving to some sensible I/O abstraction layer, instead of
continuosly emulating Unix on Windows.
This feature (using kernel32 handles as file descriptors immediately) is
still optional. My current code should also build correctly when the
flag :FDS-ARE-WINDOWS-HANDLES is disabled at build time (e.g. from
For retaining compatibility with third-party code whose authors _know_
the old SBCL behavior, GET-OSFHANDLE and OPEN-OSFHANDLE alien routines
are now redefined for non-lowio builds, so they behave (mostly) like
IDENTITY. There is no guarantee that it always helps (e.g. some code may
call real _get_osfhandle or the like on its own, instead of our routine
However, I've just tested my new builds with those cross-platform
packages from Zach Bean's QUICKLISP repository that are known to wrap
and unwrap file descriptors from under ANSI file streams, and didn't
found any new failures. Even more, CL+SSL _started to work_ (it turned
out that CL+SSL expects to get kernel32 handle from
SB-BSD-SOCKETS:SOCKET-FILE-DESCRIPTOR, and it's exactly what happens
now -- but not before).
4. As some recent reports show, users deciding to test my builds may
have a hard time with SBCL_HOME variable pointing to the wrong place.
My sbcl.exe is able to locate both "sbcl.core" and contribs in its
directory _without_ SBCL_HOME, so I made environment variable
registration into an _optional_ feature in my current MSI
installers. However, if some other installation already sets SBCL_HOME
(system-wide), or if it's set manually, sbcl.exe may fail after deciding
to load the wrong sbcl.core. Don't know at this moment how it should be
resolved finally; maybe I should do the thing that I hesitated to, i.e.
ignore SBCL_HOME if sbcl.core is found in executable's directory.
Opinions are welcome.
Actual URLs, new and old:
...auto-updated links to MSI installers and archived stand-alone
executables for Windows/X86 and Windows/AMD64
...page header contains the same links to installers and binaries as
the Wiki page above; the page also contains some documentation of my
changes to SBCL code, but changes of the last few weeks are not
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia