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

ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 4)
by Loïc Maury 25 Jan '11

25 Jan '11

--- dlls/ntdll/cdrom.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)

1 0

Re: [Bug 25402] Woody Two Legs crashes with unimplemented function msvcr90.dll._wcslwr_s
by Eric Pouech 25 Jan '11

25 Jan '11

the spec should read wstr instead of ptr A+ 2011/1/25 <wine-bugs(a)winehq.org> > http://bugs.winehq.org/show_bug.cgi?id=25402 > > Andrew Millington <andrew.millington(a)gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Keywords| |patch > > --- Comment #5 from Andrew Millington <andrew.millington(a)gmail.com> > 2011-01-25 01:23:06 CST --- > After applying http://source.winehq.org/patches/data/70240 it complains > about > unimplemented function d3dx9_36.dll.D3DXFloat32To16Array and that is bug > #25769. > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > Do not reply to this email, post in Bugzilla using the > above URL to reply. > ------- You are receiving this mail because: ------- > You are watching all bug changes. > > > -- -- Eric Pouech

1 0

Re: [PATCH 2/4] wined3d: Add support for the NULL format.
by Stefan Dösinger 25 Jan '11

25 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 24.01.2011 um 18:41 schrieb Henri Verbeet: > - if (surface) > + if (surface && surface->resource.format->id != WINED3DFMT_NULL) Doesn't this cause GL errors? In my testing I had to set the draw buffer to GL_NONE to be able to draw without a color attachment. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNPqNaAAoJEN0/YqbEcdMwWFwP/0KW7THyiplBKi6csC7b6qWi i7Bi3VG5UMRomIDUyWMTlH+mwLqP7+AchzVYEHAM/blhe5yqemDc2YAN2f2/aNtV cbWoaIilTNF3PKH11wVvtUowidrwHmr9eV+SmHplvhdpJCTGKqU0ZxmNgl2DDiSD iPVfCmL6RE1e5n9i11AH7aQIcZjwPTEQBQlLR5IB1zpcnXab0r7vyTU44f0HkcJ0 785ast6QuG7lawibe7PmRz41VcFCtSMZF3QGgEujAn+frtYhqjVLdP8LITWZ+1mL jPfCWEQX1vlgbdMogykfnKSfm5oxaDMsrU3vMskwUGWFZCX+M7ffHIfy7cpy8HUt YVz4kqeaLr1xeZEsEaAQqjNal1PXoJCJSVA6ckV7VhB0+OkXpcH4i8ifdCtRv1PJ 0V/vryBBQgM9AczBQI8lb1c7w7lQL9EzttpNwbbC3mBTsT3/7EHJRuxR8EStIgzC 8gyTXveyBGuJel8Bwx6M+tBSskCNKFzPN7MKkvIE2+X5NSYj5eI05GSQRMl/eush jZWe+ls9GYgl76bL8+By1RRTsXGizPdW8UnX6HhzMfBErU1Z7IZbbqEiTMgXFOJL 0v0UXfLecE/mHlgrauk7b0C51JMtTXq5uuSOQ8uxFz/t2KcElja6pY4/nkN3DoLe I/cZaSyeQ3B5lTVTeZt/ =UA0G -----END PGP SIGNATURE-----

2 1

Static analysis scan
by Amine Khaldi 24 Jan '11

24 Jan '11

Hello folks, I've set up a static analysis scan using clang static analyzer. The results are available at http://austinenglish.com/logs/clang_analyzer/index.html thanks to Austin for the web space. Please feel free to fix the defects. I'll run future scans when the defects get fixed progressively. Have fun ;) With best regards, Amine.

2 1

Re: oleaut32/typelib2: Use implementation pointer to trace ICreateTypeInfo2
by Michael Stefaniuc 24 Jan '11

24 Jan '11

Hello Nikolay, On 01/24/2011 01:01 AM, Nikolay Sivov wrote: > Use implementation pointer to trace ICreateTypeInfo2 > diff --git a/dlls/oleaut32/typelib2.c b/dlls/oleaut32/typelib2.c > index 8260ef2..5c843a1 100644 > --- a/dlls/oleaut32/typelib2.c > +++ b/dlls/oleaut32/typelib2.c > @@ -2322,6 +2321,7 @@ static HRESULT WINAPI ICreateTypeInfo2_fnAddVarDesc( > > /* increment the number of variable elements */ > This->typeinfo->cElement += 0x10000; > +ERR("count=%d\n", This->typeinfo->cElement); this looks like some leftover debug line. > > return status; > } bye michael

2 1

Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.
by Jacek Caban 24 Jan '11

24 Jan '11

On 1/18/11 7:31 PM, Erich Hoover wrote: > On Tue, Jan 18, 2011 at 3:08 AM, Jacek Caban <jacek(a)codeweavers.com <mailto:jacek(a)codeweavers.com>> wrote: > ... > I'm not sure what you mean by "hijack the IOleCommandTarget". All we do is implementing client's IOleCommandTarget. It's something different from document's one. > I understand that, but apparently the native implementation (testing on the test bot WXPPROSP3) sends the command to the client > IOleCommandTarget instead of the document IOleCommandTarget (at least under the conditions of the webbrowser tests). That is what I mean by hijacking, the command is going to the "wrong" target. My guess would be that there is some sort of priority mechanism, though I have no idea how it would work (except maybe "if there's a client/container then send to that target, else send to the document target). That sounds reasonable. > I've attached a test where I disabled the client/container, and you > can see that it then gets passed through (QueryStatusWB will return success instead of passing through the client target and returning failure): > https://testbot.winehq.org/JobDetails.pl?Key=8408 Hmm, it means that another run of tests (at least required subset of existing test_WebBrowser) with client's IOleCommandTarget disabled would be interesting. Do you feel like writing it? Otherwise we'd need at least a FIXME in this case. Jacek

2 5

Re: gdi32: Prevent character code from wrapping around.
by Alexandre Julliard 24 Jan '11

24 Jan '11

Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > If lastChar is 0xffffffff, FONT_GetCharsByRangeA falls into > infinite loop and crash. You probably want more sanity checks (with tests), characters above 0xffff wouldn't make sense anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] To: wine-patches@winehq.org
by Alexandre Julliard 24 Jan '11

24 Jan '11

Eric Pouech <eric.pouech(a)orange.fr> writes: > [Kernel32]: in bare console with curses, ensure control stream is sent to tty (even when some fd:s are redirected) There doesn't seem to be much point in initializing input if we can't see the output. On the contrary, I think we should err on the side of not initializing anything unless really necessary. -- Alexandre Julliard julliard(a)winehq.org

1 0

Questioning the depth_clamp_test in d3d8:visual
by Joerg-Cyril.Hoehle＠t-systems.com 24 Jan '11

24 Jan '11

Hi, Trying to understand bugs #10636 and #19773 , I glanced at the d3d8 visual.ok directx test results. It appears that the green colour on test.winehq does not mean much. - All (any exception?) WTB machines skip the tests because d3d8 is not installed. - Same for Francois Gouget's virtual machines. That alone explains green colour. - Wylda's *real* machine #1 (NVidia gfx) produces 5 errors: visual.c:1411: Test failed: color 0x00ffffff. visual.c:1413: Test failed: color 0x00ffffff. visual.c:1415: Test failed: color 0x00ffffff. - "geniuh"'s (NVidia) machine as well. - Saulius' (NVidia) XP and w7 machines shows only these 3 errors. - Wylda's Intel-based machine #2 passes the tests. Hurray! - One unknown win7 machine with Intel gfx also passes them. - Aurimas' machine produces one different error (also Intel gfx). BTW, Wylda recently mentioned that the d3d tests produce vastly different graphics on his 2 machines. My conclusion: the tests only prove that Wine wants to mimic Intel graphics, but they do not account for the variety of observed test results. Danger: one may draw false conclusions from the ok() and wrongly generalize supposed behaviour of the tested functions. Looking at Wine test data (from 1.3.12), it appears that Wine implements exactly the opposite behaviour: the NVidia (+ 1 ATI) machines pass the tests, e.g. behave like Intel on native, while the Intel gfx one (eeepc) produces the 3 errors known from native NVidia! This smells wrong... Regards, Jörg Höhle

3 2

Re: server: fix connect failures on newer kernels
by Marcus Meissner 24 Jan '11

24 Jan '11

On Mon, Jan 24, 2011 at 12:21:15AM -0500, Mike Kaplinskiy wrote: > For some reason the newer kernels report POLLOUT|POLLERR|POLLHUP when > connect() fails. Strip the POLLOUT in this case. This (hopefully) > fixes bug 25456. > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 1b81544..3c6425e 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -3965,7 +3965,7 @@ static void test_ConnectEx(void) > closesocket(listener); > listener = INVALID_SOCKET; > > - address.sin_port = 1; > + address.sin_port = htons(1); > > bret = pConnectEx(connector, (struct sockaddr*)&address, addrlen, NULL, 0, &bytesReturned, &overlapped); > ok(bret == FALSE && GetLastError(), "ConnectEx to bad destination failed: " > diff --git a/server/sock.c b/server/sock.c > index d37a316..134efb0 100644 > --- a/server/sock.c > +++ b/server/sock.c > @@ -388,6 +388,9 @@ static void sock_poll_event( struct fd *fd, int event ) > > if (sock->state & FD_CONNECT) > { > + if (event & POLLOUT && event & (POLLERR|POLLHUP)) > + event &= ~POLLOUT; Add more braces to make the operator precedence a bit more clear... (just a style issue though) Ciao, Marcus

2 1