August 2011 - Wine-devel - list.winehq.org

The state of IDirectSoundBuffer
by Michael Stefaniuc 29 Aug '11

29 Aug '11

Hello guys, my tests: - http://source.winehq.org/patches/data/78080 - http://winetestbot.winehq.org/JobDetails.pl?Key=13790 - http://winetestbot.winehq.org/JobDetails.pl?Key=13791 - http://winetestbot.winehq.org/JobDetails.pl?Key=13792 - http://winetestbot.winehq.org/JobDetails.pl?Key=13793 show that native dsound has only one IDirectSoundBuffer implementation. That shouldn't matter as per the COM rules that is an implementation detail but there are broken apps out there (http://bugs.winehq.org/show_bug.cgi?id=28207) that rely on that fact. Not sure how many of the crashes due to dsound http://bugs.winehq.org/buglist.cgi?cmdtype=runnamed&namedcmd=dsound can be traced to that as PrimaryBufferImpl and IDirectSoundBufferImpl had (before my dsound changes) only the first three fields in common. Well PrimaryBufferImpl has only three fields as it stores its info in its parent object aka the device (this is a very common "design" in our dsound). Keeping the two objects/implementations in sync is brittle and will litter the code. Thus my goal is to merge PrimaryBufferImpl into IDirectSoundBufferImpl. My plan of battle is (to keep the patches small and limit the scope of the regressions I'll introduce during this): - Make the primary buffer use struct IDirectSoundBufferImpl. - Move fields that belong to the primary buffer out of struct DirectSoundDevice. The structs DirectSoundDevice and IDirectSoundBufferImpl share quite a few fields. - For methods that have the same implementation I'll use the IDirectSoundBufferImpl_<Method> - Methods that differ considerably between primary and secondary buffer I'll make IDirectSoundBufferImpl_<Method> just a wrapper that calls out into the respective implementation, something along the lines of: if(is_primary) return primarybuffer_<method>(...); else return secondarybuffer_<method>(...); - Once all methods are converted I'll switch the primary buffer to use the same vtbl. - Profit! Comments? bye michael

2 1

Re: crytpui/tests: Add tests for CryptUIDlgSelectCertificateA.
by Marvin 29 Aug '11

29 Aug '11

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=13801 Your paranoid android. === W7PROX64 (64 bit cryptui) === cryptui.c:806: Test failed: expected ERROR_SUCCESS, got 80070057 cryptui.c:840: Test failed: expected ERROR_SUCCESS, got 80070057 cryptui.c:846: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:857: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:869: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:871: Test failed: display callback was not called cryptui.c:873: Test failed: the dialog box did not display certificate cryptui.c:879: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:881: Test failed: display callback was not called cryptui.c:891: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:899: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:901: Test failed: TabCtrl_SetCurSel returned -559038737

1 0

re: kernel32: Add UDF support Based on Steven Wallace work. Should fix the wine side of bug #26273
by Dan Kegel 29 Aug '11

29 Aug '11

Fails tests here? ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so volume.c && touch volume.ok fixme:volume:DefineDosDeviceW (0x00000000,L"a:",L"Z:\\home\\dank\\wineslave.dir\\sandbox\\slave\\runtests\\build\\dlls\\kernel32\\tests") DDD_RAW_TARGET_PATH flag not set, not supported yet volume.c:105: Tests skipped: can't test removing fake drive fixme:volume:GetVolumeNameForVolumeMountPointW Mounted Folders are not yet supported volume.c:359: Test failed: GetVolumeInformationA root failed, last error 66 volume.c:401: Test failed: GetVolumeInformationA with \ failed, last error 66 volume.c:423: Test failed: GetVolumeInformationA failed, last error 66 volume.c:434: Test failed: GetVolumeInformationA failed, last error 66 volume.c:445: Test failed: GetVolumeInformationA failed, root=C:\, last error=66 volume.c:451: Test failed: GetVolumeInformationA did fail, root=\\?\C:\, last error=66 volume.c:458: Test failed: GetVolumeInformationA did fail, root=\\.\C:\, last error=66 volume.c:486: Test failed: GetVolumeInformationA failed, root=\\?\Volume{00000000-0000-0000-0000-000000000043}\, last error=66 fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS Command exited with non-zero status 8 0.02user 0.04system 0:00.09elapsed 80%CPU (0avgtext+0avgdata 22992maxresident)k 0inputs+0outputs (0major+5625minor)pagefaults 0swaps make[1]: *** [volume.ok] Error 8

2 1

Cmd tests timeout and splitting tests
by Octavian Voicu 29 Aug '11

29 Aug '11

Hello, I've noticed a lot of timeouts for cmd tests lately, which is not so surprising with all the new incoming tests. I think test_builtins.cmd should be split in a few files, which would then be run separately. An added benefit is that it would permit putting tests that affect other tests in separate files. In order to fix the timeout problem it's not enough to split the tests in different files. Each file has to be run on its own from winetest. I see following solutions: 1) Hack winetest and increase timeout just for cmd.exe batch tests. 2) Allow individual tests to receive a parameter. Downside is that make_ctests needs to be changed a bit (to recognize filenames given as "test.c:param"), and a manual rule for running MAKECTESTS needs to be added to the Makefile of those tests, which would list all the tests + values for the params. 3) Add a new source file for each .cmd file. All the batch running meat would still be in batch.c, with main test function non-static. A header file with prototypes and a macro for defining a test would be included in subsequent tests. I would go for number 3, I think it's the cleanest solution (although it would add a few more source files). Any comments on that? Octavian

3 3

Re: [PATCH] explorer: Try ShellExecute if the parameter isn't a directory (try 2)
by Jay Yang 29 Aug '11

29 Aug '11

On 08/29/2011 04:08 AM, Jay Yang wrote: > Changes from last time: > Fixed a build issue. > > --- > programs/explorer/Makefile.in | 2 +- > programs/explorer/explorer.c | 4 ++++ > 2 files changed, 5 insertions(+), 1 deletions(-) > > sorry, thunderbird seems to have sent to old file

1 0

re: Cmd tests timeout and splitting tests
by Dan Kegel 28 Aug '11

28 Aug '11

Hi Octavian, the intention was to just add new TESTCMD resources into rsrc.rc when test_builtins.cmd got too big.... but I never thought the tests would be so slow, splitting them by adding new rsrc.rc entries wouldn't help a timeout problem. I'd go for solution #3, too, but it's troubling that test names would be duplicated in the Makefile.in and in rsrc.rc. An awful thought just occurred to me: we could make test_builtins.cmd itself take a parameter saying which subtest to run. That would avoid needing to modify rsrc.rc, but you'd still need to figure out how to iterate through the tests. - Dan

1 0

re: rpcrt4:properly unmarshall EMUM16 discriminant
by Dan Kegel 28 Aug '11

28 Aug '11

Didn't apply here: $ git apply text fatal: corrupt patch at line 15 Looks like your email program word-wrapped both this and your other patch. Try attaching the patches instead.

3 5

re: [po]updated korean resource
by Dan Kegel 28 Aug '11

28 Aug '11

Patch failed to apply here: patching file po//ko.po Hunk #1 succeeded at 775 (offset -4 lines). Hunk #2 succeeded at 783 (offset -4 lines). Hunk #3 succeeded at 798 (offset -4 lines). Hunk #4 FAILED at 8714. Hunk #5 FAILED at 8809. Hunk #6 succeeded at 8812 (offset -23 lines). Hunk #7 FAILED at 8968. Hunk #8 succeeded at 10220 (offset -25 lines). 3 out of 8 hunks FAILED -- saving rejects to file po//ko.po.rej Also, please send plain text email next time (but still with the patch as an attachment).

2 3

re: [PATCH] attrib: Move implementation from cmd.exe to the standalone command (try 2)
by Dan Kegel 28 Aug '11

28 Aug '11

Hi Christian, your patch causes test failures in programs/cmd/tests here: ... batch.c:301: Test failed: unexpected char 0x41 position 0 in line 545 (got 'ATTRIB - Displays or changes file attributes.', wanted 'not-r.test not found after delete, good') batch.c:295: Test failed: unexpected end of line 546 (got '', wanted 'r.test found before delete, good') - Dan

1 0

Re: services: Remove an unused variable.
by Frédéric Delanoy 27 Aug '11

27 Aug '11

On Fri, Aug 26, 2011 at 17:35, Francois Gouget <fgouget(a)codeweavers.com> wrote: > --- > > Totally independent from my other (futur) services patches. > > programs/services/services.c | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/programs/services/services.c b/programs/services/services.c > index 35edbba..ff824bc 100644 > --- a/programs/services/services.c > +++ b/programs/services/services.c > @@ -289,12 +289,11 @@ static void scmdatabase_autostart_services(struct scmdatabase *db) > size = i; > for (i = 0; i < size; i++) > { > - DWORD err; > const WCHAR *argv[2]; > service = services_list[i]; > argv[0] = service->name; > argv[1] = NULL; > - err = service_start(service, 1, argv); > + service_start(service, 1, argv); > /* FIXME: do something if the service failed to start */ > release_service(service); > } Wouldn't it be better to do something with err rather than muting (as the comment suggests)?

2 2