Using Python with COM to communicate with proprietary Windows software

[Joakim Persson]

Hello all. I am involved in a project where we have a desire to
improve our software testing tools, and I'm in charge of looking for
solutions regarding the logging of our software (originating from
embedded devices). Currently, we are using a heavyweight, proprietary
log tool developed by another part of the company. This tool contains
all "standard" logging functionality, but we also need to insert
"debug" log points in the software of the embedded device, and we
cannot get new releases of this big log tool very often (typically,
these debug log points might be very temporarily inserted into the
software during the development phase). 

Therefore, we have added a requirement to the log tool where we made
them implement a COM server in the log tool, so that we can access
arbitrary log points in the embedded device. My thoughts then, as
someone who wants to bring in more interpreted, lightweight languages
(and SW development processes) into the organization, was to use
Python to easily add log parsing and log presentation in different
ways. 

This means that I must come up with a way to interface Python with
this log tool. After some investigations, I have run inte problems --
my inital approach was to use Python + win32com to communicate with
the COM interface. Unfortunately, it seems as if win32com, even if I
makepy the log tool executable (which gives me the full range of
available functions of the interface, just as expected), cannot be
used, since the interface is not a simple IDispatch interface. Also, I
discovered that the Python client must also implement a COM server to
receive the log information as it is generated by the embedded device,
passed into the log tool and then sent by the log tool COM server. 

I have a rather bloated C++ client prototype which "works", so I
should have all the code needed to invoke the interface, but this
client is of course rather bloated in itself and not suitable for my
experimental programming approach. Am I right in believing that the
COM interface I am trying to use is of what is called a "custom" type,
that I cannot access using Python + win32com? I can use Python +
win32com just fine when accessing most normal COM servers (typical
example: MS Office programs implementing IDispatch interfaces), but I
cannot access the proprietary interface -- I get "interface not
supported"-type messages (I can query the CoClass for IUnknown and
IDispatch interfaces, but not using the known IID for the custom
interface). 

So, I'm trying to sum up my options. I have looked at Boost to try to
merge C++ and Python code, take care of the COM server/client creation
and messaging by the C++ part, and then take care of the data
processing/presentation part in Python, like so: 

+----+
|PRES| <-- Python and friends (wxPython could be interesting)
+----+
 ||||
+----+
|DATA| <-- Pure python
+----+
 ||||
+----+
|COM | <-- C++
+----+

... all linked together into, eventually, one Python executable
(linking in the C++ through a DLL which is then imported by Python). 

I haven't fully explored how to do this, but it seems as if Boost is
usable using MSVC++ (the organizations standard IDE) -- has anyone
tried something similar? My final idea is to "give up" on one single
program for this, and use a C++ intermediate program to communicate
with the log tool and then let it forward its data through sockets or
named pipes, which Python seems to deal with more easily. 

I have tried using Java + jawin as well just for a quick exploratory
spike, and ran into the same problems ("interface not supported" etc).
The jawin documentation talks a bit about wrapping the custom
interface into java objects, but this is rather obscure and
undocumented, and untangling it would take quite some time -- so I
figured that somebody could have done something similar in the past. 

Does anyone have any hints on how to go forward? The whole point with
my project is to demonstrate the usefulness of rapid prototyping using
Python (this has already been successful for smaller test tools, test
scripts and smaller intermediary programs), but I don't want something
like COM client/server obscurity getting in the way...

Thanks in advance, 

-- 
Joakim Persson
M.Sc student, CS/E @ LTH