On 4/10/2012 4:48 AM, Vitaliy Margolen wrote:
On 04/09/2012 12:14 PM, Kornél Pál wrote:
I think this would work. (But don't know whether it was accepted.)
No, it won't work. Wine itself (ntdll & kernel32) accesses it.
In my opinion it still would work, just would not be optimal.
Note that I
On 04/09/2012 12:14 PM, Kornél Pál wrote:
I think this would work. (But don't know whether it was accepted.)
No, it won't work. Wine itself (ntdll & kernel32) accesses it.
Vitaliy.
On 4/9/2012 7:46 PM, Francois Gouget wrote:
On Thu, 22 Mar 2012, Kornél Pál wrote:
[...]
A bit better approach was to mark that page PAGE_GUARD. Then wine could get an
indication that it needs to be updated. Frequent accesses were not impacted
because PAGE_GUARD could be reset by an APC some tim
On Thu, 22 Mar 2012, Kornél Pál wrote:
[...]
> A bit better approach was to mark that page PAGE_GUARD. Then wine could get an
> indication that it needs to be updated. Frequent accesses were not impacted
> because PAGE_GUARD could be reset by an APC some time later.
Why reset PAGE_GUARD?
Would the
>
> Writable shared memory is unacceptable, but as long as it's read-only
> from the client there's no problem in principle.
>
Excellent, thanks Alexandre.
I'm attaching my current shared memory diff. It uses shm_open + mmap in
wineserver to map the shared memory area read/write, and shm_open
Dmitry Timoshkov writes:
> Joey Yandle wrote:
>
>> > Why do you need to update the data in wineserver and not in the client?
>>
>> The problem is that the timer updates need to be extremely precise, or
>> they are worse than useless. So we can either do that in every wine
>> process, or do it
>
> Can you use a separate process -- a Win32 service -- to update this shared
> memory?
>
Something like plugplay.exe? I don't see why not. I'll look over the
plugplay.exe code and see if it looks promising.
cheers,
Joey
On Apr 2, 2012, at 10:01 PM, Joey Yandle wrote:
>> You need to make wineserver multithreaded then, and that idea has been
>> shot down as well.
>
> Yes, either wine or wineserver will need a thread to set these values
> with the required precision.
Can you use a separate process -- a Win32 servi
> It's been continously said that any memory sharing scheme between a client
> and wineserver won't be accepeted, ever.
You're the second person to make that assertion without pointing out the
relevant discussion. Such assertions are not helpful.
> You need to make wineserver multithreaded then,
Joey Yandle wrote:
> > Why do you need to update the data in wineserver and not in the client?
>
> The problem is that the timer updates need to be extremely precise, or
> they are worse than useless. So we can either do that in every wine
> process, or do it once in wineserver and share the me
> Why do you need to update the data in wineserver and not in the client?
The problem is that the timer updates need to be extremely precise, or
they are worse than useless. So we can either do that in every wine
process, or do it once in wineserver and share the memory.
On Windows, the kernel s
Joey Yandle wrote:
> If anyone does know how Alexandre et alia feel about sharing data
> between wine and wineserver, please let me know. It seems the closest
> to what Windows does, in the context of wine. And as long as the
> mapping is read-only from wine, then it seems unlikely to cause too
>
> I know they declined an in-process wineserver due to difficulties
> blaming the right component on a crash: is it the app or wine that's faulty?
>
> I found no other relevant discussion on wine-devel since January 2010,
> when searching for first 'share' and then 'server'.
>
If anyone does
On Thu, Mar 22, 2012 at 5:19 AM, Joey Yandle wrote:
> >
> > It's been explained several times already that any approach to share data
> > between wineserver and clients is going to be rejected.
> >
>
> Can you point me to such an explanation? I joined wine-devel just
> before posting my RFC. If
> When numbers don't increment (as happens now) protection is
> happy. When they start to increment, even on fast PCs round trip
> user-space->wineserver->ntoskrnl will take way longer then it "should".
>
Indeed, that pathway will never be fast enough. I'm surprised it works
with no incrementing,
On 03/24/2012 01:09 PM, Joey Yandle wrote:
Any code written for windows expects these values to
update every 15.6 ms.
Exactly. Wine's wineserver & fake kernel in form of ntoskernl can not work
with native speed by definition.
For example even earliest versions of safedisk (1.5) were really pic
>
> BTW one more thing, this change will most likely break number of copy
> protection systems. Such as safedisk. They use user shared date times to
> estimate time it took for some kernel operations. And some of those time
> intervals are really tight.
>
I'm extremely confused by this statement
On 03/24/2012 08:56 AM, Kornél Pál wrote:
On 3/22/2012 2:19 PM, Vitaliy Margolen wrote:
Since there are a plenty of ways to measure elapsed time, I don't think that
this specific way should generally be prohibited.
I'm not saying it should be prohibited. I'm saying it fixes only one app and
po
On 3/22/2012 2:19 PM, Vitaliy Margolen wrote:
BTW one more thing, this change will most likely break number of copy
protection systems. Such as safedisk. They use user shared date times to
estimate time it took for some kernel operations. And some of those time
intervals are really tight.
I'm n
On 03/21/2012 10:19 PM, Joey Yandle wrote:
It's been explained several times already that any approach to share data
between wineserver and clients is going to be rejected.
Can you point me to such an explanation? I joined wine-devel just
before posting my RFC. If this has been discussed pr
On 3/22/2012 7:43 AM, Kornél Pál wrote:
On 3/22/2012 6:00 AM, Dmitry Timoshkov wrote:
Joey Yandle wrote:
It's been explained several times already that any approach to share data
between wineserver and clients is going to be rejected.
I think this is the reason that timers in shared_user_data
On 3/22/2012 6:00 AM, Dmitry Timoshkov wrote:
Joey Yandle wrote:
It's been explained several times already that any approach to share data
between wineserver and clients is going to be rejected.
I think this is the reason that timers in shared_user_data are not being
updated. I also think tha
On 03/21/2012 10:19 PM, Joey Yandle wrote:
If not, can you look at the APC based patch I posted and let me know how
to make the callbacks happen with more precise timing?
Yes, that is the only possible way to do this currently in Wine. Separate
thread is a no-go. It will break some application
>
> It's been explained several times already that any approach to share data
> between wineserver and clients is going to be rejected.
>
Can you point me to such an explanation? I joined wine-devel just
before posting my RFC. If this has been discussed previously, I'd
prefer to get the contex
Joey Yandle wrote:
> After looking over the code, I think I should just mmap() directly in
> wineserver rather than using MapViewOfFile; I should however still use
> MapViewOfFile in ntdll/thread.c.
>
> Mr Google tells me that I can get a handle for MapViewOfFile by calling
> CreateFileMapping.
>
> So I'm going to go ahead and try this now. If anyone has a issue with
> this approach, please let me know.
>
I implemented this approach, only to find that numerous places in ntdll/
write to user_shared_data. I need to move all of that code to server/,
which will take a while, since much o
> 2. in server/main.c:
>
> int fd = shm_open("/KUSER_SHARED_DATA", O_RDWR | O_CREAT, 0600);
> // call MapViewOfFile to map fd to 0x7ffe
>
After looking over the code, I think I should just mmap() directly in
wineserver rather than using MapViewOfFile; I should however still use
MapViewOf
>
> MapViewOfFile (and the underlying NtMapViewOfSection) has support for
> specifying the address to map it.
>
So what I should do is:
1. in ntdll/thread.c:thread_init:
int fd = shm_open("/KUSER_SHARED_DATA", O_RDONLY | O_CREAT, 0600);
// call MapViewOfFile to map fd to 0x7ffe
2. in
On 3/21/2012 9:11 PM, Joey Yandle wrote:
If user_shared_data was written by wineserver and mapped read-only to
wine processes there was no need to create separate threads in wine
processes. As I know Windows is sharing this structure and is updating
it in kernel mode so wine behavior was similar
>
> If user_shared_data was written by wineserver and mapped read-only to
> wine processes there was no need to create separate threads in wine
> processes. As I know Windows is sharing this structure and is updating
> it in kernel mode so wine behavior was similar if was updated by
> wineserver.
On 3/21/2012 2:20 PM, Marcus Meissner wrote:
However, I do not know if we can have additional threads at all in a
Win32 process without confusing the win32 processes, or if this needs
to be solved differently (APC?).
If user_shared_data was written by wineserver and mapped read-only to
wine pr
>> However, I do not know if we can have additional threads at all in a
>> Win32 process without confusing the win32 processes, or if this needs
>> to be solved differently (APC?).
>>
>
> A previous version of my patch used NtTimer/APC:
>
I'm attaching a cleaned up version of my APC code. It do
>
> - The shared data structure should be modified with atomic
> accesses only. (Or use a criticalsection if possible.)
>
According the this website, Windows updates the times too frequently to
use a critical section:
http://www.dcl.hpi.uni-potsdam.de/research/WRK/2007/08/getting-os-informat
On Tue, Mar 20, 2012 at 06:40:37PM -0700, Joey Yandle wrote:
> Hi everybody,
>
> As originally discovered by Carsten Juttner, Star Wars: The Old Republic
> uses the time values in KUSER_SHARED_DATA to trigger network send
> buffers. wine does not currently update these values, so TOR does not
> m
34 matches
Mail list logo
