August 2016 - Wine-Devel - list.winehq.org

Re: What flavor of C does Wine source target?

by achbarrr＠gmail.com

hello Ruslan wine is looking like emulator its works same like bluestacks app player. if its true wine is not emulator its must work like other. Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: >Hello all, > >While developing some code for Wine I wanted to ensure that I don't >use some C99 features like C++-style comments or declaration of >variables after statement. But the only way I found to do this with >gcc was to use '-std=c89 -pedantic'. This appears to break lots of >other things in winelib, particularly 'inline' functions, so it can't >really be used for Wine/Winelib sources. The default for GCC is gnu89, >which does allow the things Wine doesn't want. > >So, I wonder now, what flavor of C does Wine actually target? What >tools can I use to automatically restrict language features? > >Regards, >Ruslan > >

Aug. 26, 2016

What flavor of C does Wine source target?

by Ruslan Kabatsayev

Hello all, While developing some code for Wine I wanted to ensure that I don't use some C99 features like C++-style comments or declaration of variables after statement. But the only way I found to do this with gcc was to use '-std=c89 -pedantic'. This appears to break lots of other things in winelib, particularly 'inline' functions, so it can't really be used for Wine/Winelib sources. The default for GCC is gnu89, which does allow the things Wine doesn't want. So, I wonder now, what flavor of C does Wine actually target? What tools can I use to automatically restrict language features? Regards, Ruslan

Aug. 26, 2016

Re: [PATCH] wined3d: Fix ATI1 buffer size, try 3

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25380 Your paranoid android. === w864 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f.

Aug. 26, 2016

Re: [PATCH] ntdll: Use boot time to calculate tick count

by Ken Thomases

On Aug 25, 2016, at 2:55 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > Two catches with the macOS behavior: First, this implementation is much > more expensive than one system call in a very frequently called > function. mach_absolute_time() isn't even a system call. It's implemented in user space. It reads the TSC from the CPU and applies adjustments read from the commpage. There's a potential for it to loop if the commpage is adjusted while it's running. > It's an open question whether fixing behavior on sleep is > worth the cost. Second, the boot time has precision only to the nearest > second. This could cause skew if the current time is updated in <~1 > second intervals. Actually, it will cause skew whenever the current time is updated by a delta that's not whole seconds. Another issue is the race between sysctl() and gettimeofday(). If a time adjustment occurs between them, you'll get an incorrect result. This could be detected by checking the boot time again after gettimeofday() and repeating if it changed. Unfortunately, that adds even more overhead. (Actually, if we track the last known boot time in a static, we could only check it after and loop if it changed. That requires interlocked updating of the static, though, to make it thread safe.) Unfortunately, I don't know a good solution. I think that it may be a bug that mach_absolute_time() doesn't count time spent sleeping, but that's of no comfort. -Ken

Aug. 25, 2016

Re: [2/3] winex11: Returning more reliable value from X11DRV_MsgWaitForMultipleObjects.

by Ken Thomases

Hi, On Aug 23, 2016, at 8:13 AM, Akihiro Sagawa <sagawa.aki(a)gmail.com> wrote: > > This patch fixes ole32 test failure with my IME window patch. > > After processing several X events, X11DRV_MsgWaitForMultipleObjects always > tells us that a new message is available. This is not true for some cases. > > For instance, when we call DestroyWindow, the X queues DestroyEvent. Then, > X11DRV_MsgWaitForMultipleObjects handles the event only; none is posted or > sent as hwnd for destroyed window is unavailable. However, the function > states "new message is available" by returning count - 1 value. > > This is an issue for CoWaitForMultipleHandles because it expects a new > message in the queue and consumes the message. I'm looking at this with an eye toward whether the Mac driver needs a similar change. First, there's no change in the ole32 tests with or without your IME window patch when using the Mac driver. There's a clipboard failure but everything else succeeds. Second, the Mac driver doesn't have a notion of the window being destroyed behind our backs. I.e. there's nothing like a DestroyNotify event for a window whose HWND is still valid. But, just because that particular case doesn't come up doesn't mean the change is not still relevant to the Mac driver for other cases. However, I'm having a hard time seeing the logic of your change. In process_events(), you use a variable named "queued" to hold the result of calls to event handlers. That implies that event handlers should only return true if they have posted or sent a Windows message or hardware input. But that doesn't seem to be what you've actually done in the event handlers. For example, in the first "if" statement in X11DRV_MapNotify(), you return true without queuing anything. Instead, you seem to be returning true for some notion of "success" in handling events, but I'm not sure how that plays into the rationale for this patch. Am I misunderstanding something? I also don't get why you changed the TRACE at the end of process_events(). The events really were processed. They aren't "ignored" just because they didn't result in messages or input being queued. Also, shouldn't the return type of process_events() be changed to BOOL? Thanks, Ken

Aug. 25, 2016

RE: [PATCH] ntdll: Set Rip in for longjmp in RtlRestoreContext (try2)

by Daniel Lehman

On 08/18/16 18:29, Daniel Lehman wrote: > + pass = 0; > + pRtlCaptureContext(&ctx); > + if (InterlockedIncrement(&pass) == 1) /* interlocked to prevent > + compiler from moving */ The patch looks good for me except one thing that I don't understand. Why there's no risk that compiler will move the pass=0 assignment after pRtlCaptureContext call? I can see how another compiler could move it; just didn't in my case. I'll send an updated version

Aug. 25, 2016

Re: [PATCH] ntdll: Set Rip in for longjmp in RtlRestoreContext (try2)

by Piotr Caban

Hi Daniel, On 08/18/16 18:29, Daniel Lehman wrote: > + pass = 0; > + pRtlCaptureContext(&ctx); > + if (InterlockedIncrement(&pass) == 1) /* interlocked to prevent compiler from moving */ The patch looks good for me except one thing that I don't understand. Why there's no risk that compiler will move the pass=0 assignment after pRtlCaptureContext call? Maybe something like this will be more correct: pass = 0; InterlockedIncrement(&pass); pRtlCaptureContext(&ctx); if (InterlockedIncrement(&pass) == 2) ? Thanks, Piotr

Aug. 25, 2016

Re: [PATCH 1/2] rbtree.h: Store parent in each entry and use that to manipulate the tree without a stack.

by Jacek Caban

On 25.08.2016 16:44, Sebastian Lackner wrote: > Nevertheless, before spending more time on an alternative implementation it might > be useful to decide in which direction we want to proceed. ;) Agreed ;) I still hope that my patches will get in. After last Henri's reply I was expecting a sign off, but it's still not there. Henri? Jacek

Aug. 25, 2016

Re: [PATCH 1/2] rbtree.h: Store parent in each entry and use that to manipulate the tree without a stack.

by Sebastian Lackner

On 25.08.2016 16:33, Jacek Caban wrote: > On 25.08.2016 15:59, Sebastian Lackner wrote: >> On 25.08.2016 15:30, Jacek Caban wrote: >>> Hi Sebastian, >>> >> [...] >>>> I assume that there are currently no plans to exchange the RBTree with >>>> something else, nevertheless it shouldn't hurt to share some code. I've >>>> attached a proof-of-concept patch to replace the RBTree with a Scapegoat >>>> tree I wrote a while ago. In contrast to other trees a nice property is that >>>> it is not really required to keep the tree balanced all the time, instead we >>>> have rebuild operations which will automatically detect it if the performance >>>> gets too bad and build a binary search tree. When deleting lots of elements >>>> for example we could disable rebuild temporarily to avoid too much overhead. >>> Sure. Since you posted it, I had a quick look. That implementation >>> requires allocators, which is what we should avoid to simplify usage of >>> the tree. You could get rid of the array by storing another pointer in >>> nodes that would be used to link them into ordered list instead of an >>> array (that would require a bit more tricky wine_rb_build, but it should >>> be doable without much perf cost). However, then you'd give up memory >>> advantage. >> Well, I do not think allocators in general are a problem.It is only a problem if >> important operations can fail because of out of memory errors. The Scapegoat >> tree uses it only for the rebuild operation which is not critical (performance >> will get worse, but everything will continue to work as expected). > > Sure, failing operations is the most annoying part of allocators, so > it's a step forward. Still, avoiding overhead of adding allocators in > each tree user would be nice. > > >> Also, I do not think its possible to replace the array with an ordered list - >> the rebuild operation requires computation of the median which would be way too >> expensive for regular lists. > > I think that should be doable, but with a different algorithm in wine_rb_build. That's what I meant by tricky. Here is first that comes first into my mind: > > let's say that nodes are in list1 > > while(list1 length > 1) { > while(list1 length > 0) { > take first 3 elements node1, node2, node3 from list1 (*) > node2->left = node1 > node2->right = node3 > append node2 into list2 > } > list1 = list2 > } > > root = the only element in list1 > > (*) if list length 2, use NULL for node3, if length is 1, > node1=node3=NULL, node2=the only node in list > > Since on every outer loop iteration length of new list is 3 times > shorter than previous length, the complexity is O(n), just like with the > array. > > > Jacek > I see what you mean. In fact, since we know how many nodes are in the subtree which has to be rebuild (and thus the height of the balanced subtree), this could probably even be implemented recursively without using any allocators and O(log n) stack usage. Nevertheless, before spending more time on an alternative implementation it might be useful to decide in which direction we want to proceed. ;) Regards, Sebastian

Aug. 25, 2016

Re: [PATCH 1/2] rbtree.h: Store parent in each entry and use that to manipulate the tree without a stack.

by Jacek Caban

On 25.08.2016 15:59, Sebastian Lackner wrote: > On 25.08.2016 15:30, Jacek Caban wrote: >> Hi Sebastian, >> > [...] >>> I assume that there are currently no plans to exchange the RBTree with >>> something else, nevertheless it shouldn't hurt to share some code. I've >>> attached a proof-of-concept patch to replace the RBTree with a Scapegoat >>> tree I wrote a while ago. In contrast to other trees a nice property is that >>> it is not really required to keep the tree balanced all the time, instead we >>> have rebuild operations which will automatically detect it if the performance >>> gets too bad and build a binary search tree. When deleting lots of elements >>> for example we could disable rebuild temporarily to avoid too much overhead. >> Sure. Since you posted it, I had a quick look. That implementation >> requires allocators, which is what we should avoid to simplify usage of >> the tree. You could get rid of the array by storing another pointer in >> nodes that would be used to link them into ordered list instead of an >> array (that would require a bit more tricky wine_rb_build, but it should >> be doable without much perf cost). However, then you'd give up memory >> advantage. > Well, I do not think allocators in general are a problem.It is only a problem if > important operations can fail because of out of memory errors. The Scapegoat > tree uses it only for the rebuild operation which is not critical (performance > will get worse, but everything will continue to work as expected). Sure, failing operations is the most annoying part of allocators, so it's a step forward. Still, avoiding overhead of adding allocators in each tree user would be nice. > Also, I do not think its possible to replace the array with an ordered list - > the rebuild operation requires computation of the median which would be way too > expensive for regular lists. I think that should be doable, but with a different algorithm in wine_rb_build. That's what I meant by tricky. Here is first that comes first into my mind: let's say that nodes are in list1 while(list1 length > 1) { while(list1 length > 0) { take first 3 elements node1, node2, node3 from list1 (*) node2->left = node1 node2->right = node3 append node2 into list2 } list1 = list2 } root = the only element in list1 (*) if list length 2, use NULL for node3, if length is 1, node1=node3=NULL, node2=the only node in list Since on every outer loop iteration length of new list is 3 times shorter than previous length, the complexity is O(n), just like with the array. Jacek

Aug. 25, 2016