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

Re: Dylan Smith : richedit: Added missing DestroyWindow in a test.

by Alexandre Julliard

"Dylan Smith" <dylan.ah.smith(a)gmail.com> writes: > Sorry for posting again, but I just noticed that I already sent the > patch that fixes the tests, and you suggested either _fix_ or revert > the patch. Well, could you try applying the patch from > http://www.winehq.org/pipermail/wine-patches/2008-June/056829.html and > see if it fixes this problem? I tested it in Windows XP, and in Wine, > and in Wine with valgrind. The patch doesn't apply cleanly, please resend it. -- Alexandre Julliard julliard(a)winehq.org

July 2, 2008

Re: rpcrt4: Fix a test that fails in win2k3

by Kai Blin

On Wednesday 02 July 2008 11:52:11 Rob Shearman wrote: > 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. Hm, I seem to recall a Samba RPC fix doing the same thing. This seems to be a byte alignment thing. If you're interested, I can see if I can dig up the appropriate discussion on samba-technical. 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.

July 2, 2008

Re: ntdll: suppress Valgrind warnings in NtFsControlFile (take 3)

by Rob Shearman

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

July 2, 2008

Re: Fallback from RPC_C_AUTHN_GSS_NEGOTIATE to RPC_C_AUTHN_WINNT if no SPNEGO package available

by Rob Shearman

2008/7/1 Stefan Kuhr <winesku(a)googlemail.com>: > Hello everyone, Hi Stefan, Thank you for your contribution. > please find attached a patch for Bug #14222 (which I just submitted to > bugzilla). I think that this patch is not a hack, because even if > someday a Negotiate package is available in WINE, this code won't > break the Negotiate package. That may be so, but it won't work for servers that only register the RPC_C_AUTHN_GSS_NEGOTIATE authentication scheme. So the patch should include a FIXME to warn users about this. Otherwise, the patch is fine. > 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. > Please let me know if I did something obvious wrong since this is the > first time I submit a patch to WINE. -- Rob Shearman

July 2, 2008

Re: Thoughts on implementation of winhttp.dll

by Hans Leidekker

On Tuesday 01 July 2008 21:42:30 Zac Brown wrote: > Does anyone have thoughts on implementing parts of winhttp in terms of > wininet? The primary issue that prevents entirely implementing winhttp in > terms of wininet is that there is no direct Win32 API for fetching an SSL > certificate in winhttp. Would InternetQueryOption(INTERNET_OPTION_SECURITY_CERTIFICATE) not do what you want? There are other problems to be solved though, filtered callbacks and authentication come to mind. This topic has been discussed before and I even wrote a proof of concept patch, all of which can be found in the list archives. -Hans

July 2, 2008

Re: rpcrt4: Fix a test that fails in win2k3

by Rob Shearman

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

July 2, 2008

Re: New valgrind warnings in rpcrt4/tests/server

by Rob Shearman

2008/7/2 Dan Kegel <dank(a)kegel.com>: > Hi Rob! > Could you have a look at these fresh warnings in rpcrt4/tests/server? > Thanks... Hi Dan, The following warning is caused by the generated code for non-encapsulated unions not setting _StubMsg.MaxCount before calling the relevant phase function. However, looking in detail at this bug brings up a few other issues with the code which need to be fixed. > http://kegel.com/wine/valgrind/logs-2008-07-01/vg-rpcrt4_server-diff.txt > > + Syscall param socketcall.send(msg) points to uninitialised byte(s) ... > + 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 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 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 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) > ... The following warning is caused simply by a missing call to _StubMsg.pfnFree in the generated code: > + 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) > -- Rob Shearman

July 2, 2008

Re: [Gdiplus 4/4] Implement GdipCloneImage

by Huw Davies

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

July 2, 2008

Re: [RESEND]Make wine_glGetString() return NULL on null gl context - Solves Bug 13599

by H. Verbeet

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.

July 2, 2008

Re: winecfg.cpl: Add new control panel applet for winecfg

by Reece Dunn

2008/7/2 Owen Rudge <owen(a)owenrudge.net>: > Well, the first part of the project was to get the shell namespace > implementation of Control Panel working properly, which is now > effectively complete. Hi, I just tested Cepstral SwiftTalker with latest git (see bug: http://bugs.winehq.org/show_bug.cgi?id=12534) and I can't see the options from the `control` program. You might want to get this and other applets displaying/working before creating default Wine-specific ones (e.g. like the one installed by Internet Explorer). >From my investigation into that bug (12534), I found that built-in control panel applets and installed ones were processed differently - installed ones used the registry, built-in ones didn't. - Reece

July 2, 2008