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.