Re: Special use case for ctypes
Zak Smolen <[email protected]> Fri, 5 May 2017 13:21:13 -0400
| Newsgroups | gmane.comp.python.ctypes |
|---|---|
| Message-ID | <CAODUn57PzMncpBEw3ZsAmhpYvOF29qLp+yB=6t2Axo17qASXnA@mail.gmail.com> |
--===============1276931717443543692== Content-Type: multipart/alternative; boundary=001a113cdd2ece5584054eca1d17 --001a113cdd2ece5584054eca1d17 Content-Type: text/plain; charset=UTF-8 Huh, I always heard of Python for .NET as Python consuming a .NET DLL but it looks like the reverse is true as well. And it looks like it works with numpy according to their example code (IronPython doesn't really work with most of the science/math libs). I'll give that a go before I try accessing python DLLs. On Fri, May 5, 2017 at 12:45 PM, Zak Smolen <[email protected]> wrote: > Thanks for that clarification. Yeh it really seems like the only way to > truly get this to work is if it all happens from the same process. I'll > look into including python and see if that method works. Looking at my > code, my method of calling the python was in a new process, so that would > never really work. > > On Fri, May 5, 2017 at 10:52 AM, eryk sun <[email protected]> wrote: > >> On Fri, May 5, 2017 at 1:52 PM, Zak Smolen <[email protected]> wrote: >> > So my thought behind this is that it must be possible... somehow, >> because of >> > debuggers. You can attach a debugger to an existing process and see it's >> > memory and such. I don't need simultaneous access from both the C# >> wrapper >> > and the python at the same time. I can have the C# not touch the C >> while the >> > python is running. It looks like debuggers do things with signals and >> such. >> >> Reading the memory of a process like a debugger is not much of a >> programming interface. ReadProcessMemory [1] requires a process handle >> with VM read access (e.g. your Python script would need a handle for >> the C# process). It's implemented by having the memory manager attach >> to the process, map the target address range into kernel space, and >> then attach to your process and copy that data to your buffer. >> WriteProcessMemory [2] requires a handle with VM write and operation >> access, and it's implemented in the opposite direction: map your >> buffer to kernel space and then attach to the target process and write >> the data at the target address. Considering these two address spaces >> are unrelated, you'd need some IPC scheme to send the base address to >> the process that wants to read from or write to memory in your >> process. >> >> If you want a section of shared memory, the DLL has to be designed >> around it from the start. As far as the code in the DLL is concerned >> it's just reading from and writing to a global variable at an address >> in the current process. But under the hood the pages (typically 4 KiB >> each) are shared with every process that loads the DLL, so they all >> access the same data. >> >> The alternative is to embed CPython in your .NET application. If >> Python for .NET is hosted out of process, then yes it will be a >> separate DLL instance. But you could still investigate directly >> loading pythonXX.dll in your process to run the interpreter and have >> ctypes (for whatever reason you need to do this in Python instead of >> C#) access the DLL in your current process. >> >> [1]: https://msdn.microsoft.com/en-us/library/ms680553 >> [2]: https://msdn.microsoft.com/en-us/library/ms681674 >> > > --001a113cdd2ece5584054eca1d17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Huh, I always heard of Python for .NET as Python consuming= a .NET DLL =C2=A0but it looks like the reverse is true as well. And it loo= ks like it works with numpy according to their example code (IronPython doe= sn't really work with most of the science/math libs). I'll give tha= t a go before I try accessing python DLLs.</div><div class=3D"gmail_extra">= <br><div class=3D"gmail_quote">On Fri, May 5, 2017 at 12:45 PM, Zak Smolen = <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a>></span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"><div dir=3D"ltr">Thanks for that clarification. Yeh it really seems li= ke the only way to truly get this to work is if it all happens from the sam= e process. I'll look into including python and see if that method works= . Looking at my code, my method of calling the python was in a new process,= so that would never really work.</div><div class=3D"HOEnZb"><div class=3D"= h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, May 5= , 2017 at 10:52 AM, eryk sun <span dir=3D"ltr"><<a href=3D"mailto:eryksu= [email protected]" target=3D"_blank">[email protected]</a>></span> wrote:<br><= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><span>On Fri, May 5, 2017 at 1:52 PM, Zak Smo= len <<a href=3D"mailto:[email protected]" target=3D"_blank">zaksmolen@= gmail.com</a>> wrote:<br> > So my thought behind this is that it must be possible... somehow, beca= use of<br> > debuggers. You can attach a debugger to an existing process and see it= 's<br> > memory and such. I don't need simultaneous access from both the C#= wrapper<br> > and the python at the same time. I can have the C# not touch the C whi= le the<br> > python is running. It looks like debuggers do things with signals and = such.<br> <br> </span>Reading the memory of a process like a debugger is not much of a<br> programming interface. ReadProcessMemory [1] requires a process handle<br> with VM read access (e.g. your Python script would need a handle for<br> the C# process). It's implemented by having the memory manager attach<b= r> to the process, map the target address range into kernel space, and<br> then attach to your process and copy that data to your buffer.<br> WriteProcessMemory [2] requires a handle with VM write and operation<br> access, and it's implemented in the opposite direction: map your<br> buffer to kernel space and then attach to the target process and write<br> the data at the target address. Considering these two address spaces<br> are unrelated, you'd need some IPC scheme to send the base address to<b= r> the process that wants to read from or write to memory in your<br> process.<br> <br> If you want a section of shared memory, the DLL has to be designed<br> around it from the start. As far as the code in the DLL is concerned<br> it's just reading from and writing to a global variable at an address<b= r> in the current process. But under the hood the pages (typically 4 KiB<br> each) are shared with every process that loads the DLL, so they all<br> access the same data.<br> <br> The alternative is to embed CPython in your .NET application. If<br> Python for .NET is hosted out of process, then yes it will be a<br> separate DLL instance. But you could still investigate directly<br> loading pythonXX.dll in your process to run the interpreter and have<br> ctypes (for whatever reason you need to do this in Python instead of<br> C#) access the DLL in your current process.<br> <br> [1]: <a href=3D"https://msdn.microsoft.com/en-us/library/ms680553" rel=3D"n= oreferrer" target=3D"_blank">https://msdn.microsoft.com/en-<wbr>us/library/= ms680553</a><br> [2]: <a href=3D"https://msdn.microsoft.com/en-us/library/ms681674" rel=3D"n= oreferrer" target=3D"_blank">https://msdn.microsoft.com/en-<wbr>us/library/= ms681674</a><br> </blockquote></div><br></div> </div></div></blockquote></div><br></div> --001a113cdd2ece5584054eca1d17-- --===============1276931717443543692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot --===============1276931717443543692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ctypes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ctypes-users --===============1276931717443543692==--