August 2010 - Wine-Devel - list.winehq.org

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by Juan Lang

> ^ is bitwise-XOR, so it is more like if(This->navpane.show != show_navpane), > which looks to be what he intended. Ah, yes 'tis. Perhaps it's a deficiency of my brain, but when reading bit-twiddling code, I remember the bitwise operators, but when reading logical code, I tend to stick to the boolean operators more. David, AJ will probably override me and say it's not necessary, but to my eyes != looks clearer. Thanks, --Juan

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by David Hedberg

On Thu, Aug 26, 2010 at 19:32, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > On Thu, Aug 26, 2010 at 8:11 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> Hi David, I know this was committed already, but something caught my >> eye that I didn't understand: >> >> + if(This->navpane.show ^ show_navpane) >> >> Is this a cute way to write if(This->navpane.show && show_navpane) ? >> If so, why ^ rather than &&? > > ^ is bitwise-XOR, so it is more like if(This->navpane.show != show_navpane), > which looks to be what he intended. > > Octavian > It's indeed supposed to be !=, which also seems like the easier and better way of expressing it. :-) I guess the only reason I used ^ is that that was what came to my mind when I wrote the code in question. It shouldn't matter in practice, but I can include a patch for it in my next batch of patches.

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by Octavian Voicu

On Thu, Aug 26, 2010 at 8:11 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi David, I know this was committed already, but something caught my > eye that I didn't understand: > > + if(This->navpane.show ^ show_navpane) > > Is this a cute way to write if(This->navpane.show && show_navpane) ? > If so, why ^ rather than &&? ^ is bitwise-XOR, so it is more like if(This->navpane.show != show_navpane), which looks to be what he intended. Octavian

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by Juan Lang

Hi David, I know this was committed already, but something caught my eye that I didn't understand: + if(This->navpane.show ^ show_navpane) Is this a cute way to write if(This->navpane.show && show_navpane) ? If so, why ^ rather than &&? Thanks, --Juan

Aug. 26, 2010

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)

by testbot＠testbot.winehq.org

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=4793 Your paranoid android. === W7PRO (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (64 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1)

Aug. 26, 2010

Re: ddraw/tests: New visual back buffer flipping tests. (try 3)

by Oldřich Jedlička

On Wednesday 25 August 2010 12:03:50 Stefan Dösinger wrote: > > + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > > + "Attaching a back buffer to a front buffer returned %08x\n", hr); > > The patch looks OK. Out of curiosity, which windows system returns > DDERR_CANNOTATTACHSURFACE? Allowing this result with broken() is OK since > you have an application that depends on this behavior. I've searched my previous patches and I think that I've copied it during my first tries from dsurface.c: AttachmentTest. I don't know if it is needed in my tests too, probably not for the testbot. It looked like a good idea to have the check too if it had been in AttachmentTest already. I can remove it with further patch (also from the dsurface.c: BackBufferAttachmentFlipTest). Should I remove it? I will wait for the patch to be applied first and I will send small correction to remove the broken() check, right? I can remove the broken() check from my "New attachment tests for 3D back buffers." patch too. Should I remove it or keep it? Oldřich.

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by James Mckenzie

Vincent Povirk <madewokherd(a)gmail.com> wrote: >Sent: Aug 26, 2010 9:03 AM >To: Dan Kegel <dank(a)kegel.com> >Cc: wine-devel(a)winehq.org, Stefan Dösinger <stefandoesinger(a)gmx.at> >Subject: Re: Inviting Mono and pulseaudio to wineconf? > >> Mono: >> Vincent, what do you think? Probably they're not holding us up, >> but maybe they'd like to see a presentation from you about >> status of Mono integration? > >Oh geez. Um. Well, they are indeed not holding us up. In all my >communication with them, they've been very helpful. > Since Microsoft appears to have taken a hostile turn towards anything released with Windows 7, WMP 10, .NET .3.5 + working with Wine, it would be very interesting to see what the Mono team's stance is on integration with Wine and the path onward. At one time it was very hostile, now it seems to have changed to at least neutral and maybe even what we call 'hallway' friendly. >I don't know that the current status of Mono integration is much to talk about. > >> http://wiki.winehq.org/Mono is looking good. (Think there's a Summer >> of Code 2011 project or two in there?) > >Judging by bugzilla, there don't seem to be any large projects that >would help compatibility enough to be worthwhile. All the mscoree bugs >only affect one app. > Hmmm. Maybe we need to widen the 'gene pool' to see if other applications are affected. James McKenzie

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Vincent Povirk

> Mono: > Vincent, what do you think? Probably they're not holding us up, > but maybe they'd like to see a presentation from you about > status of Mono integration? Oh geez. Um. Well, they are indeed not holding us up. In all my communication with them, they've been very helpful. I don't know that the current status of Mono integration is much to talk about. > http://wiki.winehq.org/Mono is looking good. (Think there's a Summer > of Code 2011 project or two in there?) Judging by bugzilla, there don't seem to be any large projects that would help compatibility enough to be worthwhile. All the mscoree bugs only affect one app.

Aug. 26, 2010

Re: : Use SUBLANG_NEUTRAL for language-independent resources

by Greg Geldorp

> From: Francois Gouget <fgouget(a)free.fr> > > According to past Winetest results these platforms could (should?) have > it though. A full log is strange but I don't how it could be cause by my > patch: > > gameux: start - - > Usage: C:\winetest\gameux_test64.exe test_name > > Valid test names: > gameexplorer > gamestatistics > gameux: done (1) > > No test summary line found Your patch only changed the .rc file. TestBot doesn't know what tests to run in that case (it determines the tests to run from the .c files that were changed). Same kind of thing happens when the .js files for the jscript.dll tests are changed. I'll see if I can teach it to just run all tests in these cases. Ge.

Aug. 26, 2010

Re: [5/5] d3d10: Implement D3D10CompileShader, forward to d3dcompiler.

by Henri Verbeet

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > +#define COBJMACROS > #include "config.h" > #include "wine/port.h" > - > +#include "objbase.h" > +#include "d3dcompiler.h" > #include "d3d10_private.h" You should probably just include d3dcompiler.h from d3d10_private.h.

Aug. 26, 2010

Re: [2/5] d3dcompiler: Stub D3DCompile implementation.

by Henri Verbeet

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Please stick to the coding style used in the rest of the d3d10 dlls (see e.g. blob.c for reference). This applies to patches 4 and 5 as well.

Aug. 26, 2010

Re: user32: Make GetMessage and PeekMessage patchable

by Henri Verbeet

On 26 August 2010 15:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)macbook.local> Please configure git properly?

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Dan Kegel

On Wed, Aug 25, 2010 at 9:51 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >>> Would it be appropriate and useful to invite someone from >>> Mono and Pulseaudio to attend Wineconf this year? > > I guess it never hurts to have people around, but we should have a set of issues to discuss with them. Pulseaudio: What's the status with http://bugs.winehq.org/show_bug.cgi?id=10495 ? Alexandre said in http://bugs.winehq.org/show_bug.cgi?id=10495#c251 that it's being worked on... Mono: Vincent, what do you think? Probably they're not holding us up, but maybe they'd like to see a presentation from you about status of Mono integration? http://wiki.winehq.org/Mono is looking good. (Think there's a Summer of Code 2011 project or two in there?) - Dan

Aug. 26, 2010

Re: gameux: Use SUBLANG_NEUTRAL for language-independent resources.

by Francois Gouget

On Thu, 26 Aug 2010, testbot(a)testbot.winehq.org wrote: [...] > http://testbot.winehq.org/JobDetails.pl?Key=4787 > > Your paranoid android. > > === W98SE (32 bit) === > === W2KPROSP4 (32 bit) === > === WXPPROSP3 (32 bit) === > === W2K3R2SESP2 (32 bit) === > === W2K8SE (32 bit) === > No test summary line found I think it's just because these platforms don't have the gameux library. Isn't testbot supposed to detect that though? > === WVISTAADM (32 bit) === > === W7PRO (32 bit) === > === W7PROX64 (32 bit) === > === W7PROX64 (64 bit) === > No test summary line found According to past Winetest results these platforms could (should?) have it though. A full log is strange but I don't how it could be cause by my patch: gameux: start - - Usage: C:\winetest\gameux_test64.exe test_name Valid test names: gameexplorer gamestatistics gameux: done (1) No test summary line found -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

Aug. 26, 2010

Re: Use SUBLANG_NEUTRAL for the Gaelic resources?

by Francois Gouget

On Tue, 24 Aug 2010, Huw Davies wrote: [...] > > If not it would be better to use SUBLANG_NEUTRAL instead of > > SUBLANG_GAELIC. For instance: > > I think they're different enough to warrant falling back to English > rather than Irish (which is essentially what you're asking). Works for me. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Aug. 26, 2010

Re: gameux: Use SUBLANG_NEUTRAL for language-independent resources.

by testbot＠testbot.winehq.org

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=4787 Your paranoid android. === W98SE (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 === W7PROX64 (64 bit) === No test summary line found

Aug. 26, 2010

Re: [PATCH 4/5] shell32: Add INameSpaceTreeControlEvents stub to the ExplorerBrowser control.

by David Hedberg

On Thu, Aug 26, 2010 at 13:03, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 8/26/2010 14:53, David Hedberg wrote: >> >> + *ppvObject = NULL; >> + if(IsEqualIID(riid,&IID_INameSpaceTreeControlEvents)) >> + { >> + *ppvObject = iface; >> + } >> + > > Why don't you allow IUnknown here? > An oversight on my part I guess, although I'm not sure anyone will ever request IUnknown here in this case. I'll add it.

Aug. 26, 2010

Re: [PATCH 1/5] shell32: Check for ICommDlgBrowser from Site and use it in the IExplorerBrowser control.

by David Hedberg

On Thu, Aug 26, 2010 at 13:15, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 8/26/2010 14:53, David Hedberg wrote: >> >> --- >> dlls/shell32/ebrowser.c | 98 +++++++++++++++++++---- >> dlls/shell32/tests/ebrowser.c | 174 >> ++++++++++++++++++++++++++++++++++++++++- >> 2 files changed, 251 insertions(+), 21 deletions(-) >> >> diff --git a/dlls/shell32/ebrowser.c b/dlls/shell32/ebrowser.c >> index b243aa0..1137880 100644 >> --- a/dlls/shell32/ebrowser.c >> +++ b/dlls/shell32/ebrowser.c >> @@ -73,6 +73,8 @@ typedef struct _ExplorerBrowserImpl { >> LPITEMIDLIST current_pidl; >> >> IUnknown *punk_site; >> + ICommDlgBrowser3 *pcdb3_site; >> + UINT cdb_site_supported; >> } ExplorerBrowserImpl; > > I think a better way for this would be to store a pointer for each interface > version, instead of having additional switch. When you have separate > pointers a call looks more obvious like: > > if (pcdb_site) ICommDlgBrowser_*(pcdb_site). > > Makes sense, I'll send a new version. Thanks.

Aug. 26, 2010

Re: [PATCH 1/5] shell32: Check for ICommDlgBrowser from Site and use it in the IExplorerBrowser control.

by Nikolay Sivov

On 8/26/2010 14:53, David Hedberg wrote: > --- > dlls/shell32/ebrowser.c | 98 +++++++++++++++++++---- > dlls/shell32/tests/ebrowser.c | 174 ++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 251 insertions(+), 21 deletions(-) > > diff --git a/dlls/shell32/ebrowser.c b/dlls/shell32/ebrowser.c > index b243aa0..1137880 100644 > --- a/dlls/shell32/ebrowser.c > +++ b/dlls/shell32/ebrowser.c > @@ -73,6 +73,8 @@ typedef struct _ExplorerBrowserImpl { > LPITEMIDLIST current_pidl; > > IUnknown *punk_site; > + ICommDlgBrowser3 *pcdb3_site; > + UINT cdb_site_supported; > } ExplorerBrowserImpl; I think a better way for this would be to store a pointer for each interface version, instead of having additional switch. When you have separate pointers a call looks more obvious like: if (pcdb_site) ICommDlgBrowser_*(pcdb_site).

Aug. 26, 2010

Re: [PATCH 4/5] shell32: Add INameSpaceTreeControlEvents stub to the ExplorerBrowser control.

by Nikolay Sivov

On 8/26/2010 14:53, David Hedberg wrote: > + *ppvObject = NULL; > + if(IsEqualIID(riid,&IID_INameSpaceTreeControlEvents)) > + { > + *ppvObject = iface; > + } > + Why don't you allow IUnknown here?

Aug. 26, 2010

Re: mpr: Fix Czech translation.

by Alexandre Julliard

Amine Khaldi <amine.khaldi(a)reactos.org> writes: > Regards, > Amine. There's no need to send a separate patch for each language, it's the same change for all. Also make sure your mailer doesn't mangle the high bit chars. -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2010

[PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

by Joerg-Cyril.Hoehle＠t-systems.com

Octavian, are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146 and the partial patch and additional test cases there? >winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values. >+#define MCI_INTEGER_PTR 13 What kind of testing did you perform on native systems to derive the existence of this value? If such value does not exist, then I fear your patch set looses the ability to drop in native dlls for compatibility testing and validation. If it exists, then it's good news you found it. >-static DWORD MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd, >+static DWORD MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd, >- if (!MCI_GetDWord(&(data[offset+0]), &args) || >- !MCI_GetDWord(&(data[offset+1]), &args) || >- !MCI_GetDWord(&(data[offset+2]), &args) || >- !MCI_GetDWord(&(data[offset+3]), &args)) { >+ if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) { The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*, they are DWORD with some DWORD_PTR in between. Wouldn't using DWORD* data help avoid such pointer arithmetic and eliminate several hunks of the patch ? Regards, Jörg Höhle

Aug. 26, 2010

Re: RFC: Resolving a full screen bug

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > I've been periodically revisiting a patch I've been using to fix a bug > with running Borderlands under Wine at the same resolution as the > desktop ( original message: > http://www.winehq.org/pipermail/wine-devel/2010-May/083339.html ). > Attached is an iteration that appears to resolve the issue without > impacting the other applications I normally run. It appears that the > problem arises since Borderlands goes straight from being iconified to > being exactly the desktop resolution, as a result Wine never turns off > the "iconic" flag - so the application window is not sized or > positioned properly. I would appreciate it if I could get some > feedback on this patch, it doesn't seem to break anything but it would > be nice to have an expert opinion. It's not correct, the iconic flag is supposed to reflect the state that we have asked from X. What is the exact sequence that leads to the window remaining iconified? -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2010

RFC: Resolving a full screen bug

by Erich Hoover

I've been periodically revisiting a patch I've been using to fix a bug with running Borderlands under Wine at the same resolution as the desktop ( original message: http://www.winehq.org/pipermail/wine-devel/2010-May/083339.html ). Attached is an iteration that appears to resolve the issue without impacting the other applications I normally run. It appears that the problem arises since Borderlands goes straight from being iconified to being exactly the desktop resolution, as a result Wine never turns off the "iconic" flag - so the application window is not sized or positioned properly. I would appreciate it if I could get some feedback on this patch, it doesn't seem to break anything but it would be nice to have an expert opinion. Erich Hoover ehoover(a)mines.edu

Aug. 25, 2010

Re: winetrick & mono dot net 3.5 emmulation.

by Hin-Tak Leung

apologies - for laziness, I picked one message with Dan Kegel and did a reply and emptied subject/body. I guess that messes up e-mail software that actually uses the invisible headers for threads. -------- Original Message -------- Subject: Re: winetrick & mono dot net 3.5 emmulation. Date: Wed, 25 Aug 2010 21:01:09 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> Hin-Tak Leung wrote: > The installer of one application I have requires Net 3.5 and refuses > to install > if it is not detected. Yet it runs adequately well with mono 2.6.x > (when installed to Vista then copied over). So I am wondering if there > should be a winetrick "lie about having .net 3.5" registry setting, > and go about seeing what needs to be done - e.g. how is that installer > detecting dot net 3.5 ? > > > > Can you open a separate thread for this? I'm going ahead and deleting all of the messages from the hijacked thread on my system and you have a very good point to make. James McKenzie

Aug. 25, 2010