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