November 2007 - Wine-devel - list.winehq.org

Re: shell32: Use SHStrDupW in IShellFolder2::GetDetailsOf to allocate returned string
by Vitaliy Margolen 02 Nov '07

02 Nov '07

Thomas Weidenmueller wrote: > Use SHStrDupW in IShellFolder2::GetDetailsOf to allocate the returned > string. pOleStr in the STRRET structure has to be allocated using > CoTaskMemAlloc(). SHStrDupW uses CoTaskMemAlloc() whereas StrDupW uses > LocalAlloc(). > > - Thomas > ------------------------------------------------------------------------ > > Index: recyclebin.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/recyclebin.c,v > retrieving revision 1.5 > diff -u -r1.5 recyclebin.c > --- recyclebin.c 11 Jun 2007 13:47:57 -0000 1.5 > +++ recyclebin.c 1 Nov 2007 21:58:30 -0000 Please diff it from the top of the source tree. The above should say dlls/shell32/recyclebin.c Vitaliy.

1 0

Re: [PATCH 02/18] inetcomm: Add a framework for connecting to a server and sending/receiving data asynchronously with callbacks being called in the context of the original thread, using window messages.
by Alexandre Julliard 02 Nov '07

02 Nov '07

Robert Shearman <rob(a)codeweavers.com> writes: > +#include "winsock2.h" > +#include "winuser.h" > + > +#undef GetProp > +#undef SendMessage > +#undef SetProp > + > +#include "objbase.h" > +#include "imnxport.h" You forgot to submit the new imnxport.idl. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: setupapi: Add stub for SetupInstallServicesFromInfSectionW
by Robert Shearman 02 Nov '07

02 Nov '07

Chris Robinson wrote: > @ stdcall SetupInstallFromInfSectionA(long long str long long str long ptr ptr long ptr) > @ stdcall SetupInstallFromInfSectionW(long long wstr long long wstr long ptr ptr long ptr) > @ stdcall SetupInstallServicesFromInfSectionA(long str long) > +@ stdcall SetupInstallServicesFromInfSectionW(long wstr long) > @ stub SetupInstallServicesFromInfSectionExA > @ stub SetupInstallServicesFromInfSectionExW > -@ stub SetupInstallServicesFromInfSectionW > @ stdcall SetupIterateCabinetA(str long ptr ptr) > @ stdcall SetupIterateCabinetW(wstr long ptr ptr) > @ stub SetupLogErrorA > There's no need to move the entry for SetupInstallServicesFromInfSectionW. The list was sorted alphabetically, but now it isn't. -- Rob Shearman

3 2

Valgrind and structs with holes
by Dan Kegel 02 Nov '07

02 Nov '07

Valgrind is a great tool, but if there's a struct with a hole in it, and we write that struct to a socket (say, to send it to the server), valgrind will likely complain that the hole is uninitialized. For instance, the warning ==3415== Syscall param writev(vector[1]) points to uninitialised byte(s) ==3415== at 0x40007F2: (within /lib/ld-2.6.1.so) ==3415== by 0x4412E24: wine_server_call (server.c:244) ==3415== by 0x43EBA73: server_ioctl_file (file.c:1010) ==3415== by 0x43EC570: NtFsControlFile (file.c:1223) ==3415== by 0x45394C1: WaitNamedPipeW (sync.c:1298) ==3415== by 0x453963B: WaitNamedPipeA (sync.c:1225) ==3415== by 0x46490B5: test_CreateNamedPipe (pipe.c:97) in kernel32/tests/sync.c can be silenced either by appeasing Valgrind with a patch like --- a/dlls/kernel32/sync.c +++ b/dlls/kernel32/sync.c @@ -1285,6 +1285,12 @@ BOOL WINAPI WaitNamedPipeW (LPCWSTR name, DWORD nTimeOut) return FALSE; } + /* FILE_PIPE_WAIT_FOR_BUFFER has a hole after boolean TimeoutSpecified. + * Clear the hole so valgrind doesn't get upset about uninitialized bytes. + * No need to zero Name[1...], which is initialized ok later. + */ + memset(pipe_wait, 0, sizeof(FILE_PIPE_WAIT_FOR_BUFFER)); or by using a suppression like { wine_struct_hole_FILE_PIPE_WAIT_FOR_BUFFER Memcheck:Param writev(vector[1]) obj:* fun:wine_server_call fun:server_ioctl_file fun:NtFsControlFile fun:WaitNamedPipeW } Alexandre, which approach would you prefer? If you say #1, I'll eat my hat. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Exception but not when running with +relay
by Paul Vriens 02 Nov '07

02 Nov '07

Hi, I just tried the latest PE Explorer (http://www.heaventools.com/download-pe-explorer.htm) When I stopped the application I ran into an exception within NtSetInformationThread. If I however do a +relay I don't get into this exception. What does such a difference point to? -- Cheers, Paul.

1 0

valgrind results online
by Dan Kegel 02 Nov '07

02 Nov '07

I've posted results from running the entire conformance test suit under Valgrind at http://kegel.com/wine/valgrind/20071001/ There are 100 files there; one for each test that had warnings. (And one more file with everything concatenated together, http://kegel.com/wine/valgrind/20071001/vg-all.txt) A lot of the warnings are probably just problems in our conformance tests, not in Wine, and several of the warnings might be problems in Valgrind. But I wouldn't be surprised if there were several dozen real problems in Wine, so please take a look. (Juan has already submitted a bunch of cleanups for crypt32. I'll probably run these tests daily for a while and upload the results to a new directory for each day.) I've also updated the instructions on how to run tests under Valgrind, http://wiki.winehq.org/Wine_and_Valgrind and updated the Wine patch there to include a bunch more suppressions. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Dead code in dlls/ntdll/tape.c
by Gerald Pfeifer 01 Nov '07

01 Nov '07

We currently have the following code in tape.c: if (data->Offset.u.LowPart >= 0) { cmd.mt_op = MTFSF; cmd.mt_count = data->Offset.u.LowPart; } else { cmd.mt_op = MTBSF; cmd.mt_count = -data->Offset.u.LowPart; } data is of type TAPE_SET_POSITION*, which in turn is defined as typedef struct _TAPE_SET_POSITION { ULONG Method; ULONG Partition; LARGE_INTEGER Offset; BOOLEAN Immediate; } TAPE_SET_POSITION, *PTAPE_SET_POSITION; Offset is of type LARGE_INTEGER which is defined as struct { DWORD LowPart; LONG HighPart; } u; Note how LowPart is unsigned (DWORD) here, so indeed the comparisons for >= 0 is always going to evaluate to true. Hans, I believe you originally wrote that code. Do you remember what you where trying to do here? The patch below removes this dead code and is equivalent to what we currently have. I am not sure it is the desired way to fix what I describe above, though. Gerald Index: dlls/ntdll/tape.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/tape.c,v retrieving revision 1.16 diff -u -3 -p -r1.16 tape.c --- dlls/ntdll/tape.c 26 Jun 2007 12:14:34 -0000 1.16 +++ dlls/ntdll/tape.c 1 Nov 2007 16:32:29 -0000 @@ -427,25 +427,13 @@ static NTSTATUS TAPE_SetPosition( int fd break; #endif case TAPE_SPACE_FILEMARKS: - if (data->Offset.u.LowPart >= 0) { - cmd.mt_op = MTFSF; - cmd.mt_count = data->Offset.u.LowPart; - } - else { - cmd.mt_op = MTBSF; - cmd.mt_count = -data->Offset.u.LowPart; - } + cmd.mt_op = MTFSF; + cmd.mt_count = data->Offset.u.LowPart; break; #if defined(MTFSS) && defined(MTBSS) case TAPE_SPACE_SETMARKS: - if (data->Offset.u.LowPart >= 0) { - cmd.mt_op = MTFSS; - cmd.mt_count = data->Offset.u.LowPart; - } - else { - cmd.mt_op = MTBSS; - cmd.mt_count = -data->Offset.u.LowPart; - } + cmd.mt_op = MTFSS; + cmd.mt_count = data->Offset.u.LowPart; break; #endif case TAPE_LOGICAL_BLOCK:

3 2

Wine Gecko packaging
by Jacek Caban 01 Nov '07

01 Nov '07

Hello, As you probably have noticed, downloading Gecko on first use confuses users. Now, with last week patches, there is an other way to do it, transparent for users. MSHTML code looks for cab file in $data_dir/gecko (that is usually /usr/share/wine/gecko). Alternatively, if you run Wine from build dir, it looks for $build_dir/../gecko. Wine checks it both in wineprefixcreate and, if Gecko is not installed, on first usage. It means that if you download wine_gecko-0.1.0.cab from SourceForge and put it in the right place, you will no longer have to care about installing Gecko. Now, it's time to consider Linux packages to simplify its use. In Gentoo it may be a separate USE flag, but for other distributions that don't support such things, we'll need a separate package. Such package will need only one file placed in the right place, so it should be easy to do and maintain (I don't expect versions to change often). Are Wine packagers interested in creating Gecko packages? Thanks, Jacek

4 6

iexplore proxy server
by Luke Bratch 01 Nov '07

01 Nov '07

Hello Is there supposed to be a way to set a HTTP (or otherwise) proxy server in Wine's iexplore at the moment? I can't find any such documentation, but searching around has found a lot of people suggesting that setting these keys will help: [Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings] "ProxyEnable"=dword:00000001 "ProxyServer"="proxyserver:8080" Setting those didn't make any difference in iexplore, but the attached patch which edits a file that the Gecko installer creates, makes HTTP proxy support work perfectly. Is this the correct/only way to do this? Thanks Luke Bratch ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

2 1

Cleanup of riched20 tests - request for help on test_WM_PASTE
by Alex Villacís Lasso 01 Nov '07

01 Nov '07

I am currently trying to clean up the riched20 tests that are failing in WinXP. While doing this, I have encountered the following problem: on the function test_WM_PASTE() (at line 1959 of dlls/riched20/tests/editor.c in current git), the test is supposed to feed simulated keystrokes corresponding to Ctrl-C, Ctrl-V, and so on, supposedly to test copy and paste features via the keyboard. The problem is that the verification at line 1989 fails on WinXP, because the text on the control has not been modified - the control seems to disregard simulated WM_CHAR messages of the Ctrl-<keystroke> variety. The test at line 1977 succeeds accidentally, because the sequence of Ctrl-C, Ctrl-V, Ctrl-Z that is being tested is equivalent to not modifying the control text at all. A more through test would be to send WM_GETTEXT messages after each step to ensure that the text is actually being modified, but the bigger problem is how to make the control obey the keystrokes in the first place. If I place a message loop right before the DestroyWindow() call, I can send keystrokes manually and they work as expected. Only simulated WM_CHAR messages are being discarded. I have tried changing the SendMessage() calls into PostMessage() calls (since Visual Studio's Spy++ shows that WM_CHAR messages were posted, not sent), but to no avail. I have also tried placing message loops between messages, with no luck. I have even tried to simulate the WM_KEYDOWN and WM_KEYUP messages with parameters exactly as seen by Spy++, but this does not work either. So I am asking for help. What could be going wrong with this test? How can I feed the expected keystrokes so that the test works as expected? Has this test ever worked before? It fails in both WinXP (real machine) and inside a QEMU session running Win98. (All tests on WinXP were compiled with CygWin) -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

1 1