September 2012 - Wine-Devel

Re: [PATCH 1/2] mshtml: Added DISPATCH_PROPERTYGET|DISPATCH_METHOD flags support for elements exposed as window properties

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 http://testbot.winehq.org/JobDetails.pl?Key=21785 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

Sept. 25, 2012

Re: shlwapi: PathCreateFromUrlA() should not crash when given NULL buffers.

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > Add NULL and insufficient buffer tests for PathCreateFromUrl(). > --- > dlls/shlwapi/path.c | 3 +++ > dlls/shlwapi/tests/path.c | 49 +++++++++++++++++++++++++++++---------------- > 2 files changed, 35 insertions(+), 17 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M shlwapi.dll -T ../../.. -p shlwapi_test.exe.so path.c && touch path.ok path.c:322: Test succeeded inside todo block: got len = 22 expected 22 from url file:///localhost/c:/foo/bar path.c:322: Test succeeded inside todo block: got len = 19 expected 19 from url file://host//c:/foo/bar make: *** [path.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2012

Re: oledb32: Add support for IDBInitialize interface in IDataInitialize

by Alistair Leslie-Hughes

On 25/09/2012 8:44 PM, Marvin wrote: > 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=21782 > > Your paranoid android. > > > === WNT4WSSP6 (32 bit marshal) === > marshal.c:66: Test failed: CoMarshalInterface failed with error 0x80040155 > marshal.c:239: Test failed: "CoUnmarshalInterface" failed with error 0x8003001e > marshal: unhandled exception c0000005 at 004165D0 > This test was already failing for some boxes. See http://test.winehq.org/data/6ebf13960be6105243536113625b5ca50883c8c9/index_… Best Regards Alistair Leslie-Hughes

Sept. 25, 2012

Re: oledb32: Add support for IDBInitialize interface in IDataInitialize

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 http://testbot.winehq.org/JobDetails.pl?Key=21782 Your paranoid android. === WNT4WSSP6 (32 bit marshal) === marshal.c:66: Test failed: CoMarshalInterface failed with error 0x80040155 marshal.c:239: Test failed: "CoUnmarshalInterface" failed with error 0x8003001e marshal: unhandled exception c0000005 at 004165D0

Sept. 25, 2012

Re: [5/6] start: Support getting the file to open by AppleEvent. (resend)

by Per Johansson

On Tue, Sep 25, 2012 at 10:57 AM, Francois Gouget <fgouget(a)free.fr> wrote: > On Tue, 25 Sep 2012, Per Johansson wrote: > > > Hi, > > > > I should probably add a note that when I wrote this I had some doubts it > it > > belongs in start.exe, and I still somewhat do. > > > > The alternative would be to write a new program. The advantage to that > is: > > Start.exe already has a /unix option so adding a /AppleEvent one may > make sense. > > I have two questions though (I apologize if careful reading the patch > would answer them). > > How would this new /AppleEvent option be used? > It will be used in file type association scripts created by winemenubuilder (patch 6/6). You won't invoke it manually since it only makes sense if there's an AppleEvent waiting to be delivered. The AppleEvent is sent to an application by OS X when you open a document. Is AppleEvent how they call DDE on Mac OS X<g>? > Pretty much, details differ but it serves the same function. AppleEvents have existed since 1991 and are pretty much unchanged since then at the API level. Mac OS prefers a single instance of each application and the events are therefore sent by the OS instead of a new instance of the application. This patch only checks for an event at launch, but since it usually immediately exits it's then ready to relaunch and check for another event. Regards, -- Per Johansson

Sept. 25, 2012

Re: [5/5] dxgi/tests: Test some reference counts.

by Alexandre Julliard

Ričardas Barkauskas <rbarkauskas(a)codeweavers.com> writes: > --- > dlls/dxgi/tests/device.c | 69 > ++++++++++++++++++++++++++++++++++------------ > 1 file changed, 51 insertions(+), 18 deletions(-) In general testing reference count values is not useful, unless you have an app that depends on it. -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2012

Re: Spam applications for testbot accounts

by Francois Gouget

On Mon, 17 Sep 2012, Scott Ritchie wrote: > Never underestimate the overeagerness of bots, I suppose... > > We're getting a lot of spam applications for testbot accounts now, maybe 2-3 > per day. Some are easy to discard because they put stuff like penis pills > into the info field, but others look like just names. Suggestions are > welcome. Is this something that calls for some anti-bot / capcha mechanism in the TestBot? If so please enter a bug on the TestBot's bug tracker: http://bugs.winehq.org/buglist.cgi?product=Wine-Testbot -- Francois Gouget <fgouget(a)codeweavers.com>

Sept. 25, 2012

Re: [5/6] start: Support getting the file to open by AppleEvent. (resend)

by Francois Gouget

On Tue, 25 Sep 2012, Per Johansson wrote: > Hi, > > I should probably add a note that when I wrote this I had some doubts it it > belongs in start.exe, and I still somewhat do. > > The alternative would be to write a new program. The advantage to that is: Start.exe already has a /unix option so adding a /AppleEvent one may make sense. I have two questions though (I apologize if careful reading the patch would answer them). How would this new /AppleEvent option be used? Is AppleEvent how they call DDE on Mac OS X<g>? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Sept. 25, 2012

Re: [5/6] start: Support getting the file to open by AppleEvent. (resend)

by Per Johansson

Hi, I should probably add a note that when I wrote this I had some doubts it it belongs in start.exe, and I still somewhat do. The alternative would be to write a new program. The advantage to that is: 1. start.exe is left more similar to it's windows counterpart. 2. This other program could handle multiple files sent in the same AppleEvent, which is possible. 3. The same program could also act as a proxy for a dock icon, handling clicks and activating windows (this is a later project). I'd imagine it'd be called winehostproxy or somesuch and handle several types of interaction with the host (is that what we call it btw?). If you think that's more appropriate I can work on that instead of adding this to start. Regards, -- Per Johansson 2012/9/23 Per Johansson <pelle(a)morth.org> >

Sept. 25, 2012

Re: Overriding the check for ownership of a prefix

by Scott Ritchie

On 9/24/12 2:48 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Scott, > > I don't think you need to override this check, esp. given that > there's a good reason for it being there: The good reason doesn't apply in this use case. Overriding it fixes every problem I'm facing without having to do anything complicated or manual. >> Note that there is a problem with this setup if the app modifies >> the registry and we then need to update the prefix-default >> registry > > I've excellent experience with symbolic links. In fact, none of the > apps (games) I use are installed directly within any .wine prefix. > Drive_c/Program Files/Games is a symbolic link to a large partition. > Your apps don't need to have conflicting registry settings then. I can't assume I'll always be so lucky. >> Imagine a distro package containing a Windows game in the form of >> a read-only copy of an installed prefix (into, say, /opt). > > So I recommend the following setup: - Have the game's main directory > be something like /opt/games/XYZ in UNIX, but tell it to install to > C:\games/XYZ - During installation, write down all registry keys that > the app creates and every file that it stores outside of its local > directory. > > Beware: the name of the directory C:\Program.. depends upon every > user's locale at .wine creation time! Use C:\Games\ instead to avoid > that pitfall. > > For every user: - After .wine is created normally, add a symlink > from Drive_c/Games to /opt/games - Add registry keys or dlls needed > by the app. > > wineprefixcreate ln -s /opt/games/XYZ $HOME/.wine/drive_c/games cp -p > whatever.dll $HOME/.wine/drive_c/windows/system32/ wine regedit > xyz.reg > > Trivial, isn't it? > We can't assume apps will install cleanly, or only need the files in their install directories; copying to windows system folder does happen, and then it becomes a real mess. > Typically, you don't need to recreate the content of user-local > APPDATA directories. The app will create them upon each run, since > they ought to run with different users on one machine. > > Caveat: Although my .wine and games directories are distinct, I've no > experience with write-protecting the games partition. Obviously, > this only has a chance to work with modern apps, written after MS > started recommending separating the app's dir from its per-local > configuration files to be since stored in ~/LOCALAPPDATA or the like. > Thus w9x/w2k-era games are ruled out. Still, I don't know where > those apps attempt to store e.g. crash logs. > > I've seen apps write high-scores or savegames to their central > directory when w2k was set in winecfg, and use HKCU/LOCALAPPDATA > (what's the exact name?) when running in xp mode. > > I've made excellent experience with plenty of apps sharing a single > .wine-games prefix with such a setup. I.e. you don't need one prefix > per app. Like on a real box, the apps ought to be able to coexist. > Perhaps. But separate prefixes give us so many advantages here, at the mere cost of some disk space. > Drawback: when I was initially attracted to Wine 5 years ago, every > .wine was a tiny 3-4MB. Nowadays it's more than 10 times that size, > and I'm not happy with that. Using a single onion-union-fs to share > drive_c/xyz may be interesting -- for as long as one single version > of Wine is in use. > > Regards, Jörg Höhle > Thank you though, you do propose one alternative.

Sept. 25, 2012