August 2016 - Wine-Devel - list.winehq.org

Re: [PATCH] ntdll: Call __finally blocks in __C_specific_handler (try2)
by Piotr Caban Aug. 6, 2016

Aug. 6, 2016

On 08/06/16 01:39, Daniel Lehman wrote: > + if (rec->ExceptionFlags & EH_TARGET_UNWIND && > + dispatch->TargetIp < dispatch->ImageBase + table->ScopeRecord[i].EndAddress) > + { > + break; > + } Here's a test that shows that you also need to check BeginAddress: BOOL first = TRUE; __try { begin: if(!first) { printf("here\n"); return 0; } first = FALSE; __try { __try { goto begin; } __finally { printf("finally 1\n"); } } __finally { printf("finally 2\n"); } } __finally { printf("finally 3\n"); }

1 0

Re: [PATCH 1/5] d3dx11: Use debugstr_a() to trace a user-supplied string.
by Henri Verbeet Aug. 5, 2016

Aug. 5, 2016

On 5 August 2016 at 20:56, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -32,7 +32,7 @@ HRESULT WINAPI D3DX11CompileFromMemory(const char *data, SIZE_T data_size, const > { > TRACE("data %s, data_size %lu, filename %s, defines %p, include %p, entry_point %s, target %s, " > "sflags %#x, eflags %#x, pump %p, shader %p, error_messages %p, hresult %p.\n", > - debugstr_a(data), data_size, debugstr_a(filename), defines, include, entry_point, > + debugstr_a(data), data_size, debugstr_a(filename), defines, include, debugstr_a(entry_point), Somewhat related, this seems to assume "data" is a zero-terminated string.

2 1

Re: Simple D3D/WGL demos for wine
by Matteo Bruni Aug. 5, 2016

Aug. 5, 2016

2016-08-05 22:00 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: > On Fri, Aug 5, 2016 at 10:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> 2016-08-04 19:29 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: >>> Hello all. I'd like to implement a set of simple demos which would be >>> something like glxgears for Wine — a simple way to check that WGL, >>> D3D8, D3D9 and later D3D10 and D3D11 are operational, without any need >>> to look for a real app to test. I suppose it's not very interesting to >>> have just flat untextured gears, so I'd instead draw a textured cube >>> (similarly to what the tests in dxdiag do). >> >> Do you plan to include these demos in Wine or maintain them >> separately? I'd be in favor of including them in Wine proper (others >> might disagree though) but that introduces a few additional >> constraints, like no C++ code allowed. > I intended them to eventually get into Wine source, after I bring them > to more or less final form. It seems Wine does provide some macros to > call Direct3D virtual functions from C code — like > IDirect3D9_CreateDevice. Actually those macros are also in the original MS headers. Except when they aren't, like for a bunch of d3dx9 interfaces. In those cases we shouldn't have them either. If there is no macro for a method you need you can just manually call the function pointer through the vtable; see the relevant test sources for examples of that if it turns out to be the case. >> BTW, actually we do have a (VERY sketchy) dxdiag implementation in >> Wine, under programs/dxdiag/. You could integrate those demos into it >> in principle. > Good to know it exists, will look into integration of the demos there. > Do you think the WGL demo still fits there? I'd like to have a demo > for WGL since it's the simplest 3D interface for Wine, it's used by > wined3d, and if even it's not working then the users would be better > directed to where their problems might be (i.e. graphics > configuration, not wined3d code). I think it would be fine and nice to have, yes. >>> I have some prototype code for this (standalone and written in C++ for >>> now), and it uses D3DXCreateTextureFromFile. This is all OK when I >>> compile for D3D9 with wineg++ or when I compile for D3D8 and D3D9 with >>> ming32. But when I try to compile for D3D8 with wineg++, there's a >>> problem, since there's no d3dx8*.h nor d3dx8.dll in Wine. >>> >>> Is it undesirable for Wine to have d3dx8 (I remember some commits >>> removing the library and headers related to it several years ago)? >> >> You remember correctly. It turns out d3dx8 in practice was always >> statically compiled into the game executables. IIRC the DX8 SDK had no >> d3dx8.dll at all, just a d3dx8.lib with the full library. There was >> also a d3dx8_d.dll with a debug version of the library but that wasn't >> installed by the usual DirectX redistributable so applications can't >> depend on its presence either. In any case, we've had 0 applications >> using our d3dx8.dll, which means our implementation wasn't actually >> used or tested and there was no point in keeping it. >> >>> Should I just drop usage of D3DXCreateTextureFromFile and use plain >>> IDirect3DDeviceX::CreateTexture? >> >> You could use some other API to load the image files. I imagine that >> mixing d3dx9.h with d3d8 won't be a great experience. There are other >> options though, depending on the texture file format you want to use; >> WIC (windowscodecs) might be a good choice generally speaking. >> Another possibility is to create the textures you need procedurally, >> without needing to load them from a file or a resource. > For WGL version I used GdiPlus (flat) API, so I guess this is the way > to go for D3D versions. > The texture I thought of using was something like the following: > http://6g6.eu/sih0-winehq-logo-glass.png > I don't think it'd be easy to generate procedurally, although if > there's a good idea on what image to use instead, I'd favor the > procedural version due to its better reliability (i.e. no dependency > on external file being readable, residing in the expected location > etc.). The procedural generation thing was just an idea, loading from file or, probably better, from resource is okay too. >>> Also I use some matrix functions, which are identical between d3dx8 >>> and d3dx9. Would it be OK if a wine demo would link to d3dx9 both for >>> d3d9 and d3d8 versions of it? Or should I just reimplement all the >>> needed functions? >> >> As I mentioned above, I suspect you would get issues when trying to >> include d3dx9.h together with d3d8.h, although you can probably >> workaround that in this case by carefully dividing your code over >> multiple .c files. >> Depending on what you exactly need, just copying or reimplementing the >> relevant functions might be simpler. > Yeah there were some issues with including d3dx9.h directly, I worked > around them by manually declaring the necessary functions and types > and still linking to d3dx9 DLL. I guess that works too. It doesn't seem critical for the time being and it will probably be easier to give more sensible suggestions during an actual patch review. Looking forward to your patches :)

1 0

Re: usp10/tests: Reserve for InClass a byte for every character in teststr. (v4)
by Marvin Aug. 5, 2016

Aug. 5, 2016

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 https://testbot.winehq.org/JobDetails.pl?Key=24770 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

1 0

Fwd: Simple D3D/WGL demos for wine
by Ruslan Kabatsayev Aug. 5, 2016

Aug. 5, 2016

Sorry, forgot to include the mailing list to recipients. ---------- Forwarded message ---------- From: Ruslan Kabatsayev <b7.10110111(a)gmail.com> Date: Fri, Aug 5, 2016 at 11:00 PM Subject: Re: Simple D3D/WGL demos for wine To: Matteo Bruni <matteo.mystral(a)gmail.com> On Fri, Aug 5, 2016 at 10:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2016-08-04 19:29 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: >> Hello all. I'd like to implement a set of simple demos which would be >> something like glxgears for Wine — a simple way to check that WGL, >> D3D8, D3D9 and later D3D10 and D3D11 are operational, without any need >> to look for a real app to test. I suppose it's not very interesting to >> have just flat untextured gears, so I'd instead draw a textured cube >> (similarly to what the tests in dxdiag do). > > Do you plan to include these demos in Wine or maintain them > separately? I'd be in favor of including them in Wine proper (others > might disagree though) but that introduces a few additional > constraints, like no C++ code allowed. I intended them to eventually get into Wine source, after I bring them to more or less final form. It seems Wine does provide some macros to call Direct3D virtual functions from C code — like IDirect3D9_CreateDevice. > BTW, actually we do have a (VERY sketchy) dxdiag implementation in > Wine, under programs/dxdiag/. You could integrate those demos into it > in principle. Good to know it exists, will look into integration of the demos there. Do you think the WGL demo still fits there? I'd like to have a demo for WGL since it's the simplest 3D interface for Wine, it's used by wined3d, and if even it's not working then the users would be better directed to where their problems might be (i.e. graphics configuration, not wined3d code). > >> I have some prototype code for this (standalone and written in C++ for >> now), and it uses D3DXCreateTextureFromFile. This is all OK when I >> compile for D3D9 with wineg++ or when I compile for D3D8 and D3D9 with >> ming32. But when I try to compile for D3D8 with wineg++, there's a >> problem, since there's no d3dx8*.h nor d3dx8.dll in Wine. >> >> Is it undesirable for Wine to have d3dx8 (I remember some commits >> removing the library and headers related to it several years ago)? > > You remember correctly. It turns out d3dx8 in practice was always > statically compiled into the game executables. IIRC the DX8 SDK had no > d3dx8.dll at all, just a d3dx8.lib with the full library. There was > also a d3dx8_d.dll with a debug version of the library but that wasn't > installed by the usual DirectX redistributable so applications can't > depend on its presence either. In any case, we've had 0 applications > using our d3dx8.dll, which means our implementation wasn't actually > used or tested and there was no point in keeping it. > >> Should I just drop usage of D3DXCreateTextureFromFile and use plain >> IDirect3DDeviceX::CreateTexture? > > You could use some other API to load the image files. I imagine that > mixing d3dx9.h with d3d8 won't be a great experience. There are other > options though, depending on the texture file format you want to use; > WIC (windowscodecs) might be a good choice generally speaking. > Another possibility is to create the textures you need procedurally, > without needing to load them from a file or a resource. For WGL version I used GdiPlus (flat) API, so I guess this is the way to go for D3D versions. The texture I thought of using was something like the following: http://6g6.eu/sih0-winehq-logo-glass.png I don't think it'd be easy to generate procedurally, although if there's a good idea on what image to use instead, I'd favor the procedural version due to its better reliability (i.e. no dependency on external file being readable, residing in the expected location etc.). > >> Also I use some matrix functions, which are identical between d3dx8 >> and d3dx9. Would it be OK if a wine demo would link to d3dx9 both for >> d3d9 and d3d8 versions of it? Or should I just reimplement all the >> needed functions? > > As I mentioned above, I suspect you would get issues when trying to > include d3dx9.h together with d3d8.h, although you can probably > workaround that in this case by carefully dividing your code over > multiple .c files. > Depending on what you exactly need, just copying or reimplementing the > relevant functions might be simpler. Yeah there were some issues with including d3dx9.h directly, I worked around them by manually declaring the necessary functions and types and still linking to d3dx9 DLL. > > As an aside, one possible objection to these demos could be "but we > have tests already!" IMO these cover a somewhat separate use case and > having simple d3d* demos that common users could easily run, similarly > to the "Test sound" button in winecfg, could be valuable.

1 0

Wineconf 2016 location and dates are set - book your travel now!
by Jeremy White Aug. 5, 2016

Aug. 5, 2016

Hi folks, WineConf 2016 will be held on November 12th and 13th in St. Paul, MN. I've put up all of the details here: https://wiki.winehq.org/WineConf2016 Everyone is welcome at WineConf, please feel free to come. If you need help with travel expenses, please write to ask to ask for help; we are generally able to help, particularly for contributors to Wine (directions are in the Wiki). If you're interested in WineConf, you should sign up for the wineconf mailing list: https://www.winehq.org/mailman/listinfo/wineconf I've put the only two agenda items that matter to me on the Wiki: the keynote and fixing the tests. Feel free to suggest other topics or agenda items using the wineconf mailing list. I look forward to seeing you all there! Cheers, Jeremy

1 0

Re: [PATCH] d3dx9: Remove dead assignment (Coverity)
by Nikolay Sivov Aug. 5, 2016

Aug. 5, 2016

On 05.08.2016 21:57, Matteo Bruni wrote: > 2016-08-04 8:17 GMT+02:00 Nikolay Sivov <nsivov(a)codeweavers.com>: >> Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> >> --- >> >> It's overwritten right after if block. >> >> dlls/d3dx9_36/mesh.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/dlls/d3dx9_36/mesh.c b/dlls/d3dx9_36/mesh.c >> index 3204ea7..c26aa72 100644 >> --- a/dlls/d3dx9_36/mesh.c >> +++ b/dlls/d3dx9_36/mesh.c >> @@ -5662,7 +5662,6 @@ static HRESULT create_outline(struct glyphinfo *glyph, void *raw_outline, int da >> pt->corner = POINTTYPE_CURVE_END; >> } >> outline->count--; >> - lastpt = &outline->items[outline->count - 1]; >> } else { >> /* outline closed with a line from end to start point */ >> attempt_line_merge(outline, outline->count - 1, &pt->pos, FALSE, cos_table); >> -- >> 2.8.1 > > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > > BTW, there is exactly the same issue in the tests in tests/mesh.c line 3737. > > Ok, will try to remember to remove it too.

1 0

Simple D3D/WGL demos for wine
by Ruslan Kabatsayev Aug. 5, 2016

Aug. 5, 2016

Hello all. I'd like to implement a set of simple demos which would be something like glxgears for Wine — a simple way to check that WGL, D3D8, D3D9 and later D3D10 and D3D11 are operational, without any need to look for a real app to test. I suppose it's not very interesting to have just flat untextured gears, so I'd instead draw a textured cube (similarly to what the tests in dxdiag do). I have some prototype code for this (standalone and written in C++ for now), and it uses D3DXCreateTextureFromFile. This is all OK when I compile for D3D9 with wineg++ or when I compile for D3D8 and D3D9 with ming32. But when I try to compile for D3D8 with wineg++, there's a problem, since there's no d3dx8*.h nor d3dx8.dll in Wine. Is it undesirable for Wine to have d3dx8 (I remember some commits removing the library and headers related to it several years ago)? Should I just drop usage of D3DXCreateTextureFromFile and use plain IDirect3DDeviceX::CreateTexture? Also I use some matrix functions, which are identical between d3dx8 and d3dx9. Would it be OK if a wine demo would link to d3dx9 both for d3d9 and d3d8 versions of it? Or should I just reimplement all the needed functions? Regards, Ruslan

2 1

Re: d3dx10: Add D3DX10CreateEffectPoolFromFileA/W stubs.
by Matteo Bruni Aug. 5, 2016

Aug. 5, 2016

2016-08-04 11:25 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > For https://bugs.winehq.org/show_bug.cgi?id=39506 You should probably put the stubs in async.c. Looks good to me otherwise.

1 1

Re: [1/6] msvcirt: Add a partial implementation of class ostream_withassign.
by Piotr Caban Aug. 5, 2016

Aug. 5, 2016

Hi Iván, On 08/05/16 13:12, Iván Matellanes wrote: > typedef struct _ostream { > const int *vbtable; > int unknown; > -} ostream; > +} ostream, ostream_withassign; I don't think you need ostream_withassign type. You can just use ostream since the structures are identical. > /* ??0ostream@@QAE(a)PAVstreambuf@@@Z */ > /* ??0ostream@@QEAA(a)PEAVstreambuf@@@Z */ > +/* ??0ostream_withassign@@QAE(a)PAVstreambuf@@@Z */ > +/* ??0ostream_withassign@@QEAA(a)PEAVstreambuf@@@Z */ > DEFINE_THISCALL_WRAPPER(ostream_sb_ctor, 12) Calling ostream equivalents is OK in most cases. In case of constructors ostream_withassing_vtable should be used. Thanks, Piotr

2 3