September 2009 - wine-devel

Re: [try 3] comctl32: Implement highlighting (marquee) selection support in listview
by Nikolay Sivov 21 Sep '09

21 Sep '09

Owen Rudge wrote: > Minor update, rename some potentially confusing comments/variables. > > --- > dlls/comctl32/listview.c | 135 > ++++++++++++++++++++++++++++++++++++++++----- > 1 files changed, 120 insertions(+), 15 deletions(-) + /* Draw focus rect if highlighting */ + if (infoPtr->bHighlighting) + DrawFocusRect(hdc, &infoPtr->marqueeRect); + :). Now we have 3 different names for a single thing.

2 1

Re: mshtml / shdocv / urlmon tests hanging?
by Dan Kegel 21 Sep '09

21 Sep '09

Without. Thanks, I'll rerun tonight. On Sep 21, 2009 8:05 AM, "Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: On 09/21/2009 04:32 PM, Dan Kegel wrote: > > Doing a full test with my xattr patches, I saw hangs > ... With or without Gecko installed? -- Cheers, Paul.

1 0

Re: [try 2] comctl32: Implement highlighting (marquee) selection support in listview
by Nikolay Sivov 21 Sep '09

21 Sep '09

Owen Rudge wrote: > This patch adds support for selecting multiple items in a > multi-selection listview using the mouse (by dragging and > highlighting). It has been reimplemented in a more efficient manner > compared to the previous patches. > > --- > dlls/comctl32/listview.c | 135 > ++++++++++++++++++++++++++++++++++++++++----- > 1 files changed, 120 insertions(+), 15 deletions(-) Hi again. Didn't test it actually but it looks definitely better without extra cycles and state caching, thanks for that. I suggest another simple naming improvement: you're mixing different things in comments and naming, it looks confusing now. --- + BOOL bHighlighting; + RECT highlightRect; --- I suggest something like marqueeRect name here cause item itself has a state flag called LVIS_DROPHILITED which has nothing to do with this rectangle obviously. --- + /* Cancel out the old focus rectangle and draw the new one */ + LISTVIEW_InvalidateRect(infoPtr, &infoPtr->highlightRect); --- Focus rectangle is an item focus bounds in current naming, so comment is a bit confusing here. --- + /* Draw focus rect if highlighting */ + if (infoPtr->bHighlighting) + DrawFocusRect(hdc, &infoPtr->highlightRect); ... + /* Remove the focus rectangle */ + if (infoPtr->bHighlighting) + LISTVIEW_InvalidateRect(infoPtr, &infoPtr->highlightRect); --- Same here, it isn't a focus rectangle. Regards.

2 1

mshtml / shdocv / urlmon tests hanging?
by Dan Kegel 21 Sep '09

21 Sep '09

Doing a full test with my xattr patches, I saw hangs on about seven tests, all in mshtml , shdocv, and urlmon. While doing a baseline test run without my xattr patches, I noticed that mshtml / dom tests were still hanging. Has anybody else seen these tests hang lately?

2 1

Re: oledb32: Implement CanConvert.
by Marcus Meissner 21 Sep '09

21 Sep '09

On Mon, Sep 21, 2009 at 01:50:51PM +0100, Huw Davies wrote: > --- > dlls/oledb32/convert.c | 231 +++++++++++++++++++++++++++++++++++++++++- > dlls/oledb32/tests/convert.c | 10 -- > 2 files changed, 228 insertions(+), 13 deletions(-) > diff --git a/dlls/oledb32/convert.c b/dlls/oledb32/convert.c > index 458abb5..a2385f0 100644 > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -126,13 +126,238 @@ static HRESULT WINAPI convert_DataConvert(IDataConvert* iface, > return E_NOTIMPL; > } > > +static inline WORD get_dbtype_class(DBTYPE type) > +{ > + switch(type) > + { > + case DBTYPE_I2: > + case DBTYPE_R4: > + case DBTYPE_R8: > + case DBTYPE_I1: > + case DBTYPE_UI1: > + case DBTYPE_UI2: > + return DBTYPE_I2; > + > + case DBTYPE_I4: > + case DBTYPE_UI4: > + return DBTYPE_I4; > + > + case DBTYPE_I8: > + case DBTYPE_UI8: > + return DBTYPE_I8; > + > + case DBTYPE_BSTR: > + case DBTYPE_STR: > + case DBTYPE_WSTR: > + return DBTYPE_BSTR; > + > + case DBTYPE_DBDATE: > + case DBTYPE_DBTIME: > + case DBTYPE_DBTIMESTAMP: > + return DBTYPE_DBDATE; > + } > + return type; > +} > + > +/* Many src types will convert to this group of dst types */ > +static inline BOOL common_class(WORD dst_class) > +{ > + switch(dst_class) > + { > + case DBTYPE_EMPTY: > + case DBTYPE_NULL: > + case DBTYPE_I2: > + case DBTYPE_I4: > + case DBTYPE_BSTR: > + case DBTYPE_BOOL: > + case DBTYPE_VARIANT: > + case DBTYPE_I8: > + case DBTYPE_CY: > + case DBTYPE_DECIMAL: > + case DBTYPE_NUMERIC: > + return TRUE; > + } > + return FALSE; > +} > + > +static inline BOOL array_type(DBTYPE type) > +{ > + return (type >= DBTYPE_I2 && type <= DBTYPE_UI4); > +} > + > static HRESULT WINAPI convert_CanConvert(IDataConvert* iface, > - DBTYPE wSrcType, DBTYPE wDstType) > + DBTYPE src_type, DBTYPE dst_type) > { > convert *This = impl_from_IDataConvert(iface); > - FIXME("(%p)->(%d, %d): stub\n", This, wSrcType, wDstType); > + DBTYPE src_base_type = src_type & 0x1ff; > + DBTYPE dst_base_type = dst_type & 0x1ff; > + WORD dst_class = get_dbtype_class(dst_base_type); > > - return E_NOTIMPL; > + TRACE("(%p)->(%d, %d)\n", This, src_type, dst_type); > + > + if(src_type & DBTYPE_VECTOR || dst_type & DBTYPE_VECTOR) return S_FALSE; I think this needs brackets... Ciao, Marcus

3 3

Wine in Tango
by Joel Holdsworth 21 Sep '09

21 Sep '09

Hi All, If anyone's interested I've published a working version of my Tango graphics for wine to Gitorious... http://gitorious.org/wine-tango/wine-tango clone: git clone git://gitorious.org/wine-tango/wine-tango.git branch: public-beta-1 This branch features Roderick Colenbrander's as-yet unmerged XRender patches, some patches from me for 32-bit support in the areas of icons, image lists and toolbars, and a partial set of patches to apply the tango graphics for shell32, user32 and comdlg32. Graphics for other apps/dlls are excluded, as well as the few tests I've produced. The work is most clear to see if you open a file dialog, or a message box. The full set of Tango graphics can be seen here: http://www.airwebreathe.org.uk/wine-icon/ . There are still a few graphical things to fix: dxdiag, certwatermark.bmp. Comments and criticisms are welcome! Best Regards Joel Holdsworth

9 15

Re: cppcheck Sept 18
by James Mckenzie 21 Sep '09

21 Sep '09

-----Original Message----- >From: Henri Verbeet <hverbeet(a)gmail.com> >Sent: Sep 20, 2009 12:19 PM >To: Pauli Nieminen <suokkos(a)gmail.com> >Cc: wine-devel(a)winehq.org, Joris Huizer <joris_huizer(a)yahoo.com> >Subject: Re: cppcheck Sept 18 > >2009/9/20 Pauli Nieminen <suokkos(a)gmail.com> >> >> On Sat, Sep 19, 2009 at 1:59 PM, Joris Huizer <joris_huizer(a)yahoo.com> wrote: >>> >>> [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible >>> error) Array index out of bounds >>> >>> This one is a false positive, it uses FIELD_OFFSET(cs_t, ca[5]), >>> and it found an array: >>> int ca[5]; >>> >> int ca[5]; >> has only entries up to ca[4] (0-4) so to me it looks like bug. >> >Not quite. For one, the ca[5] that's being used here isn't the local >variable ca[5], but the field ca[1] of the cs_t structure. The >expression is used as a way to calculate the size of a cs_t structure >with 5 elements. > But what is the real size of ca[]? Is it five, fifty or five-hundred? Maybe that is why the cppcheck is declaring it out-of-bounds. James McKenzie

2 1

Re: [PATCH 4/6] d3d9: Limit "NumSimultaneousRTs" to 4.
by Stefan Dösinger 20 Sep '09

20 Sep '09

Am Sunday 20 September 2009 20:09:25 schrieb Henri Verbeet: > pCaps->MaxVertexShaderConst = min(D3D9_MAX_VERTEX_SHADER_CONSTANTF, > pCaps->MaxVertexShaderConst); + pCaps->NumSimultaneousRTs = > min(D3D9_MAX_SIMULTANEOUS_RENDERTARGETS, pCaps->NumSimultaneousRTs); } I think you also have to make sure RTs > 3 can't be used in SetRenderTarget and GetRenderTarget

1 0

cppcheck Sept 18
by Joris Huizer 20 Sep '09

20 Sep '09

[/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd These two are false positives, as the process ends (calling exit(1) [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds This one is a false positive, it uses FIELD_OFFSET(cs_t, ca[5]), and it found an array: int ca[5]; [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 That is a bug, sent a patch HTH, Joris

4 3

Re: dlls/comctl32/tests/tab.c: Transform CheckSize from a macro to a function.
by Nikolay Sivov 20 Sep '09

20 Sep '09

Gerald Pfeifer wrote: > This not only avoids a 12+ line macro, it also sheds a couple of > compiler warnings with GCC 4.4 (though not the forthcoming 4.5). > > Gerald > > > ChangeLog: > Transform CheckSize from a macro to a function. > Hi, Gerald. This patch breaks line trace for tests. You should pass __LINE__ to your helper to work this as before.

1 0

Re: cppcheck Sept 18
by James Mckenzie 20 Sep '09

20 Sep '09

>[/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible >error) Array index out of bounds > >This one is a false positive, it uses FIELD_OFFSET(cs_t, ca[5]), >and it found an array: >int ca[5]; > Actually, if this is a zero offset array, this is out of bounds. It might be better to extend ca by one and eliminate the possibility of the overflow and it only uses one more int worth of space... James McKenzie

1 0

porting winetricks to windows
by Dan Kegel 20 Sep '09

20 Sep '09

Part of my http://wiki.winehq.org/UnitTestSuites effort is to make it easy to write scripts that automate the building of windows apps on wine or windows interchangably. After a while of writing special purpose tool-install-scripts that would work on either wine or windows, I realized that I really just wanted winetricks to be my tool install script, and that it should run on windows. i.e. if you want firefox on windows or wine, you should be able to do "sh winetricks -q firefox" and have it appear. Likewise, if you happen to need the Windows 7 SDK for something you're building, you should be able to say "sh winetricks -q psdkwin7" and have it appear, no questions asked. (Assuming on windows that you have cygwin installed, of course.) So I'm starting to make that happen. Firefox works, psdkwin7 is not quite working, and lots of verbs that run windows apps still need their paths converted, but it shouldn't be hard to get your favorite verb working in both OS's now.

4 5

Re: Add dxdiag help message box
by Brian Nguyen 19 Sep '09

19 Sep '09

Hm, okay. I just wanted to test the waters here; I'll rework this to use a function that loads a string from a resource file. Does the help message itself look okay? I just used the message provided by the native dxdiag app, but I could rework it if there are issues with copyright or wine conventions. On Thu, Sep 17, 2009 at 6:34 AM, Henri Verbeet <hverbeet@...<http://www.nabble.com/user/SendEmail.jtp?type=post&post=25500104&i=0>> wrote: > 2009/9/17 Brian Nguyen <*mtxcoll*@...<http://www.nabble.com/user/SendEmail.jtp?type=post&post=25500104&i=1>>: >> +/* Thread-safe function for converting to wide char strings at runtime */ >> +LPWSTR PrintWide(LPWSTR buf, size_t len, const char *s) >> +{ >> + size_t i; >> + for (i = 0; i < len && *s != '\0'; i++, s++) { >> + buf[i] = *s; >> + } >> + return buf; >> +} > That doesn't do what you want, you should use MultiByteToWideChar() to > convert to WCHAR. However, I don't think you want to hardcode the > strings in the first place, you should load them from the resources so > they can be translated. Also, functions like that which are only used > in the current file should be static. Thanks for taking this on! -- -Austin -- Brian Nguyen mtxcoll(a)gmail.com

3 7

Fwd: Wine in Tango
by Reece Dunn 19 Sep '09

19 Sep '09

---------- Forwarded message ---------- From: Reece Dunn <msclrhd(a)googlemail.com> Date: 2009/9/19 Subject: Re: Wine in Tango To: Henri Verbeet <hverbeet(a)gmail.com> 2009/9/19 Henri Verbeet <hverbeet(a)gmail.com>: > 2009/9/19 Joel Holdsworth <joel(a)airwebreathe.org.uk>: >> On Sat, 2009-09-19 at 21:43 +0200, Henri Verbeet wrote: >>> 2009/9/19 Vitaliy Margolen <wine-devel(a)kievinfo.com>: >>> > - The European stop sign is not known/used in US. It has no meaning to most >>> > people. >>> Actually, assuming you mean >>> http://www.airwebreathe.org.uk/wine-icon/oic_hand-48.png, that's not a >>> stop sign in Europe either. It generally means "no entry", and I was >>> under the impression it's used in that way in the US as well. Not that >>> that makes it any more appropriate as an "error" sign. (Doesn't gnome >>> use that one as well though? I guess that would at least make it >>> recognizable to some people.) >> >> It's the dialog error icon from the Tango base set. Does that carry any >> weight? maybe... maybe not. It seemed clear enough to me though. >> > Possibly, consistency is generally a good thing. I can't say I pay a > whole lot of attention to the icons in messageboxes, but I could see > how this one wouldn't be entirely clear on its own to a new user. The > color red probably does more to convey the message "error" than the > sign. The error icon needs to be recognisable as well (aside from colour) for people with red-green colour blindness. A no entry sign doesn't really make sense here (although, it is the correct image from a tango perspective). Tango does have an unofficial (X) 'traditional' version (ref: http://commons.wikimedia.org/wiki/Tango_icons), so it would probably be better to use that instead. Not sure what the Oxygen icon looks like. ==== On the whole, these icons are a major improvement. Well done. Q: For the small 16x16 icons, why do some have the wine glass and some don't (for the ones that have a wine glass on the larger versions)? - Reece

1 0

Re: [(try 3) 3/3] opengl32/tests: Improve test for wglMakeCurrent.
by Paul Vriens 19 Sep '09

19 Sep '09

On 09/19/2009 12:29 PM, Rico Schüller wrote: > --- > dlls/opengl32/tests/opengl.c | 10 ++++++++++ > 1 files changed, 10 insertions(+), 0 deletions(-) > > > > ------------------------------------------------------------------------ > > + ret = wglMakeCurrent( NULL, NULL ); + ok( !ret, "wglMakeCurrent failed\n" ); shouldn't that message read "wglMakeCurrent succeeded" ? If you are testing the last error it's usually a good idea to set the last error before the call (aka "SetLastError(0xdeadbeef)"). -- Cheers, Paul.

4 4

Re: winex11: add alternative header
by Steven Edwards 19 Sep '09

19 Sep '09

2009/9/18 André Hentschel <nerv(a)dawncrow.de>: > this is my first patch to autoconf-stuff, please tell me if i did something wrong > see also Bug 20070 I expect It should actually not look like the following > #ifdef HAVE_X11_EXTENSIONS_XF86VMODE_H > #include <X11/extensions/xf86vmode.h> > +#elif defined (HAVE_X11_EXTENSIONS_XF86VMPROTO_H) > +#include <X11/extensions/xf86vmproto.h> > #endif and instead like this: #ifdef HAVE_X11_EXTENSIONS_XF86VMODE_H #include <X11/extensions/xf86vmode.h> #endif #ifdef HAVE_X11_EXTENSIONS_XF86VMPROTO_H #include <X11/extensions/xf86vmproto.h> #endif Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 2

[bugzilla] donate to sponsoring bug
by sacchi antonio 19 Sep '09

19 Sep '09

This idea was born because I'm not a developer but I want to help Wine, this is not a perfect idea, help me to make it better! Maybe this button will appear only on very few bugs/projects (2-3 max?) and money could go directly to Wine and after bug/project will be released/fixed money could go to people. Now Alexandre decides if a patch will be included or not, so I think he will have the task of deciding also money issue. Sorry for my english.. S.A. 2009/9/16 Tom Wickline <twickline(a)gmail.com>: > Hello, > > You could have the money go into the general WPF or WCF "Wine Conference > Fund" > But the problem is if say I donate $50.00 who's to say the bug I donate to > will be resolved > any time soon? Paypal only allows refunds up to 60 days, so how would you go > about a refund > if the bug wasn't fixed in say a year or more? > > I think it would be hard to keep everyone happy, because as soon as people > donate to a bug > their going to expect something in return. And a refund most likely if the > bug isn't fixed. > > Tom > > 2009/9/16 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se> >> >> I suppose that this only will appear on some bugs and disregarding that >> people might put off fixing bugs waiting for it to become a "pay-bug". >> Who's going to get the money? It seems quite common that people share >> credit on fixing bugs, should we burden Alexandre with the task of deciding >> that? >> Wouldn't this rather be on "projects", than bugs? The bug mentioned feels >> more like a "project". >> >> //Nicklas >> >> -----Original Message----- >> From: wine-devel-bounces(a)winehq.org on behalf of sacchi antonio >> Sent: Wed 2009-09-16 11:47 >> To: wine-devel(a)winehq.org >> Subject: [bugzilla] donate to sponsoring bug >> >> hello all. >> I'm new here but I'd like to suggest something, >> what do you think about this? >> http://img29.imageshack.us/img29/2940/wined.png >> >> Maybe it will be good for old/hard bugs? >> >> Thanks >> >> >> > > > > -- > http://www.wine-reviews.net/ > http://bordeauxgroup.com/ >

3 2

Add jscript component to Bugzilla?
by Ken Sharp 19 Sep '09

19 Sep '09

Any chance someone could add a jscript component to Bugzilla? It's used a decent amount to warrant it...

1 1

Re: [Bug 19523] winmm: Multiple waveOutOpen calls on single device supported by Windows, not Wine
by Ken Thomases 19 Sep '09

19 Sep '09

Taking this conversation out of the bug, since it seems I opened the bug in error and it should be closed. On Sep 19, 2009, at 2:29 AM, wine-bugs(a)winehq.org wrote: > http://bugs.winehq.org/show_bug.cgi?id=19523 > > --- Comment #3 from Eric Pouech <eric.pouech(a)orange.fr> 2009-09-19 > 02:28:51 --- > of course, there is... OK, in that case: a) that's good to know; and b) thanks for setting me straight. I might quibble with "of course", though. ;) > let's take the wave out driver interface as example: > > DWORD WINAPI wodMessage(UINT wDevID, UINT wMsg, DWORD_PTR dwUser, > DWORD_PTR dwParam1, DWORD_PTR dwParam2); > > in case wMsg in WODM_OPEN, dwUser is expected to be a pointer to a > DWORD, that > the driver is supposed to filled with a unique instance ID (to > identify the > stream) > > in other (subsequent) messages, winmm passes in dwUser the unique ID > defined by > the driver at WODM_OPEN time > > winmm correctly supports this scheme (see MMDRV_Open in dlls/winmm/ > lolvldrv.c) No offense, but looking at MMDRV_Open, it's clear as mud to me that dwDriverInstance has this meaning and corresponds to dwUser. Is there any documentation of the low-level driver interface? > but, none of the wine drivers correctly initialize the dwUser while > processing > the various XXXX_OPEN messages Does that mean this functionality is untested? Thanks again, Ken

3 3

Re: [(try 3) 1/3] wined3d: Don't call wglMakeCurrent(NULL, NULL) in context_set_current() if the current context is NULL.
by Rico Schüller 19 Sep '09

19 Sep '09

Am 19.09.2009 12:29, schrieb Rico Schüller: > Hi, > > this patch series fixes a bug which happens on windows with wined3d. > There a second call to wglMakeCurrent(NULL, NULL) fails, which will in > one case result in an early return in context_set_current(), which > doesn't set the the current context to NULL in such a case, but frees > the variable. So on the next call to context_set_current() (e.g. from > WineD3D_CreateFakeGLContext()) the memory in old->... could be some > other random memory and the app could crash. > > try 3 improvements: > - try 2 had the wrong test patch (3/3), so this time with the correct one > > try 2 improvements: > - moved the check from winex11.drv to gdi32 (because we don't need any > X11 functionality) > - order of patches changed > > The first patch fixes the behaviour in wined3d. The second one adds > the fix in gdi32 to change the behaviour to the one on xp. The third > patch adds a test case to opengl32/tests. > > Cheers > Rico > > --- > dlls/wined3d/context.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > > I have to add some more tests. I'll resend a better version of the patch set. Cheers Rico

1 0

cppcheck Sept 18
by chris ahrendt 19 Sep '09

19 Sep '09

[/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 chris

1 0

Re: clock: fix license in Swedish resources
by Austin English 18 Sep '09

18 Sep '09

2009/9/15 Austin English <austinenglish(a)gmail.com>: > Wine is LGPL, not GPL. Also, convert to UTF-8. > > -- > -Austin Something wrong with these two patches? -- -Austin

1 0

WineHQ Scheduled Downtime
by Jeremy Newman 18 Sep '09

18 Sep '09

WineHQ.org will be going off-line today starting at 14:30 US Central time. At this time we are performing hardware upgrades and maintenance. The system will be off-line from 20 minutes up to an hour. Services Affected: * WineHQ.org website * Bugzilla * Forums * AppDB * mailing lists * GIT and CVS -Newman

1 0

Re: [PATCH 1/3] winex11.drv: Check the current context in X11DRV_wglMakeCurrent().
by Roderick Colenbrander 18 Sep '09

18 Sep '09

Hi, I'm not sure if we should skip the glXMakeCurrent(null, null) call in GLX as in case of GLX it doesn't hurt. Second I'm not sure if we need to put the SetLastError code in winex11 or in gdi32/opengl.c. I think it should be in there as we don't need any X11 info. Roderick 2009/9/18 Rico Schüller <kgbricola(a)web.de>: > Hi, > > this patch series fixes a bug which happens on windows with wined3d. There a > second call to wglMakeCurrent(NULL, NULL) fails, which will in one case > result in an early return in context_set_current(), which doesn't set the > the current context to NULL in such a case, but frees the variable. So on > the next call to context_set_current() (e.g. from > WineD3D_CreateFakeGLContext()) the memory in old->... could be some other > random memory and the app could crash. > > The first patch adds a fix for winex11.drv to change the behaviour to the > one on xp. The second patch adds a test case to opengl32/tests. And the > third one fixes the behaviour in wined3d. > > Cheers > Rico > > --- > dlls/winex11.drv/opengl.c | 13 +++++++++++-- > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > > >

2 1

Re: gdi32/bitblt: GdiAlphaBlend - Check for NULL Pointer (incl. testcase)
by Paul Vriens 18 Sep '09

18 Sep '09

On 09/18/2009 01:42 PM, Markus Stockhausen wrote: > Hi, > > as I was encouraged to resent the patch from last week in git format I > hope it will be better this time. > > Best regards > > > ------------------------------------------------------------------------ > > Hi Markus, After reading this patch again, it seems to me it's not a 100% correct. There is a slight difference in passing hdcSrc as NULL compared to retrieving dcSrc via get_dc_ptr. The actual test sets hdcSrc to NULL, so the corresponding test in the implementation should be: if (!hdcSrc) return FALSE; dcSrc = get_dc_ptr ( hdcSrc ); Now, I don't know whether get_dc_ptr can fail but that's a different matter. -- Cheers, Paul.

2 3

Re: New testcase for creating nested storage objects
by Nikolay Sivov 18 Sep '09

18 Sep '09

Markus Stockhausen wrote: > Hi, > > attached you will find a new testcase that checks for differences > between Wine and Windows when handling reference counters for nested > storage objects. > > Best regards. > > Markus > Hi, Markus. Tests passes on XP, fails on current Wine. You should mark failing tests with todo_wine. Like that: > c1 = IStorage_AddRef(stg); > todo_wine ok(c1 == 2, "creating internal storage added > references to ancestor\n"); > c1 = IStorage_AddRef(stg); > IStorage_Release(stg2); > c2 = IStorage_AddRef(stg) - 1; > todo_wine ok(c1 == c2, "releasing internal storage > removed references to ancestor\n"); otherwise it will fail on Wine. Also give a more appropriate patch name and don't forget to add a prefix something like this: ole32/tests: Test for nested storages reference counting. P.S. git diff patch is preferable here. Thanks for your work.

2 2

glean and Piglit -- OpenGL driver testing
by Saulius Krasuckas 18 Sep '09

18 Sep '09

Today I saw two similar projects related to OpenGL: [1]: > glean is a suite of tools for evaluating the quality of an OpenGL > implementation and diagnosing any problems that are discovered. glean > also has the ability to compare two OpenGL implementations and highlight > the differences between them. It seems be having win32 port also. [2]: > Piglit is a collection of automated tests for OpenGL implementations. > > The goal of Piglit is to help improve the quality of open source OpenGL > drivers by providing developers with a simple means to perform > regression tests. > > Current status is that the framework is working (though rough at the > edges). It contains the Glean tests, some tests adapted from Mesa as > well as some specific regression tests for certain bugs. HTML summaries > can be generated (see below), including the ability to compare different > test runs. Could these be of any use for our graphic guys -- Stefan and co.? Then there is PerceptualDiff utility I found some time ago [3]. Guessed, could it also usefull for finding visual regressions of Wine? Probably not, as it seems to be used for testing video codecs (but I may be wrong): > PerceptualDiff is an image comparison utility that makes use of a > computational model of the human visual system to compare two images. > > So why would I use a program to tell me if two images are similar if I > can tell the difference myself by eyeballing it? > > Well the utility of this program really shines in the context of QA of > rendering algorithms. > > During regression testing of a renderer, hundreds of images are > generated from an older version of the renderer and are compared with a > newer version of the renderer. This program drastically reduces the > number of false positives (failures that are not actually failures) > caused by differences in random number generation, OS or machine > architecture differences. Also, you do not want a human looking at > hundreds of images when you can get the computer to do it for you > nightly on a cron job. [1] http://glean.sourceforge.net/whatis.html [2] http://people.freedesktop.org/~nh/piglit/ [3] http://pdiff.sourceforge.net/

4 5

Re: oledb32/tests: Add CanConvert tests.
by Paul Vriens 18 Sep '09

18 Sep '09

On 09/17/2009 03:35 PM, Huw Davies wrote: > --- > dlls/oledb32/tests/Makefile.in | 2 +- > dlls/oledb32/tests/convert.c | 76 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 77 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Huw, This introduces issues on (older) W2K systems and below. Do we need to add some kind of skip variable or just quit (with a win_skip) if the first one fails? We could also check the conversion 0000 -> 0087 as that seems to be common on all as a failure. If this conversion fails, bail out? Thoughts? -- Cheers, Paul.

1 0

Regression
by chris ahrendt 18 Sep '09

18 Sep '09

b5b58e423d32666581f69046c74bb19902c35c2b is first bad commit commit b5b58e423d32666581f69046c74bb19902c35c2b Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Thu Sep 17 12:35:24 2009 +0200 d3d8: Add a separate function for cube texture initialization. :040000 040000 8cd1752ed711799ebfb77127de399d527add5415 963c6467c8b4367b8a7bd1c1e4eece07937c13d6 M dlls [cahrendt@stinky wine-git]$ Chris

2 1

apply context draw buffer
by chris ahrendt 17 Sep '09

17 Sep '09

Something broke between yesterday's git tree and todays... went to run some applications and everything is slow as molasas... seems to be getting in a infinite loop in the apply context draw buffer

1 0

Re: Add dxdiag help message box
by Henri Verbeet 17 Sep '09

17 Sep '09

2009/9/17 Brian Nguyen <mtxcoll(a)gmail.com>: > +/* Thread-safe function for converting to wide char strings at runtime */ > +LPWSTR PrintWide(LPWSTR buf, size_t len, const char *s) > +{ > + size_t i; > + for (i = 0; i < len && *s != '\0'; i++, s++) { > + buf[i] = *s; > + } > + return buf; > +} That doesn't do what you want, you should use MultiByteToWideChar() to convert to WCHAR. However, I don't think you want to hardcode the strings in the first place, you should load them from the resources so they can be translated. Also, functions like that which are only used in the current file should be static.

2 1

Re: [1/5] mapi32: Scan registry for MAPI providers and load them
by Nikolay Sivov 17 Sep '09

17 Sep '09

Owen Rudge wrote: > --- > dlls/mapi32/Makefile.in | 2 +- > dlls/mapi32/mapi32_main.c | 5 +- > dlls/mapi32/util.c | 148 > +++++++++++++++++++++++++++++++++++++++++++++ > dlls/mapi32/util.h | 28 +++++++++ > 4 files changed, 181 insertions(+), 2 deletions(-) > create mode 100644 dlls/mapi32/util.h Hi. Few comments. > + > +static HMODULE mapi_provider = NULL; > +static HMODULE mapi_ex_provider = NULL; > + This is redundant, static will be initialized to zero anyway. > +static void load_mapi_provider(HKEY hkeyMail, LPCWSTR valueName, HMODULE *mapi_provider) > +{ > + static const WCHAR mapi32_dll[] = {'m','a','p','i','3','2','.','d','l','l',0 }; > + > + DWORD dwType, dwLen = 0; > + LPWSTR dllPath; > + > + if (!mapi_provider) > + return; > + I don't think this check is necessary, it's your internal helper. > +cleanUp: ; Semicolumn isn't needed here.

1 0

please test inconsistent WAVEFORMAT on MS-Windows (compiler needed)
by Joerg-Cyril.Hoehle＠t-systems.com 17 Sep '09

17 Sep '09

Hi, One MS-Windows machine passes all the attached tests, proving that MS-Windows ignores nBlockAlign and nAvgBytesPerSec. It would be helpful to get confirmation from more machines. Please build with the attached patch, execute it in interactive mode set WINETEST_INTERACTIVE=1 winetest.exe wave and listen to the sound and especially the pauses. OTOH, Wine fails at least one test: - One waveOutGetPosition test in WAVE_MAPPER fails. - My recently accepted patches (for OSS and CoreAudio) do something forbidden, that the test was written to reveal: they fix broken values in the WAVEFORMAT description, because both winmm and dsound depend on their correctness. But Wine should not touch user-supplied data. That is a todo_wine until dsound learns how to live with broken input. I'll add todo_wine before submitting these tests as a patch. Try this out with <= 1.1.29 (test with WINETEST_INTERACTIVE=1 make test) and you'll hear how Wine's winmm incorrectly computes the duration of the sound when given inconsistent format descriptions, causing silence where none should be, because MS-Windows does not care about BlockAlign and AvgBytesPerSec. With the upcoming 1.1.30, this will be corrected for OSS and CoreAudio, but not yet with the WAVE_MAPPER (ALSA is still broken). Regards, Jörg Höhle

1 0

Re: winetest: Add the ability to retrieve the dll path for com dlls from the registry.
by Paul Vriens 17 Sep '09

17 Sep '09

On 09/14/2009 03:10 PM, Huw Davies wrote: > --- > programs/winetest/main.c | 87 ++++++++++++++++++++++++++++++++++++++------- > 1 files changed, 73 insertions(+), 14 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Huw, Winetest doesn't do a complete run anymore (tested only on W2K3 and Vista) for now. It ends with a 998 error during enumeration of the test (oleaut32 being the last visible one). I'm crossbuilding a winetest as we speak but just thought I'd mention it. -- Cheers, Paul.

2 3

Re: user32: Skip STM_SETIMAGE message if the static control style doesnot match
by Dmitry Timoshkov 17 Sep '09

17 Sep '09

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > This style checking is needed to the STM_SETIMAGE message processing according > to MSDN: > > http://msdn.microsoft.com/en-us/library/bb760782%28VS.85%29.aspx This change requires a test case. -- Dmitry.

1 0

re: Disabling URL attachments.
by Dan Kegel 17 Sep '09

17 Sep '09

Done.

2 1

dstlen < 0 for MultiByteToWideChar / WideChatToMultiByte
by Michael Stefaniuc 17 Sep '09

17 Sep '09

Hello Detlef, although Smatch could have handled the task too of finding places where Wine passes -1 as destlen to MultiByteToWideChar / WideChatToMultiByte this can be done with the C compiler too. Please see the attached patch. This solution doesn't finds more occurrences that you have found and patched already. But this is really only the stuff that the compiler can figure out at compile time. It has no chance at all to catch stuff like void foo(int bar) { int dstlen = -1; if (bar) dstlen = 10; MultiByteToWideChar(a, b, c, d, e, dstlen) } Those can't be found by a grep either and I think that's why Alexandre is reluctant to apply your patches. bye michael

2 1

Disabling URL attachments.
by Vitaliy Margolen 17 Sep '09

17 Sep '09

Can Bugzilla admin please disable URL attachments? Number of users don't get the concept of what attachment is, and keep attaching urls to things like pastebin, or some file share servers. Instead of attaching actual files. Vitaliy.

1 0

Re: oleaut32: Fail the typelib test when LoadTypeLib fails.
by Jacek Caban 16 Sep '09

16 Sep '09

Hi Vincent, Vincent Povirk wrote: > > As far as I know, this failure only occurs when I do something stupid > like set use_midl_tlb to 1 and don't provide a working > midl_tmarshal.tlb, but I need the test to remind me that I'm an idiot > when I do that. Silently skipping tests is unacceptable. > While you are at this, it would be better to test the exact hr value, so the test should be: ok(hr == S_OK, ...). Jacek

1 0

Status of Quartz
by Keith Muir 16 Sep '09

16 Sep '09

what's the status of wine quartz.dll at present? reason I'm asking is because I'm trying to get a Computer based training(CBT) app Testout Navigator to run which uses Windows Media Player 9 to show videos. Using WINDEBUG with warn+dll seems to show most of the trouble is due to quartz.dll interaction with ntdll.dll Regards, Keith

1 0

Testcase for IStorage_CreateStorage
by Markus Stockhausen 16 Sep '09

16 Sep '09

Hi, as I'm still working on a resolution to bug #9575 I have digged into several directions. My current opinion is that IStorage_CreateStorage for some unkown reason increments the reference pointer of the associated IStorage object. In native Windows this is not the case. My 37th try in writing a Wine testcase resulted in the following code that hopefully shows the difference between the two environments. I put it somewhere in the storage32 tests to get it running. No warranty for side effects. static const WCHAR yyy[] = { 'x','.','t','x','t',0 }; r = StgOpenStorage( yyy, NULL, STGM_TRANSACTED | STGM_SHARE_EXCLUSIVE | STGM_READWRITE , NULL, 0, &stg); ok(r==S_OK, "StgCreateStorage failed\n"); if(stg) { static const WCHAR xxx[] = { 'D','a','t','a','S','p','a','c','e','I','n','f','o',0 }; IStorage_CreateStorage(stg,xxx,STGM_READWRITE | STGM_SHARE_EXCLUSIVE,0,0,&stg2); if (stg2) { r = IStorage_AddRef(stg); ok(r == 2, "WINE ERROR: refcount should be 2\n"); IStorage_Release(stg2); while ( r ) r=IStorage_Release(stg); } else { ok( 1 == 2, "IStorage::CreateStorage failed\n"); IStorage_Release(stg); } } If I got everything in the right place this test should fail on Wine wheres it will be ok in Windows. Before doing further research I hope someone of the experts can check if the test really reveals the source of the above mentioned bug. Thanks in advance.

1 0

now OSS driver emulation -- and other drivers too -- works as well as OSS HW mode; block size error gone?
by Joerg-Cyril.Hoehle＠t-systems.com 16 Sep '09

16 Sep '09

Hi, if your app worked well in OSS HW driver mode but not in emulation mode, the following patch may help you. For me, it fixed the following: - wrong playback speed in some apps (bug #19901); - spurious errors about block size: err:dsound:DSOUND_MixInBuffer length not a multiple of block size, len = 1579, block size = 2 - an assertion failure and crash (bug #12349): mixer.c:489: DSOUND_MixInBuffer: Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed. As the MacOS CoreAudio driver produces sound effects much like OSS emulation, a similar fix to wineCoreAudio.drv will certainly cure sound on the Mac, lifting some apps' rating from garbage to gold! diff --git a/dlls/wineoss.drv/audio.c b/dlls/wineoss.drv/audio.c index ca79cd5..9ef0d5b 100644 --- a/dlls/wineoss.drv/audio.c +++ b/dlls/wineoss.drv/audio.c @@ -2071,6 +2071,13 @@ static DWORD wodOpen(WORD wDevID, LPWAVEOPENDESC lpDesc, DWORD dwFlags) wwo->waveFormat.Format.nSamplesPerSec) / wwo->waveFormat.Format.nChannels; } + if (wwo->waveFormat.Format.nBlockAlign != wwo->waveFormat.Format.nChannels * + wwo->waveFormat.Format.wBitsPerSample / 8) { + WARN("Fixing BlockAlign\n"); + wwo->waveFormat.Format.nBlockAlign = wwo->waveFormat.Format.nChannels * + wwo->waveFormat.Format.wBitsPerSample / 8; + lpDesc->lpFormat->nBlockAlign=wwo->waveFormat.Format.nBlockAlign; /* see DirectSoundDevice_Create */ + } /* Read output space info for future reference */ if (ioctl(wwo->ossdev.fd, SNDCTL_DSP_GETOSPACE, &info) < 0) { ERR("ioctl(%s, SNDCTL_DSP_GETOSPACE) failed (%s)\n", wwo->ossdev.dev_name, strerror(errno)); The problem is that Wine depends on invariants about BlockAlign and AvgBytesPerSec but does not enforce them when presented incorrect data. MSDN says http://msdn.microsoft.com/en-us/library/bb669161(VS.85).aspx "If wFormatTag is WAVE_FORMAT_PCM or WAVE_FORMAT_EXTENSIBLE, nBlockAlign must be equal to the product of nChannels and wBitsPerSample divided by 8 (bits per byte). If wFormatTag is WAVE_FORMAT_PCM, nAvgBytesPerSec should be equal to the product of nSamplesPerSec and nBlockAlign." In the source base up to now, Wine only corrects the format in the OSS hardware mode. That's why OSS HW works well. It's too early to submit this as a patch as there are a few open issues: - Does the bogus data originate from the app or is some other function in Wine returning this data? A trace snippet from bug #19901 shows inconsistent data in the following call to SetFormat following device creation: PrimaryBufferImpl_Create (formattag=0x0001,chans=2,samplerate=44100,bytespersec=176400,blockalign=4,bitspersamp=16,cbSize=0) DSOUND_PrimarySetFormat (formattag=0x0001,chans=1,samplerate=22050,bytespersec=88200,blockalign=4,bitspersamp=16,cbSize=0) - Is there some central place in dsound for enforcing the invariant instead of identical code in the half dozen OSS/ALSA/CoreAudio/Jack etc. drivers? - Is the modification of the WAVEOPENDESC structure allowed, as it seems to be a user-supplied structure, which should be handled read-only? - Should the sound driver refuse to open when submitted such incorrect data? Possibly not. MSDN says about SetFormat http://msdn.microsoft.com/en-us/library/bb206041(VS.85).aspx "The method succeeds even if the hardware does not support the requested format; DirectSound sets the buffer to the closest supported format. To determine whether this has happened, an application can call the GetFormat ..." Thus, DS may set a format different from what was supplied. Presumably, BlockAlign and AvgBytesPerSec play a minor role, as they can be derived from the other values. Experimentally, I had wineoss.drv/audio.c:supportedformat() refuse inconsistent formats. Wine nevertheless played the app's sound at bogus speed after scanning all wineacm/mp3/xyz drivers (which it would not do otherwise), taking an execution path I've not yet analysed. - How does MS-Windows behave in the presence of bad data? Additional tests are needed. - I've not yet fixed the ALSA driver, but I expect similar improvements, at least in the emulation case, because the sound errors are the same in OSS and ALSA emulation modes. This is exciting news about progress in Wine sound issues! Bugzilla has errors about block size as old as 2005 still open. Regards, Jörg Höhle

2 4

Down to an average of 1% failures on my Windows boxes
by Paul Vriens 16 Sep '09

16 Sep '09

Hi, Just wanting to let you know that I'm down to 1% average failures on my Windows boxes (W95/W98/NT4/W2K/XP/W2K3/Vista). Short list: Sep-2009 : 1% Jun-2009 : 2% May-2009 : 3% Mar-2009 : 4% Feb-2009 : 5% So I doubt we get to zero before WineConf ;) -- Cheers, Paul.

1 0

CertGetPublicKeyLength() test failures on Win7
by Greg Geldorp 15 Sep '09

15 Sep '09

Hi Juan, I see 3 test failures related to CertGetPublicKeyLength() on Win7, crypt32/tests/cert.c lines 3146/3160/3165. All 3 failures are the same, CertGetPublicKeyLength() returns 0 with last error 0x80090004 (NTE_BAD_LEN). After looking at it for a while, I'm inclined to change the condition to ok(ret == 56 || (ok == 0 && GetLastError() == NTE_BAD_LEN), ...). Do you agree that's the correct fix or do I need to dig deeper? Thanks, Ge.

2 4

Wine at Ohloh
by Saulius Krasuckas 15 Sep '09

15 Sep '09

FYI, http://www.ohloh.net/p/wine/analyses/latest I wonder how do they find 27k lines of C++ code in Wine tree...

4 4

Re: [PATCH 2/2] dpwsockx: Implementation of Open callback
by Vitaliy Margolen 15 Sep '09

15 Sep '09

Ismael Barros wrote: > --- > +static DWORD WINAPI udp_listener_thread( LPVOID lpParameter ) > +{ > + for ( ;; ) > + { ..... > + } > +} You do not have exit from the loop. > + /* Launch thread */ > + listener->handle = CreateThread( NULL, 0, udp_listener_thread, > + listener, 0, NULL ); I haven't found the place where you closing this handle. > + /* Launch thread */ > + listener->handle = CreateThread( NULL, 0, > + ( is_tcp > + ? tcp_listener_thread > + : udp_listener_thread ), > + listener, 0, NULL ); Same here. Vitaliy.

3 7

re: [3/4] msi: GetDriveType and GetVolumeInformation require a path terminated by a slash.
by Dan Kegel 15 Sep '09

15 Sep '09

Don't changes like this need corresponding conformance tests? Likewise with "[4/4] msi: Don't append the cabinet file name in find_published_source."

2 1

How I create wine app launcher icons on the Mac
by Joerg-Cyril.Hoehle＠t-systems.com 15 Sep '09

15 Sep '09

Hi, On Linux, I have been using .desktop files that freedesktop defines to keep a directory full of icons. They all launch Wine applications. Often enough, these desktop files are initially create by Wine in ~/.local/share/applications/wine/..., along with the icon files in ~/.local/share/icons/. Here's how I now have app launcher icons on the Mac: sips -i ~/.local/share/icons/foo.png --out foo.png # sips -i converts and *additionaly* adds icon resource to file # Alas, sips does not understand .xpm cat sample.command > foo.png # > overwrites contents but keeps resource fork mv foo.png ~/Desktop/foo.command # .command is the finder's suffix for executable shell scripts chmod a+x foo.command sample.command contains: #!/bin/sh cd /User/me/xyz && WINEDEBUG=-gsm WINEPREFIX=$HOME/.wine exec wine xyz.exe Afterwards you edit foo.command and change the directory, environment variables and executable names to meet your needs. Be careful to use an editor that keeps the resource fork. "Opening" this icon will launch a Terminal where all logs will go. Optionally you may use Cmd-I(nformation) to disable the display of the .command suffix in the finder (unless forced globally). Wine's X11 window opens above the Terminal window. I wonder whether this functionality could be somehow integrated into the git (winemenubuilder?), or whether developers believe this should be left to "surrounding" projects like Darwine. What do you think? Jörg Höhle PS: You can wrap up the whole thing into a single shell script using the cat <<EOF syntax.

2 3

Re: [1/2] comctl32: Implement highlighting (marquee) selection support in listview
by Nikolay Sivov 14 Sep '09

14 Sep '09

Owen Rudge wrote: > These patches add support for selecting multiple items in a > multi-selection listview using the mouse (by dragging and highlighting). > > --- > dlls/comctl32/listview.c | 172 > ++++++++++++++++++++++++++++++++++++++++++---- > 1 files changed, 157 insertions(+), 15 deletions(-) Hi, Owen. Some comments. --- @@ -201,6 +201,7 @@ typedef struct tagITEM_INFO LPARAM lParam; INT iIndent; ITEM_ID *id; + UINT orig_state; /* state before highlighting operation begins */ } ITEM_INFO; --- Why do you need this restoring code? If you're starting selection box with some items selected they should be deselected if not Shift pressed and leaved untouched if Shift used. I don't see a reason to restore it - when you want to toggle selected state moving rectangle with Ctrl pressed you could just: LISTVIEW_GetItemState() and place inverted state with following LISTVIEW_SetItemState(). Also such large cycles shouldn't be used if you could manage not to use them. Currently we're not doing right sometimes with ownerdata lists which leads to huge response times (see http://bugs.winehq.org/show_bug.cgi?id=14303). Anyway this part: --- + /* Take a snapshot of all the item states */ + for (i = 0; i < infoPtr->nItemCount; i++) + { + hdpaSubItems = DPA_GetPtr(infoPtr->hdpaItems, i); + lpItem = DPA_GetPtr(hdpaSubItems, 0); + + if (lpItem) + lpItem->orig_state = lpItem->state; + } --- is wrong. You can't do it that way cause selected state could also be cached at parent side with corresponding callback bit set (look at LISTVIEW_GetItemT()). P.S. No need to split in two patches here, fist is useless if we can't see rectangle.

2 2

Re: [PATCH 1/1] winecoreaudio: make supported format test more restrictive
by Ken Thomases 14 Sep '09

14 Sep '09

On Sep 14, 2009, at 6:21 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> <Joerg-Cyril.Hoehle(a)t-systems.com > wrote: > supportedformat() has been in OSS' audio.c since 2004, so the > coreaudio driver was forked even before that time?!? Well, the CoreAudio driver was based on the ALSA driver. So, if ALSA was copied from the OSS driver before that change was made, then effectively, yes, the CoreAudio driver was forked before that time. -Ken

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel September 2009