[EMAIL PROTECTED] (Thomas Kho) writes:
> diff --git a/dlls/kernel/tests/Makefile.in b/dlls/kernel/tests/Makefile.in
> index bfeae14..5f6c12e 100644
> --- a/dlls/kernel/tests/Makefile.in
> +++ b/dlls/kernel/tests/Makefile.in
> @@ -3,7 +3,7 @@ TOPOBJDIR = ../../..
> SRCDIR= @srcdir@
> VPATH
On Sat, 05 Aug 2006 10:32:15 +0200, Alexandre Julliard 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.
How is the thread to interrupt to be selected? I really am not seeing
what's wron
Dan Kegel wrote:
On 8/5/06, Eric Pouech <[EMAIL PROTECTED]> wrote:
I was talking (at least) about VirtualQueryEx, which should be also
implemented. All the debuggers use it for memory inspection.
FWIW, an implementation for Linux was posted at
http://www.winehq.org/pipermail/wine-devel/2002
Dan Kegel kegel.com> writes:
>
> On 8/5/06, Eric Pouech wanadoo.fr> wrote:
> > I was talking (at least) about VirtualQueryEx, which should be also
> > implemented. All the debuggers use it for memory inspection.
>
> FWIW, an implementation for Linux was posted at
> http://www.winehq.org/piperm
On 8/5/06, Eric Pouech <[EMAIL PROTECTED]> wrote:
I was talking (at least) about VirtualQueryEx, which should be also
implemented. All the debuggers use it for memory inspection.
FWIW, an implementation for Linux was posted at
http://www.winehq.org/pipermail/wine-devel/2002-July/007482.html
Per
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
On 8/5/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
On 8/5/06, Eric Pouech <[EMAIL PROTECTED]> 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 n
On 8/5/06, Eric Pouech <[EMAIL PROTECTED]> 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 de
Dan Kegel wrote:
On 8/5/06, Alexandre Julliard <[EMAIL PROTECTED]> 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
On 8/5/06, Alexandre Julliard <[EMAIL PROTECTED]> 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 debugger
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> So all you have to do is identify all the locks that your APCs
> might need to acquire, and verify that they are always acquired
> in the same order by all possible code paths.
> (Or did I miss something, Alexandre?)
Well, you are right that running APCs
On 8/4/06, Thomas Kho <[EMAIL PROTECTED]> wrote:
> > Tommy's APC version of his
> > VirtualAllocEx / CreateRemoteThread patch
> > seems to be safe (since APCs only run a points where threads
> > in well-written programs are not holding locks),
>
> Unfort
On 8/4/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> Tommy's APC version of his
> VirtualAllocEx / CreateRemoteThread patch
> seems to be safe (since APCs only run a points where threads
> in well
On 8/4/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Tommy's APC version of his
> VirtualAllocEx / CreateRemoteThread patch
> seems to be safe (since APCs only run a points where threads
> in well-written programs are not holding locks),
Unfortunately there'
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> Tommy's APC version of his
> VirtualAllocEx / CreateRemoteThread patch
> seems to be safe (since APCs only run a points where threads
> in well-written programs are not holding locks),
Unfortunately there's no s
Tommy's APC version of his
VirtualAllocEx / CreateRemoteThread patch
seems to be safe (since APCs only run a points where threads
in well-written programs are not holding locks),
is complete enough to make many apps happy,
and is probably the best that can be done without
a service thread
rrectly. This is why VirtualAllocEx is not implemented yet...
--
Alexandre Julliard
[EMAIL PROTECTED]
Has there been any work on VirtualAllocEx for allocating memory
to other processes?
I would like to get this going to allow me to run mta:vc and blow
away other people in gta vice city (I believe that is a noble
cause).
To get me started I have a question.
Is there a mechanism for one wine
18 matches
Mail list logo
