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

Re: [PATCH 3/9] d2d1: Validate bitmap formats.

by Henri Verbeet

On 23 July 2015 at 22:00, Marvin <testbot(a)winehq.org> wrote: > 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=15530 > > Your paranoid android. > For what it's worth, the issue seems to be that bitmap_desc.dpiX/dpiY are uninitialized.

July 27, 2015

mountmgr.sys: Write usable device paths into HKLM\SYSTEM\MountedDevices.

by Bernhard Übelacker

Hello, I got asked if I could get a discussion started for the attached patch and bug #38235 [1]. This bug is about Blindwrite 7 not showing any usable source DVD drive. It seems Blindwrite relies on the values stored in HKLM\SYSTEM\MountedDevices to enumerate drives. Wine currently stores in e.g. "\DosDevices\D:" the linux mount point of the drive as ansi string. A native Windows XP stores there (as wide string): \??\IDE#CdRomVBOX_CD-ROM_____________________________1.0_____#42562d3231303037333036372020202020202020#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b} This patch stores now as content just the device (also as wide string): \\.\d: This is sufficient to make Blindwrite 7 happy. - Is there currently any use of the stored linux mount point anywhere? - Is there a test needed and where should that be placed as mountmgr.sys has currently no tests subdirectory? - Is there a reason known why this short device name should not be used in this situation? Kind regards, Bernhard [1] https://bugs.winehq.org/show_bug.cgi?id=38235

July 27, 2015

Re: d3dx9_36: Add D3DXTessellateNPatches stub

by Matteo Bruni

2015-07-24 11:06 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > d3dx9_36: Add D3DXTessellateNPatches stub > > > Best Regards > Alistair Leslie-Hughes Please avoid caps in the parameter names. Also don't forget the period at the end of the FIXME message.

July 27, 2015

Re: [2/2] d3dx9_36: Add D3DXCreateFragmentLinker, D3DXCreateFragmentLinkerEx stubs

by Matteo Bruni

2015-07-23 11:11 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > > Hi, > > Fixes crash of https://bugs.winehq.org/show_bug.cgi?id=38086 > > Changelog: > d3dx9_36: Add D3DXCreateFragmentLinker, D3DXCreateFragmentLinkerEx stubs > > > Best Regards > Alistair Leslie-Hughes > + FIXME("(device %p, size %u, linker %p)\n", device, size, linker); Please drop the parentheses in the message. > + > + if(linker) Space between if and '('. While you're at it, please drop the D3DXCreateFragmentLinker and D3DXCreateFragmentLinkerEx entries from d3dx9_42.spec, it looks like those functions were removed in d3dx9_42.dll. You should probably also add the function prototypes to d3dx9shader.h.

July 27, 2015

Re: [1/2] include: Add ID3DXFragmentLinker interface

by Matteo Bruni

2015-07-23 11:11 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > include: Add ID3DXFragmentLinker interface > > > Best Regards > Alistair Leslie-Hughes > +typedef interface ID3DXFragmentLinker ID3DXFragmentLinker; You don't need that. > + STDMETHOD(GetDevice)(THIS_ IDirect3DDevice9 *device) PURE; This is wrong. > + STDMETHOD(LinkPixelShader)(THIS_ const char *profile, DWORD flags, const D3DXHANDLE *fragmenthandles, UINT fragments, IDirect3DVertexShader9 **shader, ID3DXBuffer **errors) PURE; This too. For reference, I checked the definitions with those from the March 2009 DirectX SDK.

July 27, 2015

Re: d3dcompiler: Add D3DCompileFromFile, D3DCompile2 stubs (try 3 - resend)

by Matteo Bruni

2015-07-23 11:09 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > + FIXME(" srcdata %p, srcdatasize %lu, sourcename %s, defines %p, includes %p, entrypoint %s, target %s, " Extra space at the start. But it's okay, not worth a resend IMHO. As followups you could make D3DCompile() forward to D3DCompile2() and you could try to implement D3DCompileFromFile(), probably via the new D3DReadFileToBlob() function.

July 27, 2015

Re: [PATCH 5/5] qcap/tests: Add COM tests for VfwCapture.

by Michael Stefaniuc

On 07/27/2015 09:35 AM, Marvin wrote: > 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=15590 > > Your paranoid android. > > > === build (build) === > Make failed The testbot is not rebuilding everything so it fails to link to the symbol _IID_IAMVfwCaptureDialogs, which I've added with patch 1/5. Manual build test exe succeeds https://testbot.winehq.org/JobDetails.pl?Key=15579 bye michael

July 27, 2015

Re: [PATCH 5/5] qcap/tests: Add COM tests for VfwCapture.

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://testbot.winehq.org/JobDetails.pl?Key=15590 Your paranoid android. === build (build) === Make failed

July 27, 2015

Re: [1/2] ntdll/tests: Add basic tests for RtlQueueWorkItem.

by Sebastian Lackner

On 27.07.2015 00:11, Marvin wrote: > 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=15580 > > Your paranoid android. > > > === w7u (32 bit threadpool) === > threadpool.c:763: Test failed: WaitForSingleObject returned 258 > threadpool.c:777: Test failed: WaitForSingleObject returned 0 > threadpool.c:779: Test failed: threadpool.c:715: Running timer callback > This is unrelated to my tests. If noone has an idea what is causing these random failures I'll try to increase the timeouts a bit (in a separate patch of course) - however, these random issues do not occur on a local Windows 7 machine, which makes me suspect that it could also be related to testbot issues.

July 26, 2015

Re: [1/2] ntdll/tests: Add basic tests for RtlQueueWorkItem.

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://testbot.winehq.org/JobDetails.pl?Key=15580 Your paranoid android. === w7u (32 bit threadpool) === threadpool.c:763: Test failed: WaitForSingleObject returned 258 threadpool.c:777: Test failed: WaitForSingleObject returned 0 threadpool.c:779: Test failed: threadpool.c:715: Running timer callback

July 26, 2015