July 2008 - Wine-Devel - list.winehq.org

re: secur32: Allow loading external schannel.dll.
by Juan Lang July 2, 2008

July 2, 2008

Hi Zhangrong, your patch looks fine, but I'd appreciate it if you could update the comment for SECUR32_addProvider in secur32_priv.h to reflect your changes. --Juan

4 5

Splitting up ole component
by Dan Kegel July 2, 2008

July 2, 2008

Rob wrote: >> Oh, and there was no rpcrt4 component to >> be selected for this bug in bugzilla, you might consider to add one. > >Currently, we are using the "ole" component for RPC bugs, including >rpcrt4 and widl, but I agree that this isn't clear. I think we should >probably split the ole component up into rpc (which would be a >container for rpcrt4 & widl issues), ole32 and oleaut32. I've added the rpc component, been wanting to do that for a while. As for the other proposed change: the description for ole is currently OLE, Active X ( dlls/{ole32,oleacc,oleaut32,olecli32,oledlg,olepro32,olesvr32,olethk32,stdole2.tlb,stdole32.tlb}/ ) That's a lot more than just ole32 and oleaut32. Can you propose descriptions for the ole* components after the change? - Dan

2 2

Re: rpcrt4: Fix a test that fails in win2k3
by Rob Shearman July 2, 2008

July 2, 2008

2008/7/2 James Hawkins <jhawkins(a)codeweavers.com>: > diff --git a/dlls/rpcrt4/tests/ndr_marshall.c b/dlls/rpcrt4/tests/ndr_marshall.c > index fa19674..abd06dc 100644 > --- a/dlls/rpcrt4/tests/ndr_marshall.c > +++ b/dlls/rpcrt4/tests/ndr_marshall.c > @@ -1848,7 +1848,9 @@ static void test_ndr_buffer(void) > ok(ret == StubMsg.Buffer, "NdrGetBuffer should have returned the same value as StubMsg.Buffer instead of %p\n", ret); > ok(RpcMessage.Handle != NULL, "RpcMessage.Handle should not have been NULL\n"); > ok(RpcMessage.Buffer != NULL, "RpcMessage.Buffer should not have been NULL\n"); > - ok(RpcMessage.BufferLength == 10, "RpcMessage.BufferLength should have been 10 instead of %d\n", RpcMessage.BufferLength); > + ok(RpcMessage.BufferLength == 10 || > + RpcMessage.BufferLength == 12, /* win2k3 */ > + "RpcMessage.BufferLength should have been 10 or 12 instead of %d\n", RpcMessage.BufferLength); > ok(RpcMessage.RpcFlags == 0, "RpcMessage.RpcFlags should have been 0x0 instead of 0x%lx\n", RpcMessage.RpcFlags); > ok(StubMsg.Buffer != NULL, "Buffer should not have been NULL\n"); > ok(!StubMsg.BufferStart, "BufferStart should have been NULL instead of %p\n", StubMsg.BufferStart); I think the behaviour on win2k3 should be marked as broken, since I can't see any reason why it would need to return more bytes than was requested. -- Rob Shearman

2 2

Re: [quartz/tests] Make tests run on everything lower then Vista (Try 2)
by Alexander Dorofeyev July 2, 2008

July 2, 2008

Paul Vriens wrote: > Hi, > > RegDeleteTreeW is only available on Vista. (Were these tests run on > Windows to > verify?). Yes most of it was tested on XP, except this final registry cleanup thing, sorry my mistake. Also it ran without errors with previous version of your patch on XP here. > > This version simply replaces the RegDeleteTree by a RegDeleteKey > (which is > sufficient as there is only one value underneath the key). This is not necessarily the case, Filtermapper's Register... methods add values and create subkeys in that key. I think it will have at least "Pins" subkey in the end. It was causing problms, until I found what I thought is a good safe and easy solution (RegDeleteTree). To ensure everything is removed, and especially if some Unregister.. calls fail for whatever reason, it really is preferable to do a recursive delete. If it takes copypasting a function then so be it. I think your previous patch was better, but maybe somebody noticed a problem with it, I don't know.

2 2

Tests and Valgrinding
by Zachary Goldberg July 2, 2008

July 2, 2008

Hello! I've been watching wine a bit recently and there's been a lot of activity (code wise) in new features (backpressure from the freeze I'm sure) and lots and lots of test fixes. I know we have test.winehq.org which is fantastic, but it doesn't give a very good feel for progress that all of these recent patches have been making. Sure we can look at individual days and see how things go but there exists no real aggregate over time to see how the test suite is doing as a whole on all platforms. Do we have any such metrics/graphs? I think those would be very interesting and perhaps motivating. (Perhaps I should work on that to add to the last post in WWN's? Bugs / Appdb / Test Suite) Also, Dan Kegel has been extraordinarily diligent in valgrinding of late (/applause) and I just wanted to ask if we're doing anything to support him? Once he posts to the list it seems that its the author's (of the breaking patch) responsibility to fix the problem. Some people have been very diligent in that (again, /applause) but I think some of Dan's posts have been left unanswered. I know Dan mentioned perhaps making Valgrind-passing a requirement (along with not breaking tests) for being committed. I think perhaps we should take a look at this and seriously consider implementing it. --Zach

2 1

Re: Dylan Smith : richedit: Added missing DestroyWindow in a test.
by James Hawkins July 2, 2008

July 2, 2008

On Tue, Jul 1, 2008 at 8:27 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: 2a139746cc631f4ec291a89b4556af17266ce8c0 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=2a139746cc631f4ec291a89b4… > > Author: Dylan Smith <dylan.ah.smith(a)gmail.com> > Date: Sat Jun 28 03:00:46 2008 -0400 > > richedit: Added missing DestroyWindow in a test. > This commit is causing ~350 failures on all platforms. Please send in a fix or a revert patch. -- James Hawkins

3 3

Re: ntdll: suppress Valgrind warnings in NtFsControlFile (take 3)
by Rob Shearman July 2, 2008

July 2, 2008

2008/7/1 Dan Kegel <dank(a)kegel.com>: > + /* Alexandre says pretty much all ioctls potentially involve holey structures, s/Alexandre says// Also, while you're changing the comment, "pretty much" and "potentially" duplicate each other in the uncertainty, so one should be removed. -- Rob Shearman

1 0

New valgrind warnings in rpcrt4/tests/server
by Dan Kegel July 2, 2008

July 2, 2008

Hi Rob! Could you have a look at these fresh warnings in rpcrt4/tests/server? Thanks... http://kegel.com/wine/valgrind/logs-2008-07-01/vg-rpcrt4_server-diff.txt + Syscall param socketcall.send(msg) points to uninitialised byte(s) + at (within /lib/ld-2.7.so) + by rpcrt4_conn_write (rpc_binding.h:168) + by RPCRT4_SendWithAuth (rpc_message.c:533) + by RPCRT4_Send (rpc_message.c:675) + by I_RpcSend (rpc_message.c:1225) + by I_RpcSendReceive (rpc_message.c:1328) + by NdrSendReceive (ndr_clientserver.c:214) + by square_unencu (server_c.c:2467) + by union_tests (server.c:889) + by run_tests (server.c:1241) + by client (server.c:1260) + by func_server (server.c:1357) + by run_test (test.h:449) + by main (test.h:498) + Address 0x7f01350c is 28 bytes inside a block of size 36 alloc'd + at notify_alloc (heap.c:191) + by RtlAllocateHeap (heap.c:1231) + by RPCRT4_SendWithAuth (rpc_message.c:492) + by RPCRT4_Send (rpc_message.c:675) + by I_RpcSend (rpc_message.c:1225) + by I_RpcSendReceive (rpc_message.c:1328) + by NdrSendReceive (ndr_clientserver.c:214) + by square_unencu (server_c.c:2467) + by union_tests (server.c:889) + by run_tests (server.c:1241) + by client (server.c:1260) + by func_server (server.c:1357) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a stack allocation + at square_unencu (server_c.c:2424) ... + Syscall param write(buf) points to uninitialised byte(s) + at (within /lib/ld-2.7.so) + by WriteFile (file.c:559) + by rpcrt4_conn_np_write (rpc_transport.c:404) + by rpcrt4_conn_write (rpc_binding.h:168) + by RPCRT4_SendWithAuth (rpc_message.c:533) + by RPCRT4_Send (rpc_message.c:675) + by I_RpcSend (rpc_message.c:1225) + by I_RpcSendReceive (rpc_message.c:1328) + by NdrSendReceive (ndr_clientserver.c:214) + by square_unencu (server_c.c:2467) + by union_tests (server.c:889) + by run_tests (server.c:1241) + by client (server.c:1275) + by func_server (server.c:1357) + by run_test (test.h:449) + by main (test.h:498) + Address 0x7f013524 is 28 bytes inside a block of size 36 alloc'd + at notify_alloc (heap.c:191) + by RtlAllocateHeap (heap.c:1231) + by RPCRT4_SendWithAuth (rpc_message.c:492) + by RPCRT4_Send (rpc_message.c:675) + by I_RpcSend (rpc_message.c:1225) + by I_RpcSendReceive (rpc_message.c:1328) + by NdrSendReceive (ndr_clientserver.c:214) + by square_unencu (server_c.c:2467) + by union_tests (server.c:889) + by run_tests (server.c:1241) + by client (server.c:1275) + by func_server (server.c:1357) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a stack allocation + at square_unencu (server_c.c:2424) ... + 24 bytes in 2 blocks are definitely lost + at malloc (vg_replace_malloc.c:207) + by MIDL_user_allocate (server.c:53) + by s_get_s123 (server.c:538) + by IServer_get_s123 (server_s.c:4545) + by process_request_packet (rpc_server.c:290) + by RPCRT4_process_packet (rpc_server.c:345) + by RPCRT4_worker_thread (rpc_server.c:362) + by worker_thread_proc (threadpool.c:113) + by ??? (thread.c:128) + by call_thread_func (thread.c:383) + by start_thread (thread.c:443) + by start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so) + by clone (in /lib/tls/i686/cmov/libc-2.7.so)

2 1

Re: [Gdiplus 4/4] Implement GdipCloneImage
by Huw Davies July 2, 2008

July 2, 2008

On Tue, Jul 01, 2008 at 09:41:22PM -0400, Adam Petaccia wrote: > --- > dlls/gdiplus/image.c | 19 +++++++++++++++++-- > dlls/gdiplus/tests/image.c | 6 ------ > 2 files changed, 17 insertions(+), 8 deletions(-) > > diff --git a/dlls/gdiplus/image.c b/dlls/gdiplus/image.c > index bf2ac35..59ea837 100644 > --- a/dlls/gdiplus/image.c > +++ b/dlls/gdiplus/image.c > @@ -244,9 +244,24 @@ GpStatus WINGDIPAPI GdipCloneImage(GpImage *image, GpImage **cloneImage) > + memcpy((*cloneImage)->picture, image->picture, sizeof(IPicture)); > + > + return Ok; > } > You can't simply copy an interface ptr like this. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: [RESEND]Make wine_glGetString() return NULL on null gl context - Solves Bug 13599
by H. Verbeet July 2, 2008

July 2, 2008

2008/7/1 Massimo Del Fedele <max(a)veneto.com>: > + if(NtCurrentTeb()->glContext == NULL) > + return NULL; > + Alexandre said on IRC that you should probably use wglGetCurrentContext() there, rather than using NtCurrentTeb() directly.

1 0