September 2009 - Wine-Devel

Re: [try 3] comctl32: Implement highlighting (marquee) selection support in listview
by Nikolay Sivov Sept. 21, 2009

Sept. 21, 2009

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 Sept. 21, 2009

Sept. 21, 2009

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 Sept. 21, 2009

Sept. 21, 2009

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 Sept. 21, 2009

Sept. 21, 2009

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 Sept. 21, 2009

Sept. 21, 2009

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 Sept. 21, 2009

Sept. 21, 2009

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 Sept. 20, 2009

Sept. 20, 2009

-----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 Sept. 20, 2009

Sept. 20, 2009

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 Sept. 20, 2009

Sept. 20, 2009

[/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 Sept. 20, 2009

Sept. 20, 2009

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 Sept. 20, 2009

Sept. 20, 2009

>[/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 Sept. 19, 2009

Sept. 19, 2009

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 Sept. 19, 2009

Sept. 19, 2009

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(a)...<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 Sept. 19, 2009

Sept. 19, 2009

---------- 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 Sept. 19, 2009

Sept. 19, 2009

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 Sept. 19, 2009

Sept. 19, 2009

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 Sept. 19, 2009

Sept. 19, 2009

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 Sept. 19, 2009

Sept. 19, 2009

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 Sept. 19, 2009

Sept. 19, 2009

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 Sept. 19, 2009

Sept. 19, 2009

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 Sept. 18, 2009

Sept. 18, 2009

[/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 Sept. 18, 2009

Sept. 18, 2009

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 Sept. 18, 2009

Sept. 18, 2009

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 Sept. 18, 2009

Sept. 18, 2009

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 Sept. 18, 2009

Sept. 18, 2009

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 Sept. 18, 2009

Sept. 18, 2009

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 Sept. 18, 2009

Sept. 18, 2009

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 Sept. 18, 2009

Sept. 18, 2009

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 Sept. 17, 2009

Sept. 17, 2009

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(a)stinky wine-git]$ Chris

2 1

apply context draw buffer
by chris ahrendt Sept. 17, 2009

Sept. 17, 2009

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 Sept. 17, 2009

Sept. 17, 2009

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 Sept. 17, 2009

Sept. 17, 2009

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 Sept. 17, 2009

Sept. 17, 2009

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 Sept. 17, 2009

Sept. 17, 2009

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 Sept. 17, 2009

Sept. 17, 2009

"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 Sept. 16, 2009

Sept. 16, 2009

Done.

2 1

dstlen < 0 for MultiByteToWideChar / WideChatToMultiByte
by Michael Stefaniuc Sept. 16, 2009

Sept. 16, 2009

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 Sept. 16, 2009

Sept. 16, 2009

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 Sept. 16, 2009

Sept. 16, 2009

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 Sept. 16, 2009

Sept. 16, 2009

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 Sept. 16, 2009

Sept. 16, 2009

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 Sept. 16, 2009

Sept. 16, 2009

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 Sept. 16, 2009

Sept. 16, 2009

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 Sept. 15, 2009

Sept. 15, 2009

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 Sept. 15, 2009

Sept. 15, 2009

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 Sept. 15, 2009

Sept. 15, 2009

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 Sept. 15, 2009

Sept. 15, 2009

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 Sept. 15, 2009

Sept. 15, 2009

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 Sept. 14, 2009

Sept. 14, 2009

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 Sept. 14, 2009

Sept. 14, 2009

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

Re: ddraw: complete recognition of pixelformat 19: X8L8V8U8
by Stefan Dösinger Sept. 14, 2009

Sept. 14, 2009

Am Monday 14 September 2009 17:28:13 schrieb Joerg-Cyril.Hoehle(a)t-systems.com: > Hi, > > the argument for including this code is based on symmetry: Every place in > the Wine source tree (incl. ddraw, d3d9, wined3d) that handles L6V5U5 also > handles X8L8V8U8 -- except for these two places. So I closed the gap. > > This fixes > err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 19 > Please see bug #16559 for further discussion. > > Being based on the symmetry argument means this patch is completely > independent on possible missing conversions between D3DFMT and WINED3DFMT > codes somewhere in Wine. I would not eliminate that possibility. The above > error message that used to mention Pixelformats 62/63/64 nowadays mentions > 19/64/69/70. > > Regards, > Jörg Höhle The patch seems ok to me

1 0

Re: ntdll: Do not accept device control requests with invalid and/or incompatible handles
by Alexandre Julliard Sept. 14, 2009

Sept. 14, 2009

Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes: > +static void test_device_control(void) > +{ > + IO_STATUS_BLOCK io; > + NTSTATUS status; > + > + /* Try using a bugus handle for I/O control */ > + HANDLE handle = (HANDLE)0xdeadbeef; > + status = pNtDeviceIoControlFile(handle, NULL, NULL, NULL, &io, IOCTL_SERIAL_SET_BAUD_RATE, NULL, 0, NULL, 0); > + ok(status == STATUS_INVALID_HANDLE, "Expected %08X, got %08X\n", STATUS_INVALID_HANDLE, status); > + > + /* Try using an valid (but wrong) handle for I/O control */ > + handle = GetStdHandle(STD_INPUT_HANDLE); > + status = pNtDeviceIoControlFile(handle, NULL, NULL, NULL, &io, IOCTL_SERIAL_SET_BAUD_RATE, NULL, 0, NULL, 0); > + ok(status == STATUS_INVALID_HANDLE, "Expected %08X, got %08X\n", STATUS_INVALID_HANDLE, status); GetStdHandle returns a console handle which is not a valid ntdll handle, so you are not testing what you think. -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: Is Wine printing on MacOSX?
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 14, 2009

Sept. 14, 2009

Hi, Stefan Dösinger wrote: >>All that happened [with notepad] is that the printer ejected a blank page. >Printing from notepad works fine for me on both Linux and OSX, fwiw Saving to file instead of printing, notepad generated a .ps file. Reading this into Apple's preview shows the text. Converting to pdf, then viewing also shows the text. Printing this prints a blank page! So either Apple does not like the PS generated by Wine, or only the printer, or that's a problem with fonts or whatever else. I'm using a PPC driver for an old Lexmark Z33 printer that prints documents from TextEdit and Safari perfectly. I still need to test a wine application other than notepad. BTW, the page footer says "Page &p": &p is not substituted by notepad. Is this a known bug in notepad or Wine's printer driver? Regards, Jörg Höhle.

1 0

Re: [3/5] comctl32/dpa: Implement DPA_SaveStream() with tests
by Vitaliy Margolen Sept. 14, 2009

Sept. 14, 2009

Nikolay Sivov wrote: > Changelog: > - Implement DPA_SaveStream() with tests > > + streamData.dwSize = curr_pos.QuadPart - initial_pos.QuadPart; > + streamData.dwData2 = 1; > + streamData.dwItems = streamInfo.iPos;// + 1; c++ comment. > +#if 0 > + /* crashes on XP */ > + hRes = pDPA_SaveStream(NULL, CB_Save, pStm, NULL); > + expect(E_INVALIDARG, hRes); > + > + hRes = pDPA_SaveStream(dpa, CB_Save, NULL, NULL); > + expect(E_INVALIDARG, hRes); > +#endif Don't use #if 0 / #endif in tests. Use if (0){} instead. This will guarantee that code will still compile. Vitaliy.

2 1

Re: include: Add missing definitions in af_irda.h. (try 2)
by Alexandre Julliard Sept. 13, 2009

Sept. 13, 2009

Thomas Trummer <th.trummer(a)gmail.com> writes: > @@ -97,4 +100,159 @@ typedef struct _SOCKADDR_IRDA > #define LmCharSetISO_8859_9 0x09 > #define LmCharSetUNICODE 0xff > > +#define SIO_LAZY_DISCOVERY _IOR('t', 127, ULONG) > + > +#define WINDOWS_AF_IRDA 26 > +#define WINDOWS_PF_IRDA WINDOWS_AF_IRDA > + > +#define WCE_AF_IRDA 22 > +#define WCE_PF_IRDA WCE_AF_IRDA > + > +#ifndef AF_IRDA > +#define AF_IRDA WINDOWS_AF_IRDA > +#endif > + > +#ifndef PF_IRDA > +#define PF_IRDA AF_IRDA > +#endif > + > +#define IRDA_PROTO_SOCK_STREAM 1 You need a WS prefix on all definitions that can conflict with Unix. -- Alexandre Julliard julliard(a)winehq.org

4 4

Sept 11 with tools and tests removed
by chris ahrendt Sept. 13, 2009

Sept. 13, 2009

Here is the run for Friday Sept. 11 with the tools and the tests directory results removed. [/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/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

6 11

Re: wined3d: Add Intel GMA 4500MHD
by Stefan Dösinger Sept. 13, 2009

Sept. 13, 2009

Am Sunday 13 September 2009 08:15:19 schrieb Jaime Rave: > More information about Intel cards: > http://en.wikipedia.org/wiki/Intel_GMA#Table_of_GMA_graphics_cores_and_chip >sets + || strstr(gl_renderer, "Intel®")) I don't know if it is safe check for the ®. I think its not part of the standard ASCII character set, so there might be codepage issues. I don't think its necessary to check for it anyway, I think "Intel" is good enough. (In which case we might change the "Intel(R)" and "Intel Inc." checks as well) + if (strstr(gl_renderer, "GM45")) + { + /* GMA 4500MHD. These can take up to 2048MB */ + *vidmem = 512; + return CARD_INTEL_GM45; + } + You are adding trailing whitespace in the last line(I think Alexandre's commit scripts fiter that out though)

1 0

Re: wined3d: Add Intel GMA 4500MHD
by Roderick Colenbrander Sept. 13, 2009

Sept. 13, 2009

Just one minor thing make sure the right email address is configured in your git repository, so that the correct email address is set in the patch Roderick On Sun, Sep 13, 2009 at 8:15 AM, Jaime Rave <jaimerave(a)ubuntu-co.com> wrote: > More information about Intel > cards: http://en.wikipedia.org/wiki/Intel_GMA#Table_of_GMA_graphics_cores_and_chip… > > > >

1 0

Re: [ntdll] Add test for NtQueryDirectoryFile [try 2]
by James McKenzie Sept. 12, 2009

Sept. 12, 2009

Dan Kegel wrote: > Here's the next broken-out test patch from the series that > implements support for hidden and system attributes. > This one just adds a test for NtQueryDirectoryFile(). > It passes for me on Wine and Vista Home Basic. > > Changes since first try: > 1) fixed issues Paul found (wasn't setting hidden attribute, wasn't > cleaning up on failure) > 2) actually test reported file attributes > Dan: It looks like your original patch was approved by AJ in commit 398a8ea1fec599cfd6442e3b8bba620431cf53b7 You might want to run a diff against the current git. James McKenzie

2 1

Re: DDraw: Add a few missing WINAPIs
by Henri Verbeet Sept. 12, 2009

Sept. 12, 2009

2009/9/12 Stefan Dösinger <stefan(a)codeweavers.com>: > I wonder how this worked in the past, and why the compiler didn't complain. It's pretty simple really, these functions don't need WINAPI because they're ddraw internal functions "cleverly" disguised as vtable methods. IIRC it's actually harmful to add WINAPI to these on OS X due to some obscure compiler bug.

2 1

re: fixing ReadDirectoryChangesW()
by Dan Kegel Sept. 12, 2009

Sept. 12, 2009

Michael Pujos wrote: > I'm willing to resubmit this patch with updated tests > against current Wine, but before I procceed > I need to be sure it won't be rejected simply because it changes the protocol. Server changes are tricky to get in. You have to be patient and persistent. I think your best next move is to file a bug describing the problem (and give the URL for the app it affects for you, if possible), and submit just the tests first (with appropriate todo_wine lines where wine gets it wrong currently). All that is useful, and a good first step towards getting the bug fixed. Thanks! - Dan

3 2

Re: DDraw: Add a few missing WINAPIs
by Stefan Dösinger Sept. 12, 2009

Sept. 12, 2009

Am Saturday 12 September 2009 23:41:00 schrieb Stefan Dösinger: > Am Saturday 12 September 2009 23:25:56 schrieb Stefan Dösinger: > > Oops: forgot the patch: Er, never mind that patch - those functions aren't used directly in the vtable. There are the FPUSetup and FPUPreserve wrappers around them, so the default calling convention is ok.

1 0

RE: Help with a native Windows test program needed (CreateFileW).
by Markus Stockhausen Sept. 12, 2009

Sept. 12, 2009

Sorry for the the wrong feedback. As I have limited possibilites creating executables on Windows I relied on Thomas executable for the tests. Maybe you can post a corrected version. It is not my intention to confuse someone. Im just trying to narrow down my initial analysis. The last write access to the malicous memory address before the application dump comes from CreateFileW. Best regards. -------- Weitergeleitete Nachricht -------- Von: wine-bugs(a)winehq.org An: mst(a)collogia.de Betreff: [Bug 9575] IBExpert need windows native ole32.dll to run Datum: Sat, 12 Sep 2009 05:18:49 -0500 http://bugs.winehq.org/show_bug.cgi?id=9575 --- Comment #15 from Alexandre Julliard <julliard(a)winehq.org> 2009-09-12 05:18:42 --- There's no such behavior. The test is broken.

2 5

Re: [ntdll] Add test for NtQueryDirectoryFile
by Paul Vriens Sept. 12, 2009

Sept. 12, 2009

On 09/12/2009 02:18 AM, Dan Kegel wrote: > Here's the next broken-out test patch from the series that > implements support for hidden and system attributes. > This one just adds a test for NtQueryDirectoryFile(). > It passes for me on Wine and Vista Home Basic. > > [Paul, could you test it on your box to make sure it's ok there?] Hi Dan, No failures on my NT4+ boxes (32bit). One thing I noticed is that you don't cleanup in some of the failure cases which would leave that temporary directory around. -- Cheers, Paul.

1 2

Help with a native Windows test program needed (CreateFileW).
by Markus Stockhausen Sept. 12, 2009

Sept. 12, 2009

Hi, as I have no Windows machine and cannot test this. I'm in need for someone who can build a small exe that gives further hints to my observations in bug #9575. The following is needed: call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) Return the result of second call. I expect it to be a valid handle on Windows whereas Wine will return an invalid handle. Thanks in advance. Markus

2 3

RE: Help with a native Windows test program needed (CreateFileW)
by Greg Geldorp Sept. 11, 2009

Sept. 11, 2009

Hi Markus, > From: Markus Stockhausen <markus.stockhausen(a)collogia.de> > > as I have no Windows machine and cannot test this: I'm in need for > someone who can build a small exe that gives further hints to my > observations in bug #9575. The following is needed: > > call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) > call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) > > Return the result of second call. I expect it to be a valid handle on > Windows whereas Wine will return an invalid handle. This test program: int main(int argc, char *argv[]) { HANDLE File1, File2; File1 = CreateFileW(L"test.dat", GENERIC_READ, 0, NULL, CREATE_ALWAYS, 0, NULL); File2 = CreateFileW(L"test.dat", GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL); printf("File1 0x%x File2 0x%x error %u\n", File1, File2, GetLastError()); return 0; } returns this result on Windows 2008: File1 0x10 File2 0xffffffff error 32 so the second CreateFile fails on Windows too, with ERROR_SHARING_VIOLATION. Ge.

1 0

RFC: registry keys of serial ports
by Stefan Leichter Sept. 11, 2009

Sept. 11, 2009

Hi, i like to know what modifikations the attached patch needs to go into git. More things need to be done in this area. I know of: - more registry keys [1] - remove the registry keys when a serial port disappears (USB) - the links in the dosdevice directory needs to be created Patches for the items above will be created, when the current patch went into git References: 1 http://www.winehq.org/pipermail/wine-patches/2009-April/071999.html - http://www.winehq.org/pipermail/wine-devel/2009-April/074476.html -- Stefan

3 5

Help with a native Windows test program needed (CreateFileW)
by Markus Stockhausen Sept. 11, 2009

Sept. 11, 2009

Hi, as I have no Windows machine and cannot test this: I'm in need for someone who can build a small exe that gives further hints to my observations in bug #9575. The following is needed: call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...) Return the result of second call. I expect it to be a valid handle on Windows whereas Wine will return an invalid handle. Thanks in advance. Markus

2 1

fixing ReadDirectoryChangesW()
by Michael Pujos Sept. 11, 2009

Sept. 11, 2009

A few months ago I wrote a patch that addressed the following issues with ReadDirectoryChangesW(): "1. move and rename of files and directories in a monitored directory are not notified 2. the current implementation allow to only get one change (FILE_NOTIFY_INFORMATION structure) at a time. No change is actually lost but the calling application using ReadDirectoryChangesW() expect to retrieve all changes since the last call. With the current implementation it would only get the first and would have to call ReadDirectoryChangesW() again to get the other. With this patch , it gets all notification (as many consecutive FILE_NOTIFY_INFORMATION structs) since the last call to ReadDirectoryChangesW(). These move operations are implemented by this patch and conform to what win32 does: - Moving a directory or a file inside the monitored directory. A FILE_NOTIFY_INFORMATION structure with action FILE_ACTION_ADDED is returned - Moving a directory or a file out of the monitored directory. A FILE_NOTIFY_INFORMATION structure with action FILE_ACTION_REMOVED is returned - Renaming a directory or a file in the monitored directory. Two consecutive FILE_NOTIFY_INFORMATION structures with actions FILE_ACTION_RENAMED_OLD_NAME and FILE_ACTION_RENAMED_NEW_NAME are returned within the same reply. This can actually be done because issue 2 above is corrected." This old patch can be found here: http://bubbleguuum.free.fr/0001-server-implement-move-rename-change-notific… This patch modify the server protocol in server_protocol.h from struct read_change_reply { struct reply_header __header; int action; /* VARARG(name,string); */ }; to: struct read_change_reply { struct reply_header __header; int action_count; /* VARARG(name,string); */ }; I'm willing to resubmit this patch with updated tests against current Wine, but before I procceed I need to be sure it won't be rejected simply because it changes the protocol.

1 0

Re: [PATCH 2/4] mshtml: Added http loading test.
by Paul Vriens Sept. 11, 2009

Sept. 11, 2009

On 09/02/2009 12:27 PM, Jacek Caban wrote: > --- > dlls/mshtml/tests/htmldoc.c | 270 > +++++++++++++++++++++++++++++-------------- > 1 files changed, 182 insertions(+), 88 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Jacek, Looks like this one introduced 2 test failures on some boxes, I couldn't find a common denominator though. The failures happen on IE6, IE7 and IE8 on different platforms (NT4 and higher). There are however also IE8 boxes without failures. The failures seem to be triggered by the "test_download(FALSE, FALSE, FALSE);" on line 4026. Could you have a look? (Some other failures happen on ME and lower but I'll investigate those). -- Cheers, Paul.

2 1

Re: [ntdll] Add tests for NtQueryInformationFile
by Paul Vriens Sept. 11, 2009

Sept. 11, 2009

On 09/09/2009 02:41 PM, Dan Kegel wrote: > Alexandre said I should break up the big xattr patch, > so here are just the NtQueryInformationFile tests, > improved a bit. Once these are in I'll submit the > NtQueryDirectoryFile tests. > > Passes on both Wine and Vista. > > > ------------------------------------------------------------------------ > > Hi Dan, This patch introduces some issues on NT4 and higher. Attached patch fixes it but I'm not sure if you are already chasing these failures. Weird that it doesn't fail on your Vista box. That remark "whoops, vista doesn't implement this one?\n" should probably be changed. It also looks like Vista/Win7 has either 2 or 4 failures (most likely related to indexing being disabled, if so that could also happen on other platforms). Not sure if we should explicitly check for attributes being 2020, ignore FILE_ATTRIBUTE_NOT_CONTENT_INDEXED or just check as I did. -- Cheers, Paul.

2 4

Mirror Space
by Marty Cannon Sept. 11, 2009

Sept. 11, 2009

Hey guys, Since the wine.budgetdedicated.com server was down all weekend, I thought I'd offer an additional mirror location. I currently mirror several major linux distributions, and would love to contribute to something as valuable to the community as the wine project is. My site currently runs around 3500GB per month, so a few hundred GB worth of transfer shouldn't make much difference. I've never set up an apt mirror, but with some instruction and googling, I bet I can do it. At the very least, I can mirror the package archive just incase the main site goes down. Let me know how I can help. -Marty Cannon amarillolinux.com

6 12

Fixing the user32/dde tests on Win9x/WinMe
by Paul Vriens Sept. 11, 2009

Sept. 11, 2009

Hi, DdeInitializeW is not implemented on the mentioned platforms but it's not just a matter of skipping some tests when that W-function is found to be not implemented. Any idea what the best way would be to fix these tests? -- Cheers, Paul.

1 0

Re: bitblt.c - GdiAlphaBlend : Check for NULL Pointer
by Roderick Colenbrander Sept. 11, 2009

Sept. 11, 2009

Recently Nikolay Sivov wrote some tests for this call. His tests didn't make it in yet but I think those should enter and then based on those results changes should be made. Roderick On Thu, Sep 10, 2009 at 10:56 PM, Markus Stockhausen <markus.stockhausen(a)collogia.de> wrote: > Hi, > > http://bugs.winehq.org/show_bug.cgi?id=18041 reveals a bug where > GdiAlphaBlend will crash in Teamviewer application when a NULL pointer > is handed over. The attached check fixes that behaviour. > > Tanks in advance. > > Markus > > > > >

4 7

Status of LoadLibrary and .so
by Joe Dluzen Sept. 10, 2009

Sept. 10, 2009

Hi all, back a few years ago it didn't: http://www.winehq.org/pipermail/wine-devel/2003-July/018498.html Does anyone know of the status of LoadLibrary and a .so? Can it load directly or is there a workaround that does not involve multiple processes and some sort of IPC? thanks, Joe

3 2

Wineconf drumbeat - don't sleep on the streets!
by Jeremy White Sept. 10, 2009

Sept. 10, 2009

Hi Folks, It's now close enough to November that you can't blow this email off <grin>. We've got all the info here: http://wiki.winehq.org/WineConf2009 Our challenge this year is that we're managing the booking, so we need a firm head count ahead of time. Again, if money is an issue, and you haven't already, please contact me privately. So if you're thinking of coming, email Hans. Now. Please. Failure to do so may result in your sleeping on the streets of Enschede *grin*. Cheers, Jeremy

2 2

Re: [2/4] WineD3D: Make context_attach_surface_fbo srgb aware
by Henri Verbeet Sept. 10, 2009

Sept. 10, 2009

2009/9/10 Stefan Dösinger <stefan(a)codeweavers.com>: > @@ -402,7 +433,7 @@ static void context_apply_fbo_entry(struct wined3d_context *context, struct fbo_ > for (i = 0; i < GL_LIMITS(buffers); ++i) > { > IWineD3DSurface *render_target = device->render_targets[i]; > - context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, i, render_target); > + context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, i, render_target, SRGB_ANY); > } > > /* Apply depth targets */ I don't think SRGB_ANY is correct here. context_apply_fbo_entry() very much cares about which texture is attached to the FBO. If rendering to sRGB textures was supported properly this would depend on the sRGB write state, but since it isn't this should aways be SRGB_RGB. > @@ -2041,7 +2072,7 @@ struct wined3d_context *ActivateContext(IWineD3DDeviceImpl *This, IWineD3DSurfac > FIXME("Activating for CTXUSAGE_BLIT for an offscreen target with ORM_FBO. This should be avoided.\n"); > ENTER_GL(); > context_bind_fbo(context, GL_FRAMEBUFFER_EXT, &context->dst_fbo); > - context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, target); > + context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, target, SRGB_ANY); > context_attach_depth_stencil_fbo(context, GL_FRAMEBUFFER_EXT, NULL, FALSE); > LEAVE_GL(); > } else { Similar to above. > @@ -6045,7 +6045,7 @@ static void color_fill_fbo(IWineD3DDevice *iface, IWineD3DSurface *surface, > context = ActivateContext(This, NULL, CTXUSAGE_RESOURCELOAD); > ENTER_GL(); > context_bind_fbo(context, GL_FRAMEBUFFER_EXT, &context->dst_fbo); > - context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, surface); > + context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, surface, SRGB_ANY); > context_attach_depth_stencil_fbo(context, GL_FRAMEBUFFER_EXT, NULL, FALSE); > } Afaik color fill colors are specified in RGB space. Unless you have a test that shows otherwise, this should be SRGB_RGB. > @@ -6463,7 +6463,7 @@ void stretch_rect_fbo(IWineD3DDevice *iface, IWineD3DSurface *src_surface, WINED > TRACE("Source surface %p is offscreen\n", src_surface); > ENTER_GL(); > context_bind_fbo(context, GL_READ_FRAMEBUFFER_EXT, &context->src_fbo); > - context_attach_surface_fbo(context, GL_READ_FRAMEBUFFER_EXT, 0, src_surface); > + context_attach_surface_fbo(context, GL_READ_FRAMEBUFFER_EXT, 0, src_surface, SRGB_ANY); > glReadBuffer(GL_COLOR_ATTACHMENT0_EXT); > checkGLcall("glReadBuffer()"); > context_attach_depth_stencil_fbo(context, GL_READ_FRAMEBUFFER_EXT, NULL, FALSE); > @@ -6503,7 +6503,7 @@ void stretch_rect_fbo(IWineD3DDevice *iface, IWineD3DSurface *src_surface, WINED > > ENTER_GL(); > context_bind_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, &context->dst_fbo); > - context_attach_surface_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, 0, dst_surface); > + context_attach_surface_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, 0, dst_surface, SRGB_ANY); > glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT); > checkGLcall("glDrawBuffer()"); > context_attach_depth_stencil_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, NULL, FALSE); This doesn't work either. While it probably doesn't matter if the blit is done in RGB or sRGB space, it still needs to be the same color space for both surfaces (and one of those can be onscreen). On a higher level, I'm not really happy with how sRGB textures currently fit in and how that's starting to spread to everything that has to deal with surfaces.

2 1

Re: [3/4] WineD3D: Perform the srgb copy with fbo_blit if possible
by Henri Verbeet Sept. 10, 2009

Sept. 10, 2009

2009/9/10 Stefan Dösinger <stefan(a)codeweavers.com>: > + if (context->current_fbo) { > + context_bind_fbo(context, GL_FRAMEBUFFER_EXT, &context->current_fbo->id); > + } else { > + context_bind_fbo(context, GL_FRAMEBUFFER_EXT, NULL); > + } This shouldn't be needed. > + /* Need FBOs obviously */ > + if(wined3d_settings.offscreen_rendering_mode != ORM_FBO) return FALSE; > + /* Need framebuffer blit */ > + if(!GL_SUPPORT(EXT_FRAMEBUFFER_BLIT)) return FALSE; > + /* Need to be able to attach both RGB and sRGB copy */ > + if((fmt_flags & attach_flags) != attach_flags) return FALSE; > + /* Need to be able to blit from and to my format */ > + if(!surface_can_stretch_rect(This, This)) return FALSE; > + /* Need either RGB or sRGB copy up to date */ > + if((This->Flags & (SFLAG_INSRGBTEX | SFLAG_INTEXTURE)) == 0) return FALSE;That's redundant, Some of those are redundant. A format is never FBO attachable if FBOs are disabled, surface_can_stretch_rect() will already check for regular attachment.

1 0

Re: bitblt.c - GdiAlphaBlend : Check for NULL Pointer
by Paul Vriens Sept. 10, 2009

Sept. 10, 2009

On 09/10/2009 10:56 PM, Markus Stockhausen wrote: > Hi, > > http://bugs.winehq.org/show_bug.cgi?id=18041 reveals a bug where > GdiAlphaBlend will crash in Teamviewer application when a NULL pointer > is handed over. The attached check fixes that behaviour. > > Tanks in advance. > > Markus > > > > ------------------------------------------------------------------------ > > No comments on the validity of the patch but you should add a test for this to the conformance tests. If you are bailing out when dcSrc == NULL then the other checks in that function for dcSrc are not necessary anymore. -- Cheers, Paul.

1 0

Re: winehq: Fix some HTML markup
by Jeremy Newman Sept. 10, 2009

Sept. 10, 2009

The reason I left the XHTML markup in was eventually the goal was to convert the entire website to XHTML. The only issue with leaving them in while still in HTML4/Transitional is that the pages do not pass W3C validation. I am still willing to live with non-valid working HTML to save some work down the road. -N André Hentschel wrote: > --- > templates/de/about.template | 2 +- > templates/de/contributing.template | 8 +++--- > templates/de/download.template | 10 +++--- > templates/de/help.template | 16 ++++++------ > templates/en/about.template | 2 +- > templates/en/contributing.template | 8 +++--- > templates/en/documentation.template | 48 +++++++++++++++++----------------- > templates/en/download.template | 10 +++--- > templates/en/help.template | 16 ++++++------ > templates/fr/about.template | 2 +- > templates/pl/about.template | 2 +- > templates/pl/download.template | 10 +++--- > templates/pl/help.template | 16 ++++++------ > templates/pt/about.template | 2 +- > templates/pt/contributing.template | 8 +++--- > 15 files changed, 80 insertions(+), 80 deletions(-) > > > > > > ------------------------------------------------------------------------ > >

3 3

Asynchronus serial port
by Fenixk19 Sept. 10, 2009

Sept. 10, 2009

Hello! I've already post the bug(http://bugs.winehq.org/show_bug.cgi?id=19713) on this subject, but i need more help. So I've decided to write here. There is a problem in wine. When I use asynchronous serial port read, data never comes. Event, caused by select comes. But operation status stays pending, and i can't do anything to this serial port anymore. In windows it never get pending, and port can be accessed just after data arrival. Seems to be wineserver problem, but i don't know, where to look at. What code respond for asynchronous serial port in wineserver? Alexander. P.S. Test program attached.

4 4

Re: [PATCH 12/12] openal32: fixed ctx null ptr debug (Coverity)
by Chris Robinson Sept. 10, 2009

Sept. 10, 2009

I have a different patch that will fix this, that also fixes a problem with error states.

1 0

Re: server: Use kernel support for thread affinity when available
by Chris Robinson Sept. 10, 2009

Sept. 10, 2009

On Thursday 10 September 2009 9:43:02 am Juan Lang wrote: > +/* Define to 1 if you have the `sched_getaffinity' function. */ > +#undef HAVE_SCHED_GETAFFINITY > + ... > +#ifdef HAVE_SCHED_GET_AFFINITY > +#define __USE_GNU > +#include <sched.h> > +#endif Looks like a typo there.

1 0

Re: winex11: Make X11DRV_PALETTE_ComputeColorShifts() static.
by Roderick Colenbrander Sept. 10, 2009

Sept. 10, 2009

In a next patch ComputeChannelShift will be called from outside palette.c and for this reason I made it non-static. Roderick On Thu, Sep 10, 2009 at 5:58 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/winex11.drv/palette.c | 115 ++++++++++++++++++++++---------------------- > dlls/winex11.drv/x11drv.h | 1 - > 2 files changed, 57 insertions(+), 59 deletions(-) > > diff --git a/dlls/winex11.drv/palette.c b/dlls/winex11.drv/palette.c > index 81bb73b..cdbfb21 100644 > --- a/dlls/winex11.drv/palette.c > +++ b/dlls/winex11.drv/palette.c > @@ -131,6 +131,63 @@ static void palette_set_mapping( HPALETTE hpal, int *mapping ) > wine_tsx11_unlock(); > } > > +/*********************************************************************** > + * X11DRV_PALETTE_ComputeChannelShift > + * > + * Calculate conversion parameters for a given color mask > + */ > +static void X11DRV_PALETTE_ComputeChannelShift(unsigned long maskbits, ChannelShift *physical, ChannelShift *to_logical) > +{ > + int i; > + > + if (maskbits==0) > + { > + physical->shift=0; > + physical->scale=0; > + physical->max=0; > + to_logical->shift=0; > + to_logical->scale=0; > + to_logical->max=0; > + return; > + } > + > + for(i=0;!(maskbits&1);i++) > + maskbits >>= 1; > + > + physical->shift = i; > + physical->max = maskbits; > + > + for(i=0;maskbits!=0;i++) > + maskbits >>= 1; > + physical->scale = i; > + > + if (physical->scale>8) > + { > + /* On FreeBSD, VNC's default 32bpp mode is bgrabb (ffc00000,3ff800,7ff)! > + * So we adjust the shifts to also normalize the color fields to > + * the Win32 standard of 8 bits per color. > + */ > + to_logical->shift=physical->shift+(physical->scale-8); > + to_logical->scale=8; > + to_logical->max=0xff; > + } else { > + to_logical->shift=physical->shift; > + to_logical->scale=physical->scale; > + to_logical->max=physical->max; > + } > +} > + > +/*********************************************************************** > + * X11DRV_PALETTE_ComputeColorShifts > + * > + * Calculate conversion parameters for a given color > + */ > +static void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask) > +{ > + X11DRV_PALETTE_ComputeChannelShift(redMask, &shifts->physicalRed, &shifts->logicalRed); > + X11DRV_PALETTE_ComputeChannelShift(greenMask, &shifts->physicalGreen, &shifts->logicalGreen); > + X11DRV_PALETTE_ComputeChannelShift(blueMask, &shifts->physicalBlue, &shifts->logicalBlue); > +} > > /*********************************************************************** > * COLOR_Init > @@ -278,64 +335,6 @@ void X11DRV_PALETTE_Cleanup(void) > } > > /*********************************************************************** > - * X11DRV_PALETTE_ComputeChannelShift > - * > - * Calculate conversion parameters for a given color mask > - */ > -static void X11DRV_PALETTE_ComputeChannelShift(unsigned long maskbits, ChannelShift *physical, ChannelShift *to_logical) > -{ > - int i; > - > - if (maskbits==0) > - { > - physical->shift=0; > - physical->scale=0; > - physical->max=0; > - to_logical->shift=0; > - to_logical->scale=0; > - to_logical->max=0; > - return; > - } > - > - for(i=0;!(maskbits&1);i++) > - maskbits >>= 1; > - > - physical->shift = i; > - physical->max = maskbits; > - > - for(i=0;maskbits!=0;i++) > - maskbits >>= 1; > - physical->scale = i; > - > - if (physical->scale>8) > - { > - /* On FreeBSD, VNC's default 32bpp mode is bgrabb (ffc00000,3ff800,7ff)! > - * So we adjust the shifts to also normalize the color fields to > - * the Win32 standard of 8 bits per color. > - */ > - to_logical->shift=physical->shift+(physical->scale-8); > - to_logical->scale=8; > - to_logical->max=0xff; > - } else { > - to_logical->shift=physical->shift; > - to_logical->scale=physical->scale; > - to_logical->max=physical->max; > - } > -} > - > -/*********************************************************************** > - * X11DRV_PALETTE_ComputeColorShifts > - * > - * Calculate conversion parameters for a given color > - */ > -void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask) > -{ > - X11DRV_PALETTE_ComputeChannelShift(redMask, &shifts->physicalRed, &shifts->logicalRed); > - X11DRV_PALETTE_ComputeChannelShift(greenMask, &shifts->physicalGreen, &shifts->logicalGreen); > - X11DRV_PALETTE_ComputeChannelShift(blueMask, &shifts->physicalBlue, &shifts->logicalBlue); > -} > - > -/*********************************************************************** > * X11DRV_PALETTE_BuildPrivateMap > * > * Allocate colorcells and initialize mapping tables. > diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h > index 62b0d63..844af31 100644 > --- a/dlls/winex11.drv/x11drv.h > +++ b/dlls/winex11.drv/x11drv.h > @@ -494,7 +494,6 @@ extern BOOL X11DRV_IsSolidColor(COLORREF color); > extern COLORREF X11DRV_PALETTE_ToLogical(X11DRV_PDEVICE *physDev, int pixel); > extern int X11DRV_PALETTE_ToPhysical(X11DRV_PDEVICE *physDev, COLORREF color); > extern int X11DRV_PALETTE_LookupPixel(COLORREF color); > -extern void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask); > > extern unsigned int depth_to_bpp( unsigned int depth ); > > -- > 1.6.3.3 > > >

1 0

Re: mshtml: Add support for Reference BSTR when setting styles.
by Paul Vriens Sept. 10, 2009

Sept. 10, 2009

On 09/10/2009 12:00 PM, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > mshtml: Add support for Reference BSTR when setting styles. > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > > Hi Alistair, Now VT_BSTR is used in two case-statements. -- Cheers, Paul.

1 1

Re: msi: Ignore CoInitialize failure in ACTION_CreateShortcuts.
by Hans Leidekker Sept. 10, 2009

Sept. 10, 2009

> Fixes http://bugs.winehq.org/show_bug.cgi?id=19636 Or it doesn't: err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded err:shell:ShellLink_QueryInterface -- Interface: E_NOINTERFACE Because IShellLink is apartment-threaded only? -Hans

1 0

Performance tag for Bugzilla?
by Scott Ritchie Sept. 9, 2009

Sept. 9, 2009

We have a wiki page functioning as sort of a wannabe performance tag here: http://wiki.winehq.org/Performance-related_bugs Is this a reasonable tag to have? Thanks, Scott Ritchie

1 0

http://bugs.winehq.org/show_bug.cgi?id=18337
by Frank Gruman Sept. 9, 2009

Sept. 9, 2009

I have been using wine for various tools and utilities at work and home for some time now. Recently I tried to use wine to run the VMware Infrastructure Client and ran into bug 18337 (http://bugs.winehq.org/show_bug.cgi?id=18337) I am pasting my comments on that bug here to avoid repetition (http://bugs.winehq.org/show_bug.cgi?id=18337#c4) <paste> So - I looked through the code (current git @1.1.29) and compared to the 1.0 release (because of comment 1) and did not see that CERT_CHAIN_POLICY_SSL was ever implemented. Looking at chain.c, line 1886-1902 I can see the switch-case statement where this would have been handled. The problem I ran into while trying to keep up with the code was figuring out what the verify_* methods are trying to do. I'd really like to see this work and may have some spare cycles to help out. The problem is that I don't understand everything happening in these methods - can I get some pointers to what is happening or what should happen in the yet to be created verify_ssl_policy() method? </paste> Regards, Frank

2 3

ddraw: Added support for WINED3DFMT_X8L8V8U8, WINED3DFMT_R8G8B8A8_SNORM and WINED3DFMT_R16G16_SNORM to PixelFormat_WineD3DtoDD
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 9, 2009

Sept. 9, 2009

Stephan, All the patches proposed to bug #16559 forget one thing: it cannot be right to patch only PixelFormat_WineD3DtoDD without patching its converse function in the same file, PixelFormat_DD2WineD3D. There's no gain in silencing a fixme by introducing internal inconsistency in the source code. I had my own patch which changed both but for X8L8V8U8 only, but never published it because I observed no visual difference in the one app I tested, and had no time for 3 other ones I own, nor the other formats. I'm left wondering which of the pixelformats actually produces a visual difference as e.g. in comment #27. BTW, I suggest you submit individual patches, one per format. Regards, Jörg Höhle

2 1

Re: CPPCheck for Sept 8th
by chris ahrendt Sept. 9, 2009

Sept. 9, 2009

Nicolas Le Cam wrote: > 2009/9/9 Alexandre Julliard <julliard(a)winehq.org>: >> chris ahrendt <celticht32(a)yahoo.com> writes: >> >>> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd >> This is the only one that looks a real bug, all the rest are false >> positives. Please filter them out from future reports. >> >> -- >> Alexandre Julliard >> julliard(a)winehq.org >> >> >> > > Not necessary false positives. Errors in dlls/msvcrt/tests/file.c, for > example, are real but expected errors, as it's the purpose of the test > to see how it behaves on Windows in such situation. > So continue to send everything then? Since I have been running them the size has not really been that large... just let me know what you want me to send and I will send it in... Chris

2 1

CPPCheck for Sept 8th
by chris ahrendt Sept. 9, 2009

Sept. 9, 2009

[/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd [/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/wineoss.drv/mmaux.c:146]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource leak: mixer [/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 [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map This is using thursdays git tree of CPPCheck.. please let me know if there are FP's so I can report them. Chris p.s. Thanks stephan for pointing out I sent it to the wrong list =D

3 2

Re: CPPCheck for Sept 8th
by chris ahrendt Sept. 9, 2009

Sept. 9, 2009

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd > > This is the only one that looks a real bug, all the rest are false > positives. Please filter them out from future reports. > Is there any others? So ignore the tests findings and the tools findings? Are These the ones that may be a bug then : [/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/wineoss.drv/mmaux.c:146]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource leak: mixer [/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 These Ignore correct? [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map Chris

1 0

Re: CPPCheck for Sept 8th
by chris ahrendt Sept. 9, 2009

Sept. 9, 2009

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd > > This is the only one that looks a real bug, all the rest are false > positives. Please filter them out from future reports. > Alexandre, I will filter them as best I can going forward... Chris

1 0

Re: CPP Run for Sept 8
by Stefan Dösinger Sept. 9, 2009

Sept. 9, 2009

hi, I think its better to send these reports to wine-devel instead of wine-patches

1 0

Re: gdi32/tests: Some GdiAlphaBlend tests
by Roderick Colenbrander Sept. 9, 2009

Sept. 9, 2009

Regarding the zero source DC, what happens visually? On Wed, Sep 9, 2009 at 1:30 PM, Nikolay Sivov<bunglehead(a)gmail.com> wrote: > Bug http://bugs.winehq.org/show_bug.cgi?id=18041 shows this commented crash. > I'm not sure how to fix it, but I think this call can't do anything > without source context. > > Another question is where to place such check - in gdi32 or winex11...any > advices are welcome. > > Changelog: > - Some GdiAlphaBlend tests > > >From a59cadcf03edeefff95c340230a47c9c3c60727f Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Wed, 9 Sep 2009 15:20:34 +0400 > Subject: Some GdiAlphaBlend tests > > --- > dlls/gdi32/tests/bitmap.c | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdi32/tests/bitmap.c b/dlls/gdi32/tests/bitmap.c > index 8666da2..38acd09 100644 > --- a/dlls/gdi32/tests/bitmap.c > +++ b/dlls/gdi32/tests/bitmap.c > @@ -2376,6 +2376,25 @@ static void test_GdiAlphaBlend(void) > blend.SourceConstantAlpha = 128; > blend.AlphaFormat = 0; > > + /* zero dimensions */ > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 0, 0, hdcSrc, 0, 0, 20, 20, blend), TRUE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, 0, 0, 0, 0, blend), TRUE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > + > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 0, 0, hdcSrc, 0, 0, 0, 0, blend), TRUE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > + > +#if 0 > + /* zero source HDC - crashes on wine, works on native */ > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, NULL, 0, 0, 20, 20, blend), FALSE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > +#endif > + > expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, 0, 0, 20, 20, blend), TRUE, BOOL, "%d"); > SetLastError(0xdeadbeef); > expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, -1, 0, 10, 10, blend), FALSE, BOOL, "%d"); > -- > 1.5.6.5 > > > > >

2 1

Re: mfc42: Stub implementation with the message where to get it from
by Alexandre Julliard Sept. 9, 2009

Sept. 9, 2009

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > This is more of the testing waters type of patch. If this approach is > fine then we can do the same for all other dlls that are shipped with > Windows but not really a part of an O/S. I don't think you can put up a message box on attach, that could potentially become very annoying since it will trigger also for version checks etc. That sort of thing should be done at the loader level. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: gdi32: Handle OEM_CHARSET
by Dmitry Timoshkov Sept. 9, 2009

Sept. 9, 2009

"Vladimir Pankratov" <scriptkid(a)mail.ru> wrote: > --- a/dlls/gdi32/freetype.c 2009-08-08 13:27:23.000000000 +0500 > +++ b/dlls/gdi32/freetype.c 2009-09-07 19:58:58.000000000 +0500 > @@ -3576,6 +3576,7 @@ > if(!TranslateCharsetInfo((DWORD*)(INT_PTR)lf.lfCharSet, &csi, TCI_SRCCHARSET)) { > switch(lf.lfCharSet) { > case DEFAULT_CHARSET: > + case OEM_CHARSET: > csi.fs.fsCsb[0] = 0; > break; > default: How is this different from the default case? -- Dmitry.

2 1

Re: [PATCH 02/10] d3d10: Implement annotation parsing.
by Henri Verbeet Sept. 9, 2009

Sept. 9, 2009

2009/9/9 Rico Schüller <kgbricola(a)web.de>: > -static void parse_fx10_annotation(const char **ptr) > +static HRESULT parse_fx10_annotation(struct d3d10_effect_variable *a, const char **ptr, const char *data) > { > - skip_dword_unknown(ptr, 3); > + DWORD offset; > + > + read_dword(ptr, &offset); > + TRACE("Annotation name at offset %#x.\n", offset); > + > + a->name = copy_name(data + offset); > + if (!a->name) > + { > + ERR("Failed to copy name.\n"); > + return E_OUTOFMEMORY; > + } > + TRACE("Annotation name: %s.\n", a->name); > + > + read_dword(ptr, &offset); > + TRACE("Annotation type info at offset %#x.\n", offset); > + > + a->type = get_fx10_type(a->effect, data, offset); > + if (!a->type) > + { > + ERR("Failed to get variable type.\n"); > + return E_FAIL; > + } > + > + skip_dword_unknown(ptr, 1); > + > + return S_OK; > } It seems to me that this is just the same code for parsing variables (that has implications for 1/10 as well).

2 1

Re: msxml3: Add IDispatchEx support to IXMLDOMElement (resend 2)
by Alexandre Julliard Sept. 9, 2009

Sept. 9, 2009

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > Feedback if something is wrong would be great. domdoc.c:601: warning: ISO C90 forbids mixed declarations and code -- Alexandre Julliard julliard(a)winehq.org

1 0

Google Summer of Code mentor summit Oct 24th-25th
by Kai Blin Sept. 9, 2009

Sept. 9, 2009

Hi folks, Wine gets to send two delegates to the Google Summer of Code mentor summit in Mountain View, CA, this October. Is anybody who mentored interested in going? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0