eading 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
r 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 wineserv
On Fri, Apr 07, 2006 at 11:47:08AM +0200, Stefan Dösinger wrote:
> I think we need to set the context before the first gl call in a thread. It
> should be enought to do a ckeck in ENTER_GL() if a context is set for the
> current thread, and if not create one and set it.
Yeah, check as soon as yo
Hi,
> If we add 'intelligent' (i.e. 'lazy' or 'just in time' :-) ) state change
> evaluation it could even be pretty efficient code-wise (maybe not so
> efficient in the GL driver though as it may lead to more 'pipeline flushes'
> than the 'hacky' solution).
I think we need to set the context befor
On Thu, Apr 06, 2006 at 10:23:11AM +0200, Stefan Dösinger wrote:
> That would be usefull too for multithreaded direct3d. Somehow we have to
> bring
> another thread to releasing the glxContext, so we can re-use it in a new
> thread.
After discussing this at length on IRC with another coder, we
> The wineserver would have to trigger some code in the client, either by
> having a signal or a generic background thread that could do it on behalf
> of the other process.
>
> Such a scheme has been discussed before for things like CreateRemoteThread
> and friends.
That would be usefull too for
On Wed, 05 Apr 2006 19:06:41 -0400, Segin wrote:
> Hmm... Intresting. I am going to assume, from what I have seen, that
> emulated Win32 processes have a represenative POSIX process. Is it
> possible to implement a lookup table of sorts to make it work cross-process?
The wineserver would have to
is already a lookup in the server, but there is no cross-process
syscall for NtProtectVirtualMemory (and in fact for all of the other
virtual memory functions). The cleanest fix is to get the kernel to
support this. One suggested way of fixing this and other cross-process
problems in Wine
Robert Shearman wrote:
Segin wrote:
Could someone clue me in to just what this means and why it is:
err:virtual:NtProtectVirtualMemory Unsupported on other process
A quick Google comes up that function is undocumented, so I don't
have much info on it.
From the wine source:
if (!is_curr
Segin wrote:
Could someone clue me in to just what this means and why it is:
err:virtual:NtProtectVirtualMemory Unsupported on other process
A quick Google comes up that function is undocumented, so I don't have
much info on it.
From the wine source:
if (!is_current_process( process ))
Could someone clue me in to just what this means and why it is:
err:virtual:NtProtectVirtualMemory Unsupported on other process
A quick Google comes up that function is undocumented, so I don't have
much info on it.
From the wine source:
if (!is_current_process( process ))
{
ERR(
11 matches
Mail list logo
