python - dll access (ctypes or swig)

[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

 

[Larry Bates]

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

 

[Larry Bates]

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

 

[Alex Martelli]

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

 

[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/ >?

 

[Larry Bates]

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

 

[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

 

[Alex Martelli]

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

 

[Thomas Heller]

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

 

[Alex Martelli]

...
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