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

Re: Use environment variable WINE_NO_MENU_ENTRIES to prevent menu icon and menu entry creation.

by Detlef Riekenberg

On Do, 2009-02-05 at 18:02 +0100, Christoph Korn wrote: > int PASCAL WinMain (HINSTANCE hInstance, HINSTANCE prev, LPSTR > cmdline, int show) > { > + if(getenv("WINE_NO_MENU_ENTRIES")) > + { > + return 0; > + } > + > LPSTR token = NULL, p; Declaring a variable after code is C99 and not allowed in Wine. -- By by ... Detlef

Feb. 6, 2009

Re: widl: initialize _RetVal to avoid compiler warnings

by Rob Shearman

2009/2/5 Christoph von Wittich <Christoph(a)apiviewer.de>: > --- a/tools/widl/proxy.c > +++ b/tools/widl/proxy.c > @@ -327,7 +327,12 @@ static void gen_proxy(type_t *iface, const var_t > *func, int idx, > if (has_ret) { > print_proxy( "" ); > write_type_decl_left(proxy, type_function_get_rettype(func->type)); > - print_proxy( " _RetVal;\n"); > + > + /* Initialize _RetVal properly in order to avoid compiler warnings */ > + if (is_ptr(type_function_get_rettype(func->type)) || > is_array(type_function_get_rettype(func->type))) > + print_proxy(" _RetVal = NULL;\n"); > + else > + print_proxy(" _RetVal = 0;\n"); > } > print_proxy( "RPC_MESSAGE _RpcMessage;\n" ); > if (has_ret) { I think this is just hiding the problem. Can you give an example of IDL which causes widl to generate code that causes compiler warnings? -- Rob Shearman

Feb. 6, 2009

Re: rpcrt4: Check for null endpoint in RpcServerUseProtseqEpExW

by Rob Shearman

2009/2/6 Nikolay Sivov <bunglehead(a)gmail.com>: > Rob Shearman wrote: >> 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(); >>> } >>> >> >> > Ok, I'll try to find out. > Rob, could you suggest a good documentation source on RPC? I'm not > experienced in it. Sure, although this particular aspect isn't well documented. I did find a couple of references, but you have to fill in the blanks to get to the conclusion that RpcServerUseProtseqEpEx with a NULL endpoint should generate an otherwise unused endpoint string: http://www.opengroup.org/onlinepubs/9629399/chap2.htm#tagcjh_05_02_03 http://msdn.microsoft.com/en-us/library/aa378452(VS.85).aspx - "The endpoint name is generated by the RPC run time or the operating system." The following may also be useful in future RPC issues, but not in this case: http://msdn.microsoft.com/en-us/library/cc243560(PROT.10).aspx -- Rob Shearman

Feb. 6, 2009

Re: DIB Engine - Patchset separated by original author

by Luke Benstead

2009/2/6 L. Rahyen <research(a)science.su>: > On 2009-02-06 (Friday) 12:40:51 Massimo Del Fedele wrote: >> I've been out for job for a while, but I don't see many comments about >> the patch..... I guess I'll stop developing the engine for now. >> It makes few sense to code for something that will probably never be >> accepted..... > > Did you try to talk about your implementation of DIB engine with Alexandre (on > IRC or e-mail privately)? If not you should try. > BTW, if you get almost zero comments this isn't necessary bad thing - this > usually means that nobody has anything bad to say about your implementation and > this is good thing. However, if Alexandre see something wrong in your > implementation you need to talk to him personally about this to understand > what's wrong and how you can improve it. > Personally I think you are doing important and useful job because many programs > can benefit from DIB engine including AutoCAD. > > > I agree, you should stop by #winehackers and chat to Alexandre. Perhaps Huw, and Jesse could also join in a discussion about the best way forward. Luke.

Feb. 6, 2009

Re: DIB Engine - Patchset separated by original author

by L. Rahyen

On 2009-02-06 (Friday) 12:40:51 Massimo Del Fedele wrote: > I've been out for job for a while, but I don't see many comments about > the patch..... I guess I'll stop developing the engine for now. > It makes few sense to code for something that will probably never be > accepted..... Did you try to talk about your implementation of DIB engine with Alexandre (on IRC or e-mail privately)? If not you should try. BTW, if you get almost zero comments this isn't necessary bad thing - this usually means that nobody has anything bad to say about your implementation and this is good thing. However, if Alexandre see something wrong in your implementation you need to talk to him personally about this to understand what's wrong and how you can improve it. Personally I think you are doing important and useful job because many programs can benefit from DIB engine including AutoCAD.

Feb. 6, 2009

re: gdiplus: Some tests for GdipGetLineRect

by Dan Kegel

Nikolay Sivov <bunglehead at gmail.com> wrote: > ... > + ok(rectf.X == 10.0, "Expected 10.0 got %.2f\n", rectf.X); Exact equality comparison on float is never a good idea in unit tests. You need a range test instead. See http://code.google.com/p/googletest/wiki/GoogleTestAdvancedGuide#Floating-P…

Feb. 6, 2009

Re: DIB Engine - Patchset separated by original author

by Massimo Del Fedele

Jesse Allen ha scritto: > On Sun, Feb 1, 2009 at 9:29 AM, Massimo Del Fedele <max(a)veneto.com> wrote: >> As asked to me, I have separated the dib engine into a patchset, trying to >> keep (when possible) the original author's submissions, so Huw Davies, Jesse >> Allen and me. >> I had to change some of other author's commits in order to fit my engine and >> to rebase it on 1.1.14, so I ask both previous authors to check if they >> agree on the patches. >> >> I hope this will help the review, as keeping it rebased on wine tree will >> become quite hard having it as a separated patchset. >> >> Attached here is a zipped patchset, which apply on wine 1.1.14. >> >> Ciao >> >> Max >> >> >> >> > > Hello, > > I have placed the patches unchanged onto this git page: > http://repo.or.cz/w/wine/dibdrv-max.git > > Hope this helps. > > Jesse > > Hi Jesse, I've been out for job for a while, but I don't see many comments about the patch..... I guess I'll stop developing the engine for now. It makes few sense to code for something that will probably never be accepted..... Ciao Max

Feb. 6, 2009

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

by Juan Lang

Hi Luke, @@ -382,7 +382,14 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection, { DWORD bytes_read; ret = ReadFile(npc->pipe, buf, bytes_left, &bytes_read, NULL); - if (!ret || !bytes_read) + if (!ret) + { + TRACE("ReadFile error, status %x\n", GetLastError()); + if (GetLastError() != ERROR_MORE_DATA) + break; + ret = TRUE; /* ERROR_MORE_DATA is an expected acceptable error code */ + } + if (!bytes_read) break; Style nit: it would be simpler to do: DWORD bytes_read; ret = ReadFile(npc->pipe, buf, bytes_left, &bytes_read, NULL); + if (!ret && GetLastError() == ERROR_MORE_DATA) + ret = TRUE; if (!ret || !bytes_read) break; Don't you think? --Juan

Feb. 6, 2009

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

by Alexandre Julliard

Rob Shearman <robertshearman(a)gmail.com> writes: > 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? We could do that, though it wouldn't help with the server case. A more generic solution could be to add a dummy reference somewhere in the exception macros to make the compiler believe it's used. I certainly agree we should avoid the extra #ifdefs. -- Alexandre Julliard julliard(a)winehq.org

Feb. 6, 2009

Re: rpcrt4: Check for null endpoint in RpcServerUseProtseqEpExW

by Nikolay Sivov

Rob Shearman wrote: > 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(); >> } >> > > Ok, I'll try to find out. Rob, could you suggest a good documentation source on RPC? I'm not experienced in it. Thanks.

Feb. 6, 2009