September 2011 - Wine-Devel

[PATCH 0/5] (4th attempt) CMD command line parsing

by Martin Wilck

This is my 4th attempt at fixing the cmd command line treatment. All patches pass the cmd tests with 0 errors both under wine and on the Test Bot, including NT. Whitespace issues are fixed, too. Apart from that, the code is the same as before. The size of my patches has been criticized - only patch 2/5 is really big, but it has to be that way to pass the tests. This will also be my last attempt to get this merged. If the patches don't get applied this time, I hope that the cmd Gurus (Frederic or Dan) will take up the bits they like and get them in over time. If there are any technical issues or bugs in my code, I'll of course take care (please email me privately, as I'm not monitoring wine-devel). A private side note: I estimate that I have spent at least 10x more effort and time to get the tests right and the patches submission-ready than I spent on fixing the actual Wine code. I believe this project needs to think over its policies. I fully understand that a project this big needs to take a lot of care to maintain qualitiy standards. But the way this is currently working is discouraging and frustrating for casual contributors like myself. Martin Wilck (5): cmd/tests: add tests for command line parsing cmd: use GetCommandline() rather than argv cmd: improve parsing of quotes in command line cmd: fix handling of special characters in command line cmd: fix parameter parsing of quotes and special chars programs/cmd/batch.c | 82 ++++++--- programs/cmd/tests/rsrc.rc | 6 + programs/cmd/tests/test_builtins.cmd.exp | 8 +- programs/cmd/tests/test_cmdline.cmd | 158 +++++++++++++++++ programs/cmd/tests/test_cmdline.cmd.exp | 77 +++++++++ programs/cmd/wcmdmain.c | 276 ++++++++++++------------------ 6 files changed, 406 insertions(+), 201 deletions(-) create mode 100755 programs/cmd/tests/test_cmdline.cmd create mode 100755 programs/cmd/tests/test_cmdline.cmd.exp -- 1.7.3.4

Sept. 28, 2011

CreateDC and DRIVER_GetDriverName

by Bruno Jesus

Hi, I'm seeking advice as I really don't understand anything about wine display drawing (gdi, x11, ...). Every game created with an old win3.11 tool called Klik & Play do not work in wine because a driver called DIB is passed as parameter to CreateDC. Till today I've only seen a driver called DISPLAY being used by all sorts of applications. Looking at the DRIVER_GetDriverName [1] function I can see a list where 3 different drivers are supported. In an attempt to run an old game called Mortuum [2] I can see that it always fail due to this missing DIB driver: err:dc:CreateDCW no driver found for L"DIB" My lack of knowledge made me do a dirty hack in the CreateDCW function forcing the driver DISPLAY to be used instead of DIB and when I started the game it draw it's first screen and then crashed. What should be done to support the DIB driver name now that DIB is implemented in wine? [1] = http://source.winehq.org/source/dlls/gdi32/driver.c#L800 [2] = ftp://ftp.padua.org/pub/msdos/windows/games/local/mortuum.zip Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

Sept. 28, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface.

by Erich Hoover

On Wed, Sep 28, 2011 at 2:45 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > ... > In general it's better to have the individual dlls handle their own > differences, instead of requiring d3dx9_36 to handle all the quirks of > 20 different versions. It sounded like we were only talking about some functions not existing on older versions, but if that's not the case then I would definitely agree. Erich Hoover ehoover(a)mines.edu

Sept. 28, 2011

Re: [PATCH] d3dx9_36: avoid using fabsf/fmaxf

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=14617 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Sept. 28, 2011

Re: [PATCH] d3dx9_36: avoid using fabsf/fmaxf

by Austin English

On Wed, Sep 28, 2011 at 01:51, Natanael Copa <ncopa(a)alpinelinux.org> wrote: > This fixes compiling on Alpine Linux and other uClibc based distros. > > This is related bug 28247 and commit 4cddd5ffdf0c568445365c6c62e7788d7dbbca7d > --- > dlls/d3dx9_36/tests/mesh.c | 14 +++++++------- > 1 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index 6a78e64..c09607f 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -6160,7 +6160,7 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > FLOAT *got = (FLOAT*)(got_ptr + decl_ptr->Offset); > FLOAT *exp = (FLOAT*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fabsf(*got - *exp); > + FLOAT diff = abs(*got - *exp); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got %f for vertex %d %s, expected %f.\n", > mesh_number, *got, vertex_number, usage_strings[decl_ptr->Usage], *exp); > break; > @@ -6169,7 +6169,7 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > D3DXVECTOR2 *got = (D3DXVECTOR2*)(got_ptr + decl_ptr->Offset); > D3DXVECTOR2 *exp = (D3DXVECTOR2*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fmaxf(fabsf(got->x - exp->x), fabsf(got->y - exp->y)); > + FLOAT diff = max(abs(got->x - exp->x), abs(got->y - exp->y)); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got (%f, %f) for vertex %d %s, expected (%f, %f).\n", > mesh_number, got->x, got->y, vertex_number, usage_strings[decl_ptr->Usage], exp->x, exp->y); > break; > @@ -6178,8 +6178,8 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > D3DXVECTOR3 *got = (D3DXVECTOR3*)(got_ptr + decl_ptr->Offset); > D3DXVECTOR3 *exp = (D3DXVECTOR3*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fmaxf(fabsf(got->x - exp->x), fabsf(got->y - exp->y)); > - diff = fmaxf(diff, fabsf(got->z - exp->z)); > + FLOAT diff = max(abs(got->x - exp->x), abs(got->y - exp->y)); > + diff = max(diff, abs(got->z - exp->z)); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got (%f, %f, %f) for vertex %d %s, expected (%f, %f, %f).\n", > mesh_number, got->x, got->y, got->z, vertex_number, usage_strings[decl_ptr->Usage], exp->x, exp->y, exp->z); > break; > @@ -6188,9 +6188,9 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > D3DXVECTOR4 *got = (D3DXVECTOR4*)(got_ptr + decl_ptr->Offset); > D3DXVECTOR4 *exp = (D3DXVECTOR4*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fmaxf(fabsf(got->x - exp->x), fabsf(got->y - exp->y)); > - diff = fmaxf(diff, fabsf(got->z - exp->z)); > - diff = fmaxf(diff, fabsf(got->w - exp->w)); > + FLOAT diff = max(abs(got->x - exp->x), abs(got->y - exp->y)); > + diff = max(diff, abs(got->z - exp->z)); > + diff = max(diff, abs(got->w - exp->w)); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got (%f, %f, %f, %f) for vertex %d %s, expected (%f, %f, %f, %f).\n", > mesh_number, got->x, got->y, got->z, got->w, vertex_number, usage_strings[decl_ptr->Usage], exp->x, exp->y, exp->z, got->w); > break; > -- > 1.7.6.1 fmaxf was already removed in http://source.winehq.org/git/wine.git/commitdiff/49064869595a8d0c97a79055eb… -- -Austin

Sept. 28, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface.

by Michael Stefaniuc

On 09/28/2011 11:03 PM, Rico Schüller wrote: > Am 28.09.2011 22:18, schrieb Erich Hoover: >> 2011/9/28 Rico Schüller<kgbricola(a)web.de>: >>> ... >>> d3dx9_25 and 24 needs it's own implementation because it's not only >>> the last >>> function which changed and that way it would look the same for all >>> forwarding effect interfaces in d3dx9_2{4,5,6}.dlls. >> I'm not an expert on this area, but I'd be tempted to implement this >> by having everything go through d3dx9_36. I might be missing >> something, but it seems like you could easily declare different >> virtual function tables and switch to the appropriate one based on the >> GUID passed to QueryInterface. >> >> Erich Hoover >> ehoover(a)mines.edu >> > That's possible but D3DXCreateEffect needs to return the correct effect > interface for the corresponding dll, too. The D3DXCreateEffect in > d3dx9_36.dll doesn't know anything about which version it should return. > So at least that function is needed 3 times. Maybe a QueryInterface in > D3DXCreateEffect25 after the D3DXCreateEffect call should do the trick, > but it breaks native d3dx9_36.dll in that case or the interfaces still > need to be known to 24/25, 26 and 36 dlls, but don't have to be public. > Well that would really make the code a lot smaller. > > Sure the possible problem with the "wrong" supported GUID would then > affected all d3dx9_xx.dlls. I'm fine with both versions. The question is > what's more important, compatibility or code size? From a quick look now Not making a mess out of COM else it will come haunt you ;) > I don't think that the "compatibility issue" affects any app, but I > couldn't prove it. I could only say, that only the corresponding > interface is allowed by each dll. bye michael

Sept. 28, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface.

by Rico Schüller

Am 28.09.2011 22:18, schrieb Erich Hoover: > 2011/9/28 Rico Schüller<kgbricola(a)web.de>: >> ... >> d3dx9_25 and 24 needs it's own implementation because it's not only the last >> function which changed and that way it would look the same for all >> forwarding effect interfaces in d3dx9_2{4,5,6}.dlls. > I'm not an expert on this area, but I'd be tempted to implement this > by having everything go through d3dx9_36. I might be missing > something, but it seems like you could easily declare different > virtual function tables and switch to the appropriate one based on the > GUID passed to QueryInterface. > > Erich Hoover > ehoover(a)mines.edu > That's possible but D3DXCreateEffect needs to return the correct effect interface for the corresponding dll, too. The D3DXCreateEffect in d3dx9_36.dll doesn't know anything about which version it should return. So at least that function is needed 3 times. Maybe a QueryInterface in D3DXCreateEffect25 after the D3DXCreateEffect call should do the trick, but it breaks native d3dx9_36.dll in that case or the interfaces still need to be known to 24/25, 26 and 36 dlls, but don't have to be public. Well that would really make the code a lot smaller. Sure the possible problem with the "wrong" supported GUID would then affected all d3dx9_xx.dlls. I'm fine with both versions. The question is what's more important, compatibility or code size? From a quick look now I don't think that the "compatibility issue" affects any app, but I couldn't prove it. I could only say, that only the corresponding interface is allowed by each dll. Cheers Rico

Sept. 28, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface.

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > 2011/9/28 Rico Schüller <kgbricola(a)web.de>: >> ... >> d3dx9_25 and 24 needs it's own implementation because it's not only the last >> function which changed and that way it would look the same for all >> forwarding effect interfaces in d3dx9_2{4,5,6}.dlls. > > I'm not an expert on this area, but I'd be tempted to implement this > by having everything go through d3dx9_36. I might be missing > something, but it seems like you could easily declare different > virtual function tables and switch to the appropriate one based on the > GUID passed to QueryInterface. In general it's better to have the individual dlls handle their own differences, instead of requiring d3dx9_36 to handle all the quirks of 20 different versions. -- Alexandre Julliard julliard(a)winehq.org

Sept. 28, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface.

by Erich Hoover

2011/9/28 Rico Schüller <kgbricola(a)web.de>: > ... > d3dx9_25 and 24 needs it's own implementation because it's not only the last > function which changed and that way it would look the same for all > forwarding effect interfaces in d3dx9_2{4,5,6}.dlls. I'm not an expert on this area, but I'd be tempted to implement this by having everything go through d3dx9_36. I might be missing something, but it seems like you could easily declare different virtual function tables and switch to the appropriate one based on the GUID passed to QueryInterface. Erich Hoover ehoover(a)mines.edu

Sept. 28, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface.

by Rico Schüller

Am 28.09.2011 16:43, schrieb Erich Hoover: > SetRawValue is at the end of the table, so it being extra will not > influence any older application. So, you should be able to get the > same functionality with way less code by adding that alternative GUID > to the QueryInterface in d3dx9_36. > > Erich Hoover > ehoover(a)mines.edu > Sure that's possible for d3dx9_26.dll, but native d3dx9_36.dll doesn't offer that GUID. I don't think that's much of an issue (because I don't think an app depends on this), but I found the solution with the forward a better one that also looks a way more compatible. Well, adding only the GUID would reduce the needed code a lot. d3dx9_25 and 24 needs it's own implementation because it's not only the last function which changed and that way it would look the same for all forwarding effect interfaces in d3dx9_2{4,5,6}.dlls. Cheers Rico

Sept. 28, 2011