python - dll access (ctypes or swig)


D

Daniel Watrous

Hello,

I am interested in using python to script access to some hardware for
which there are existing drivers in the form of DLLs. The DLLs each
have four exported functions and a host of COM Properties and COM
Methods. The four exported functions are as follows:
DllCanUnloadNow
DllGetClassObject
DllRegisterServer
DllUnregisterServer

The COM methods and properties all begin with I, followed by a unique name.

I am able to load the DLL using ctypes and it can access the exported
functions, but I'm not sure how to access the COM methods and
properties. I have read that ctypes once had support for COM but that
it has since been separated into its own project. I couldn't find any
information about how these work together.

All help is appreciated. THANKS in advance...

Daniel
 
Ad

Advertisements

L

Larry Bates

Daniel said:
Hello,

I am interested in using python to script access to some hardware for
which there are existing drivers in the form of DLLs. The DLLs each
have four exported functions and a host of COM Properties and COM
Methods. The four exported functions are as follows:
DllCanUnloadNow
DllGetClassObject
DllRegisterServer
DllUnregisterServer

The COM methods and properties all begin with I, followed by a unique name.

I am able to load the DLL using ctypes and it can access the exported
functions, but I'm not sure how to access the COM methods and
properties. I have read that ctypes once had support for COM but that
it has since been separated into its own project. I couldn't find any
information about how these work together.

All help is appreciated. THANKS in advance...

Daniel

I recently learned that you can ship COM as either an .EXE or a .DLL (nobody
has yet let me know why). You don't have a traditional .DLL that you would
use ctypes to call methods in, you have a COM .DLL. COM methods need to be
access with Win32com

obj=win32com.client.Dispatch("typelib name").

You need to find out the COM dispatch typelib name and make sure the DLL is
registered (regsvr32 your.dll).

-Larry
 
L

Larry Bates

Daniel said:
Hello,

I am interested in using python to script access to some hardware for
which there are existing drivers in the form of DLLs. The DLLs each
have four exported functions and a host of COM Properties and COM
Methods. The four exported functions are as follows:
DllCanUnloadNow
DllGetClassObject
DllRegisterServer
DllUnregisterServer

The COM methods and properties all begin with I, followed by a unique name.

I am able to load the DLL using ctypes and it can access the exported
functions, but I'm not sure how to access the COM methods and
properties. I have read that ctypes once had support for COM but that
it has since been separated into its own project. I couldn't find any
information about how these work together.

All help is appreciated. THANKS in advance...

Daniel

I recently learned that you can ship COM as either an .EXE or a .DLL (nobody
has yet let me know why). You don't have a traditional .DLL that you would
use ctypes to call methods in, you have a COM .DLL. COM methods need to be
access with Win32com

obj=win32com.client.Dispatch("typelib name").

You need to find out the COM dispatch typelib name and make sure the DLL is
registered (regsvr32 your.dll).

-Larry
 
A

Alex Martelli

Larry Bates said:
recently learned that you can ship COM as either an .EXE or a .DLL (nobody
has yet let me know why).

The "why" is pretty obvious -- you may want to be able to instantiate a
COM object either in-process, or in its own separate process, depending
on that object's nature. For example, a complete application that when
running exposes COM objects to let other processes drive/script it will
be an EXE file since it can also run independently.

In general I'm no big fan of MS's design, but COM, despite its
imperfections, was in fact seriously good (Don Box's "Essential COM", an
excellent book, went just into enough depth to let a developer really
appreciate that, IMHO). I'm using the past tense because MS has been
trying to kill COM for a while now (but I notice that "Essential COM",
while 10 years-old, is _still_ in stock at Amazon -- so, I guess that so
far MS's attempts haven't _quite_ succeeded yet:).


Alex
 
C

Cameron Laird

I recently learned that you can ship COM as either an .EXE or a .DLL (nobody
has yet let me know why). You don't have a traditional .DLL that you would
use ctypes to call methods in, you have a COM .DLL. COM methods need to be
access with Win32com

obj=win32com.client.Dispatch("typelib name").

You need to find out the COM dispatch typelib name and make sure the DLL is
registered (regsvr32 your.dll).

-Larry

Is this--adroit use of Win32com with special-purpose DLLs--written
up anywhere? Doing this with unusual hardware that turns up in the
real world is ENTIRELY more satisfying than trying to wrangle the
Visual C bindings that vendors usually push, but, apart from Mark
and Andy's book, now over seven years old, I know of no appropri-
ately ambitious tutorial in the subject.

Daniel, do you have what you need to make progress? Have you seen
<URL: http://www.oreilly.com/catalog/pythonwin32/ >?
 
L

Larry Bates

Alex said:
The "why" is pretty obvious -- you may want to be able to instantiate a
COM object either in-process, or in its own separate process, depending
on that object's nature. For example, a complete application that when
running exposes COM objects to let other processes drive/script it will
be an EXE file since it can also run independently.

In general I'm no big fan of MS's design, but COM, despite its
imperfections, was in fact seriously good (Don Box's "Essential COM", an
excellent book, went just into enough depth to let a developer really
appreciate that, IMHO). I'm using the past tense because MS has been
trying to kill COM for a while now (but I notice that "Essential COM",
while 10 years-old, is _still_ in stock at Amazon -- so, I guess that so
far MS's attempts haven't _quite_ succeeded yet:).


Alex

I guess I was the only one it wasn't "obvious" to <grin>. I've always
written my COM servers as .EXE files even though they cannot be run
independently. What I find is "odd" is that I can create a .DLL or an
..EXE of my COM server and after I register it, my application doesn't
appear to know the difference. The difference seems to be hidden from
the actual application and doesn't affect it (at least that I can
determine).

I also think COM works quite well and I've found it much easier to use
than C-style DLLs that many vendors ship as their API. Most of what
I've learned came from Mark/Andy's Python Programming on Win32 and
trial-and-error so my knowledge is quite limited.

Thanks for the info.

Larry
 
Ad

Advertisements

D

Daniel Watrous

thank you for the responses and the links. I will give these ideas a
try this week and post again if I have more questions. Thanks again
for being so helpful!

Daniel
 
A

Alex Martelli

Larry Bates said:
I guess I was the only one it wasn't "obvious" to <grin>. I've always
written my COM servers as .EXE files even though they cannot be run
independently. What I find is "odd" is that I can create a .DLL or an
.EXE of my COM server and after I register it, my application doesn't
appear to know the difference. The difference seems to be hidden from
the actual application and doesn't affect it (at least that I can
determine).

Yes, except for performance (a DLL affords within-process communication
without the overhead of IPC, so it can be much faster when appropriate)
and some technical issues such as threading (if COM client and server
are in separate processes, their threading models are independent from
each other; if they are in the same process, they'd better have
compatible threading approaches -- a thread-unsafe DLL server can make a
single-threaded client happy but would cause problems and crashes if a
freely-threaded client tried using it).


Alex
 
T

Thomas Heller

Alex said:
Yes, except for performance (a DLL affords within-process communication
without the overhead of IPC, so it can be much faster when appropriate)
and some technical issues such as threading (if COM client and server
are in separate processes, their threading models are independent from
each other; if they are in the same process, they'd better have
compatible threading approaches -- a thread-unsafe DLL server can make a
single-threaded client happy but would cause problems and crashes if a
freely-threaded client tried using it).

I think that the latter problem (incompatible threading models in the same
process) are solved by COM apartments - aren't they?

Thomas
 
Ad

Advertisements

A

Alex Martelli

Thomas Heller said:
...
I think that the latter problem (incompatible threading models in the same
process) are solved by COM apartments - aren't they?

"apartment" is one threading model, but it still means that your
application and your in-process server must be compatible with it
(again, we're discussing the fact that out-of-process servers, at a
performance price, can do away with these minor limitations).


Alex
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top