Python bindings tutorial
in [Python]
|
Prev: cycling through options
Next: Timer
From: MikeLisanke on 17 Mar 2010 05:08 On Mar 16, 3:12 pm, "Gabriel Genellina" <gagsl-...(a)yahoo.com.ar> wrote: > En Tue, 16 Mar 2010 13:20:40 -0300, Johny <pyt...(a)hope.cz> escribió: > > > Is there any tutorial how to write a bindings for a exe ( dos) > > program? > > I would like to run it from a Python directly > > ( using import command and a particular function from the binding) > > not using os.system command. > > Do you mean that you want to execute a particular function in the .exe > program? > That's not possible (ok, you *could* do that if you work hard enough, but > that's not how things are usually done) > > -- > Gabriel Genellina Gabriel, 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. Regards, Mike
From: Stefan Behnel on 17 Mar 2010 05:36 MikeLisanke(a)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
From: Dave Angel on 17 Mar 2010 07:14 Stefan Behnel wrote: > <div class="moz-text-flowed" style="font-family: > -moz-fixed">MikeLisanke(a)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?? DaveA
From: Alf P. Steinbach on 17 Mar 2010 08:03 * Dave Angel: > Stefan Behnel wrote: >> <div class="moz-text-flowed" style="font-family: >> -moz-fixed">MikeLisanke(a)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
From: Stefan Behnel on 17 Mar 2010 08:18
Dave Angel, 17.03.2010 12:14: > Stefan Behnel wrote: >> 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. >> > 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 So, because you can, you'd also try to link against fonts then, I guess? I hope you notice that what you and me said isn't contradictory. But there's a reason why there are libraries and executables, and there's no reason you *should* export anything from an executable - that's what libraries are there for. That's my point. Besides, nothing guarantees that it's safe to call stuff that an executable exports. The executable may well require some setup code that it only executes when it is properly started. Stefan |