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

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

Dec. 10, 2012

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 Dec. 10, 2012

Dec. 10, 2012

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 Dec. 10, 2012

Dec. 10, 2012

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 Dec. 10, 2012

Dec. 10, 2012

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 Dec. 10, 2012

Dec. 10, 2012

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 Dec. 9, 2012

Dec. 9, 2012

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 Dec. 9, 2012

Dec. 9, 2012

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 Dec. 9, 2012

Dec. 9, 2012

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 Dec. 7, 2012

Dec. 7, 2012

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 Dec. 7, 2012

Dec. 7, 2012

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

Re: [PATCH 2/3] msxml3: Added URL validation tests
by Marvin Dec. 7, 2012

Dec. 7, 2012

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

1 0

Re: [PATCH] gdi32: Don't enumerate font when OpenFontFace fails.
by Dmitry Timoshkov Dec. 6, 2012

Dec. 6, 2012

Qian Hong <fracting(a)gmail.com> wrote: > - GetEnumStructs( face, &elf, &ntm, &type ); > + if (!get_enum_structs( face, &elf, &ntm, &type )) return FALSE; > free_family( family ); 'face' and 'family' are leaked here. Also returning FALSE at this point is too late since both 'face' and 'family' are already in the linked lists. -- Dmitry.

2 2

Re: [1/2] schannel/tests: Fix test on win8
by Hans Leidekker Dec. 6, 2012

Dec. 6, 2012

On Thu, 2012-12-06 at 12:56 +0100, André Hentschel wrote: > diff --git a/dlls/schannel/tests/main.c b/dlls/schannel/tests/main.c > index b576848..9c28e8b 100644 > --- a/dlls/schannel/tests/main.c > +++ b/dlls/schannel/tests/main.c > @@ -179,8 +179,8 @@ static void testGetInfo(void) > /* First package: Unified */ > status = pTables->GetInfo(&PackageInfo); > ok(status == STATUS_SUCCESS, "status: 0x%x\n", status); > - ok(PackageInfo.fCapabilities == 0x107b3, "fCapabilities: 0x%x\n", > - PackageInfo.fCapabilities); > + ok((PackageInfo.fCapabilities & ~SECPKG_FLAG_APPCONTAINER_PASSTHROUGH) == 0x107b3, > + "fCapabilities: 0x%x\n", PackageInfo.fCapabilities); > ok(PackageInfo.wVersion == 1, "wVersion: %d\n", PackageInfo.wVersion); > ok(PackageInfo.wRPCID == 14, "wRPCID: %d\n", PackageInfo.wRPCID); > ok(PackageInfo.cbMaxToken == 0x4000 || A nicer fix would be to use a disjunction of or-ed symbolic constants, just like the negotiate test.

1 0

[3/4] gdiplus: Always use AlphaBlend to draw to 32-bit DIB's.
by Vincent Povirk Dec. 5, 2012

Dec. 5, 2012

1 0

Re: [PATCH] winmm: Don't mask out SND_ALIAS_ID or SND_FILENAME in sndPlaySound
by Dmitry Timoshkov Dec. 5, 2012

Dec. 5, 2012

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > + br = sndPlaySoundA((LPCSTR)SND_ALIAS_SYSTEMASTERISK, SND_ALIAS_ID|SND_SYNC); > + ok(br == TRUE || br == FALSE, "sndPlaySound gave strange return: %u\n", br); This kind of test is broken. -- Dmitry.

3 9

Re: testbot/build: Chdir to the Wine source directory before calling 'git apply'.
by Henri Verbeet Dec. 5, 2012

Dec. 5, 2012

On 5 December 2012 05:35, Francois Gouget <fgouget(a)codeweavers.com> wrote: > The --directory option is not meant to specify where the Git repository lives. > --- > > I'm not sure how it worked before. Maybe this use of the --directory > option worked by chance but git changed and broke it. > Alternatively you could set GIT_DIR, although I'm not quite familiar enough with the code to know if there's a reason to prefer one over the other.

1 0

d3dx9_36 [patch 1/3]: Implement D3DXSHEvalHemisphereLight
by Nozomi Kodama Dec. 5, 2012

Dec. 5, 2012

Hello any problems with the patches http://source.winehq.org/patches/data/91986 http://source.winehq.org/patches/data/91985 http://source.winehq.org/patches/data/91984 Best regards, Nozomi

2 1

Re: [2/3] gdiplus: If a 32-bit dib is selected in an hdc, use the dib directly.
by Alexandre Julliard Dec. 4, 2012

Dec. 4, 2012

Vincent Povirk <madewokherd(a)gmail.com> writes: > @@ -2264,6 +2266,41 @@ GpStatus WINGDIPAPI GdipCreateFromHDC2(HDC hdc, HANDLE hDevice, GpGraphics **gra > if(graphics == NULL) > return InvalidParameter; > > + hbm = GetCurrentObject(hdc, OBJ_BITMAP); > + if (hbm && GetObjectW(hbm, sizeof(dib), &dib) && dib.dsBm.bmBitsPixel == 32) > + { > + /* Make a bitmap object so we can use the alpha channel */ > + GpBitmap *bitmap; > + DWORD height, stride; > + BYTE *bits; > + > + height = abs(dib.dsBmih.biHeight); > + stride = dib.dsBmih.biWidth * 4; > + > + if(dib.dsBmih.biHeight > 0) /* bottom-up */ > + { > + bits = (BYTE*)dib.dsBm.bmBits + (height - 1) * stride; > + stride = -dib.dsBmih.biWidth * 4; > + } > + else > + bits = dib.dsBm.bmBits; > + > + retval = GdipCreateBitmapFromScan0(dib.dsBmih.biWidth, height, stride, > + PixelFormat32bppPARGB, bits, &bitmap); This won't work, you won't get a negative height with GetObject, and you won't get DIB info at all for DDBs. Also not all DIBs are in PARGB format. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: mshtml: Added support for converting (some) argument types in builtin function calls using script engine
by Marvin Dec. 4, 2012

Dec. 4, 2012

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=23216 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

2 1

Re: DSound/winepulse review
by Maarten Lankhorst Dec. 4, 2012

Dec. 4, 2012

Added wine-devel to cc Op 26-10-12 13:12, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > Maarten, > > I'll try and come up with a review of your winepulse patches yet I'm not familiar with the PA API. > > Regarding your dsound ones, I'm sorry I've not enough experience > with the DSound API to be really useful. I was happy that Alexey Loukianov and A.Eikum > worked on DSound. > > One issue that struck me is the 5ms period downgrade in winepulse. > I advise you keep that as a separate patch. Halving the externally visible SetEVentHandle rate > is certainly not something that should be in the one big core patch introducing winepulse. Yeah this was explicitly to make skyrim work better, I return the updated latency in GetStreamLatency, and with the fixes wine dsound uses that value for calculating mixing fraglen. > Even if it causes no test failure, that trick would certainly be visible in the log lines. Native shows: > render.c:2084: Should play 1000ms continuous tone with fragment size 480. > render.c:2136: Released 48000=100x480 -960 frames at 48000 worth 980ms in 1008ms Yeah I seem to fire more events, so less data gets played. This requires some rethinking though, winepulse doesn't attempt to hide latency at all, and so far the mmdevapi tests have failed on my usb headphones because it didn't always have a smooth buffer increment. The tests don't fail, but because of the extra firing processing sometimes gets skipped.. Woops, some more digging revealed I also seemed to have done a SetEvent in pulse_started_callback, which is entirely bogus, presumably a leftover from before I hooked up the latency callback for when in underrun mode. With that SetEvent part of the latency hack disabled and the bogus SetEvent removed, I get: render.c:2127: Released 44541=101x441 -441 frames at 44100 worth 1000ms in 1003ms Can't get better than that. :-) I disabled the exclusive mode on winepulse because I felt that mode was sufficiently different in behavior, and I don't think the mmdevapi tests cover it properly. I'll do some more digging if the SetEvent is still needed for the hack, or if the period lowering is enough. I would suspect lowering the period is sufficient now. Quick testing of skyrim seems to indicate I can leave the SetEvent part out, so I pass all tests properly again. :-) > BTW, I'd still be pleased if you could upload somewhere to bugzilla results from > runtest -v -i mmdevapi/render and capture > from your winepulse driver. I think I asked you that favour already but found nothing. My tree removes todo_wine from the tests, but anyway: capture.c:501: Returned periods: 10.0000 ms 0.4988 ms capture.c:513: pwfx: 0xdccb0 capture.c:514: Tag: fffe capture.c:515: bits: 32 capture.c:516: chan: 2 capture.c:517: rate: 44100 capture.c:518: align: 8 capture.c:519: extra: 22 capture.c:524: Res: 32 capture.c:525: Mask: 3 capture.c:526: Alg: FLOAT capture.c:585: Returned latency: 10.0000 ms capture.c:185: Wait'ed position 0 pad 0 flags 0, amount of frames locked: 441 capture.c:247: Sleep.1 position 441 pad 15435 flags 0, amount of frames locked: 441 capture.c:291: GetBufferSize 22050 period size 441 capture.c:301: Overrun position 1323 pad 22050 flags 1, amount of frames locked: 441 capture.c:328: Cont'ed position 1764 pad 21609 flags 0, amount of frames locked: 441 capture.c:352: Restart position 2205 pad 21168 flags 0, amount of frames locked: 441 capture.c:383: Reset position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:409: Running position 23373 pad 7938 flags 0, amount of frames locked: 441 capture: 255 tests executed (0 marked as todo, 0 failures), 0 skipped. render.c:185: Returned periods: 10.0000 ms 2.0000 ms render.c:197: pwfx: 0xdccb0 render.c:198: Tag: fffe render.c:199: bits: 32 render.c:200: chan: 6 render.c:201: rate: 48000 render.c:202: align: 24 render.c:203: extra: 22 render.c:208: Res: 32 render.c:209: Mask: 3f render.c:210: Alg: FLOAT render.c:268: Initialize(duration=0) GetBufferSize is 192 render.c:333: Returned latency: 10.0000 ms render.c:411: IsSupported(shared , 8000x 8x1) render.c:411: IsSupported(shared , 8000x 8x2) render.c:411: IsSupported(shared , 8000x16x1) render.c:411: IsSupported(shared , 8000x16x2) render.c:411: IsSupported(shared , 11025x 8x1) render.c:411: IsSupported(shared , 11025x 8x2) render.c:411: IsSupported(shared , 11025x16x1) render.c:411: IsSupported(shared , 11025x16x2) render.c:411: IsSupported(shared , 12000x 8x1) render.c:411: IsSupported(shared , 12000x 8x2) render.c:411: IsSupported(shared , 12000x16x1) render.c:411: IsSupported(shared , 12000x16x2) render.c:411: IsSupported(shared , 16000x 8x1) render.c:411: IsSupported(shared , 16000x 8x2) render.c:411: IsSupported(shared , 16000x16x1) render.c:411: IsSupported(shared , 16000x16x2) render.c:411: IsSupported(shared , 22050x 8x1) render.c:411: IsSupported(shared , 22050x 8x2) render.c:411: IsSupported(shared , 22050x16x1) render.c:411: IsSupported(shared , 22050x16x2) render.c:411: IsSupported(shared , 44100x 8x1) render.c:411: IsSupported(shared , 44100x 8x2) render.c:411: IsSupported(shared , 44100x16x1) render.c:411: IsSupported(shared , 44100x16x2) render.c:411: IsSupported(shared , 48000x 8x1) render.c:411: IsSupported(shared , 48000x 8x2) render.c:411: IsSupported(shared , 48000x16x1) render.c:411: IsSupported(shared , 48000x16x2) render.c:411: IsSupported(shared , 96000x 8x1) render.c:411: IsSupported(shared , 96000x 8x2) render.c:411: IsSupported(shared , 96000x16x1) render.c:411: IsSupported(shared , 96000x16x2) render.c:2174: Output to a MS-DOS console is particularly slow and disturbs timing. render.c:2175: Please redirect output to a file. render.c:870: Testing shared mode render.c:902: Latency: 10.0000 ms render.c:921: BufferSize 24000 estimated fragment 480 x 50 = 24000 render.c:945: Clock Frequency 1152000 render.c:974: data at 0x530030 render.c:1023: padding 14302 past sleep #2 render.c:1042: padding 14302 position 232752 past stop #2 render.c:1076: data at 0x530030 render.c:1100: position 115416 past 100ms sleep #3 render.c:1117: padding 18711 position 126936 past stop #3 render.c:1145: data at 0x530030 for prefill 22500 render.c:1175: hpctime 381 after 370ms render.c:1194: hpctime 481 pcpos 492 render.c:1199: padding 1250 position 510000/21250 slept 470ms iteration 0 render.c:1227: data at 0x530030 render.c:1194: hpctime 589 pcpos 599 render.c:1199: padding 18551 position 634776/26449 slept 570ms iteration 1 render.c:1232: data at 0x530030 (small 5449) render.c:1194: hpctime 691 pcpos 701 render.c:1199: padding 19321 position 747072/31128 slept 670ms iteration 2 render.c:1232: data at 0x530030 (small 4679) render.c:1194: hpctime 793 pcpos 803 render.c:1199: padding 18727 position 873624/36401 slept 770ms iteration 3 render.c:1232: data at 0x530030 (small 5273) render.c:1194: hpctime 895 pcpos 905 render.c:1199: padding 19089 position 991488/41312 slept 870ms iteration 4 render.c:1232: data at 0x530030 (small 4911) render.c:1194: hpctime 996 pcpos 1007 render.c:1199: padding 19279 position 1104792/46033 slept 970ms iteration 5 render.c:1232: data at 0x530030 (small 4721) render.c:1194: hpctime 1098 pcpos 1109 render.c:1199: padding 18961 position 1225728/51072 slept 1070ms iteration 6 render.c:1232: data at 0x530030 (small 5039) render.c:1194: hpctime 1200 pcpos 1211 render.c:1199: padding 19326 position 1337904/55746 slept 1170ms iteration 7 render.c:1232: data at 0x530030 (small 4674) render.c:1194: hpctime 1302 pcpos 1312 render.c:1199: padding 18970 position 1458624/60776 slept 1270ms iteration 8 render.c:1232: data at 0x530030 (small 5030) render.c:1248: position 1458624 render.c:1257: position 2034624 past underrun, 0 padding left, 84776 frames written render.c:1279: hpctime 2304 after underrun render.c:882: Testing exclusive mode at 48000 render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1002ms render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1004ms render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -960 frames at 48000 worth 990ms in 1003ms render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1007ms render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1002ms render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1005ms render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -960 frames at 48000 worth 990ms in 997ms render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -960 frames at 48000 worth 990ms in 999ms render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -330 frames at 48000 worth 1003ms in 1009ms render.c:2075: Should play 1000ms continuous tone with fragment size 480. render.c:2127: Released 48480=101x480 -960 frames at 48000 worth 990ms in 1003ms render: 4996 tests executed (0 marked as todo, 0 failures), 0 skipped. Sometimes up to 2 tests fail due to position updates not being regular, as you can see from this line: render.c:2127: Released 48480=101x480 -330 frames at 48000 worth 1003ms in 1009ms I suspect this is because it's nearly done playing though, but it can get worse when you use usb headphones, not much I can do about that though, except if I started lying, but it's so far been much simpler when I don't.. Exclusive mode tests aren't done, I disabled exclusive mode because I felt tests were insufficient. If you can point me to an application using it I'll work on it though, but I didn't feel mmdevapi tests were complete enough for handling this. *BONUS* My favorite capture results (a2dp phone as "microphone"): capture.c:501: Returned periods: 135.2834 ms 135.2834 ms capture.c:513: pwfx: 0xdccb0 capture.c:514: Tag: fffe capture.c:515: bits: 32 capture.c:516: chan: 2 capture.c:517: rate: 44100 capture.c:518: align: 8 capture.c:519: extra: 22 capture.c:524: Res: 32 capture.c:525: Mask: 3 capture.c:526: Alg: FLOAT capture.c:585: Returned latency: 135.2834 ms capture.c:168: Test failed: Waiting on event handle failed! capture.c:185: Wait'ed position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:217: Test failed: GetNextPacketSize 0 vs. GCP 0 capture.c:220: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001 capture.c:247: Sleep.1 position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:286: Test failed: GetNextPacketSize 0 vs. GetDevicePeriod 5966 capture.c:291: GetBufferSize 23864 period size 5966 capture.c:299: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001 capture.c:301: Overrun position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:326: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001 capture.c:328: Cont'ed position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:347: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001 capture.c:352: Restart position -559038737 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:354: Test failed: restarted GCP 0 capture.c:383: Reset position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:408: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001 capture.c:409: Running position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:426: Test failed: Wait(event) after Stop gave 102 capture.c:434: Test failed: Wait(event) after Reset gave 102 capture.c:440: Test failed: Wait(NULL event) gave 102 capture: 224 tests executed (0 marked as todo, 12 failures), 0 skipped. I love this one because it shows that when you have a source that's not capturing, winepulse still gets the correct results. Even though obviously the tests completely fail because there's no data. ;-) ~Maarten

2 3

Re: [PATCH 1/5] [WineHelp]: added basic infrastructure for a new wineconsole mode: line
by Frédéric Delanoy Dec. 4, 2012

Dec. 4, 2012

On Mon, Dec 3, 2012 at 10:12 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > diff --git a/programs/wineconsole/line.c b/programs/wineconsole/line.c > new file mode 100644 > index 0000000..4b7fd29 > --- /dev/null > +++ b/programs/wineconsole/line.c > @@ -0,0 +1,334 @@ > +/* > + * a GUI application for displaying a console > + * Line back end > + * > + * Copyright 2002 Eric Pouech Guess that should be 2012 ;) Frédéric

1 0

Re: wshom: Basic support for REG_SZ values in RegRead() (try2)
by Jacek Caban Dec. 4, 2012

Dec. 4, 2012

Hi Nikolay, On 12/04/12 10:33, Nikolay Sivov wrote: > + if (name[len] != '\\') > + return HRESULT_FROM_WIN32(ERROR_PATH_NOT_FOUND); > + /* skip '\' after root name */ > + len++; > + > + /* at this point we have at least one '\' in path */ > + val = strrchrW(name, '\\'); > + keyname = SysAllocStringLen(&name[len], val-&name[len]); It's better, but now if there is only one backslash, you will have val-&name[len] == -1. Thanks, Jacek

1 0

Re: wshom: Basic support for REG_SZ values in RegRead()
by Jacek Caban Dec. 4, 2012

Dec. 4, 2012

Hi Nikolay, On 12/03/12 12:29, Nikolay Sivov wrote: > + /* skip '\' after root name */ > + if (name[len] == '\\') len++; It looks like if name[len] != '\\', then name should be considered invalid. > + > + val = strlenW(name); > + while (name[--val] != '\\' && val) > + ; > + keyname = SysAllocStringLen(&name[len], val-len); This won't work if name has no backslashes. > + /* skip leading '\' */ > + val++; > + > + type = REG_NONE; > + datalen = 0; > + ret = RegGetValueW(root, keyname, &name[val], RRF_RT_ANY, &type, NULL, &datalen); > + if (ret == ERROR_SUCCESS) > + { > + if (type == REG_SZ) > + { > + V_VT(value) = VT_BSTR; > + V_BSTR(value) = SysAllocStringLen(NULL, datalen-1); > + ret = RegGetValueW(root, keyname, &name[val], RRF_RT_ANY, &type, V_BSTR(value), &datalen); > + } > + else > + FIXME("type %d not handled\n", type); This should return an error. Jacek

2 1

Re: [PATCH] ddraw: Create a dynamic buffer if DDLOCK_DISCARDCONTENTS is used
by Rico Schüller Dec. 4, 2012

Dec. 4, 2012

On 03.12.2012 23:11, Stefan Dösinger wrote: > + DWORD pool = buffer->Caps & D3DVBCAPS_SYSTEMMEMORY ? WINED3D_POOL_SYSTEM_MEM : WINED3D_POOL_DEFAULT; ... > + return wined3d_buffer_create_vb(buffer->ddraw->wined3d_device, > + buffer->size, usage, pool, buffer, &ddraw_null_wined3d_parent_ops, > + wined3d_buffer); Is there a reason why you don't use "enum wined3d_pool" for pool? Cheers Rico

1 0

Re: [3/3] gdiplus: Bitmaps created from a 32-bit dib should be PARGB.
by Dmitry Timoshkov Dec. 4, 2012

Dec. 4, 2012

Vincent Povirk <madewokherd(a)gmail.com> wrote: > case 32: > - format = PixelFormat32bppRGB; > + if (bm.bmBits) > + format = PixelFormat32bppPARGB; > + else > + format = PixelFormat32bppRGB; Besides the test failure, to my eyes format = bm.bmBits ? PixelFormat32bppPARGB : PixelFormat32bppRGB; looks shorter and clearer. -- Dmitry.

2 1