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