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("Unsupported on other process\n"); return STATUS_ACCESS_DENIED; }
And that's self explanitory, but why is it "Unsupported on other process"?
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 )) { ERR("Unsupported on other process\n"); return STATUS_ACCESS_DENIED; }
And that's self explanitory, but why is it "Unsupported on other process"?
The POSIX & Linux equivalent doesn't take a process ID as an argument, hence it only operates on the current process.
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_current_process( process )) { ERR("Unsupported on other process\n"); return STATUS_ACCESS_DENIED; }
And that's self explanitory, but why is it "Unsupported on other process"?
The POSIX & Linux equivalent doesn't take a process ID as an argument, hence it only operates on the current process.
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?
Segin wrote:
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_current_process( process )) { ERR("Unsupported on other process\n"); return STATUS_ACCESS_DENIED; }
And that's self explanitory, but why is it "Unsupported on other process"?
The POSIX & Linux equivalent doesn't take a process ID as an argument, hence it only operates on the current process.
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?
There 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 without kernel support is to change the context of the target process to set up a call to the relevant function and restore the registers afterwards. AFAIK, no one has tried to implement this yet.
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 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.
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 multithreaded direct3d. Somehow we have to bring another thread to releasing the glxContext, so we can re-use it in a new thread.
Any chance we can do this with signals? e.g. SIGUSER1 to call a wine-provided callback function, which calls callbacks registered by the various dlls?
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 think that the easiest solution would be to have one GL context per thread (and multiple contexts can share the same rendering target and also texture handles).
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).
After we just have to rely that this is properly implemented at the GL driver level...
I once wanted to toy with this in the DDraw code base but well, seeing that it will phased out pretty soon I did not do any work on it. On the other hand I could try for some specific games (like DungeonSiege) as an experiment to then port it over to WineD3D.
Lionel
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 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.
I think we need a mutex or something simmilar for all the object structures too.
I once wanted to toy with this in the DDraw code base but well, seeing that it will phased out pretty soon I did not do any work on it. On the other hand I could try for some specific games (like DungeonSiege) as an experiment to then port it over to WineD3D.
Multithreaded d3d was one of the reasons for my decision to port ddraw over to wined3d. Once it's implemented in wined3d all versions have it :)
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 you want to do a GL call if this thread has already his GL context set. And if no, create it (sharing the texture ids with the 'primary' one) and set it as current.
I think we need a mutex or something simmilar for all the object structures too.
Yes we need to protect all internal states by mutexes (different than the 'GL' mutex as the plan would be to only ever call any GL function when rendering on screen :-) ).
Lionel
-
Lionel Ulmer -
Mike Hearn -
Robert Shearman -
Segin -
Stefan Dösinger