Time to commit remote ops for VirtualAllocEx, CreateRemoteThread

[Eric Pouech]

Dan Kegel wrote:

> On 8/5/06, Eric Pouech <eric.pouech at wanadoo.fr> wrote:
>
>> >> Still, doing that stuff in APCs is a step in the right direction, you
>> >> just need to make sure you can safely run these APCs from the SIGUSR1
>> >> handler.
>> >
>> > Do we have to verify that now, or can that wait until we want
>> > to add support for debuggers?
>>
>> Most of the *serious* debuggers I know of make use of remote virtual
>> functions. This includes WineDbg, WinDbg (the MS one)...
>> - WinDbg (the MS debugger)
>
>
> Installer doesn't work:
> http://bugs.winehq.org/show_bug.cgi?id=5866
> (not a showstopper, but does make it harder to test with)
>
>> - WineDbg
>
>
> Where?  I just looked:
> dank at lappy:~/wine-git/programs/winedbg$ grep CreateRemote *.c
> dank at lappy:~/wine-git/programs/winedbg$ grep VirtualAlloc *.c
> dank at lappy:~/wine-git/programs/winedbg$
>
>> - gdb (when compiled on Windows)
>
>
> I just peeked, and vanilla gdb-6.4 doesn't contain the string
> CreateRemoteThread.
> Some old version of 'gdb-next' did, though, but the only mention of it
> I can find is here:
> http://darwinsource.opendarwin.org/DevToolsDec2001/gdb-203/src/gdb-next/winpdo-nat.c 
>
>
> Got a place one can grab working sources + binary for a gdb that does
> use CreateRemoteThread?
> - Dan
>
>
I was talking (at least) about VirtualQueryEx, which should be also 
implemented. All the debuggers use it for memory inspection.
Some of the debuggers use VirtualAllocEx for some nice features (like 
calling a function in the debuggee), and they use the created space to 
push some values to be used for those specific functions (and also 
inject code the same way).

A+