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

Re: [6/6] winhttp: main.c: Add stub implementation for WinHttpCloseHandle
by Zac Brown 07 Jul '08

07 Jul '08

Zac Brown wrote: > Add stub implementation for WinHttpCloseHandle > > ignore, forgot patch.

1 0

Incompatible behavior regarding SetCapture/ReleaseCapture & dialogs
by Andreas Rosenberg 07 Jul '08

07 Jul '08

Hi all! About 3 years ago, I reported a few incompatiblities in Wine, that caused problems with an application called IQ-FMEA, that our company is developing. Some things I could fix myself and sent them to wine-patches and they were accepted. One incompatibility between Windows & Wine is still there and causes problems in our app when operating various dialogs (most important the common file dialog, because this happens frequently). To demonstrate the problem, I wrote a small app. It may be included into the conformance test library, but it's a little bit tricky, so I'm unsure how to do something like this. Scenario: Two windows A and B exist. - Window B captures the mouse input. - Window A opens the CommonFileDialog (GetOpenFileName,GetSaveFileName, ChooseFont) - during the open process of the CommonFileDialog the mouse capture is released on Windows (between the 2nd & the 3rd WM_NOTIFY being passed to the OFNHookProc). The dialog is automatically closed by the hook proc, by posting WM_COMMAND with IDCANCEL. On Wine the mouse capture is not release, making it impossible to operate the dialog with the mouse. The same scenario may happen with ChooseFont (and probably more dialog windows). log output of my test app on Windows XP: Testing GetOpenFileName Wnd with capture:000201fe WM_INITDIALOG:000201fe WM_NOTIFY:000201fe - fffffda7 - (0) WM_NOTIFY:000201fe - fffffda5 - (1) WM_NOTIFY:00000000 - fffffda6 - (2) Quitting dialog Wnd with capture:00000000 Testing ChooseFont Wnd with capture:000201fe WM_INITDIALOG:000201fe WM_CTLCOLORDLG:00000000 - (0) Quitting dialog Wnd with capture:00000000 log output of my test app on Wine 1.1.0 (for OpenSuse 10.3) Testing GetOpenFileName Wnd with capture:0001002a WM_INITDIALOG:0001002a WM_NOTIFY:0001002a - fffffda7 - (0) WM_NOTIFY:0001002a - fffffda5 - (1) WM_NOTIFY:0001002a - fffffda6 - (2) CommonFileDialog - mouse capture should have been released now! Quitting dialog Wnd with capture:0001002a Testing ChooseFont Wnd with capture:0001002a WM_INITDIALOG:0001002a WM_CTLCOLORDLG:0001002a - (0) ChooseFontDialog - mouse capture should have been released now! Quitting dialog Wnd with capture:0001002a Maybe someone being more familiar with the internal framework can take a look into this problem. Regards, Andreas

1 0

Re: quartz: Fix deadlock with transform filter
by Alexandre Julliard 07 Jul '08

07 Jul '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > diff --git a/dlls/quartz/acmwrapper.c b/dlls/quartz/acmwrapper.c > index d877930..22bfb87 100644 > --- a/dlls/quartz/acmwrapper.c > +++ b/dlls/quartz/acmwrapper.c > @@ -186,7 +186,9 @@ static HRESULT ACMWrapper_ProcessSampleData(TransformFilterImpl* pTransformFilte > } > TRACE("Sample stop time: %u.%03u\n", (DWORD)(tStart/10000000), (DWORD)((tStart/10000)%1000)); > > + LeaveCriticalSection(&This->tf.csFilter); > hr = OutputPin_SendSample((OutputPin*)This->tf.ppPins[1], pOutSample); > + EnterCriticalSection(&This->tf.csFilter); This looks very wrong this the lock wasn't grabbed by this function, it will violate expectations of the caller. It looks like the locking strategy needs some more thought. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [dxdiagn] [resend] Implemented szDeviceIdentifier property in dxdiagn dll
by James Hawkins 07 Jul '08

07 Jul '08

On Mon, Jul 7, 2008 at 12:46 PM, Markus <kde(a)graph-ix.net> wrote: > If d3d9 could not be properly initialized, the value 'n/a' is set. This > behavior has been verified against the native dxdiagn.dll. The > corresponding testcase will follow once I have time. > You forgot the patch. -- James Hawkins

2 1

CUDA wrapper
by Seth Shelnutt 07 Jul '08

07 Jul '08

As a continuation from the question on making the FAH GPU2 Nvidia client run, we have gotten past the detecting the card as we changed Wine's generic output to look like an Nvidia card thanks to a few of you. Now comes the hard part. Even when using the cudart.dll file it does not work. We get an cudastream error about it not being implemented. It then repeats these 5 lines until the client is stopped. Reading file work/wudata_07.tpr, VERSION 3.1.4 (single precision) Reading file work/wudata_07.tpr, VERSION 3.1.4 (single precision) Reading sasa-enabled ir 0 0 Initializing Nvidia gpu library cudaMalloc CUDAStream::Allocate failed feature is not yet implemented Martijn Berger said here ( http://www.winehq.org/pipermail/wine-devel/2008-July/067063.html) that all that should need to be done is right a wrapper to translate the calls from cudart.dll to libcuda.so.2.0. I suppose the place to start would be to download the SDK's and see how much documentation is available on both the Linux and Windows calls. -Seth Shelnutt

4 10

Re: [1/2] Retyped find_in_cache's transformation matrix parameter.
by Michael Karcher 07 Jul '08

07 Jul '08

Am Montag, den 07.07.2008, 17:17 +0200 schrieb Michael Karcher: Sorry for commentless resending. I am too stupid to notice that July had begun and considered the mail lost as it didn't appear in June's archive. Still I wonder why the patch (series) didn't make it in. Any feedback? Regards, Michael Karcher

1 0

Re: [PATCH 2/4] widl: Write out calls to freeing functions for return types on the server in generated code.
by Alexandre Julliard 07 Jul '08

07 Jul '08

"Rob Shearman" <robertshearman(a)gmail.com> writes: > tools/widl/proxy.c | 3 +++ > tools/widl/server.c | 3 +++ > 2 files changed, 6 insertions(+), 0 deletions(-) This one doesn't work: ../../../tools/runtest -q -P wine -M rpcrt4.dll -T ../../.. -p rpcrt4_test.exe.so server.c && touch server.ok err:rpc:I_RpcReceive we got fault packet with status 0x3e6 wine: Unhandled exception 0x000003e6 at address 0x7b8449a0 (thread 001a), starting debugger... Unhandled exception: 0x000003e6 in 32-bit code (0x7b844a16). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b844a16 ESP:0033f9f4 EBP:0033fa58 EFLAGS:00000246( - 00 - IZP1) EAX:7b82eb79 EBX:7b8b30e8 ECX:00110048 EDX:00000000 ESI:0033fac4 EDI:00000000 Stack dump: 0x0033f9f4: 00000000 0011fa30 0033fa20 608b0dd4 0x0033fa04: 000003e6 00000000 00000000 7b8449a0 0x0033fa14: 00000000 608abe79 608abd5c 000003e6 0x0033fa24: 0011f840 00000000 608a2567 00110000 0x0033fa34: 00000000 0011fa30 608b0dd4 00000000 0x0033fa44: 0033fba0 0033fa78 60899ea8 0033fba0 Backtrace: =>1 0x7b844a16 RaiseException+0x76(code=0x3e6, flags=0x0, nbargs=0x0, args=0x0) [/home/julliard/wine/wine/dlls/kernel32/except.c:85] in kernel32 (0x0033fa58) 2 0x608a2e75 RpcRaiseException+0x35(exception=0x3e6) [/home/julliard/wine/wine/dlls/rpcrt4/rpcrt4_main.c:184] in rpcrt4 (0x0033fa78) 3 0x60874e30 NdrFreeBuffer(pStubMsg=0x1) [/home/julliard/wine/wine/dlls/rpcrt4/ndr_clientserver.c:184] in rpcrt4 (0x0033faa8) 4 0x6055ecab get_filename+0x7b() [/home/julliard/wine/wine/dlls/rpcrt4/tests/server_c.c:4198] in rpcrt4_test (0x0033fbd8) 5 0x6055c2e1 basic_tests+0xb41() [/home/julliard/wine/wine/dlls/rpcrt4/tests/server.c:850] in rpcrt4_test (0x0033fd58) 6 0x6055cf5d run_tests+0x1d() [/home/julliard/wine/wine/dlls/rpcrt4/tests/server.c:865] in rpcrt4_test (0x0033fe08) 7 0x6055dfd6 func_server+0x586() [/home/julliard/wine/wine/dlls/rpcrt4/tests/server.c:1262] in rpcrt4_test (0x0033fe68) 8 0x6056b0f0 run_test+0x130(name=0x110403) [/home/julliard/wine/wine/dlls/rpcrt4/tests/../../../include/wine/test.h:451] in rpcrt4_test (0x0033fea8) 9 0x6056b2f3 main+0x133(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/rpcrt4/tests/../../../include/wine/test.h:499] in rpcrt4_test (0x0033fed8) 10 0x6056ba7b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in rpcrt4_test (0x0033ff08) 11 0x7b876d47 start_process+0xc7(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:904] in kernel32 (0x0033ffe8) 12 0x600289c7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x7b844a16 RaiseException+0x76 [/home/julliard/wine/wine/dlls/kernel32/except.c:85] in kernel32: movl 0xfffffffc(%ebp),%ebx -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 1/4] widl: Optimise the generated code by skipping calls calling the type function directly for some reference pointers.
by Alexandre Julliard 07 Jul '08

07 Jul '08

"Rob Shearman" <robertshearman(a)gmail.com> writes: > Skip calling the Pointer marshalling/unmarshalling/buffer > sizing/freeing function in this case. This one doesn't work either: ../../../tools/runtest -q -P wine -M qmgr.dll -T ../../.. -p qmgr_test.exe.so file.c && touch file.ok fixme:qmgr:BITS_IBackgroundCopyJob_AddFile Check for valid filenames and supported protocols file.c:127: Test failed: Got incorrect remote name wine: Unhandled page fault on read access to 0x89fffffe at address 0x60540d3a (thread 0025), starting debugger... Unhandled exception: page fault on read access to 0x89fffffe in 32-bit code (0x60540d3a). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:60540d3a ESP:0032fe00 EBP:0032fe68 EFLAGS:00010202( - 00 - -RI1) EAX:89fffffe EBX:60b5edd4 ECX:c000000d EDX:00000000 ESI:7ffbc000 EDI:00320000 Stack dump: 0x0032fe00: 00122c4c 00000001 60546b54 00000000 0x0032fe10: 60546b48 00000003 605441ac 60546720 0x0032fe20: 605441a2 60546b48 60545398 60545378 0x0032fe30: 0032fe58 60546084 60546b4c 7b876ba4 0x0032fe40: 7bca34cc 00000001 71670f10 11dd4c1e 0x0032fe50: 1a00835a cb923592 00000039 6054621c Backtrace: =>1 0x60540d3a func_file+0x27a() [/home/julliard/wine/wine/dlls/qmgr/tests/file.c:108] in qmgr_test (0x0032fe68) 2 0x6054328a run_test+0x14a(name=0x1103e5) [/home/julliard/wine/wine/dlls/qmgr/tests/../../../include/wine/test.h:451] in qmgr_test (0x0032fea8) 3 0x60543ae2 main+0x142(argc=<register ECX not in topmost frame>, argv=0x1103c8) [/home/julliard/wine/wine/dlls/qmgr/tests/../../../include/wine/test.h:499] in qmgr_test (0x0032fed8) 4 0x60543bbb __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in qmgr_test (0x0032ff08) 5 0x7b876d47 start_process+0xc7(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:904] in kernel32 (0x0032ffe8) 6 0x600289c7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x60540d3a func_file+0x27a [/home/julliard/wine/wine/dlls/qmgr/tests/file.c:108] in qmgr_test: movl 0x0(%eax),%edx 108 IBackgroundCopyFile_Release(test_file); -- Alexandre Julliard julliard(a)winehq.org

1 0

Support of USB hardware tokens
by Alexander Morozov 07 Jul '08

07 Jul '08

Hello All, I created a patch which adds support of USB hardware tokens with native Windows drivers (.sys): ftp://ftp.etersoft.ru/pub/download/amorozov/0001-Support-of-native-Windows-drivers-for-USB-tokens.txt Now SafeNet UltraPro (driver sntnlusb.sys, vid/pid 04b9:0300) and Eutron SmartKey 3 (driver eusk3usb.sys, vid/pid 073d:0025) are supported. These devices are used by some Windows applications for piracy defense. This patch adds dlls/usbd.sys, dlls/wineusbhub and programs/wineusb. Usbd.sys is exist also in Windows. This is a kernel level DLL exporting some functions required for USB drivers. Wineusbhub plays a role of a lower driver in device stack (under USB token driver). Wineusb is a service calling driver`s AddDevice routine if there is a registry key corresponding to device and device is plugged. Now this check is executed only when wineusb is starting. USB driver is loaded by programs/winedevice. Now AddDevice and some PNP functions are called in addition to DriverEntry. Calling DriverEntry is realized by means of wineserver requests. Some required ntoskrnl.exe functions are added. For using native USB driver should copy HKLM\System\CurrentControlSet\Enum\USB\Vid_<vid>&Pid_<pid> and HKLM\System\CurrentControlSet\Services\<driver_name> from Windows registry. HKLM\System\CurrentControlSet\Services\<driver_name>\Start should be setted to 2. I`d like to add this patch to Wine. What about this? I think should split my patch into many little commits. Should also add some tests or make some changes? Thanks, Alexander Morozov

2 2

Odd valgrind error in imm.c, possible fix
by Dan Kegel 06 Jul '08

06 Jul '08

Today a test got stuck, and I had to kill wineserver. After that, lots of tests seem to have the same error: + Invalid read of size 4 + at IMM_FreeThreadData (imm.c:233) + by DllMain (imm.c:385) + by __wine_spec_dll_entry (dll_entry.c:40) + by (within /home/dank/wine-git/dlls/ntdll/ntdll.dll.so) + by MODULE_InitDLL (loader.c:910) + by process_detach (loader.c:1081) + by LdrShutdownProcess (loader.c:2143) + by ExitProcess (process.c:2101) + by service_run_main_thread (service.c:604) + by StartServiceCtrlDispatcherW (service.c:703) + by wmain (device.c:287) + Address 0x0 is not stack'd, malloc'd or (recently) free'd Presumably this is because killing wineserver also killed the background notepad I run to keep from having to valgrind wineboot etc. over and over again. If the immediate cause is something like imm32's DllMain getting called with DLL_PROCESS_DETACH after being called with DLL_THREAD_DETACH, the following patch might be a sensible fix. Is it? diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c index 94b7752..bcd11f1 100644 --- a/dlls/imm32/imm.c +++ b/dlls/imm32/imm.c @@ -230,10 +230,13 @@ static void IMM_InitThreadData(void) static void IMM_FreeThreadData(void) { IMMThreadData* data = TlsGetValue(tlsIndex); - IMM_DestroyContext(data->defaultContext); - DestroyWindow(data->hwndDefault); - HeapFree(GetProcessHeap(),0,data); - TRACE("Thread Data Destroyed\n"); + if (data) + { + IMM_DestroyContext(data->defaultContext); + DestroyWindow(data->hwndDefault); + HeapFree(GetProcessHeap(),0,data); + TRACE("Thread Data Destroyed\n"); + } } static HMODULE LoadDefaultWineIME(void)

1 0