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

Fw : BOOL WINAPI versus BOOL in d3dx9 and d3dx8
by paulo lesgaz 01 Feb '09

01 Feb '09

Hi, the declaration of IntersectionTri is BOOL IntersectionTri(.....) in d3dx8mesh.h and BOOL WINAPI IntersectionTri(.....) in d3dx9mesh.h . Is the latter one compatible with the former one (so I can forward d3dx9 function to the d3dx8 one) or must I implement them separately? David

1 0

Running the fusion tests
by Paul Vriens 31 Jan '09

31 Jan '09

Hi, I didn't look into this yet but currently the fusion tests are only run on Wine. I can happily run the fusion tests on my XP box if I just crossbuild these tests. It's only when run through winetest that these tests are not run. I guess it has to do with how this library should be loaded (not directly through LoadLibrary)? -- Cheers, Paul.

1 0

Reliable Datagram / Stream behaviour of NT Pipes
by Luke Kenneth Casson Leighton 31 Jan '09

31 Jan '09

folks, hi, if you recall, i implemented nt named pipes in samba tng, and also implemented the use of nt named pipes as a transport in freedce, for when i ported freedce to win32. so i have quite a bit of experience when it comes to nt named pipes. i've encountered some bugs (thanks to python again :) ) in the wine implementation of nt named pipes, and have raised it as a bug http://bugs.winehq.org/show_bug.cgi?id=17195 but it started getting complicated so i thought i'd best raise it here. the behaviour of nt named pipes is a cross between datagrams and streams - it's the best of both worlds: * absolute inviolate message sizes (datagrams) * absolute inviolate message order (streams). the issue with the implementation of nt named pipes on top of _just_ streams (unix sockets) is this: two packets sent get blatted into one read. you _cannot_ allow this to happen - it screws applications up _royally_, as applications _critically_ depend on the number of reads and writes being interleaved, thanks to the characteristics of NamedPipes. standard unix applications / protocols (SMTP, etc) have no choice but to do manual synchronisation built-in to the protocol, because standard unix streams don't _have_ this "free feature". so, in samba tng, the emulated-implementation of nt named pipes (on top of unix sockets) i was forced to send a (32-bit) length field actually _in_ the data stream, just like is done in NetBIOS. the NetBIOS protocol (which was implemented by IBM, not microsoft) sends a 16-bit length field followed by that exact number of bytes. again, NetBIOS implements a "reliable datagram-stream" protocol on top of standard unix streams (tcp stream, this time) inexplicably, unix simply... is ... entirely... missing this concept. so, i'm sorry to have to tell you this, but you are absolutely forced to emulate it (by sending length, data, length data), just like everyone else ever has. so, send (write) is simple: write out the length field, write out the data. done. dead simple. read is... tricky. you _may_ have to keep track of having read the length, already. or, of how _much_ has been read already, of the "current packet being read". .... *walks through source code a bit...* ... i'm veery tempted to say "can i have a go at implementing this?" but... i know it'll be ... how-to-say... eeenteresting :) should i try? would an extra server message need to be added (for read), so that the server can keep track of how much data has been read back (of the current datagram)? l.

2 3

New Coverity run
by Paul Vriens 31 Jan '09

31 Jan '09

Hi, I've been in touch with David Maxwell and he looked into the 'lack' of reports since the end of October. -- Cheers, Paul.

2 2

Re: gdi32: Remove unneeded check. (Coverity)
by Rob Shearman 31 Jan '09

31 Jan '09

2009/1/27 Kai Blin <kai.blin(a)gmail.com>: > > lcdfilter = FT_LCD_FILTER_DEFAULT is hardcoded, so the check is always true. > > This fixes Coverity CID 816 > > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c > index 1ca6953..dfbcf2f 100644 > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -4783,18 +4783,15 @@ DWORD WineEngGetGlyphOutline(GdiFont *incoming_font, UINT glyph, UINT format, > (format == WINE_GGO_HRGB_BITMAP || format == WINE_GGO_HBGR_BITMAP)? > FT_RENDER_MODE_LCD: FT_RENDER_MODE_LCD_V; > > - if ( lcdfilter == FT_LCD_FILTER_DEFAULT || lcdfilter == FT_LCD_FILTER_LIGHT ) > + if ( render_mode == FT_RENDER_MODE_LCD) > { > - if ( render_mode == FT_RENDER_MODE_LCD) > - { > - lpgm->gmBlackBoxX += 2; > - lpgm->gmptGlyphOrigin.x -= 1; > - } > - else > - { > - lpgm->gmBlackBoxY += 2; > - lpgm->gmptGlyphOrigin.y += 1; > - } > + lpgm->gmBlackBoxX += 2; > + lpgm->gmptGlyphOrigin.x -= 1; > + } > + else > + { > + lpgm->gmBlackBoxY += 2; > + lpgm->gmptGlyphOrigin.y += 1; > } > > width = lpgm->gmBlackBoxX; It doesn't make much sense to leave the lcdfilter variable in the function if you're going to remove the if condition depending on it, since it only has one other use. However, It might have been the intention of the author of this code that this is setting to be changed at compile time (or runtime through a registry tweak) and have the code do the appropriate thing - in that case it would have been better to put the variable at the top of the file. -- Rob Shearman

3 2

Re: msadp32.acm : block align and adpcm extra data
by Vincent Pelletier 31 Jan '09

31 Jan '09

Le Thursday 22 January 2009 16:25:42 Stefano Guidoni, vous avez écrit : > This patch solves bug 7385: > Function ADPCM_StreamSize must return a > buffer size, which is a multiple of block align. > This buffer size is > calculated taking into account input-blockalign, output-blockalign and > adpcm-samplesperblock. Hi. Excuse me for contacting you directly, but that patch didn't enter the source tree, because of the "while" loops. I've been trying for hours to guess by trial and (tons of) error the right formula not involving any "magic" number (besides 7, which is the number of bytes per channel in adpcm block header afaik), but I could not reach the right result: after ~ten seconds, the result of my computation diverges from yours, and audio starts repeating/skipping. Probably operation rounding errors. and/or integer overflows. Could you explain me how you reached that formula ? Mainly, I don't understand why there is no trace of the number of samples per seconds, nor why you multiply a plock align with another block align in the denominator of source size computation when source is adpcm. By advance, many thanks for enlightening me. -- Vincent Pelletier

1 0

request for windows test: GetPrivateProfileSectionNamesA
by Marcus Meissner 31 Jan '09

31 Jan '09

Hi, Could someone please test those, I want to see if the second or third crash on Windows to handle those borderline cases. Ciao & Thanks, Marcus --- dlls/kernel32/tests/profile.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/dlls/kernel32/tests/profile.c b/dlls/kernel32/tests/profile.c index 5292c33..feeb7b2 100644 --- a/dlls/kernel32/tests/profile.c +++ b/dlls/kernel32/tests/profile.c @@ -214,6 +214,13 @@ static void test_profile_sections_names(void) WriteFile( h, content, sizeof(content), &count, NULL); CloseHandle( h); + ret = GetPrivateProfileSectionNamesA( NULL, 0, testfile3 ); + ok (ret == 0, "GetPrivateProfileSectionNamesA(NULL,0) returned %d instead of 0\n", ret); + ret = GetPrivateProfileSectionNamesA( buf, 0, testfile3 ); + ok (ret == 0, "GetPrivateProfileSectionNamesA(buf,0) returned %d instead of 0\n", ret); + ret = GetPrivateProfileSectionNamesA( NULL, 1, testfile3 ); + ok (ret == 0, "GetPrivateProfileSectionNamesA(NULL,1) returned %d instead of 0\n", ret); + /* Test with sufficiently large buffer */ memset(buf, 0xc, sizeof(buf)); ret = GetPrivateProfileSectionNamesA( buf, 29, testfile3 ); -- 1.5.6

2 1

Re: [2/13]msctf: implement SetFocus and GetFocus
by Jacek Caban 31 Jan '09

31 Jan '09

Hi Aric, Aric Stewart wrote: > --- > dlls/msctf/threadmgr.c | 28 ++++++++++++++++++++++++---- > 1 files changed, 24 insertions(+), 4 deletions(-) > + if (!pdimFocus || FAILED(IUnknown_QueryInterface(pdimFocus,&IID_ITfDocumentMgr,(LPVOID*) &check))) + return E_INVALIDARG; + + This->focus = check; Shouldn't This->focus be released if it's already set? Jacek

2 1

Highest commits per month (ever)
by Paul Vriens 31 Jan '09

31 Jan '09

Hi, This month we hit the highest number of commits per month ever : 1307. It's a shame there is weekend coming ;) -- Cheers, Paul.

1 1

DIB Engine - Rebased on wine-1.1.14
by Massimo Del Fedele 31 Jan '09

31 Jan '09

As before, separated in 2 patches. Ciao Max

1 0