Mike Hearn <[EMAIL PROTECTED]> writes:
> Ick. OK, how about implementing them using a SuspendThread call, so we
> can use SIGUSR1 for both? Would suspending the thread, altering the
> context, then resuming it in a blocking fashion give close enough
> behaviour to what the apps expect?
This could
Alexandre Julliard wrote:
Well, you'll be surprised. In the general case the results may well be
unpredictable but there are lots of cases where they are perfectly
predictable, and some apps do rely on that.
Ick. OK, how about implementing them using a SuspendThread call, so we
can use SIGUSR1 for
Alexandre Julliard wrote:
What makes you think that? There is no such restriction in the API,
you can get/set the context without suspending the thread. The
obvious use case is a thread setting its own context.
Hmm, you must know something I don't :)
MSDN (I know, I know ...) says:
"You cannot ge
Hi Alexandre,
A user recently reported another app that doesn't work due to Armadillo
copy protection. This scheme requires SetThreadContext/GetThreadContext to
work properly and currently they do not.
These two functions require the thread to be suspended, therefore they
always return a bogus co
