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

Re: infosoft/tests: COM cleanup in infosoft.c.

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=11350 Your paranoid android. === WVISTAADM (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W2K8SE (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PRO (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PROX64 (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PROX64 (64 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed

May 31, 2011

Re: comctl32/tests: Using unsigned constants to remove sign comparison warning.

by Marko Nikolic

David Laight wrote: > On Fri, May 27, 2011 at 10:09:04PM +0400, Nikolay Sivov wrote: >> On Fri, May 27, 2011 at 5:16 PM, Marko Nikolic <grkoma(a)gmail.com> wrote: >> > --- >> > ?dlls/comctl32/tests/treeview.c | ? ?6 +++--- >> > ?1 files changed, 3 insertions(+), 3 deletions(-) >> > >> > diff --git a/dlls/comctl32/tests/treeview.c >> > b/dlls/comctl32/tests/treeview.c index 5fd26a0..b1eb85e 100644 >> > --- a/dlls/comctl32/tests/treeview.c >> > +++ b/dlls/comctl32/tests/treeview.c >> > @@ -634,7 +634,7 @@ static void test_get_set_bkcolor(void) >> > >> > ? ? /* If the value is -1, the control is using the system color for >> > the background color. */ ? ? crColor = (COLORREF)SendMessage( hTree, >> > TVM_GETBKCOLOR, 0, 0 ); - ? ?ok(crColor == -1, "Default background >> > color reported as 0x%.8x\n", crColor); + ? ?ok(crColor == 0xffffffff, >> > "Default background color reported as 0x%.8x\n", crColor); >> > >> >> ~0 looks better here imo. > > Rather ~0u > The 0xffffffff should be 0xffffffffu > > David > You are right, thanks, I'll update the patch. Marko

May 31, 2011

Re: Added unbound sampler test for pixel shaders.

by Stefan Dösinger

On Tuesday 31 May 2011 17:48:14 Sean Sube wrote: > + static const DWORD ps_code[] = > + { > + 0xFFFF0200, 0x0200001F, 0x90000000, 0xA00F0800, > + 0x0200001F, 0x80000000, 0xB00F0000, 0x03000042, > + 0x800F0000, 0xB0E40000, 0xA0E40000, 0x02000001, > + 0x800F0800, 0x80E40000, 0x0000FFFF, > + }; Please write the assembler code into comments, this makes the test easier to read. > + hr = IDirect3DDevice9_GetPixelShader(device, &old_ps); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_GetPixelShader failed, hr %#x.\n", hr); The individual tests should unset the pixel shader, if old_ps is not NULL here that's a bug. > + color = getPixelColorFromSurface(rt, 32, 32); > + ok(color == 0xFF000000, "Color is %#x.\n", color); My understanding is that the test currently fails, so you should mark it as todo: todo_wine ok(...); > + hr = IDirect3DDevice9_CreatePixelShader(device, ps_code, &ps); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_CreatePixelShader failed, hr %#x. \n", hr); Your test must check is PS 2.0 shaders are supported. We already have a pixel shader >= 2.0 supported block in the START_TEST(visual) function, please call your test function inside it. (e.g. after dp2add_ps_test)

May 31, 2011

Re: [2/3] kernel32/heap: Fix some hacks in GlobalMemoryStatus().

by Adam Martinson

On 05/31/2011 12:02 PM, Dmitry Timoshkov wrote: > Adam Martinson<amartinson(a)codeweavers.com> wrote: > >> +/* Check the current process and all ancestors. Some apps run sub-processes that >> + * have the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, but the parent process doesn't. >> + * (eg, Dragon NaturallySpeaking 7 setup runs Install Shield 6). >> + * If any don't have IMAGE_FILE_LARGE_ADDRESS_AWARE, return FALSE. */ > How do the processes running in separate address spaces have anything to do > with that? > Hmm, didn't consider that. Maybe this is only needed if the processes share one

May 31, 2011

Re: [1/3] kernel32/heap: Emulate Win9x if appropriate in GlobalMemoryStatusEx().

by Adam Martinson

On 05/31/2011 12:09 PM, Dmitry Timoshkov wrote: > Adam Martinson<amartinson(a)codeweavers.com> wrote: > >> + if (osver.dwMajorVersion>= 5) > That's a wrong check for win9x. > It's not, it's a check for win2k and later, the stuff in that block isn't done for win9x.

May 31, 2011

Re: [1/3] kernel32/heap: Emulate Win9x if appropriate in GlobalMemoryStatusEx().

by Dmitry Timoshkov

Adam Martinson <amartinson(a)codeweavers.com> wrote: > + if (osver.dwMajorVersion >= 5) That's a wrong check for win9x. -- Dmitry.

May 31, 2011

Re: [2/3] kernel32/heap: Fix some hacks in GlobalMemoryStatus().

by Dmitry Timoshkov

Adam Martinson <amartinson(a)codeweavers.com> wrote: > +/* Check the current process and all ancestors. Some apps run sub-processes that > + * have the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, but the parent process doesn't. > + * (eg, Dragon NaturallySpeaking 7 setup runs Install Shield 6). > + * If any don't have IMAGE_FILE_LARGE_ADDRESS_AWARE, return FALSE. */ How do the processes running in separate address spaces have anything to do with that? -- Dmitry.

May 31, 2011

Re: [4/5] ddraw: Extend the lifetime of the IDirect3D7::EnumDevices strings beyond function scope.

by Andrew Nguyen

On 05/31/2011 10:47 AM, Stefan Dösinger wrote: > Does the enum_device_entry structure have to be in ddraw_private.h? I > think you can just declare it in ddraw.c because it is used only there. No, I simply defined the structure there to be consistent with the role of the unused structure definitions I removed earlier. I can certainly move the definition to ddraw.c.

May 31, 2011

Re: [4/5] ddraw: Extend the lifetime of the IDirect3D7::EnumDevices strings beyond function scope.

by Stefan Dösinger

Does the enum_device_entry structure have to be in ddraw_private.h? I think you can just declare it in ddraw.c because it is used only there. At some point we'll want to get rid of the ddraw device type strings and call wined3d_get_adapter_identifier - but that needs more work and some more tests. Am 31.05.2011 um 12:50 schrieb Andrew Nguyen: > --- > dlls/ddraw/ddraw.c | 43 +++++++++++++------ > dlls/ddraw/ddraw_private.h | 8 ++++ > dlls/ddraw/tests/d3d.c | 98 ++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 136 insertions(+), 13 deletions(-) > > > <0004-ddraw-Extend-the-lifetime-of-the-EnumDevices-strings-b.txt>

May 31, 2011

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.05.2011 um 12:50 schrieb Alexandre Julliard: > I mean using D3DPOOL in wined3d, not by including the d3d9 headers, but > by defining it when necessary, i.e. if neither d3d8types.h nor > d3d9types.h have been included already. This would lead to a mixture of WINED3D* and D3D* types. But that could be addressed with a #define WINED3DPOOL D3DPOOL if D3DPOOL is available and declaring the num if D3DPOOL is not available. There are types like D3DRENDERSTATETYPE that aren't clear subsets/supersets. For example d3d8 has D3DRS_ZBIAS while d3d9 has D3DRS_DEPTHBIAS, and ZBIAS was removed. I guess that's something we should discuss with Henri once he is back. I don't like the idea just yet because we can't check if the d3d8, d3d9 and wined3d types are the same. With the switch statement without a default case we get a compiler warning if the wined3d type changes and the compiler optimizes the switch statement and no-op function away(At least the last time I checked). -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN5QCKAAoJEN0/YqbEcdMwELoQAIGzt1Pz8xDjTl0872+Eo4ul eTTopbvjUf1b44p0SSQBk8ypwP8FXn1K72wQxk0XcQBr5LOsX8T3i2gDKOwjfMtS YQ4OoEep0+LYdz69bsPydnFE3PNnT8Uhj8v4Di2udfnv5pXp16Ay9y45XfyzFbCY C5Zho8U4V43yWXpyiNF7o1wbSg82Bvkr9YsZJ9e2r1mTmHMKyJfdsjc5kUyDR9el u51Zad53xv99rLa8qmh6lXerbHeGXGTuBv5hMlv0eCWHQyrLvPh0aUvboke83UyE QbM9WME91WhcPlm1VEvA6grP+XZrb20Ib6XINSk804hMZNZlH3r20+kv/3owd2RN IqUxv5KgqR7st1GCOdhzeHo5CorR0JwmNIu68bOO+vJ5fS+b56MORNJ9AO/T+tKN e5pIoUdA2frwqj+/O/pZTpPTvLm+1GjR7/Zp7Dbc4hzqkxmqBRDFsyooBP9ijKzm 9odh6xTI+Al3rUaGxs4mpzAqnWEHGU6IkWPRHcJ3eNtAPRdrahjRCffLH3mT98W0 KsW8CreW2dUBwV/Qreio5jWoSApoEm/k2C/GzaNvhXWCzs0oKcLx7gO6T6uwGowD /76Me1KxRygrmntZprWN5iDEs6+PAsF3Cc6CI1MeNj3a3MYxRqLwj+yuGhjatOgu GuLlEila6eHSAAMoHMx0 =w8v0 -----END PGP SIGNATURE-----

May 31, 2011

Re: advapi: test and fix GetUserName() in case where buffer is too small

by Dan Kegel

I'm looking forward to Andrew's test-only patch... When I saw he had a test on testbot, I probably should have dropped mine.

May 31, 2011

Re: advapi: test and fix GetUserName() in case where buffer is too small

by Andrew Nguyen

On 05/31/2011 08:17 AM, Hans Leidekker wrote: > On Tue, 2011-05-31 at 06:32 -0500, Andrew Nguyen wrote: > >> - DWORD sizeW = *lpSize * 2; >> + DWORD sizeW = 0; >> + >> + GetUserNameW( NULL, &sizeW ); > > Can we avoid the extra call? I was trying to avoid making the assumption that a Unicode buffer with *lpSize Unicode characters would necessarily be appropriate for the second GetUserNameW call. Considering the failure path for the GetUserNameW call in the old version, I don't believe we know what the number of ANSI characters actually is unless we had WideCharToMultiByte figure it out. Thus, my intent was to never allow a failure due to insufficient buffer size so GetUserNameA knows the appropriate value for sizeA. That said, I suspect Windows does allocate the Unicode buffer based on the passed buffer size, so I think just going back to the old approach of unconditionally allocating *lpSize Unicode characters should be okay in practice. >> I didn't intend to scoop Dan's work, but I have a version of his fix, >> which is attached, with deeper tests which I wrote before Hans expressed >> his concerns. Should I just send in the tests with todo_wine and let Dan >> fix those, or should I send a revised version and allow a "winner" to be >> picked? > > I vote for getting some tests in first. > > I'll go ahead and extract the tests to a separate patch then.

May 31, 2011

Re: advapi: test and fix GetUserName() in case where buffer is too small

by Hans Leidekker

On Tue, 2011-05-31 at 06:32 -0500, Andrew Nguyen wrote: > - DWORD sizeW = *lpSize * 2; > + DWORD sizeW = 0; > + > + GetUserNameW( NULL, &sizeW ); Can we avoid the extra call? > I didn't intend to scoop Dan's work, but I have a version of his fix, > which is attached, with deeper tests which I wrote before Hans expressed > his concerns. Should I just send in the tests with todo_wine and let Dan > fix those, or should I send a revised version and allow a "winner" to be > picked? I vote for getting some tests in first.

May 31, 2011

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

by Michael Mc Donnell

On Tue, May 31, 2011 at 12:51 PM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > On Mon, May 30, 2011 at 10:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> 2011/5/30 Michael Mc Donnell <michael(a)mcdonnell.dk>: >>> Thanks for the comments Matteo! I have a few questions below. >>> >>> On Mon, May 30, 2011 at 2:45 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>>> 2011/5/29 Michael Mc Donnell <michael(a)mcdonnell.dk>: >>>>> On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger >>>>> <stefandoesinger(a)gmx.at> wrote: >>>>>> On Saturday 28 May 2011 19:55:55 you wrote: >>>>>> >>>>>>> It was implemented by setting the vertex declaration to null when the >>>>>>> declaration is invalid. That seems to match what happens on Windows, >>>>>>> because if a program has set an invalid declaration and then calls >>>>>>> GetDeclaration or DrawSubset it will fail with an access violation. >>>>>>> Should Wine also fail with an access violation or should it be >>>>>>> slightly more graceful and return E_FAIL instead (which my new patch >>>>>>> does)? >>>>>> Yes, I think returning E_FAIL is a good idea, but write a WARN if >>>>>> CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not >>>>>> be shown by default(unlike a FIXME), it is used when the app does something >>>>>> fishy but you think you handled it correctly. >>>>>> >>>>>>> + if (FAILED(hr)) >>>>>>> + new_vertex_declaration = NULL; >>>>>>> + >>>>>>> + /* Free old vertex declaration */ >>>>>>> + if (This->vertex_declaration) >>>>>>> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); >>>>>> In this situation you can just release the old decl before calling >>>>>> CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. >>>>>> That simplified the code a bit. Don't forget to set This->vertex_declaration to >>>>>> NULL in case of an error though >>>>> >>>>> Ok I've simplified the code. I've also inserted three WARNs. I've >>>>> skipped a WARN when freeing the mesh because that works fine on >>>>> Windows with an invalid declaration. >>>>> >>>>>>> + /* Set the position type to color instead of float3 (invalid >>>>>> declaration) */ >>>>>>> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >>>>>>> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >>>>>>> + "got %#x expected D3D_OK\n", hr); >>>>>> Is this really invalid? I don't know it on top of my head, but in general >>>>>> types and usage are independent, especially with shaders. I don't see a check >>>>>> in d3d9 or wined3d for this case. >>>>> >>>>> You're right it isn't invalid. It doesn't crash, it just doesn't draw >>>>> anything. I've change that comment and re-ordered the tests. >>>>> >>>>>> Beyond that I think the patches look OK. I'd recommend to send them to wine- >>>>>> devel one more time and then next week to wine-patches. Henri is on Vacation >>>>>> this week, and he's usually more picky than I am. I also hope some of the >>>>>> people who regularly contribute to d3dx9 will have a look and comment. >>>>> >>>>> Ok, I've attached the newest version. I'll let the patches sit here >>>>> for a week, and start working on the other functions in the mean time. >>>>> >>>> >>>> The patches are OK with me, just some nitpicking: >>> >>> That sounds great :-) >>> >>>> + testContext = HeapAlloc(GetProcessHeap(), 0, sizeof(struct TestContext)); >>>> >>>> We usually use something like HeapAlloc(GetProcessHeap(), 0, >>>> sizeof(*testContext)); instead. >>> >>> Ok, I guess that's better in case the type of the variable changes at >>> some point? >>> >> >> Yes, that's a reason. The other one is simply consistency. > > Ok, I've changed that. > >>>> I think you can remove some obvious comments (like /* Create the test >>>> mesh */). Also, check your whitespaces. >>> >>> Is it too much or too little whitespace? Could you give me an example? >> >> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics for bigger vertex size, " >> >> + "got %#x expected D3D_OK\n", hr); >> >> Here you put 4 spaces on the line continuation, which is neither the >> "align to be below the '(' + 1 space" used in most of the file, nor >> the 8 spaces used in wined3d. The d3dx9_36 sources aren't known for a >> nice and consistent coding style (I'm sure you noticed that), so >> that's mostly trying to not mix even more style variants... > > Ok I've changed it to the "align to be below the '(' + 1 space" convention. > >> There was also something wrong with spaces in a comment that caught my >> eye, I think. > > The only thing that stood out to me was that I had extra newlines in > my multi-line comments. I've removed those. > >> I told you I was nitpicking... :) > > That's ok, I prefer consistency too :-) Oops the patches I sent earlier had a tab character and some superfluous whitespace.

May 31, 2011

RFC: d3d9: Increment the reference count of the IDirect3D9 instance when creating a device.

by Andrew Nguyen

The Pathologic demo in bug 21552 expects that the reference count of a IDirect3D9 instance is incremented after a successful call to CreateDevice with the instance. Does my proposed fix for d3d8 and d3d9 manage the reference count of the device parent appropriately? In particular, I'm concerned about the slightly cumbersome acquisition of the pointer to the parent instance within the Release call for the Direct3D device interface. Is the overall location of the AddRef/Release calls correct, and should I be doing something differently when the device tries to decrement the parent reference count?

May 31, 2011

Re: advapi: test and fix GetUserName() in case where buffer is too small

by Andrew Nguyen

On 05/31/2011 02:17 AM, Hans Leidekker wrote: > On Mon, 2011-05-30 at 21:13 -0700, Dan Kegel wrote: > >> @@ -91,7 +91,7 @@ GetUserNameW( LPWSTR lpszName, LPDWORD lpSize ) >> >> if (len > *lpSize) >> { >> - SetLastError(ERROR_MORE_DATA); >> + SetLastError(ERROR_INSUFFICIENT_BUFFER); > > GetUserNameA also needs to be fixed. It sets ERROR_MORE_DATA when > WideCharToMultiByte fails, which can simply be removed because that > function will set ERROR_INSUFFICIENT_BUFFER itself if the buffer is too > small. > > And there are at least two cases, in dlls/crypt32/protectdata.c and > dlls/msi/package.c, where we depend on the wrong error. > > > > I didn't intend to scoop Dan's work, but I have a version of his fix, which is attached, with deeper tests which I wrote before Hans expressed his concerns. Should I just send in the tests with todo_wine and let Dan fix those, or should I send a revised version and allow a "winner" to be picked?

May 31, 2011

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

by Michael Mc Donnell

On Mon, May 30, 2011 at 10:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/5/30 Michael Mc Donnell <michael(a)mcdonnell.dk>: >> Thanks for the comments Matteo! I have a few questions below. >> >> On Mon, May 30, 2011 at 2:45 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>> 2011/5/29 Michael Mc Donnell <michael(a)mcdonnell.dk>: >>>> On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger >>>> <stefandoesinger(a)gmx.at> wrote: >>>>> On Saturday 28 May 2011 19:55:55 you wrote: >>>>> >>>>>> It was implemented by setting the vertex declaration to null when the >>>>>> declaration is invalid. That seems to match what happens on Windows, >>>>>> because if a program has set an invalid declaration and then calls >>>>>> GetDeclaration or DrawSubset it will fail with an access violation. >>>>>> Should Wine also fail with an access violation or should it be >>>>>> slightly more graceful and return E_FAIL instead (which my new patch >>>>>> does)? >>>>> Yes, I think returning E_FAIL is a good idea, but write a WARN if >>>>> CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not >>>>> be shown by default(unlike a FIXME), it is used when the app does something >>>>> fishy but you think you handled it correctly. >>>>> >>>>>> + if (FAILED(hr)) >>>>>> + new_vertex_declaration = NULL; >>>>>> + >>>>>> + /* Free old vertex declaration */ >>>>>> + if (This->vertex_declaration) >>>>>> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); >>>>> In this situation you can just release the old decl before calling >>>>> CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. >>>>> That simplified the code a bit. Don't forget to set This->vertex_declaration to >>>>> NULL in case of an error though >>>> >>>> Ok I've simplified the code. I've also inserted three WARNs. I've >>>> skipped a WARN when freeing the mesh because that works fine on >>>> Windows with an invalid declaration. >>>> >>>>>> + /* Set the position type to color instead of float3 (invalid >>>>> declaration) */ >>>>>> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >>>>>> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >>>>>> + "got %#x expected D3D_OK\n", hr); >>>>> Is this really invalid? I don't know it on top of my head, but in general >>>>> types and usage are independent, especially with shaders. I don't see a check >>>>> in d3d9 or wined3d for this case. >>>> >>>> You're right it isn't invalid. It doesn't crash, it just doesn't draw >>>> anything. I've change that comment and re-ordered the tests. >>>> >>>>> Beyond that I think the patches look OK. I'd recommend to send them to wine- >>>>> devel one more time and then next week to wine-patches. Henri is on Vacation >>>>> this week, and he's usually more picky than I am. I also hope some of the >>>>> people who regularly contribute to d3dx9 will have a look and comment. >>>> >>>> Ok, I've attached the newest version. I'll let the patches sit here >>>> for a week, and start working on the other functions in the mean time. >>>> >>> >>> The patches are OK with me, just some nitpicking: >> >> That sounds great :-) >> >>> + testContext = HeapAlloc(GetProcessHeap(), 0, sizeof(struct TestContext)); >>> >>> We usually use something like HeapAlloc(GetProcessHeap(), 0, >>> sizeof(*testContext)); instead. >> >> Ok, I guess that's better in case the type of the variable changes at >> some point? >> > > Yes, that's a reason. The other one is simply consistency. Ok, I've changed that. >>> I think you can remove some obvious comments (like /* Create the test >>> mesh */). Also, check your whitespaces. >> >> Is it too much or too little whitespace? Could you give me an example? > > + todo_wine ok(hr == D3D_OK, "Test UpdateSematics for bigger vertex size, " > > + "got %#x expected D3D_OK\n", hr); > > Here you put 4 spaces on the line continuation, which is neither the > "align to be below the '(' + 1 space" used in most of the file, nor > the 8 spaces used in wined3d. The d3dx9_36 sources aren't known for a > nice and consistent coding style (I'm sure you noticed that), so > that's mostly trying to not mix even more style variants... Ok I've changed it to the "align to be below the '(' + 1 space" convention. > There was also something wrong with spaces in a comment that caught my > eye, I think. The only thing that stood out to me was that I had extra newlines in my multi-line comments. I've removed those. > I told you I was nitpicking... :) That's ok, I prefer consistency too :-)

May 31, 2011

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)

by Alexandre Julliard

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > Am 31.05.2011 um 12:12 schrieb Alexandre Julliard: >> Most enums are identical, or just have an extra value or two. I don't >> see why you can't pass either type to wined3d since they have the same >> name. > Do you mean the status quo? Or do you mean using the D3DPOOL type in > wined3d by including the d3d9 headers(this works in wined3d.dll > itself)? I mean using D3DPOOL in wined3d, not by including the d3d9 headers, but by defining it when necessary, i.e. if neither d3d8types.h nor d3d9types.h have been included already. This way d3d8 uses the d3d8 definition, d3d9 uses the d3d9 definition, and ddraw/d3d10/wined3d internals use the wined3d definition which is probably a superset of the others. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2011

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.05.2011 um 12:12 schrieb Alexandre Julliard: > Most enums are identical, or just have an extra value or two. I don't > see why you can't pass either type to wined3d since they have the same > name. Do you mean the status quo? Or do you mean using the D3DPOOL type in wined3d by including the d3d9 headers(this works in wined3d.dll itself)? The problem here's ddraw(and d3d10/11), the functionally equivalent types work differently there, they are a set of flags in DDSURFACEDESC2. Yet we can't include d3d8types.h or d3d9types.h in ddraw because there are a handful of types that cause name conflicts. We used to do that a long time ago, but there are only a handful of types that exist in all 3 d3d versions and can be reused. In d3d10 the fixed function pipeline is gone, and so are the types related to it, but they are still needed for the wined3d interface definition. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN5MOyAAoJEN0/YqbEcdMwmFkP/AtNv+3BKIuaY08uDmrpcSI0 qvudinT7Yw6bA0B7TKRIbmgfGVFHc+u+GGfl6bk035LXDL0DBmeo2eYRsS3V3pSq 8lDd/T2g1MDCCFjUx9qoQJeHNGb9qN5gU+ztQeFLynsxvdvCmHNT+ztPejLUSLfe mDIKFZns1/Y6YtyqEbpmCTLjy/WadTeLCj0PfhNERCIujyyDxxdudcqiM2uTCmwe 01wSjISTXcwl3vUdevYOZ2phHHOkPrAQ5mhz0Y1vyTqqg/1sySuKfK4EyZvAiguC 9CSH4nDoiU8OriXFvfCQxHwKJ3dxVfP+EOh3BOXbaB/Nc90+5zKzQYPJzzLEp7uT bX0WkKJHr8R/thlQ/q3zYU2QvTjSVfk+eqdjnKZw5jziWdeM66SdBLeahsubyqOv poIepool5HqPt2oqFvzTyrvJzX730isSu1cy2vU8DmxLGh9H8zrExbPm3Mj16jcO lwapsIxHOagwhVvO1w8TzXGS5KuuRC6TQMaujEVJihdidf0F478YuSw2dpQynOra jaxHwjU+Hy9Tf0HWLr9VefV/mTvUDLe3e07c1QxcU6ImEwQx8QHgViN2nbgCshco WfJefQTTFHg73cN4F9gkXjfIM1Yl3SNcz387spL2GXb3OB3fvAZeinzs9rlUi3b/ sUBcqL50lIuwUgUKOzrg =6HyE -----END PGP SIGNATURE-----

May 31, 2011

Re: [PATCH 1/6] mshtml: Added support for accessing document elements by index

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=11331 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

May 31, 2011

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)

by Alexandre Julliard

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > Am 31.05.2011 um 11:10 schrieb Alexandre Julliard: >> I still don't see the point of that kind of switch statement. To be >> honest I don't see either why we even need different enum types in the >> first place. > Because for most enums the d3d8 ones differ from the d3d9 ones but > have the same name. We cannot include d3d9types.h in d3d8 and ddraw > but we still have to talk to wined3d. Most enums are identical, or just have an extra value or two. I don't see why you can't pass either type to wined3d since they have the same name. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2011

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.05.2011 um 11:10 schrieb Alexandre Julliard: > I still don't see the point of that kind of switch statement. To be > honest I don't see either why we even need different enum types in the > first place. Because for most enums the d3d8 ones differ from the d3d9 ones but have the same name. We cannot include d3d9types.h in d3d8 and ddraw but we still have to talk to wined3d. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN5LsaAAoJEN0/YqbEcdMwMBYQAJfhdtFoBi3dq0nDvK5PwdN3 V5elaAUp3KTwugfmhy9TL1VhPY9QyOQ0x0/dXbd9dqH1cNn54IvU8rl0tcRqlW5B pmeD2fh+eywSGaw2UBhQJjQTHOcRwXo8CJTb/6Z5D10Gt0YNcUAyaQOgQkThiIbI ttItwkM6N9HF+lmWSQ66ue6jNe+8lf0b9pC+r5I8HLi/fUL0L4PglgKTBP/rs8kq YgQmiSRuJ+tP4bzlr8XyuoZEynnL2QJG/60q3M6qC9iA+BR1tHHJsAXQflErICZr v/MrQwbiBjAASXMdmRqxAF9hyA6Qv9cRKbOtEIeI8GPoOg2/V3QbNRiI2GcLMz6s O8zPUxzwbGfuJDQKh04cAsMAIw32JNh1IAPz+GcS9oXzVvCuH+PlfQiLGz+Lxukf jwup8N/3UojvVHU6C8PUDgYV6+eOm0Pbr9j2BUVIj+nliycQlsnrj6P/zthI+r9m tgh152AV8RN52zBZTQlf258KqV1Thw8LnCAkA+a4mG1Bz6gGh4u/o9UDFY8rbENi tSEugEl0w6OecHJBOHTpOPenHHyE3KKCwNZ3bsC/TE4AnuXUMGLoPw88dWCfnrS9 gtvX2pyIpdbjuktAaAPoM15QNZvV16+hmstGXNsrEPgi/p+U6JHw5GvAPtgccPDD iBVo1M4T31Jph8Q3VcGj =snIO -----END PGP SIGNATURE-----

May 31, 2011

Re: kernel32: Call Fls callback (try 2)

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > + if (ret && callback) callback(NtCurrentTeb()->FlsSlots[index]); > + /* FIXME: add equivalent of ThreadZeroTlsCell here */ > + if (NtCurrentTeb()->FlsSlots) NtCurrentTeb()->FlsSlots[index] = 0; It's not that easy... -- Alexandre Julliard julliard(a)winehq.org

May 31, 2011

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)

by Alexandre Julliard

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > +static inline D3DPOOL d3dpool_from_wined3dpool(WINED3DPOOL type) > +{ > + switch (type) > + { > + case WINED3DPOOL_DEFAULT: return D3DPOOL_DEFAULT; > + case WINED3DPOOL_MANAGED: return D3DPOOL_MANAGED; > + case WINED3DPOOL_SYSTEMMEM: return D3DPOOL_SYSTEMMEM; > + case WINED3DPOOL_SCRATCH: return D3DPOOL_SCRATCH; > + case WINED3DPOOL_FORCE_DWORD: return D3DPOOL_FORCE_DWORD; > + } > + return (D3DPOOL) type; > +} > + > +static inline WINED3DPOOL wined3dpool_from_d3dpool(D3DPOOL type) > +{ > + switch (type) > + { > + case D3DPOOL_DEFAULT: return WINED3DPOOL_DEFAULT; > + case D3DPOOL_MANAGED: return WINED3DPOOL_MANAGED; > + case D3DPOOL_SYSTEMMEM: return WINED3DPOOL_SYSTEMMEM; > + case D3DPOOL_SCRATCH: return WINED3DPOOL_SCRATCH; > + case D3DPOOL_FORCE_DWORD: return WINED3DPOOL_FORCE_DWORD; > + } > + return (WINED3DPOOL) type; > +} I still don't see the point of that kind of switch statement. To be honest I don't see either why we even need different enum types in the first place. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2011

Re: advapi: test and fix GetUserName() in case where buffer is too small

by Hans Leidekker

On Mon, 2011-05-30 at 21:13 -0700, Dan Kegel wrote: > @@ -91,7 +91,7 @@ GetUserNameW( LPWSTR lpszName, LPDWORD lpSize ) > > if (len > *lpSize) > { > - SetLastError(ERROR_MORE_DATA); > + SetLastError(ERROR_INSUFFICIENT_BUFFER); GetUserNameA also needs to be fixed. It sets ERROR_MORE_DATA when WideCharToMultiByte fails, which can simply be removed because that function will set ERROR_INSUFFICIENT_BUFFER itself if the buffer is too small. And there are at least two cases, in dlls/crypt32/protectdata.c and dlls/msi/package.c, where we depend on the wrong error.

May 31, 2011

Re: bug in GetUserNameW error return values

by James McKenzie

On 5/30/11 11:52 AM, Kevin Hendricks wrote: > Hi, > > There is a small bug in the wine implementation of GetUserNameW (and the same fix is needed in GetUserNameA). > > From: > dlls/advapi32/advapi.c starting at line 92 > > > if (len> *lpSize) > { > SetLastError(ERROR_MORE_DATA); > *lpSize = len; > return FALSE; > } > > > It seems the actual GetUserNameW returns 122 not 234 which maps to ERROR_INSUFFICIENT_BUFFER and not ERROR_MORE_DATA > File a bug report with all of these details. Developers do not work bugs from the mailing list. James McKenzie

May 30, 2011

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

by Matteo Bruni

2011/5/30 Michael Mc Donnell <michael(a)mcdonnell.dk>: > Thanks for the comments Matteo! I have a few questions below. > > On Mon, May 30, 2011 at 2:45 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> 2011/5/29 Michael Mc Donnell <michael(a)mcdonnell.dk>: >>> On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger >>> <stefandoesinger(a)gmx.at> wrote: >>>> On Saturday 28 May 2011 19:55:55 you wrote: >>>> >>>>> It was implemented by setting the vertex declaration to null when the >>>>> declaration is invalid. That seems to match what happens on Windows, >>>>> because if a program has set an invalid declaration and then calls >>>>> GetDeclaration or DrawSubset it will fail with an access violation. >>>>> Should Wine also fail with an access violation or should it be >>>>> slightly more graceful and return E_FAIL instead (which my new patch >>>>> does)? >>>> Yes, I think returning E_FAIL is a good idea, but write a WARN if >>>> CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not >>>> be shown by default(unlike a FIXME), it is used when the app does something >>>> fishy but you think you handled it correctly. >>>> >>>>> + if (FAILED(hr)) >>>>> + new_vertex_declaration = NULL; >>>>> + >>>>> + /* Free old vertex declaration */ >>>>> + if (This->vertex_declaration) >>>>> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); >>>> In this situation you can just release the old decl before calling >>>> CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. >>>> That simplified the code a bit. Don't forget to set This->vertex_declaration to >>>> NULL in case of an error though >>> >>> Ok I've simplified the code. I've also inserted three WARNs. I've >>> skipped a WARN when freeing the mesh because that works fine on >>> Windows with an invalid declaration. >>> >>>>> + /* Set the position type to color instead of float3 (invalid >>>> declaration) */ >>>>> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >>>>> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >>>>> + "got %#x expected D3D_OK\n", hr); >>>> Is this really invalid? I don't know it on top of my head, but in general >>>> types and usage are independent, especially with shaders. I don't see a check >>>> in d3d9 or wined3d for this case. >>> >>> You're right it isn't invalid. It doesn't crash, it just doesn't draw >>> anything. I've change that comment and re-ordered the tests. >>> >>>> Beyond that I think the patches look OK. I'd recommend to send them to wine- >>>> devel one more time and then next week to wine-patches. Henri is on Vacation >>>> this week, and he's usually more picky than I am. I also hope some of the >>>> people who regularly contribute to d3dx9 will have a look and comment. >>> >>> Ok, I've attached the newest version. I'll let the patches sit here >>> for a week, and start working on the other functions in the mean time. >>> >> >> The patches are OK with me, just some nitpicking: > > That sounds great :-) > >> + testContext = HeapAlloc(GetProcessHeap(), 0, sizeof(struct TestContext)); >> >> We usually use something like HeapAlloc(GetProcessHeap(), 0, >> sizeof(*testContext)); instead. > > Ok, I guess that's better in case the type of the variable changes at > some point? > Yes, that's a reason. The other one is simply consistency. >> I think you can remove some obvious comments (like /* Create the test >> mesh */). Also, check your whitespaces. > > Is it too much or too little whitespace? Could you give me an example? + todo_wine ok(hr == D3D_OK, "Test UpdateSematics for bigger vertex size, " + "got %#x expected D3D_OK\n", hr); Here you put 4 spaces on the line continuation, which is neither the "align to be below the '(' + 1 space" used in most of the file, nor the 8 spaces used in wined3d. The d3dx9_36 sources aren't known for a nice and consistent coding style (I'm sure you noticed that), so that's mostly trying to not mix even more style variants... There was also something wrong with spaces in a comment that caught my eye, I think. I told you I was nitpicking... :) > > Thanks! >

May 30, 2011

Re: [1/2] README: Update Linux requirements

by Wolfram Sang

> I also thought about moving 2.4.x in one context with 2.2.x, but at > least no one else did so i didn't. Please do. Despite the question if it is "good enough", 2.4 is for sure not considered "current" anymore.

May 30, 2011

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

by Michael Mc Donnell

Thanks for the comments Matteo! I have a few questions below. On Mon, May 30, 2011 at 2:45 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/5/29 Michael Mc Donnell <michael(a)mcdonnell.dk>: >> On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger >> <stefandoesinger(a)gmx.at> wrote: >>> On Saturday 28 May 2011 19:55:55 you wrote: >>> >>>> It was implemented by setting the vertex declaration to null when the >>>> declaration is invalid. That seems to match what happens on Windows, >>>> because if a program has set an invalid declaration and then calls >>>> GetDeclaration or DrawSubset it will fail with an access violation. >>>> Should Wine also fail with an access violation or should it be >>>> slightly more graceful and return E_FAIL instead (which my new patch >>>> does)? >>> Yes, I think returning E_FAIL is a good idea, but write a WARN if >>> CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not >>> be shown by default(unlike a FIXME), it is used when the app does something >>> fishy but you think you handled it correctly. >>> >>>> + if (FAILED(hr)) >>>> + new_vertex_declaration = NULL; >>>> + >>>> + /* Free old vertex declaration */ >>>> + if (This->vertex_declaration) >>>> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); >>> In this situation you can just release the old decl before calling >>> CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. >>> That simplified the code a bit. Don't forget to set This->vertex_declaration to >>> NULL in case of an error though >> >> Ok I've simplified the code. I've also inserted three WARNs. I've >> skipped a WARN when freeing the mesh because that works fine on >> Windows with an invalid declaration. >> >>>> + /* Set the position type to color instead of float3 (invalid >>> declaration) */ >>>> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >>>> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >>>> + "got %#x expected D3D_OK\n", hr); >>> Is this really invalid? I don't know it on top of my head, but in general >>> types and usage are independent, especially with shaders. I don't see a check >>> in d3d9 or wined3d for this case. >> >> You're right it isn't invalid. It doesn't crash, it just doesn't draw >> anything. I've change that comment and re-ordered the tests. >> >>> Beyond that I think the patches look OK. I'd recommend to send them to wine- >>> devel one more time and then next week to wine-patches. Henri is on Vacation >>> this week, and he's usually more picky than I am. I also hope some of the >>> people who regularly contribute to d3dx9 will have a look and comment. >> >> Ok, I've attached the newest version. I'll let the patches sit here >> for a week, and start working on the other functions in the mean time. >> > > The patches are OK with me, just some nitpicking: That sounds great :-) > + testContext = HeapAlloc(GetProcessHeap(), 0, sizeof(struct TestContext)); > > We usually use something like HeapAlloc(GetProcessHeap(), 0, > sizeof(*testContext)); instead. Ok, I guess that's better in case the type of the variable changes at some point? > I think you can remove some obvious comments (like /* Create the test > mesh */). Also, check your whitespaces. Is it too much or too little whitespace? Could you give me an example? Thanks!

May 30, 2011

Re: [1/2] README: Update Linux requirements

by André Hentschel

Am 30.05.2011 20:51, schrieb Michael Stefaniuc: > Hello André, > > On 05/30/2011 08:09 PM, André Hentschel wrote: >> now that it's official >> --- >> README | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/README b/README >> index baa6ab3..51a080b 100644 >> --- a/README >> +++ b/README >> @@ -41,7 +41,7 @@ support kernel threads may be supported in the future. >> Linux info: >> While Linux 2.2.x should still work and Linux 2.0.x may still work >> (older 2.0.x versions had thread-related crashes), >> - it's best to have a current kernel such as 2.4.x or 2.6.x. >> + it's best to have a current kernel such as 2.4.x, 2.6.x or 3.0. > Are you sure that a 2.4 Kernel is still good enough for modern Wine? > And for the new Linux numbering: it is 3.x not 3.0 as the main change is > to have only two digits for the Linux version as released by Linus; the > third is reserved for the stable trees. > > bye > michael Hi Michael, I also thought about moving 2.4.x in one context with 2.2.x, but at least no one else did so i didn't. And yes, i intended to write 3.x -- Best Regards, André Hentschel

May 30, 2011

bug in GetUserNameW error return values

by Kevin Hendricks

Hi, There is a small bug in the wine implementation of GetUserNameW (and the same fix is needed in GetUserNameA). From: dlls/advapi32/advapi.c starting at line 92 if (len > *lpSize) { SetLastError(ERROR_MORE_DATA); *lpSize = len; return FALSE; } It seems the actual GetUserNameW returns 122 not 234 which maps to ERROR_INSUFFICIENT_BUFFER and not ERROR_MORE_DATA This bug prevents the username from being properly read in all version of of Kindle for PC when run under wine. The code in question luckily ignores the improper error return value and simply replaces the username with the string "AlternateUserName" so Kindle For PC will actually work under wine but this actually changes how the DRM is created on the ebook as the Kindle DRM is tied to both the user name and the volume serial number, making it hard to post-process any ebook under wine. Please fix this in your next release. Thanks, Kevin

May 30, 2011

Re: [1/2] README: Update Linux requirements

by Michael Stefaniuc

Hello André, On 05/30/2011 08:09 PM, André Hentschel wrote: > now that it's official > --- > README | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/README b/README > index baa6ab3..51a080b 100644 > --- a/README > +++ b/README > @@ -41,7 +41,7 @@ support kernel threads may be supported in the future. > Linux info: > While Linux 2.2.x should still work and Linux 2.0.x may still work > (older 2.0.x versions had thread-related crashes), > - it's best to have a current kernel such as 2.4.x or 2.6.x. > + it's best to have a current kernel such as 2.4.x, 2.6.x or 3.0. Are you sure that a 2.4 Kernel is still good enough for modern Wine? And for the new Linux numbering: it is 3.x not 3.0 as the main change is to have only two digits for the Linux version as released by Linus; the third is reserved for the stable trees. bye michael

May 30, 2011

Re: GSoC: dinput8 Action Mapping

by Vitaliy Margolen

On 05/29/2011 04:18 PM, Lucas Zawacki wrote: > I'm sending a series of patches so everyone can take a > look before I try commiting them. Please note that these contain a > partial implementation of EnumDevicesBySemantics, BuildActionMap and > SetActionMap, and also they're only the A versions. In general you heading the right direction. In practice these patches can't go in as is for number of reasons: - Too many white space changes. Yes, I know dinput looks terrible, thanks to whomever wrote it 10+ years ago. But current Wine policies do not allow white space only changes. You can fix few lines around area you modifying but not throughout the entire file - If you modifying line please change tabs to spaces - I've been working for years to get codding style of dinput to one standard - curly braces on their own line. No curlies when you don't need them. Please don't break it. - You have to implement both A & W versions of your functions, or things will break. > - FIXME("(this=%p,%s,%p,%p,%p,%04x): stub\n", This, ptszUserName, lpdiActionFormat, > + TRACE("(this=%p,%s,%p,%p,%p,%04x): stub\n", This, ptszUserName, lpdiActionFormat, Don't change fixme to trace without actually implementing stuff. If it's partially implemented - change the message to say "semi-stub". > + if ((r = dinput_devices[i]->enum_deviceA(DI8DEVCLASS_ALL, dwFlags, &devinst, This->dwVersion, j))) { > + /* note that we have to create the device and set it's data format */ > + if ( GET_DIDEVICE_TYPE(devinst.dwDevType) == DI8DEVTYPE_KEYBOARD ) { If you looking for keyboard then you should ask for keyboard devices only instead of DI8DEVCLASS_ALL. Also note that according to MSDN ans some of my tests, keyboard and mouse was always enumerated, regardless of action format. > + IDirectInputDevice_SetDataFormat(lpdidev,&c_dfDIKeyboard); This should be done in IDirectInputDevice8AImpl_SetActionMap not EnumDevicesBySemantics. > ok(SUCCEEDED(hr), "EnumDevicesBySemantics failed: hr=%08x\n",hr); > - todo_wine ok (ndevices > 0, "EnumDevicesBySemantics did not call the callback. hr=%08x ndevices=%d\n", hr, ndevices); > + ok(ndevices > 0, "EnumDevicesBySemantics did not call the callback. hr=%08x ndevices=%d\n", hr, ndevices); I'm not seeing any changes in the dinput code. How did this test got fixed? You sure it wasn't broken because of incorrect function call? Then it would have failed on Windows. > + /* set the buffer */ > + if (lpdiActionFormat->dwBufferSize > 0) { > + IDirectInputDevice_Unacquire(lpdidev); > + dipdw.diph.dwSize = sizeof(DIPROPDWORD); > + dipdw.dwData = lpdiActionFormat->dwBufferSize; > + IDirectInputDevice_SetProperty(lpdidev,DIPROP_BUFFERSIZE,&dipdw.diph); > + } This is wrong. You do not need to un-acquire device - it was just created. You must specify diph.dwHow = DIPH_DEVICE and diph.dwHeaderSize = sizeof(DIPROPHEADER) or this call fail. And this again needs to go into SetActionMap. > + /* each app data is indexed by the device ObjID */ > + DWORD actionmap[MAX_DEVICE_OBJECTS]; Wrong data type. Should be UINT_PTR not DWORD. > I'm not too sure of how to code the tests that require user input... You can inject input events with SendInput or keybd_event/mouse_event. This of course only applies to keyboard and mouse. Joysticks will have to be tested manually. Please combine patches that implement something with tests for it. Also don't forget to run your tests on Windows. Or at least on Wine with native dinput.dll & dinput8.dll. Vitaliy

May 30, 2011

RE: Tahoma Font License

by Mark Page

---------------------------------------- > Date: Wed, 25 May 2011 16:39:04 -0700 > From: scott(a)open-vote.org > To: wine-devel(a)winehq.org > Subject: Re: Tahoma Font License > > On 05/25/2011 09:27 AM, Maarten Lankhorst wrote: > > Hi mark, > > > > 2011/5/25 Mark Page : > >> > >> I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... GNU Lesser General Public License 2.1 > >> > >> It would be useful to add the font to the ClanLib SDK resources (ClanLib has a zlib style license) > >> > >> It is not clear how a font can be licensed using LGPL, since LGPL is based around software libraries. > >> > >> Ideally I feel it should have a creative commons license > >> > >> I believe Creative commons did not exist when that font was created > > tahoma.sfd: Copyright: Copyright (c) 2004 Larry Snyder, Based on > > Bitstream Vera Sans Copyright (c) 2003 by Bitstream, Inc. Font renamed > > in accordance with former's license. Please do not contact Bitstream > > Inc. for any reason regarding this font. > > > > So just look up the original without contacting bitstream inc. ? > > > > The topic of relicensing wine fonts has come up before. Usually the > discussion ends with "our fonts aren't as good as you think, and you > probably don't want them so don't worry about licensing." > > I'm not so sure it's true anymore. Symbol replacement, for instance, > can actually be useful to show special characters on web pages that > would otherwise come up as question marks. > > -Scott Ritchie > > For reference, I have emailed Larry, via an email address I found searching archive wine developer lists ( wierd_w at y***o.com ) I sent the email last week. Hopefully, he still is using that address. I will post a message if he does allow a change of license. Mark.

May 30, 2011

Re: GSoC: dinput8 Action Mapping

by Marcus Meissner

On Sun, May 29, 2011 at 07:18:03PM -0300, Lucas Zawacki wrote: > Hey guys. So last week I finally got a good understanding of dinput as > a whole and nailed some trivial cases of action mapping, the ones with > the keyboard. I'm sending a series of patches so everyone can take a > look before I try commiting them. Please note that these contain a > partial implementation of EnumDevicesBySemantics, BuildActionMap and > SetActionMap, and also they're only the A versions. There are some > tests for EnumDevicesBySemantics. I'm not too sure of how to code the > tests that require user input... > > I hope it's not a nuisance to read the code split in 7 files, if you > guys want I can merge it in one big diff. Its ok. In general changes should be in small patches, and should ensure for every patch in the sequence (in sequence): - wine builds - make test still runs I looked over your patches and as much as I can make out, they look fine :) Ciao, Marcus > On a bright note, this patchset results in the input working for these > two games: > > * http://appdb.winehq.org/objectManager.php?sClass=application&iId=3678 > * http://appdb.winehq.org/objectManager.php?sClass=application&iId=7919 > > Cheers :) > From 551a2f3bea643add493d50a5580f7c2a3c2f7566 Mon Sep 17 00:00:00 2001 > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > Date: Sat, 28 May 2011 14:56:28 -0300 > Subject: dinput8/tests: Organized it a little and added a test for the EnumDevicesBySemantics callback. > > --- > dlls/dinput8/tests/device.c | 37 +++++++++++++++++++++++++------------ > 1 files changed, 25 insertions(+), 12 deletions(-) > > diff --git a/dlls/dinput8/tests/device.c b/dlls/dinput8/tests/device.c > index c18a83a..eca22a9 100644 > --- a/dlls/dinput8/tests/device.c > +++ b/dlls/dinput8/tests/device.c > @@ -27,6 +27,23 @@ > #include "initguid.h" > #include "dinput.h" > > +/* Dummy GUID */ > +static const GUID ACTION_MAPPING_GUID = { 0x1, 0x2, 0x3, { 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb } }; > + > +static DIACTION actionMapping[]= > +{ > + /* axis */ > + { 0, 0x01008A01 /* DIAXIS_DRIVINGR_STEER */ , 0, { "Steer" } }, > + /* button */ > + { 1, 0x01000C01 /* DIBUTTON_DRIVINGR_SHIFTUP */ , 0, { "Upshift" } }, > + /* keyboard mapping */ > + { 2, DIKEYBOARD_SPACE , 0, { "Missiles" } } > +}; > + > + > +/* This will set the number of devices, incrementing it > + each time a new one is enumerated > +*/ > static BOOL CALLBACK enum_by_semantics( > LPCDIDEVICEINSTANCE lpddi, > LPDIRECTINPUTDEVICE8 lpdid, > @@ -34,6 +51,10 @@ static BOOL CALLBACK enum_by_semantics( > DWORD dwRemaining, > LPVOID pvRef) > { > + > + int *ndevices = pvRef; > + if (ndevices != NULL) *ndevices += 1; > + > return DIENUM_CONTINUE; > } > > @@ -44,17 +65,7 @@ static void test_action_mapping(void) > HINSTANCE hinst = GetModuleHandle(NULL); > LPDIRECTINPUT8 pDI = NULL; > DIACTIONFORMAT af; > - /* Dummy GUID */ > - const GUID ACTION_MAPPING_GUID = { 0x1, 0x2, 0x3, { 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb } }; > - > - DIACTION actionMapping[]= > - { > - /* axis */ > - { 0, 0x01008A01 /* DIAXIS_DRIVINGR_STEER */ , 0, { "Steer" } }, > - > - /* button */ > - { 1, 0x01000C01 /* DIBUTTON_DRIVINGR_SHIFTUP */ , 0, { "Upshift" } } > - }; > + int ndevices = 0; > > hr = CoCreateInstance(&CLSID_DirectInput8, 0, 1, &IID_IDirectInput8A, (LPVOID*)&pDI); > if (hr == DIERR_OLDDIRECTINPUTVERSION || > @@ -86,9 +97,10 @@ static void test_action_mapping(void) > af.dwGenre = 0x01000000; /* DIVIRTUAL_DRIVING_RACE */ > > hr = IDirectInput8_EnumDevicesBySemantics(pDI,0, &af, > - enum_by_semantics, 0, 0); > + enum_by_semantics, &ndevices, 0); > > ok(SUCCEEDED(hr), "EnumDevicesBySemantics failed: hr=%08x\n",hr); > + todo_wine ok (ndevices > 0, "EnumDevicesBySemantics did not call the callback. hr=%08x ndevices=%d\n", hr, ndevices); > > /* The call fails with a zeroed GUID */ > memset(&af.guidActionMap, 0, sizeof(GUID)); > @@ -107,3 +119,4 @@ START_TEST(device) > > CoUninitialize(); > } > + > -- > 1.7.0.4 > > From 1829925b178b3c2eb45fe4ea1956a226e6f91628 Mon Sep 17 00:00:00 2001 > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > Date: Sun, 29 May 2011 16:49:45 -0300 > Subject: dinput: Implement a simple version of EnumDevicesBySemanticsA which enumerates only the keyboard. > > --- > dlls/dinput/dinput_main.c | 46 ++++++++++++++++++++++++++++++++++++++------ > 1 files changed, 39 insertions(+), 7 deletions(-) > > diff --git a/dlls/dinput/dinput_main.c b/dlls/dinput/dinput_main.c > index d3727bc..2d572bf 100644 > --- a/dlls/dinput/dinput_main.c > +++ b/dlls/dinput/dinput_main.c > @@ -120,7 +120,7 @@ static struct list direct_input_list = LIST_INIT( direct_input_list ); > */ > HRESULT WINAPI DirectInputCreateEx( > HINSTANCE hinst, DWORD dwVersion, REFIID riid, LPVOID *ppDI, > - LPUNKNOWN punkOuter) > + LPUNKNOWN punkOuter) > { > IDirectInputImpl* This; > > @@ -282,7 +282,7 @@ static HRESULT WINAPI IDirectInputAImpl_EnumDevices( > } > } > } > - > + > return 0; > } > /****************************************************************************** > @@ -290,7 +290,7 @@ static HRESULT WINAPI IDirectInputAImpl_EnumDevices( > */ > static HRESULT WINAPI IDirectInputWImpl_EnumDevices( > LPDIRECTINPUT7W iface, DWORD dwDevType, LPDIENUMDEVICESCALLBACKW lpCallback, > - LPVOID pvRef, DWORD dwFlags) > + LPVOID pvRef, DWORD dwFlags) > { > IDirectInputImpl *This = impl_from_IDirectInput7W( iface ); > DIDEVICEINSTANCEW devInstance; > @@ -313,7 +313,7 @@ static HRESULT WINAPI IDirectInputWImpl_EnumDevices( > } > } > } > - > + > return 0; > } > > @@ -416,7 +416,7 @@ static HRESULT WINAPI IDirectInputWImpl_QueryInterface(LPDIRECTINPUT7W iface, RE > > static HRESULT WINAPI IDirectInputAImpl_Initialize(LPDIRECTINPUT7A iface, HINSTANCE hinst, DWORD x) { > TRACE("(this=%p,%p,%x)\n",iface, hinst, x); > - > + > /* Initialize can return: DIERR_BETADIRECTINPUTVERSION, DIERR_OLDDIRECTINPUTVERSION and DI_OK. > * Since we already initialized the device, return DI_OK. In the past we returned DIERR_ALREADYINITIALIZED > * which broke applications like Tomb Raider Legend because it isn't a legal return value. > @@ -674,6 +674,9 @@ static HRESULT WINAPI IDirectInput8WImpl_FindDevice(LPDIRECTINPUT8W iface, REFGU > return IDirectInput2WImpl_FindDevice( &This->IDirectInput7W_iface, rguid, pszName, pguidInstance ); > } > > +/*********************************************************************** > + * EnumDevicesBySemanticsA > + */ > static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > LPDIRECTINPUT8A iface, LPCSTR ptszUserName, LPDIACTIONFORMATA lpdiActionFormat, > LPDIENUMDEVICESBYSEMANTICSCBA lpCallback, > @@ -681,8 +684,13 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > ) > { > IDirectInputImpl *This = impl_from_IDirectInput8A( iface ); > + DIDEVICEINSTANCEA devinst; > + LPDIRECTINPUTDEVICE8A lpdidev; > + unsigned int i; > + int j, r; > + int hasFormat = 0; > > - FIXME("(this=%p,%s,%p,%p,%p,%04x): stub\n", This, ptszUserName, lpdiActionFormat, > + TRACE("(this=%p,%s,%p,%p,%p,%04x): stub\n", This, ptszUserName, lpdiActionFormat, > lpCallback, pvRef, dwFlags); > #define X(x) if (dwFlags & x) FIXME("\tdwFlags |= "#x"\n"); > X(DIEDBSFL_ATTACHEDONLY) > @@ -695,6 +703,29 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > > _dump_diactionformatA(lpdiActionFormat); > > + devinst.dwSize = sizeof(devinst); > + /* mimicking what EnumDevices does and calling the callback function */ > + for (i = 0; i < NB_DINPUT_DEVICES; i++) { > + if (!dinput_devices[i]->enum_deviceA) continue; > + for (j = 0, r = -1; r != 0; j++) { > + > + TRACE(" - checking device %u ('%s')\n", i, dinput_devices[i]->name); > + if ((r = dinput_devices[i]->enum_deviceA(DI8DEVCLASS_ALL, dwFlags, &devinst, This->dwVersion, j))) { > + /* note that we have to create the device and set it's data format */ > + if ( GET_DIDEVICE_TYPE(devinst.dwDevType) == DI8DEVTYPE_KEYBOARD ) { > + IDirectInput_CreateDevice(iface,&devinst.guidInstance, &lpdidev, NULL); > + IDirectInputDevice_SetDataFormat(lpdidev,&c_dfDIKeyboard); > + hasFormat = 1; > + } > + /* only enumerate keyboard */ > + if (!hasFormat) continue; > + > + if (lpCallback(&devinst, lpdidev, 0 , 0, pvRef) == DIENUM_STOP) > + return DI_OK; > + } > + } > + } > + > return DI_OK; > } > > @@ -841,7 +872,7 @@ static HRESULT WINAPI DICF_CreateInstance( > return DirectInputCreateEx(0,0,riid,ppobj,pOuter); > } > > - FIXME("(%p,%p,%s,%p) Interface not found!\n",This,pOuter,debugstr_guid(riid),ppobj); > + FIXME("(%p,%p,%s,%p) Interface not found!\n",This,pOuter,debugstr_guid(riid),ppobj); > return E_NOINTERFACE; > } > > @@ -1121,3 +1152,4 @@ void check_dinput_hooks(LPDIRECTINPUTDEVICE8W iface) > > LeaveCriticalSection(&dinput_hook_crit); > } > + > -- > 1.7.0.4 > > From 97459e68a1247854301f7ef05584c6e860ad1b59 Mon Sep 17 00:00:00 2001 > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > Date: Sun, 29 May 2011 16:50:22 -0300 > Subject: dinput8/tests: Testing if EnumDevicesBySemantics sets the device buffer size according to the DIACTIONFORMAT. > > --- > dlls/dinput8/tests/device.c | 18 ++++++++++++++++-- > 1 files changed, 16 insertions(+), 2 deletions(-) > > diff --git a/dlls/dinput8/tests/device.c b/dlls/dinput8/tests/device.c > index eca22a9..dab298c 100644 > --- a/dlls/dinput8/tests/device.c > +++ b/dlls/dinput8/tests/device.c > @@ -51,10 +51,23 @@ static BOOL CALLBACK enum_by_semantics( > DWORD dwRemaining, > LPVOID pvRef) > { > - > + HRESULT hr; > + DIPROPDWORD dipdw; > int *ndevices = pvRef; > + > if (ndevices != NULL) *ndevices += 1; > > + /* test the buffer size */ > + dipdw.diph.dwSize = sizeof(DIPROPDWORD); > + hr = IDirectInputDevice_GetProperty(lpdid, DIPROP_BUFFERSIZE, &dipdw.diph); > + ok (SUCCEEDED(hr), "IDirectInputDevice_GetProperty failed hr=%08x\n",hr); > + > + if ( SUCCEEDED(hr) ) { > + todo_wine ok ( dipdw.dwData == 32, > + "EnumDevicesBySemantics must set the buffer size, buffersize=%d\n", > + dipdw.dwData); > + } > + > return DIENUM_CONTINUE; > } > > @@ -94,13 +107,14 @@ static void test_action_mapping(void) > af.dwNumActions = sizeof(actionMapping) / sizeof(actionMapping[0]); > af.rgoAction = actionMapping; > af.guidActionMap = ACTION_MAPPING_GUID; > + af.dwBufferSize = 32; > af.dwGenre = 0x01000000; /* DIVIRTUAL_DRIVING_RACE */ > > hr = IDirectInput8_EnumDevicesBySemantics(pDI,0, &af, > enum_by_semantics, &ndevices, 0); > > ok(SUCCEEDED(hr), "EnumDevicesBySemantics failed: hr=%08x\n",hr); > - todo_wine ok (ndevices > 0, "EnumDevicesBySemantics did not call the callback. hr=%08x ndevices=%d\n", hr, ndevices); > + ok(ndevices > 0, "EnumDevicesBySemantics did not call the callback. hr=%08x ndevices=%d\n", hr, ndevices); > > /* The call fails with a zeroed GUID */ > memset(&af.guidActionMap, 0, sizeof(GUID)); > -- > 1.7.0.4 > > From 33b8103cd04a028cd191c39fa58f56f307601b21 Mon Sep 17 00:00:00 2001 > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > Date: Sun, 29 May 2011 16:55:46 -0300 > Subject: dinput: EnumDevicesBySemantics now sets the device buffer according to the DIACTIONFORMAT structure > > --- > dlls/dinput/dinput_main.c | 9 +++++++++ > dlls/dinput8/tests/device.c | 2 +- > 2 files changed, 10 insertions(+), 1 deletions(-) > > diff --git a/dlls/dinput/dinput_main.c b/dlls/dinput/dinput_main.c > index 2d572bf..debf060 100644 > --- a/dlls/dinput/dinput_main.c > +++ b/dlls/dinput/dinput_main.c > @@ -686,6 +686,7 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > IDirectInputImpl *This = impl_from_IDirectInput8A( iface ); > DIDEVICEINSTANCEA devinst; > LPDIRECTINPUTDEVICE8A lpdidev; > + DIPROPDWORD dipdw; /* to set the buffer */ > unsigned int i; > int j, r; > int hasFormat = 0; > @@ -720,6 +721,14 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > /* only enumerate keyboard */ > if (!hasFormat) continue; > > + /* set the buffer */ > + if (lpdiActionFormat->dwBufferSize > 0) { > + IDirectInputDevice_Unacquire(lpdidev); > + dipdw.diph.dwSize = sizeof(DIPROPDWORD); > + dipdw.dwData = lpdiActionFormat->dwBufferSize; > + IDirectInputDevice_SetProperty(lpdidev,DIPROP_BUFFERSIZE,&dipdw.diph); > + } > + > if (lpCallback(&devinst, lpdidev, 0 , 0, pvRef) == DIENUM_STOP) > return DI_OK; > } > diff --git a/dlls/dinput8/tests/device.c b/dlls/dinput8/tests/device.c > index dab298c..70e5498 100644 > --- a/dlls/dinput8/tests/device.c > +++ b/dlls/dinput8/tests/device.c > @@ -63,7 +63,7 @@ static BOOL CALLBACK enum_by_semantics( > ok (SUCCEEDED(hr), "IDirectInputDevice_GetProperty failed hr=%08x\n",hr); > > if ( SUCCEEDED(hr) ) { > - todo_wine ok ( dipdw.dwData == 32, > + ok ( dipdw.dwData == 32, > "EnumDevicesBySemantics must set the buffer size, buffersize=%d\n", > dipdw.dwData); > } > -- > 1.7.0.4 > > From 67b5ac926ec3107df70a8b018191a9b209eb22b8 Mon Sep 17 00:00:00 2001 > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > Date: Sun, 29 May 2011 18:48:29 -0300 > Subject: dinput: Implemented SetActionMapA. Added an array of action mappings to the wine's dinput device > > --- > dlls/dinput/device.c | 64 +++++++++++++++++++++++++---------------- > dlls/dinput/device_private.h | 9 +++++- > 2 files changed, 47 insertions(+), 26 deletions(-) > > diff --git a/dlls/dinput/device.c b/dlls/dinput/device.c > index 397e70e..90ede33 100644 > --- a/dlls/dinput/device.c > +++ b/dlls/dinput/device.c > @@ -100,7 +100,7 @@ static void _dump_EnumObjects_flags(DWORD dwFlags) { > FE(DIDFT_TGLBUTTON), > FE(DIDFT_POV), > FE(DIDFT_COLLECTION), > - FE(DIDFT_NODATA), > + FE(DIDFT_NODATA), > FE(DIDFT_FFACTUATOR), > FE(DIDFT_FFEFFECTTRIGGER), > FE(DIDFT_OUTPUT), > @@ -221,7 +221,7 @@ void _dump_DIDATAFORMAT(const DIDATAFORMAT *df) { > TRACE(")\n"); > TRACE(" - dwDataSize: %d\n", df->dwDataSize); > TRACE(" - dwNumObjs: %d\n", df->dwNumObjs); > - > + > for (i = 0; i < df->dwNumObjs; i++) { > TRACE(" - Object %d:\n", i); > TRACE(" * GUID: %s ('%s')\n", debugstr_guid(df->rgodf[i].pguid), _dump_dinput_GUID(df->rgodf[i].pguid)); > @@ -326,19 +326,19 @@ void fill_DataFormat(void *out, DWORD size, const void *in, const DataFormat *df > df->dt[i].offset_out, df->dt[i].value); > *(out_c + df->dt[i].offset_out) = (char) df->dt[i].value; > break; > - > + > case 2: > TRACE("Copying (s) to %d default value %d\n", > df->dt[i].offset_out, df->dt[i].value); > *((short *) (out_c + df->dt[i].offset_out)) = (short) df->dt[i].value; > break; > - > + > case 4: > TRACE("Copying (i) to %d default value %d\n", > df->dt[i].offset_out, df->dt[i].value); > *((int *) (out_c + df->dt[i].offset_out)) = df->dt[i].value; > break; > - > + > default: > memset((out_c + df->dt[i].offset_out), 0, df->dt[i].size); > break; > @@ -388,7 +388,7 @@ static HRESULT create_DataFormat(LPCDIDATAFORMAT asked_format, DataFormat *forma > memcpy(format->user_df, asked_format, asked_format->dwSize); > > TRACE("Creating DataTransform :\n"); > - > + > for (i = 0; i < format->wine_df->dwNumObjs; i++) > { > format->offsets[i] = -1; > @@ -396,7 +396,7 @@ static HRESULT create_DataFormat(LPCDIDATAFORMAT asked_format, DataFormat *forma > for (j = 0; j < asked_format->dwNumObjs; j++) { > if (done[j] == 1) > continue; > - > + > if (/* Check if the application either requests any GUID and if not, it if matches > * the GUID of the Wine object. > */ > @@ -415,7 +415,7 @@ static HRESULT create_DataFormat(LPCDIDATAFORMAT asked_format, DataFormat *forma > DIDFT_GETTYPE(asked_format->rgodf[j].dwType) & format->wine_df->rgodf[i].dwType)) > { > done[j] = 1; > - > + > TRACE("Matching :\n"); > TRACE(" - Asked (%d) :\n", j); > TRACE(" * GUID: %s ('%s')\n", > @@ -424,7 +424,7 @@ static HRESULT create_DataFormat(LPCDIDATAFORMAT asked_format, DataFormat *forma > TRACE(" * Offset: %3d\n", asked_format->rgodf[j].dwOfs); > TRACE(" * dwType: %08x\n", asked_format->rgodf[j].dwType); > TRACE(" "); _dump_EnumObjects_flags(asked_format->rgodf[j].dwType); TRACE("\n"); > - > + > TRACE(" - Wine (%d) :\n", i); > TRACE(" * GUID: %s ('%s')\n", > debugstr_guid(format->wine_df->rgodf[i].pguid), > @@ -432,7 +432,7 @@ static HRESULT create_DataFormat(LPCDIDATAFORMAT asked_format, DataFormat *forma > TRACE(" * Offset: %3d\n", format->wine_df->rgodf[i].dwOfs); > TRACE(" * dwType: %08x\n", format->wine_df->rgodf[i].dwType); > TRACE(" "); _dump_EnumObjects_flags(format->wine_df->rgodf[i].dwType); TRACE("\n"); > - > + > if (format->wine_df->rgodf[i].dwType & DIDFT_BUTTON) > dt[index].size = sizeof(BYTE); > else > @@ -442,10 +442,10 @@ static HRESULT create_DataFormat(LPCDIDATAFORMAT asked_format, DataFormat *forma > format->offsets[i] = asked_format->rgodf[j].dwOfs; > dt[index].value = 0; > next = next + dt[index].size; > - > + > if (format->wine_df->rgodf[i].dwOfs != dt[index].offset_out) > same = 0; > - > + > index++; > break; > } > @@ -462,7 +462,7 @@ static HRESULT create_DataFormat(LPCDIDATAFORMAT asked_format, DataFormat *forma > TRACE(" * Offset: %3d\n", asked_format->rgodf[j].dwOfs); > TRACE(" * dwType: %08x\n", asked_format->rgodf[j].dwType); > TRACE(" "); _dump_EnumObjects_flags(asked_format->rgodf[j].dwType); TRACE("\n"); > - > + > if (asked_format->rgodf[j].dwType & DIDFT_BUTTON) > dt[index].size = sizeof(BYTE); > else > @@ -478,7 +478,7 @@ static HRESULT create_DataFormat(LPCDIDATAFORMAT asked_format, DataFormat *forma > same = 0; > } > } > - > + > format->internal_format_size = format->wine_df->dwDataSize; > format->size = index; > if (same) { > @@ -1191,7 +1191,7 @@ HRESULT WINAPI IDirectInputDevice2AImpl_EnumEffects( > { > FIXME("(this=%p,%p,%p,0x%08x): stub!\n", > iface, lpCallback, lpvRef, dwFlags); > - > + > return DI_OK; > } > > @@ -1203,7 +1203,7 @@ HRESULT WINAPI IDirectInputDevice2WImpl_EnumEffects( > { > FIXME("(this=%p,%p,%p,0x%08x): stub!\n", > iface, lpCallback, lpvRef, dwFlags); > - > + > return DI_OK; > } > > @@ -1317,7 +1317,7 @@ HRESULT WINAPI IDirectInputDevice7AImpl_EnumEffectsInFile(LPDIRECTINPUTDEVICE8A > DWORD dwFlags) > { > FIXME("(%p)->(%s,%p,%p,%08x): stub !\n", iface, lpszFileName, pec, pvRef, dwFlags); > - > + > return DI_OK; > } > > @@ -1328,7 +1328,7 @@ HRESULT WINAPI IDirectInputDevice7WImpl_EnumEffectsInFile(LPDIRECTINPUTDEVICE8W > DWORD dwFlags) > { > FIXME("(%p)->(%s,%p,%p,%08x): stub !\n", iface, debugstr_w(lpszFileName), pec, pvRef, dwFlags); > - > + > return DI_OK; > } > > @@ -1339,7 +1339,7 @@ HRESULT WINAPI IDirectInputDevice7AImpl_WriteEffectToFile(LPDIRECTINPUTDEVICE8A > DWORD dwFlags) > { > FIXME("(%p)->(%s,%08x,%p,%08x): stub !\n", iface, lpszFileName, dwEntries, rgDiFileEft, dwFlags); > - > + > return DI_OK; > } > > @@ -1350,7 +1350,7 @@ HRESULT WINAPI IDirectInputDevice7WImpl_WriteEffectToFile(LPDIRECTINPUTDEVICE8W > DWORD dwFlags) > { > FIXME("(%p)->(%s,%08x,%p,%08x): stub !\n", iface, debugstr_w(lpszFileName), dwEntries, rgDiFileEft, dwFlags); > - > + > return DI_OK; > } > > @@ -1382,7 +1382,7 @@ HRESULT WINAPI IDirectInputDevice8WImpl_BuildActionMap(LPDIRECTINPUTDEVICE8W ifa > X(DIDBAM_INITIALIZE) > X(DIDBAM_HWDEFAULTS) > #undef X > - > + > return DI_OK; > } > > @@ -1391,8 +1391,21 @@ HRESULT WINAPI IDirectInputDevice8AImpl_SetActionMap(LPDIRECTINPUTDEVICE8A iface > LPCSTR lpszUserName, > DWORD dwFlags) > { > + IDirectInputDeviceImpl *This = impl_from_IDirectInputDevice8A(iface); > + int i; > + > + This->use_actionmap = 1; > + > + /* search for actions for this device and apply them */ > + for (i=0; i < lpdiaf->dwNumActions; i++) { > + if (IsEqualGUID( &lpdiaf->rgoAction[i].guidInstance, &This->guid ) ) { > + int actionIndex = DIDFT_GETINSTANCE(lpdiaf->rgoAction[i].dwObjID); > + This->actionmap[actionIndex] = lpdiaf->rgoAction[i].uAppData; > + } > + } > + > FIXME("(%p)->(%p,%s,%08x): stub !\n", iface, lpdiaf, lpszUserName, dwFlags); > - > + > return DI_OK; > } > > @@ -1402,7 +1415,7 @@ HRESULT WINAPI IDirectInputDevice8WImpl_SetActionMap(LPDIRECTINPUTDEVICE8W iface > DWORD dwFlags) > { > FIXME("(%p)->(%p,%s,%08x): stub !\n", iface, lpdiaf, debugstr_w(lpszUserName), dwFlags); > - > + > return DI_OK; > } > > @@ -1410,7 +1423,7 @@ HRESULT WINAPI IDirectInputDevice8AImpl_GetImageInfo(LPDIRECTINPUTDEVICE8A iface > LPDIDEVICEIMAGEINFOHEADERA lpdiDevImageInfoHeader) > { > FIXME("(%p)->(%p): stub !\n", iface, lpdiDevImageInfoHeader); > - > + > return DI_OK; > } > > @@ -1418,6 +1431,7 @@ HRESULT WINAPI IDirectInputDevice8WImpl_GetImageInfo(LPDIRECTINPUTDEVICE8W iface > LPDIDEVICEIMAGEINFOHEADERW lpdiDevImageInfoHeader) > { > FIXME("(%p)->(%p): stub !\n", iface, lpdiDevImageInfoHeader); > - > + > return DI_OK; > } > + > diff --git a/dlls/dinput/device_private.h b/dlls/dinput/device_private.h > index f254d7f..b399d59 100644 > --- a/dlls/dinput/device_private.h > +++ b/dlls/dinput/device_private.h > @@ -28,6 +28,8 @@ > #include "wine/list.h" > #include "dinput_private.h" > > +#define MAX_DEVICE_OBJECTS 256 > + > typedef struct > { > int size; > @@ -71,6 +73,10 @@ struct IDirectInputDeviceImpl > BOOL overflow; /* return DI_BUFFEROVERFLOW in 'GetDeviceData' */ > > DataFormat data_format; /* user data format and wine to user format converter */ > + > + int use_actionmap; > + /* each app data is indexed by the device ObjID */ > + DWORD actionmap[MAX_DEVICE_OBJECTS]; > }; > > extern BOOL get_app_key(HKEY*, HKEY*) DECLSPEC_HIDDEN; > @@ -150,7 +156,7 @@ extern HRESULT WINAPI IDirectInputDevice2AImpl_GetObjectInfo( > LPDIDEVICEOBJECTINSTANCEA pdidoi, > DWORD dwObj, > DWORD dwHow) DECLSPEC_HIDDEN; > -extern HRESULT WINAPI IDirectInputDevice2WImpl_GetObjectInfo(LPDIRECTINPUTDEVICE8W iface, > +extern HRESULT WINAPI IDirectInputDevice2WImpl_GetObjectInfo(LPDIRECTINPUTDEVICE8W iface, > LPDIDEVICEOBJECTINSTANCEW pdidoi, > DWORD dwObj, > DWORD dwHow) DECLSPEC_HIDDEN; > @@ -246,3 +252,4 @@ extern HRESULT WINAPI IDirectInputDevice8WImpl_GetImageInfo(LPDIRECTINPUTDEVICE8 > LPDIDEVICEIMAGEINFOHEADERW lpdiDevImageInfoHeader) DECLSPEC_HIDDEN; > > #endif /* __WINE_DLLS_DINPUT_DINPUTDEVICE_PRIVATE_H */ > + > -- > 1.7.0.4 > > From 5b668ce7a929c34491fd478eefd50730e9a1c4ca Mon Sep 17 00:00:00 2001 > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > Date: Sun, 29 May 2011 18:55:56 -0300 > Subject: dinput: queue_event function now sets the uAppData member if the device is using action mapping > > --- > dlls/dinput/device.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/dlls/dinput/device.c b/dlls/dinput/device.c > index 90ede33..a979fff 100644 > --- a/dlls/dinput/device.c > +++ b/dlls/dinput/device.c > @@ -576,6 +576,10 @@ void queue_event(LPDIRECTINPUTDEVICE8A iface, int inst_id, DWORD data, DWORD tim > This->data_queue[This->queue_head].dwData = data; > This->data_queue[This->queue_head].dwTimeStamp = time; > This->data_queue[This->queue_head].dwSequence = seq; > + if (This->use_actionmap) { > + This->data_queue[This->queue_head].uAppData = This->actionmap[ofs]; > + } > + > This->queue_head = next_pos; > /* Send event if asked */ > } > -- > 1.7.0.4 > > From 943df09d16501c88a6a0a9bdf675b8514f268b68 Mon Sep 17 00:00:00 2001 > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > Date: Sun, 29 May 2011 19:01:29 -0300 > Subject: dinput: Implemented BuildActionMapA for all the DIACTION that map actions to DIKEYBOARD_* constants. > > --- > dlls/dinput/device.c | 23 +++++++++++++++++++++++ > 1 files changed, 23 insertions(+), 0 deletions(-) > > diff --git a/dlls/dinput/device.c b/dlls/dinput/device.c > index a979fff..19a64f7 100644 > --- a/dlls/dinput/device.c > +++ b/dlls/dinput/device.c > @@ -1358,11 +1358,34 @@ HRESULT WINAPI IDirectInputDevice7WImpl_WriteEffectToFile(LPDIRECTINPUTDEVICE8W > return DI_OK; > } > > +/****************************************************************************** > + * BuildActionMap > + * This sets an objID and a GUID for each DIACTION in the DIACTIONFORMAT that > + * should be mapped to this device. > + */ > HRESULT WINAPI IDirectInputDevice8AImpl_BuildActionMap(LPDIRECTINPUTDEVICE8A iface, > LPDIACTIONFORMATA lpdiaf, > LPCSTR lpszUserName, > DWORD dwFlags) > { > + IDirectInputDeviceImpl *This = impl_from_IDirectInputDevice8A(iface); > + int i; > + > +/* dwSemantic=810004df is dwObjID=0xdf04 */ > +#define SEMANTIC_TO_OBJID(s) (0x0000ffff & ( ((s) << 8) | ((s) >> 8) )) > + > + if ( IsEqualGUID(&This->guid, &GUID_SysKeyboard) ) { > + for (i=0; i < lpdiaf->dwNumActions; i++) { > + if ( HIWORD(lpdiaf->rgoAction[i].dwSemantic) == 0x8100) { /* DIKEYBOARD_* constant */ > + lpdiaf->rgoAction[i].dwObjID = SEMANTIC_TO_OBJID(lpdiaf->rgoAction[i].dwSemantic); > + lpdiaf->rgoAction[i].guidInstance = This->guid; > + lpdiaf->rgoAction[i].dwHow |= DIAH_USERCONFIG; /* set it as configured by the user */ > + } > + } > + } > + > +#undef SEMANTIC_TO_OBJID > + > FIXME("(%p)->(%p,%s,%08x): stub !\n", iface, lpdiaf, lpszUserName, dwFlags); > #define X(x) if (dwFlags & x) FIXME("\tdwFlags =|"#x"\n"); > X(DIDBAM_DEFAULT) > -- > 1.7.0.4 > > -- Working, but not speaking, for the following german company: SUSE LINUX Products GmbH, HRB 16746 (AG Nuernberg) Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

May 30, 2011

Re: [3/8] d3d8: Use D3DRESOURCETYPE -> WINED3DRESOURCETYPE enum conversion function instead of implicit conversion (clang)

by Stefan Dösinger

On Monday 30 May 2011 13:34:25 Frédéric Delanoy wrote: > In a similar vein, there's also > + case WINED3DMULTISAMPLE_NONE: return D3DMULTISAMPLE_NONE; > + case WINED3DMULTISAMPLE_NONMASKABLE: return (D3DMULTISAMPLE_TYPE) > type; > > Does this also need to be moved to device.c? Yes, to be on the safe side. The multisample type shouldn't be used in any performance-critical area. > I should probably better resubmit the whole modified series with a > (try 2), right? Or only the modified ones, still using the original > [foo/8] > series? I recommend to wait until Alexandre pushes the patches today and resubmit unapplied patches afterwards with (try 2) and a documentation what is different from the first version.

May 30, 2011

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

by Matteo Bruni

2011/5/29 Michael Mc Donnell <michael(a)mcdonnell.dk>: > On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger > <stefandoesinger(a)gmx.at> wrote: >> On Saturday 28 May 2011 19:55:55 you wrote: >> >>> It was implemented by setting the vertex declaration to null when the >>> declaration is invalid. That seems to match what happens on Windows, >>> because if a program has set an invalid declaration and then calls >>> GetDeclaration or DrawSubset it will fail with an access violation. >>> Should Wine also fail with an access violation or should it be >>> slightly more graceful and return E_FAIL instead (which my new patch >>> does)? >> Yes, I think returning E_FAIL is a good idea, but write a WARN if >> CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not >> be shown by default(unlike a FIXME), it is used when the app does something >> fishy but you think you handled it correctly. >> >>> + if (FAILED(hr)) >>> + new_vertex_declaration = NULL; >>> + >>> + /* Free old vertex declaration */ >>> + if (This->vertex_declaration) >>> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); >> In this situation you can just release the old decl before calling >> CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. >> That simplified the code a bit. Don't forget to set This->vertex_declaration to >> NULL in case of an error though > > Ok I've simplified the code. I've also inserted three WARNs. I've > skipped a WARN when freeing the mesh because that works fine on > Windows with an invalid declaration. > >>> + /* Set the position type to color instead of float3 (invalid >> declaration) */ >>> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >>> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >>> + "got %#x expected D3D_OK\n", hr); >> Is this really invalid? I don't know it on top of my head, but in general >> types and usage are independent, especially with shaders. I don't see a check >> in d3d9 or wined3d for this case. > > You're right it isn't invalid. It doesn't crash, it just doesn't draw > anything. I've change that comment and re-ordered the tests. > >> Beyond that I think the patches look OK. I'd recommend to send them to wine- >> devel one more time and then next week to wine-patches. Henri is on Vacation >> this week, and he's usually more picky than I am. I also hope some of the >> people who regularly contribute to d3dx9 will have a look and comment. > > Ok, I've attached the newest version. I'll let the patches sit here > for a week, and start working on the other functions in the mean time. > The patches are OK with me, just some nitpicking: + testContext = HeapAlloc(GetProcessHeap(), 0, sizeof(struct TestContext)); We usually use something like HeapAlloc(GetProcessHeap(), 0, sizeof(*testContext)); instead. I think you can remove some obvious comments (like /* Create the test mesh */). Also, check your whitespaces.

May 30, 2011

Re: [3/8] d3d8: Use D3DRESOURCETYPE -> WINED3DRESOURCETYPE enum conversion function instead of implicit conversion (clang)

by Frédéric Delanoy

On Mon, May 30, 2011 at 12:42, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Sunday 29 May 2011 09:46:06 Frédéric Delanoy wrote: > >> +static inline D3DRESOURCETYPE >> d3dresourcetype_from_wined3dresourcetype(WINED3DRESOURCETYPE type) +{ >> ... >> + case WINED3DRTYPE_BUFFER: return D3DRTYPE_VERTEXBUFFER; >> ... >> +static inline WINED3DRESOURCETYPE >> wined3dresourcetype_from_d3dresourcetype(D3DRESOURCETYPE type) +{ >> + case D3DRTYPE_VERTEXBUFFER: return WINED3DRTYPE_BUFFER; >> + case D3DRTYPE_INDEXBUFFER: return (WINED3DRESOURCETYPE) type; > > Those two cases are worth printing a FIXME. Just move the implementation to > device.c (like d3dformat_from_wined3dformat) so you have a declared debug > channel. In a similar vein, there's also + case WINED3DMULTISAMPLE_NONE: return D3DMULTISAMPLE_NONE; + case WINED3DMULTISAMPLE_NONMASKABLE: return (D3DMULTISAMPLE_TYPE) type; Does this also need to be moved to device.c? > In the long run the resource type conversion should go away in almost all > places, and those places that still need it(like CheckDeviceFormat) have to do > the conversion on their own. > > (Sorry that I didn't send that with the feedback for patch 7, it took me a > while to get around to reading it) I should probably better resubmit the whole modified series with a (try 2), right? Or only the modified ones, still using the original [foo/8] series? Frédéric Delanoy

May 30, 2011

Re: crypt32: Add BCryptEnumAlgorithms stub.

by David Hedberg

On Mon, May 30, 2011 at 12:45, David Hedberg <dhedberg(a)codeweavers.com> wrote: > --- Sorry, the commit message should of course say bcrypt, not crypt32.

May 30, 2011

Re: [3/8] d3d8: Use D3DRESOURCETYPE -> WINED3DRESOURCETYPE enum conversion function instead of implicit conversion (clang)

by Stefan Dösinger

On Sunday 29 May 2011 09:46:06 Frédéric Delanoy wrote: > +static inline D3DRESOURCETYPE > d3dresourcetype_from_wined3dresourcetype(WINED3DRESOURCETYPE type) +{ > ... > + case WINED3DRTYPE_BUFFER: return D3DRTYPE_VERTEXBUFFER; > ... > +static inline WINED3DRESOURCETYPE > wined3dresourcetype_from_d3dresourcetype(D3DRESOURCETYPE type) +{ > + case D3DRTYPE_VERTEXBUFFER: return WINED3DRTYPE_BUFFER; > + case D3DRTYPE_INDEXBUFFER: return (WINED3DRESOURCETYPE) type; Those two cases are worth printing a FIXME. Just move the implementation to device.c (like d3dformat_from_wined3dformat) so you have a declared debug channel. In the long run the resource type conversion should go away in almost all places, and those places that still need it(like CheckDeviceFormat) have to do the conversion on their own. (Sorry that I didn't send that with the feedback for patch 7, it took me a while to get around to reading it)

May 30, 2011

Re: [8/8] d3d8: Use D3DPRIMITIVETYPE -> WINED3DPRIMITIVETYPE enum conversion function instead of implicit conversion (clang)

by Stefan Dösinger

On Monday 30 May 2011 11:29:26 Frédéric Delanoy wrote: > Yeah right, I changed/adapted the title in [7/8] since the conv > function wasn't needed anymore and thought that if I used a [7/8] with > another subject and (try 2) it wouldn't be noticed straightforwardly. Nah, Alexandre's scripts work very well there, and if the scripts don't figure it out he does. However if you restart your numbering you'll confuse the winetestbot. Your patches don't change the tests though so the testbot didn't complain.

May 30, 2011

Re: [8/8] d3d8: Use D3DPRIMITIVETYPE -> WINED3DPRIMITIVETYPE enum conversion function instead of implicit conversion (clang)

by Frédéric Delanoy

On Mon, May 30, 2011 at 10:58, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Am 29.05.2011 um 19:35 schrieb Frédéric Delanoy: > >> Please skip this patch; it needs adaptation to avoid rebasing/merge >> conflicts due to changes to be done in patch " [7/8] d3d8: Use >> D3DRENDERSTATETYPE -> WINED3DRENDERSTATETYPE enum conversion function >> instead of implicit conversion (clang)." >> >> I'll resend both patches in a subsequent series. > To avoid confusion it is better to resend them as [7/8] and [8/8] as long as the original patches aren't applied. Now I'd recommend you to wait until today's commit wave before resending anything else to see which patches are applied and resend the others. Yeah right, I changed/adapted the title in [7/8] since the conv function wasn't needed anymore and thought that if I used a [7/8] with another subject and (try 2) it wouldn't be noticed straightforwardly. Frédéric

May 30, 2011

Re: [8/8] d3d8: Use D3DPRIMITIVETYPE -> WINED3DPRIMITIVETYPE enum conversion function instead of implicit conversion (clang)

by Stefan Dösinger

Am 29.05.2011 um 19:35 schrieb Frédéric Delanoy: > Please skip this patch; it needs adaptation to avoid rebasing/merge > conflicts due to changes to be done in patch " [7/8] d3d8: Use > D3DRENDERSTATETYPE -> WINED3DRENDERSTATETYPE enum conversion function > instead of implicit conversion (clang)." > > I'll resend both patches in a subsequent series. To avoid confusion it is better to resend them as [7/8] and [8/8] as long as the original patches aren't applied. Now I'd recommend you to wait until today's commit wave before resending anything else to see which patches are applied and resend the others.

May 30, 2011

Re: NTDLL doesn't compile under Clang

by James McKenzie

On 5/29/11 11:43 AM, Charles Davis wrote: > On 5/29/11 12:41 PM, C.W. Betts wrote: >> When compiling the NTDLL component of Wine, I get the following error: >> ../../../wine-git/./dlls/ntdll/large_int.c:267:13: error: unknown use of >> instruction mnemonic without a size suffix >> __asm__("div %4,%%eax" >> ^ >> <inline asm>:1:2: note: instantiated into assembly here >> div 12(%esp),%eax >> ^ >> I'm using Clang 2.0 from Xcode 4.0 > That's a Clang bug that's already been fixed. Sadly, it didn't make it > into Xcode 4.0. Any hope of it making it into a up release of XCode? Don't like running into upstream fixed bugs in a .0 release product. :( James McKenzie

May 29, 2011

Re: [PATCH] gdiplus: Convert and pass in 3 points, not 1 (Coverity)

by Vincent Povirk

Good catch. This sort of thing would have been very hard to track down in a real app. On Sun, May 29, 2011 at 4:53 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, > > CID 1147 > We get 3 points, not 1 ... and also need to pass on 3 points. > > Ciao, Marcus > --- > dlls/gdiplus/matrix.c | 12 +++++++----- > 1 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/dlls/gdiplus/matrix.c b/dlls/gdiplus/matrix.c > index 1035cc2..acfe989 100644 > --- a/dlls/gdiplus/matrix.c > +++ b/dlls/gdiplus/matrix.c > @@ -105,7 +105,8 @@ GpStatus WINGDIPAPI GdipCreateMatrix3I(GDIPCONST GpRect *rect, GDIPCONST GpPoint > GpMatrix **matrix) > { > GpRectF rectF; > - GpPointF ptF; > + GpPointF ptF[3]; > + int i; > > TRACE("(%p, %p, %p)\n", rect, pt, matrix); > > @@ -114,10 +115,11 @@ GpStatus WINGDIPAPI GdipCreateMatrix3I(GDIPCONST GpRect *rect, GDIPCONST GpPoint > rectF.Width = (REAL)rect->Width; > rectF.Height = (REAL)rect->Height; > > - ptF.X = (REAL)pt->X; > - ptF.Y = (REAL)pt->Y; > - > - return GdipCreateMatrix3(&rectF, &ptF, matrix); > + for (i = 0; i < 3; i++) { > + ptF[i].X = (REAL)pt[i].X; > + ptF[i].Y = (REAL)pt[i].Y; > + } > + return GdipCreateMatrix3(&rectF, ptF, matrix); > } > > GpStatus WINGDIPAPI GdipCloneMatrix(GpMatrix *matrix, GpMatrix **clone) > -- > 1.7.3.4 > > > >

May 29, 2011

GSoC: dinput8 Action Mapping

by Lucas Zawacki

Hey guys. So last week I finally got a good understanding of dinput as a whole and nailed some trivial cases of action mapping, the ones with the keyboard. I'm sending a series of patches so everyone can take a look before I try commiting them. Please note that these contain a partial implementation of EnumDevicesBySemantics, BuildActionMap and SetActionMap, and also they're only the A versions. There are some tests for EnumDevicesBySemantics. I'm not too sure of how to code the tests that require user input... I hope it's not a nuisance to read the code split in 7 files, if you guys want I can merge it in one big diff. On a bright note, this patchset results in the input working for these two games: * http://appdb.winehq.org/objectManager.php?sClass=application&iId=3678 * http://appdb.winehq.org/objectManager.php?sClass=application&iId=7919 Cheers :)

May 29, 2011

Re: ddraw: Add tests for SetCooperativeLevel

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

May 29, 2011

Re: NTDLL doesn't compile under Clang

by Marcus Meissner

On Sun, May 29, 2011 at 12:43:35PM -0600, Charles Davis wrote: > On 5/29/11 12:41 PM, C.W. Betts wrote: > > When compiling the NTDLL component of Wine, I get the following error: > > ../../../wine-git/./dlls/ntdll/large_int.c:267:13: error: unknown use of > > instruction mnemonic without a size suffix > > __asm__("div %4,%%eax" > > ^ > > <inline asm>:1:2: note: instantiated into assembly here > > div 12(%esp),%eax > > ^ > > I'm using Clang 2.0 from Xcode 4.0 > That's a Clang bug that's already been fixed. Sadly, it didn't make it > into Xcode 4.0. Try this patch? Ciao, Marcus Subject: [PATCH] ntdll: specify div to be divl Hi, avoids a clang build issue. Ciao, Marcus --- dlls/ntdll/large_int.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/ntdll/large_int.c b/dlls/ntdll/large_int.c index cb98bae..54ce6b0 100644 --- a/dlls/ntdll/large_int.c +++ b/dlls/ntdll/large_int.c @@ -264,7 +264,7 @@ UINT WINAPI RtlEnlargedUnsignedDivide( ULONGLONG a, UINT b, UINT *remptr ) p1 = a >> 32; p2 = a & 0xffffffffLL; - __asm__("div %4,%%eax" + __asm__("divl %4,%%eax" : "=a" (ret), "=d" (rem) : "0" (p2), "1" (p1), "g" (b) ); if (remptr) *remptr = rem; -- 1.7.3.4

May 29, 2011

Re: NTDLL doesn't compile under Clang

by Charles Davis

On 5/29/11 12:41 PM, C.W. Betts wrote: > When compiling the NTDLL component of Wine, I get the following error: > ../../../wine-git/./dlls/ntdll/large_int.c:267:13: error: unknown use of > instruction mnemonic without a size suffix > __asm__("div %4,%%eax" > ^ > <inline asm>:1:2: note: instantiated into assembly here > div 12(%esp),%eax > ^ > I'm using Clang 2.0 from Xcode 4.0 That's a Clang bug that's already been fixed. Sadly, it didn't make it into Xcode 4.0. Chip

May 29, 2011

NTDLL doesn't compile under Clang

by C.W. Betts

When compiling the NTDLL component of Wine, I get the following error: ../../../wine-git/./dlls/ntdll/large_int.c:267:13: error: unknown use of instruction mnemonic without a size suffix __asm__("div %4,%%eax" ^ <inline asm>:1:2: note: instantiated into assembly here div 12(%esp),%eax ^ I'm using Clang 2.0 from Xcode 4.0

May 29, 2011

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

by Michael Mc Donnell

On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Saturday 28 May 2011 19:55:55 you wrote: > >> It was implemented by setting the vertex declaration to null when the >> declaration is invalid. That seems to match what happens on Windows, >> because if a program has set an invalid declaration and then calls >> GetDeclaration or DrawSubset it will fail with an access violation. >> Should Wine also fail with an access violation or should it be >> slightly more graceful and return E_FAIL instead (which my new patch >> does)? > Yes, I think returning E_FAIL is a good idea, but write a WARN if > CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not > be shown by default(unlike a FIXME), it is used when the app does something > fishy but you think you handled it correctly. > >> + if (FAILED(hr)) >> + new_vertex_declaration = NULL; >> + >> + /* Free old vertex declaration */ >> + if (This->vertex_declaration) >> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); > In this situation you can just release the old decl before calling > CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. > That simplified the code a bit. Don't forget to set This->vertex_declaration to > NULL in case of an error though Ok I've simplified the code. I've also inserted three WARNs. I've skipped a WARN when freeing the mesh because that works fine on Windows with an invalid declaration. >> + /* Set the position type to color instead of float3 (invalid > declaration) */ >> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >> + "got %#x expected D3D_OK\n", hr); > Is this really invalid? I don't know it on top of my head, but in general > types and usage are independent, especially with shaders. I don't see a check > in d3d9 or wined3d for this case. You're right it isn't invalid. It doesn't crash, it just doesn't draw anything. I've change that comment and re-ordered the tests. > Beyond that I think the patches look OK. I'd recommend to send them to wine- > devel one more time and then next week to wine-patches. Henri is on Vacation > this week, and he's usually more picky than I am. I also hope some of the > people who regularly contribute to d3dx9 will have a look and comment. Ok, I've attached the newest version. I'll let the patches sit here for a week, and start working on the other functions in the mean time.

May 29, 2011

Re: [7/8] d3d8: Use D3DRENDERSTATETYPE -> WINED3DRENDERSTATETYPE enum conversion function instead of implicit conversion (clang)

by Stefan Dösinger

On Sunday 29 May 2011 09:46:10 Frédéric Delanoy wrote: > default: > - hr = wined3d_device_set_render_state(This->wined3d_device, > State, Value); > + hr = > wined3d_device_set_render_state(This->wined3d_device, + > wined3drenderstatetype_from_d3drenderstatetype(State), Value); } > wined3d_mutex_unlock(); d3d8's SetRenderState and GetRenderState already have a switch-case statement because ZBIAS doesn't exist in wined3d, so strictly speaking a direct cast is not possible. You cannot move the switch-case from SetRenderState to the state conversion function because the meaning of the Value parameter is different between D3DRS_ZBIAS and WINED3DRS_DEPTHBIAS. So I'd suggest to put the cast into the default cases of d3ddevice8::SetRenderState and d3device8::GetRenderState In d3d9 you can cast between the d3d9 and wined3d render state types.

May 29, 2011

Re: comctl32/tests: Using unsigned constants to remove sign comparison warning.

by David Laight

On Fri, May 27, 2011 at 10:09:04PM +0400, Nikolay Sivov wrote: > On Fri, May 27, 2011 at 5:16 PM, Marko Nikolic <grkoma(a)gmail.com> wrote: > > --- > > ?dlls/comctl32/tests/treeview.c | ? ?6 +++--- > > ?1 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/dlls/comctl32/tests/treeview.c b/dlls/comctl32/tests/treeview.c > > index 5fd26a0..b1eb85e 100644 > > --- a/dlls/comctl32/tests/treeview.c > > +++ b/dlls/comctl32/tests/treeview.c > > @@ -634,7 +634,7 @@ static void test_get_set_bkcolor(void) > > > > ? ? /* If the value is -1, the control is using the system color for the background color. */ > > ? ? crColor = (COLORREF)SendMessage( hTree, TVM_GETBKCOLOR, 0, 0 ); > > - ? ?ok(crColor == -1, "Default background color reported as 0x%.8x\n", crColor); > > + ? ?ok(crColor == 0xffffffff, "Default background color reported as 0x%.8x\n", crColor); > > > > ~0 looks better here imo. Rather ~0u The 0xffffffff should be 0xffffffffu David -- David Laight: david(a)l8s.co.uk

May 27, 2011

Re: Support for D3DQUERY_TIMESTAMP* queries...

by Adam Martinson

On 05/27/2011 01:23 PM, Adam Martinson wrote: > On 05/25/2011 11:31 AM, Stefan Dösinger wrote: >> On Wednesday 25 May 2011 18:23:39 Adam Martinson wrote: >>> Do you think that needs to be done before I submit those or is that >>> something that can come later? >> I'd prefer to have this checked before submitting. It shouldn't take >> long. >> Just write a test app that grabs the timestamp in a loop and prints >> it to >> stdout and see what kind of values it writes. If it does wrap around >> in a >> reasonable amount of time(e.g. a few hours) write a test that waits >> for the >> wraparound to approach, starts a disjoint query, waits until after the >> wraparound, ends the disjoint query and prints its result. > Ran a test for 10 mins or so, on my card it behaves like the > GL_ARB_timer_query version, except the frequency is 10ns instead of > 1ns... so it doesn't look like it would wrap around in my lifetime. I > can include that test with an environment variable to set the number > of iterations if you like. Are these ok to submit now?

May 27, 2011

Re: comctl32/tests: Using unsigned constants to remove sign comparison warning.

by Nikolay Sivov

On Fri, May 27, 2011 at 5:16 PM, Marko Nikolic <grkoma(a)gmail.com> wrote: > --- > dlls/comctl32/tests/treeview.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/comctl32/tests/treeview.c b/dlls/comctl32/tests/treeview.c > index 5fd26a0..b1eb85e 100644 > --- a/dlls/comctl32/tests/treeview.c > +++ b/dlls/comctl32/tests/treeview.c > @@ -634,7 +634,7 @@ static void test_get_set_bkcolor(void) > > /* If the value is -1, the control is using the system color for the background color. */ > crColor = (COLORREF)SendMessage( hTree, TVM_GETBKCOLOR, 0, 0 ); > - ok(crColor == -1, "Default background color reported as 0x%.8x\n", crColor); > + ok(crColor == 0xffffffff, "Default background color reported as 0x%.8x\n", crColor); > ~0 looks better here imo. >

May 27, 2011

Re: winealsa: Have TRACE_ON() use the same channel as TRACE (alsa).

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > alsa.c:ALSA_TraceParameters writes to channel "alsa", therefore you may consider > that it makes sense that TRACE_ON dispatches on that same channel and apply this patch. > Otherwise you need to listen to 2 channels to get output, e.g. +alsa,+wave or +dsalsa. > > Back when everything was in audio.c, "wave" was the only channel used. That would probably be a better choice. -- Alexandre Julliard julliard(a)winehq.org

May 27, 2011

Re: [PATCH 1/2] mshtml: Added IHTMLScreen::get_availHeight implementation

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -186,8 +186,15 @@ static HRESULT WINAPI HTMLScreen_get_updateInterval(IHTMLScreen *iface, LONG *p) > static HRESULT WINAPI HTMLScreen_get_availHeight(IHTMLScreen *iface, LONG *p) > { > HTMLScreen *This = impl_from_IHTMLScreen(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + RECT work_area; > + > + TRACE("(%p)->(%p)\n", This, p); > + > + if(!SystemParametersInfoW(SPI_GETWORKAREA, 0, &work_area, 0)) > + return E_FAIL; > + > + *p = work_area.bottom; You probably want work_area.bottom - work_area.top. -- Alexandre Julliard julliard(a)winehq.org

May 27, 2011

Re: [PATCH 5/5] msvcp90: Added _Mutex class implementation

by Nikolay Sivov

On Fri, May 27, 2011 at 4:24 PM, Piotr Caban <piotr(a)codeweavers.com> wrote: > --- > dlls/msvcp100/msvcp100.spec | 32 ++++++++++++++++---------------- > dlls/msvcp71/msvcp71.spec | 16 ++++++++-------- > dlls/msvcp80/msvcp80.spec | 32 ++++++++++++++++---------------- > dlls/msvcp90/Makefile.in | 1 + > dlls/msvcp90/msvcp90.spec | 32 ++++++++++++++++---------------- > 5 files changed, 57 insertions(+), 56 deletions(-) > There's no misc.c in a patch.

May 27, 2011

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

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 26.05.2011 um 16:27 schrieb Michael Mc Donnell: > Yeah I'd prefer it too to be 100% compatible. However, I think it is > highly unlikely that any programs depend on an exception being thrown > by EndScene in a drawing method. What EndScene method is this? The device's methods? I'd be surprised if this method crashed. > But you never know, some people do > crazy things :-) I think the current implementation is good enough as > long as there is no evidence of programs depending on that behavior. > > The problem is that UpdateSemantics in the d3dx9 library depends on > d3d9 and the error code is generated by vertexdeclaration_init in > d3d9. Do the d3d9 vertexdeclaration tests pass on this Windows machine? > I thought of managing an array of D3DVERTEXELEMENT9 in ID3DXMeshImpl > instead of a IDirect3DVertexDeclaration9, and then have > ID3DXMeshImpl_DrawSubset call IDirect3DDevice9_CreateVertexDeclaration > just before IDirect3DDevice9_SetVertexDeclaration. I suspect that this is what native does. This also fits the API design because UpdateSemantics accepts a D3DVERTEXELEMENT9 array and GetDeclaration returns a D3DVERTEXELEMENT9 array. Why did MS name those functions UpdateSemantics and GetDeclaration??? I don't think you'd have extra d3d9 calls by delaying the vdecl creation. Of course you have to keep the vdecl until the next UpdateSemantic call and not recreate it every time you draw. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIbBAEBAgAGBQJN3sIsAAoJEN0/YqbEcdMwIjwP+IxUGwlGAFCtgrJBuiVc9p6u wEeG7eK412dCjQBtgjwab4SI4XEZ8+Si555ZtorcVE2LV7jhTmzpEj32VPJYuKKo asmaNmDk9X45aR9kn7/3lwX9alI0mqwFmyB4pp7C9yr9IHhPBE8+6AAspXjgBKgw QIU1yluABO2OvEsFFjEXW5jPG1PTcMoB496iOX/1bDKlm6JjcCYtlv+6jKda2fMm xBe7xTAds4whdIBQ0xbsbcWQoSTLYmRrtkyiHXolKV3IRDtKlc4FHzOkCn3CURz7 gH7z+Z4Oj5HiY42smOAgJtifCD/mwszWj7bTKtxsG4fE2rnWHu/D/8g6oi4dzufp RpWE7uMxYwGirpgcMTIESkocyfj0LHOUzcanBhHnAxdeiNYrit8G9zaF+I58YASC JBBQtWXSTOzgZ0R8G2GcVXOcrTg2bQpsZ8nd5mJVOGQAPj16cRRgBc8iJfTlUZqY S9NAzkqBQly+8cGlTxKi7pWKBcJR64T+/KoLlN3VzoannwkBvvF5nk4uB9WvIgEO +OLmZI3+5bbWBbfHhc7hWs7MYcT0pnZoePRCFjmaKeV6r+z+6XZAUWKCNDhbukXJ Sna+YSaLo47RFnNL2P1zYC8gQ3ohhHKfJbZDJ6DX+bBKsRh45OFA6H0RlYVRRkAP 8GKf5K/pnG+FBaWEIYE= =QHcz -----END PGP SIGNATURE-----

May 26, 2011

Re: [3/3]usp10: add Devanagari script

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=11215 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 26, 2011

Re: [PATCH 5/7] comdlg32: Implement support for custom control subitems.

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=11214 Your paranoid android. === WVISTAADM (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L"" itemdlg.c:1294: Test failed: Failed to find item. itemdlg.c:1297: Test failed: Got L"" itemdlg.c:1300: Test failed: Got L"" === W2K8SE (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L"" itemdlg.c:1294: Test failed: Failed to find item. itemdlg.c:1297: Test failed: Got L"" itemdlg.c:1300: Test failed: Got L""

May 26, 2011

Re: [PATCH 4/7] comdlg32: Implement some functions for modifying custom controls.

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=11212 Your paranoid android. === WVISTAADM (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L"" === W2K8SE (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L""

May 26, 2011

Re: [PATCH 1/7] comdlg32: Add a container for custom controls.

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=11209 Your paranoid android. === W7PROX64 (32 bit itemdlg) === itemdlg: unhandled exception c0000005 at 75B94C19

May 26, 2011

Re: winscard: Implement some functions of winscard.dll

by Alexandre Julliard

Sergey Stepanov <serg_admin(a)rambler.ru> writes: > @@ -33,6 +35,24 @@ const SCARD_IO_REQUEST g_rgSCardT0Pci = { SCARD_PROTOCOL_T0, 8 }; > const SCARD_IO_REQUEST g_rgSCardT1Pci = { SCARD_PROTOCOL_T1, 8 }; > const SCARD_IO_REQUEST g_rgSCardRawPci = { SCARD_PROTOCOL_RAW, 8 }; > > +#define MAKE_FUNCPTR(f) static typeof(f) * p##f = NULL > +MAKE_FUNCPTR(SCardEstablishContext); > +MAKE_FUNCPTR(SCardReleaseContext); > +#undef MAKE_FUNCPTR This can't work. You need to use the Unix headers (with appropriate configure checks), declare pointers to the Unix functions, and convert any types that need it before calling them. -- Alexandre Julliard julliard(a)winehq.org

May 26, 2011

Re: USB Device Support

by Juan Lang

Hi Scott, > I've been working through my Dell Inspiron 1545 with Linux/Ubuntu > 10.04 LTS experiences with ongoing reviews. I'd like to provide some help > to others considering making the transition from Windows to Linux. I'm > trying to get my Garmin GPS to talk to its Mapsource (running under WINE) > application through a USB port. This allows tracks to be read from and > written to the GPS itself. So far no luck. Can someone there please > provide some advice? If this functionality isn't available yet then so be > it. The Mapsource application runs fine it's just the USB communication > that isn't working. Many thanks. Such questions are better addressed to the Wine forum. Thanks, --Juan

May 26, 2011

kernel32/heap: Fix GlobalMemoryStatus()/GlobalMemoryStatusEx()

by Adam Martinson

There are a bunch of old apps which are known to be buggy with this, the ones I tested were: Dragon NaturallySpeaking 7 Adobe Illustrator 8 Need for Speed 2 SE (demo) Adobe Photoshop 4 Photoshop 4 has a hack in GlobalMemoryStatus() that's causing problems for some of the others. The 2nd patch removes that hack, and breaks it the same way it's broken on Windows. Normally I wouldn't advocate breaking apps, but in this case I think it's appropriate. The 3rd patch gives a workaround for Photoshop 4 that seams like the appropriate solution to me, as it mirrors the workaround for Windows. Any feedback would be appreciated.

May 26, 2011

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

by Michael Mc Donnell

On Thu, May 26, 2011 at 1:14 PM, Joris Huizer <joris_huizer(a)yahoo.com> wrote: > On 05/26/2011 10:33 AM, Michael Mc Donnell wrote: >> I've added some more tests to see if I could make it fail. Microsoft's >> UpdateSemantics is not very picky. I can't get it to return anything >> but D3D_OK except for when I pass a null pointer. My implementation >> follows this behavior except for two cases: it returns E_FAIL when >> passing an undefined type and when the offset is not 4 byte aligned. >> This is because the values are checked inside vertexdeclaration_init. >> So Wine is stricter. I don't think that it is necessarily a problem >> because applications that pass bogus declarations like those will >> likely not work anyway. My own tests with a small interactive demo >> show that in those cases the application will crash with an access >> violation when it tries to re-draw the scene. > > I don't know whether it applies here, but if I understand correctly, > there have been cases before that Wine must not be stricter than Windows. > Tthe reason is that a program may 'depend' on a function crashing (it having > an exception caught in that case). > In such a situation, Wine's version of the function not crashing would cause > a code path being executed > that normally never is (causing incorrect behavior even) > > Again I don't know whether it is relevant in this cause. Yeah I'd prefer it too to be 100% compatible. However, I think it is highly unlikely that any programs depend on an exception being thrown by EndScene in a drawing method. But you never know, some people do crazy things :-) I think the current implementation is good enough as long as there is no evidence of programs depending on that behavior. The problem is that UpdateSemantics in the d3dx9 library depends on d3d9 and the error code is generated by vertexdeclaration_init in d3d9. That means d3d9 would have to be changed to make it less picky. That might on the other hand break other things that depend on it being picky (I haven't looked at the tests in d3d9). I thought of managing an array of D3DVERTEXELEMENT9 in ID3DXMeshImpl instead of a IDirect3DVertexDeclaration9, and then have ID3DXMeshImpl_DrawSubset call IDirect3DDevice9_CreateVertexDeclaration just before IDirect3DDevice9_SetVertexDeclaration. But that would not solve the problem as it would just shift the bad call to ID3DXMeshImpl_DrawSubset and not result in an exception in EndScene. It would also result in a lot of extra calls depending on the number of subsets. So I can't see any good way around modifying d3d9, but that might cause other problems as mentioned earlier. So to recapitulate, I think the best solution is to ignore that little difference until we see programs that depend on it. Michael Mc Donnell

May 26, 2011

Re: kernel32/toolhelp: PROCESSENTRY32::szExeFile is the full path in Win9x.

by Adam Martinson

On 05/26/2011 06:38 AM, Saulius Krasuckas wrote: > WRT doesn't test win9x any longer, so what's the point of putting such > check in the test? Ye, I noticed that when I was looking through Marvin's results, the reason I sent this one was to have the testbot check it xD

May 26, 2011

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

by Adam Martinson

On 05/26/2011 06:56 AM, Huw Davies wrote: > On Thu, May 26, 2011 at 06:51:13AM -0500, Adam Martinson wrote: >> On 05/26/2011 06:47 AM, Huw Davies wrote: >>> On Wed, May 25, 2011 at 12:45:15PM -0500, Adam Martinson wrote: >>>> On 05/25/2011 12:36 PM, Adam Martinson wrote: >>>>> The AddRef is done in WrapDropTarget(), seems like the appropriate >>>>> place for it. Quite right on the rest though, thanks. >>>> Oops no, the window prop should be pDropTarget, not the wrapper. >>>> The wrapper is only used for the marshalling. >>> That window prop could probably go away, I only put it there because >>> that's what Windows does, I doubt there's an app that relies on it >>> though. However if it stays you do need the AddRef! >>> >>> Huw. >> Best to mirror Windows as close as possible. The AddRef() is done >> in WrapDropTarget(). On failure IDropTarget::Release() is done on >> the wrapper, which removes the ref on the original. > You're storing a 2nd instance of the ptr (the first being in the > wrapper), conventionally you take a 2nd ref. When you remove the > window prop you release and when you destroy the wrapper you release > again. > > Huw. Ah, right, looks like I'm leaking the wrapper this way.

May 26, 2011

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

by Huw Davies

On Thu, May 26, 2011 at 06:51:13AM -0500, Adam Martinson wrote: > On 05/26/2011 06:47 AM, Huw Davies wrote: > >On Wed, May 25, 2011 at 12:45:15PM -0500, Adam Martinson wrote: > >>On 05/25/2011 12:36 PM, Adam Martinson wrote: > >>>The AddRef is done in WrapDropTarget(), seems like the appropriate > >>>place for it. Quite right on the rest though, thanks. > >>Oops no, the window prop should be pDropTarget, not the wrapper. > >>The wrapper is only used for the marshalling. > >That window prop could probably go away, I only put it there because > >that's what Windows does, I doubt there's an app that relies on it > >though. However if it stays you do need the AddRef! > > > >Huw. > Best to mirror Windows as close as possible. The AddRef() is done > in WrapDropTarget(). On failure IDropTarget::Release() is done on > the wrapper, which removes the ref on the original. You're storing a 2nd instance of the ptr (the first being in the wrapper), conventionally you take a 2nd ref. When you remove the window prop you release and when you destroy the wrapper you release again. Huw.

May 26, 2011

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

by Adam Martinson

On 05/26/2011 06:47 AM, Huw Davies wrote: > On Wed, May 25, 2011 at 12:45:15PM -0500, Adam Martinson wrote: >> On 05/25/2011 12:36 PM, Adam Martinson wrote: >>> The AddRef is done in WrapDropTarget(), seems like the appropriate >>> place for it. Quite right on the rest though, thanks. >> Oops no, the window prop should be pDropTarget, not the wrapper. >> The wrapper is only used for the marshalling. > That window prop could probably go away, I only put it there because > that's what Windows does, I doubt there's an app that relies on it > though. However if it stays you do need the AddRef! > > Huw. Best to mirror Windows as close as possible. The AddRef() is done in WrapDropTarget(). On failure IDropTarget::Release() is done on the wrapper, which removes the ref on the original.

May 26, 2011

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

by Huw Davies

On Wed, May 25, 2011 at 12:45:15PM -0500, Adam Martinson wrote: > On 05/25/2011 12:36 PM, Adam Martinson wrote: > >The AddRef is done in WrapDropTarget(), seems like the appropriate > >place for it. Quite right on the rest though, thanks. > > Oops no, the window prop should be pDropTarget, not the wrapper. > The wrapper is only used for the marshalling. That window prop could probably go away, I only put it there because that's what Windows does, I doubt there's an app that relies on it though. However if it stays you do need the AddRef! Huw.

May 26, 2011

Re: kernel32/toolhelp: PROCESSENTRY32::szExeFile is the full path in Win9x.

by Saulius Krasuckas

* On Wed, 25 May 2011, Adam Martinson wrote: > > Dragon NaturallySpeaking 7 expects this in Win98 mode. > --- > dlls/kernel32/tests/toolhelp.c | 19 +++++++++++++++- > dlls/kernel32/toolhelp.c | 48 +++++++++++++++++++++++++++++---------- > 2 files changed, 53 insertions(+), 14 deletions(-) I am not sure you do it right (now that new testing strategy is taken): * On Tue, 30 Nov 2010, Alexandre Julliard wrote: > > The value of running tests on Win9x these days is certainly > questionable. We don't try to emulate the Win9x behavior anyway, except > in a very few cases (which most likely don't have tests...) so it only > serves to document historical behavior that nobody cares about any > longer. WRT doesn't test win9x any longer, so what's the point of putting such check in the test? > --- a/dlls/kernel32/tests/toolhelp.c > +++ b/dlls/kernel32/tests/toolhelp.c ... > @@ -106,6 +108,10 @@ static void test_process(DWORD curr_pid, DWORD sub_pcs_pid) > unsigned found = 0; > int num = 0; > int childpos = -1; > + OSVERSIONINFO osver; > + > + osver.dwOSVersionInfoSize = sizeof(osver); > + pGetVersionEx(&osver); > > hSnapshot = pCreateToolhelp32Snapshot( TH32CS_SNAPPROCESS, 0 ); > ok(hSnapshot != NULL, "Cannot create snapshot\n"); > @@ -116,10 +122,15 @@ static void test_process(DWORD curr_pid, DWORD sub_pcs_pid) > { > do > { > + TCHAR* bslash = strchr(pe.szExeFile, '\\'); > if (pe.th32ProcessID == curr_pid) found++; > if (pe.th32ProcessID == sub_pcs_pid) { childpos = num; found++; } > trace("PID=%x %s\n", pe.th32ProcessID, pe.szExeFile); > num++; > + if (osver.dwMajorVersion < 5) > + ok(bslash != NULL, "szExeFile is not a full path: %s\n", pe.szExeFile); > + else > + ok(bslash == NULL, "szExeFile is a full path: %s\n", pe.szExeFile); > } while (pProcess32Next( hSnapshot, &pe )); > } > ok(found == 2, "couldn't find self and/or sub-process in process list\n"); Now such check is pointless, IMHO. Here goes question to Alexandre: what about (testing in) such cases? S.

May 26, 2011

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

by Joris Huizer

On 05/26/2011 10:33 AM, Michael Mc Donnell wrote: > > I've added some more tests to see if I could make it fail. Microsoft's > UpdateSemantics is not very picky. I can't get it to return anything > but D3D_OK except for when I pass a null pointer. My implementation > follows this behavior except for two cases: it returns E_FAIL when > passing an undefined type and when the offset is not 4 byte aligned. > This is because the values are checked inside vertexdeclaration_init. > So Wine is stricter. I don't think that it is necessarily a problem > because applications that pass bogus declarations like those will > likely not work anyway. My own tests with a small interactive demo > show that in those cases the application will crash with an access > violation when it tries to re-draw the scene. > > > I don't know whether it applies here, but if I understand correctly, there have been cases before that Wine must not be stricter than Windows. Tthe reason is that a program may 'depend' on a function crashing (it having an exception caught in that case). In such a situation, Wine's version of the function not crashing would cause a code path being executed that normally never is (causing incorrect behavior even) Again I don't know whether it is relevant in this cause. HTH, Joris

May 26, 2011

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

by Michael Mc Donnell

On Wed, May 25, 2011 at 9:53 AM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > On Tue, May 24, 2011 at 8:32 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> On Tuesday 24 May 2011 19:56:06 Michael Mc Donnell wrote: >>> > *) 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. I've reverted those changes, so it's back to NULL / non-NULL. I've also moved it near the top of the file, so that other tests will be able to re-use the test context creation. >>> 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. > > Ok thanks I'll do that. I've added some more tests to see if I could make it fail. Microsoft's UpdateSemantics is not very picky. I can't get it to return anything but D3D_OK except for when I pass a null pointer. My implementation follows this behavior except for two cases: it returns E_FAIL when passing an undefined type and when the offset is not 4 byte aligned. This is because the values are checked inside vertexdeclaration_init. So Wine is stricter. I don't think that it is necessarily a problem because applications that pass bogus declarations like those will likely not work anyway. My own tests with a small interactive demo show that in those cases the application will crash with an access violation when it tries to re-draw the scene.

May 26, 2011

Re: Tahoma Font License

by Scott Ritchie

On 05/25/2011 09:27 AM, Maarten Lankhorst wrote: > Hi mark, > > 2011/5/25 Mark Page <rombust(a)hotmail.co.uk>: >> >> I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... GNU Lesser General Public License 2.1 >> >> It would be useful to add the font to the ClanLib SDK resources (ClanLib has a zlib style license) >> >> It is not clear how a font can be licensed using LGPL, since LGPL is based around software libraries. >> >> Ideally I feel it should have a creative commons license >> >> I believe Creative commons did not exist when that font was created > tahoma.sfd: Copyright: Copyright (c) 2004 Larry Snyder, Based on > Bitstream Vera Sans Copyright (c) 2003 by Bitstream, Inc. Font renamed > in accordance with former's license. Please do not contact Bitstream > Inc. for any reason regarding this font. > > So just look up the original without contacting bitstream inc. ? > The topic of relicensing wine fonts has come up before. Usually the discussion ends with "our fonts aren't as good as you think, and you probably don't want them so don't worry about licensing." I'm not so sure it's true anymore. Symbol replacement, for instance, can actually be useful to show special characters on web pages that would otherwise come up as question marks. -Scott Ritchie

May 25, 2011

Re: extern char **environ and msvc

by Stefan Dösinger

On Wednesday 25 May 2011 23:04:02 Frank Richter wrote: > The underlying issue is probably the _CRTIMP - that's most likely > _declspec(dllimport) in MSVC. I suspected something like this, but msvc didn't want to tell me what _CRTIMP was. Either way it doesn't get me much closer to a fix.

May 25, 2011

Re: [2/2] user32: Add message test for hotkeys.

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

May 25, 2011

Re: extern char **environ and msvc

by Frank Richter

On 25.05.2011 22:52, Stefan Dösinger wrote: > I'm sorry for the German, I don't know how to change this. Google finds only > other clueless people. Either way it says something like "Inconsistent DLL > binding" I believe the English translation is “inconsistent DLL linkage”. > > The line in stdlib.h declares _environ as > > _CRTIMP extern char ** _environ; /* pointer to environment table */ > > The compiler just writes a warning, but afterwards linking fails: > > 1>loader.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__environ". > > The linker complains about an "unresolved external symbol __environ". Removing > our declaration of environ fixes the warning, link error and libwine seems to > work OK. > > I don't know what the proper fix is, please advise. Maybe this code shouldn't > be compiled at all? I don't think I need the loader code on Windows. The underlying issue is probably the _CRTIMP - that's most likely _declspec(dllimport) in MSVC. This matters, as DLL-imported and “plain” extern variables are handled differently on Windows. IIRC DLL export/import of variables is indirect - when DLL-importing a variable you really import a _pointer_ to the variable. So accessing the variable dereferences some pointer. “extern” variables, otoh, are accessed directly (resolving the actual variable location is handled at link-time). -f.r.

May 25, 2011

Re: [1/2] user32: Add test for RegisterHotKey/UnregisterHotKey.

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

May 25, 2011

re: Hans Leidekker : msi: Support rollback of failed uninstalls.

by Hans Leidekker

On Wed, 2011-05-25 at 18:49 +0000, Dan Kegel wrote: > wow, msi has really come a long way! Thanks. In hindsight we should have implemented rollbacks early on, when installers still failed regularly ;-)

May 25, 2011

extern char **environ and msvc

by Stefan Dösinger

Hi, This is one of the last remaining hacks needed to compile the d3d parts of Wine with Visual Studio. Our definition of **environ is conflicting with one already in the Windows SDK headers: 1>..\..\wine\libs\wine\loader.c(54): warning C4273: '_environ': Inkonsistente DLL-Bindung. 1> C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdlib.h(299): Siehe vorherige Definition von '_environ' I'm sorry for the German, I don't know how to change this. Google finds only other clueless people. Either way it says something like "Inconsistent DLL binding" The line in stdlib.h declares _environ as _CRTIMP extern char ** _environ; /* pointer to environment table */ The compiler just writes a warning, but afterwards linking fails: 1>loader.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__environ". The linker complains about an "unresolved external symbol __environ". Removing our declaration of environ fixes the warning, link error and libwine seems to work OK. I don't know what the proper fix is, please advise. Maybe this code shouldn't be compiled at all? I don't think I need the loader code on Windows. Stefan

May 25, 2011

Re: USB Device Support

by Scott

Hi, I've been working through my Dell Inspiron 1545 with Linux/Ubuntu 10.04 LTS experiences with ongoing reviews. I'd like to provide some help to others considering making the transition from Windows to Linux. I'm trying to get my Garmin GPS to talk to its Mapsource (running under WINE) application through a USB port. This allows tracks to be read from and written to the GPS itself. So far no luck. Can someone there please provide some advice? If this functionality isn't available yet then so be it. The Mapsource application runs fine it's just the USB communication that isn't working. Many thanks. Best - Scott

May 25, 2011

Re: [PATCH 1/2] ddraw: COM cleanup for IDirectDrawSurface3 iface

by Michael Stefaniuc

On 05/25/2011 08:37 PM, Stefan Dösinger wrote: > On Wednesday 25 May 2011 00:39:46 Ričardas Barkauskas wrote: >> My first try for COM cleanup. Please donėt be too harsh :) >> If this is too large for one patch, please suggest how to split it. >> >> This is not automatic clean up so I don't really expect it to be good on >> first try. > I can't find anything wrong with it on first sight, but I don't really know how > to manually review a patch that large with many repetitions. I guess I could > print them on a *lot* of paper and read them at the pool or something like > that. I normally read such a patch at least 3 times, more if I find some issues and have to manually fix them. Well "read"... after hundreds of such patches it isn't really a conscious read anymore. More like optical filtering looking for odd things; that's why I *hate* inconsistent coding style. > I don't see an easy way to split them up either :-/ . I guess we'll have to > trust Puk's script verification. The patch could be split up. What I do for such big and ugly patches is to first handle the unsafe_impl_from_IFace() part, then introduce impl_from_IFace() and only afterwards do the obj->lpVtl to obj->iface changes. Of course that really depends on the sizes of the resulting patches, but most of the times the unsafe_impl_from_IFace() part is a different patch as that isn't standard search and replace cookie cutter COM cleanup. > Just one thing: in unsafe_impl_from_IDirectDrawSurface*: > >> + if (iface->lpVtbl !=&ddraw_surface7_vtbl) return NULL; > I don't think apps can pass in their own ddraw object implementations. I've > never seen an app that does that or any document that suggests this is > possible and achives something. So I'd recommend to add a FIXME() or ERR() to > that case. An ERR because the most likely cause for such a behavior is that > our own ddrawex.dll screws up. This is the only other place where we have a > IDirectDrawSurface* implementation. Well in that case an assert() is the better option. It's done that way in other unsafe_impl_from_IFace like functions. And the program is likely to crash anyway later on when doing magic with the wrong pointer. > Or we could just remove the check and see if we ever crash because trying to > read surface implementation fields returns odd values. bye michael

May 25, 2011

re: Hans Leidekker : msi: Support rollback of failed uninstalls.

by Dan Kegel

wow, msi has really come a long way!

May 25, 2011

Re: [PATCH 1/2] ddraw: COM cleanup for IDirectDrawSurface3 iface

by Stefan Dösinger

On Wednesday 25 May 2011 00:39:46 Ričardas Barkauskas wrote: > My first try for COM cleanup. Please donėt be too harsh :) > If this is too large for one patch, please suggest how to split it. > > This is not automatic clean up so I don't really expect it to be good on > first try. I can't find anything wrong with it on first sight, but I don't really know how to manually review a patch that large with many repetitions. I guess I could print them on a *lot* of paper and read them at the pool or something like that. I don't see an easy way to split them up either :-/ . I guess we'll have to trust Puk's script verification. Just one thing: in unsafe_impl_from_IDirectDrawSurface*: > + if (iface->lpVtbl != &ddraw_surface7_vtbl) return NULL; I don't think apps can pass in their own ddraw object implementations. I've never seen an app that does that or any document that suggests this is possible and achives something. So I'd recommend to add a FIXME() or ERR() to that case. An ERR because the most likely cause for such a behavior is that our own ddrawex.dll screws up. This is the only other place where we have a IDirectDrawSurface* implementation. Or we could just remove the check and see if we ever crash because trying to read surface implementation fields returns odd values.

May 25, 2011

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

by Dan Kegel

On Wed, May 25, 2011 at 6:23 PM, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > The layout doesn't group all values, param names, or defaults, so it > actually seems to be best described using loops. Does the the > following comment help summarize the layout? Yes. Patch looks more readable now, thanks. Maybe an assert at the bottom as a sanity check that the final output pointer is exactly at the end of the buffer would be good. - Dan

May 25, 2011

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

by Dylan Smith

Hi Dan, On Wed, May 25, 2011 at 10:31 AM, Dan Kegel <dank(a)kegel.com> wrote: > A comment or two about the layout of the output buffer might > be nice. > The layout doesn't group all values, param names, or defaults, so it actually seems to be best described using loops. Does the the following comment help summarize the layout? /* effects buffer layout: * * D3DXEFFECTINSTANCE effects[num_materials]; * for (effect in effects) * { * D3DXEFFECTDEFAULT defaults[effect.NumDefaults]; * for (default in defaults) * { * *default.pParamName; * *default.pValue; * } * } */ > Can materials and material_ptr be const pointers? ID3DXBuffer_GetBufferPointer doesn't take a const, so no for materials, but material_ptr can be const. The rest of the advice I took (see the attached patch). Thanks for the patch review.

May 25, 2011

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

by Adam Martinson

On 05/25/2011 12:36 PM, Adam Martinson wrote: > On 05/24/2011 03:37 AM, Huw Davies wrote: >>> +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. > > The AddRef is done in WrapDropTarget(), seems like the appropriate > place for it. Quite right on the rest though, thanks. Oops no, the window prop should be pDropTarget, not the wrapper. The wrapper is only used for the marshalling.

May 25, 2011

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

by Adam Martinson

On 05/24/2011 03:37 AM, Huw Davies wrote: >> +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. The AddRef is done in WrapDropTarget(), seems like the appropriate place for it. Quite right on the rest though, thanks.

May 25, 2011

Re: Tahoma Font License

by Maarten Lankhorst

Hi mark, 2011/5/25 Mark Page <rombust(a)hotmail.co.uk>: > > I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... GNU Lesser General Public License 2.1 > > It would be useful to add the font to the ClanLib SDK resources (ClanLib has a zlib style license) > > It is not clear how a font can be licensed using LGPL, since LGPL is based around software libraries. > > Ideally I feel it should have a creative commons license > > I believe Creative commons did not exist when that font was created tahoma.sfd: Copyright: Copyright (c) 2004 Larry Snyder, Based on Bitstream Vera Sans Copyright (c) 2003 by Bitstream, Inc. Font renamed in accordance with former's license. Please do not contact Bitstream Inc. for any reason regarding this font. So just look up the original without contacting bitstream inc. ? Cheers, Maarten

May 25, 2011

Tahoma Font License

by Mark Page

I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... GNU Lesser General Public License 2.1 It would be useful to add the font to the ClanLib SDK resources (ClanLib has a zlib style license) It is not clear how a font can be licensed using LGPL, since LGPL is based around software libraries. Ideally I feel it should have a creative commons license I believe Creative commons did not exist when that font was created (I initially posted this message to forum.winehq.org, and it was suggested that I should post here instead) Mark.

May 25, 2011

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

by Dan Kegel

+ static const char diffuse_paramname[] = "Diffuse"; + static const char power_paramname[] = "Power"; + static const char specular_paramname[] = "Specular"; + static const char emissive_paramname[] = "Emissive"; + static const char ambient_paramname[] = "Ambient"; + static const DWORD basic_paramname_sizes = sizeof(diffuse_paramname) + + sizeof(power_paramname) + + sizeof(specular_paramname) + + sizeof(emissive_paramname) + + sizeof(ambient_paramname); ... It might be more readable to define material_effects[] up next to where those paramnames are defined, since it kind of clutters the loop, and it's nicer to keep the whole table definition together. (Also, at least conceptually, basic_paramname_sizes could be computed by a loop over the table. Then you wouldn't need those five _paramname variables, you could just use string constants. But if the strlen's would be expensive, I guess that's ok.) A comment or two about the layout of the output buffer might be nice. Can materials and material_ptr be const pointers? - Dan

May 25, 2011

Re: [PATCH] version: mark internal function with hidden visibility

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > @@ -348,7 +348,7 @@ static BOOL find_pe_resource( HFILE lzfd, DWORD *resLen, DWORD *resOff ) > /*********************************************************************** > * find_version_resource [internal] > */ > -DWORD find_version_resource( HFILE lzfd, DWORD *reslen, DWORD *offset ) > +DECLSPEC_HIDDEN DWORD find_version_resource( HFILE lzfd, DWORD *reslen, DWORD *offset ) > { This should be in a header. It's not very useful to make it hidden if callers are not aware of the fact. -- Alexandre Julliard julliard(a)winehq.org

May 25, 2011

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

by Stefan Dösinger

On Tuesday 24 May 2011 22:57:34 Henri Verbeet wrote: > 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. I planned to do this on top of this patch, but it turned out to be way easier than expected. Please ignore this patch for now. The others should still apply though.

May 25, 2011

Re: usp10/tests: Make enumFontProc() static.

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=11170 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 25, 2011

Re: [PATCH 1/2] ddraw: COM cleanup for IDirectDrawSurface3 iface

by Michael Stefaniuc

Damn ... I have attached the wrong diff. Michael Stefaniuc wrote: > Ričardas Barkauskas wrote: >> My first try for COM cleanup. Please donėt be too harsh :) >> If this is too large for one patch, please suggest how to split it. >> >> This is not automatic clean up so I don't really expect it to be good on >> first try. > Heh! I have attached the raw diff generated by my coccinelle script. > Looking at the interdiff between the two patches it looks like you > caught everything. And the BADBADBAD() (*) from the generated patch are > replaced with unsafe_impl_from_IDirectDrawSurface3(), very good. > > If you want to do more COM cleanup I can give you the raw generated > patches to save you some time. > > bye > michael > > P.S.: (*) My script validates that impl_from_IFace() is called only from > methods of that IFace. All other impl_from_IFace() calls are replaced > with BADBADBAD().

May 25, 2011

Re: [PATCH 1/2] ddraw: COM cleanup for IDirectDrawSurface3 iface

by Michael Stefaniuc

Hello Ričardas! Ričardas Barkauskas wrote: > My first try for COM cleanup. Please donėt be too harsh :) > If this is too large for one patch, please suggest how to split it. > > This is not automatic clean up so I don't really expect it to be good on > first try. Heh! I have attached the raw diff generated by my coccinelle script. Looking at the interdiff between the two patches it looks like you caught everything. And the BADBADBAD() (*) from the generated patch are replaced with unsafe_impl_from_IDirectDrawSurface3(), very good. If you want to do more COM cleanup I can give you the raw generated patches to save you some time. bye michael P.S.: (*) My script validates that impl_from_IFace() is called only from methods of that IFace. All other impl_from_IFace() calls are replaced with BADBADBAD().

May 25, 2011

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

by Michael Mc Donnell

On Tue, May 24, 2011 at 8:32 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > 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. Yeah it might not be a problem at all. I'll give it a quick second look to see if it's possible to cache things. I anyway need to read some more code too to see exactly how the APIs interact. >> 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. Ok good, I started to doubt this last night. I'll remove it and try to get a better sense of how the API works. >> > *) 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. Ok thanks I'll do that. >> > *) 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. Ok :-) I don't have any strong feelings about it, so I'll just follow your convention until somebody complains.

May 25, 2011

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

by Dan Kegel

On Tue, May 24, 2011 at 10:26 PM, Marvin <testbot(a)testbot.winehq.org> wrote: > === 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') Well, foo. Guess NT is different. I'll rework the tests sometime and resubmit. > === 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') This one surprised me, doesn't seem to match local testing on XP.

May 25, 2011

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