I have finally succeeded in generating a DLL with LispWorks. Along the
way I found some "interesting" items...
1. The Lisp multiprocessor is started prior to calling the main
routine, apparently despite whatever you specify in the delivery
options.
2. As a consequence of (1) the main routine is launched on a separate
thread and there is no guarantee that it will run or complete before
the DLL returns to the caller of LoadLibrary(). So be sure not to put
critical initialization inside that main routine. Rather, set up a
separate initialization routine and explicitly call that from the DLL
client code.
3. The LispWorks multiprocessor engine seems to need a functioning
Windows Event pump in place before it can successfully initiate
multiprocessing. Since this happens before the main routine is called,
it is imperative that the caller ensure such exists before calling
LoadLibrary(). Ways of accomplishing this are:
a. Call MessageBox() in the client before calling LoadLibray(). But
this requires the user to click on a dismissal button...
b. Create a window or console based client and ensure that this
window gets created prior to calling LoadLibrary on the Lisp DLL.
c. Create a hidden window in the client, and use an Event to ensure
that the window gets created before calling LoadLibrary. That window
can get by with a null event loop handler. But it needs to be in a
separate thread, or else you get stuck forever running the hidden
window.
4. Getting delivery levels above 1 are tricky. I have sometimes
succeeded in delivering at level 5 -- the most stringent and smallest
resulting images. At level 5 I always get a nastygram telling me that
there is an interpreted function in an image with no interpreter. The
image is generated anyway, and this interpreted function has never
caused me any problems. Perhaps it has to do with the LispWorks
actions or advice system.
I have succeeded in generating a multithreaded back end for a COM/OLE
server whose front end was written in MSVC++ use the ATL generated
framework. This makes for a very easy to build COM/OLE server since
the C code only needs to prep arguments and call the Lisp DLL
entrypoints. Doing the guts of the server in Lisp allowed me to reduce
the code from >3 KLOC of C++ to around 500 lines of Lisp... and I got
enhanced behavior with the Lisp code too!
Generating LispWorks DLL's is a wild ride for the first few days.. but
after a while it becomes pretty slick. Hopefully, these comments will
help others to do the same.
Cheers,
David McClain, Sr. Scientist, Raytheon Systems Co., Tucson, AZ