September 2011 - Wine-devel

Re: [1/5] ddraw: Add some NULL pointer tests
by Marvin 05 Sep '11

05 Sep '11

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=13949 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

2 1

Re: [PATCH 2/4] wined3d: Git rid of the rect checks for present in IWineD3DSurfaceImpl_BltOverride().
by Stefan Dösinger 05 Sep '11

05 Sep '11

On Sunday 04 September 2011 22:43:50 Henri Verbeet wrote: > These are no longer needed since present can handle these now. I think we can remove the entire special case and just do a blit. This hack is related to the ddraw windowed backbuffer hack you removed a while ago, except that the back->front blit is used by a handful of fullscreen apps too.

2 3

Re: [2/4] msi/tests: Fix a number of test messages.
by Marvin 05 Sep '11

05 Sep '11

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=13969 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5996: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon) === WXPPROSP3 (32 bit install) === Timeout

1 0

Re: [2/3] winhttp/tests: Initialize a variant with a known value.
by Marvin 05 Sep '11

05 Sep '11

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=13968 Your paranoid android. === W7PRO (32 bit winhttp) === winhttp.c:1971: Test failed: failed to send request 12152 winhttp.c:1977: Test failed: got 12019

1 0

Re: cmd: Avoid rereading batch file for every call/goto executed (try 2)
by Octavian Voicu 05 Sep '11

05 Sep '11

2011/9/5 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > + static WCHAR string[MAX_PATH]; Why make this static? It's only a temporary buffer and it's only used once, when building the cache. Octavian

2 1

Re: cmd: Avoid unneeded local variable in WCMD_goto
by Frédéric Delanoy 04 Sep '11

04 Sep '11

2011/9/4 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > --- > programs/cmd/builtins.c | 9 ++++----- > 1 files changed, 4 insertions(+), 5 deletions(-) Please ignore this patch. The changes it brings are incorporated in another patch ("cmd: Avoid rereading batch file for every call/goto executed") Frédéric

1 0

WINEDEBUG=warn+heap make test crashes in dsound?
by Dan Kegel 04 Sep '11

04 Sep '11

Hi Michael, is this up your alley? You've been looking at dsound recently, iirc. - Dan export WINEDEBUG=warn+heap ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so ds3d.c && touch ds3d.ok ALSA lib pcm_pulse.c:1008:(_snd_pcm_pulse_open) Unknown field handle_underrun ... ds3d.c:467: Test failed: buffer size changed after SetFormat() - previous size was 88200, current size is 22052 fixme:dsound3d:IDirectSound3DListenerImpl_QueryInterface Unknown IID {31efac30-515c-11d0-a9aa-00aa0061be93} wine: Unhandled page fault on read access to 0xfeef021a at address 0x68d6775f (thread 002c), starting debugger... Backtrace: =>0 0x68d6775f IDirectSound3DListenerImpl_Release+0xe9(iface=0x1d5170) [/home/dank/wine-git/dlls/dsound/sound3d.c:791] in dsound (0x0033f768) 1 0x684bce32 test_primary_3d_with_listener+0x677(lpGuid=(nil)) [/home/dank/wine-git/dlls/dsound/tests/ds3d.c:1228] in dsound_test (0x0033f868) 2 0x684bd181 dsenum_callback+0x183(lpGuid=(nil), lpcstrDescription="Primary Sound Driver", lpcstrModule="", lpContext=0x0(nil)) [/home/dank/wine-git/dlls/dsound/tests/ds3d.c:1283] in dsound_test (0x0033f8a8) 3 0x68d558e4 a_to_w_callback+0xe0(guid=(nil), descW="Primary Sound Driver", modW="", data=0x33fc80) [/home/dank/wine-git/dlls/dsound/dsound_main.c:291] in dsound (0x0033f938) 4 0x68d55c3b DirectSoundEnumerateW+0x2ab(lpDSEnumCallback=0x68d55803, lpContext=0x33fc80) [/home/dank/wine-git/dlls/dsound/dsound_main.c:370] in dsound (0x0033fc68) 5 0x68d55985 DirectSoundEnumerateA+0x88(lpDSEnumCallback=0x684bcffd, lpContext=0x0(nil)) [/home/dank/wine-git/dlls/dsound/dsound_main.c:321] in dsound (0x0033fc98) 6 0x684bd50d ds3d_tests+0x2a() [/home/dank/wine-git/dlls/dsound/tests/ds3d.c:1307] in dsound_test (0x0033fcc8) 7 0x684bd5cd func_ds3d+0x7b() [/home/dank/wine-git/dlls/dsound/tests/ds3d.c:1326] in dsound_test (0x0033fcf8) 8 0x684d04d3 run_test+0x9e(name="ds3d.c") [/home/dank/wine-git/dlls/dsound/tests/../../../include/wine/test.h:556] in dsound_test (0x0033fd58)

2 1

RFC - The ProductName registry entry
by Bruno Jesus 04 Sep '11

04 Sep '11

Louis Lenders sent the following url patch to fix bug #28065, it was rejected because it fixes the product name so even if you set other version inside winecfg the registry entry will still say "Windows XP". http://www.winehq.org/pipermail/wine-patches/2011-August/105414.html I have made a small change to winecfg to make it save the correct ProductName based on the selected OS and would like comments. If I ever send my patch to git Louis Lenders patch will need to get in too because we would need a default ProductName setting in registry and his patch was correct because the default wine OS is XP, am I right? The patch is quite simple and it tries to never let 2 ProductName exist in different windows versions. Thanks in advance, Bruno

1 0

bug in OLEPictureImpl_Load (and possibly other stream readers)
by Michael Blumenkrantz 04 Sep '11

04 Sep '11

Hi, I have been working with Bernhard Loos (jhgf) for the past couple days to track down the source of http://bugs.winehq.org/show_bug.cgi?id=28235, and today I am happy to report that I have finally located it!. Attached are two files: olefail.cpp - the source olefail.txt - actually olefail.exe renamed to evade mailing list filters :) This is a tiny demo app, most of which is copied right out of MSDN, which showcases the problem. To break it down: *On Windows, OLEPictureImpl_Load will read exactly 2 bytes for the header to attempt to determine the length in the case that the stat() member function of the stream interface is broken. This is acknowledged in a large block comment at olepicture.c:1339. Wine then ignores this fact and reads 8 bytes. This is just the tip of the bug, however! *The major bug is that after this, at olepicture.c:1412, wine decides to attempt to read a buffer of unknown size and content UNTIL THE END OF THE BUFFER. While this may work for reading a string, when reading a binary buffer you MUST know the size. I'm sure we all know this :) *Unless the stream reader interface is fairly smart at this point and returns 0 bytes read (which seems unlikely if the stat() mechanism is broken), wine is guaranteed to crash. The solution here is to remove the broken "try until you die" method of attempting to read more than 2 bytes of the unknown buffer. Instead, simply return an error as Windows does and move on.

1 0

Re: [PATCH 1/2] d3dx9: Do not allocate ctab memory, reuse the shader blob.
by Rico Schüller 03 Sep '11

03 Sep '11

Please do not apply, it breaks some else which doesn't have a test, yet. Am 03.09.2011 09:32, schrieb Rico Schüller: > --- > dlls/d3dx9_36/shader.c | 11 +--------- > dlls/d3dx9_36/tests/shader.c | 43 > ++++++++++++++++++++++++++++++++--------- > 2 files changed, 34 insertions(+), 20 deletions(-) > > > >

1 0