ntdll: CreateRemoteThread and RtlCreateUserThread for remote processes, take 2

[Mike Hearn]

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
   "awkward"

 - 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
itself.

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,
   I think?

thanks -mike