A string. It is the name of the file that the image is saved as. This name should not be the same as the original name of the image.
A list of strings, or the keyword
A list of strings.
A generalized boolean.
If non-nil, there is a garbage collection before the image is saved. The default value is
Determines if some global variables are cleared before the image is saved. You can generally use the default value, which is
If this is
the function normal-gc is called before the image is saved. The default is
A function to be called on restart.
Controls whether multiprocessing is enabled on restart.
On Windows console controls whether the new image will be a Console or GUI application and when, if ever, to make a console window in the latter case.
environment controls whether the LispWorks environment is started on restart. Possible values are discussed below.
remarks adds a comment to the save history. The value should be a string.
A generalized boolean. If non-nil, the Lisp heap and the executable are saved in two separate files.
For information about the sort of changes you might want to save in a new image, see Customization of LispWorks.
Do not use
when the graphical IDE is running. Instead create a build script and use it with the
command line argument similar to the examples below, or run LispWorks in a subprocess using the Application Builder tool.
is implemented only on Windows, Linux, x86/x64 Solaris, Macintosh and FreeBSD. It controls whether the image saved is an executable or a dynamic library (DLL). The default value is
and this value means an executable is saved. The value
is supported on Microsoft Windows only (see below). Otherwise
should be list (potentially
). In this case a dynamic library is saved, and each string in
names a function which becomes an export of the dynamic library and should be defined as a Lisp function using
. Each exported name can be found by
(on Windows) or
(on other platforms). The exported symbol is actually a stub which ensures that the LispWorks dynamic library has finished initializing, and then enters the Lisp code.
On Microsoft Windows the
list can also contain the keyword
can simply be the keyword
, both of which mean that the DLL is intended to be used as a COM server. See the
LispWorks COM/Automation User Guide and Reference Manual
On Mac OS X the default behavior is to generate an object of type "Mach-O dynamically linked shared library" with file type
below for information about creating another type of library on Mac OS X.
On Linux, Macintosh, x86/x64 Solaris and FreeBSD, to save a dynamic library image the computer needs to have a C compiler installed. This is typically
(which is available by installing Xcode on the Macintosh).
specifies whether a LispWorks dynamic library should initialize inside the call to
(on Microsoft Windows) or
(on other platforms), or wait for further calls. Automatic initialization is useful when the dynamic library does not communicate by function calls. On Microsoft Windows it also allows
to succeed or fail according to whether the LispWorks dynamic library initializes successfully or not. Not using automatic initialization allows you to relocate the library if necessary using InitLispWorks, and do any other initialization that may be required. The default value of
on other platforms. For more information about automatic initialization in LispWorks dynamic libraries, see LispWorks as a dynamic library.
should be a list of filenames. It is ignored on Microsoft Windows. On other platforms if
is non-nil then a dynamic library containing each named file is saved. Each file must be of a format that the default C compiler (
) knows about and can incorporate into a shared library. Typically they will be C source files, but can also be assembler or object files. They must not contain exports that clash with names in the LispWorks shared library (see Dynamic library C functions for the predefined exports). The added files are useful to write wrappers around calls into the LispWorks dynamic library. Such wrappers are useful for:
dlopen, by using
is used only when saving a dynamic library. On Mac OS X it generates an object of type "Mach-O bundle" and is used for creating shared libraries that will be used by applications that cannot load dylibs (FileMaker for example). It also does not force the filename extension to be
. On other Unix-like systems
merely has the effect of not forcing the file type of the saved image, and the format of the saved image is the same as the default. On Microsoft Windows
(the default), then the saved image is written as a single executable file containing the Lisp heap. If
, then the saved Lisp heap is split into a separate file, named by adding
to the name of the executable. When the executable runs, it reloads the Lisp heap from this file automatically.
In addition, when saving LispWorks as an application bundle on the Macintosh (for example by using create-macos-application-bundle),
can be the symbol
. This places the Lisp heap file in the
directory of the bundle, rather than in the
directory alongside the executable, which allows the heap to be included in the signature of the bundle.
, if non-nil, specifies a function (with no arguments) to be called when the image is started. If
is called in a new process.
is called after the initialization file is loaded. The default value of
, the executable image will start without multiprocessing enabled. When
is true or the image is a DLL, the image will start with multiprocessing enabled. The default value of
Unchanged since previous save.
On the Macintosh, the value
has the same effect as the value
At startup, if input and output are not redirected
At startup, even if input and output are redirected.
Unchanged since previous save.
Start with just the TTY listener.
Start the environment automatically, no TTY listener.
You should not try to save a new image over an existing one. Always save images using a unique image name, and then, if necessary, replace the new image with the old one after the call to
Note that LispWorks quits automatically after processing a build script via
, whereas with
you need to call quit explicitly at the end of the build script.
This example shows a portable build script which, on Cocoa, saves your new LispWorks image in a Mac OS X application bundle. This allows your new LispWorks for Macintosh image to be launchable from the Finder or Dock and to have its own icon or other resources: