Luis Oliveira wrote:

Allegro resets the stack pointer to whatever value it had before pushing the foreign call's arguments to the stack. This approach works for either stdcall or cdecl. I'd believe CLISP's ffcall is insensitive to the actual stack value on return as well. But that's not the only difference.

Edi Weitz recompiled the .dll used by cl-gd for ease of use by Lisp. The reason is name decoration: the original contains names like "myfun@8", whereas Edi's version has names "myfun" -- or vice-versa. The "@8" suffix means thath the function takes 8 bytes of arguments, probably two 32-bit pointers, or two 32-bit ints, or a mix of both, or whatever. In CLISP, using def-call-out, you must give the exact matching name. As a result, it's much easier to interface when the library contains the typical "short" names. However, IIRC, Visual Basic has it the other way by default, but can accomodate both. I believe authors aware of the problem when coming from other languages would normally use the short form. Sadly, gd does not (historic reasons, probably). Note that name decoration can be independent on the calling convention. IIRC, MS-VC etc. can use .def(inition) file and define the mapping themselves that they want in their library. All of that is from memory, from times when I tried to figure out the difference between :stdc and :stdc-stdcall. What it means for cffi is that there may come the day when defcfun needs another keyword to specify the name decoration, so as to be able to interface to library X. Then the cffi macro could add the "@N" to the given name itself, since it can compute the size of the arguments. That's my vision of things. Or cffi could delegate this to the underlying Lisp. AFAIK, Lispworks has some keywords for that difference. CLISP does not. Yet cffi still needs a keyword to be able to tell Lispworks whether to set the keyword or not... Regards, Jörg Höhle.