Possible fix idea for NtProtectVirtualMemory
tkho at ucla.edu
Tue Oct 10 19:36:06 CDT 2006
On 10/10/06, Segin <segin2005 at gmail.com> wrote:
> It took some good hydro from Holland and about 6 hours of trying to
> write a program that could syncronize multiple instances of itself using
> IPC and signals (so it could run on Minix 3, where pthreads sadly
> doesn't exist, so it was a threading hack of sorts) to come up with a
> possible fix for the cross-process problem with NtProtectVirtualMemory.
> The solution: Use signals.
> It's really simple to explain (I wouldn't know where to begin with
> actually coding it, pointers would help). Since the
> NtProtectVirtualMemory call is only supported by the current process,
> use wineserver and software signals to allow a bit of a cross-process hack.
> When the individual Win32 process client recieves a certain signal (ohh,
> for now, say SIGUSR2), the client would break the Win32 code, call up
> wineserver for the parameters (and silently ignore if it's a false
> signal, e.g. lame user trying to use `kill -USR2'), preform the required
> operations itself, and then resume executing the Win32 process.
> Does this sound like a good hack or what?
I was wrestling with this over the summer, but alas, school got in the
way before it got "good enough." Check out
http://wiki.winehq.org/RemoteProcessOperations (the page history might
be useful--Dan recently removed some info.)
Basically, Wine already uses signals for some things, and
piggy-backing these operations on the current mechanism is doable
should be done in the coming months.
More information about the wine-devel