December 2012 - Wine-devel - list.winehq.org

Re: [PATCH 1/3] atl: Allow version-based differences in struct layouts
by Marvin 10 Dec '12

10 Dec '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=23310 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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH] ntdll/tests: Accept larger SYSTEM_CACHE_INFORMATION on win8
by Marvin 10 Dec '12

10 Dec '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=23306 Your paranoid android. === W2KPROSP4 (32 bit info) === info.c:515: Test failed: Inconsistent length 0 info.c:522: Test failed: Expected STATUS_SUCCESS, got c0000004 info.c:527: Test failed: Expected STATUS_SUCCESS, got c0000004 info.c:532: Test failed: Inconsistent length 36 === WXPPROSP3 (32 bit info) === info.c:515: Test failed: Inconsistent length 0 info.c:522: Test failed: Expected STATUS_SUCCESS, got c0000004 info.c:527: Test failed: Expected STATUS_SUCCESS, got c0000004 info.c:532: Test failed: Inconsistent length 36 === W2K3R2SESP2 (32 bit info) === info.c:515: Test failed: Inconsistent length 0 info.c:522: Test failed: Expected STATUS_SUCCESS, got c0000004 info.c:527: Test failed: Expected STATUS_SUCCESS, got c0000004 info.c:532: Test failed: Inconsistent length 36 === WVISTAADM (32 bit info) === info.c:515: Test failed: Inconsistent length 12 info.c:532: Test failed: Inconsistent length 36 === W2K8SE (32 bit info) === info.c:515: Test failed: Inconsistent length 12 info.c:532: Test failed: Inconsistent length 36 === W7PRO (32 bit info) === info.c:515: Test failed: Inconsistent length 12 info.c:532: Test failed: Inconsistent length 36 === W7PROX64 (32 bit info) === info.c:515: Test failed: Inconsistent length -16 info.c:523: Test failed: Inconsistent length 36 info.c:528: Test failed: Inconsistent length 36 info.c:532: Test failed: Inconsistent length 36 === TEST64_W7SP1 (32 bit info) === info.c:515: Test failed: Inconsistent length -16 info.c:523: Test failed: Inconsistent length 36 info.c:528: Test failed: Inconsistent length 36 info.c:532: Test failed: Inconsistent length 36 === W7PROX64 (64 bit info) === info.c:532: Test failed: Inconsistent length 64 === TEST64_W7SP1 (64 bit info) === info.c:532: Test failed: Inconsistent length 64

1 0

[PATCH] dsound: Use event based threads
by Joerg-Cyril.Hoehle＠t-systems.com 10 Dec '12

10 Dec '12

Hi, Maarten Lankhorst queried: >Bump, anything wrong with this patch? Here's my 0.0$ ... (standard DSound disclaimer here...) Using mmdevapi's events in DSound is basically TRT. Then, the DSound mixer will be synchronized with mmdevapi writes. >+ /* ALSA is retarded, add a timeout.. */ >+ ret = WaitForSingleObject(dev->sleepev, dev->sleeptime); How does that comment help the reader of the code? >+ if (period_ms <= 15) >+ device->sleeptime = period_ms * 5 / 2; >+ else >+ device->sleeptime = period_ms * 3 / 2; I expect such threshold functions to be continuous or at least monotonic. A sawtooth is certainly unexpected. What is its purpose? What I would understand is a comment in the code saying that as of 2012, all 3 wine*.drv mmdevapi drivers have a bug that they stop sending events after IAudioClient_Stop. Therefore add a short timeout to the wait. If that's the reason for the timeout, then period_ms * 1.5 is perfectly fine. There's no reason for a particular threshold. Note that neither 1.5 nor 2.5 give you regular spacing around the time of transition from playing to stopped. + IAudioClient_GetStreamLatency(device->client, &period); + period_ms = (period + 9999) / 10000; If IAC_Stop is the reason for the sleep time out, then it's obvious that GetStreamLatency has no business here, rather than the device period. I could understand a use of GetStreamLatency when it comes to computing a reasonable size of the primary buffer. + ret = WaitForSingleObject(dev->sleepev, dev->sleeptime); + ... if (ret) WaitFor* return values are defined in terms of WAIT_OBJECT_0, WAIT_TIMEOUT and WAIT_FAILED etc., not zero or non-zero. >+ device->sleepev = CreateEventW(0, 0, 0, 0); >+ device->thread = CreateThread(0, 0, DSOUND_mixthread, device, 0, 0); I haven't checked the overall style of DSound, but I prefer FALSE and TRUE be used for things advertised as BOOL. (I tend to write NULL for null pointer initialisation. Note that I easily read "if (foo) ..." for boolean and pointer types; I don't expect "if (foo == TRUE) or (foo != NULL) ...") BTW, I still believe that mixing and resampling would find their best place in mmdevapi, not DSound. Regards, Jörg Höhle

3 5

Re: msi: Fix logical expressions that always evaluate to FALSE
by Hans Leidekker 10 Dec '12

10 Dec '12

On Sat, 2012-12-08 at 21:59 +0000, Andrew Talbot wrote: > diff --git a/dlls/msi/action.c b/dlls/msi/action.c > index 076d1b3..677a43f 100644 > --- a/dlls/msi/action.c > +++ b/dlls/msi/action.c > @@ -6763,7 +6763,7 @@ static UINT ACTION_RemoveODBC( MSIPACKAGE *package ) > #define ENV_MOD_PREFIX 0x80000000 > #define ENV_MOD_MASK 0xC0000000 > > -#define check_flag_combo(x, y) ((x) & ~(y)) == (y) > +#define check_flag_combo(x, y) ((x) & (y)) == (y) > > static UINT env_parse_flags( LPCWSTR *name, LPCWSTR *value, DWORD *flags ) > { It makes the tests fail here: err:msi:env_parse_flags Invalid flags: 00000007 err:msi:ITERATE_Actions Execution halted, action L"RemoveEnvironmentStrings" returned 1627 err:msi:env_parse_flags Invalid flags: 00000007 action.c:5899: Test failed: Expected ERROR_SUCCESS, got 1627 action.c:5905: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 action.c:5908: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 action.c:5920: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 I'd suggest to simply remove these checks.

1 0

Re: [PATCH 1/4] kernel32: Support UTF-7 in MultiByteToWideChar.
by Dmitry Timoshkov 09 Dec '12

09 Dec '12

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > I came back to the problem of UTF-7 support and made some improvements > to my previous submission. The tests are now more stringent, especially > in regard to null terminator checking, and they test the srclen > parameter more thoroughly now as well. > > I also noticed that a related test for error checking was marked > todo_wine. The fix was trivial and is included as a fourth patch. > > Please let me know what you think. I'm willing to put some more effort > into this. Why don't you put it in libs/wine where other unicode conversion routines are implemented? Also you probably need to add support for composition/ surrogates like other implementations do. -- Dmitry.

5 12

Re: [PATCH 4/6] server: Store and return security attributes with extended file attributes (try 5).
by Anssi Hannula 09 Dec '12

09 Dec '12

Hi, 27.11.2012 00:45, Erich E. Hoover kirjoitti: > This patch adds the ability to store and retrieve the security > attributes of a file by turning them into extended file attributes (if > available). These attributes are stored in the attribute > "user.WINEACL" in the form: > <ACE1>;<ACE2>;...;<ACEN> > where each ACE takes the form: > <Type>,<Flags>,<Mask>,<SID> > With this information it is possible to more accurately store the ACL > information files, and also allows patch 5 to tell whether it's > necessary for an ACL to be inherited by a contained file in a folder. I don't see the need for an uppercase "WINEACL" in the attribute name, especially since all the examples in e.g. attr(5) are lowercase. Moreover, [1] recommends using application specific namespaces in the attribute name, so IMHO a better attribute name would be "user.wine.acl". </bikeshedding> Thanks for your work on this :) [1] http://www.freedesktop.org/wiki/CommonExtendedAttributes -- Anssi Hannula

2 2

Re: [2/3] xmllite: Support comment nodes
by Marvin 09 Dec '12

09 Dec '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=23296 Your paranoid android. === W7PROX64 (64 bit reader) === reader.c:571: Test failed: Expected S_OK, got 80070057 Timeout === TEST64_W7SP1 (64 bit reader) === reader.c:571: Test failed: Expected S_OK, got 80070057 Timeout

1 0

Re: [1/3] xmllite: Track internal parser state to select expected node type
by Marvin 09 Dec '12

09 Dec '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=23295 Your paranoid android. === W7PROX64 (64 bit reader) === reader.c:571: Test failed: Expected S_OK, got 80070057 Timeout === TEST64_W7SP1 (64 bit reader) === reader.c:571: Test failed: Expected S_OK, got 80070057 Timeout

1 0

Re: [PATCH] gdi32: Don't enumerate fonts when OpenFontFace fails (try 2).
by Alexandre Julliard 07 Dec '12

07 Dec '12

Qian Hong <fracting(a)gmail.com> writes: > dlls/gdi32/freetype.c | 17 +++++++++++------ > 1 file changed, 11 insertions(+), 6 deletions(-) It's causing a test failure: ../../../tools/runtest -q -P wine -M gdiplus.dll -T ../../.. -p gdiplus_test.exe.so font.c && touch font.ok font.c:400: Test failed: Expected 0, got 3 font.c:401: Test failed: got NULL font collection make[1]: *** [font.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 3/3] msxml3: Tests code clean up
by Marvin 07 Dec '12

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

1 0