April 2009 - Wine-devel - list.winehq.org

Re: [1/5] resend include: bring in6_addr into line with the MS definition
by Alexandre Julliard 13 Apr '09

13 Apr '09

Jeff Latimer <lats(a)yless4u.com.au> writes: > +#ifdef USE_WS_PREFIX > +#define WS(x) WS_##x > +#else > +#define WS(x) x > +#endif > + > +struct WS(in6_addr) { > + union { > + WS(u_char) Byte[16]; > + WS(u_short) Word[8]; > + } u; > +} IN6_ADDR, *PIN6_ADDR, *LPIN6_ADDR; > + > +#define in_addr6 WS(in6_addr) > + > +#define _S6_un u > +#define _S6_u8 Byte > +#ifndef USE_WS_PREFIX > +#define s6_addr _S6_un._S6_u8 > +#else > +#define WS_s6_addr _S6_un._S6_u8 > +#endif > + > +#define s6_bytes u.Byte > +#define s6_words u.Word You need the WS prefix on all definitions that can potentially conflict with Unix. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: do ERR messages imply bugs?
by Vitaliy Margolen 13 Apr '09

13 Apr '09

Roderick Colenbrander wrote: > On Sun, Apr 12, 2009 at 6:53 PM, Vitaliy Margolen > <wine-devel(a)kievinfo.com <mailto:wine-devel(a)kievinfo.com>> wrote: > > Vincent Povirk wrote: > > Chris Ahrendt filed a few bugs recently for "err" messages encountered > > during test runs (17997 and 17998 at least). > > > 17997 is a bogus report - Gecko is not intalled. Nothing actually > failed. > 17998 is the same. Only I let our resident 3D gurus to respond. I > don't see > any problems with tests testing invalid conditions. This most likely > one of > those cases. > > If Chris doesn't like err messages, he can shut them off. > > Vitaliy. > > > The first ERR line in bug 17998 could indicate a real bug as a program > is trying to lock a surface which has already been locked. > > err:d3d_surface:IWineGDISurfaceImpl_LockRect (0x132280) Surface already locked > > I'm not sure about the opengl error. It could mean that some display > driver is offering some render_type flags which I'm not handling yet. > That can also cause issues. > > err:wgl:get_render_type_from_fbconfig Unknown render_type: 0 This is all well and good, but I'm seeing this errors from pretty much any 3D application. Not that all these 3D apps work flawlessly on Wine to begin with - haven't seen one yet. But it's been a policy to ignore all messages from Wine until user can show the real problem. So far no tests fail - and that is the only acceptable "problems" from tests. Vitaliy.

5 13

Re: Re : [4/4] (Try4) msi/tests: Fix package test when run on root drive directory.
by Nicolas Le Cam 13 Apr '09

13 Apr '09

2009/4/13 James McKenzie <jjmckenzie51(a)earthlink.net>: > Nicolas Le Cam wrote: >> James, >> >> Here are updated patches for part 3 & 4 of my previous patch set. Tell >> me if you think I could submit them to wine-patches. >> >> For patch 3, the only todo_wine is when launched from root drive dir >> as explained in my previous mail. >> For patch 4, I skip a test if test is executed on root drive dir, as >> it doesn't make sense to execute it in this case. >> >> If needed I can remove the skip and change expected value to be first >> fixed drive when test is run on root drive dir. But this is already >> tested by patch 3 (when run on a root drive dir). >> >> > Did these work with WindowsXP or Windows Vista as expected? I don't > have them here to test, only Wine. > > I would defer the todo_wine to others with more experience, as this > marks the tested function needs more work with Wine and my experience > with msi is only as a user. > > James McKenzie > > > It worked as expected on Win2k and Wine. I can test it on WinXP if wanted, but I don't own any Vista. The todo_wine is to handle root drive directories where Windows output first fixed drive where Wine currently output an empty string as demonstrated on . Fix seems to be simple. We just need to break the for loop after the GetDriveType test in ACTION_SearchDirectory function in appseach.c if path is only three characters long (attr should also be checked against INVALID_FILE_ATTRIBUTES just after it). ACTION_CheckDirectory could perhaps be updated to handle root drive directories too, but I'm not certain with this one. As I don't have any experience with msi at all even as user, I will certainly wait for someone to validate what I'm saying. Thanks for review. -- Nicolas Le Cam

2 2

wininet: Add tests for asynchronous HttpSendRequestEx/HttpEndRequest.
by Nicolas Le Cam 13 Apr '09

13 Apr '09

Hi Hans, Your patch makes the test timeout on my machine (http://test.winehq.org/data/f212579ae9a1b770ebd34cec20f95e1977bb57f0/2000_w…) Timeout occurs in HttpSendRequestEx_test on HttpEndRequest call which hang. Disabling test_async_HttpSendRequestEx makes it pass again. After some tests it seems to be a timing issue, but I haven't been able to find a real solution. Just that waiting at least 500msec between the two HttpEndRequest, or waiting at least 150ms after the WaitForSingleObject that follow the second HttpEndRequest makes test pass. Reading response doesn't change anything. After reading a little bit about how this works I don't see anything wrong. Perhaps you will. thanks, Nicolas Le Cam

2 4

Re: [4/4] (Try4) msi/tests: Fix package test when run on root drive directory.
by James Hawkins 12 Apr '09

12 Apr '09

On Fri, Apr 10, 2009 at 6:15 AM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: > Try2: This time with the patch. > > Tested on Win2k/WinXP. Marked two tests as todo_wine. > I was serious before. You can't change the old tests. Please add new tests for the exposed bugs. Same goes for patch 3/4. -- James Hawkins

4 8

Re: [5/8] WineD3D: Add a more formal framework for driver quirks
by Stefan Dösinger 12 Apr '09

12 Apr '09

I accidentally deleted the mail in my inbox, so that reply is without a proper in-reply-to tag. Here's the archive for reference: http://www.winehq.org/pipermail/wine-devel/2009-April/074718.html > - I don't like how much information specific to constant fixups the > table contains. There is a lot of intended redundancy here. The minimum we need is the flag to use the ARB or GLSL constant value. I want some additional safeguards to make the fixup noisy if one of the assumptions we make about the driver isn't true any more. The patches here only handle constants, but I want to do the same for varyings. I don't like the idea of using a callback function to apply the fixups because it would repeat quite a bit of value checking and FIXME writing code for different cards, just with different constants in the code. > - The "apple" field is weird. If you're going to have a callback > function you might as well match that information there, if > appropriate. On the other hand, I don't think you really need the > callback function, you only match on vendor and card anyway. All non-apple platforms have the same graphics driver, just the Apple drivers have their own weirdness that does not occur anywhere else. Its mostly many unsupported features that are advertised and software emulated which we have to filter out. All other platforms share the same driver anyway, even Windows to a certain extend. I can replace this with a driver vendor enum or a driver vendor matching function. However, I am prepared to adjust the setup in the future if $NEWWEIRDRIVERVENDOR pops up(e.g. Gallium3D) that has different requirements. I want to keep the driver vendor match separated from the card match to allow defining fixups that apply to all cards run by a driver from a specific vendor. A later patch adds a fixup that uses the ARB constant limits on all cards if we're running on a apple driver. There are other ways to do this, like returning a matching score and using the best match, or merging two fixups into one. I think that my approach matches what we want to do best and is simpler than trying to merge fixup descs. > - What is the point of only allowing one fixup per card, and then > adding QUIRK_NO_SANITY_CHECK to allow more fixups? You might as well > just allow multiple fixups and apply them in the order they're > defined. See above - generic fixups for a driver vendor that applies across cards. Obviously a Geforce 8 has different uniform or varying limits than a Intel GMA 950, but in both cases the GLSL uniform info is no good and we should use the ARB one instead. > - Why do you store the quirk table in gl_info? It's never used from > there. (I realise the next couple of patches do use it from there). > ... > and just add a DWORD "quirk_flags" to gl_info. My patches add two fields that are accessed from other places in the code. There may or may not be more in the future. I prefer to have one pointer in the gl_info structure than multiple DWORDs containing quirk info, but I am flexible with this.

2 1

Re: i have itunes 7.60 successfully running on f10 kde 4.2
by Ben Klein 12 Apr '09

12 Apr '09

2009/4/12 Warren Dumortier <nwarrenfl(a)gmail.com>: > No latest iTunes doesn't install, in fact only 7.60 installs if i remember... > Consult bugzilla. If there are no appropriate bugs open, open a bug, and provide as detailed information as you can. You should also be willing to provide additional information on request (remarkably, some people aren't, and they believe that just submitting an obscure bug is enough to get it fixed).

1 0

Re: implement PS_USERSTYLE handling, tested with Dia(win32)
by James McKenzie 11 Apr '09

11 Apr '09

Hans Breuer wrote: > From b89af7d06fc8cbf5210c61fd58ed62caeddad968 Mon Sep 17 00:00:00 2001 > From: Hans Breuer <hans(a)breuer.org> > Date: Sun, 29 Mar 2009 18:27:29 +0200 > Subject: implement PS_USERSTYLE handling, tested with Dia(win32) - see > http://hans.breuer.org/dia/dia-wine.htm > > --- > dlls/winex11.drv/pen.c | 31 +++++++++++++++++++++++++++---- > 1 files changed, 27 insertions(+), 4 deletions(-) > > diff --git a/dlls/winex11.drv/pen.c b/dlls/winex11.drv/pen.c > index 49fe74c..039798e 100644 > --- a/dlls/winex11.drv/pen.c > +++ b/dlls/winex11.drv/pen.c > @@ -54,12 +54,33 @@ HPEN CDECL X11DRV_SelectPen( X11DRV_PDEVICE > *physDev, HPEN hpen ) > elp = HeapAlloc( GetProcessHeap(), 0, size ); > > GetObjectW( hpen, size, elp ); > - /* FIXME: add support for user style pens */ > logpen.lopnStyle = elp->elpPenStyle; > logpen.lopnWidth.x = elp->elpWidth; > logpen.lopnWidth.y = 0; > logpen.lopnColor = elp->elpColor; > - > + /* support for user style pens */ > + if (MAX_DASHLEN < elp->elpNumEntries) > + { > + FIXME("PS_USERSTYLE: len(dashes)>MAX_DASHLEN %d,%d\n", > elp->elpNumEntries, MAX_DASHLEN); > + physDev->pen.dash_len = 0; > + } > + else > + { > + BOOL overflow = FALSE; > + physDev->pen.dash_len = elp->elpNumEntries; > + for (i = 0; i < elp->elpNumEntries; ++i) > + { > + if (elp->elpStyleEntry[i] > 255) > + { > + overflow = TRUE; /* can't fit the type */ > + physDev->pen.dashes[i] = 255; > + } > + else > + physDev->pen.dashes[i] = > (char)elp->elpStyleEntry[i]; > + } > + if (overflow) > + FIXME("PS_USERSTYLE: dashes clipped (type overflow)\n"); > + } > HeapFree( GetProcessHeap(), 0, elp ); > } > else > @@ -108,14 +129,16 @@ HPEN CDECL X11DRV_SelectPen( X11DRV_PDEVICE > *physDev, HPEN hpen ) > memcpy(physDev->pen.dashes, PEN_alternate, > physDev->pen.dash_len); > break; > case PS_USERSTYLE: > - FIXME("PS_USERSTYLE is not supported\n"); > + /* handled above */ > + break; > /* fall through */ > default: > physDev->pen.dash_len = 0; > break; > } > if(physDev->pen.ext && physDev->pen.dash_len && > - (logpen.lopnStyle & PS_STYLE_MASK) != PS_ALTERNATE) > + (logpen.lopnStyle & PS_STYLE_MASK) != PS_ALTERNATE && > + (logpen.lopnStyle & PS_STYLE_MASK) != PS_USERSTYLE) > for(i = 0; i < physDev->pen.dash_len; i++) > physDev->pen.dashes[i] *= (physDev->pen.width ? > physDev->pen.width : 1); > This needs a conformance test to show this is what happens in Windows. If this is not supported in certain versions, you will also need to add broken() code for those versions with what happens. Look at the Wine source code and search for the use of this call. James McKenzie

2 2

Re: [2/2] secur32/tests: Fix GetUserNameEx() tests
by Austin English 11 Apr '09

11 Apr '09

On Sat, Apr 11, 2009 at 1:45 PM, Ge van Geldorp <ge(a)gse.nl> wrote: > Update tests based on more Windows test runs > > Changelog: > secur32/tests: Fix GetUserNameEx() tests > > --- > dlls/secur32/tests/secur32.c | 42 > +++++++++++++++++++++--------------------- > 1 files changed, 21 insertions(+), 21 deletions(-) @@ -242,15 +234,23 @@ START_TEST(secur32) if (pGetComputerObjectNameA) testGetComputerObjectNameA(); + else + skip("GetComputerObjectNameA not exported by secur32.dll\n"); if (pGetComputerObjectNameW) testGetComputerObjectNameW(); + else + skip("GetComputerObjectNameW not exported by secur32.dll\n"); if (pGetUserNameExA) testGetUserNameExA(); + else + skip("GetUserNameExA not exported by secur32.dll\n"); if (pGetUserNameExW) testGetUserNameExW(); + else + skip("GetUserNameExW not exported by secur32.dll\n"); test_InitSecurityInterface(); Shouldn't these be win_skip's? -- -Austin

2 1

Re: [2/3] secur32/tests: Add simple tests for GetUserNameExA/W() [try 2]
by Paul Vriens 11 Apr '09

11 Apr '09

Ge van Geldorp wrote: > Try 2: Add buffer overflow tests > > Changelog: > secur32/tests: Add simple tests for GetUserNameExA/W() > > --- > dlls/secur32/tests/secur32.c | 86 > ++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 86 insertions(+), 0 deletions(-) > > Hi Ge, The tests show a big list of possible last errors. Are these for a specific platform? If so, we should probably list that. Is the ERROR_INVALID_PARAMETER for NameUnknown also for a specific platform? The reason I'm asking is because W2K fails with ERROR_INVALID_PARAMETER for NameDnsDomain and I'm looking for the cleanest way to add that (as broken()). -- Cheers, Paul.

2 2