June 2009 - Wine-Devel - list.winehq.org

Re: shlwapi: add test for CombineUrl
by Alexandre Julliard June 2, 2009

June 2, 2009

Aric Stewart <aric(a)codeweavers.com> writes: > Associated with bug 18063 which is fixed. Apparently not: ../../../tools/runtest -q -P wine -M shlwapi.dll -T ../../.. -p shlwapi_test.exe.so url.c && touch url.ok url.c:781: Test failed: Got length 22, expected 21 url.c:786: Test failed: Got length 22, expected 21 url.c:790: Test failed: Got length 21, expected 20 url.c:792: Test failed: Expected http://wine:1234/dir, but got http://wine:1234/dir/ url.c:798: Test failed: Got length 22, expected 21 url.c:803: Test failed: Got length 22, expected 21 url.c:807: Test failed: Got length 21, expected 20 make[2]: *** [url.ok] Error 7 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [1/3] wininet: Check for bad allocation in HeapReAlloc
by Alexandre Julliard June 2, 2009

June 2, 2009

Jason Green <jave27(a)gmail.com> writes: > @@ -4213,10 +4213,10 @@ static INT HTTP_GetResponseHeaders(LPWININETHTTPREQW lpwhr, BOOL clear) > > /* regenerate raw headers */ > while (cchRawHeaders + buflen + strlenW(szCrLf) > cchMaxRawHeaders) > - { > cchMaxRawHeaders *= 2; > - lpszRawHeaders = HeapReAlloc(GetProcessHeap(), 0, lpszRawHeaders, (cchMaxRawHeaders+1)*sizeof(WCHAR)); > - } > + lpszRawHeaders = HeapReAlloc(GetProcessHeap(), 0, lpszRawHeaders, (cchMaxRawHeaders+1)*sizeof(WCHAR)); > + if (lpszRawHeaders == NULL) > + goto lend; If you are going to check the allocation, then you should handle the error properly too instead of leaking memory. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/3] d3dx9: Test the return codes of the D3DXGetImageInfo functions
by Alexandre Julliard June 2, 2009

June 2, 2009

Tony Wasserka <tony.wasserka(a)freenet.de> writes: > + /* D3DXGetImageInfoFromFile */ > + todo_wine { > + hr = D3DXGetImageInfoFromFileA("bmp1x1.bmp", &info); > + ok(hr == D3D_OK, "D3DXGetImageInfoFromFile returned %#x, expected %#x\n", hr, D3D_OK); > + } > + > + hr = D3DXGetImageInfoFromFileA("bmp1x1.bmp", NULL); > + ok(hr == D3D_OK, "D3DXGetImageInfoFromFile returned %#x, expected %#x\n", hr, D3D_OK); > + > + hr = D3DXGetImageInfoFromFileA("testdummy.bmp", NULL); /* existing file which is not a valid image, second parameter NULL */ > + ok(hr == D3D_OK, "D3DXGetImageInfoFromFile returned %#x, expected %#x\n", hr, D3D_OK); You can't depend on external files in tests, you have to create them yourself at run-time. -- Alexandre Julliard julliard(a)winehq.org

1 0

XI2 DirectInput mouse implementation RFC (Tarballed)
by Paul TBBle Hampson June 2, 2009

June 2, 2009

(Resend, the first email never arrived. I didn't realise one of my patches was 33k >_<) I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput. It's got a fair few problems, I'm mainly interested in feedback on the approach, although obviously any code or style criticisms are welcome. Current limitations: * Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support. * Doesn't send button-ups; XI2 can't distinguish button up from down * Doesn't send events after button-down until after button-up on a window. I'm pretty sure this is an XI2 bug, but it might be a design feature. * Doesn't support exclusive mode. XI2 bug (grabs not yet implemented) Hopefully this can be implemented entirely within the dinput code in winex11drv (ie disabling and hiding the mouse on acquire. dinput already takes care of unacquiring when we are no longer the foreground app) * Mouse buttons aren't remapped nicely downwards. Need to look harder at this, my mouse reports buttons 1, 2, 3, 4, 5, 8, 9, 10, 11 and 12 under X. 4 and 5 are scroll, 6 and 7 might be horizontal scroll in which case if this is always the case we can just remap downwards. Might need to implement device querying to confirm mouse button mapping... * Only supports the Mouse. Adding keyboard support should be really trivial compared to actually getting the framework right. * Doesn't detect capabilities... A mouse with a horizontal scroll wheel'd have four axes. I haven't looked to see if DirectInput can support that, or if our dinput code can easily accomodate more axes or buttons than the current 3/8 setup. This the point we'd need another callthrough from gdimouse to the graphics driver. * Assumes a process will only try and acquire the mouse once. I'm not sure that this is a bad assumption, and it might be that dinput makes this a valid assumption for us. * Assumes no one else wants GenericEvents. Some day we'll need a GenericEvent handler system inside WineX11, particularly if wintab gets converted to XInput 2 support. Easy enough to do now if wanted. * gdimouse uses Wine Mouse GUID value. I'm not sure where these come from, if anywhere. Trivial to fix before submission. If this format is fine, then the first patch is basically ready to go, the latter two patches may need to be re-split or merged more sensibly. In the libs folder I've also attached a couple of fixes for the XI2 stuff if anyone wants to try it. One only affects 64-bit builds, and one fixes XCB locking assertions which you could probably otherwise ignore. So they're both kinda optional in the Wine context. Also one more patch, against the xinput utility from whot's git tree, to fix a compile failure in the XI2 test functionality. -- Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com Shorter .sig for a more eco-friendly paperless office.

4 13

Re: gdi32: Stub for GdiEntry13()
by Kovács András June 2, 2009

June 2, 2009

Hi, I think you should add @ stdcall DdQueryDisplaySettingsUniqueness() line to gdi32.spec file, otherwise you will get message like this: err:module:find_forwarded_export function not found for forward 'gdi32.DdQueryDisplaySettingsUniqueness' used by L"C:\\windows\\system32 \\gdi32.dll". If you are using builtin L"gdi32.dll", try using the native one instead. Best regards, Andras 2009. 06. 2, kedd keltezéssel 01.37-kor Nikolay Sivov ezt írta: > Requested in bug http://bugs.winehq.org/show_bug.cgi?id=18638 > > Changelog: > - Stub for GdiEntry13() > > >From 860bd34f2f0927c306a3f58825ffe46981b522bf Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Tue, 2 Jun 2009 01:27:30 +0400 > Subject: Stub for GdiEntry13 > > --- > dlls/gdi32/driver.c | 11 +++++++++++ > dlls/gdi32/gdi32.spec | 1 + > 2 files changed, 12 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdi32/driver.c b/dlls/gdi32/driver.c > index 20d3f36..8a3c7ed 100644 > --- a/dlls/gdi32/driver.c > +++ b/dlls/gdi32/driver.c > @@ -741,3 +741,14 @@ INT WINAPI NamedEscape( HDC hdc, LPCWSTR pDriver, INT nEscape, INT cbInput, LPCS > lpszOutData); > return 0; > } > + > +/******************************************************************* > + * DdQueryDisplaySettingsUniqueness [GDI32.@] > + * GdiEntry13 [GDI32.@] > + */ > +ULONG WINAPI DdQueryDisplaySettingsUniqueness(VOID) > +{ > + FIXME("stub\n"); > + > + return 0; > +} > diff --git a/dlls/gdi32/gdi32.spec b/dlls/gdi32/gdi32.spec > index 36a8fb1..a50f763 100644 > --- a/dlls/gdi32/gdi32.spec > +++ b/dlls/gdi32/gdi32.spec > @@ -174,6 +174,7 @@ > # @ stub GdiDrawStream > # @ stub GdiEndDocEMF > # @ stub GdiEndPageEMF > +@ stdcall GdiEntry13() gdi32.DdQueryDisplaySettingsUniqueness > # @ stub GdiFixUpHandle > @ stdcall GdiFlush() > # @ stub GdiFullscreenControl

3 2

Fw: Need a temporary list moderator
by Luke Bratch June 2, 2009

June 2, 2009

--- On Thu, 28/5/09, Luke Bratch <l_bratch(a)yahoo.co.uk> wrote: > In a couple of weeks I'm going to be travelling around > India for about a month, from 14th June - 17th July, so I'll > need somebody to cover list moderation during that period. > > It's a simple task; you just need to bring up a web page > for each list a couple of times per day, and single out any > genuine messages that are awaiting approval, discarding the > rest. > > You'll need to do it almost every day for the whole month, > otherwise people will start to wonder where their mail is > getting to.... :) > > If you are interested, please email me directly. No responses so far - anybody? Luke

5 4

Re: gdiplus: add support for string alignment to GdipDrawString
by Paul Vriens June 2, 2009

June 2, 2009

Stephan Rose wrote: > Adds support for aligning a string inside the given bounding rectangle > for GdipDrawString. Both vertical and horizontal alignments implemented. > > > ------------------------------------------------------------------------ > > Hi Stephan, No remarks about the real contents of the patch (not my area of expertise). You are mixing tabs and spaces in this patch. This file uses 4 space indentation, please stick to that. The use of curly brackets is also not consistent. Looks like the rest of the file puts the opening curly bracket right after the closing round bracket (not even a space in between), like you do here: + if(format){ but a bit further you do: + if(format->vertalign != StringAlignmentNear) + { Usually when patches are created, one should try to adhere to the style of the file touched. -- Cheers, Paul.

1 0

Re: gdiplus: GdipDrawString
by Stephan Rose June 2, 2009

June 2, 2009

>I don't know why gdiplus does its own linebreaks. I haven't really >done any work in that area. > >If I had to guess, I'd say it's because StringFormatFlagsNoWrap has no >equivalent flag for DrawText. That probably means you can't pass it >off to DrawText. > >Since they'll probably have to be done differently, it's best to >implement one direction at a time. When you're happy with horizontal >alignment, you can send a patch for that regardless of the status of >vertical alignment. > >You should be able to use GdipMeasureString to get the size of the >text. In fact, the alignments will need to be implemented there too, >and it may be better to start there. Hmm the only way I can see alignments having any influence on MeasureString would be if the boundingBox of the text is to be aligned to the layoutRect based on the alignment flags. Should just be able to then take the calculated bounding rect and align that to the layout based on the flags. And you're right, if I use MeasureString I solve my issue where I don't know the height of the text ahead of time. Perfect. Thanks, Stephan

2 2

[Fwd: Re: DIB engine]
by James McKenzie June 2, 2009

June 2, 2009

To the list as well. -------- Original Message -------- Subject: Re: DIB engine Date: Mon, 01 Jun 2009 19:09:15 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: Andrew Eikum <andrew(a)brightnightgames.com> References: <a71bd89a0905301414j5bd70f74y3441d367b49bc5f0(a)mail.gmail.com> <1243755935.4535.1.camel(a)stephan-desktop> <4A22AD55.5020306(a)brightnightgames.com> <b6bb06270905311154w2b9ccb12jee6d64ea587f9524(a)mail.gmail.com> <4A22D65A.3030205(a)brightnightgames.com> Andrew Eikum wrote: > Austin English wrote: >> On Sun, May 31, 2009 at 11:16 AM, Andrew >> <andrew(a)brightnightgames.com> wrote: >> >>> My name's Andrew Eikum, I'm an undergraduate Computer Science >>> student at the >>> University of Minnesota. I contacted a Wine dev a few weeks ago >>> asking for >>> a small project to use to get familiar with Wine. I was pointed >>> towards the >>> gdiplus section and told to begin stubbing out the missing >>> functions, to >>> facilitate debugging. After familiarizing myself with how Wine's >>> DLLs are >>> built, and with Git, I'm now making quick progress. I expect to have a >>> (huge) patchset ready in the next week or two with most of the gdiplus >>> functions stubbed. >>> >>> After that, I plan to begin work on implementing some of the >>> functions. My >>> degree's emphasis is computer graphics, so working on gdiplus will >>> give me a >>> chance to learn more about the field as well as apply what I already >>> know. >>> I'm looking forward to working with other Wine devs on gdiplus, and >>> other >>> parts of Wine in the future. >>> >> >> Welcome to Wine! >> >> Be sure when sending patches to break them into small sets, with one >> change per patch. It makes it much easier to review that way, and if >> your patch causes a regression, much easier to identify which part if >> it's in multiple patches. >> > Thanks for the welcome! > > I am definitely doing small commits and following the WineGit wiki > page. One concern I have is that the number of patches will probably > be over 50 or even 75 -- I'm not sure if it'd be better to submit them > all in one go as they're pretty much all alike (just stubbing), or > just do batches of 5-10 every couple days as I finish them (so it's > not a deluge of patches). Any suggestions? > > > I'll second what Austin said. Please send in like the following: [1/2] Test for some gdiplus Windows function with todo_wine wrapper that demonstrates default Windows function from a source other than reverse-engineering (this is an absolute no-no.) [2/2] Code that implements the default function along with code to remove todo_wine wrapper. This way if your second code breaks something, the test will be in place and the todo_wine wrapper will remain. James McKenzie

1 0

Re: gdiplus: Stub for GdipCloneBitmapArea
by Vincent Povirk June 2, 2009

June 2, 2009

Don't bother adding "stub" to existing FIXME's. If it's a FIXME with arguments, we know it's a stub. Vincent Povirk On Mon, Jun 1, 2009 at 8:01 PM, Andrew Eikum<andrew(a)brightnightgames.com> wrote: > Stubbing GDI+: > Add stub function for GdipCloneBitmapArea. Also add missing > prototype for GdipCloneBitmapAreaI, and add stub note to > FIXME in GdipCloneBitmapAreaI stub function. > --- > dlls/gdiplus/gdiplus.spec | 2 +- > dlls/gdiplus/image.c | 10 +++++++++- > include/gdiplusflat.h | 2 ++ > 3 files changed, 12 insertions(+), 2 deletions(-) > > > >

1 0

Re: [PATCH 5/5] wininet: Test gzip encoded read.
by Paul Vriens June 2, 2009

June 2, 2009

Jacek Caban wrote: > --- > dlls/wininet/tests/http.c | 107 > ++++++++++++++++++++++++++++++++++---------- > 1 files changed, 82 insertions(+), 25 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Jacek, This patch introduces test failures on all platforms: 1 failure with IE7 1 new failure with IE8 (there was 1 with IE8 before this patch) 5 failures with IE6 Could you have a look (test.winehq.org)? -- Cheers, Paul.

2 1

Patchwatcher not reporting failures?
by Austin English June 1, 2009

June 1, 2009

Testing patchwatcher with a patch that simply removes two todo_wine's should've caused some failures. Indeed, looking at the log: cred.c:315: Test failed: expected CredentialBlobSize of 0 but got 20 cred.c:315: Test failed: expected NULL credentials but got 0x11d4ec cred.c:328: Test failed: expected CredentialBlobSize of 0 but got 20 cred.c:328: Test failed: expected NULL credentials but got 0x11d4d0 it did. But patchwatcher shows an 'OK'. Can you take a look? -- -Austin

3 2

gdiplus: GdipDrawString
by Stephan Rose June 1, 2009

June 1, 2009

Ok was playing a bit with DrawString on sunday trying to get string alignments to work. I've got horizontal alignments working by simply setting drawcoord.right which currently is left uninitialized and then passing DT_CENTER and DT_RIGHT as needed to DrawTextW. So far, that worked. However, I can't do that for vertical alignments because the code manually does the line breaking and therefore draws each line individually. So my question is, why? Why aren't we letting DrawTextW do the line breaking and just letting it draw with the appropriate rect? Is the linebreaking different? Or does DrawTextW not have the proper support for rotations? As it stands right now, if necessary, I can easily enough calculate the offsets myself for doing horizontal alignments instead of using DT_CENTER and DT_RIGHT. But for vertical, this is a bit problematic. I don't know how many lines of text there are going to be until the text has already been drawn. Kind of a prerequisite for vertical alignment however. That means that if I just want to brute force it, I'd have to duplicate the drawing loop and once only have it measure the string / count lines. That then allows me to calculate the proper offset and I could then just rerun the thing again with the new position and it'd work. A bit more better solution would be to store the line break info in a small array (indices into the string should do that tell me where each line ends) to simply the drawing loop. That would require a dynamic array though which brings me to another question, what should I use? is stuff like std::vector ok or should I use something else? If of course there's a way we can just have DrawTextW handle the line breaking, I don't even need to care about any of the above. Can then just calculate the proper bounding rect and hand all the issues off to DrawTextW. Thoughts? Thanks, Stephan

2 1

Regular users right on bugzilla
by Jerome Leclanche June 1, 2009

June 1, 2009

Since there's been some discussion about bugzilla recently... Is there any reason regular users aren't allowed to change keywords, component and dependencies on bugs they don't own on Bugzilla? Maybe marking as duplicate as well. I don't think it'd do any harm to allow those rights to every registered user. Cheers Jerome -- J. Leclanche / Adys

6 7

Re: [2/3] kernel32: fix QueryFullProcessImageNameW for output buffer being null
by Alexandre Julliard June 1, 2009

June 1, 2009

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > @@ -3155,6 +3155,12 @@ > NTSTATUS status; > DWORD needed; > > + if(!lpExeName) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return FALSE; > + } > + This is not correct: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so process.c && touch process.ok process.c:1670: Test failed: Expected GetLastError() to be 122 (ERROR_INSUFFICIENT_BUFFER) is 87 make[2]: *** [process.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Its Alive! Patchwatcher is reborn.
by Zachary Goldberg June 1, 2009

June 1, 2009

All, As you may have noticed in the last WWN I have been working on getting patchwatcher back up on a rather nice server whose cpu time is graciously donated by STWing (stwing.org) I've got it running at the moment at http://winepatch.stwing.upenn.edu/results2/ There are still many, many kinks to be worked out before I would use this as reliable and/or before I even think about enabling sending to patch authors. But if you're curious thats where the results are going and will likely be in the future. -Zach p.s. Kudos to Dan Kegel for a great walkthrough in the PW readme.txt, and of course for putting patchwatcher together in the first place!

4 4

Installing ActivePython screws up PATH in Wine?
by Dan Kegel June 1, 2009

June 1, 2009

In Wine, I can happily install mingw and add it to the global PATH by editing the registry key PATH in [System\\CurrentControlSet\\Control\\Session Manager\\Environment] However, once I install ActivePython, something gets screwed up, and from then on, 'PATH' in CMD says PATH="C:\Python26\";;C:\Python26\; even if I remove that bit from that registry key and add other directories. Anyone know what the heck is going on?

2 1

Re: Changing default severity in Bugzilla to Normal
by James Mckenzie June 1, 2009

June 1, 2009

Austin English wrote about Re: Changing default severity in Bugzilla to Normal > >On Thu, May 28, 2009 at 1:40 PM, Ken Sharp <kennybobs(a)o2.co.uk> wrote: >> "It seems the default severity, enhancement, invites people to select a >> REALLY >> SEVERE sounding level instead. I suggest changing the default severity to >> normal in the hopes of cutting down on the yelling." >> http://bugs.winehq.org/show_bug.cgi?id=13363 >> >> Any thoughts on this? >> >> >> > >+1 > +1 James McKenzie

3 2