June 2011 - Wine-Devel - list.winehq.org

Re: [PATCH 2/6] quartz/tests: COM cleanup for the IClassFactory iface.

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 http://testbot.winehq.org/JobDetails.pl?Key=11824 Your paranoid android. === WNT4WSSP6 (32 bit filtergraph) === filtergraph: unhandled exception c0000005 at 00405B3C

June 19, 2011

Re: [PATCH 1/6] quartz/tests: COM cleanup for the IPin iface.

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 http://testbot.winehq.org/JobDetails.pl?Key=11823 Your paranoid android. === WNT4WSSP6 (32 bit filtergraph) === filtergraph: unhandled exception c0000005 at 00405B3C

June 19, 2011

Re: wined3d: Use a separate mutex for wndproc_table access.

by Henri Verbeet

On 18 June 2011 12:51, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > You don't need wined3d_wndproc_mutex_(un)lock. Just use EnterCriticalSection / > LeaveCriticalSection directly. wined3d_mutex_lock exists because it is > exported from wined3d. > I don't know, I think there's something to say for having those functions.

June 19, 2011

Re: CopyFileExW Support

by Jerome Leclanche

You are severely mixing tabs and spaces, you should fix your editor. You also have a lot of unrelated trailing whitespace changes; granted they all remove trailing whitespace, but since this isn't a small patch, it makes it harder to read. J. Leclanche On Sun, Jun 19, 2011 at 2:40 AM, Arthur Dene Ice <addtheice(a)gmail.com> wrote: > > > > >

June 19, 2011

Re: [PATCH 1/3] user32/tests: Added client-side raw input function tests (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 http://testbot.winehq.org/JobDetails.pl?Key=11822 Your paranoid android. === W7PROX64 (64 bit input) === No test summary line found

June 19, 2011

Re: Wrong AppDB link

by Ricardo Filipe

it's not there nor in the bug link queue. so it seems someone got to it already :) 2011/6/18 <wylda(a)volny.cz> > > Hi, > > by mistake i linked a wrong bug to FAR Manager: > > http://appdb.winehq.org/objectManager.php?sClass=version&iId=15928 > > Could someone remove a link from FAR to bug 27406, please? > > > Thanks, W. > > > > >

June 19, 2011

Re: openal32: test whether alGetError() returns AL_NO_ERROR when called out of context, with fix.

by Chris Robinson

On Saturday, June 18, 2011 8:32:31 PM Dan Kegel wrote: > Matches native behavior. Makes at least one app happier; see bug 27532. Just to toss in my comments, the "native" behavior referred to is the behavior of Creative's DLLs, but Creative's DLLs aren't the only ones available for Windows. OpenAL Soft behaves the same way as a real DLL as it does a Linux DSO (ie, returns an error from alGetError() when no current context is set), and IIRC, there are Windows apps that prefer using it over Creative's sometimes- unstable drivers. There is at least one other OpenAL implementation available for Windows that some apps use, but I don't know how it behaves and it costs money. IMO, it is a bug in both Creative's DLLs and the affected app. Two bugs nullifying each other, essentially. Using OpenAL Soft's DLL in place of Creative's, in real Windows, would yield the same bug experienced in Wine.

June 19, 2011

Re: shdocvw: Add ITaskbarList2 Interface

by Alistair Leslie-Hughes

Hi André, On 19/06/2011 1:52 AM, André Hentschel wrote: > --- > dlls/shdocvw/taskbarlist.c | 74 ++++++++++++++++++++++++++++--------------- > include/shobjidl.idl | 15 +++++++++ > 2 files changed, 63 insertions(+), 26 deletions(-) Can you please provide a test case to show that this interface exists? Best Regards Alistair Leslie-Hughes

June 19, 2011

Wrong AppDB link

by wylda＠volny.cz

Hi, by mistake i linked a wrong bug to FAR Manager: http://appdb.winehq.org/objectManager.php?sClass=version&iId=15928 Could someone remove a link from FAR to bug 27406, please? Thanks, W.

June 18, 2011

Re: [PATCH 2/2] d3dx9/line: Implemented tests for ID3DXLine's Begin and End methods.

by Charles Welton

Can't reproduce as this seem to only work with wine64. Perhaps there's some issue with the headers? Code compiles fine under wine32. On 06/18/2011 11:50 AM, Marvin wrote: > 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 > http://testbot.winehq.org/JobDetails.pl?Key=11808 > > Your paranoid android. > > > === WINEBUILD (build) === > Make failed -- Charles Welton

June 18, 2011

gcc 4.6 warning report

by Jerome Leclanche

Had to check a few warnings earlier and there hasn't been a warning report in a while, thought I'd share it. It's also still impossible to configure with -Werror because of warnings in configure scripts. Wine version wine-1.3.22-203-gac90c1b ac90c1bd1878599710605fa5b4e2fe8ce224b280 Enabled packages alsa freetype gstreamer jpeg ldap openal opengl openssl png x xinerama xinput2 xml xrandr Disabled packages capi cms cups curses esd fontconfig gettextpo gnutls gphoto gsm hal jack mpg123 nas opencl oss sane tiff v4l xslt xxf86vm CFLAGS -msse4 -O3 -Wall Built on Linux azura 3.0-0-generic #1-Ubuntu SMP Thu Jun 9 16:32:10 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux J. Leclanche

June 18, 2011

Re: [PATCH 2/2] d3dx9/line: Implemented tests for ID3DXLine's Begin and End methods.

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 http://testbot.winehq.org/JobDetails.pl?Key=11808 Your paranoid android. === WINEBUILD (build) === Make failed

June 18, 2011

Re: wined3d: Use a separate mutex for wndproc_table access.

by Stefan Dösinger

I can't speak about the conceptual correctness of this patch, although my gut feeling says that you're right. You don't need wined3d_wndproc_mutex_(un)lock. Just use EnterCriticalSection / LeaveCriticalSection directly. wined3d_mutex_lock exists because it is exported from wined3d. On Friday 17 June 2011 21:49:38 Piotr Pawlow wrote: > If CreateDevice is called with hFocusWindow belonging to another thread, > then any code that does SendMessage (or equivalent) to the window while > holding the main wined3d mutex causes a deadlock, because wined3d_wndproc > tries to acquire the same mutex for wndproc_table access. Using a different > mutex for this purpose solves the problem. > --- > dlls/wined3d/wined3d_main.c | 44 > +++++++++++++++++++++++++++++++----------- > 1 files changed, 32 insertions(+), 12 deletions(-)

June 18, 2011

STATE_VDECL & friends

by Stefan Dösinger

Hi, This is a brain core dump before going to bed for the other d3d developers. I did some testing concerning the vertexdeclaration, vertex shader, stream sources and pixel shader states. Currently the first 3 are hard linked, and the pixel shader is also tied to the vertex shader. I was interested which states are invalid how often, and where separating the states makes sense. Basically about 40% of all draws only the pixel shader is invalid. In another 30%-50% the pixel shader and stream source are invalid, and in about 10% to 20% of all draws all 4 states are reapplied anyways. There are relatively few cases where the vertex declaration and vertex shader are changed alone. So what does this mean? We'll have to spit away the pixel shader and stream sources states. The good news is that the stream sources are easy to separate - when the streamsources are invalid only reapply them, if the vdecl or vshader are dirty reapply shader+decl+streamsrc. The bad news is that applying the stream sources is the most expensive part. The pixel shader is already somewhat separated. Changing the pixel shader will only reapply the vertex shader, but not stream sources or other vdecl-related states. Separating vertex and pixel shaders will be tricky and not fully possible on some drivers(needs GL_ARB_separate_shader_objects or ARB shaders) and all shaders(Shader Model 3.0 varying passing) In addition to this we'll have to make parsing of the vertex declaration cheaper. I'll think of something... I'll also write some quick and dirty patches to see how much performance we really get out of these changes. Stefan PS: I attached my debug patch and the output for a few games.

June 17, 2011

Re: limits on the number of events, windows and threads?

by Ove Kaaven

Den 17. juni 2011 16:38, skrev Joerg-Cyril.Hoehle(a)t-systems.com: > Hi, > > I vaguely remember reading about a quite low limit on the number of > event objects that a thread can hold because each one is said > to take up one bit in some 32 or 64 bit mask. You should probably clarify what you mean, since it is not possible and does not make sense for a thread to "hold" an event object. Event objects might be waited on, I suppose, in which case waiting on them using WaitForMultipleObjects would be limited by the number of objects that you can pass to WaitForMultipleObjects (i.e., up to 64 objects), but this doesn't have anything to do with bitmasks, nor should it be the same as "holding". > Is there such a low limit on the number of events (or other types of > handles) than one thread can hold in native or in Wine? Would depend on what you mean by "hold", but probably not.

June 17, 2011

Re: winealsa: Avoid deadlock in AudioClient_Stop.

by Andrew Eikum

Hi Jörg, Patch makes sense to me. I'll put together some patches for the other drivers, unless you beat me to it ;) Thanks, Andrew On 06/17/2011 10:13 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > my patch is not the final word about robust design. > > Consider what happens when > DeleteTimerQueueTimer(g_timer_q, This->timer, INVALID_HANDLE_VALUE) > cannot allocate its CompletionEvent. The function will return with an > (ignored) error and not stop the timers. Do you see a check in > wineoss or winecoreaudio? The later Audio_Release will destroy > critical sections and free memory while the timers are still running! > > A tiny allocation failure => big crash > > Deallocators should not fail when resources are scarce. > > A more robust design would see Audio_Start allocate the completion > event that DeleteTimerQ requires and not start if it can't be sure to stop. > Why require a completion event? Because there's > *no* other way of telling whether a callback might still be invoked. > Even sleeping for more than the timer period is no guarantee rather > than mere heuristics that works on a slightly loaded system. > > Back to my patch. It's funny to think that it would mostly work > without error checking: DeleteTimerQ(event) does something with > event NULL or not, Wait(NULL) would immediately return and > DeleteTimerQ always signals the event when successful. > > Regards, > Jörg Höhle > > > >

June 17, 2011

Re: [1/7] server: Implement RegisterHotKey/UnregisterHotKey.

by Vincent Povirk

I now have a test, and it turns out the docs are incorrect. After registering a new hotkey with the same id/hwnd as an existing hotkey, the old key combination no longer generates a WM_HOTKEY message, and the new one does, on all Windows versions that winetestbot tested. I'll send that after I find out what happens to the current series. On Fri, Jun 17, 2011 at 5:32 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Vincent Povirk" <vincent(a)codeweavers.com> writes: > >> @@ -2632,6 +2632,29 @@ enum coords_relative >> #define SET_USER_OBJECT_FLAGS 1 >> >> >> +/* Register a hotkey */ >> +(a)REQ(register_hotkey) >> + user_handle_t window; /* handle to the window */ >> + int id; /* hotkey identifier */ >> + int flags; /* modifier keys */ >> + int vkey; /* virtual key code */ >> +(a)REPLY >> + int replaced; /* did we replace an existing hotkey? */ >> + int flags; /* flags of replaced hotkey */ >> + int vkey; /* virtual key code of replaced hotkey */ >> +(a)END > > The docs say that hotkeys are no longer replaced in recent Windows > versions. It would be a good idea to have a test for that. > > -- > Alexandre Julliard > julliard(a)winehq.org > > >

June 17, 2011

dead-lock free design

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, there are two guidelines that I identified while trying to prevent dead-locks with critical sections and access to uninitialiased memory in Wine. My latest patch shows both applications. http://www.winehq.org/pipermail/wine-patches/2011-June/103247.html 1. In callbacks, detect when it should not run anymore and exit *early*. void CALLBACK mycallback (void* user) { struct mycbdata * mycb = user; EnterCriticalSection(mycb->lock); if(!mycb->started || mycb->shutdown) { LeaveCriticalSection; return; } /* else do actual work */ This is best done after EnterCS, because the critical section is the most likely place where the callback thread will have been preempted. Note that this doesn't prevent mycb from pointing to free'ed memory. You may only deallocate resources once you've made sure that the callback cannot be invoked any more. 2. Use two phases to end cleanly. Delegate part of the work to a later stage. Pause is not Stop. Stop is not Close. Close is not Shutdown. Shutdown is not DLL Unload. My current patch applies this idea partially. DeleteTimerQueueTimer() is called within a CS, whereas Wait() is called afterwards (which is safe because the mmdevapi object is not used any more). The original deadlock happened because DeleteTimerQueue and Wait were combined in one call, within the CS. Waiting for completion is *essential* with the DeleteTimerQueueTimer API because that's the only means to ensure that callbacks are done. Then only can you free the memory that mycb above points to. A variation is to partition the work among AudioClient_Stop and AudioClient_Release. In Stop() call DeleteTimerQueueTimer() but Wait for completion of the callbacks in Release(). Alternatively, in Stop() use ChangeTimerQueueTimer(DueTime=INFINITE) to prevent firing new callbacks and use DeleteTimerQueue in Release(). I didn't write my patch that way yet because it requires some attention in AudioClient_Start() when restarting the timer callbacks. Why does the rule work? Functions likes Play/Pause/Stop typically prevent concurrent access (either from the app or from internal callback threads) using critical sections. At Close/Release time, the typical assumption is that there's no more concurrency -- at least from the side of the application. Partitioning the work allows for plenty of new possibilities. E.g. one known bug in MS-Windows is that MCI/winmm's Stop() may take a lot of time, freezing the application. However, if Stop() simply sends a stop signal to the player thread, without waiting for the thread to actually stop, it can be plenty fast. Likewise, if mmdevapi's AudioClient_Stop() simply sets This->started to FALSE, the callback will still be ticking, but not disturb. Fast too if it calls DeleteTimerQueueTimer() but delegates the Wait to AudioClient_Release(). One drawback is that resources will be allocated for longer than with the naïve approach. Sometimes, the partitioning decision depends on what state you want to guarantee after Pause, Stop or Close. This is rarely documented. E.g. for MCI's audio player you want to make sure that an immediately following Open won't fail when Wine's winmm ALSA or OSS drivers only support opening one device at a time. Regards, Jörg Höhle

June 17, 2011

limits on the number of events, windows and threads?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, I vaguely remember reading about a quite low limit on the number of event objects that a thread can hold because each one is said to take up one bit in some 32 or 64 bit mask. That was then invoked as a reason to allocate e.g. event or window objects for as short a time span as possible. Is there such a low limit on the number of events (or other types of handles) than one thread can hold in native or in Wine? Thank you for your help, Jörg Höhle

June 17, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Fri, Jun 17, 2011 at 3:02 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Friday 17 June 2011 14:27:55 Michael Mc Donnell wrote: >> Ok I've sent them to wine-patches. > They didn't make it through yet. Are you subscribed? (If you're not > subscribed, don't resend them yet, Newman will most likely let them through > manually later today) Nope I'm not subscribed to wine-patches. I'll wait.

June 17, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

On Friday 17 June 2011 14:27:55 Michael Mc Donnell wrote: > Ok I've sent them to wine-patches. They didn't make it through yet. Are you subscribed? (If you're not subscribed, don't resend them yet, Newman will most likely let them through manually later today)

June 17, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Fri, Jun 17, 2011 at 1:07 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Friday 17 June 2011 12:14:59 Michael Mc Donnell wrote: >> Ok I've added WARN message for every case where it returns an error to >> the application. I've also reworded the WARN where it uses an invalid >> declaration but still must return D3D_OK. > Looks good! Ok I've sent them to wine-patches.

June 17, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

On Friday 17 June 2011 12:14:59 Michael Mc Donnell wrote: > Ok I've added WARN message for every case where it returns an error to > the application. I've also reworded the WARN where it uses an invalid > declaration but still must return D3D_OK. Looks good!

June 17, 2011

Re: [1/7] server: Implement RegisterHotKey/UnregisterHotKey.

by Alexandre Julliard

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > @@ -2632,6 +2632,29 @@ enum coords_relative > #define SET_USER_OBJECT_FLAGS 1 > > > +/* Register a hotkey */ > +(a)REQ(register_hotkey) > + user_handle_t window; /* handle to the window */ > + int id; /* hotkey identifier */ > + int flags; /* modifier keys */ > + int vkey; /* virtual key code */ > +(a)REPLY > + int replaced; /* did we replace an existing hotkey? */ > + int flags; /* flags of replaced hotkey */ > + int vkey; /* virtual key code of replaced hotkey */ > +(a)END The docs say that hotkeys are no longer replaced in recent Windows versions. It would be a good idea to have a test for that. -- Alexandre Julliard julliard(a)winehq.org

June 17, 2011

Fwd: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

Hi Stefan sorry for the duplicate email. I forgot to also send it to wine-devel. On Fri, Jun 17, 2011 at 12:02 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Thursday 16 June 2011 10:49:19 Michael Mc Donnell wrote: >> I've added the test you outlined. It shows you're correct that >> GetDeclaration only writes up to D3DDECL_END(). I've changed the >> implementation so that it caches the number of elements and only >> writes up to D3DDECL_END(). > Looks good to me. Great! >> You're right it could potentially read undefined memory depending on >> the compiler semantics. I think the safest thing is just to read up to >> D3DDECL_END() in the passed in declaration, then it will never read >> undefined memory (except if the programmer makes a mistake). > Looks good, but please write a WARN message in every case where you return an > error to the application. We believe that we handled the error condition > correctly, so there's no need for a FIXME, but the broken app behavior may > have been triggered by some other problem in Wine, so the message is more > important than a simple TRACE. Ok I've added WARN message for every case where it returns an error to the application. I've also reworded the WARN where it uses an invalid declaration but still must return D3D_OK.

June 17, 2011