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

Re: [PATCH 1/2] vbscript: Added Mid function implementation
by Marvin 29 Mar '12

29 Mar '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=17548 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === 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

SoC 2012 Ideas
by Joerg-Cyril.Hoehle＠t-systems.com 29 Mar '12

29 Mar '12

Charles Davis wrote: >1) Make Wine use App Sandbox on Mac OS X. >At the very least, I would like to be able to limit Wine's file-system activity to the prefix. I'm not familiar with Mac OS X' particular security features, but I wonder why limiting FS activity needs changes in wine? With AppArmor or the like on Linux, you'd define a set of rules living outside of the app. Limiting to the prefix won't work, because /dev/tty and /tmp/X11.socket etc. need be used. All my apps are installed in a directory outside any .wine prefix. There's a symlink from within C:\Programs. How would you take that into account? BTW, I once defined a set of iptable rules to prevent networking for Wine (or was it for a whole user?) based on the consideration that the apps I use have nothing to do with networking. Here too, nothing need be changed in Wine. Regards, Jörg Höhle

2 1

Re: [PATCH 2/3] dmsynth: Check the rigth CLSID to create the DirectMusicSynthSink object.
by Marvin 29 Mar '12

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

1 0

Re: [PATCH 1/3] dmsynth: Add basic tests.
by Marvin 29 Mar '12

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

1 0

Re: [PATCH 1/3] dmsynth: Add basic tests.
by Marvin 29 Mar '12

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

1 0

Re: [PATCH 1/5] dmusic: Add some tests for enumerating and creating ports.
by Marvin 29 Mar '12

29 Mar '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=17542 Your paranoid android. === WNT4WSSP6 (32 bit dmusic) === dmusic.c:51: Test failed: CoCreateInstance returned: 80040154 dmusic: unhandled exception c0000005 at 00401347 === W2KPROSP4 (32 bit dmusic) === dmusic.c:51: Test failed: CoCreateInstance returned: 80004002 dmusic: unhandled exception c0000005 at 00401347 === W2K3R2SESP2 (32 bit dmusic) === dmusic.c:51: Test failed: CoCreateInstance returned: 80040154 dmusic: unhandled exception c0000005 at 00401347 === WVISTAADM (32 bit dmusic) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation === W2K8SE (32 bit dmusic) === dmusic.c:51: Test failed: CoCreateInstance returned: 80040154 dmusic: unhandled exception c0000005 at 00401347

1 0

Re: winspool.drv: Update allowed driver Version
by Marvin 28 Mar '12

28 Mar '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=17541 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

RFC: Duplicate in/out device naming
by Andrew Eikum 28 Mar '12

28 Mar '12

I'm working on Bug 14559 and have run into an interesting UI problem. In WinMM, there are three "classes" of devices: waveIn, waveOut, and mixer. Windows 7's WinMM implementation provides one mixer for each waveIn and waveOut device. The "WCHAR caps.szPname[32]" field for the matching mixer and waveIn/Out device are the same. Some applications, in this case Rosetta Stone 3, use the matching szPname fields to determine which mixer to associate with which device. The problem turns up when we have duplicate input and output device names. Consider: waveOut: 0: default 1: HDA Intel Analog 2: HDA Intel Digital waveIn: 0: default 1: HDA Intel Analog mixer: 0: default 1: HDA Intel Analog 2: HDA Intel Digital 3: default 4: HDA Intel Analog Rosetta Stone chooses waveIn[0] and starts iterating over the mixers' szPname fields, finding that mixer[0] matches. But, mixer[0] is actually associated with the waveOut default, not the waveIn default. Bad things happen. Windows 7 solves this problem implicitly by providing unique device names at the MMDevAPI level. For instance, the input device is Microphone and the output devices are Stereo and Headphones. Hacking the registry to force duplicate MMDevAPI device names actually does result in duplicate mixer names. But Wine's backends don't provide this kind of information, so we simply provide the ALSA device name as the device's name. As an attempt to solve this in Wine, I added a prefix to each MMDevice indicating its flow direction. The unique identifier must be a prefix, as WinMM's szPname field truncates at 31 characters. This gives WinMM device names like: waveOut: 0: Out: default 1: Out: HDA Intel Analog 2: Out: HDA Intel Digital This solves the Rosetta Stone issue, as you can see in the bug. But when testing this in other applications, it quickly becomes silly. Audacity 1.3 adds its own "Out: " prefix to WinMM device names, creating "Out: Out: default" in the UI. Dynamically adding prefixes only if a duplicate device is present causes issues with duplicates appearing/disappearing. Trying to remember if a duplicate has ever been present is quite "ugly" in code, requiring storing that kind of information in the registry. So I don't know what to do. Have ugly, redundant device names? Leave Rosetta Stone broken, as it is arguably an application bug? Try to guess at the device type, and insert names like "Speakers" and "Microphone" into the MMDevAPI device name, even if that might be wrong? Thoughts? Andrew

3 2

Re: [2/4] scrrun: Register Scripting interfaces (try 2)
by Alexandre Julliard 28 Mar '12

28 Mar '12

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -4,4 +4,6 @@ C_SRCS = scrrun.c > > RC_SRCS = scrrun.rc > > +IDL_TLB_SCRS = scrrun.idl This can't possibly do anything. I've fixed it up, but please test your code before sending, it's not the first time you send a registration patch that doesn't register anything. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] strmbase: Display dll in which we are searching a class to instanciate.
by Alexandre Julliard 28 Mar '12

28 Mar '12

Christian Costa <titan.costa(a)gmail.com> writes: > @@ -360,14 +361,17 @@ HRESULT WINAPI STRMBASE_DllGetClassObject(REFCLSID rclsid, REFIID riid, LPVOID * > break; > } > > + if (!GetModuleFileNameA(g_hInst, dllname, sizeof(dllname))) > + strcpy(dllname, "???"); You don't want to do that in the success case. -- Alexandre Julliard julliard(a)winehq.org

2 3