Alf P. Steinbach wrote:
* Dave Angel:
Stefan Behnel wrote:
<div class="moz-text-flowed" style="font-family:
-moz-fixed">mikelisa...@gmail.com, 17.03.2010 10:08:
Its interesting you've mentioned the hard work involved in this
interface (binding to an EXE instead of a DLL). A year or more ago I
was looking at interfacing IPMITOOL to python. Do to the problems
incurred with swig/python I switched to a running the process through
its command-line interface. I always felt the problems in interfacing
python to an EXE should be worked on (to minimize them), making the
direct use of an EXE API's a routine task. I understand some of the
problems using an EXE (not running all of its startup code but
enough for its proper operation). Have you found this a recurring
question? Thanks.
I think the point here is that executable binaries are not supposed
to be used as libraries. Libraries are. That's the difference
between a DLL and an executable in the first place. To run an
executable, execute it. The subprocess module is the tool of choice
here. To use a DLL, link against it.
Stefan
There's no real reason parts of an exe cannot be exported, same as a
dll. They are in fact the same structure. And in fact many other
files in the Windows environment are also the same structure, from
fonts to ocx's
Saying they're "not supposed to be used" is like saying that a python
module should not have an
if __name__ == "__main__":
section. After all, who could want to both run a file, and import
the same file??
A Windows DLL has defined initialization and cleanup per process and
per thread.
This means that e.g. static variables can be properly initialized when
you load the DLL in order to use its functions (I'm skipping
discussion of subtle problems, but that's the essence).
A Windows EXE has (only) a single entry point which is for process
startup. It invokes the EXE's behavior-as-a-program. There is no way
to use it to e.g. initialize static variables in order to use exported
functions.
Hence Mike Lisanke's idea of "not running all of its startup code but
enough for its proper operation" is generally not possible.
An EXE can be used as a kind of server, /if/ it is designed for that.
In particular it can be a COM server, allowing access of its
functionality from any COM-enabled binding, which for Python would
mean OLE Automation (COM, OLE, Automation: this is Microsoft
technology, we're talking Windows EXEs here). But a Python binding to
EXEs in general can't, as far as I can see, make assumptions about any
particular kind of server being implemented by the EXE.
Cheers & hth.,
- Alf
I'm not talking about COM servers, which run in a separate process.
Only about calling functionality that happens to be encoded in an .EXE file.
You're trying to generalize what I said. I never said you could call
into any .EXE file, just that calling into one is not infeasible.
You're describing using an .EXE written using the Microsoft C compiler
and/or libraries, not a Windows .EXE in general. In any case, whenever
you link to a module written in a different environment, you'll have
restrictions. Chief among them is the use of a compatible memory model,
the stack conventions, the allocators, and so on.. Solving the thread
issue is probably the easiest one to fix.
I'm not recommending it, just refuting the "not supposed to" quote above.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
