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 1, 2009

June 1, 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 1, 2009

June 1, 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 1, 2009

June 1, 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