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

Re: [3/3] d3d9: Accept the geforce 8 fog+srgb result
by Henri Verbeet 12 Nov '09

12 Nov '09

2009/11/12 Stefan Dösinger <stefan(a)codeweavers.com>: > - ok(color_match(color, 0x00808080, 1), > + ok(color_match(color, 0x00808080, 1) || broken(color_match(color, 0x00bcbcbc, 1)), Just because drivers hack around HL2 doesn't mean it's broken.

1 0

Bugging people about test failures
by Paul Vriens 12 Nov '09

12 Nov '09

Hi, I hope people don't mind me sending the occasional email about failing tests on Windows. The test.winehq.org pages are usually very red so it can be a bit hard sometimes to spot any 'regressions' in the conformance tests. I haven't payed much attention for 2 weeks and that (partly) results in what can be currently seen on test.winehq.org. I have of course limits in what I can fix so I need other people (especially the authors) to help me out here. Thanks to Juan and Rob for fixing loads of the failures already. Oh, and btw. not fixing your newly introduced failing tests in a timely matter (or at least paying attention to them) can even effect your Julliard ranking ;) -- Cheers, Paul.

1 0

Re: [try 2] [PATCH 03/12] comctl32: Implement Add, ReplaceIcon, GetImageCount, SetImageCount in IImageList
by Henri Verbeet 12 Nov '09

12 Nov '09

2009/11/11 Owen Rudge <orudge(a)codeweavers.com>: > @@ -2985,15 +2985,37 @@ static ULONG WINAPI ImageListImpl_Release(IImageList *iface) > static HRESULT WINAPI ImageListImpl_Add(IImageList *iface, HBITMAP hbmImage, > HBITMAP hbmMask, int *pi) > { > - FIXME("STUB: %p %p %p %p\n", iface, hbmImage, hbmMask, pi); > - return E_NOTIMPL; > + HIMAGELIST This = (HIMAGELIST) iface; > + int ret; > + > + if (!This || !hbmImage || !pi) > + return E_FAIL; I don't know if you have tests for the other parameters, but "iface" should never be NULL for COM methods.

1 0

Still a crash in the rpcrt4 tests
by Paul Vriens 12 Nov '09

12 Nov '09

Hi Rob, There is still a crash in the rpcrt4 tests on NT4+. These 2 tests both crash actually: 886 x = echo_ranged_int(0); 887 ok(x == 0, "echo_ranged_int() returned %d instead of 0\n", x); 888 x = echo_ranged_int(100); 889 ok(x == 100, "echo_ranged_int() returned %d instead of 100\n", x); but only in the "ncalrpc_basic" case. -- Cheers, Paul.

2 1

Re: d3d8/tests: Avoid a crash, when CreateTexture failed
by Henri Verbeet 11 Nov '09

11 Nov '09

2009/11/6 Henri Verbeet <hverbeet(a)gmail.com>: > If changing the usage makes it work, that's ok. Maybe try just passing > 0 for usage. The texture doesn't have to be lockable, all we care > about is having a unique texture pointer for the > SetTexture()/GetTexture() calls. > I.e., does the attached patch work for you?

2 1

What's the use of volatile in Wine code?
by Joerg-Cyril.Hoehle＠t-systems.com 11 Nov '09

11 Nov '09

Hi, AJ wrote in http://www.winehq.org/pipermail/wine-devel/2009-November/079575.html >If there is proper synchronization you don't need >volatile, and if there isn't volatile won't magically fix it. However, mcimidi has in its code since pre 1999: :/* it seems that in case of multi-threading, gcc is optimizing just a little bit : * too much. Tell gcc not to optimize status value using volatile. : */ :while (((volatile WINE_MCIMIDI*)wmm)->dwStatus == MCI_MODE_PAUSE); The comment is right. Any C compiler is allowed to optimize this into an endless loop without volatile. But I'd rather see the following: :volatile dwStatus = NOT_READY; /* one central declaration */ :... :while (wmm->dwStatus == PAUSE) ; /* what, busy wait!?! */ So what's the use of volatile? When is it appropriate in Wine? I found this article from MSDN about memory acquire and release semantics, volatile and multiple processors very interesting. MS-VC changed the code generator for 'volatile' between 2003 and 2005 to accomodate multi-processor systems: http://msdn.microsoft.com/en-us/library/ms686355(VS.85).aspx Regards, Jörg Höhle

4 3

Fun new valgrind warnings in rpc code?
by Dan Kegel 11 Nov '09

11 Nov '09

As of today, six tests: http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_marshal.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_ndr_marsha… http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt all report the new valgrind warning Syscall param socketcall.send(msg) points to uninitialised byte(s) at send (socket.S:100) by rpcrt4_conn_write (rpc_binding.h:170) by RPCRT4_SendWithAuth (rpc_message.c:841) by RPCRT4_Send (rpc_message.c:983) by process_bind_packet (rpc_server.c:281) by RPCRT4_process_packet (rpc_server.c:412) by RPCRT4_worker_thread (rpc_server.c:435) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) Address 0x7f037e28 is 40 bytes inside a block of size 60 alloc'd at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by RPCRT4_SendWithAuth (rpc_message.c:800) by RPCRT4_Send (rpc_message.c:983) by process_bind_packet (rpc_server.c:281) by RPCRT4_process_packet (rpc_server.c:412) by RPCRT4_worker_thread (rpc_server.c:435) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:187) by RtlAllocateHeap (heap.c:1429) by I_RpcAllocate (rpcrt4_main.c:574) by RPCRT4_ReceiveWithAuth (rpc_message.c:1160) by RPCRT4_Receive (rpc_message.c:1298) by RPCRT4_io_thread (rpc_server.c:453) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) I don't think that happened before today. Rob/Hans, could you have a look?

2 1

Any Wineconf results?
by Nikolay Sivov 11 Nov '09

11 Nov '09

Hi, guys. Unfortunately, but as I expected, I wasn't able to participate in Wineconf2009 (I'm business tripping for 3 weeks in central Asia now). I'd like to read something about decisions if any you've made at this conf, some principle ideas or something. Wiki page doesn't talk too much - but thanks for Michael's slides about wine-oopses. All I'm able to find is Marcus' flickr photoset and I'm not satisfied with that :). I've noticed some 1.2 target bugs dropping and a bunch of rpcrt4 and sound patches, and that's great. Anyway thanks for this year, all of you, it's really interesting to contribute here.

2 1

Re: Owen Rudge : comctl32: Add support for scrolling during marquee selection.
by Nikolay Sivov 11 Nov '09

11 Nov '09

On Wed, Nov 4, 2009 at 10:26 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: e1f3edef3e491095dd73548b711bddf14ee73ef0 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=e1f3edef3e491095dd73548b7… > > Author: Owen Rudge <orudge(a)codeweavers.com> > Date: Mon Nov 2 10:58:26 2009 -0600 > > comctl32: Add support for scrolling during marquee selection. > > --- Hi, Owen. I've tested this a bit and it flickers like hell in some cases. Looks like list requests redraw even if selection doesn't change (pointer is still over already selected item). Other things: - selection logic is wrong when some items are already selected before marquee. On native it deselects those items, your code leave them as is. This is visible in regedit (report mode listview) - select first entry and start selection -> first item remains selected. - sometimes I get corrupted focus rectangle - moving pointer down causes bottom side to clear, rectangle contains three side after that (it could be a problem for my virtual box of course, or some embedded video drivers, but I don't see a problem moving up for example).

2 1

Re: Cpp Check Nov. 7th
by chris ahrendt 11 Nov '09

11 Nov '09

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> Alexandre Julliard wrote: >>> chris ahrendt <celticht32(a)yahoo.com> writes: >>> >>>> Well its been a few since I ran CPP Check and so I ran it today and got the following: >>>> >>>> New CPP Check Errors for the Wine Code: >>>> >>>> [/home/cahrendt/wine-git/dlls/comctl32/imagelist.c:1908]: (error) Uninitialized variable: bmi_buf >>>> [/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/shell32/shellord.c:416]: (error) Uninitialized variable: szText >>>> [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized variable: szTitle >>>> [/home/cahrendt/wine-git/dlls/shell32/shellpath.c:1360]: (error) Uninitialized variable: InfoBuffer >>>> [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd >>>> [/home/cahrendt/wine-git/server/mapping.c:118]: (error) Uninitialized variable: page_size >>> These are once again all false positives. I don't think there's any >>> point in continuing to post such reports, at least not until cppcheck >>> becomes more reliable. >>> >> Will report them to CPPcheck >> >> are you sure though all of these are false positives? > > Yes, there isn't a single legitimate bug in there. > Ticket open... chris

1 0