September 2012 - Wine-devel

Re: gdiplus: Reuse an existing image stream in GdipImageSelectActiveFrame. Take 2.
by Vincent Povirk 28 Sep '12

28 Sep '12

Looks good, thanks.

1 0

Re: [PATCH 2/2] vbscript: Added MonthName implementation
by Marvin 28 Sep '12

28 Sep '12

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

1 0

Re: gdi32: Fixed freetype working function
by Alexandre Julliard 28 Sep '12

28 Sep '12

Сергей Мосин <svmosin(a)gmail.com> writes: > The function WineEngAddFontMemResourceEx in gdi32/fretype.c contained > strange XOR operation with some random number 0x87654321, instead of > returning the real font handle. Do you have an app that depends on this? What does it do with the handle? -- Alexandre Julliard julliard(a)winehq.org

1 0

is CreateThread(CREATE_SUSPENDED) fully functional?
by Joerg-Cyril.Hoehle＠t-systems.com 27 Sep '12

27 Sep '12

Hi, Recently I thought I found a use-case for CreateThread(CREATE_SUSPENDED). The idiom is to get the thread handle before the thread starts a life on its own. I looked at the kernel tests, http://source.winehq.org/source/dlls/kernel32/tests/thread.c#L460 However, both invocations with CREATE_SUSPENDED actually test the pair CreateThread + SuspendThread. The tests do not prove that CREATE_SUSPENDED works! They only prove that the suspend counter and perhaps SuspendThread work. a) Does Wine not support CREATE_SUSPENDED, so that the tests do the best they can? In such a case, a WARN("ignoring SUSPENDED flag, beware of race conditions\n") would be appropriate. or b) CREATE_SUSPENDED is fully supported on all platforms. Then the tests need some refinement. Thank you, Jörg Höhle

3 2

Re: [1/3] gdiplus: Move font substitution test into a separate body.
by Vincent Povirk 27 Sep '12

27 Sep '12

The series looks good to me. Very cool to have a fix for this.

1 0

Re: gdiplus: Reuse an existing image stream in GdipImageSelectActiveFrame.
by Vincent Povirk 27 Sep '12

27 Sep '12

> @@ -3898,7 +3894,7 @@ GpStatus WINGDIPAPI GdipImageSelectActiveFrame(GpImage *image, GDIPCONST GUID *d > return Ok; > } > > - IStream_Release(stream); > + IStream_Release(image->stream); > return stat; > } I don't think it's necessary to AddRef/Release the stream anymore in GdipImageSelectActiveFrame. Creating the new image and freeing the old one will update the refcount as necessary. And it's a bit confusing since technically the current image->stream is released by free_image_data then overwritten (with the same value, fortunately) by copying new_image to image. Looks good otherwise.

1 0

'sort' implementation (Bug 27933) - any easy way?
by Ann and Jason Edmeades 27 Sep '12

27 Sep '12

Hello, While working on more of the 'for' processing in the command shell, I've come across a stumbling block that wildcard expansion 'ordering' is not guaranteed (findfirst/findnext) meaning I cannot automate tests for some of the key bits - this is frustrating as we really need tests for the things I'm looking at as the code is getting complex. Looking in the cmd testsuite, there's already some commented out tests as well, saying we really need a 'sort' implementation, and that would also resolve the problem I have at the moment. Therefore, I'd like to know if there's any simple way to implement a command line sort program which we can call from the command shell. This has subsequently been raised as bug 27933. My first thought was to avoid reinventing the wheel and to have a windows program called sort which parses its parameters and then runs the Unix 'sort' command with an equivalent command line. I think most of the windows command line parameters have Unix equivalents, and for the majority of cases it would be a case of transposing a windows path to a Unix path, and just running the Unix sort. However, I then started to get concerned about stdin / stdout... Is there any way to take the windows stdin and 'connect it' to the unix program you spawn, and vica-versa for the stdout. Whilst I dont accurately need this for the testsuite, without it the wine implementation would not match the windows one. So I think my specific questions are... 1. Is wrappering an existing (Linux) 'sort' program an option for this, or do we really need a whole unique implementation of sort (which I would have no idea how to write!)? If it is an option, the two key questions I have are: 2. How do I handle stdin / stdout, so sort can work in pipes / redirects 3. Is it ok to use wine_get_unix_file_name to convert files and directories to the unix equivalents when building the unix equivalent command line? (as per winepath) Thanks. Jason

1 0

Re: d3dx9_36 [patch 6/6]: Implement D3DXSHEvalHemisphereLight
by Rico Schüller 27 Sep '12

27 Sep '12

Well I think, if you rework a series, please add something like try xyz or so ... Also try to avoid to add / remove some patches, at least if they actually don't have anything todo with the rest of the patch set (if they could be submitted on their own). On 27.09.2012 10:00, Nozomi Kodama wrote: > + TRACE("%u, %p, %p, %p, %p, %p, %p\n", order, dir, &top, &bottom, rout, gout, bout); Sure, that's an other form of the trace. I think we hadn't one with such a version... other traces in the file look like (the one marked with * is my preferred version): TRACE("out %p, order %u, a %p, b %p\n", out, order, a, b); * TRACE("(%p, %p, %u)\n", pout, pin, n); I don't think it makes much sense to print the address for &top. It doesn't gather some useful information, does it? Instead you may print the actual content for r,g,b if you like. > + if ( gout ) Also here, I prefer "if (gout)" ... I know there are several occurrences for the other style ... I should have mentioned that earlier ... it's not something which is critical... git grep "if (" dlls/d3dx9_36/* | wc -l reveals ~2000 while git grep "if ( " dlls/d3dx9_36/* | wc -l does ~100 > + ok(relative_error(expected, blue_out[j]) < admitted_error, > + "Blue: case %u, order %u: expected[%u] = %f, received %f \n", l, order, j, expected, blue_out[j]); Please indent 8 instead of 2 spaces when a new line is used ... Cheers Rico

1 0

dsound: Don't bother shrinking the secondary buffer list.
by Joerg-Cyril.Hoehle＠t-systems.com 27 Sep '12

27 Sep '12

Michael, >+#include <assert.h> your patch is already committed, yet I believe that the least that dsound needs is new asserts. Asserts in dsound have been a PITA in Wine for the last decade. It's ok for the kernel to crash in an assert. IMHO it is not ok for an optional thing like sound. The assert's backtrace will not help anybody, because the logical error will have happened much earlier. Instead, a plain ERR would have been just as telling. Let's quote http://www.winehq.org/docs/winedev-guide/debugging#DBG-CLASSES "ERR: Messages in this class indicate serious errors in Wine, such as as conditions that should never happen by design." I recommend: - assert(device->buffers[0] == pDSB); + if (pdevice->buffers[0] != pDSB) + ERR("broken device buffer %p\n", device->buffers[0]); HeapFree(GetProcessHeap(), 0, device->buffers); device->buffers = NULL; The ERR is IMHO revealing enough in a user's log. If a sound component detects a bogus state, I'd very much prefer that it disables sound -- without crashing. Regards, Jörg Höhle

2 1

Re: d3dx9_36 [patch 1/6]: Implement D3DXSHMultiply4
by Rico Schüller 27 Sep '12

27 Sep '12

On 27.09.2012 09:56, Nozomi Kodama wrote: > +FLOAT* WINAPI D3DXSHMultiply4(FLOAT *out, CONST FLOAT *a, CONST FLOAT *b) FLOAT * WINAPI D3DXSHMultiply4(FLOAT *out, const FLOAT *a, const FLOAT *b) A minor nitpick, anyone against something like? I think that was what Matteo meant in http://www.winehq.org/pipermail/wine-devel/2012-September/096924.html with "Fix the FLOAT*"? > + TRACE("(%p, %p, %p)\n", out, a, b); I would probably prefer: TRACE("out %p, a %p, b %p\n", out, a, b); I know the other Multiply functions and so on use your trace format... > + out[0] = 0.28209479f * a[0] * b[0]; There are still double spaces ... Hint: it's not the only occurrence. Cheers Rico

1 0