ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes

[Dan Kegel]

On 7/16/06, Mike Hearn <mike at plan99.net> wrote:
> Well, I think calling CreateThread directly from the context of the
> hijacked thread would be simpler, though I understand that gets hairy
> as well if the hijacked thread is holding (say) the loader lock

I'd rather not take the chance of doing anything that messes with the
poor thread we're hijacking.    Hmm... http://lwn.net/Articles/7577/ makes
me think that converting a linux thread to a win32 thread might
require initializing the thread's TLS area.  We'll look at that a bit.

> > Well, kind of.  Signals are only delivered when syscalls return, so
> > they won't work well if the thread you pick to molest happens to
> > not make any syscalls for a long time.
>
> Hm, really? I haven't come across this before ... how then is it
> possible to debug a program that is sitting in while(1); if SIGSTOP
> cannot be delivered?

The magic of ptrace().

> > Well, if Alexandre thinks that's the way to go, that'd be fine.
> > I thought those only fired when the thread in question performed
> > an alertable wait condition (so says
> > http://msdn.microsoft.com/library/en-us/dllproc/base/queueuserapc.asp )
> > so it didn't seem like an obvious way to go.
>
> Right but if the thread is suspended then it's waiting, and we could
> maybe hack it to do an alertable wait. Though doing an alertable wait
> during a suspend is surely the wrong thing to do in most cases,
> presumably the server could easily queue an APC itself but not allow
> other clients to do the same.

That sounds a bit invasive, but if Alexandre prefers it, fine.
- Dan