April 2010 - Wine-devel - list.winehq.org

Re: [1/2] gdiplus: Add test for GdipCreateBitmapFromGdiDib.
by Greg Geldorp 24 Apr '10

24 Apr '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=1718 Your paranoid android. === W2K3R2SESP2 (32 bit image) === No test summary line found === WVISTAADM (32 bit image) === Timeout

1 0

Re: Minor dlls/dbghelp/dwarf.c simplification
by Eric Pouech 24 Apr '10

24 Apr '10

Gerald Pfeifer a écrit : > ChangeLog: > Remove two variables which are not really used in > dwarf2_parse_line_numbers. > > diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c > index 4be0f6a..69d7357 100644 > --- a/dlls/dbghelp/dwarf.c > +++ b/dlls/dbghelp/dwarf.c > @@ -1920,7 +1920,7 @@ static BOOL dwarf2_parse_line_numbers(const dwarf2_section_t* sections, > { > dwarf2_traverse_context_t traverse; > unsigned long length; > - unsigned version, header_len, insn_size, default_stmt; > + unsigned insn_size, default_stmt; > unsigned line_range, opcode_base; > int line_base; > const unsigned char* opcode_len; > @@ -1939,8 +1939,6 @@ static BOOL dwarf2_parse_line_numbers(const dwarf2_section_t* sections, > length = dwarf2_parse_u4(&traverse); > traverse.end_data = sections[section_line].address + offset + length; > > - version = dwarf2_parse_u2(&traverse); > - header_len = dwarf2_parse_u4(&traverse); > insn_size = dwarf2_parse_byte(&traverse); > default_stmt = dwarf2_parse_byte(&traverse); > line_base = (signed char)dwarf2_parse_byte(&traverse); > > > > > this is wrong: dwarf_parse family set makes the pointer in the cxt advance by the size of the object which is being parse and actually, the correct fix would be to make use of those variables (like checking if the version is a known one), instead of throwing things away A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

Re: shell32: remove unneeded parsing of SHELLEXECUTEINFO.lpFile [try 3]
by Paul Vriens 24 Apr '10

24 Apr '10

On 04/24/2010 10:53 AM, Ilya Basin wrote: > 1) removes the block of code that splits lpFile into filename and > parameters and removes '"'s from filename . Even without this block > ShellExecute not fails with quoted lpFile. > > 2) removes 2 corresponding todo_wine's from tests. > > The real application affected by this bug is uTorrent: if you have 2 > downloads containing, say, > "foo/bar.avi" and "foo 2/baz.avi", when you double click the latter > avi file, it'll open the explorer in folder "foo" instead. > > try 2: > disabled todo_wine for "%s\\masked file.shlexec" > instead of disabling all todo_wine's in the loop > > try 3: > try 2 didn't apply cleanly in git: ok() format string changed. > Hi Ilya, In your last email on wine-devel about this subject you mentioned adding some extra tests. There was at least some communication with you and the author of that piece you are now removing. The reason for that piece was shown in a code-snippet he gave and adding tests for that specific case would be worthwhile I think. -- Cheers, Paul.

2 1

Re: shell32: remove unneeded parsing of SHELLEXECUTEINFO.lpFile [try 3]
by Nikolay Sivov 24 Apr '10

24 Apr '10

On 4/24/2010 12:53, Ilya Basin wrote: > 1) removes the block of code that splits lpFile into filename and > parameters and removes '"'s from filename . Even without this block > ShellExecute not fails with quoted lpFile. > > 2) removes 2 corresponding todo_wine's from tests. > > The real application affected by this bug is uTorrent: if you have 2 > downloads containing, say, > "foo/bar.avi" and "foo 2/baz.avi", when you double click the latter > avi file, it'll open the explorer in folder "foo" instead. > > try 2: > disabled todo_wine for "%s\\masked file.shlexec" > instead of disabling all todo_wine's in the loop > > try 3: > try 2 didn't apply cleanly in git: ok() format string changed. > > --- > dlls/shell32/shlexec.c | 62 +----------------------------------------- > dlls/shell32/tests/shlexec.c | 16 +++++------ > 2 files changed, 8 insertions(+), 70 deletions(-) > > diff --git a/dlls/shell32/shlexec.c b/dlls/shell32/shlexec.c > index a81cada..b89bb08 100644 > --- a/dlls/shell32/shlexec.c > +++ b/dlls/shell32/shlexec.c > @@ -1678,67 +1678,7 @@ static BOOL SHELL_execute( LPSHELLEXECUTEINFOW sei, SHELL_ExecuteW32 execfunc ) > /* Else, try to execute the filename */ > TRACE("execute:%s,%s,%s\n", debugstr_w(wszApplicationName), debugstr_w(wszParameters), debugstr_w(wszDir)); > > - /* separate out command line arguments from executable file name */ > Where are tests for this separation path? You know, it's suspicious to just remove it to solve for not-clearly related problem to this code block.

1 0

wine + rtkit, take 2
by Maarten Lankhorst 24 Apr '10

24 Apr '10

Hi all, Just thought I'd try my luck again with rtkit, so here's what I came up with this time without a bizarre dbus call in ntdll. :) This requires a patch to rtkit, since I'm setting the realtime priority of a different process. However since rtkit will validate the pid/tid, userid and starting time independently, so it is guaranteed that we won't be able to ddos. wine-rtkit.patch has to be applied to wine. the rtkit patch to rtkit. Of course it's still a proof of concept. If AJ is interested in merging this after rtkit has merged a patch, then I will clean up the hardcoded dlopen. ;) Open for feedback. Cheers, Maarten

1 0

re: cmd: Fix builtin for with /f parameter
by Dan Kegel 23 Apr '10

23 Apr '10

Thanks. Can you add a test, too, please? 'Just' add a section to test_builtins.cmd and the corresponding expected output to test_builtins.exp.

1 0

Internet Explorer in Wine
by Detlef Riekenberg 23 Apr '10

23 Apr '10

I test sometimes native IE in Wine with the least possible changes. With my implementation of shlwapi,SHCreateThreadRef this week, the native IE UI came up in Wine, using our shell replacement, mshtml with gecko and all that low level stuff: http://www.myimg.de/?img=ieinwineef89e.png The related COM interfaces for the IE Style UI are implemented in shdocvw (IWebBrowser and IInternetExplorer) and browseui (for user elements: Menu, Addressbar) You need to copy shdocvw.dll, browseui.dll and browselc.dll to ~/.wine_drive_c/windows/system32/ and override shdocvw and browseui to native. (native browseui.dll needs browselc.dll) It works, but it's unstable and the Menu as well as the Addressbar are absend (not registered in Wine). register browseui.dll (or use regedit for minimal changes) "Menu Band" CLSID: {5b4dae26-b807-11d0-9815-00c04fd91972} InProcServer32 is "%systemroot%\system32\browseui.dll" and ThreadingModel is Apartment "Address" has CLSID {01E04581-4EEE-11D0-BFE9-00AA005B4383} InProcServer32 is "%systemroot%\system32\browseui.dll", ThreadingModel is Apartment and Implemented Categories need the subkey {00021492-0000-0000-C000-000000000046} (IE8 has still the full IE6 style UI available) Happy testing, and don't forget to fill bugzilla. -- By by ... Detlef

1 0

Re: [1/2] imm32: Fix ImmAssociateContextEx Parameter Handling
by Nikolay Sivov 23 Apr '10

23 Apr '10

On 4/23/2010 16:14, André Hentschel wrote: > --- > dlls/imm32/imm.c | 13 ++++++++++--- > dlls/imm32/tests/imm32.c | 8 ++++---- > 2 files changed, 14 insertions(+), 7 deletions(-) > > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 2a85b70..2fd6477 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -516,12 +516,19 @@ static BOOL CALLBACK _ImmAssociateContextExEnumProc(HWND hwnd, LPARAM lParam) > */ > BOOL WINAPI ImmAssociateContextEx(HWND hWnd, HIMC hIMC, DWORD dwFlags) > { > - TRACE("(%p, %p, %d): stub\n", hWnd, hIMC, dwFlags); > + TRACE("(%p, %p, 0x%x):\n", hWnd, hIMC, dwFlags); > > if (!IMM_GetThreadData()->defaultContext) > IMM_GetThreadData()->defaultContext = ImmCreateContext(); > > - if (dwFlags == IACE_DEFAULT) > + if (!hWnd) return FALSE; > + > + if (!dwFlags) > + { > + ImmAssociateContext(hWnd,hIMC); > + return TRUE; > + } > + else if (dwFlags == IACE_DEFAULT) > { > ImmAssociateContext(hWnd,IMM_GetThreadData()->defaultContext); > return TRUE; > @@ -539,7 +546,7 @@ BOOL WINAPI ImmAssociateContextEx(HWND hWnd, HIMC hIMC, DWORD dwFlags) > } > else > { > - ERR("Unknown dwFlags 0x%x\n",dwFlags); > + FIXME("Unknown dwFlags 0x%x\n",dwFlags); > return FALSE; > } > } > Some comments for this. Why return value from ImmAssociateContext is never used? Also it nicely turns to switch() for this dwFlags parameter, but it's a matter of taste.

1 0

DNS-sd Patch V.4
by C.W. Betts 23 Apr '10

23 Apr '10

Due to the fact that Mac OS X has the dns-sd functions in it's main library (libSystem.B.dylib), I thought it unwise to try to unload it. This patch The Photoshop CS3 installer seems to stall during installation due to the lack of Bonjour (bug 15590). This patch attempts to fix it.

3 4

Re: Intercept relay_call causes seh:raise_exception code=c0000005
by Jui-Hao Chiang 22 Apr '10

22 Apr '10

Hi, All: I also find out 2 special things (1) The address of the array which causes the exception happens to be the memory-mapped address of comctl32.dll (check the /proc/../smaps) (2) If the address of the array is pointing to heap (from my malloc), or some other places which are not occupied by any dll, then "no" exception will occur Originally I doubt the exception may be the bug of the RPC library I am using (libc6-dev package inside Ubuntu). However, if that's the case, my malloc pointer should also cause exception (but it doesn't) Still hope someone can give a hint on how to debug this question Best wishes, Jui-Hao > > Message: 11 > Date: Wed, 21 Apr 2010 09:37:53 -0400 > From: Jui-Hao Chiang <windtracekimo(a)gmail.com> > Subject: Intercept relay_call causes seh:raise_exception code=c0000005 > To: wine-devel(a)winehq.org > Message-ID: > <i2h52cf60ee1004210637gc7f20e5dq9b958127331b18cf(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, All, I am currently using the WINEDEBUG=relay feature to intercept > function calls as the following > > 1. in dlls/ntdll/relay.c, insert code snippet in > static LONGLONG WINAPI relay_call( struct relay_descr *descr, unsigned > int idx, const INT_PTR *stack ) > { > ..... > my_own_function(entry_point->name, nb_args stack); /* added by myself */ > ret = call_entry_point( entry_point->orig_func, nb_args, stack + 1 ); > /* original Wine code*/ > .... > } > > LONGLONG > my_own_function(const char *funcname, int nb_args, const INT_PTR *stack) > { > /* CreateBitmap has 5 parameters, the 5th one is pointing to an array > while others are native type as the following > HBITMAP WINAPI CreateBitmap( INT width, INT height, UINT planes, > UINT bpp, LPCVOID bits ) > */ > if (strcmp(funcname, "CreateBitmap") == 0) > Rpc_CreateBitmap(*(stack+1), *(stack+2), *(stack+3), > *(stack+4), *(stack+5)); // this function just try to forward all > parameters to remote RPC server for record > } > > 2. Run program with WINEDEBUG=trace+all,relay wine notepad > dump 2>&1 > 3. If I only pass the parameter 1 to 4 to Rpc_CreateBitmap, then there > is no problem, but if I add the 5th one (which points to some array), > then the notepad aborts with he following debug message > > 0009:Call gdi32.CreateBitmap(00000008,00000008,00000001,00000001,7e95d822) > ret=7e8da083 > 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0xb754a21d > ip=b754a21d tid=0009 > 0009:trace:seh:raise_exception info[0]=00000001 > 0009:trace:seh:raise_exception info[1]=7e95d822 > 0009:trace:seh:raise_exception eax=00000055 ebx=b7593ff4 ecx=0033fa4c > edx=00000001 esi=7e95d822 edi=00000001 > 0009:trace:seh:raise_exception ebp=0033fa54 esp=0033fa44 cs=0073 > ds=007b es=007b fs=0033 gs=003b flags=00010202 > 0009:trace:seh:call_vectored_handlers calling handler at 0x7b83fd50 > code=c0000005 flags=0 > 0009:trace:seh:call_vectored_handlers handler at 0x7b83fd50 returned 0 > 0009:trace:seh:call_stack_handlers calling handler at 0x7bc4a480 > code=c0000005 flags=0 > 0009:trace:seh:__regs_RtlUnwind code=c0000005 flags=2 > 0009:trace:seh:__regs_RtlUnwind calling handler at 0x7bc6bc50 > code=c0000005 flags=2 > 0009:trace:seh:__regs_RtlUnwind handler at 0x7bc6bc50 returned 1 > 0009:exception in PE entry point > (proc=0x7e95a890,module=0x7e8c0000,reason=PROCESS_ATTACH,res=0x1) > > 4. But if I use malloc to copy the content of the array pointed by 5th > parameter, then there is no problem > LONGLONG > my_own_function(const char *funcname, int nb_args, const INT_PTR *stack) > { > char *buffer = NULL; > if (strcmp(funcname, "CreateBitmap") == 0) { > buffer = (char*)malloc(.....); > memcpy(buffer, *(stack+5), ....); > Rpc_CreateBitmap(*(stack+1), *(stack+2), *(stack+3), > *(stack+4), buffer); /* No exception if I do this */ > } > > Can anyone gives me a hint that what's happening here? or I am doing > some illegal operations? > Appreciate any comments, > Jui-Hao >

2 2