As far as we know each of the 32-bit LispWorks implementations runs correctly in the 32-bit subsystem of the corresponding 64-bit platform.
On macOS, the LispWorks application bundle is signed in the name of LispWorks Ltd.
On Microsoft Windows, the LispWorks Personal Edition executable is signed in the name of LispWorks Ltd.
Other LispWorks editions are not signed, because of the complications around image saving and delivery that this would lead to.
For more information, see 13.3.6 Code signing in saved images in the LispWorks® User Guide and Reference Manual.
The supplied LispWorks (64-bit) for Macintosh images are universal binaries, which run the correct native architecture on arm64 (Apple silicon) and x86_64 (Intel) Macintosh computers by default.
A running Lisp image only supports one architecture, chosen when the image was started. On a x86_64 based Macintosh, this is always the x86_64 architecture. On an arm64 Macintosh, a running LispWorks image can be either the native arm64 architecture or the x86_64 architecture (using Rosetta 2).
Functions such as hcl:save-image and lispworks:deliver create an image containing only the running architecture and functions that operate on fasl files such as cl:compile-file and cl:load only support the running architecture.
To build a universal binary application from LispWorks 8.1 for Macintosh, you will need to install LispWorks on an arm64 (Apple silicon) Macintosh computer.
The supplied LispWorks (64-bit) for Macintosh images are split, which means that the Lisp heap is split into a separate file, named by adding .lwheap to the name of the executable. In the appliction bundle, this is stored in the Resources directory.
In addition, the split argument to hcl:save-image and lispworks:deliver defaults to :default, which causes the new image to be split by default on macOS.
Release Notes and Installation Guide - 25 Feb 2025 19:14:05