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,