April 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 4/5] ddraw/tests: Add a test for getdc palette handling.
by Marvin April 28, 2014

April 28, 2014

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=6628 Your paranoid android. === w2008s64 (64 bit ddraw7) === ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6115: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6428: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6493: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6553: Test failed: Failed to create surface, hr 0x80004002.

1 0

Re: [PATCH 3/5] ddraw/tests: Handle a backbuffer palette misbehavior on Windows 8.
by Marvin April 28, 2014

April 28, 2014

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=6626 Your paranoid android. === w2008s64 (64 bit ddraw7) === ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6115: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6428: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6493: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6553: Test failed: Failed to create surface, hr 0x80004002.

1 0

Re: [PATCH 2/5] ddraw/tests: Skip the ddraw7 primary palette test if 8 bpp mode doesn't work.
by Marvin April 28, 2014

April 28, 2014

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=6625 Your paranoid android. === w864 (32 bit ddraw7) === ddraw7.c:5635: Test failed: Got unexpected refcount 3. ddraw7.c:5654: Test failed: Got unexpected refcount 3. ddraw7.c:5661: Test failed: Got unexpected hr 0. ddraw7.c:5664: Test failed: Got unexpected refcount 3. ddraw7.c:5666: Test failed: Got unexpected refcount 2. ddraw7.c:5672: Test failed: Got unexpected hr 0. ddraw7.c:5675: Test failed: Got unexpected refcount 2. ddraw7.c:5679: Test failed: Got unexpected refcount 6. ddraw7.c:5796: Test failed: Failed to set cooperative level, hr 0x8876023b. === w2008s64 (64 bit ddraw7) === ddraw7.c:6352: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6091: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6352: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6404: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6469: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6529: Test failed: Failed to create surface, hr 0x80004002.

1 0

Re: [PATCH 1/5] ddraw/tests: Test P8 to RGB blits (try 3).
by Marvin April 28, 2014

April 28, 2014

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=6624 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2.c:5096: Test failed: Got unexpected refcount 3. ddraw2.c:5115: Test failed: Got unexpected refcount 3. ddraw2.c:5122: Test failed: Got unexpected hr 0. ddraw2.c:5125: Test failed: Got unexpected refcount 3. ddraw2.c:5127: Test failed: Got unexpected refcount 2. ddraw2.c:5133: Test failed: Got unexpected hr 0. ddraw2.c:5136: Test failed: Got unexpected refcount 2. ddraw2.c:5138: Test failed: Got unexpected refcount 1. === w864 (32 bit ddraw1) === ddraw1.c:3991: Test failed: Got unexpected refcount 3. ddraw1.c:4010: Test failed: Got unexpected refcount 3. ddraw1.c:4017: Test failed: Got unexpected hr 0. ddraw1.c:4020: Test failed: Got unexpected refcount 3. ddraw1.c:4022: Test failed: Got unexpected refcount 2. ddraw1.c:4028: Test failed: Got unexpected hr 0. ddraw1.c:4031: Test failed: Got unexpected refcount 2. ddraw1.c:4033: Test failed: Got unexpected refcount 1. === wxppro (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 00247AE8. ddraw7: unhandled exception c0000005 at 0045EB6B === wvista (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 00264A78. ddraw7: unhandled exception c0000005 at 0045EB6B === w2008s64 (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 005CFE60. ddraw7: unhandled exception c0000005 at 0045EB6B === w7u (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 007ABEB8. ddraw7: unhandled exception c0000005 at 0045EB6B === w864 (32 bit ddraw7) === ddraw7.c:5629: Test failed: Got unexpected refcount 3. ddraw7.c:5648: Test failed: Got unexpected refcount 3. ddraw7.c:5655: Test failed: Got unexpected hr 0. ddraw7.c:5658: Test failed: Got unexpected refcount 3. ddraw7.c:5660: Test failed: Got unexpected refcount 2. ddraw7.c:5666: Test failed: Got unexpected hr 0. ddraw7.c:5669: Test failed: Got unexpected refcount 2. ddraw7.c:5673: Test failed: Got unexpected refcount 6. ddraw7.c:5790: Test failed: Failed to set cooperative level, hr 0x8876023b. === w2008s64 (64 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 0000000000000000, expected 0000000000732980. ddraw7: unhandled exception c0000005 at 0000000000454891 === w864 (64 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 0000000000000000, expected 00000000006C77A0. ddraw7: unhandled exception c0000005 at 0000000000454891 === w864 (32 bit ddraw4) === ddraw4.c:5756: Test failed: Got unexpected refcount 3. ddraw4.c:5775: Test failed: Got unexpected refcount 3. ddraw4.c:5782: Test failed: Got unexpected hr 0. ddraw4.c:5785: Test failed: Got unexpected refcount 3. ddraw4.c:5787: Test failed: Got unexpected refcount 2. ddraw4.c:5793: Test failed: Got unexpected hr 0. ddraw4.c:5796: Test failed: Got unexpected refcount 2. ddraw4.c:5798: Test failed: Got unexpected refcount 1. ddraw4.c:5800: Test failed: Got unexpected refcount 6. ddraw4.c:5920: Test failed: Failed to set cooperative level, hr 0x8876023b. ddraw4.c:5959: Test failed: Failed to attach surface, hr 0x887600e1. ddraw4.c:5962: Test failed: Got unexpected hr 0. ddraw4.c:5964: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5967: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:5970: Test failed: Got unexpected hr 0x887601c2. ddraw4.c:5972: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5975: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:5977: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5980: Test failed: Got unexpected hr 0x887600e1. ddraw4.c:5982: Test failed: Got unexpected hr 0x887601c2.

1 0

Re: mshtml: Renamed nsIDOMHTMLSelectElement::Remove to select_Remove to avoid conflict with nsIDOMElement.
by Zhenbo Li April 28, 2014

April 28, 2014

Thanks, Jacek This patch should fix that problem, but would it hide the problem in widl? I tried midl.exe with VS, and got #define nsIDOMHTMLSelectElement_Remove(This,index) \ ( (This)->lpVtbl -> Remove(This,index) ) Then why widl can't handle this situation? 2014-04-28 18:17 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > Spotted by Zhenbo Li. > > --- > dlls/mshtml/nsiface.idl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > -- Have a nice day! Zhenbo Li

2 1

Fwd: [draft patch] atl100/tests: Added more tests for AtlAxWin{, Lic} procedure.
by Qian Hong April 28, 2014

April 28, 2014

Hi, A lot of thanks to Nikolay and Jacek for many comments and suggestions :) While working on tests, I found some differences between atl80 and atl100: --- snip --- + ok(wndproc[0] == wndproc[1], "expected same proc!\n"); --- snip --- - On atl80, wndprocs are different for class AtlAxWin80 and class AtlAxWinLic80, however, wndprocs are the same for class AtlAxWin100 and class AtlAxWinLic100. --- snip --- + hwnd = CreateWindowW(cls_names[i], NULL, 0, 100, 100, 100, 100, NULL, N ULL, NULL, NULL); + ok(hwnd != NULL, "CreateWindow failed!\n"); + control = (IUnknown *)0xdeadbeef; + res = AtlAxGetControl(hwnd, &control); + todo_wine ok(res == E_FAIL, "AtlAxGetControl failed with res %08x\n", res); --- snip --- - On atl80, CreateWindow with NULL window name or empty name, then call AtlAxGetControl, result is S_OK. On atl100, the same test show that result is E_FAIL. control is NULL in both situation. We've already shared source between different atl version, so it would be annoying to change the code to match different edge case on different version of atl. As far as now, I can't find any real world app depends on any of the above different edge result, so I guess we'd better follow what atl100 does even in atl80 code, would we? Thanks for any comments. --- dlls/atl100/tests/atl.c | 159 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 147 insertions(+), 12 deletions(-)

1 1

Re: mshtml: Added IHTMLTable::width property implementation. (try 5)
by Jacek Caban April 28, 2014

April 28, 2014

Hi Zhenbo, This looks better, but there are two more things I didn't catch earlier. On 04/27/14 15:08, Zhenbo Li wrote: > + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); > + if (NS_FAILED(nsres)){ > + ERR("Get Width(%s) failed!\n", debugstr_variant(p)); You can't access output argument (p) here. This will be undefined. > + nsAString_Finish(&val); > + return E_FAIL; > + } > + > + hres = nsstr_to_truncated_bstr(&val, &bstr); > + > + V_VT(p) = VT_BSTR; > + V_BSTR(p) = bstr; > + return hres; You leak val here. Jacek

1 0

[RFC 1/11] Linux FF: Joystick control panel program
by Elias Vanderstuyft April 27, 2014

April 27, 2014

a) When unloading conditional effects in joy.cpl, the program crashes: When unloading the conditional effect array entries, Wine tries to access an invalid (high) address because dieffect.lpvTypeSpecificParams was not set at the time the effect was created. So declare a valid 'standard' (maxed out) conditional effect. For other unknown effects: - The same can happen when CustomForce effects are available, but because Wine's FF dinput->linux translation does not support this yet, we simply print a FIXME to indicate a possible cause if a crash would happen. - The same for other (unsupported) effects (this is probably not safe?), but then we print a WARN. => This is probably not safe, but these effects won't be unloaded, because they will never be allowed to be created: I tested this by using a dummy FF device that advertised to support CustomForce, but because JoystickAImpl_EnumEffects() does not handle CustomForce, no CustomForce entry was generated in the joy.cpl application, and there was no crash at exit. Solution: After the code of joy.cpl/main.c:766 : else if (IsEqualGUID(&pdei->guid, &GUID_Sine) || IsEqualGUID(&pdei->guid, &GUID_Square) || IsEqualGUID(&pdei->guid, &GUID_Triangle) || IsEqualGUID(&pdei->guid, &GUID_SawtoothUp) || IsEqualGUID(&pdei->guid, &GUID_SawtoothDown)) { DIPERIODIC pforce; pforce.dwMagnitude = DI_FFNOMINALMAX; pforce.lOffset = 0; pforce.dwPhase = 0; pforce.dwPeriod = FF_PERIOD_TIME; dieffect.cbTypeSpecificParams = sizeof(pforce); dieffect.lpvTypeSpecificParams = &pforce; dieffect.dwFlags |= DIEP_TYPESPECIFICPARAMS; } add the following code : else if (IsEqualGUID(&pdei->guid, &GUID_Spring) || IsEqualGUID(&pdei->guid, &GUID_Damper) || IsEqualGUID(&pdei->guid, &GUID_Inertia) || IsEqualGUID(&pdei->guid, &GUID_Friction)) { DICONDITION cxyforce[2]; int i; for (i = 0; i < 2; ++i) { cxyforce[i].lOffset = 0; cxyforce[i].lPositiveCoefficient = DI_FFNOMINALMAX; cxyforce[i].lNegativeCoefficient = DI_FFNOMINALMAX; cxyforce[i].dwPositiveSaturation = DI_FFNOMINALMAX; cxyforce[i].dwNegativeSaturation = DI_FFNOMINALMAX; cxyforce[i].lDeadBand = 0; } dieffect.cbTypeSpecificParams = sizeof(cxyforce); dieffect.lpvTypeSpecificParams = cxyforce; dieffect.dwFlags |= DIEP_TYPESPECIFICPARAMS; } else if (IsEqualGUID(&pdei->guid, &GUID_CustomForce)) { FIXME("Unhandled type specific parameters of CustomForce effect, this may lead to memory errors later on.\n"); } else WARN("Possibly unhandled type specific parameters of effect with guid %x.\n", pdei->guid); b) Weirdly, I had to add these commands that evaluates the DIEFFECT pointers at the end of each if-case, otherwise the pointers seemed to point to other address or data on that address was getting overwritten: TRACE("&rforce=0x%x\n", &rforce); TRACE("&cforce=0x%x\n", &cforce); TRACE("&pforce=0x%x\n", &pforce); TRACE("&cxyforce[0]=0x%x; &cxyforce[1]=0x%x\n", &(cxyforce[0]), &(cxyforce[1])); Elias

2 5

Re: winex11.drv: merge the clipboard and drag-and-drop import functions
by André Hentschel April 27, 2014

April 27, 2014

Am 27.04.2014 11:20, schrieb Damjan Jovanovic: > * Merges the X selection import functions used by the clipboard and > drag-and-drop, now allowing files to be copied-and-pasted from X11 > apps into Wine apps, and new types (eg. images) to be > dragged-and-dropped from X11 apps into Wine apps (instead of just > files and text like before). Also has the benefit of now allowing > drag-and-drop to use INCR for large data transfers. > * Fixes several memory leaks in xdnd.c > * Uses GlobalAlloc() instead of HeapAlloc() for STGMEDIUM's hGlobal. > * De-duplicates considerable shared code. Cool work, but this sounds like "needs splitting"...

1 0

Advice fixing #13683 (DirectX mouse overlay?)
by Christopher Thielen April 26, 2014

April 26, 2014

Hi wine-devel, I'm attempting to fix http://bugs.winehq.org/show_bug.cgi?id=13683 but need some advice as to where to start. I'm not too familiar with hacking on Wine. I'd like to test Stefan Dösinger's theory outlined in the comments for #13683 that the missing second mouse cursor is perhaps being implemented using DirectX overlays and that Wine's lack of overlay compatibility flags is to blame. Would the proper action to test this theory be to fake a certain set of flags in dlls/d3d8/device.c's static HRESULT WINAPI d3d8_device_GetDeviceCaps(IDirect3DDevice8 *iface, D3DCAPS8 *caps) ? If that proves to be the issue, I'd then need to write proper code to report the correct set of flags presumably. Is there any easy way to see which DLLs Wine loads when running an application? I appreciate any advice, I'm new but want to help, Christopher Thielen

4 25