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