July 2009 - Wine-Devel - list.winehq.org

Re: [PATCH 1/6] wined3d: Keep track of a thread's wined3d context.
by Alexandre Julliard July 22, 2009

July 22, 2009

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > --- > dlls/wined3d/context.c | 81 +++++++++++++++++++++++++++++---------- > dlls/wined3d/wined3d_main.c | 40 ++++++++++++++++++++ > dlls/wined3d/wined3d_private.h | 5 ++ > 3 files changed, 105 insertions(+), 21 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so d3d.c && touch d3d.ok wine: Unhandled page fault on read access to 0x005cab9c at address 0x68e9e94a (thread 0043), starting debugger... Unhandled exception: page fault on read access to 0x005cab9c in 32-bit code (0x68e9e94a). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68e9e94a ESP:0032f7b0 EBP:0032f7d8 EFLAGS:00010206( R- -- I - -P- ) EAX:0012e9d8 EBX:68ef4194 ECX:00000001 EDX:0012e9d8 ESI:001bbda0 EDI:00000000 Stack dump: 0x0032f7b0: 000084e0 0032f7c8 00185bf0 0012ea18 0x0032f7c0: 00000000 00000000 0012e9d8 68ef4194 0x0032f7d0: 00000000 001bbda0 0032f908 68ea9045 0x0032f7e0: 0012e9d8 00000000 00000001 0032f8f8 0x0032f7f0: 0032f8f4 0032f8f0 0032f8ec 0032f8e8 0x0032f800: 00000000 00000000 00000000 00000000 Backtrace: =>0 0x68e9e94a surface_bind_and_dirtify+0x4a(This=0x1bbda0, srgb=0) [/home/julliard/wine/wine/dlls/wined3d/surface.c:321] in wined3d (0x0032f7d8) 1 0x68ea9045 IWineD3DSurfaceImpl_LoadLocation+0x185(iface=<register EDI not in topmost frame>, flag=64, rect=(nil)) [/home/julliard/wine/wine/dlls/wined3d/surface.c:4878] in wined3d (0x0032f908) 2 0x68e9b17e IWineD3DSurfaceImpl_LoadTexture+0x5e(iface=<register EDI not in topmost frame>, srgb_mode=0) [/home/julliard/wine/wine/dlls/wined3d/surface.c:2598] in wined3d (0x0032f938) 3 0x68e9e70b surface_internal_preload+0xcb(iface=<register ESI not in topmost frame>, srgb=SRGB_RGB) [/home/julliard/wine/wine/dlls/wined3d/surface.c:804] in wined3d (0x0032f978) 4 0x68dfc756 context_apply_attachment_filter_states+0xf6(surface=<register ESI not in topmost frame>, force_preload=<is not available>) [/home/julliard/wine/wine/dlls/wined3d/context.c:181] in wined3d (0x0032f9e8) 5 0x68dfcd4c context_attach_depth_stencil_fbo+0x9c(context=0x185bf0, fbo_target=36160, depth_stencil=<register ESI not in topmost frame>, use_render_buffer=0) [/home/julliard/wine/wine/dlls/wined3d/context.c:223] in wined3d (0x0032fab8) 6 0x68ea80e4 surface_load_ds_location+0x414(iface=<register EDI not in topmost frame>, location=4194304) [/home/julliard/wine/wine/dlls/wined3d/surface.c:4448] in wined3d (0x0032fb88) 7 0x68e1391a IWineD3DDeviceImpl_SetDepthStencilSurface+0x1aa(iface=<register EDI not in topmost frame>, pNewZStencil=(nil)) [/home/julliard/wine/wine/dlls/wined3d/device.c:6613] in wined3d (0x0032fbb8) 8 0x686b8e2f IDirectDrawSurfaceImpl_Release+0x32f(iface=0x128ab8) [/home/julliard/wine/wine/dlls/ddraw/surface.c:315] in ddraw (0x0032fc08) 9 0x686550bd func_d3d+0x16ad() [/home/julliard/wine/wine/dlls/ddraw/tests/d3d.c:178] in ddraw_test (0x0032fde8) 10 0x68674640 run_test+0x130(name="d3d.c") [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:456] in ddraw_test (0x0032fe28) 11 0x6867482e main+0x11e(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:505] in ddraw_test (0x0032fed8) 12 0x68675044 __wine_spec_exe_entry+0x84(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ddraw_test (0x0032ff08) 13 0x7b878c90 start_process+0x130(arg=(nil)) [/home/julliard/wine/wine/dlls/kernel32/process.c:955] in kernel32 (0x0032ffe8) 14 0x6802bc7d wine_call_on_stack+0x1d() in libwine.so.1 (0x00000000) 0x68e9e94a surface_bind_and_dirtify+0x4a [/home/julliard/wine/wine/dlls/wined3d/surface.c:321] in wined3d: movl 0xfffe1a64(%edx,%eax,4),%eax 321 active_sampler = This->resource.wineD3DDevice->rev_tex_unit_map[active_texture - GL_TEXTURE0_ARB]; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [winhttp/tests] Fix a test failure on some W2K/XP systems
by Nicolas Le Cam July 22, 2009

July 22, 2009

2009/7/22 Paul Vriens <paul.vriens.wine(a)gmail.com>: > Changelog > Fix a test failure on some W2K/XP systems > > -- > Cheers, > > Paul. > > From f9708be5421888568cacfd5144aec0ea0a7877ce Mon Sep 17 00:00:00 2001 > From: Paul Vriens <Paul.Vriens.Wine(a)gmail.com> > Date: Wed, 22 Jul 2009 11:30:01 +0200 > Subject: [PATCH] Fix a test failure on some W2K/XP systems > > --- > dlls/winhttp/tests/winhttp.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/winhttp/tests/winhttp.c b/dlls/winhttp/tests/winhttp.c > index bce91fe..d74b9c2 100644 > --- a/dlls/winhttp/tests/winhttp.c > +++ b/dlls/winhttp/tests/winhttp.c > @@ -939,7 +939,8 @@ static void test_set_default_proxy_config(void) > info.lpszProxy = wideString; > SetLastError(0xdeadbeef); > ret = WinHttpSetDefaultProxyConfiguration(&info); > - ok(!ret && GetLastError() == ERROR_INVALID_PARAMETER, > + ok((!ret && GetLastError() == ERROR_INVALID_PARAMETER) || > + broken(ret), /* Earlier winhhtp versions on W2K/XP */ > "expected ERROR_INVALID_PARAMETER, got %d\n", GetLastError()); > > info.lpszProxy = normalString; > -- > 1.6.0.6 > > > > > Hi Paul, You did a small typo here. winhhtp -> winhttp Bye -- Nicolas Le Cam

1 0

Re: user32: Draw the whole button only if requested.
by Alexandre Julliard July 22, 2009

July 22, 2009

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -847,7 +847,8 @@ static void PB_Paint( HWND hwnd, HDC hDC, UINT action ) > if (state & (BUTTON_CHECKED | BUTTON_3STATE)) > uState |= DFCS_CHECKED; > > - DrawFrameControl( hDC, &rc, DFC_BUTTON, uState ); > + if (action == ODA_DRAWENTIRE) > + DrawFrameControl( hDC, &rc, DFC_BUTTON, uState ); It doesn't seem right to do only half the drawing operations. If we are not doing ODA_DRAWENTIRE then we should be drawing only the focus rect, like the other button types do. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3d8: Fix the null condition in ApplyStateBlock
by Henri Verbeet July 22, 2009

July 22, 2009

Is 0 really special here, or should invalid handles in general just return D3D_OK? I imagine this affects IDirect3DDevice8Impl_CaptureStateBlock() as well.

1 0

Problems with macro preprocessing in wrc
by Frédéric Delanoy July 21, 2009

July 21, 2009

Hi all, I was just looking at "bug 7304: WRC (Wine Resource Compiler) preprocessing is buggy" [http://bugs.winehq.org/show_bug.cgi?id=7304 , still present in 1.1.26] and wondered: why implement a custom macro preprocessor while others already exist (e.g. m4) and have been around/debugged for ages? Is it just to reduce dependencies requirements of Wine? or is it simply too difficult to integrate? Frédéric

1 0

Re: please reduce the four registrations on the single winehq.org site.
by Dan Kegel July 21, 2009

July 21, 2009

Steven Edwards wrote: > Based upon my recollection there was a lot of contempt for OpenID at > the last wineconf. Maybe the situation has changed recently... For those new to the story, OpenID is incredibly insecure. See for example http://marcoslot.net/apps/openid/ http://www.gnucitizen.org/blog/hijacking-openid-enabled-accounts/ http://www.techafina.com/posts/openid-benefits-and-risks/ http://kuza55.blogspot.com/2007/01/insecure-openid-features.html Moreover, it's hard to use, as shown by usability testing at Yahoo: http://www.betanews.com/article/Yahoo-usability-tests-bode-ill-for-OpenID-t… In short: if you care about your data or your identity, stay far away from OpenID. Now, if you absolutely must use OpenID, there are people working on making it more secure. For instance, Google is giving it a shot; see http://google-code-updates.blogspot.com/2009/05/google-openid-api-taking-ne… But I doubt the wine community wants to go there. Better to implement a plain old shared password database between our four services. - Dan

2 2

Re: [2/2] winapi_extract: The old C parser is not needed anymore so remove it.
by Paul Vriens July 21, 2009

July 21, 2009

Francois Gouget wrote: > --- > tools/winapi/winapi_c_parser.pm | 264 -------------------------------- > tools/winapi/winapi_extract | 8 +- > tools/winapi/winapi_extract_options.pm | 7 +- > 3 files changed, 4 insertions(+), 275 deletions(-) > delete mode 100644 tools/winapi/winapi_c_parser.pm > Hi Francois, After this patch, we can't run "./tools/winapi/winapi_extract --pseudo-stub-statistics" any more: dlls/actxprxy/dlldata.c:21.2: file: } without {: \ It looks like this is the reason our winapi_stats webpage isn't up-to-date? (Checked after seeing that email chain on wine-devel "Status of the Status pages?"). -- Cheers, Paul.

2 1

Re: WW2 fighters fix
by Paul Vriens July 21, 2009

July 21, 2009

Alexandre Hardy wrote: > WW2 Fighters fails to display any in game graphics when in OpenGL > mode apparantly as a result of specifying both NORMAL and FULLSCREEN > flags to Direct Draw. The patch attached prints a warning instead > of failing to apply the settings. The patch has been tested on wine-1.1.24 > and earlier versions (1.1.21, 1.1.22). > > Alexandre Hardy > > > ------------------------------------------------------------------------ > > Hi, The subject of the patch should be a but more describing what it actually does (and include the dll/module it's touching). Another thing is that these kind of changes need tests. You can extend the current tests quite easily. I don't know anything about these modes (or if the combinations I show below actually make sense) but 2 quick tests on Windows 2003: DDSCL_NORMAL | DDSCL_EXCLUSIVE : DDERR_INVALIDPARAMS DDSCL_NORMAL | DDSCL_FULLSCREEN : DD_OK -- Cheers, Paul.

2 1

Re: WW2 fighters fix
by Stefan Dösinger July 21, 2009

July 21, 2009

Am Monday 20 July 2009 15:45:28 schrieb Alexandre Hardy: > WW2 Fighters fails to display any in game graphics when in OpenGL > mode apparantly as a result of specifying both NORMAL and FULLSCREEN > flags to Direct Draw. The patch attached prints a warning instead > of failing to apply the settings. The patch has been tested on wine-1.1.24 > and earlier versions (1.1.21, 1.1.22). Hi, Please write a test for this and add it to dlls/ddraw/tests/ddrawmodes.c It might happen that Windows returns an error in this situation. I think we already have a test that shows that DDSCL_FULLSCREEN without DDSCL_EXCLUSIVE(and vice versa) is not permitted, so I think setting DDSCL_EXCLUSIVE in the if case is wrong. Also please use the code layout of the surrounding code.

1 0

suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
by Joerg-Cyril.Hoehle＠t-systems.com July 21, 2009

July 21, 2009

Dear Mac developers, please make suggestions about the xyz_LIBRARY_PATH MacOS issue that allows libpng.so and libfreetype.so to be found at run-time in /usr/X11/lib (bug 17674). A patch appending /usr/X11/lib to DYLD_FALLBACK_LIBRARY_PATH, much like Mike Kronenberg and MacPorts do, was rejected. http://www.winehq.org/pipermail/wine-patches/2009-July/075290.html Alexandre Julliard explained to me that he feels the xyz_LIBRARY_PATH feels bad being specific to Wine. He believes that all X11 apps should be affected and this issue be solved at "system level". Why aren't X11 apps affected on my machine? From the manpages, I believe the issue is specific to dlopen(), not regular shared libraries. Few apps use dlopen(). Configure detects these libraries precisely because it does not use dlopen(). So either we can convince AJ that is issue is specific to Wine, or the best that can be done on MacOS, or file a bug with Apple, or we need another solution. - Emmanuel Maillard had a patch specific to libfreetype in wineQuartz for 0.9.58, prepending the output of get_runtime_libdir() prior to calling wine_dlopen(). I object that this would have to be repeated for every other particular .so that Wine happens to use, e.g. libpng -- not very nice. (I also don't understand why get_runtime_libdir() would have helped, /usr/X11/lib is needed for these two libraries). - Other suggestions? Thanks for your help, Jörg Höhle.

8 27