>>>>> On Fri, 11 Aug 2006 10:41:11 +0200, Edi Weitz said:
> On Fri, 4 Aug 2006 16:58:05 +0100, Martin Simmons
> > That approach is fine for XP (though be aware that your private copy
> > of the DLL will not be updated by Windows Update). Personally I
> > prefer the vcredist_x86 approach though, because it works on all
> > versions of Windows.
> I just saw the same thing for the first time - a LispWorks DLL
> delivered to a customer only worked after he installed the C++ runtime
> library - I didn't notice this during the beta phase because I
> obviously only tested on my own machines.
> I think this is pretty sad, because it makes deployment of LispWorks
> executables on Windows a lot harder. In the "good old days" (two
> weeks ago) you just gave them an EXE, now you have to use an
> installer, and if you want to do it 100% correctly you probably even
> have to use Microsoft's installer.
If you use the vcredist_x86.exe then you shouldn't need an installer.
Remember to install Windows first :-)
> And people will probably start to ask questions like "If this is a
> pure Common Lisp program as you said, why on earth do you need this
> C++ library?"
> So, could you shed some light on why whis was necessary? ISTR that
> the other two Lisps that can create executables on Windows (Corman
> Lisp and AllegroCL) also need these libraries, but LispWorks so far
> didn't. Is there some specific new feature that needs this support?
> Will every EXE/DLL created with LW 5.0 need the C++ runtime libraries?
LispWorks has a small amount of C code that loads the Lisp heap and deals
a few OS interfacing issues. We build this with the VC++ compiler and link
dynamically to the C (not C++) runtime library.
The thing that has changed in LispWorks 5.0 is that we switched from VC++ 6
VC++ 2005. This was necessary for three reasons:
1) VC++ 6 is no longer supported by Microsoft. It is no longer part of
2) We found a fatal bug in the C runtime library (msvcrt.dll) used by VC++
programs on Vista beta. I don't know if this has been fixed in the rc
3) We needed support for 64-bit compilation and didn't want to support two
different versions of VC++.
Unfortunately, we are in another transition stage, where older operating
systems don't have the libraries needed to run newer applications. This
happened before with the VC++ 6 msvcrt.dll and also with the Common