ntdll: CreateRemoteThread and RtlCreateUserThread for
remote processes, take 2
mike at plan99.net
Wed Aug 2 17:42:35 CDT 2006
On Tue, 01 Aug 2006 20:41:54 -0500, Thomas Kho wrote:
> This is an implementation of CreateRemoteThread and RtlCreateUserThread for
> remote processes that re-introduces a service thread for each process and uses
> a signal to flag pending operations. Operations are guarded by a global mutex
> for each process.
Hey, great, this is a big improvement on last time.
Still I have a few questions about the approach:
- The service thread seems like a good idea to me. But why use a signal
in this case, when there are simpler ways to achieve the same thing,
for instance with a named pipe?
- I'm not sure using the realtime signals will work. I don't remember
the details, Alexandre is the signals guru, but I remember them being
- There is a lot of stuff to handle the global mutex. Why is this
necessary? I'm afraid I really don't see where the lock is needed
here; if you were using a pipe then the service thread would
serialize the requests in its main loop
- Writing to a remote process by taking the address of a variable
in the current one?! What if the DLLs are located at different
base addresses? I know this is unlikely to happen in Windows but
on Linux we have ASLR and they introduced this for Vista as well.
Assuming a pointer that is valid in one process is also valid in
another is not a good idea, in general.
And there are a few small style nits, for instance there's usually
no reason to change "void *foo" to "void *foo = NULL", you want it
to remain uninitialized because that way the compiler will warn if
it's ever used before being set to something: superior to blindly
using a NULL ptr with no warning I'm sure you'll agree.
Also watch the code style - internally Wine tends to use unix_style
not hungarian notation, which is usually confined to the API definition
Anyway, assuming Alexandre concurs with what I've said, here's where you
want to go next:
* Drop the signal, and use a named pipe instead
* This should let you drop the global mutex and WriteProcessMemory calls,
More information about the wine-devel