[LuaJIT ffi] dynamic loading of DLL functions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[LuaJIT ffi] dynamic loading of DLL functions

Thomas Lauer-3
I am trying to call a few Win32 functions which may or may not be
present in the target DLL.

I've found no simple (ie fast) way to check whether a cdef'd function
has actually been found in the relevant namespace. ffi.typeof() etc all
seem to throw an error if the function name could not be resolved. Of
course, I could catch that but I'd assume this scenario is sufficiently
common to warrant some sort of API. Perhaps I did miss something
obvious?

--
cheers  thomasl

Reply | Threaded
Open this post in threaded view
|

Re: [LuaJIT ffi] dynamic loading of DLL functions

Mike Pall-29
Thomas Lauer wrote:
> I am trying to call a few Win32 functions which may or may not be
> present in the target DLL.
>
> I've found no simple (ie fast) way to check whether a cdef'd function
> has actually been found in the relevant namespace. ffi.typeof() etc all
> seem to throw an error if the function name could not be resolved. Of
> course, I could catch that but I'd assume this scenario is sufficiently
> common to warrant some sort of API. Perhaps I did miss something
> obvious?

pcall() is your friend. If you have millions of symbols to look
up, consider using GetProcAddress() instead (like you would in C).

--Mike

Reply | Threaded
Open this post in threaded view
|

Re: [LuaJIT ffi] dynamic loading of DLL functions

Thomas Lauer-3
Mike Pall <[hidden email]> wrote:

> Thomas Lauer wrote:
> > I am trying to call a few Win32 functions which may or may not be
> > present in the target DLL.
> >
> > I've found no simple (ie fast) way to check whether a cdef'd function
> > has actually been found in the relevant namespace. ffi.typeof() etc all
> > seem to throw an error if the function name could not be resolved. Of
> > course, I could catch that but I'd assume this scenario is sufficiently
> > common to warrant some sort of API. Perhaps I did miss something
> > obvious?
>
> pcall() is your friend. If you have millions of symbols to look
> up, consider using GetProcAddress() instead (like you would in C).

Yeah, that's how I'm doing it at the moment. But to throw this sort of
machinery on such a simple problem somehow just doesn't feel right, if
you know what I mean.

Anyway, it's not a million symbols, so it's gotta be alright, I guess.

--
cheers  thomasl