ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes

[Mike Hearn]

Heya,

First of all 'mad propz' to you for tackling this. I have no strong
opinion on whether this approach of hijacking a thread is better than
having a service thread, that's Alexandres call. But a few comments on the
way you've done things here:

I don't think there's any reason to use Linux specific syscalls
to do this. IMHO it can probably be done using only Wine provided APIs and
infrastructure.

I am not how this works. You create a new "raw" kernel thread
using clone, then run NT code using it. But that isn't valid and may not
work - only threads created by Wine may use Win32.

You are using ptrace instead of signals. That seems over complex -
signals are designed to interrupt a thread and have the necessary support
to restart syscalls, preserve registers etc. I know both SIGUSRs are taken
but SIGUSR2 is currently used for the DOSVM which Alexandre wants to
change. You could disable it for your tests, and anyway if it comes to the
crunch SIGUSR2 can always be multiplexed.

You don't preserve the register state. This is something you get for free
with signals, but you'd need to use a register function if you want to do
it outside a signal handler.

There seems to be a race condition - if the main thread is in the
middle of shutting down you might be able to hijack it just as it's about
to exit(), at which point the newly created sacrificial
thread will also be torn down, leaving CreateRemoteThread hung. It could
also cause the newly created thread to try and communicate with the
wineserver after it's been disconnected.

A service thread seems like a cleaner solution in general but if I were
you I'd take this further by using SIGUSR2 to do the remote thread
creation. Alternatively, you might be able to suspend the remote thread
and queue an APC to it.

thanks -mike

On Fri, 14 Jul 2006 19:59:51 -0700, Thomas Kho wrote:
> ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes
> 
> Greetings,