August 2006 - Wine-devel - list.winehq.org

Re: Patch to riched20 (resubmission)
by Huw Davies 28 Aug '06

28 Aug '06

On Sun, Aug 27, 2006 at 05:35:54PM -0700, Mark Lu wrote: > If the rtf control is a child window AND it doesn't display its own context > menu, > then the WM_CONTEXTMENU message should be passed to the parent window in > the rtf > control's DefWindowProc. Here is what MSDN says on the subject: > > "If a window does not display a shortcut menu it should pass this message > to the DefWindowProc function. If a window is a child window, > DefWindowProc > sends the message to the parent. Otherwise, DefWindowProc displays a > default > shortcut menu if the specified position is in the window's caption." You mention the DefWindowProc behaviour here... > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -2318,7 +2319,11 @@ LRESULT WINAPI RichEditANSIWndProc(HWND > ME_SelectWord(editor); > break; > case WM_CONTEXTMENU: > - ME_ShowContextMenu(editor, (short)LOWORD(lParam), > (short)HIWORD(lParam)); > + if (!ME_ShowContextMenu(editor, (short)LOWORD(lParam), > (short)HIWORD(lParam))) > + { > + if (GetWindowLongW( hWnd, GWL_STYLE ) & WS_CHILD) > + SendMessageW( GetParent(hWnd), msg, wParam, lParam ); > + } > break; > case WM_PAINT: > if (editor->bRedraw) ...yet here you send the message to the parent yourself. Why can't you replace this with a 'goto do_default;' and let DefWindowProc do this for you? Huw.

2 1

Re: shlwapi: Fix writing an empty DataBlock list in SHWriteDataBlockList() (2nd resend)
by Alexandre Julliard 28 Aug '06

28 Aug '06

Thomas Weidenmueller <wine-patches(a)reactsoft.com> writes: > --- dlls/shlwapi/clist.c 23 May 2006 12:48:43 -0000 1.12 > +++ dlls/shlwapi/clist.c 24 May 2006 17:23:15 -0000 > @@ -29,6 +29,8 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(shell); > > +#include "pshpack1.h" > + > /* DataBlock list element (ordinals 17-22) */ > typedef struct tagSHLWAPI_CLIST That doesn't look right. Why do you need to change the packing? -- Alexandre Julliard julliard(a)winehq.org

1 0

Patch not applied.
by Renu Rajput 28 Aug '06

28 Aug '06

Hi I've tried submitting a patch to wine-patches 3 times(as per feedback from Wine group), but it has not been applied yet. Please tell me what I am doing wrong. Thanks Renu Here's the patch: diff -urN OldDir/dlls/comdlg32/filedlg.c NewDir/dlls/comdlg32/filedlg.c --- OldDir/dlls/comdlg32/filedlg.c 2006-08-10 18:45:12.000000000 +0530 +++ NewDir/dlls/comdlg32/filedlg.c 2006-08-11 16:09:32.000000000 +0530 @@ -2011,7 +2011,10 @@ IPersistFolder2_Release(ppf2); if( ! COMDLG32_PIDL_ILIsEqual(pidlCurrent, fodInfos-> ShellInfos.pidlAbsCurrent)) { - IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser, pidlCurrent, SBSP_ABSOLUTE); + if (SUCCEEDED(IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser, pidlCurrent, SBSP_ABSOLUTE))) + { + SendCustomDlgNotificationMessage(hwnd, CDN_FOLDERCHANGE); + } } else if( nOpenAction == ONOPEN_SEARCH ) {

2 1

Re : [DDRAW] Only detach surfaces when releasing a non-texture surface attached to a complex root.
by Elie Morisse 28 Aug '06

28 Aug '06

Le 27.08.2006 19:23:53, Elie Morisse a écrit : > Refcounting fix, Wine devs tell me if I'm wrong as from now on I get something like this w/ The Nomad Soul : > > fixme:d3d:IWineD3DDeviceImpl_Release (0x1248028) Device released with resources still bound, acceptable but unexpected > fixme:d3d:dumpResources Leftover resource 0x217f988 with type 1,WINED3DRTYPE_SURFACE > fixme:d3d:dumpResources Leftover resource 0x1abca8 with type 1,WINED3DRTYPE_SURFACE > > Other games I tried aren't affected though, so this one may just be buggy.. > Good part is this prevents memory faults in The Nomad Soul at exit and when switching resolution. > > Please use this one instead, it fixes a regression in Moto Racer 2 ( detach surfaces of complex attached surfaces when releasing the root ).

1 0

Re: [DDRAW] Only detach surfaces when releasing a non-texture surface attached to a complex root.
by Stefan Dösinger 28 Aug '06

28 Aug '06

Am Sonntag 27 August 2006 17:23 schrieb Elie Morisse: > Refcounting fix, Wine devs tell me if I'm wrong as from now on I get > something like this w/ The Nomad Soul : > > fixme:d3d:IWineD3DDeviceImpl_Release (0x1248028) Device released with > resources still bound, acceptable but unexpected fixme:d3d:dumpResources > Leftover resource 0x217f988 with type 1,WINED3DRTYPE_SURFACE > fixme:d3d:dumpResources Leftover resource 0x1abca8 with type > 1,WINED3DRTYPE_SURFACE > > Other games I tried aren't affected though, so this one may just be buggy.. > Good part is this prevents memory faults in The Nomad Soul at exit and when > switching resolution. Just asking, does this game hit the This->first_attached != This case? This shouldn't happen, I suspect that the refcounting issue is somewhere else. Also the This->first_complex == This check should always return true in theory. Can you send me a +ddraw,+d3d7 trace of the game, with and without your patch?

2 1

Building Wine with the lsb sdk
by Dan Kegel 28 Aug '06

28 Aug '06

I've been a longtime fan of the idea behind the LSB, i.e. build once, run everywhere. (If you're an anti-fan of the LSB, please kindly skip this message.) So tonight I downloaded the current LSB SDK from http://www.freestandards.org/en/Download and gave it a shot. Here's the script I came up with: #!/bin/sh set -ex PATH=/opt/lsb/bin:$PATH CC=lsbcc CXX=lsbc++ export CC export CXX # Must define RTLD_DEFAULT because of http://bugs.linuxbase.org/show_bug.cgi?id=375 # Must define MAP_FILE because it's not in Unix's SUS3 # Must disable linux/videodev.h as it's not supported by the LSB, # and won't compile with lsbcc LSBCC_SHAREDLIBS=wine export LSBCC_SHAREDLIBS ac_cv_header_linux_videodev_h=no \ ./configure --prefix=/usr/local/wine-lsb make depend LDFLAGS=-ldl make LDFLAGS=-ldl CFLAGS="-g -O2 \"-DRTLD_DEFAULT=((void *)0)\" -DMAP_FILE=0" This worked past a number of problems, but the build breaks with the error /opt/lsb/include/unistd.h:342: error: syntax error before 'Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library' while building dlls/comctl32/tests/imagelist.c The fix is not obvious. I'll try giving it another look sometime this week. - Dan

1 1

DIB Engine
by satyr_22901＠yahoo.com 27 Aug '06

27 Aug '06

Hi, I've recently tried to play Heroes of Might and Magic IV under Wine, which has very poor performance and this message it printed out many, many times after the game is started: fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy After doing some digging it appears the problem is the current DIB engine or lack thereof (the DIBEngine page on the Wine wiki and the bugzilla bug it links to are very useful). From what I can tell this has been a known shortcoming in Wine for at least 4.5 - 5 years, with a few partial patches created three or four years ago. Is (or has) there any recent (less than a year old) work being done on creating a more efficient DIB engine for Wine? If not, has anyone looked into using a library like EVAS or Cairo as a foundation for implementing it? Before anyone asks, yes I'm a newbie in terms of hacking on Wine or working with device independent bitmaps under Windows, and yes I am volunteering to help work on an improved DIB engine. :) Thanks, Brian P.S. I've run other games such as Diablo II and Total Annihilation (including more recently being able to use TA: Mutation) under Wine and they work beautifully. Keep up the good work! Jen: Wings? I don't have wings! Kira: Of course not. You're a boy. - from "The Dark Crystal" __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

9 10

Re: [DDRAW] Only detach surfaces when releasing a non-texture surface attached to a complex root.
by Stefan Dösinger 27 Aug '06

27 Aug '06

Am Sonntag 27 August 2006 17:23 schrieb Elie Morisse: > Refcounting fix, Wine devs tell me if I'm wrong as from now on I get > something like this w/ The Nomad Soul : > > fixme:d3d:IWineD3DDeviceImpl_Release (0x1248028) Device released with > resources still bound, acceptable but unexpected fixme:d3d:dumpResources > Leftover resource 0x217f988 with type 1,WINED3DRTYPE_SURFACE > fixme:d3d:dumpResources Leftover resource 0x1abca8 with type > 1,WINED3DRTYPE_SURFACE > > Other games I tried aren't affected though, so this one may just be buggy.. > Good part is this prevents memory faults in The Nomad Soul at exit and when > switching resolution. Not so sure about this yet, the patch seems to contain a lot of indention changes, it is a bit hard to read. Can you check this with the moto racer 2 demo? It is a bit nasty in terms of refcounting

1 0

Test showing GetShortPathNameW problem preventing msi from installing .NET 1.1
by Robert Reif 27 Aug '06

27 Aug '06

This test shows the problem that msi is having installing .Net 1.1. Could someone familiar with this code have a look at it please? diff -p -u -r1.36 path.c --- dlls/kernel/tests/path.c 14 Jun 2006 11:54:23 -0000 1.36 +++ dlls/kernel/tests/path.c 26 Aug 2006 15:53:13 -0000 @@ -929,6 +929,16 @@ static void test_GetTempPath(void) SetEnvironmentVariableA("TMP", save_TMP); } +static void test_GetShortPathNameW(void) +{ + WCHAR nameW[] = { 'c',':','\\','w','i','n','d','o','w','s','\\','M','i','c','r','o','s','o','f','t','.','N','E','T','\\','F','r','a','m','e','w','o','r','k','\\','v','1','.','1','.','4','3','2','2','\\','1','0','3','3','\\','v','b','c','7','u','i','.','d','l','l',0 }; + DWORD size; + + size = GetShortPathNameW( nameW, NULL, 0 ); + + ok(size > 0, "GetShortPathNameW() failed\n"); +} + START_TEST(path) { CHAR origdir[MAX_PATH],curdir[MAX_PATH], curDrive, otherDrive; @@ -939,4 +949,5 @@ START_TEST(path) test_PathNameA(curdir, curDrive, otherDrive); test_CleanupPathA(origdir,curdir); test_GetTempPath(); + test_GetShortPathNameW(); }

3 3

Re: WineD3D: Sample from the correct source when using older pixel shaders
by Ivan Gyurdiev 27 Aug '06

27 Aug '06

Stefan Dösinger wrote: > Pre 2.0 pixel shaders do not contain a tag for the texture type to sample > from. Wine had 2D textures hardcoded, this patch checks the bound texture > type to decide from which texture to sample from. For >= 2.0 shaders the > shader tag is still used. > Why can't this be done in a much cleaner way where the sampler is initialized (2nd pass, baseshader, get_registers_used)? Then you don't have to copy and paste the same thing in many places - there's 10 texture instructions or something like that for pixel shaders alone. Also, maybe the stateblock should be passed as an argument to all functions that use its states. I don't like walking up the tree to find what you need (this->wineD3Ddevice) - it's a hidden dependency on device state, which isn't even all the time - that's why you had to move the point where the shader is compiled [ this needs better documentation ]. Similarly, I think the code would be cleaner if projected sampling vs regular was retrieved from the stateblock, and stored somewhere else, at the point when the sampler is initialized.

3 5