February 2009 - Wine-Devel - list.winehq.org

Re: rpcrt4: Check for null endpoint in RpcServerUseProtseqEpExW

by Rob Shearman

2009/2/5 Nikolay Sivov <bunglehead(a)gmail.com>: > Changelog: > - Check for null endpoint in RpcServerUseProtseqEpExW. > Installed IE8 RC1 crashes on this call, parameter set is specified in > test case. > > >From 89f889b2c7a754302b599884577b4eba22b3d235 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Thu, 5 Feb 2009 22:03:48 +0300 > Subject: Check for null endpoint in RpcServerUseProtseqEpExW > > --- > dlls/rpcrt4/rpc_server.c | 6 ++++-- > dlls/rpcrt4/tests/rpc.c | 15 +++++++++++++++ > 2 files changed, 19 insertions(+), 2 deletions(-) > > diff --git a/dlls/rpcrt4/rpc_server.c b/dlls/rpcrt4/rpc_server.c > index b6e058a..e9bed42 100644 > --- a/dlls/rpcrt4/rpc_server.c > +++ b/dlls/rpcrt4/rpc_server.c > @@ -775,8 +775,10 @@ RPC_STATUS WINAPI RpcServerUseProtseqEpExW( RPC_WSTR Protseq, UINT MaxCalls, RPC > return status; > > EndpointA = RPCRT4_strdupWtoA(Endpoint); > - status = RPCRT4_use_protseq(ps, EndpointA); > - RPCRT4_strfree(EndpointA); > + if (EndpointA) { > + status = RPCRT4_use_protseq(ps, EndpointA); > + RPCRT4_strfree(EndpointA); > + } This isn't correct, I'm afraid. The protseq open function should generate an endpoint name to use. For example, the ncacn_ip_tcp code should select a random available TCP port. > return status; > } > > diff --git a/dlls/rpcrt4/tests/rpc.c b/dlls/rpcrt4/tests/rpc.c > index bf538e4..b815acc 100644 > --- a/dlls/rpcrt4/tests/rpc.c > +++ b/dlls/rpcrt4/tests/rpc.c > @@ -830,6 +830,20 @@ static void test_UuidCreate(void) > } > } > > +static void test_RpcServerUseProtseqEpEx(void) > +{ > + RPC_STATUS status; > + RPC_POLICY policy; > + static WCHAR protW[] = {'n','c','a','l','r','p','c',0}; > + > + policy.Length = sizeof( policy ); > + policy.EndpointFlags = 0; > + policy.NICFlags = 0; > + > + status = RpcServerUseProtseqEpExW(protW, 10, NULL, NULL, &policy); > + ok(status == RPC_S_OK, "Expected RPC_S_OK, got %d\n", status); > +} This is a good start, but you should also test the bindings created as a result of doing this and then you will probably discover that the fix to RpcServerUseProtseqEpExW isn't quite correct. > START_TEST( rpc ) > { > static unsigned char ncacn_np[] = "ncacn_np"; > @@ -849,4 +863,5 @@ START_TEST( rpc ) > test_endpoint_mapper(ncalrpc, NULL, lrpc_endpoint); > test_RpcStringBindingFromBinding(); > test_UuidCreate(); > + test_RpcServerUseProtseqEpEx(); > } -- Rob Shearman

Feb. 6, 2009

Re: widl: filter_func isn't used when USE_COMPILER_EXCEPTIONS is defined

by Rob Shearman

2009/2/6 Christoph von Wittich <Christoph(a)apiviewer.de>: > diff --git a/tools/widl/proxy.c b/tools/widl/proxy.c > index 0dcb737..88c0e53 100644 > --- a/tools/widl/proxy.c > +++ b/tools/widl/proxy.c > @@ -122,10 +122,12 @@ static void init_proxy(const statement_list_t *stmts) > print_proxy( " void *This;\n"); > print_proxy( "};\n"); > print_proxy( "\n"); > + print_proxy("#ifndef USE_COMPILER_EXCEPTIONS\n"); > print_proxy("static int __proxy_filter( struct __proxy_frame *__frame > )\n"); > print_proxy( "{\n"); > print_proxy( " return (__frame->_StubMsg.dwStubPhase != > PROXY_SENDRECEIVE);\n"); > print_proxy( "}\n"); > + print_proxy("#endif /* USE_COMPILER_EXCEPTIONS */\n"); > print_proxy( "\n"); > } I think a better solution to this would be to use proxy_filter as the expression in the RpcExcept statements. Alexandre, what do you think? -- Rob Shearman

Feb. 6, 2009

Re: [patch] rpcrt4_conn_np_read needs to expect and accept ERROR_MORE_DATA

by Luke Kenneth Casson Leighton

On Fri, Feb 6, 2009 at 10:29 AM, Rob Shearman <robertshearman(a)gmail.com> wrote: > 2009/2/5 Luke Kenneth Casson Leighton <luke.leighton(a)googlemail.com>: >> http://bugs.winehq.org/show_bug.cgi?id=17263 > > The patch looks acceptable in theory. Please email the patch to > wine-patches (or wine-devel) and I'll review the implementation of it. ok!

Feb. 6, 2009

Re: Stub DDE interface for Progman.exe

by Rob Shearman

2009/2/5 Jeremiah Flerchinger <jeremiah.flerchinger(a)gmail.com>: > On Thu, 2009-02-05 at 18:58 +0100, Rolf Kalbermatter wrote: >> "Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote: >> >> > The shell32.dll DDE callback isn't always initialized & handling >> > Progman calls for all apps. I've seen Progman calls pass >> > through the DDE_client and DDE_server of user32.dll instead >> > and never go through shell32.dll. >> >> That would IMHO only be possible if the shell executable, which normally is >> just explorer >> creating the actual desktop view had been replaced by a different executable >> that does >> not initialize the shell DDE interface properly. >> >> Rolf Kalbermatter >> > DdeConnect, DDeInitialize, and DDeDisconnect can be called directly by > including Windows.h and importing the calls from user32 > (http://msdn.microsoft.com/en-us/library/ms648745(VS.85).aspx) DDE > calls can then be made with SendMessage or PostMessage. > > I found a couple apps that appear to do this. Wine does not > automatically start explorer.exe or initialize the shell DDE interface, > nor does it route the DdeConnect routine in user32.dll to the DdeConnect > routine in the shell32.dll. The DDE interface in shell32 and user32 will > need to call the same set of routines from either method for full > functionality of DDE calls, including those to Progman. http://en.wikipedia.org/wiki/Library_(computing)#Dynamic_linking -- Rob Shearman

Feb. 6, 2009

Re: Stub DDE interface for Progman.exe

by Rob Shearman

2009/2/5 Jeremiah Flerchinger <jeremiah.flerchinger(a)gmail.com>: > On Thu, 2009-02-05 at 18:12 +0000, Rob Shearman wrote: >> 2009/2/3 Dmitry Timoshkov <dmitry(a)codeweavers.com>: >> > "Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote: >> > >> >> Stubs basic DDE interface of Progman.exe. Similar to Progman stub in >> >> shell32.dll. Both will need to be extended and a 3rd progman interface >> >> will need to be added in user32. >> > >> > Progman DDE interface should be implemented by shell32.dll, nowhere else. >> >> And it already is: ShellDDEInit. >> >> All it needs is some always running process to call it. It looks like >> explorer would be a good choice. >> > Is explorer always running in Wine? I know "wine explorer" does not run > ShellDDEInit when it starts. I thought most people were against > additional processes, but I want to see the Progman DDE interface > working for the different ways of calling it. Try running a simple winelib app with WINEDEBUG=+process set and see for yourself. > ShellDDEInit didn't exist before Win 2000 and was in Shdocw.dll and not > shell32.dll. Do we want to call ShellDDEInit in shell32 when Wine starts > (and ends) then? I'm not sure if there is a desire to allow native shell32 to be used in Wine. However, if there is it would be simple to use GetProcAddress with appropriate checks on the shell32 module that has been loaded. > It is supposed to be called only by the process that is > acting as the shell when it registers itself as a DDE host for the > shell. I don't think anything else would ever call it then. I can't work out what you mean by this. Perhaps you can rephrase it or describe in more detail what you mean. -- Rob Shearman

Feb. 6, 2009

Re: [patch] rpcrt4_conn_np_read needs to expect and accept ERROR_MORE_DATA

by Rob Shearman

2009/2/5 Luke Kenneth Casson Leighton <luke.leighton(a)googlemail.com>: > http://bugs.winehq.org/show_bug.cgi?id=17263 The patch looks acceptable in theory. Please email the patch to wine-patches (or wine-devel) and I'll review the implementation of it. -- Rob Shearman

Feb. 6, 2009

Re: wine iexplore speed test (JavaScript)

by Detlef Riekenberg

On Do, 2009-02-05 at 18:31 +0100, Jacek Caban wrote: > Detlef Riekenberg wrote: > > I did a speed test for JS with Wine: > > http://v8.googlecode.com/svn/data/benchmarks/v3/run.html > > Personally I don't see much point in looking for benchmarks as > long as we have so many real applications that don't work > due to lacks in our MSHTML implementation. It was mainly so check, how well the integrated gecko works. > We currently use jscript.dll only for documents with 'file:' URLs. Thanks for clarify this. -- By by ... Detlef

Feb. 6, 2009

Re: IPinImpl_QueryInternalConnections() is unused

by Maarten Lankhorst

Hi Francois, 2009/2/4 Francois Gouget <fgouget(a)free.fr>: > > dlls/qcap/pin.c defines an IPinImpl_QueryInternalConnections() function > but it is not actually used anywhere. Is there any reason to keep it? > > It sort of looks like IPin is a virtual class and that > IPin::QueryInternalConnections() is going to be implemented in its > descendents like VfwPin as is currently the case. But then > VfwPin_QueryInternalConnections() is just as much of a stub so maybe it > is it that should go away? qcap/pin.c is just a copy of quartz/pin.c with some things removed, and it wasn' t kept up to date. I wouldn' t be surprised if it defined some methods not being used. Cheers, Maarten.

Feb. 6, 2009

Re: New Wine Gecko package

by Jerome Leclanche

On Fri, Feb 6, 2009 at 3:48 AM, Dan Kegel <dank(a)kegel.com> wrote: > James Mckenzie wrote: >> It depends on the timeline for the 1.2 release. >> If this is a long way off, it may be worth the effort. > > I don't know. The 1.1 branch has are lots of improvements > people want; what's so special about Gecko? > IMHO we should leave the 1.0 branch alone, > and just get on with 1.2. I agree. The potential security issues that have been fixed would (from what I understood) specifically target Wine. Targeting Wine 1.0.1 would be... pretty restricted. I don't think it's worth investing time for something like this when 1.2 is coming soon. > > Speaking of which, I wonder which of Alexandre's 1.2 wish list > features will be done first? > http://wiki.winehq.org/WineReleasePlan > Win64 is looking like the front runner at the moment, > but there were some USB patches recently, maybe > that will come from behind. > I haven't followed recent discussions about it, but it seemed to me the DIB engine got the most efforts and work done lately. If it's accepted and starts being usable, it'd be great JL -- Adys

Feb. 6, 2009

re: New Wine Gecko package

by Dan Kegel

James Mckenzie wrote: > It depends on the timeline for the 1.2 release. > If this is a long way off, it may be worth the effort. I don't know. The 1.1 branch has are lots of improvements people want; what's so special about Gecko? IMHO we should leave the 1.0 branch alone, and just get on with 1.2. Speaking of which, I wonder which of Alexandre's 1.2 wish list features will be done first? http://wiki.winehq.org/WineReleasePlan Win64 is looking like the front runner at the moment, but there were some USB patches recently, maybe that will come from behind.

Feb. 6, 2009