January 2014 - Wine-Devel - list.winehq.org

Re: wininet: InternetGetConnectedStateExW must return TRUE for success (try 2)

by Henri Verbeet

On 29 January 2014 23:01, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Citavi relies on == TRUE comparison so return TRUE instead of != FALSE > I think that in general this kind of change benefits from a comment indicating that the extra compare is on purpose, mostly to avoid someone from removing it again in the future.

Jan. 30, 2014

Re: [PATCH] oleaut32: Fix RecordCopy()/RecordClear() behavior

by Nikolay Sivov

On 1/30/2014 10:40, 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 > https://newtestbot.winehq.org/JobDetails.pl?Key=4547 > > Your paranoid android. > > > === build (build) === > Make failed > ../../../../wine/dlls/oleaut32/tests/vartype.c:28:22: fatal error: test_tlb.h: No such file or directory > compilation terminated. > make: *** [vartype.o] Error 1 You need to 'make depend' I think to get everything updated.

Jan. 30, 2014

Re: [PATCH] oleaut32: Fix RecordCopy()/RecordClear() behavior

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

Jan. 30, 2014

Re: mshtml/tests: Use common wine_dbgstr_guid implementation from test.h (resend)

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://newtestbot.winehq.org/JobDetails.pl?Key=4536 Your paranoid android. === wvista (32 bit htmldoc) === No test summary line found === w7pro64 (32 bit htmldoc) === No test summary line found

Jan. 30, 2014

Re: Fixing conflicts between WineD3D and WGL

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-01-29 19:11, schrieb Henri Verbeet: > On 29 January 2014 19:04, Chris Robinson <chris.kcat(a)gmail.com> > wrote: >> The multi-threaded command stream patches would fix this issue, >> wouldn't it? In that case, WineD3D has a GL context on its own >> thread to handle the D3D calls, leaving the app threads more or >> less alone. Of course, it'll be a while before they get into Wine >> proper. > It could, but only if we decide to enable CSMT even on > uniprocessor systems, and only if we decide to do all GL calls in > the worker thread, including e.g. resource maps and updates. I agree with Henri on this. We should not rely on the CSMT patches to take care of this. Using it on uniprocessor systems is going to hurt performance. It'd also be very useful to keep the single threaded command stream fully operational (including the optional StrictDrawOrdering) for debugging purposes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6XYWAAoJEN0/YqbEcdMwrQEP/iB5KFekS3RsS/S1v1rMprRS VprzpMOPhkHWMUcy0ge+UA9ff9BO9IVrY021mUU5VzTJvPs0h4w6tUa0gqhrn5pi SM1+Ds1ZsrKiQ6zNcXkV54+gwGi/Nr95HRD2UgXET2An2rOKKoHeXwunxj7v6b4f DzeoVrx5JS5/PrBTLFz34NHCBQ/eOtsI+8s6QR9M8S+OT0I/LCN4TLlxeI35EM// VnUKbBkjedy80+SfIAPTXQN8Hhe8Am6fGhnLVYxbw5hkA0oQt5omqoO6vbamIXth 4gyjnikaEI5IB1Q6+CCU1AKlOfxgdXOyNmZ6nDw6X2lJff4il8l5uARFfMuCAGmH NKv3QeDoTUl0pzsfIuPY9NoWTQ8s587YPeS1FBMu3nJYeApfDHD2PBf2QteY1emz h/QcjVTtIgRt1thRch12ikN9D5S5EnoMmDmF8kErmRhCQziwDGH/88OmVCY3FvQn tXwwCIocXZyTsWocgreuuNU4IZUKbBV5ymWwWRmjn3qQnuCA9/8dG5I+5DR6Rk+u PVLI/WrR82TGlC02Bz7YoNXYSmcC+kEOzrTuixXDwFg8ctuXH6q9mJVU/a3ezLRm 9xla91RVQcz+OS0ay6Lsn/Tm3MVCxqslmPfJn7YMSp6fwkTNlSYc2JTToKcurAsE R+R2PV/x+LhIaezyIRG/ =LxIC -----END PGP SIGNATURE-----

Jan. 29, 2014

Re: Fixing conflicts between WineD3D and WGL

by Ken Thomases

On Jan 29, 2014, at 5:10 AM, Henri Verbeet wrote: > On 29 January 2014 01:47, Ken Thomases <ken(a)codeweavers.com> wrote: >> The most important things to achieve are a) to not "consume" the only opportunity the app has to set the window's pixel format, and b) to restore the app's current GL context (and implicitly its DC) when returning control to it. I don't think it's necessary to avoid WineD3D ever changing WGL's notion of the current context. Certainly, while a WineD3D GL context is current, GL functions like glClear() will operate on WineD3D's context. If the app thinks its context is current and calls GL functions, its context better really be current. So, WineD3D really needs to restore the app's context before returning control (and it generally does, I think). If it's going to do that, then wglGetCurrentContext() will take care of itself. Same for wglGetCurrentDC(). >> > There may be performance reasons though. The wglMakeCurrent() required > to restore the previous GL context is pretty expensive, so > applications that have a GL context current while calling into wined3d > take a considerable performance hit. I think I've only ever seen 1 or > 2 applications that were affected that though, so perhaps we don't > care enough. My point is that the current GL context is exposed through WGL but it also affects the behavior of GL functions (of course). So, while we might be able to hide the change of the current GL context from wglGetCurrentContext(), that doesn't do us any good because we need GL functions to target the right context. There's just no getting around switching the current GL context to WineD3D's when WineD3D needs to call GL functions and then back to the app's when control is returned to it. (Except Chris's point of doing all GL on a different thread.) Do you know what makes wglMakeCurrent() expensive? For X11, we'll still have to use glXMakeCurrent(), which sets the context drawable, even for my proposed wglMakeContextCurrentWINE(). Maybe it's the setting of the drawable that's expensive. For the Mac, we can just make the context current without setting the drawable again. That might be less expensive, although maybe there's a lot of thread state inside the GL engine that has to be swapped in and out. (I would hope that that would all be stored in the context and switching contexts would be just a matter of swapping a pointer somewhere.) >> Extension WGL_WINE_make_current: >> >> BOOL wglMakeContextCurrentWINE(HGLRC hglrc); >> >> The standard WGL function wglMakeCurrent() combines two operations. It sets the a GL context's drawable to the provided DC and it makes the GL context current for the thread. This new function, wglMakeContextCurrentWINE(), would only do the latter. It would make a GL context current for the thread without changing which DC it's associated with. Both the X11 and Mac drivers already maintain the necessary state to do that. They don't need to have the DC passed in again. (If a GL context is associated with separate draw and read DCs using wglMakeContextCurrentARB(), then this function will leave it associated with both DCs.) >> >> This allows WineD3D to faithfully restore the app's previously-current WGL context. This addresses bug 28869. >> > Maybe. Note that some of the quirk detection code renders to this > context. I think all rendering there goes to FBOs, so in that regard > it's probably safe, but it does feel a bit fragile. For regular > wined3d rendering we do of course need a drawable, although this may > work out in practice. I'm not sure I understand. "quirk detection code renders to this context" – to which context do you refer? The point of this extension is just for restoring the app's GL context. It would not necessarily be used to make a WineD3D context current, it would only be used to restore the app's WGL context to be current. It doesn't take a DC so that this works even for the case where the original DC was destroyed/released. (It could be used to make a WineD3D context current a second time, if you don't want to change the draw DC. But to associate the draw DC with the context the first time, you'd still use wglMakeCurrent().) > I think WGL_WINE_surface would work from wined3d's point of view, at > the very least interface wise. There are probably some details to work > out about how it should interact with gdi32 rendering and things like > the window moves, minimization, etc. I don't have as good of an > overview of how it would work out for winex11. I'm not so sure about > WGL_WINE_make_current, but it may be enough in practice. OK, thanks. I guess my next step will be to put together a patch to implement this all. I may do it quick-and-dirty at first just to prove the concept. I _think_ that window moves, etc. should be handled roughly as they are already. For a surface created from a window, things should work almost exactly as they currently do. The main difference would be where the pixel format is stored. With a window DC – how things currently work – it's conceptually stored as a property of the window. With a surface DC, it would be stored as a property of the surface. The other thing needing an update would be sync_gl_drawable(). That's for window moves and resizes. Currently, it looks up the single drawable for a given HWND. With surfaces, it would have to iterate over the surfaces for that window, as well. -Ken

Jan. 29, 2014

Re: [PATCH] shell32: Older shell32 doesn't support CSIDL_PROGRAM_FILES

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > This should fix the failing NT4 tests. > > These tests are _really_ old, like 2005. I'm surprised they haven't > been fixed by now. Is there something I'm missing? They should probably have been fixed back then, but at this point NT4 isn't worth the trouble anymore, we should simply get rid of it in the test results. -- Alexandre Julliard julliard(a)winehq.org

Jan. 29, 2014

Re: Fixing conflicts between WineD3D and WGL

by Henri Verbeet

On 29 January 2014 19:04, Chris Robinson <chris.kcat(a)gmail.com> wrote: > The multi-threaded command stream patches would fix this issue, wouldn't it? > In that case, WineD3D has a GL context on its own thread to handle the D3D > calls, leaving the app threads more or less alone. Of course, it'll be a > while before they get into Wine proper. It could, but only if we decide to enable CSMT even on uniprocessor systems, and only if we decide to do all GL calls in the worker thread, including e.g. resource maps and updates.

Jan. 29, 2014

Re: Fixing conflicts between WineD3D and WGL

by Chris Robinson

On 01/29/2014 03:10 AM, Henri Verbeet wrote: > There may be performance reasons though. The wglMakeCurrent() > required to restore the previous GL context is pretty expensive, so > applications that have a GL context current while calling into > wined3d take a considerable performance hit. I think I've only ever > seen 1 or 2 applications that were affected that though, so perhaps > we don't care enough. The multi-threaded command stream patches would fix this issue, wouldn't it? In that case, WineD3D has a GL context on its own thread to handle the D3D calls, leaving the app threads more or less alone. Of course, it'll be a while before they get into Wine proper.

Jan. 29, 2014

Re: [2/2] winhttp/tests: Only advance to the next notification test if the function is ok.

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://newtestbot.winehq.org/JobDetails.pl?Key=4521 Your paranoid android. === wvista (32 bit notification) === notification.c:363: Test failed: failed to receive response 12029 notification.c:368: Test failed: request failed unexpectedly 0 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 4 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 4 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 4 got 8 notification.c:99: Test failed: 441: expected status 0x00000008 got 0x00200000 notification.c:99: Test failed: 447: expected status 0x00000008 got 0x00200000 notification.c:455: Test failed: failed unexpectedly 12019 notification.c:456: Test failed: request failed unexpectedly 2293700 notification.c:460: Test failed: failed to query data available 12019 Timeout === w7pro64 (32 bit notification) === notification.c:455: Test failed: failed unexpectedly 12019 notification.c:456: Test failed: request failed unexpectedly 2686916 notification.c:460: Test failed: failed to query data available 12019 Timeout === w2008s64 (64 bit notification) === notification.c:359: Test failed: failed to send request 12029 notification.c:363: Test failed: failed to receive response 12017 notification.c:367: Test failed: failed unexpectedly 12019 notification.c:368: Test failed: request failed unexpectedly 4 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 3 got 8 === w7pro64 (64 bit notification) === notification.c:359: Test failed: failed to send request 12002 notification.c:363: Test failed: failed to receive response 12019 notification.c:368: Test failed: request failed unexpectedly 4 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:100: Test failed: 370: expected function 3 got 8

Jan. 29, 2014