June 2015 - Wine-devel - list.winehq.org

Re: [PATCH 2/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface.
by Marvin 10 Jun '15

10 Jun '15

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://testbot.winehq.org/JobDetails.pl?Key=14108 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm.c:2037: Test failed: Expected 32 bpp, got 24d3drm.c:2054: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2058: Test failed: Expected 640x480, got 1024x768 d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. === wxppro (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. === w2003std (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840.

1 0

Re: [PATCH 1/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper.
by Marvin 10 Jun '15

10 Jun '15

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://testbot.winehq.org/JobDetails.pl?Key=14107 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm.c:2037: Test failed: Expected 32 bpp, got 24d3drm.c:2054: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2058: Test failed: Expected 640x480, got 1024x768 === wxppro (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. === w2003std (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32.

1 0

Re: [3/3] kernel32: Forward SetFileInformationByHandle FileDispositionInfo class to ntdll.
by Marvin 10 Jun '15

10 Jun '15

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://testbot.winehq.org/JobDetails.pl?Key=14103 Your paranoid android. === wvistau64 (32 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [1/3] kernel32: Improve stub for SetFileInformationByHandle.
by Marvin 10 Jun '15

10 Jun '15

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://testbot.winehq.org/JobDetails.pl?Key=14101 Your paranoid android. === wvistau64 (32 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820 === w7u (32 bit file) === file.c:4204: Test failed: SetFileValidData failed 87 file.c:4207: Test failed: SetFileValidData failed 87 === wvistau64 (64 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820

2 1

Re: regedit: Need 3 bytes of room at end of buffer for \r\n\0 to avoid endless loop.
by Sebastian Lackner 10 Jun '15

10 Jun '15

On 21.05.2015 13:14, Jiaxing Wang wrote: > --- > programs/regedit/regproc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > The patch looks correct to me, and the issue can be easily reproduced by trying to import for example http://ix.io/j1Y. (md5sum: 6928e59d2c1a92666377a088a1523666) The only problem I see is that the code for A/W has diverged a lot over time. I'm not sure, but I assume Alexandre might expect to merge or at least synchronize it, before fixing specific parser bugs.

1 0

Re: include: Fix definition of FILE_DISPOSITION_INFO.
by Nikolay Sivov 09 Jun '15

09 Jun '15

On 09.06.2015 10:09, Sebastian Lackner wrote: > A member called DeleteFile cannot be accessed because its defined as > DeleteFile_must_be_suffixed_with_W_or_A_in_this_context. > > --- > include/winbase.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > This is how it's defined in SDK though, I don't think you can change that.

3 4

Re: rpcrt4: Restore original error code when ReadFile fails with ERROR_MORE_DATA.
by Alexandre Julliard 09 Jun '15

09 Jun '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Required when named pipe messagemode is implemented. Restoring last error is in general wrong. You'll need a better reason to justify this. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: gdiplus: Implement trivial case of GdipCreateRegionRgnData for empty and infinite regions
by Dmitry Timoshkov 09 Jun '15

09 Jun '15

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > First bits for https://bugs.winehq.org/show_bug.cgi?id=34843 What is the reason of reimplementing it when wine-staging already includes full implementation with tests? https://github.com/wine-compholio/wine-staging/blob/master/patches/gdiplus-… -- Dmitry.

6 14

Re: gdiplus: Implement trivial case of GdipCreateRegionRgnData for empty and infinite regions (try2)
by Vincent Povirk 09 Jun '15

09 Jun '15

Looks good to me, thanks. On Tue, Jun 9, 2015 at 1:37 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > try2: check for both possible magic values > > >

1 0

mciqtz32: Guarantees that CoInitialize and CoUninitialize run on the same thread.
by Joerg-Cyril.Hoehle＠t-systems.com 09 Jun '15

09 Jun '15

Aki, if I understand your critical section well, you serialize all accesses to the individual player thread. This may be ok for commands that return immediately, e.g. STATUS, but the MCI knows commands that may take a long time, in particular PLAY, RECORD and even SEEK. Did you run a test like this: CreateTask { SetEvent started MCICommand(MCI_PLAY, "av_file_that_takes_3_minutes.avi", MCI_WAIT); } Wait(started); Repeat 10 times { MCICommand(MCI_STATUS,MCI_POSITION); printf MCICommand(MCI_STATUS,MCI_MODE); Printf Sleep(2s); } Wait(thread); I would expect all MCI commands "STATUS POSITION" etc. to work while another thread is busy playing a file synchronously (using MCI_WAIT). Furthermore +static LRESULT MCIQTZ_relayTaskMessage [...] + if (WaitForSingleObject(wma->task.done, INFINITE) == WAIT_OBJECT_0) Are you sure it's ok to block the user thread like this? Shouldn't the code use a loop that also pumps the MS-Windows message queue and dispatches messages? E.g. there may be a need to dispatch REFRESH and PAINT messages? Did you cross-check what MS-Windows does here? On a related note, IIRC some wine devices use a more reliable approach to waiting: WaitForMultiple(2 objects: [task.done, task.threadId], INFINITE); That way, should the player crash or exit somehow, the main (user) task doesn't hang. Regards, Jörg Höhle

2 4