Re: Special use case for ctypes

--===============7457104622332464215==
Content-Type: multipart/alternative; boundary=001a113d3c6adfc3a2054ec99d13

--001a113d3c6adfc3a2054ec99d13
Content-Type: text/plain; charset=UTF-8

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
>

--001a113d3c6adfc3a2054ec99d13
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for that clarification. Yeh it really seems like th=
e only way to truly get this to work is if it all happens from the same pro=
cess. I&#39;ll look into including python and see if that method works. Loo=
king at my code, my method of calling the python was in a new process, so t=
hat would never really work.</div><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=
">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">eryksun@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"=
">On Fri, May 5, 2017 at 1:52 PM, Zak Smolen &lt;<a href=3D"mailto:zaksmole=
[email protected]">[email protected]</a>&gt; wrote:<br>
&gt; So my thought behind this is that it must be possible... somehow, beca=
use of<br>
&gt; debuggers. You can attach a debugger to an existing process and see it=
&#39;s<br>
&gt; memory and such. I don&#39;t need simultaneous access from both the C#=
 wrapper<br>
&gt; and the python at the same time. I can have the C# not touch the C whi=
le the<br>
&gt; 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&#39;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&#39;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&#39;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&#39;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>

--001a113d3c6adfc3a2054ec99d13--


--===============7457104622332464215==
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
--===============7457104622332464215==
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

--===============7457104622332464215==--