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