May 2011 - Wine-Devel - list.winehq.org

Re: cmd: Don't read past end of thisVar in WCMD_expand_envvar (valgrind)

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 http://testbot.winehq.org/JobDetails.pl?Key=11166 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:223: Test failed: unexpected char 0x54 position 0 in line 86 (got 'This Line Is Never Reached. If this runs, it is a bug.', wanted '65536') batch.c:223: Test failed: unexpected char 0x31 position 0 in line 87 (got '1', wanted 'errorlevel just right, good') batch.c:223: Test failed: unexpected char 0x65 position 0 in line 88 (got 'errorlevel too low, bad', wanted 'abc0def') batch.c:223: Test failed: unexpected char 0x54 position 0 in line 89 (got 'This Line Is Never Reached. If this runs, it is a bug.', wanted 'errorlevel zero, good') batch.c:223: Test failed: unexpected char 0x61 position 0 in line 90 (got 'abc1def', wanted '7 should be 7') batch.c:223: Test failed: unexpected char 0x65 position 0 in line 91 (got 'errorlevel nonzero, bad', wanted '7 should still be 7') batch.c:223: Test failed: unexpected char 0x37 position 0 in line 92 (got '7 should be 7', wanted '3 should be 3 now') batch.c:223: Test failed: unexpected char 0x54 position 0 in line 93 (got 'This Line Is Never Reached. If this runs, it is a bug.', wanted '-----------Testing GOTO-----------') batch.c:223: Test failed: unexpected char 0x37 position 0 in line 94 (got '7 should still be 7', wanted 'goto with no leading space worked') batch.c:223: Test failed: unexpected char 0x30 position 0 in line 95 (got '0 should be 3 now', wanted 'goto with a leading space worked') batch.c:223: Test failed: unexpected char 0x2d position 0 in line 96 (got '-----------Testing GOTO-----------', wanted 'goto with a leading tab worked') batch.c:223: Test failed: unexpected char 0x67 position 0 in line 97 (got 'goto with no leading space worked', wanted 'goto with a following space worked') batch.c:223: Test failed: unexpected char 0x67 position 0 in line 98 (got 'goto with a leading space worked', wanted '-----------Done, jumping to EOF-----------') batch.c:235: Test failed: too long output, got additional goto with a leading tab worked === W2KPROSP4 (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === WXPPROSP3 (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W2K3R2SESP2 (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === WVISTAADM (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W2K8SE (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W7PRO (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W7PROX64 (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W7PROX64 (64 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now')

May 25, 2011

Re: windows are incompletely drawn: bisected to commit 7864ade5a8306c0078e16ae6d7e40bdece29395b

by Austin English

On Tue, May 24, 2011 at 17:24, Wolfgang Walter <wine(a)stwm.de> wrote: > An application we use shows incompletely painted windows with 1.3.19. I > bisected it to commit > > 7864ade5a8306c0078e16ae6d7e40bdece29395b is the first bad commit > commit 7864ade5a8306c0078e16ae6d7e40bdece29395b > Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> > Date: Tue Sep 14 14:24:11 2010 +0900 > > winex11.drv: Avoid copying invalid window bits. > > > I reverted it in 1.3.19 and that fixed indeed the problem. > > The wrongly painted windows are maximized windows within a MDI window: if > there are serveral such windows opened and one switches between them parts of > the newly active window is not painted and the content of the old one is > still displayed. http://bugs.winehq.org/show_bug.cgi?id=26247 http://bugs.winehq.org/show_bug.cgi?id=27093 -- -Austin

May 24, 2011

Re: [2/5] d3dx9: Generate effect instances from materials for mesh loading.

by Matteo Bruni

2011/5/24 Dylan Smith <dylan.ah.smith(a)gmail.com>: > --- > dlls/d3dx9_36/mesh.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++-- > 1 files changed, 112 insertions(+), 5 deletions(-) > > diff --git a/dlls/d3dx9_36/mesh.c b/dlls/d3dx9_36/mesh.c > index fa32797..20b3262 100644 > --- a/dlls/d3dx9_36/mesh.c > +++ b/dlls/d3dx9_36/mesh.c ... > + strcpy(defaults->pParamName, diffuse_paramname); > + defaults->pValue = defaults->pParamName + sizeof(diffuse_paramname); > + defaults->Type = D3DXEDT_FLOATS; > + defaults->NumBytes = sizeof(D3DCOLORVALUE); > + memcpy(defaults->pValue, &material_ptr->MatD3D.Diffuse, sizeof(D3DCOLORVALUE)); > + (defaults + 1)->pParamName = (LPSTR)((D3DCOLORVALUE*)defaults->pValue + 1); > + defaults++; > + > + strcpy(defaults->pParamName, power_paramname); > + defaults->pValue = defaults->pParamName + sizeof(power_paramname); > + defaults->Type = D3DXEDT_FLOATS; > + defaults->NumBytes = sizeof(FLOAT); > + *(FLOAT*)defaults->pValue = material_ptr->MatD3D.Power; > + (defaults + 1)->pParamName = (LPSTR)((FLOAT*)defaults->pValue + 1); > + defaults++; ... A nitpick maybe, but I think you could avoid to repeat the same code for each parameter by means of a loop driven by a table. It may be worth a try if it doesn't become more cumbersome than the current approach.

May 24, 2011

windows are incompletely drawn: bisected to commit 7864ade5a8306c0078e16ae6d7e40bdece29395b

by Wolfgang Walter

An application we use shows incompletely painted windows with 1.3.19. I bisected it to commit 7864ade5a8306c0078e16ae6d7e40bdece29395b is the first bad commit commit 7864ade5a8306c0078e16ae6d7e40bdece29395b Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> Date: Tue Sep 14 14:24:11 2010 +0900 winex11.drv: Avoid copying invalid window bits. I reverted it in 1.3.19 and that fixed indeed the problem. The wrongly painted windows are maximized windows within a MDI window: if there are serveral such windows opened and one switches between them parts of the newly active window is not painted and the content of the old one is still displayed. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

May 24, 2011

Re: [1/5] wined3d: Don't check the FBO status if FIXMEs are off

by Henri Verbeet

On 24 May 2011 22:37, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I put the fixme checks outside context_check_fbo_status because the ENTER_GL() / LEAVE_GL() > locking is more expensive than the FBO validation itself. Moving the locking into the function I'm not sure that's really worth it. If the GL lock is really such a concern, you should probably change the calls in context.c to already be under the GL lock anyway. You can easily change context_apply_draw_buffers() for example to require locking by the caller.

May 24, 2011

Re: [2/2]usp10/test: add Tibetan shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11159 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 24, 2011

Re: usp10/test: make sure to only trace on _test_shape_ok number of glyphs if font is not valid

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 http://testbot.winehq.org/JobDetails.pl?Key=11158 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 24, 2011

Re: [PATCH 4/5] wined3d: Mask out writes to unused render targets.

by Stefan Dösinger

On Tuesday 24 May 2011 21:18:53 Henri Verbeet wrote: > @@ -1999,19 +1999,22 @@ static void context_apply_draw_buffers(struct > wined3d_context *context, UINT rt_ if > (wined3d_settings.offscreen_rendering_mode == ORM_FBO) { > const struct wined3d_gl_info *gl_info = context->gl_info; > - unsigned int i; > + unsigned int i = 0; > > - for (i = 0; i < rt_count; ++i) > + while (rt_mask) > { > if (rts[i] && rts[i]->resource.format->id != > WINED3DFMT_NULL) context->draw_buffers[i] = GL_COLOR_ATTACHMENT0 + i; > else > context->draw_buffers[i] = GL_NONE; > + > + rt_mask >>= 1; > + ++i; > } Shouldn't you also check if the lowest bit of rt_mask? Otherwise you'll miss situations where oC0 is written, oC1 isn't and oC2 is written. context->draw_buffer_dirty also has to be dirtified somewhere when the pixel shader is changed, their rt masks are different and a target is bound to one of the changed indices.

May 24, 2011

Re: [PATCH] wined3d: Mark wined3d_pixel_format with hidden visibility

by Henri Verbeet

On 13 May 2011 18:27, Marcus Meissner <meissner(a)suse.de> wrote: > @@ -1273,7 +1273,7 @@ struct wined3d_pixel_format > BOOL doubleBuffer; > int auxBuffers; > int numSamples; > -} wined3d_pixel_format; > +} wined3d_pixel_format DECLSPEC_HIDDEN; > No, that's wrong. It's not supposed to be a variable at all, it's a leftover from the typedef.

May 24, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

On Tuesday 24 May 2011 19:56:06 Michael Mc Donnell wrote: > Sorry I phrased that in a wrong way. In the UpdateSemantics function I > call IDirect3DDevice9_CreateVertexDeclaration which allocates a new > Vertex Declaration on the heap. Is there an alternative? I guess you could cache existing declarations. The d3d9 API doesn't give you an option to reuse an existing declaration. I doubt apps will regularly change the declaration, usually this doesn't make sense without also changing the data. Of course that doesn't mean there isn't a broken app out there that does this. > I also noticed that I didn't call > IDirect3DDevice9_SetVertexDeclaration. I've added it to stick with the > defined locking scheme. Locking scheme? I've just started reading into into the Mesh API, but I don't think you're supposed to apply the declaration until the mesh is used for drawing. > > *) In your first test you forgot to check the HeapAlloc result. > > Ok, I'll return E_OUTOFMEMORY in that case. I guess the callers will only abort the tests if NewTestContext fails, so I think the NULL / non-NULL return value was better. > Should I try to make some more invalid > D3DVERTEXELEMENT9 arrays to see if I can provoke an error? I was thinking about something that would make CreateVertexDeclaration fail, e.g. declaring a usage+usage index twice or using an undefined type. dlls/d3d9/vertexdeclaration.c and dlls/wined3d/vertexdeclaration.c check for a few error conditions in their vertexdeclaration_init functions. Just pick one of them(no need to check all of them) But watch out that you don't open a can of worms here. Our CreateVertexDeclaration probably doesn't catch all error conditions. I recommend that you pick one it does catch, otherwise you'll have to fix d3d9.dll and wined3d.dll too for a small test. > > *) In the wined3d code(and its client libs) Henri and I avoid structure > > typedefs. The existing d3dx9 code has a few of them. I'm ok with either > > way, but maybe you and the other d3dx9 devs want to go the wined3d way. > > Sure I can change them. So just normal structs? Is it to keep the > namespace clean? Henri started with this change, I think keeping the namespace clean was a consideration. What you do is up to you and the other devs working on d3dx9. I'm only suggesting that you discuss the code style and agree on a format. Either way it is a fairly minor point IMO, but it tends to end up in holy war.

May 24, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

Thanks for the lengthy feedback! On Tue, May 24, 2011 at 3:36 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > I'm at school right now, so I had only a very quick look. I'll take a closer > look later in the evening. > > On Tuesday 24 May 2011 14:38:19 Michael Mc Donnell wrote: >> This is my first try at implementing the UpdateSemantics mesh method. >> It works fine here on my local machine, passes the new tests, and >> works with my little interactive demo(not included). I still have a >> few questions though. >> >> This implementation allocates new heap memory and I suspect that it >> would be faster to re-use the already allocated memory. > As far as I can see this happens only in the tests, where it doesn't really > matter. Creating and destroying the device is more expensive than the heap > allocation, so if you care about performance you should reuse your test > context structure Sorry I phrased that in a wrong way. In the UpdateSemantics function I call IDirect3DDevice9_CreateVertexDeclaration which allocates a new Vertex Declaration on the heap. I think it might slow things down if UpdateSemantics is in a tight loop where it is used for animation. I also noticed that I didn't call IDirect3DDevice9_SetVertexDeclaration. I've added it to stick with the defined locking scheme. >> Btw should I roll all or some of the patches up into a single patch? > I think you can merge the 3 test patches into one Ok, I've rolled the three test patches into one. >> Any other comments about the patches in general? > > *) >> + * Copyright (C) 2011 Google (Michael Mc Donnell) > Afaik the gsoc conditions say that you keep the copyright to your code :-) Yes you are right. First paragraph in the faq about code :-) > *) In your first test you forgot to check the HeapAlloc result. Ok, I'll return E_OUTOFMEMORY in that case. > *) You could write a test that passes an invalid D3DVERTEXELEMENT9 array to > UpdateSemantics to see how it handles an invalid declaration. I've already got one test with an invalid D3DVERTEXELEMENT9 array. It happily accepts too big declarations even though msdn says "The call is valid only if the old and new declaration formats have the same vertex size". I've added test for null pointers, which it didn't handle correctly. Should I try to make some more invalid D3DVERTEXELEMENT9 arrays to see if I can provoke an error? > A few style suggestions: > > *) memset(mem, 0, size) is preferred over ZeroMemory(mem, size); Ok > *) In the wined3d code(and its client libs) Henri and I avoid structure > typedefs. The existing d3dx9 code has a few of them. I'm ok with either way, > but maybe you and the other d3dx9 devs want to go the wined3d way. Sure I can change them. So just normal structs? Is it to keep the namespace clean? > *) In the TestContext structure you can use gotos for error handling, for > example: > > void *ptr1 = NULL, *ptr2 = NULL, *ptr3 = NULL; > > ptr1 = HeapAlloc(...); > if(!ptr1) goto err; > ptr2 = HeapAlloc(...); > if(!ptr2) goto err; > ptr3 = HeapAlloc(...); > if(!ptr3) goto err; > > return success; > > err: > HeapFree(ptr3); > HeapFree(ptr2); > HeapFree(ptr1); > return error; > > That avoids ever-growing if (FAILED(hr)) blocks with repeated code. Ok I've changed NewTestContext to use gotos instead. I've also changed it so that it returns an HRESULT instead of a pointer to the new structure. I've attached the new versions of the patches.

May 24, 2011

Re: [8/8]usp10/test: add Lao shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11140 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 24, 2011

Re: [7/8]usp10/test: add Phags-pa shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11139 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 24, 2011

Re: [6/8]usp10/test: add Thaana shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11138 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 24, 2011

Re: [5/8]usp10/tests: add Syriac shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11137 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 24, 2011

Re: [4/8]usp10: add Thai shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11136 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 24, 2011

Re: [3/8]usp10: add Arabic Shaping Test

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 http://testbot.winehq.org/JobDetails.pl?Key=11135 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 24, 2011

Re: [2/8]usp10: add Hebrew shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11134 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 24, 2011

Re: [1/8]usp10/tests: update test_ScriptShapeOpenType framework to shape in a given font

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 http://testbot.winehq.org/JobDetails.pl?Key=11133 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === usp10.c:1733: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 73 usp10.c:1699: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1711: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 87 usp10.c:1712: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 71 usp10.c:1720: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 87 usp10.c:1721: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 88 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 87 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 87 usp10.c:1749: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 86 === W2KPROSP4 (32 bit usp10) === usp10.c:1733: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1699: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1711: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1712: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1720: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1721: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1749: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WXPPROSP3 (32 bit usp10) === usp10.c:1733: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1699: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1711: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1712: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1720: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1721: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1749: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K3R2SESP2 (32 bit usp10) === usp10.c:1733: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1699: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1711: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1712: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1720: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1721: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1749: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WVISTAADM (32 bit usp10) === usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 49 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 5 not 7 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 3 not 5 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 5 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 3 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 88 === W2K8SE (32 bit usp10) === usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 49 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 5 not 7 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 3 not 5 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 5 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 3 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 88 === W7PRO (32 bit usp10) === usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 49 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 5 not 7 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 3 not 5 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 5 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 3 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 88 === W7PROX64 (32 bit usp10) === usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 49 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 5 not 7 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 3 not 5 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 5 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 3 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 88

May 24, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

Hi, I'm at school right now, so I had only a very quick look. I'll take a closer look later in the evening. On Tuesday 24 May 2011 14:38:19 Michael Mc Donnell wrote: > This is my first try at implementing the UpdateSemantics mesh method. > It works fine here on my local machine, passes the new tests, and > works with my little interactive demo(not included). I still have a > few questions though. > > This implementation allocates new heap memory and I suspect that it > would be faster to re-use the already allocated memory. As far as I can see this happens only in the tests, where it doesn't really matter. Creating and destroying the device is more expensive than the heap allocation, so if you care about performance you should reuse your test context structure > Btw should I roll all or some of the patches up into a single patch? I think you can merge the 3 test patches into one > Any other comments about the patches in general? *) > + * Copyright (C) 2011 Google (Michael Mc Donnell) Afaik the gsoc conditions say that you keep the copyright to your code :-) *) In your first test you forgot to check the HeapAlloc result. *) You could write a test that passes an invalid D3DVERTEXELEMENT9 array to UpdateSemantics to see how it handles an invalid declaration. A few style suggestions: *) memset(mem, 0, size) is preferred over ZeroMemory(mem, size); *) In the wined3d code(and its client libs) Henri and I avoid structure typedefs. The existing d3dx9 code has a few of them. I'm ok with either way, but maybe you and the other d3dx9 devs want to go the wined3d way. *) In the TestContext structure you can use gotos for error handling, for example: void *ptr1 = NULL, *ptr2 = NULL, *ptr3 = NULL; ptr1 = HeapAlloc(...); if(!ptr1) goto err; ptr2 = HeapAlloc(...); if(!ptr2) goto err; ptr3 = HeapAlloc(...); if(!ptr3) goto err; return success; err: HeapFree(ptr3); HeapFree(ptr2); HeapFree(ptr1); return error; That avoids ever-growing if (FAILED(hr)) blocks with repeated code.

May 24, 2011

Re: [11/15]usp10/tests: update test_ScriptShapeOpenType framework to shape in a given font

by Aric Stewart

Ah, I wondered if I was pushing the Macro thing too far. -aric On 11/05/24 5:26, Alexandre Julliard wrote: > Aric Stewart<aric(a)codeweavers.com> writes: > >> @@ -297,9 +297,13 @@ static void test_ScriptItemize( void ) >> test_items_ok(test10,4,&Control,&State,1,t101,FALSE,0); >> } >> >> -static inline void _test_shape_ok(HDC hdc, LPCWSTR string, DWORD cchString, >> - SCRIPT_CONTROL *Control, SCRIPT_STATE *State, >> - DWORD item, DWORD nGlyphs, >> +#define shape_cond_ok(a,b,c...) if (a>0) {winetest_ok(b,c);} else if(!b) {winetest_trace(c);} >> + >> +#define shape_cond_skip(a,b...) if (a>0) {winetest_win_skip(b);} else {winetest_trace(b);} > > You can't do that. >

May 24, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

Hi Stefan This is my first try at implementing the UpdateSemantics mesh method. It works fine here on my local machine, passes the new tests, and works with my little interactive demo(not included). I still have a few questions though. This implementation allocates new heap memory and I suspect that it would be faster to re-use the already allocated memory. That would, however, require quite a bit of re-engineering. Should I submit the current version or wait and try to do an optimized version? Btw should I roll all or some of the patches up into a single patch? Any other comments about the patches in general? Cheers, Michael Mc Donnell

May 24, 2011

Re: [PATCH] winealsa.drv: Implement device enumeration

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > dlls/winealsa.drv/mmdevdrv.c | 113 > +++++++++++++++++++++++++++++++++++------- > 1 files changed, 94 insertions(+), 19 deletions(-) It doesn't work here (and I didn't even plug in my USB headset ;-) ../../../tools/runtest -q -P wine -M mmdevapi.dll -T ../../.. -p mmdevapi_test.exe.so capture.c && touch capture.ok ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM front [many more of the same...] ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:158: Test failed: Activation failed with 80004005 ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:323: Test failed: Activation failed with 80004005 ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:420: Test failed: Activation failed with 80004005 ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:520: Test failed: Activation failed with 80004005 ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:607: Test failed: Activation failed with 80004005 wine: Unhandled page fault on read access to 0x00000000 at address 0x68687a9a (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x68687a9a). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68687a9a ESP:0032fc30 EBP:0032fd38 EFLAGS:00010206( R- -- I - -P- ) EAX:00000000 EBX:6869915c ECX:0032fd04 EDX:686995c8 ESI:68693ada EDI:80004005 Stack dump: 0x0032fc30: 00000000 68693ae4 80004005 00000000 0x0032fc40: 0032fd18 00123e08 00000017 00c9ed90 0x0032fc50: 0032fd00 7bc9ed90 0032fc78 7bc68211 0x0032fc60: 00000002 00000040 0032fca8 7bc688f5 0x0032fc70: 7bcb9c30 00000002 00000001 7bc3578f 0x0032fc80: 00000017 00000017 00000000 7ffdf044 Backtrace: =>0 0x68687a9a func_capture+0x38a() [/home/julliard/wine/wine/dlls/mmdevapi/tests/capture.c:609] in mmdevapi_test (0x0032fd38) 1 0x686929be run_test+0x14d(name="capture.c") [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/wine/test.h:556] in mmdevapi_test (0x0032fd88) 2 0x68693487 main+0x156(argc=0x1, argv=(nil)) [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/wine/test.h:624] in mmdevapi_test (0x0032fe48) 3 0x6869365c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mmdevapi_test (0x0032fe90) 4 0x7b85aaac call_process_entry+0xb() in kernel32 (0x0032fea8) 5 0x7b85b6df start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1087] in kernel32 (0x0032fee8) 6 0x7bc73808 call_thread_func+0xb() in ntdll (0x0032fef8) 7 0x7bc76f6e call_thread_entry_point+0x6d(entry=0x7b85b680, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffc8) 8 0x7bc4c15e start_process+0x1d(kernel_start=0x7b85b680) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) 9 0x6802998d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x68687a9a func_capture+0x38a [/home/julliard/wine/wine/dlls/mmdevapi/tests/capture.c:609] in mmdevapi_test: movl 0x0(%eax),%edx 609 hr = IAudioClient_GetMixFormat(ac, &fmt); -- Alexandre Julliard julliard(a)winehq.org

May 24, 2011

Re: [8/15]usp10/tests: Hebrew shaping test

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/usp10/tests/usp10.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c && touch usp10.ok usp10.c:438: Test failed: 0: Glyph not present when it should be usp10.c:438: Test failed: 1: Glyph not present when it should be usp10.c:438: Test failed: 2: Glyph not present when it should be usp10.c:438: Test failed: 3: Glyph not present when it should be make[1]: *** [usp10.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

May 24, 2011

Re: [11/15]usp10/tests: update test_ScriptShapeOpenType framework to shape in a given font

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -297,9 +297,13 @@ static void test_ScriptItemize( void ) > test_items_ok(test10,4,&Control,&State,1,t101,FALSE,0); > } > > -static inline void _test_shape_ok(HDC hdc, LPCWSTR string, DWORD cchString, > - SCRIPT_CONTROL *Control, SCRIPT_STATE *State, > - DWORD item, DWORD nGlyphs, > +#define shape_cond_ok(a,b,c...) if (a>0) {winetest_ok(b,c);} else if(!b) {winetest_trace(c);} > + > +#define shape_cond_skip(a,b...) if (a>0) {winetest_win_skip(b);} else {winetest_trace(b);} You can't do that. -- Alexandre Julliard julliard(a)winehq.org

May 24, 2011

Re: ole32/ole2: Don't call IDropTarget::QueryInterface() in RegisterDragDrop(). [whitespace fixed]

by Huw Davies

> +static IDropTarget* WrapDropTarget(IDropTarget* inner) > +{ > + DropTargetWrapper* This = HeapAlloc(GetProcessHeap(), 0, sizeof(*This)); > + > + if (This) > + { > + This->iface = (IDropTarget){ &DropTargetWrapper_VTbl }; This->iface.lpVtbl = &DropTargetWrapper_VTbl; > - hr = CoMarshalInterface(stream, &IID_IDropTarget, unk, MSHCTX_LOCAL, NULL, MSHLFLAGS_TABLESTRONG); > - IUnknown_Release(unk); > + hr = CoMarshalInterface(stream, &IID_IDropTarget, (IUnknown*)wrapper, MSHCTX_LOCAL, NULL, MSHLFLAGS_TABLESTRONG); > > if(SUCCEEDED(hr)) > { > hr = create_map_from_stream(stream, &map); > if(SUCCEEDED(hr)) > { > - IDropTarget_AddRef(pDropTarget); > SetPropW(hwnd, prop_oledroptarget, pDropTarget); You probably want to set the window prop to the wrapper here. Either way you still need the AddRef (on the wrapper if you set that), it gets released in RevokeDragDrop. Huw.

May 24, 2011

Re: performance regression or not?

by Ken Thomases

On May 23, 2011, at 12:13 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > - I'm now wondering whether thread affinity may play a role. > Alas, I don't know how to disable one core with Mac OS X 10.5.8 Double-click on /Developer/Extras/PreferencePanes/Processor.prefPane. That will install it to System Preferences. Then, you can manipulate the processor cores. Regards, Ken

May 24, 2011

Re: Wine's implementation of d3dtypes.h does not work with ISO C++

by Chris Robinson

On Monday, May 23, 2011 12:51:37 PM Daniel Scharrer wrote: > return ((D3DVALUE [4][4])&_11)[r][c]; Something like this should work: return ((D3DVALUE(*)[4])&_11)[r][c];

May 24, 2011

Question about the fSources argument to SHChangeNotifyRegister

by Jay Yang

Hi, Could someone who understands the fSources argument to SHChangeNotifyRegister explain it to me? MSDN says it can take some combination of SHCNRF_InterruptLevel, SHCNRF_ShellLevel, SHCNRF_RecursiveInterrupt, and SHCNRF_NewDelivery. I've looked at the source and it seems that the only one wine handles differently is SHCNRF_NewDelivery, so what do the others mean? MSDN says something about it but quite frankly I don't know what the difference between interrupt level and shell level notifications are. Also the the only place in the tree where wine uses this function, in dlls/shell32/shlview.c, it gets passed SHCNF_IDLIST, which isn't even one of the values. SHCNF_IDLIST happens to be defined as 0, but I think that's irrelevant. Thanks -- Jay Yang

May 23, 2011

Re: [1/5] d3d: Make the INTZ test more reliable

by Stefan Dösinger

On Monday 23 May 2011 23:16:42 Henri Verbeet wrote: > On 23 May 2011 22:50, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > This eliminates the precision issues caused by the projected texture by > > setting the .w coordinate to a constant value. I decided to keep the > > projected sampling itself around to demonstrate that d3d doesn't do > > anything special with the 3rd and 4th value like it does with other > > shadow formats > > The 3rd and 4th coordinate are going to be the same for the locations > you're sampling now. Good point

May 23, 2011

Re: [1/5] d3d: Make the INTZ test more reliable

by Henri Verbeet

On 23 May 2011 22:50, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This eliminates the precision issues caused by the projected texture by > setting the .w coordinate to a constant value. I decided to keep the > projected sampling itself around to demonstrate that d3d doesn't do anything > special with the 3rd and 4th value like it does with other shadow formats The 3rd and 4th coordinate are going to be the same for the locations you're sampling now.

May 23, 2011

Re: [PATCH 3/5] d3d9/tests: Fix the depth clamping test.

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 http://testbot.winehq.org/JobDetails.pl?Key=11124 Your paranoid android. === WXPPROSP3 (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W2K3R2SESP2 (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === WVISTAADM (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W2K8SE (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W7PRO (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W7PROX64 (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W7PROX64 (64 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c

May 23, 2011

Re: dbghelp: Implement SymEnumSourceFilesW.

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: >> The A version should call the W one, not the other way around. > Alexandre, > > in order to properly manage this, we need to move file names in > dbghelp from ansi to unicode > but, as dbghelp API uses some kind of regular expression to match > filenames, we need a unicode regex function set > unfortunately, glib doesn't provide this (yet) > > so, shall we ?: > - embed a (simple) unicode regex lib in dbghelp > - or make generic in libwine (so that the day that glib provides the > right interface we can use it) > - or ... > > libTRE seems a good choice here, with compatible license That looks like serious overkill. These regexps are not complicated, we can do our own matching function in dbghelp. -- Alexandre Julliard julliard(a)winehq.org

May 23, 2011

Re: no line numbers in backtraces on Mac OS X?

by Charles Davis

On 5/23/11 1:53 PM, Stefan Dösinger wrote: > On Monday 23 May 2011 17:48:55 Charles Davis wrote: >> Right now on Mac, you have to configure with -gstabs+. DbgHelp doesn't >> support DWARF on Mac OS yet. (It doesn't know how to find the .dSYM >> bundle or the original object files.) > Or you could just use gdb for debugging instead of winedbg. Just attach gdb to > the running process. True, but gdb lacks information about PE-format modules that winedbg has. Chip

May 23, 2011

Re: no line numbers in backtraces on Mac OS X?

by Stefan Dösinger

On Monday 23 May 2011 17:48:55 Charles Davis wrote: > Right now on Mac, you have to configure with -gstabs+. DbgHelp doesn't > support DWARF on Mac OS yet. (It doesn't know how to find the .dSYM > bundle or the original object files.) Or you could just use gdb for debugging instead of winedbg. Just attach gdb to the running process.

May 23, 2011

Re: performance regression or not?

by Stefan Dösinger

On Monday 23 May 2011 19:13:10 Joerg-Cyril.Hoehle(a)t-systems.com wrote: > This looks like a serious performance degradation over time, isn't it? > Actually, the situation is much subtler and so confusing that I don't > know what to think about it. I'd say this is a performance regression in any case, although probably not a classic one where a function became slower. Considering that the CPU isn't fully utilized the application is probably waiting for something(e.g. a critical section) longer than it should. Even a slight change in an unrelated place might change that behavior. That could explain why disabling sound changes the behavior, or changing the settings(this often restarts the 3D renderer). The strange bisect result could occur because the bug isn't always reproducible, so you entered git bisect good when you actually had bad code. It would be even nastier if the original code didn't always work and the game went from "works 80% of the time" to "works 20% of the time".

May 23, 2011

Re: dbghelp: Implement SymEnumSourceFilesW.

by Eric Pouech

> The A version should call the W one, not the other way around. Alexandre, in order to properly manage this, we need to move file names in dbghelp from ansi to unicode but, as dbghelp API uses some kind of regular expression to match filenames, we need a unicode regex function set unfortunately, glib doesn't provide this (yet) so, shall we ?: - embed a (simple) unicode regex lib in dbghelp - or make generic in libwine (so that the day that glib provides the right interface we can use it) - or ... libTRE seems a good choice here, with compatible license A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 23, 2011

Wine's implementation of d3dtypes.h does not work with ISO C++

by Daniel Scharrer

Hi all, I am working on porting the d3d 7 game Arx Fatalis [1] to linux/OpenGL and we are currently compiling as a winelib application to do so. Because the game is written in c++ and defines D3D_OVERLOADS, I get the following errors in d3dtypes.h (reported as wine bug [2]): /usr/include/wine/windows/d3dtypes.h: In member function ‘D3DVALUE& _D3DMATRIX::operator()(int, int)’: /usr/include/wine/windows/d3dtypes.h:339:30: error: ISO C++ forbids casting to an array type ‘D3DVALUE [4][4]’ /usr/include/wine/windows/d3dtypes.h: In member function ‘const D3DVALUE& _D3DMATRIX::operator()(int, int) const’: /usr/include/wine/windows/d3dtypes.h:341:36: error: ISO C++ forbids casting to an array type ‘const D3DVALUE [4][4]’ Notice that is is a fatal error and not just a warning unless -fpermissive is passed to wineg++. While we can work around this when using gcc (using pragmas to enable -fpermissive just for wine's d3d headers), there is no portable way (across compilers) to use Direct3D's overloaded operators from wine's implementation. The bug report [2] hasn't gotten any real responses and I'd really like to get this fixed, but don't know what the best solution would be that follows wine coding conventions. Wine's current implementation of D3DMATRIX is typedef struct _D3DMATRIX { D3DVALUE _11, _12, _13, _14; D3DVALUE _21, _22, _23, _24; D3DVALUE _31, _32, _33, _34; D3DVALUE _41, _42, _43, _44; #if defined(__cplusplus) && defined(D3D_OVERLOADS) _D3DMATRIX() { } /* This is different from MS, but avoids anonymous structs. */ D3DVALUE &operator () (int r, int c) { return ((D3DVALUE [4][4])&_11)[r][c]; } const D3DVALUE &operator() (int r, int c) const { return ((const D3DVALUE [4][4])&_11)[r][c]; } #endif } D3DMATRIX, *LPD3DMATRIX; MSDN doesn't seem to have a documentation for anything older than d3d 9 anymore, so I have no idea what the original definition looks like. The comment indicates that anonymous structs aren't allowed -- is this correct? An alternative solution would be to calculate the 2D array offsets manually, something like this: D3DVALUE &operator () (int r, int c) { return ((D3DVALUE*)&_11)[r*4 + c]; } Would that implementation be acceptable? Also, if D3D_OVERLOADS has been defined, wine's d3dtypes.h (and also d3d.h) expect <math.h> to have already been included: In file included from /usr/include/wine/windows/d3dtypes.h:346:0, from /usr/include/wine/windows/d3d.h:26, from test.cpp:4: /usr/include/wine/windows/d3dvec.inl: In function ‘D3DVALUE Magnitude(const _D3DVECTOR&)’: /usr/include/wine/windows/d3dvec.inl:118:33: error: ‘sqrt’ was not declared in this scope As I don't have a copy of the d3d 7 SDK I can't check if this is normal or another bug in the wine headers. [1] https://github.com/lubosz/ArxFatalis [2] http://bugs.winehq.org/show_bug.cgi?id=25942 -- Daniel Scharrer

May 23, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 7 resend)

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > The problem is that Wine's winaspi/wnaspi32 is using the UnixDeviceName > key. The way it uses it, it expects a SCSI generic device (/dev/sg*). > That's why I set it to the /dev/sg* device if it's present, and don't > set it otherwise. > > Most modern programs should be using SPTI instead of ASPI, though a few > older programs from the Windows 9x era might still use ASPI. Do you want > to rip out WinASPI support? No, but it shouldn't depend on the Unix device name, it should do ioctls on the Win32 device. But that's an unrelated change of course. Note that I don't get a Unix device for my /dev/sg0 device either. -- Alexandre Julliard julliard(a)winehq.org

May 23, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 7 resend)

by Charles Davis

On 5/23/11 12:15 PM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: > >> Rebased against Marcus Meissner's DECLSPEC_HIDDEN patches. (I hate you, Marcus...) >> Try 7: Fix getting the device name for IDE devices. >> Try 6: Fix some problems noticed by Vitaliy Margolen. >> Try 5: Get the value of "DeviceName" from mountmgr instead of making one up. >> Try 4: Fix unused variable warning. >> Try 3: Add support for IDE drives. >> Try 2: Don't depend on the SCSI generic driver on Linux. > > The unix device name is not being set properly here. I would consider > not setting the key a feature (we don't really need it), but it means > the DMA flag isn't set either. The problem is that Wine's winaspi/wnaspi32 is using the UnixDeviceName key. The way it uses it, it expects a SCSI generic device (/dev/sg*). That's why I set it to the /dev/sg* device if it's present, and don't set it otherwise. Most modern programs should be using SPTI instead of ASPI, though a few older programs from the Windows 9x era might still use ASPI. Do you want to rip out WinASPI support? Chip

May 23, 2011

Re: user32: Partially implement FlashWindowEx with tests (try 2)

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > + for (i=0; i<pfwi->uCount + 1; i++) > + { > + FlashWindow(pfwi->hwnd, TRUE); > + Sleep(msecs); > + FlashWindow(pfwi->hwnd, FALSE); > + Sleep(msecs); > + } I don't think you want to hang the app that way. -- Alexandre Julliard julliard(a)winehq.org

May 23, 2011

Re: dbghelp: Implement SymEnumSourceFilesW.

by Alexandre Julliard

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > This fixes bug 27222. > > --- > dlls/dbghelp/dbghelp.spec | 2 +- > dlls/dbghelp/source.c | 102 +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 103 insertions(+), 1 deletions(-) The A version should call the W one, not the other way around. -- Alexandre Julliard julliard(a)winehq.org

May 23, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 7 resend)

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > Rebased against Marcus Meissner's DECLSPEC_HIDDEN patches. (I hate you, Marcus...) > Try 7: Fix getting the device name for IDE devices. > Try 6: Fix some problems noticed by Vitaliy Margolen. > Try 5: Get the value of "DeviceName" from mountmgr instead of making one up. > Try 4: Fix unused variable warning. > Try 3: Add support for IDE drives. > Try 2: Don't depend on the SCSI generic driver on Linux. The unix device name is not being set properly here. I would consider not setting the key a feature (we don't really need it), but it means the DMA flag isn't set either. -- Alexandre Julliard julliard(a)winehq.org

May 23, 2011

Re: [15/15]usp10/test: add Lao shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11107 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 23, 2011

Re: [14/15]usp10/test: add Phags-pa shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11106 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 23, 2011

performance regression or not?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, please consider the following WINEDEBUG=+fps numbers. 1.1.24 24-19 fps, depending on orientation 1.3.16 14-7 fps 1.3.18-291-g9da9240 14-6 fps 1.3.18-342-gab199f5 13-5 fps 1.3.19-46-g3025f7f 8 fps 1.3.20 7-4 fps The low fps results in jerky character movement. This looks like a serious performance degradation over time, isn't it? Actually, the situation is much subtler and so confusing that I don't know what to think about it. - Disabling audio in winecfg yields 25 fps. Audio seems to play a major role, although both CPU% of the dual core machine are mostly near 33%. - Once and only once, while running 1.3.19-27-gf912e55, I observed 25 fps (with sound!) instead of 13. So new Wine *can* still play fast, it just almost never does it. Why? - After much bisecting, I've learnt that while newer versions of Wine typically produce low fps initially, I can go to the app's options -> graphics -> effects settings during game, change some of them, revert them to their original values, then observe 25 fps -- with sound! What's this weird relationship between sound and 3D? - git bisect lead to a change about mmdevapi.dll that the app does not even use. My hypothesis so far is that Wine or the app seems extremely sensitive to the random location of some stuff in memory. - I don't believe the machine is overloaded. I can start 2 side by side, e.g. demo and retail, in different versions of Wine. - I'm now wondering whether thread affinity may play a role. Alas, I don't know how to disable one core with Mac OS X 10.5.8 The app uses mono internally (windows' version). It's named 2weistein http://www.2weistein.de/ There exists a demo of the first 2 levels, but the level 'Lyrias Zauberbann' where fps varies much is not part of the demo. How to make sense of these observations? Thanks for your help, Jörg Höhle Testing using an "early 2009" NVidia Mac Mini with OS X 10.5.8 and XQuartz 2.6.1

May 23, 2011

Re: [13/15]usp10/test: add Thaana shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11105 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 23, 2011

Re: [12/15]usp10/tests: add Syriac shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11104 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 23, 2011

Re: [8/15]usp10/tests: Hebrew shaping test

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 http://testbot.winehq.org/JobDetails.pl?Key=11100 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 73 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 87 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 71 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 87 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 88 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 87 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 87 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 86 === W2KPROSP4 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WXPPROSP3 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K3R2SESP2 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80

May 23, 2011

Re: no line numbers in backtraces on Mac OS X?

by Charles Davis

On 5/23/11 9:44 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > Is it normal that there are no source line numbers in backtraces on Mac OS? > Despite many patches to winedbg etc., the backtraces I get are > no better that those from 1.1.24 times. > 18 0x41f5b2a1 _OpenDriverA+0x51() in winmm (0x0032ce78) > 19 0x4041467f _initAudioDlg+0x75f() in winecfg (0x0032dc28) > > I'm using configure + make to build. On Linux, the line numbers help > a lot in locating bogus code. Right now on Mac, you have to configure with -gstabs+. DbgHelp doesn't support DWARF on Mac OS yet. (It doesn't know how to find the .dSYM bundle or the original object files.) > > Thank for your help, You're welcome. Chip

May 23, 2011

Re: no line numbers in backtraces on Mac OS X?

by Eric Pouech

we miss dwarf support on mac it's likely the cause here (if you can, you can try to compile with stabs, it should work) (there's an open bug in bugzilla for this) A+ 2011/5/23 <Joerg-Cyril.Hoehle(a)t-systems.com> > Hi, > > Is it normal that there are no source line numbers in backtraces on Mac OS? > Despite many patches to winedbg etc., the backtraces I get are > no better that those from 1.1.24 times. > 18 0x41f5b2a1 _OpenDriverA+0x51() in winmm (0x0032ce78) > 19 0x4041467f _initAudioDlg+0x75f() in winecfg (0x0032dc28) > > I'm using configure + make to build. On Linux, the line numbers help > a lot in locating bogus code. > > Thank for your help, > Jörg Höhle. > > > -- -- Eric Pouech

May 23, 2011

no line numbers in backtraces on Mac OS X?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Is it normal that there are no source line numbers in backtraces on Mac OS? Despite many patches to winedbg etc., the backtraces I get are no better that those from 1.1.24 times. 18 0x41f5b2a1 _OpenDriverA+0x51() in winmm (0x0032ce78) 19 0x4041467f _initAudioDlg+0x75f() in winecfg (0x0032dc28) I'm using configure + make to build. On Linux, the line numbers help a lot in locating bogus code. Thank for your help, Jörg Höhle.

May 23, 2011

mmsystem16.h incorrect? SEGPTR vs. LPSTR

by Joerg-Cyril.Hoehle＠t-systems.com

Alexandre, Damjan, Eric, I understand your answers mean that a patch is needed to MCI_*_PARMS16 in mmsystem16.h to turn all occurrences of LPSTR into SEGPTR. E.g. MCI_LOAD_PARMS16, MCI_DGV_INFO_PARMS16, MCI_DGV_OPEN_PARMS16 ... I suppose "DWORD dwCallback;" is ok to copy 1:1 (what the code currently does) because it contains a window handle, not pointer. It would be wrong if the 16bit SDK contained HWND16 wCallback; UINT16 wReserved0; because then Wine might see half garbage and be lucky when wReserved is 0. Regards, Jörg Höhle

May 23, 2011

Re: mmsystem16.h incorrect? SEGPTR vs. LPSTR

by Damjan Jovanovic

On Mon, May 23, 2011 at 2:54 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Executive summary: I believe LPSTR is all wrong in mmsystem16.h's MCI defs. > > Hi, > > I've some doubts about the correctness of some definitions in > mmsystem16.h, esp. the use of SEGPTR vs. LPSTR types. > > Please compare > typedef struct { > DWORD dwCallback; > LPSTR lpstrReturn; > ... > } MCI_DGV_INFO_PARMS16, * LPMCI_DGV_INFO_PARMS16; > http://source.winehq.org/source//include/wine/mmsystem16.h > typedef struct { > DWORD dwCallback; > SEGPTR lpstrReturn; > ... > } MCI_INFO_PARMS16, *LPMCI_INFO_PARMS16; > > These definitions do not match. SEGPTR requires the use of the > MapSL() helper function to correctly access the segmented pointer, > while LPSTR is a linear string pointer. > > For reasons I recently explained in > http://www.winehq.org/pipermail/wine-devel/2011-May/090060.html > I very much doubt that both pointer types were used simultaneously -- unless > the digital video device (mciavi16.dll?) embedded different return > types in its resource file. It's not impossible, just very unlikely. > > Within one winmm, The return type MCI_STRING (value 0001) can *either* denote > linear C strings, or segmented ones. Should 2 types really have been > used as the above structure definitions suggest, then one will > have a distinct return value in its resource definition file > (e.g. mciavi_res.rc or extractable from the .dll). For instance, > that's how we derived that there must exist a distinct value for > 64bit use we then named MCI_INTEGER64 in Wine's mmddk.h > > However, I feel it's more likely that LPSTR above is wrong, that no > distinct return type was used and that segmented pointers were used in > most places within the MCI in 16 bit times, partly because Wine > currently uses the SEGPTR definitions and MapSL() helpers in its > current code base and would have crashed otherwise (but if that code > is never exercised?). > > Likewise for MCI_OPEN_PARMS16 and MCI_DGV_OPEN_PARMS16. Wine's > current MCI code would choke if it had to deal with 2 different types > of pointers here. > > To give another example, I find it illogical that MCI_LOAD_PARMS16 > takes an LPCSTR, while MCI_SOUND_PARMS16 takes a SEGPTR according to > mmsystem16.h. It's not about a different name, it's entirely > different content! > > I'd be pleased if somebody could grab out an old SDK and have a look > at the includes or otherwise shed light on this issue. > > Thank you for your help, > Jörg Höhle > > > AFAICT Wine's 16 bit headers cannot be used to compile Win16 code into a Winelib. The only purpose of Wine's 16 bit headers is to allow 32 bit code to read and write 16 bit structures and thus play nicely with 16 bit binaries. That's why Wine's types and names of 16 bit fields, structures, functions and headers don't always match what Win16 actually used, and why those headers are in a special directory that won't exist on any Windows API (include/wine/). According to Openwatcom's headers, LPSTR is a FAR pointer to char. "FAR" is a 16:16 segmented pointer, which makes sense, because Win16, being 16 bit, had no 32 bit linear pointer type in user-space (only kernel VxDs had it). So the Win16 MCI headers' LP[C]STRs were still 16:16 pointers to char. The SEGPTR type doesn't exist on Win16 at all. It's a Wine invention to conveniently mark a 16:16 pointer and since it's an integer type, it catches attempts to assign directly between 32 bit linear pointers and SEGPTRs with compiler warnings. So it seems Wine's headers should never use LP[C]STR in 16 bit structures, SEGPTR should always be used instead. Damjan Jovanovic

May 23, 2011

Re: mmsystem16.h incorrect? SEGPTR vs. LPSTR

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > I'd be pleased if somebody could grab out an old SDK and have a look > at the includes or otherwise shed light on this issue. You won't find anything in the SDK. SEGPTR is a Wine invention to help distinguish pointers that have already been converted. The SDK uses LPSTR etc. throughout, but these are obviously all segmented pointers in 16-bit code. -- Alexandre Julliard julliard(a)winehq.org

May 23, 2011

mmsystem16.h incorrect? SEGPTR vs. LPSTR

by Joerg-Cyril.Hoehle＠t-systems.com

Executive summary: I believe LPSTR is all wrong in mmsystem16.h's MCI defs. Hi, I've some doubts about the correctness of some definitions in mmsystem16.h, esp. the use of SEGPTR vs. LPSTR types. Please compare typedef struct { DWORD dwCallback; LPSTR lpstrReturn; ... } MCI_DGV_INFO_PARMS16, * LPMCI_DGV_INFO_PARMS16; http://source.winehq.org/source//include/wine/mmsystem16.h typedef struct { DWORD dwCallback; SEGPTR lpstrReturn; ... } MCI_INFO_PARMS16, *LPMCI_INFO_PARMS16; These definitions do not match. SEGPTR requires the use of the MapSL() helper function to correctly access the segmented pointer, while LPSTR is a linear string pointer. For reasons I recently explained in http://www.winehq.org/pipermail/wine-devel/2011-May/090060.html I very much doubt that both pointer types were used simultaneously -- unless the digital video device (mciavi16.dll?) embedded different return types in its resource file. It's not impossible, just very unlikely. Within one winmm, The return type MCI_STRING (value 0001) can *either* denote linear C strings, or segmented ones. Should 2 types really have been used as the above structure definitions suggest, then one will have a distinct return value in its resource definition file (e.g. mciavi_res.rc or extractable from the .dll). For instance, that's how we derived that there must exist a distinct value for 64bit use we then named MCI_INTEGER64 in Wine's mmddk.h However, I feel it's more likely that LPSTR above is wrong, that no distinct return type was used and that segmented pointers were used in most places within the MCI in 16 bit times, partly because Wine currently uses the SEGPTR definitions and MapSL() helpers in its current code base and would have crashed otherwise (but if that code is never exercised?). Likewise for MCI_OPEN_PARMS16 and MCI_DGV_OPEN_PARMS16. Wine's current MCI code would choke if it had to deal with 2 different types of pointers here. To give another example, I find it illogical that MCI_LOAD_PARMS16 takes an LPCSTR, while MCI_SOUND_PARMS16 takes a SEGPTR according to mmsystem16.h. It's not about a different name, it's entirely different content! I'd be pleased if somebody could grab out an old SDK and have a look at the includes or otherwise shed light on this issue. Thank you for your help, Jörg Höhle

May 23, 2011

Request for comments: d3dX : wined3d implicit enum conversion warnings and resolution

by Frédéric Delanoy

Hi guys, while trying to compile wine with clang, I get a whole bunch of "implicit conversion from enumeration type FOO to different enumeration type WINED3DFOO" (and conversely) warnings when an enum value of type A is assigned to a var of enum type B. In order to tackle those, instead of using (probably ugly) casts everywhere, I put them in a "static inline" function in d3dX_private.h (conv functions put in the header so inlining is possible everywhere, so a potential performance impact is limited) Originally, I intended to issue a FIXME("Unhandled/unrecognized value...") in the default: clause of a switch statement to catch values not in in the original enum's domain, but I couldn't find a way to make FIXMEs work in a .h file 'cos of a macro expansion hell I'm not quite sure however what the best solution is wrt performance, so I'd like your comments on this Some explanations: *D3DPOOL and WINED3DPOOL have a full 1-1 mapping, so the conv functions simply do a cast. *D3DRESOURCETYPE and WINED3DRESOURCETYPE have *not* a 1-1 mapping, and I present here 3 possible solution types: D3DRESOURCETYPE => D3DRTYPE_SURFACE = 1, D3DRTYPE_VOLUME = 2, D3DRTYPE_TEXTURE = 3, D3DRTYPE_VOLUMETEXTURE = 4, D3DRTYPE_CUBETEXTURE = 5, D3DRTYPE_VERTEXBUFFER = 6, D3DRTYPE_INDEXBUFFER = 7, D3DRTYPE_FORCE_DWORD = 0x7fffffff WINED3DRESOURCETYPE => WINED3DRTYPE_SURFACE = 1, WINED3DRTYPE_VOLUME = 2, WINED3DRTYPE_TEXTURE = 3, WINED3DRTYPE_VOLUMETEXTURE = 4, WINED3DRTYPE_CUBETEXTURE = 5, WINED3DRTYPE_BUFFER = 6, WINED3DRTYPE_FORCE_DWORD = 0x7fffffff Type 1 --------- Identical semantics to direct assigment All cases specified, even "obvious" ones (D3D_FOO <-> WINED3D_FOO), using same enum value; non mapped values use the default: clause (e.g. D3DRTYPE_INDEXBUFFER=7; no 7 enum val in WINED3DRESOURCETYPE) Default clause: only used for values not in original enum Type 2 --------- Same as v1 except obvious values aren't specified in a case: Non directly obvious values (same enum val) can still be "highlighted" (e.g. WINED3DRTYPE_BUFFER=6 ==> D3DRTYPE_VERTEXBUFFER=6) Default clause: used for values not in original enum AND obvious values Maybe more optimal than "type 1", but isn't that a micro/premature optimisation? Type 3 --------- Potentially more risky/invasive: conversion does not simply return value "as-is" Semantics *changes* from direct assigment; some additional code changes are necessary; could help centralise, though e.g. D3DRTYPE_VERTEXBUFFER=6 => WINED3DRTYPE_BUFFER=6 D3DRTYPE_INDEXBUFFER=7 => WINED3DRTYPE_BUFFER=6 Adapted code (directx.c): - switch(RType) { - case D3DRTYPE_VERTEXBUFFER: - case D3DRTYPE_INDEXBUFFER: - WineD3DRType = WINED3DRTYPE_BUFFER; - break; - - default: - WineD3DRType = RType; - break; - } + WineD3DRType = wined3dresourcetype_from_d3dresourcetype(RType); What do you think would be best? Frédéric

May 23, 2011

Re: ddraw: Don't interpret end padding as dwCaps2 for x64.

by Alexandre Julliard

Dylan Smith <dylan.ah.smith(a)gmail.com> writes: > @@ -3123,6 +3123,8 @@ static HRESULT CreateSurface(IDirectDrawImpl *ddraw, DDSURFACEDESC2 *DDSD, > memset(&desc2, 0, sizeof(desc2)); > desc2.dwSize = sizeof(desc2); /* For the struct copy */ > DD_STRUCT_COPY_BYSIZE(&desc2, DDSD); > + if (DDSD->dwSize == sizeof(DDSURFACEDESC)) > + CLEAR_STRUCT_END_PADDING((DDSURFACEDESC*)&desc2, ddsCaps); I'd suggest to rethink the whole thing. We don't really need to set the same structure fields 4 times. -- Alexandre Julliard julliard(a)winehq.org

May 23, 2011

Re: urlmon: Fix incorrect pointer arithmetic (too conversative) in map_url_to_zone.

by Nikolay Sivov

On Sun, May 22, 2011 at 10:53 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > The difference between two pointers (of the same type) is the number > of elements, not the number of bytes. That's why it was divided by element size to get 'number of elements'. What's a problem? > Thus the code below was way > incorrect, luckily only too conversative. > > Gerald > > --- > dlls/urlmon/sec_mgr.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/urlmon/sec_mgr.c b/dlls/urlmon/sec_mgr.c > index 7b4bb35..75850ee 100644 > --- a/dlls/urlmon/sec_mgr.c > +++ b/dlls/urlmon/sec_mgr.c > @@ -529,7 +529,7 @@ static HRESULT map_url_to_zone(LPCWSTR url, DWORD *zone, LPWSTR *ret_url) > hres = CoInternetParseUrl(secur_url, PARSE_PATH_FROM_URL, 0, path, > sizeof(path)/sizeof(WCHAR), &size, 0); > > - if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)/sizeof(WCHAR)) { > + if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)) { > UINT type; > > memcpy(root, path, (ptr-path)*sizeof(WCHAR)); > -- > 1.7.4.1 > > >

May 22, 2011

Re: comctl32: Shed an unused parameter of TOOLTIPS_HitTestT and rename to TOOLTIPS_HitTest. (RESEND)

by Nikolay Sivov

On Sun, May 22, 2011 at 6:07 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > Any problems with this patch I submitted back in February? > I believe I mentioned it, or I should have. Message handler is incomplete, cause it should return text as well, that's why it has A/W versions. This needs tests and proper implementation, not just reducing parameters list for no reason. (and if tests show no use of text for these messages it's a reason of course) > Gerald > > --- > dlls/comctl32/tooltips.c | 7 +++---- > 1 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c > index a2e58e0..445845c 100644 > --- a/dlls/comctl32/tooltips.c > +++ b/dlls/comctl32/tooltips.c > @@ -1396,8 +1396,7 @@ TOOLTIPS_GetToolInfoT (const TOOLTIPS_INFO *infoPtr, TTTOOLINFOW *ti, BOOL isW) > > > static LRESULT > -TOOLTIPS_HitTestT (const TOOLTIPS_INFO *infoPtr, LPTTHITTESTINFOW lptthit, > - BOOL isW) > +TOOLTIPS_HitTest (const TOOLTIPS_INFO *infoPtr, LPTTHITTESTINFOW lptthit) > { > TTTOOL_INFO *toolPtr; > INT nTool; > @@ -2209,8 +2208,8 @@ TOOLTIPS_WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > > case TTM_HITTESTA: > case TTM_HITTESTW: > - return TOOLTIPS_HitTestT (infoPtr, (LPTTHITTESTINFOW)lParam, > - uMsg == TTM_HITTESTW); > + return TOOLTIPS_HitTest (infoPtr, (LPTTHITTESTINFOW)lParam); > + > case TTM_NEWTOOLRECTA: > case TTM_NEWTOOLRECTW: > return TOOLTIPS_NewToolRectT (infoPtr, (LPTTTOOLINFOW)lParam); > -- > 1.7.4.1 > > >

May 22, 2011

Re: TestBot job 11094 results: Re: comctl32/tests: Add casts to avoid comparison of different int types. [take 2]

by Gerald Pfeifer

On Mon, 23 May 2011, Marvin wrote: > VM Status Number of test failures > WINEBUILD completed > WNT4WSSP6 completed 0 > W2KPROSP4 completed 0 > WXPPROSP3 completed 0 > W2K3R2SESP2 failed > WVISTAADM completed 0 > W2K8SE completed 0 > W7PRO completed 0 > W7PROX64 completed 0 > W7PROX64 completed 0 For the record, I plead not guilty as far as the following goes. === W2K3R2SESP2 (32 bit tab) === Can't copy exe to VM: Failed to resolve host :-) Gerald

May 22, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by Ove Kåven

Den 22. mai 2011 21:48, skrev Scott Ritchie: > On 05/22/2011 03:53 AM, Ove Kåven wrote: >> Den 21. mai 2011 19:38, skrev Scott Ritchie: >>> Well now we can just Depends: wine:i386 or similar, I think. >> >> Last time I asked, they said the first multiarch implementation will not >> support that. The implementation cost of that would be very high (among >> other things, it might violate the current architecture >> self-containment), and the number of packages needing it is too small. >> > > Looking at the spec, it seems like Depends: wine:i386 isn't allowed, > however we can create a unique package name that only exists on i386 (eg > wine32), declare it Multiarch: foreign, and then have wine depend on wine32. Yes, that was what I was thinking of doing if I had to. But it's really not very clean...

May 22, 2011

Re: user32: Partially implement FlashWindowEx with tests

by Detlef Riekenberg

On So, 2011-05-22, André Hentschel wrote > Thanks, will get into try 2 > pfwi->cbSize < sizeof(FLASHWINFO) || pfwi->cbSize > sizeof(FLASHWINFO) That code can be reduced to: pfwi->cbSize != sizeof(FLASHWINFO) -- By by ... Detlef

May 22, 2011

Re: ddraw: Don't interpret end padding as dwCaps2 for x64.

by Dylan Smith

On Sun, May 22, 2011 at 3:10 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Sunday 22 May 2011 06:57:30 Dylan Smith wrote: >> 4 bytes of padding are at the end of DDSURFACEDESC when compiling for >> x64, because it contains a pointer field followed by an odd number >> of DWORD fields. > Does DDSURFACEDESC have the same padding when using the microsoft headers and > msvc? > I tried and got the same results for x64: offsetof(DDSURFACEDESC, ddsCaps) = 112 offsetof(DDSURFACEDESC, ddsCaps) + sizeof(DDSCAPS) = 116 sizeof(DDSURFACEDESC) = 120

May 22, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by Scott Ritchie

On 05/22/2011 03:53 AM, Ove Kåven wrote: > Den 21. mai 2011 19:38, skrev Scott Ritchie: >> Well now we can just Depends: wine:i386 or similar, I think. > > Last time I asked, they said the first multiarch implementation will not > support that. The implementation cost of that would be very high (among > other things, it might violate the current architecture > self-containment), and the number of packages needing it is too small. > Looking at the spec, it seems like Depends: wine:i386 isn't allowed, however we can create a unique package name that only exists on i386 (eg wine32), declare it Multiarch: foreign, and then have wine depend on wine32.

May 22, 2011

Re: comctl32/tests: Add casts to avoid comparison of different int types. [take 2]

by Gerald Pfeifer

On Wed, 16 Feb 2011, Alexandre Julliard wrote: >> This is the first hunk of a patch a few days ago; testbot.winehq.org >> thinks it's fine: https://testbot.winehq.org/JobDetails.pl?Key=9291 > You don't need casts. If the variable has the wrong type you can change > that. At first I didn't realize what you had in mind, but now I believe the patch below does this. :-) Gerald ChangeLog: comctl32/tests: Rewrite a test in test_TCS_OWNERDRAWFIXED to avoid a type mismatch or cast. --- dlls/comctl32/tests/tab.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/dlls/comctl32/tests/tab.c b/dlls/comctl32/tests/tab.c index 8b64764..7f5bbb7 100644 --- a/dlls/comctl32/tests/tab.c +++ b/dlls/comctl32/tests/tab.c @@ -1313,6 +1313,7 @@ static void test_TCM_SETITEMEXTRA(void) static void test_TCS_OWNERDRAWFIXED(void) { LPARAM lparam, lparam2; + ULONG_PTR itemdata; TCITEMA item; HWND hTab; BOOL ret; @@ -1335,9 +1336,9 @@ static void test_TCS_OWNERDRAWFIXED(void) ShowWindow(hTab, SW_SHOW); RedrawWindow(hTab, NULL, 0, RDW_UPDATENOW); - lparam = 0; - memset(&lparam, 0xde, 4); - ok(g_drawitem.itemData == lparam, "got %lx, expected %lx\n", g_drawitem.itemData, lparam); + itemdata = 0; + memset(&itemdata, 0xde, 4); + ok(g_drawitem.itemData == itemdata, "got %lx, expected %lx\n", g_drawitem.itemData, itemdata); DestroyWindow(hTab); -- 1.7.4.1

May 22, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by Marcus Meissner

On Sun, May 22, 2011 at 06:26:45AM -0700, James McKenzie wrote: > On 5/21/11 11:51 PM, Marcus Meissner wrote: > >On Sat, May 21, 2011 at 05:57:40PM -0700, James McKenzie wrote: > >>On 5/19/11 1:51 PM, Marcus Meissner wrote: > >>>It is trivial. You basically build wine twice, once in the 32bit > >>>environment and once inthe 64bit one. > >>> > >>Maybe Wine can look into some sort of merge process to build both > >>and at runtime select one or the other? I don't know if this is > >>possible, I'm just 'throwing the idea out there'. > >Not sure what you mean. > > > >If you install 64 bit wine + 32bit stuff I listed, you will have > >a 64+32 bit capable wine setup. > > > That was the answer I was looking for. Thank you, Marcus. The > ability is already there. So, if I install 64 bit wine on a 64 bit > machine it should work something like what Windows does now, one > directory (wineprefix) for 64 bitness and one directory (wineprefix) > for 32 bitness. wineprefix for the installed .exe and .dlls? as in ~/.wine/ ? A 64bit install and/or a 32bit install will use just 1 wineprefix (~/.wine) If the setup is done by the 64bit binary, it will be set up in away that both 64 and 32bit windows binaries will work. But 64bit and 32bit ~/.wine are not seperate. Ciao, Marcus

May 22, 2011

Re: user32: Partially implement FlashWindowEx with tests

by André Hentschel

Am 22.05.2011 09:58, schrieb Dmitry Timoshkov: > André Hentschel <nerv(a)dawncrow.de> wrote: > >> + if (!pfwi->hwnd || pfwi->cbSize < sizeof(FLASHWINFO)) >> + { >> + SetLastError(ERROR_INVALID_PARAMETER); >> + return FALSE; >> + } > > I don't see in your tests the case for 'cbSize > sizeof(FLASHWINFO)'. > Also using !IsWindow() instead of !hwnd would fix one more test case. > Thanks, will get into try 2 -- Best Regards, André Hentschel

May 22, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by James McKenzie

On 5/21/11 11:51 PM, Marcus Meissner wrote: > On Sat, May 21, 2011 at 05:57:40PM -0700, James McKenzie wrote: >> On 5/19/11 1:51 PM, Marcus Meissner wrote: >>> It is trivial. You basically build wine twice, once in the 32bit >>> environment and once inthe 64bit one. >>> >> Maybe Wine can look into some sort of merge process to build both >> and at runtime select one or the other? I don't know if this is >> possible, I'm just 'throwing the idea out there'. > Not sure what you mean. > > If you install 64 bit wine + 32bit stuff I listed, you will have > a 64+32 bit capable wine setup. > That was the answer I was looking for. Thank you, Marcus. The ability is already there. So, if I install 64 bit wine on a 64 bit machine it should work something like what Windows does now, one directory (wineprefix) for 64 bitness and one directory (wineprefix) for 32 bitness. James McKenzie

May 22, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by Ove Kåven

Den 21. mai 2011 19:38, skrev Scott Ritchie: > Well now we can just Depends: wine:i386 or similar, I think. Last time I asked, they said the first multiarch implementation will not support that. The implementation cost of that would be very high (among other things, it might violate the current architecture self-containment), and the number of packages needing it is too small. > I don't mean the multiarch change, I mean the "build daemons will not > allow have foreign multiarch build dependencies" change, which I guess > isn't a change so much as it is a property of the new system. Well that's not any different from how it works now. There wouldn't be any management implications of that. >> Multiarch has no management implications whatsoever for the build >> daemons. All official Debian architectures are perfectly self-contained >> as they are. (Some of them currently contain cross-compiled pieces of >> other architectures, which would go away, but that does not concern the >> build daemons or the infrastructure.) > > Multiarch with foreign architecture build support would eliminate the > self-containment, wouldn't it? As far as the infrastructure is concerned, it is the runtime dependencies that are important. Until now, nothing in Debian had foreign architecture support, apart from Arch:all packages (which don't really count), which is why we now have the abomination that is ia32-libs. For the first version of multiarch, the buildds and dak are not going to change - only the package managers (and package build tools) would need to be aware of multiarch. Maybe foreign architecture support for the archive tools are added later, maybe not. Either way, infrastructure maintenance is not going to get easier.

May 22, 2011

Re: user32: Partially implement FlashWindowEx with tests

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > + if (!pfwi->hwnd || pfwi->cbSize < sizeof(FLASHWINFO)) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return FALSE; > + } I don't see in your tests the case for 'cbSize > sizeof(FLASHWINFO)'. Also using !IsWindow() instead of !hwnd would fix one more test case. -- Dmitry.

May 22, 2011

Re: ddraw: Don't interpret end padding as dwCaps2 for x64.

by Stefan Dösinger

On Sunday 22 May 2011 06:57:30 Dylan Smith wrote: > 4 bytes of padding are at the end of DDSURFACEDESC when compiling for > x64, because it contains a pointer field followed by an odd number > of DWORD fields. Does DDSURFACEDESC have the same padding when using the microsoft headers and msvc?

May 22, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by Marcus Meissner

On Sat, May 21, 2011 at 05:57:40PM -0700, James McKenzie wrote: > On 5/19/11 1:51 PM, Marcus Meissner wrote: > >It is trivial. You basically build wine twice, once in the 32bit > >environment and once inthe 64bit one. > > > Maybe Wine can look into some sort of merge process to build both > and at runtime select one or the other? I don't know if this is > possible, I'm just 'throwing the idea out there'. Not sure what you mean. If you install 64 bit wine + 32bit stuff I listed, you will have a 64+32 bit capable wine setup. Ciao, Marcus

May 22, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by James McKenzie

On 5/19/11 1:51 PM, Marcus Meissner wrote: > It is trivial. You basically build wine twice, once in the 32bit > environment and once inthe 64bit one. > Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'. James McKenzie

May 21, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by James McKenzie

On 5/19/11 1:51 PM, Marcus Meissner wrote: > It is trivial. You basically build wine twice, once in the 32bit > environment and once inthe 64bit one. > Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'. James McKenzie

May 21, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by Scott Ritchie

On 05/21/2011 08:20 AM, Ove Kåven wrote: > Den 19. mai 2011 20:58, skrev Scott Ritchie: >> A side effect of this change, however, is the current build daemons ONLY >> have packages for one architecture. This means that, at build time, you >> won't be able to pull in the 32-bit packages on a 64-bit build daemon. > > Well, I don't see the problem. I've been more concerned that there's not > yet any clean way to get the 64-bit package to depend on the 32-bit > package, but for the build itself, it's quite trivial. (At least it was > a year ago or so, and I can't imagine it has gotten worse since then.) > Well now we can just Depends: wine:i386 or similar, I think. >> From what I understand, this change is originating in Debian (and thus >> propagating to Ubuntu). I believe the motivations are mostly ease of >> management of the build daemons -- only by doing this, for instance, can >> an entire architecture be properly isolated and self-contained. > > No. Very, very, far from it. > > The multiarch specs are created and maintained by a Ubuntu (and Debian) > developer, and the motivations are purely user-oriented - making it > possible, easy, and reliable for the user to do things that's currently > difficult, fragile, and error-prone. But for package maintainers, life > will certainly be no easier. > I don't mean the multiarch change, I mean the "build daemons will not allow have foreign multiarch build dependencies" change, which I guess isn't a change so much as it is a property of the new system. You're quite right that multiarch proper is for users; it's something I've been demanding for a while now. > Multiarch has no management implications whatsoever for the build > daemons. All official Debian architectures are perfectly self-contained > as they are. (Some of them currently contain cross-compiled pieces of > other architectures, which would go away, but that does not concern the > build daemons or the infrastructure.) > > Multiarch with foreign architecture build support would eliminate the self-containment, wouldn't it?

May 21, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by Ove Kåven

Den 19. mai 2011 20:58, skrev Scott Ritchie: > A side effect of this change, however, is the current build daemons ONLY > have packages for one architecture. This means that, at build time, you > won't be able to pull in the 32-bit packages on a 64-bit build daemon. Well, I don't see the problem. I've been more concerned that there's not yet any clean way to get the 64-bit package to depend on the 32-bit package, but for the build itself, it's quite trivial. (At least it was a year ago or so, and I can't imagine it has gotten worse since then.) > From what I understand, this change is originating in Debian (and thus > propagating to Ubuntu). I believe the motivations are mostly ease of > management of the build daemons -- only by doing this, for instance, can > an entire architecture be properly isolated and self-contained. No. Very, very, far from it. The multiarch specs are created and maintained by a Ubuntu (and Debian) developer, and the motivations are purely user-oriented - making it possible, easy, and reliable for the user to do things that's currently difficult, fragile, and error-prone. But for package maintainers, life will certainly be no easier. Multiarch has no management implications whatsoever for the build daemons. All official Debian architectures are perfectly self-contained as they are. (Some of them currently contain cross-compiled pieces of other architectures, which would go away, but that does not concern the build daemons or the infrastructure.)

May 21, 2011

hello

by chris.teague＠gmail.com

, i paid off all my debt http://tulsamarketplace.com/redirect.php?to=aHR0cDovL3d3dy5jbmJjNy5jb20vP3B…

May 20, 2011

Re: gdi32: Fetch CURVECAPS, LINECAPS and POLYGONALCAPS for an EMF from parent device.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > This follows the way how it's done for other device capabilities. >> >> It's not clear that this makes sense, a metafile is capable of doing all >> these things even if the device cannot. Have you verified this on a >> device that doesn't have all the caps? > > I'd expect you asked that question to the person adding these caps in > the first place. I just did what's already done with for textcaps and > rastercaps which is quite straightforward. Returning capabilities matching what metafiles can do makes sense to me, returning caps from an unrelated device doesn't. Of course Windows isn't known for doing things that make sense, but I'd still like to see a test case. -- Alexandre Julliard julliard(a)winehq.org

May 20, 2011

Re: gdi32: Fetch CURVECAPS, LINECAPS and POLYGONALCAPS for an EMF from parent device.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > This follows the way how it's done for other device capabilities. > > It's not clear that this makes sense, a metafile is capable of doing all > these things even if the device cannot. Have you verified this on a > device that doesn't have all the caps? I'd expect you asked that question to the person adding these caps in the first place. I just did what's already done with for textcaps and rastercaps which is quite straightforward. -- Dmitry.

May 20, 2011

Re: gdi32: Fetch CURVECAPS, LINECAPS and POLYGONALCAPS for an EMF from parent device.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This follows the way how it's done for other device capabilities. It's not clear that this makes sense, a metafile is capable of doing all these things even if the device cannot. Have you verified this on a device that doesn't have all the caps? -- Alexandre Julliard julliard(a)winehq.org

May 20, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by Marcus Meissner

On Thu, May 19, 2011 at 11:58:47AM -0700, Scott Ritchie wrote: > So, multiarch is going along well in Debian/Ubuntu, and by next distro > release Wine should be building as a proper multiarch package. Previous > hacks like ia32-libs will be dead for good. > > > A side effect of this change, however, is the current build daemons ONLY > have packages for one architecture. This means that, at build time, you > won't be able to pull in the 32-bit packages on a 64-bit build daemon. > > > From what I understand, this change is originating in Debian (and thus > propagating to Ubuntu). I believe the motivations are mostly ease of > management of the build daemons -- only by doing this, for instance, can > an entire architecture be properly isolated and self-contained. > > > This means for bi-arch Wine, we will need to either: > - Make Wine support building in pure 64-bit mode and then calling the > 32-bit subsystem from a separate binary > - Make a very persuasive case that Wine isn't the only package that > needs to have multiple architectures at build time > > > Hopefully I'm overestimating the amount of work involved, as this sort > of architecture modularity might be a "nice to have" in Wine anyway. > > If none of this is doable by next release, we'll just have a 32-bit only > Wine, which isn't really any worse than the situation now. It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one. You just need to take care you can install both. For openSUSE I create the binary packages: wine-32bit (i586 build) /usr/lib/libwine* /usr/lib/wine/* /usr/bin/wine /usr/bin/wine-preloader wine (both a i586 and x86_64 package) both requires the wine-32bit package Contain all other files not in wine-32bit. for 64bit also the runtime things /usr/lib64/libwine* /usr/lib64/wine/* /usr/bin/wine64 /usr/bin/wine64-preloader So basically depending on which architecture it is installed on, you get wine and wine-32bit on the final system ... Just on 64bit the wine package is 64bit. There is no need for 32bit and 64bit cross usage during build. Ciao, Marcus

May 19, 2011

Re: [3/3] d3d9: Try to get the INTZ test working on nvidia cards

by Henri Verbeet

I think I'd rather just change the way the test works.

May 19, 2011

Re: Big ugly build changes might be needed for Debian/Ubuntu

by Michael Stefaniuc

Scott Ritchie wrote: > So, multiarch is going along well in Debian/Ubuntu, and by next distro > release Wine should be building as a proper multiarch package. Previous > hacks like ia32-libs will be dead for good. > > > A side effect of this change, however, is the current build daemons ONLY > have packages for one architecture. This means that, at build time, you > won't be able to pull in the 32-bit packages on a 64-bit build daemon. > > > From what I understand, this change is originating in Debian (and thus > propagating to Ubuntu). I believe the motivations are mostly ease of > management of the build daemons -- only by doing this, for instance, can > an entire architecture be properly isolated and self-contained. > > > This means for bi-arch Wine, we will need to either: > - Make Wine support building in pure 64-bit mode and then calling the > 32-bit subsystem from a separate binary > - Make a very persuasive case that Wine isn't the only package that > needs to have multiple architectures at build time > > > Hopefully I'm overestimating the amount of work involved, as this sort > of architecture modularity might be a "nice to have" in Wine anyway. > > If none of this is doable by next release, we'll just have a 32-bit only > Wine, which isn't really any worse than the situation now. http://wiki.winehq.org/Wine64ForPackagers bye michael

May 19, 2011

Big ugly build changes might be needed for Debian/Ubuntu

by Scott Ritchie

So, multiarch is going along well in Debian/Ubuntu, and by next distro release Wine should be building as a proper multiarch package. Previous hacks like ia32-libs will be dead for good. A side effect of this change, however, is the current build daemons ONLY have packages for one architecture. This means that, at build time, you won't be able to pull in the 32-bit packages on a 64-bit build daemon. >From what I understand, this change is originating in Debian (and thus propagating to Ubuntu). I believe the motivations are mostly ease of management of the build daemons -- only by doing this, for instance, can an entire architecture be properly isolated and self-contained. This means for bi-arch Wine, we will need to either: - Make Wine support building in pure 64-bit mode and then calling the 32-bit subsystem from a separate binary - Make a very persuasive case that Wine isn't the only package that needs to have multiple architectures at build time Hopefully I'm overestimating the amount of work involved, as this sort of architecture modularity might be a "nice to have" in Wine anyway. If none of this is doable by next release, we'll just have a 32-bit only Wine, which isn't really any worse than the situation now. -Scott Ritchie

May 19, 2011

Re: [PATCH 7/7] msvcrt: Make functions working on FILE thread safe

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msvcrt/file.c | 448 > ++++++++++++++++++++++++++++++++++++---------------- > 1 files changed, 314 insertions(+), 134 deletions(-) This one should probably be split. It also breaks badly on 64-bit: ../../../../wine/tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so ../../../../wine/dlls/mshtml/tests/activex.c && touch activex.ok err:seh:setup_exception stack overflow 2336 bytes in thread 0021 eip 00002b829f113a5d esp 0000000000140ce0 stack 0x140000-0x141000-0x240000 -- Alexandre Julliard julliard(a)winehq.org

May 19, 2011

Re: hostname: Add an implementation of the hostname display utility. (try 2)

by Alexandre Julliard

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > diff --git a/programs/hostname/Makefile.in b/programs/hostname/Makefile.in > new file mode 100644 > index 0000000..300d727 > --- /dev/null > +++ b/programs/hostname/Makefile.in > @@ -0,0 +1,12 @@ > +EXTRADEFS = -DWINE_NO_UNICODE_MACROS > +MODULE = hostname.exe > +APPMODE = -mconsole -municode > +IMPORTS = ws2_32 You probably don't want to use winsock, at least not for Unix builds. -- Alexandre Julliard julliard(a)winehq.org

May 19, 2011

Re: [2/2] d3dx9: Implement D3DXLoadMeshHierarchy for basic mesh hierarchy.

by Joris Huizer

On 05/19/2011 06:34 PM, Dylan Smith wrote: > On Thu, May 19, 2011 at 6:16 AM, Joris Huizer<joris_huizer(a)yahoo.com> wrote: >> Hello, >> >> I found a possibly memory leak in the patch. >> In this function: >> >>> +static HRESULT parse_mesh(IDirectXFileData *filedata, struct mesh_data *mesh_data, DWORD provide_flags) >> These may leak the allocated blocks: >>> + >>> + mesh_data->vertices = HeapAlloc(GetProcessHeap(), 0, >>> + mesh_data->num_vertices * sizeof(*mesh_data->vertices)); >>> + mesh_data->num_tri_per_face = HeapAlloc(GetProcessHeap(), 0, >>> + mesh_data->num_poly_faces * sizeof(*mesh_data->num_tri_per_face)); >>> + mesh_data->indices = HeapAlloc(GetProcessHeap(), 0, >>> + (mesh_data->num_tri_faces + mesh_data->num_poly_faces * 2) * sizeof(*mesh_data->indices)); >>> + if (!mesh_data->vertices || !mesh_data->num_tri_per_face || !mesh_data->indices) >>> + return E_OUTOFMEMORY; >>> + > All the pointers are stored in mesh_data, which isn't lost. They are > freed at the end of load_skin_mesh_from_xof. > > +cleanup: > + if (FAILED(hr)) { > + if (d3dxmesh) IUnknown_Release(d3dxmesh); > + if (adjacency) ID3DXBuffer_Release(adjacency); > + } > + HeapFree(GetProcessHeap(), 0, mesh_data.vertices); > + HeapFree(GetProcessHeap(), 0, mesh_data.num_tri_per_face); > + HeapFree(GetProcessHeap(), 0, mesh_data.indices); > + return hr; > +} Thanks for clarification (Sorry for the noise)

May 19, 2011

Re: [2/2] d3dx9: Implement D3DXLoadMeshHierarchy for basic mesh hierarchy.

by Dylan Smith

On Thu, May 19, 2011 at 6:16 AM, Joris Huizer <joris_huizer(a)yahoo.com> wrote: > > Hello, > > I found a possibly memory leak in the patch. > In this function: > >> +static HRESULT parse_mesh(IDirectXFileData *filedata, struct mesh_data *mesh_data, DWORD provide_flags) > > These may leak the allocated blocks: >> >> + >> + mesh_data->vertices = HeapAlloc(GetProcessHeap(), 0, >> + mesh_data->num_vertices * sizeof(*mesh_data->vertices)); >> + mesh_data->num_tri_per_face = HeapAlloc(GetProcessHeap(), 0, >> + mesh_data->num_poly_faces * sizeof(*mesh_data->num_tri_per_face)); >> + mesh_data->indices = HeapAlloc(GetProcessHeap(), 0, >> + (mesh_data->num_tri_faces + mesh_data->num_poly_faces * 2) * sizeof(*mesh_data->indices)); >> + if (!mesh_data->vertices || !mesh_data->num_tri_per_face || !mesh_data->indices) >> + return E_OUTOFMEMORY; >> + > All the pointers are stored in mesh_data, which isn't lost. They are freed at the end of load_skin_mesh_from_xof. +cleanup: + if (FAILED(hr)) { + if (d3dxmesh) IUnknown_Release(d3dxmesh); + if (adjacency) ID3DXBuffer_Release(adjacency); + } + HeapFree(GetProcessHeap(), 0, mesh_data.vertices); + HeapFree(GetProcessHeap(), 0, mesh_data.num_tri_per_face); + HeapFree(GetProcessHeap(), 0, mesh_data.indices); + return hr; +}

May 19, 2011

Re: oleaut32/tests: remove macros from test_VarCyCmpR8

by Nikolay Sivov

On Thu, May 19, 2011 at 11:30 AM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > > > > This test should use a table+loop I think.

May 19, 2011

Re: [bugzilla] Fix Bug 16822 - Mass Effect: Mouse input does not work (almost completely)

by Vitaliy Margolen

On 05/18/2011 12:03 PM, siro wrote: > This patch don't clear the dinput queue in IDirectInputDevice2WImpl_Acquire Clearly this is wrong. Of course you can prove otherwise with some tests. You can also test with native dinput to see if it has the same issue or not. Vitaliy.

May 19, 2011

Re: gdi32: Add support in DeviceCaps CURVECAPS, LINECAPS, POLYGONALCAPS for EnhMetafiles

by Dmitry Timoshkov

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > gdi32: Add support in DeviceCaps CURVECAPS, LINECAPS, POLYGONALCAPS > for EnhMetafiles I'd guess they should be cached and returned for the parent device instead. -- Dmitry.

May 19, 2011

Re: [2/2] d3dx9: Implement D3DXLoadMeshHierarchy for basic mesh hierarchy.

by Joris Huizer

Hello, I found a possibly memory leak in the patch. In this function: > +static HRESULT parse_mesh(IDirectXFileData *filedata, struct mesh_data *mesh_data, DWORD provide_flags) These may leak the allocated blocks: > + > + mesh_data->vertices = HeapAlloc(GetProcessHeap(), 0, > + mesh_data->num_vertices * sizeof(*mesh_data->vertices)); > + mesh_data->num_tri_per_face = HeapAlloc(GetProcessHeap(), 0, > + mesh_data->num_poly_faces * sizeof(*mesh_data->num_tri_per_face)); > + mesh_data->indices = HeapAlloc(GetProcessHeap(), 0, > + (mesh_data->num_tri_faces + mesh_data->num_poly_faces * 2) * sizeof(*mesh_data->indices)); > + if (!mesh_data->vertices || !mesh_data->num_tri_per_face || !mesh_data->indices) > + return E_OUTOFMEMORY; > + HTH, Joris

May 19, 2011

Re: [PATCH] winex11: Make GetCursorPos respect clipping and virtual screen size.

by Lauri Kenttä

Alexandre Julliard writes: > Lauri Kenttä <lauri.kentta(a)gmail.com> writes: >> With my touchpad the results are much more interesting. > > Most likely because XInput raw events don't take acceleration into > account. I'm not sure there's a whole lot we can do about that. I've disabled acceleration, and the problem persists. Unless there's some very well hidden option that doesn't react to xset or xinput. Alexandre Julliard writes: > I think enabling clipping for these apps is a better solution. But clearly that's not an option if the user has a tablet (or other absolute pointing device) and a touchpad (at least my touchpad). Even if the touchpad problem could be avoided by disabling acceleration, that's a pain for the user and makes the touchpad behave differently from what the user is used to. What about adding this feature along with a registry key? The implementation is only a few lines and works great in my case. Of course, this is not an essential feature, as the app works fine in real full-screen mode. So I won't press this any more. -- Lauri Kenttä

May 19, 2011

Re: [PATCH] dinput: Move the c_df* data format constants to the dxguid static library, mark as hidden

by Marcus Meissner

On Wed, May 18, 2011 at 10:57:59AM +0200, Alexandre Julliard wrote: > Marcus Meissner <meissner(a)suse.de> writes: > > > --- > > dlls/dinput/Makefile.in | 1 - > > dlls/dinput/data_formats.c | 566 -------------------------------------------- > > dlls/dxguid/dxguid.c | 545 ++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 545 insertions(+), 567 deletions(-) > > delete mode 100644 dlls/dinput/data_formats.c > > What makes you think they should be in dxguid? Wild guessing and web page reading. However, strings on some .lib files in DX SDK June 2010 finds it in dinput8.lib. So please disregard. Ciao, Marcus

May 19, 2011

Re: tests/msvcrt: add test for _splitpath function

by Eric Pouech

adding c:test.txt (and friends) as input should be also interesting UNC paths should also be tested A+ + } Paths[] = { {"C:/directory/test.txt", "C:", "/directory/", > "test", ".txt"}, > + {"C:\\directory\\test.txt", "C:", "\\directory\\", > "test", ".txt"}, > + {"C:\\directory\\test", "C:", "\\directory\\", "test", > ""}, > + {"C:\\directory\\.txt", "C:", "\\directory\\", "", > ".txt"}, > + {"C:\\directory\\", "C:", "\\directory\\", "", ""}, > + {"C:\\test.txt", "C:", "\\", "test", ".txt"}, > + {"C:\\test", "C:", "\\", "test", ""}, > + {"C:\\.txt", "C:", "\\", "", ".txt"}, > + {"C:\\", "C:", "\\", "", ""}, > + {"\\directory\\test.txt", "", "\\directory\\", "test", > ".txt"}, > + {"\\directory\\test", "", "\\directory\\", "test", ""}, > + {"\\directory\\.txt", "", "\\directory\\", "", ".txt"}, > + {"\\directory\\", "", "\\directory\\", "", ""}, > + {"\\test.txt", "", "\\", "test", ".txt"}, > + {"\\test", "", "\\", "test", ""}, > + {"\\.txt", "", "\\", "", ".txt"}, > + {"\\", "", "\\", "", ""}, > + {"test.txt", "", "", "test", ".txt"}, > + {"test", "", "", "test", ""}, > + {".txt", "", "", "", ".txt"}, > + {"", "", "", "", ""}}; > -- > Eric Pouech >

May 19, 2011

Re: d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang) - please discard patch

by Frédéric Delanoy

Patch can be discarded. Spreading casts all over is probably a bad thing.

May 19, 2011

Re: d3d8: Silence implicit enum conversion warnings for D3DFormat (clang) - please discard

by Frédéric Delanoy

Please discard this patch. An updated version follows.

May 18, 2011

Re: [PATCH] winex11: Make GetCursorPos respect clipping and virtual screen size.

by Alexandre Julliard

Lauri Kenttä <lauri.kentta(a)gmail.com> writes: > So is it then possible to clip the cursor to the virtual desktop in > the wineserver, or do you see some apparent problem there? I would be > surprised if this was the only application to choke on strange mouse > coordinates. It's possible, but it's not clear that it's desirable. Pretending that the mouse is still inside the desktop when it has left can lead to strange behaviors too. I think enabling clipping for these apps is a better solution. > With my touchpad the results are much more interesting. The cursor > moves slowly (around 1/3 of normal speed) but warps once per second to > where it really should be. When the cursor stops, the game starts > polling with GetCursorPos and the cursor warps again to the correct > position. The TRACE in GetCursorPos shows that "server pos" follows > the slower movement and is different from what the function returns. > > Maybe I should file a bug about that? Most likely because XInput raw events don't take acceleration into account. I'm not sure there's a whole lot we can do about that. -- Alexandre Julliard julliard(a)winehq.org

May 18, 2011

Re: [PATCH] winex11: Make GetCursorPos respect clipping and virtual screen size.

by Lauri Kenttä

On Wed, 18 May 2011 12:22:57 +0200, Alexandre Julliard wrote: > > The clip rectangle is only valid while the pointer is grabbed, in > which > case the cursor pos will be clipped already. That's true. I only tested the other case. > So for the case where the pointer is not grabbed (for instance if you > don't have XInput) it would have to go through the wineserver. So is it then possible to clip the cursor to the virtual desktop in the wineserver, or do you see some apparent problem there? I would be surprised if this was the only application to choke on strange mouse coordinates. > Have you tried the new desktop clipping mode? Sorry, I missed that because of missing XI2. That indeed fixes the clipping (but only when the window is active) and works fine with an external mouse. With my touchpad the results are much more interesting. The cursor moves slowly (around 1/3 of normal speed) but warps once per second to where it really should be. When the cursor stops, the game starts polling with GetCursorPos and the cursor warps again to the correct position. The TRACE in GetCursorPos shows that "server pos" follows the slower movement and is different from what the function returns. Maybe I should file a bug about that? -- Lauri Kenttä

May 18, 2011