Passing DLL handle as an argument (in Windows)

[Pekka Kytölä]

Is it possible to pass my own dll's (already loaded) handle as an
argument to load/attach to the very same instance of dll? Thing is
that I've done plugin (dll) to a host app and the SDK's function
pointers are assigned once the dll is loaded in the host process. I'd
like to fire up python code with ShellExecuteEx from my plugin dll and
expose (wrap) these SDK funcs to that script. If I just load the dll
in python it will be different instance and the SDK function pointers
are all NULL. I tried passing the dll handle as lpParameter but in
vain.

Is this ShellExecute + dll handle passing even possible or do I need
to take a totally different route? What route that would be? Doesn't
have to be portable, just so it works in Windows environment.

 

[Ulrich Eckhardt]

Am 18.11.2011 08:51, schrieb Pekka Kytölä:

Is it possible to pass my own dll's (already loaded) handle as an
argument to load/attach to the very same instance of dll? Thing is
that I've done plugin (dll) to a host app and the SDK's function
pointers are assigned once the dll is loaded in the host process.

DLL handles are valid anywhere in a process, but...

I'd like to fire up python code with ShellExecuteEx from my plugin
dll and expose (wrap) these SDK funcs to that script. If I just load
the dll in python it will be different instance and the SDK function
pointers are all NULL. I tried passing the dll handle as lpParameter
but in vain.

....ShellExecuteEx will create a new process, where the DLL handle is not
valid. A new process has a separate memory space, so the function
pointers are different etc. This is so by design, it shouldn't matter to
one process when a DLL it uses is loaded into another process, too.

Is this ShellExecute + dll handle passing even possible or do I need
to take a totally different route? What route that would be? Doesn't
have to be portable, just so it works in Windows environment.

If all you want is to run Python code inside your application, you can
link in a Python interpreter and run it from there. This is called
embedding Python (docs.python.org/extending/embedding.html), as opposed
to writing Python modules, don't confuse those two Python C APIs.

Another way to get both into the same process is to convert your host
application into a Python module, which you then import into Python.
This would use the other Python C API
(docs.python.org/extending/extending.html).


It depends a bit on what you want to achieve, so you might want to
elaborate on that. This is often better than asking for a way to achieve
a solution that is impossible.


Good luck!

Uli

 

[Pekka Kytölä]

Am 18.11.2011 08:51, schrieb Pekka Kytölä:


DLL handles are valid anywhere in a process, but...


...ShellExecuteEx will create a new process, where the DLL handle is not
valid. A new process has a separate memory space, so the function
pointers are different etc. This is so by design, it shouldn't matter to
one process when a DLL it uses is loaded into another process, too.


If all you want is to run Python code inside your application, you can
link in a Python interpreter and run it from there. This is called
embedding Python (docs.python.org/extending/embedding.html), as opposed
to writing Python modules, don't confuse those two Python C APIs.

Another way to get both into the same process is to convert your host
application into a Python module, which you then import into Python.
This would use the other Python C API
(docs.python.org/extending/extending.html).

It depends a bit on what you want to achieve, so you might want to
elaborate on that. This is often better than asking for a way to achieve
a solution that is impossible.

Good luck!

Uli

Thanks for reply, I'll try to elaborate a bit

I should have included this bit from:

http://docs.python.org/library/ctypes.html#loading-shared-libraries

"All these classes can be instantiated by calling them with at least
one argument, the pathname of the shared library. If you have an
existing handle to an already loaded shared library, it can be passed
as the handle named parameter, otherwise the underlying platforms
dlopen or LoadLibrary function is used to load the library into the
process, and to get a handle to it."

So, I've got this handle to my .dll and would want to get that passed
as an argument when firing up .py via ShellExecute and use one of the
dll load functions that take in handle. What I don't know if these
windows/python dll handles are interchangable at all. Think it would
be quite nice if they were. But if they aren't I need to forget about
it and just #include <Python.h>

 

[Pekka Kytölä]

Hmm. Let me describe what is going a bit more carefully:

What I build is a dll file that has exported function that gets called
when the host application/dll loads my dll. In this function the
function pointers to the actual SDK functions are fetched. After this
my dll's registers some plugins that have callbacks. After that it's
all about reacting to an event/callback. What I'd like to do is that
after fetching those SDK function pointers I'd like to fire
up .py/.pyc that snoops for possible plugins written in python and
registers those plugins and callbacks and let them react to events.
Obviously this python code needs access to those SDK functions.
Essentially it would show for the host app as one .dll but registers
multiple plugins from different python files.

I don't mind if it's not ShellExecute route, but I'd prefer
approaching this so that I don't need to compile different dll's to
different versions of python but let the python code take care of that
stuff.

 

[Ulrich Eckhardt]

Am 18.11.2011 12:49, schrieb Pekka Kytölä:

What I'd like to do is that after fetching those SDK function
pointers I'd like to fire up .py/.pyc that snoops for possible
plugins written in python and registers those plugins and callbacks
and let them react to events. Obviously this python code needs access
to those SDK functions. Essentially it would show for the host app as
one .dll but registers multiple plugins from different python files.

Okay, so you want to export functions from your host application (it
doesn't matter if that is inside a DLL or not) to a bunch of Python
plugins. This is actually the embedding that I hinted at and documented,
but here's some example code (stripped of any error handling and
reference counting, so beware!):

// append line to debug log
static PyObject*
log_string(PyObject *self, PyObject *args)
{
char const* arg = 0;
if(!PyArg_ParseTuple(args, "s", &arg))
return NULL;

fprintf(debug_output, "%s", arg);
Py_RETURN_NONE;
}

// exported API
static PyMethodDef host_api[] =
{
{"log_string", log_string, METH_VARARGS,
"log_string(string) -> None\n"
"Write text to debug output."},
{NULL, NULL, 0, NULL}
};

Py_Initialize();
PyObject* host_api_module = Py_InitModule("host", host_api);
PyObject* test_module = PyImport_ImportModule("./test.py");
PyObject* main_function = PyObject_GetAttrString(test_module, "main");
PyObject* res = PyObject_CallObject(main_function, NULL);
Py_Finalize();


This has the disadvantage that it blocks, for multiple Python threads,
you need to program a dispatcher. Also, you can only have a single
interpreter loaded, so other parts of your program may not call
Py_Initialize().

It does the job for my uses, so I hope it helps!

Uli