May 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 2/5] riched20/tests: Small test for GetClientSite()

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 https://testbot.winehq.org/JobDetails.pl?Key=13718 Your paranoid android. === w2000pro (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0042D1B0 === wxppro (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0042D1B0 === w2003std (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0042D1B0 === wvistau64 (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at A574D492 === w2008s64 (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 00000000 === w7u (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 10000000 === w8 (32 bit richole) === richole.c:1526: Test failed: got wrong pointer === wvistau64 (64 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0000000000426DF0 === w2008s64 (64 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 000007FEFEE619B8

May 31, 2015

Re: mciqtz32: Guarantees that CoInitialize and CoUninitialize run on the same thread.

by Akihiro Sagawa

Hi Jörg, Thanks for your comments. On Fri, 29 May 2015 17:50:18 +0200, Jörg Höhle wrote: > I would expect all MCI commands "STATUS POSITION" etc. to work while > another thread is busy playing a file synchronously (using MCI_WAIT). Good point. I worried about this situation. However, recent Windows systems don't allow to call MCI commands from another thread. Therefore, this case might not happen. I also considered to implement a sort of corss-thread protection like native, but that breaks compatibilities for Win9x and affects all devices. Because I'm not sure about those effects, I left the issue. Do you know the application which relies on this feature? > Furthermore > +static LRESULT MCIQTZ_relayTaskMessage [...] > + if (WaitForSingleObject(wma->task.done, INFINITE) == WAIT_OBJECT_0) > > Are you sure it's ok to block the user thread like this? Shouldn't the code use a loop > that also pumps the MS-Windows message queue and dispatches messages? > E.g. there may be a need to dispatch REFRESH and PAINT messages? Blocking is not a good idea in general. I'll update the code to do the things more asynchronously. > Did you cross-check what MS-Windows does here? I didn't check Windows behavior at that point. IMHO, MCI code doesn't assume the Window message queue and shouldn't touch them. I'll check the behavior later. > On a related note, IIRC some wine devices use a more reliable approach to waiting: > WaitForMultiple(2 objects: [task.done, task.threadId], INFINITE); > That way, should the player crash or exit somehow, the main (user) task doesn't hang. Good catch. I'll use more reliable way. Thanks, Akihiro Sagawa

May 30, 2015

mciqtz32: Guarantees that CoInitialize and CoUninitialize run on the same thread.

by Joerg-Cyril.Hoehle＠t-systems.com

Aki, if I understand your critical section well, you serialize all accesses to the individual player thread. This may be ok for commands that return immediately, e.g. STATUS, but the MCI knows commands that may take a long time, in particular PLAY, RECORD and even SEEK. Did you run a test like this: CreateTask { SetEvent started MCICommand(MCI_PLAY, "av_file_that_takes_3_minutes.avi", MCI_WAIT); } Wait(started); Repeat 10 times { MCICommand(MCI_STATUS,MCI_POSITION); printf MCICommand(MCI_STATUS,MCI_MODE); Printf Sleep(2s); } Wait(thread); I would expect all MCI commands "STATUS POSITION" etc. to work while another thread is busy playing a file synchronously (using MCI_WAIT). Furthermore +static LRESULT MCIQTZ_relayTaskMessage [...] + if (WaitForSingleObject(wma->task.done, INFINITE) == WAIT_OBJECT_0) Are you sure it's ok to block the user thread like this? Shouldn't the code use a loop that also pumps the MS-Windows message queue and dispatches messages? E.g. there may be a need to dispatch REFRESH and PAINT messages? Did you cross-check what MS-Windows does here? On a related note, IIRC some wine devices use a more reliable approach to waiting: WaitForMultiple(2 objects: [task.done, task.threadId], INFINITE); That way, should the player crash or exit somehow, the main (user) task doesn't hang. Regards, Jörg Höhle

May 29, 2015

Re: [PATCH 1/2] msvcp110: Add _File_size implementation and test.(try 2)

by YongHao Hu

Sry, Slackner found that I still used %llx /%llu as I misunderstood Piotr's comment and there are typos in the patch. I will fix all the issues later. :P On 2015年05月29日 21:16, YongHao Hu wrote: > try2: > Improve the patch according to Piotr's advices. > Add errno and SetLastError test. > --- > dlls/msvcp110/msvcp110.spec | 4 +- > dlls/msvcp120/msvcp120.spec | 4 +- > dlls/msvcp120/tests/msvcp120.c | 75 > +++++++++++++++++++++++++++++++++---- > dlls/msvcp120_app/msvcp120_app.spec | 4 +- > dlls/msvcp90/ios.c | 20 ++++++++++ > 5 files changed, 94 insertions(+), 13 deletions(-) > >

May 29, 2015

programs/regsvr32 patches

by Hugh McMaster

Excuse me, I've looked through patches 111564-111568 and have only found one minor issue. In patch 111565 I forgot to include ctype.h for tolower(). Was there a problem with the input comparison handling, or something else? The changes to the input handling make conversion to unicode much easier and cleaner. I realise that patch 111565 looks complex, but it's just the indenting. -- Hugh McMaster

May 29, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 12)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This version of the patch looks good to me. Stefan Am 2015-05-29 um 12:06 schrieb Alistair Leslie-Hughes: > Hi, Add WARN on errors. > > I'll add more tests in another patch, which simplifies the > component list. > > Changelog: dpnet: Implement IDirectPlay8Address > GetComponentByIndex > > > Best Regards Alistair Leslie-Hughes > > > > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVaE3VAAoJEN0/YqbEcdMwqIAP/iHHkRWQmGrZnoKbvuXuYJ9i caO0PB0akO3CvyLDcC68CMtT7jQ7gthTGPiXTHe4sEjmSR3KLoqajV2TX+JluWYj s/uTxbmPjNvafeXmflSpaoy0BRq5H/D+99AkKqo/GFPlCNT0UJpR9sD7OsXXA1E9 Cq7VpKMGqgnWoLf4/pRge/rBfV2vV0FOLhHTzboEyUOTgGegOI8v345vMw/Ph7RM YPEdLYUBkIwZZuZaDtaZ9DV5HyFG1fH65cYftkQFmM7tH4Sn1NiQcNHEUmPeX3Bc hv5Q9QOshwtWgQKhWe98YyGayP16Ip0iKDpxRZ28LEcOcKfK9URX66lBNWZjL/Ci IixsgZw12okh8Wn+Q76LwIh1PakpQSHZ/iQW8qDYlyWIRboFC+VyQoemkXxvUfVS VwqAe/D1uWAf1o6BD6vHNarH7A5ymHvxmcxw/1PxTGSZg4RBqOmt4/4gCWIuPXzX 564O8wrDn1msVhwS6tqpP85Sg3ydDYiPDVZNVigJAU/kMCiPH2WbXPxUGB/Pc7hA 4QaOK6FDTxXlTqEO0FHm12DU2bYzBMogOd0N6usKzVQe2kdy9hB4/hUo8+vojamS AI0agXg+a6UjVhTpNZvoZAxC0rFF6nEJaL6MgDS64LtmT6wrrri6hEtmPJM6aC/O 2bdo052EPFKWbfytsTK+ =jq9B -----END PGP SIGNATURE-----

May 29, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 12)

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 https://testbot.winehq.org/JobDetails.pl?Key=13666 Your paranoid android. === w8 (32 bit address) === Failure running script in VM: timed out waiting for the child process

May 29, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 11)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There's one major problem I missed previously: Am 2015-05-29 um 10:22 schrieb Alistair Leslie-Hughes: > + case DPNA_DATATYPE_STRING: > + memcpy(pvBuffer, &entry->data.string, entry->size); > + break; This won't work. There's a & too much. Please consider adding tests for String and Binary types to catch this kind of thing. GetComponentByName once had the same problem I believe. Minor stuff: > + TRACE("(%p)->(%d %p %p %p %p %p)\n", This, dwComponentID, pwszName, pdwNameLen, pvBuffer, pdwBufferSize, pdwDataType); pdwNameLen, pvBuffer, pdwBufferSize, pdwDataType); A DWORD is unsigned, %u is better. > + if(*pdwBufferSize < entry->size || *pdwNameLen < namesize) > + { > + *pdwNameLen = namesize + 1; > + *pdwBufferSize = entry->size; > + *pdwDataType = entry->type; > + return DPNERR_BUFFERTOOSMALL; > + } You forgot to add a WARN here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVaCrwAAoJEN0/YqbEcdMwypEP/RttOLSqc6fQQW4XeMkBgVaS aiKUyYSysq9MnRoqP32A6lKq9LHpW23liKsvpwoWegdarTc35ENYwG7pLSLJuOIy i/e7AlWGLDphN9qdYMU0oCQ8PXGU8Y3Mb7kozZcnYm9EuYoJEFIiAYHtx4nFeGMj rVx/mruLmYTdgyR378iE4cYqNeMwzK7YtGNRHMPz8FNTzdLyzUu1blYQ8cYEbzAk Mm4RaIixByzKiGO7qUPCX4OOgYoohBOgMRiVWTJfZLrhKY0vyj0x2Jt5GWCzWeht 7mszNRRpvW+v60axT2xwemXmQSobjgjnddF0bwxC/vHZisfXF8H52lLgupXv9KRo efOsvX3lTpJstEL1Wt61NL/MqF4vwRjbrWeKD45DxHEzPX8wzUg4yFodz/yxAAN1 /l4fuX8BEjr9tttV4uup4fdOlVhlX95ZujQFT5Ue1zF97SSLOC9id/8Uy8xlHYmY Ou0H9GG5rILqG5+r9m3OghjuQcwomL6T7BSLYJ+WncdTgtxRbarhMI/mq9m0MiB2 OHkUddm/zn9EFPboQsCjqRuPFa6fcbx+b/XUmyLeBjosO3j7Otws4TGUEkzjbvWF f3fOORfbxpknZH9GxVaEFWlyUerNSJ4C4hYp5J+pHS9N5u+L9KsN0fXYT9jqpvh2 Tmu94XyHSblAoeS1ORgq =M5Sz -----END PGP SIGNATURE-----

May 29, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 11)

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 https://testbot.winehq.org/JobDetails.pl?Key=13665 Your paranoid android. === w8 (32 bit address) === The test timed out

May 29, 2015

Re: [PATCH 5/5] wined3d: Always enable GL_PROGRAM_POINT_SIZE in the GLSL backend.

by Henri Verbeet

On 28 May 2015 at 23:53, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > It's not shared but it should already be executed for each context > (the flag is stored in struct wined3d_context). I may have been a bit too quick to write a reply. :) > It would be surprising to me if that additional flag check has any > performance impact since it is next to ctx_data->glsl_program which is > accessed anyway just a bit later. Yeah, I suppose, although it still seems better to not add unnecessary code in that path. Something similar applies to struct vs_compile_args, the two extra BOOLs probably don't hurt too much, but it seems better to merge them with "clip_enabled" as flags.

May 29, 2015