[cffi-devel] Re: calling a function of the same name from two DLLs

[Hoehle, Joerg-Cyril]

Hi,

>> This is one of the things that UFFI still handles better.
Indeed.
>I believe most/many/some lisp implementations ignore the 
>:MODULE in UFFI.
Only those that only work on UNIX, where a name is mapped to one address
in the process space (and shadowing by precedence (order of opening
libraries) rules apply).
Not so on MS-Windows, as Jack Unrue shows: each library may export a
function of a given name, and they could be the same (even more so with
COM and interfaces: all subscribers provide the function of the name
mandated by the interface).

IIRC, Yaroslav Kavenchuk once had a case where calling the function in
the wrong library caused a crash.

Some Lisp implementations, when porting from UNIX to MS-Windows,
preserved
their UNIX API and threw in ad hoc behaviour: e.g. given no :library,
scan
the open ones in some order.  That's why even on MS-Windows, where
naming
the correct library can be of utter importance, that argument may not be
required or even available.  This approach is good enough for many
programs
to work.

I've said for years now that the :library/:module thing is important.
Alas,
if one has a UNIX-centric view, one fails to recognize the value of this
parameter -- which reminds me of a comment from Kent Pitman in cll some
years ago.

Jack, you must roll your own.  Luckily, you can do so.  Use CFFI as soon
as you get the address (pointer) of the function in the library that is
of interest to you.  Given that pointer, CFFI provides enough glue
to be able to construct (call) a foreign function out of it, e.g.
foreign-funcall-pointer.  Also, use CFFI to obtain that pointer
(via GetProcAddress() if all else fails).

Or use #+ to write native def-call-out forms for several Lisps that
support
the library argument?

Regards,
	Jorg Hohle.