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

Re: [1/2] winhttp/tests: Ignore some missing notifications.

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=4520 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 === 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 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 0 notification.c:460: Test failed: failed to query data available 12019 Timeout === w7pro64 (64 bit notification) === notification.c:100: Test failed: 447: expected function 3 got 4

Jan. 29, 2014

Re: Fixing conflicts between WineD3D and WGL

by Henri Verbeet

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. > There's a wrinkle having to do with the pixel format. User32 and the wineserver use the fact that a window has a pixel format to compute the "surface region" for the top-level window. This is a different "surface" than the concept central to this proposal. This "surface" is used for client-side GDI rendering using the DIB engine. Maintaining a surface region is necessary to prevent the contents of the window surface buffer from being blitted on top of any 3D rendering done to the window. To keep that functioning, the graphics drivers will still have to inform user32 that 3D rendering is being done to the window. It can do that using the existing mechanism, but that's not currently reversible because it's tied to the pixel format and that's a permanent property of a window. We'd like it to be reversible, since WineD3D can stop targeting a window. I'm thinking of using a count in user32. > Potentially related, http://bugs.winehq.org/show_bug.cgi?id=15232. I'm not entirely sure on all the details around WS_CLIPCHILDREN, particularly in fullscreen mode, but it's probably something else to keep in mind. > > 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. > What do folks think? Any feedback would be appreciated. > 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.

Jan. 29, 2014

Re: wininet: InternetGetConnectedStateExW must return TRUE for success

by Bruno Jesus

On Wed, Jan 29, 2014 at 7:48 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> - return LoadStringW(WININET_hModule, IDS_LANCONNECTION, lpszConnectionName, dwNameLen); >> + return LoadStringW(WININET_hModule, IDS_LANCONNECTION, lpszConnectionName, dwNameLen) ? TRUE : FALSE; > we're getting rid of "? TRUE : FALSE" constructs in Wine as those are > ugly and confusing. Oops, sorry. > In this case a "return LoadStringW() != 0;" or even "> 0" is better as > LoadString returns 0 on failure and a string length on success. Thank you, I'll resend when I get home. > bye > michael Best wishes, Bruno

Jan. 29, 2014

Re: [patch]: include : Add missing API to direct-x 9's shader header

by Henri Verbeet

On 28 January 2014 16:13, Kai Tietz <ktietz70(a)googlemail.com> wrote: > Resent patch without inlining. > Well, inline is prefered, but using git send-email makes it much easier to not mess that up. > +#define D3DXCONSTTABLE_LARGEADDRESSAWARE»······ 0x20000 You have a stray tab here. > -DEFINE_GUID(IID_ID3DXConstantTable, 0x9dca3190, 0x38b9, 0x4fc3, 0x92, 0xe3, 0x39, 0xc6, 0xdd, 0xfb, 0x35, 0x8b); > +DEFINE_GUID(IID_ID3DXConstantTable, 0xab3c758f, 0x93e, 0x4356, 0xb7, 0x62, 0x4d, 0xb1, 0x8f, 0x1b, 0x3a, 0x1); I may not have explicitly said this in my previous mail about this patch, but I think the headers should be consistent. So if you make this change, you can't keep D3DX_SDK_VERSION at 36. If you bump it to 43, there may be changes to other interfaces you need to make as well. This could also have consequences for the actual implementation. > + STDMETHOD(GetConstantBuffer)(THIS_ LPD3DXBUFFER *ppConstantBuffer) PURE; Please avoid names like "ppConstantBuffer" and typedefs like LPD3DXBUFFER unless required for compatibility. So e.g.: + STDMETHOD(GetConstantBuffer)(THIS_ ID3DXBuffer **constant_buffer) PURE;

Jan. 29, 2014

Re: wininet: InternetGetConnectedStateExW must return TRUE for success

by Michael Stefaniuc

Bruno, On 01/29/2014 02:27 AM, Bruno Jesus wrote: > Citavi relies on == TRUE comparison so return TRUE instead of != FALSE > > Fixes bug 17796 > > See http://bugs.winehq.org/show_bug.cgi?id=17796#c6 for AF analysis. > > > connect.txt > > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > index a49026c..e0f8f1b 100644 > --- a/dlls/wininet/internet.c > +++ b/dlls/wininet/internet.c > @@ -1219,7 +1219,7 @@ BOOL WINAPI InternetGetConnectedStateExW(LPDWORD lpdwStatus, LPWSTR lpszConnecti > WARN("always returning LAN connection.\n"); > *lpdwStatus = INTERNET_CONNECTION_LAN; > } > - return LoadStringW(WININET_hModule, IDS_LANCONNECTION, lpszConnectionName, dwNameLen); > + return LoadStringW(WININET_hModule, IDS_LANCONNECTION, lpszConnectionName, dwNameLen) ? TRUE : FALSE; we're getting rid of "? TRUE : FALSE" constructs in Wine as those are ugly and confusing. In this case a "return LoadStringW() != 0;" or even "> 0" is better as LoadString returns 0 on failure and a string length on success. bye michael

Jan. 29, 2014

Fixing conflicts between WineD3D and WGL

by Ken Thomases

Hi, This email brings together several threads of conversation that have been spread across different bug reports. Sorry for the length. The problem: WineD3D is based on WGL (a.k.a. opengl32). As a consequence, it conflicts with application use of WGL in a number of ways. It's also limited by WGL, which doesn't allow for all of the behaviors of DirectDraw and Direct3D. https://bugs.winehq.org/show_bug.cgi?id=28869 WineD3D needs to make its own GL context current temporarily and then restore the previous GL context, but WGL requires a DC to restore it and the DC may no longer be valid. https://bugs.winehq.org/show_bug.cgi?id=29301 WineD3D changes the window style of the device window when it should not. It needs to do that in order to render to the full screen where WGL only allows full-featured rendering to a window. https://bugs.winehq.org/show_bug.cgi?id=2082 Again, WineD3D is rendering to a window when it wants to render full-screen. In this case, the affected apps create an owned window that sits in front of the device window, obscuring it. http://bugs.winehq.org/show_bug.cgi?id=29934 WineD3D sets a pixel format on the application window. This conflicts with a later attempt by the app to set a different pixel format on the window via WGL. I think the solution to these problems is for WineD3D to have an alternative path to set up its GL context. Henri and I have been discussing using Wine-specific extensions to WGL to do this. There's already the extension WGL_WINE_pixel_format_passthrough which provides the wglSetPixelFormatWINE() function which is just like GDI's SetPixelFormat() and WGL's wglSetPixelFormat() except it allows for changing the pixel format after it's been set once. WineD3D needs to change it even though WGL doesn't allow that. In some of the bug reports listed above, I've suggested adding new extensions or modifying WGL_WINE_pixel_format_passthrough. We probably need a more comprehensive approach. WGL exposes various pieces of state to the application. Ideally, WineD3D would not alter any of that state since such alterations are visible to the app and Direct3D doesn't do that on Windows. I'm not sure that's achievable but we should at least minimize such visible state changes to the extent we can. WGL state: * The DC pixel format. For window DCs (which I believe are the only ones of real interest), this is actually a property of the window, not the DC. Changed by SetPixelFormat(), wglSetPixelFormat(); exposed by GetPixelFormat(), wglGetPixelFormat(). * The current GL context for the thread. Changed by wglMakeCurrent(), wglMakeContextCurrentARB(); exposed by wglGetCurrentContext(). * The DC for the current GL context. Changed by wglMakeCurrent(), wglMakeContextCurrentARB(); exposed by wglGetCurrentDC(), wglGetCurrentReadDCARB(). 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(). Here's my proposal: Extension WGL_WINE_surface: HANDLE wglCreateSurfaceWINE(HDC hdc, int pixel_format); // if hdc is GetDC(<some normal window>), a window surface is created // if hdc is GetDC(0), GetDC(GetDesktopWindow()), or CreateDC("display", …), a full-screen surface is created. // once the surface is created, it no longer refers to hdc void wglDestroySurfaceWINE(HANDLE surface); HDC wglGetSurfaceDCWINE(HANDLE surface); // Returns a DC created for the surface. This is not the DC passed in to wglCreateSurfaceWINE(). void wglReleaseSurfaceDCWINE(HANDLE surface, HDC hdc); This is somewhat modeled on WGL_ARB_pbuffer. <http://www.opengl.org/registry/specs/ARB/wgl_pbuffer.txt> A surface represents a "place" where GL can render, a potential target for a context. It can correspond to a Win32 window or it can be a full-screen surface. A full-screen surface will likely be a platform window (X11 or Mac) managed by the graphics driver but won't be a Win32 window. It should not interfere with mouse events or focus. A surface has a pixel format, similar to a window. Even if the surface was created from a window DC, its pixel format is independent of the window's. Since a surface is created with a pixel format, it shouldn't be necessary to set one with SetPixelFormat() on a surface DC. If it helps keep WineD3D's code simpler, we could allow it. I'm not sure if it will be necessary to support changing the pixel format after it's been set, using wglSetPixelFormatWINE(), or if the surface should just be destroyed and recreated as necessary. Doing the latter may eventually allow the removal of wglSetPixelFormatWINE(). The lifetime of a surface controls whatever resources the graphics driver has to manage for it. For a normal window, this may include a drawable. For a full-screen surface, this would include any full-screen platform window it might have created. WineD3D would obtain a DC from a surface using wglGetSurfaceDCWINE() just as it now obtains one for a window using GetDC(). There can be multiple DCs for a given surface. In particular, a DC can only be used on a single thread, so multiple threads would each have to get their own DC. The different lifetimes of surfaces vs. surface DCs is why this proposal differs from my approach in bug 2082, where I proposed an extension which just added full-screen DCs without a corresponding full-screen surface object. Destroying a surface while it still has extant surface DCs results in undefined behavior. Once WineD3D has a surface DC, it should be able to work with it as it currently does with window DCs. wglMakeCurrent() with a surface DC will associate the context with the surface drawable. For a surface created from a window, this would work as it does now in the graphics drivers with the exception of how the drawable is looked up from the DC. For a full-screen surface, this would target whatever full-screen drawable the graphics driver provides (possibly a platform window). There's a wrinkle having to do with the pixel format. User32 and the wineserver use the fact that a window has a pixel format to compute the "surface region" for the top-level window. This is a different "surface" than the concept central to this proposal. This "surface" is used for client-side GDI rendering using the DIB engine. Maintaining a surface region is necessary to prevent the contents of the window surface buffer from being blitted on top of any 3D rendering done to the window. To keep that functioning, the graphics drivers will still have to inform user32 that 3D rendering is being done to the window. It can do that using the existing mechanism, but that's not currently reversible because it's tied to the pixel format and that's a permanent property of a window. We'd like it to be reversible, since WineD3D can stop targeting a window. I'm thinking of using a count in user32. 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. I considered some other designs but I don't think they work well. I looked for a way to do without special DCs. We could directly specify a pixel format when creating a context rather than getting it from the window or surface via the DC. We could make a context current directly on a surface rather than a surface DC. Unfortunately, too much of WGL depends on having a DC. For example, ChoosePixelFormat() and wglSwapBuffers(). What do folks think? Any feedback would be appreciated. -Ken

Jan. 29, 2014

Re: gdiplus: Add tests for GetMetafileHeader functions.

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=4513 Your paranoid android. === wxppro (32 bit metafile) === metafile.c:338: Test failed: Expected 72.000000, got 81.279991 metafile.c:339: Test failed: Expected 72.000000, got 81.279991 metafile.c:372: Test failed: Expected 72.000000, got 81.279991 metafile.c:373: Test failed: Expected 72.000000, got 81.279991 metafile.c:399: Test failed: Expected 72.000000, got 81.279991 metafile.c:400: Test failed: Expected 72.000000, got 81.279991 === wvista (32 bit metafile) === metafile.c:338: Test failed: Expected 72.000000, got 81.279991 metafile.c:339: Test failed: Expected 72.000000, got 81.279991 metafile.c:372: Test failed: Expected 72.000000, got 81.279991 metafile.c:373: Test failed: Expected 72.000000, got 81.279991 metafile.c:399: Test failed: Expected 72.000000, got 81.279991 metafile.c:400: Test failed: Expected 72.000000, got 81.279991 === w2008s64 (32 bit metafile) === metafile.c:338: Test failed: Expected 72.000000, got 81.279991 metafile.c:339: Test failed: Expected 72.000000, got 81.279991 metafile.c:372: Test failed: Expected 72.000000, got 81.279991 metafile.c:373: Test failed: Expected 72.000000, got 81.279991 metafile.c:399: Test failed: Expected 72.000000, got 81.279991 metafile.c:400: Test failed: Expected 72.000000, got 81.279991 === w7pro64 (32 bit metafile) === metafile.c:338: Test failed: Expected 72.000000, got 81.279991 metafile.c:339: Test failed: Expected 72.000000, got 81.279991 metafile.c:372: Test failed: Expected 72.000000, got 81.279991 metafile.c:373: Test failed: Expected 72.000000, got 81.279991 metafile.c:399: Test failed: Expected 72.000000, got 81.279991 metafile.c:400: Test failed: Expected 72.000000, got 81.279991 === w2008s64 (64 bit metafile) === metafile.c:338: Test failed: Expected 72.000000, got 81.279999 metafile.c:339: Test failed: Expected 72.000000, got 81.279999 metafile.c:372: Test failed: Expected 72.000000, got 81.279999 metafile.c:373: Test failed: Expected 72.000000, got 81.279999 metafile.c:399: Test failed: Expected 72.000000, got 81.279999 metafile.c:400: Test failed: Expected 72.000000, got 81.279999 === w7pro64 (64 bit metafile) === metafile.c:338: Test failed: Expected 72.000000, got 81.279991 metafile.c:339: Test failed: Expected 72.000000, got 81.279991 metafile.c:372: Test failed: Expected 72.000000, got 81.279991 metafile.c:373: Test failed: Expected 72.000000, got 81.279991 metafile.c:399: Test failed: Expected 72.000000, got 81.279991 metafile.c:400: Test failed: Expected 72.000000, got 81.279991

Jan. 28, 2014

FOSDEM planning - last mailing list warning

by Jeremy White

Hi folks, This is it. If you are not subscribed to the wineconf mailing list, but you're planning to be at FOSDEM, you are going to be left out of all the cool parties and fun. We'll move our chatter and planning exclusively to that email list. So, if you're coming to FOSDEM, and you didn't get two copies of this email, sign up for it now: http://www.winehq.org/mailman/listinfo/wineconf Cheers, Jeremy

Jan. 28, 2014

Re: shell32/tests: Add test for GetLastError in shlfileop

by Zhenbo Li

2014-01-28 Dmitry Timoshkov <dmitry(a)baikal.ru>: > > Before starting to change anything just explain (to yourself first) > 'what you are trying to achieve' and even before that 'whether you have > investigated the problem, understand what is going on, and what exactly > the problem is that you are trying to fix'. Thank you for your advice. -- Have a nice day! Zhenbo Li

Jan. 28, 2014

Re: shell32/tests: Add test for GetLastError in shlfileop

by Dmitry Timoshkov

Zhenbo Li <litimetal(a)gmail.com> wrote: > As MSDN[1] said, "Do not use GetLastError with the return values of this > (SHFileOperation) function." > > I think wine's implement of SHFileOperation needs a big change. > Before hacking it, I hope there could be sufficient testcases to > help me understand that function. It doesn't matter what MSDN says or doesn't say, what matters is what applications depend upon. > I think wine's implement of SHFileOperation needs a big change. > Before hacking it, I hope there could be sufficient testcases to > help me understand that function. Before starting to change anything just explain (to yourself first) 'what you are trying to achieve' and even before that 'whether you have investigated the problem, understand what is going on, and what exactly the problem is that you are trying to fix'. -- Dmitry.

Jan. 28, 2014