December 2016 - Wine-Devel - list.winehq.org

Re: [PATCH] dxgi: Silence a noisy fixme
by Henri Verbeet Dec. 2, 2016

Dec. 2, 2016

On 2 December 2016 at 10:26, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > static HRESULT STDMETHODCALLTYPE dxgi_output_WaitForVBlank(IDXGIOutput *iface) > { > - FIXME("iface %p stub!\n", iface); > + BOOL once = FALSE; > + > + if (!once++) > + FIXME("iface %p stub!\n", iface); > > return E_NOTIMPL; > } Did you test that this does what you think it does? Leaving that issue aside for the moment, while printing the FIXME only once is probably fine, not tracing anything on subsequent calls isn't.

1 0

Re: [PATCH] dxgi: Silence a noisy fixme
by Hans Leidekker Dec. 2, 2016

Dec. 2, 2016

On Fri, 2016-12-02 at 09:26 +0000, Alistair Leslie-Hughes wrote: > diff --git a/dlls/dxgi/output.c b/dlls/dxgi/output.c > index 0cf8084..61a7043 100644 > --- a/dlls/dxgi/output.c > +++ b/dlls/dxgi/output.c > @@ -268,7 +268,10 @@ static HRESULT STDMETHODCALLTYPE dxgi_output_FindClosestMatchingMode(IDXGIOutput > > static HRESULT STDMETHODCALLTYPE dxgi_output_WaitForVBlank(IDXGIOutput *iface) > { > - FIXME("iface %p stub!\n", iface); > + BOOL once = FALSE; > + > + if (!once++) > + FIXME("iface %p stub!\n", iface); > > return E_NOTIMPL; > } static BOOL once;

1 0

Call for tests - GNU/Linux & specially OSX - iphlpapi
by Bruno Jesus Dec. 1, 2016

Dec. 1, 2016

Hello all, in order to exercise an IP ordering problem from bug 40247 (OSX) [1] I would like to request help for testing the crosstest at [2]. Valid testers must have at least 1 network interface with a valid IP and a the loopback interface up. A good test should result in 1 error, if not send me the results anyway, only the traces from lines 262 and 266 are needed (first in the log, 10 lines should be enough). If you find the lines I'm expecting just paste them, if you don't have patience just attach the whole results, pĺease. Sample output: bruno(a)Note:~/programs/wine32/dlls/iphlpapi/tests$ wine iphlpapi_crosstest.exe iphlpapi.c:262: Entry[0]: addr 127.0.0.1, dwIndex 1, wType 0x1 iphlpapi.c:266: Test failed: Loopback interface wrongly at position 0/3 iphlpapi.c:262: Entry[1]: addr 192.168.1.34, dwIndex 3, wType 0x1 iphlpapi.c:262: Entry[2]: addr 192.168.112.1, dwIndex 4, wType 0x1 iphlpapi.c:262: Entry[3]: addr 192.168.27.1, dwIndex 5, wType 0x1 [1] https://bugs.winehq.org/show_bug.cgi?id=40247 [2] https://testbot.winehq.org/JobDetails.pl?Key=27012 Thanks in advance, Bruno

2 2

Testing Direct3D
by Fabian Maurer Dec. 1, 2016

Dec. 1, 2016

Hello Wine-Devel, It might be a stupid question, but how do you test the Direct3D implementation? I don't mean the conformance tests, these too need to get the data somewhere. So you probably have a windows running somewhere. I currently I don't have a windows machine to test on though. Only a Virtualbox VM, and this doesn't offer (reliable) 3D acceleration for DX > 9. Do you have your own windows machine dedicated to this, or how do you do it?

3 5

Re: [PATCH 2/2] winmm: Use a thread to send driver messages on Win9x (try 2)
by Andrew Eikum Dec. 1, 2016

Dec. 1, 2016

This seems like something you should be able to write a test for. I'm also curious how this manages to work on Windows >= XP You need to be more careful about thread shutdown. See WINMM_StartDevicesThread and WINMM_DevicesThreadProc. I think you could use the same logic, including WINMM_DevicesThreadDone, to determine when to quit your new thread. Andrew On Thu, Dec 01, 2016 at 11:32:35AM -0200, Bruno Jesus wrote: > try 2: > Use a better way to detect Win9x (thanks Dmitry) > Use a single point of config/teardown and a pointer to callback (thanks Nikolay) > > More detailed explanation in the patch comments. Basically the games use a DLL that calls SuspendThread from inside the WinMM callback, this makes the program hang as we use the "main thread" to dispatch callbacks. > > Games tested in Win95 config: > Heroes of Might & Magic (well known affected) > Deadlock (well known affected) > Worms 2 (just to ensure things still work) > Age of Empires (just to ensure things still work) > Shivers (just to ensure things still work) > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=3930 > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/winmm/waveform.c | 117 ++++++++++++++++++++++++++++++++++++++++++-------- > dlls/winmm/winemm.h | 1 + > dlls/winmm/winmm.c | 2 +- > 3 files changed, 101 insertions(+), 19 deletions(-) > > diff --git a/dlls/winmm/waveform.c b/dlls/winmm/waveform.c > index 7308519..4387c44 100644 > --- a/dlls/winmm/waveform.c > +++ b/dlls/winmm/waveform.c > @@ -134,6 +134,13 @@ struct _WINMM_MMDevice { > WINMM_Device *devices[MAX_DEVICES]; > }; > > +static struct { > + HANDLE thread, event_main, event_thread; > + WINMM_CBInfo *info; > + WORD msg; > + DWORD_PTR param1, param2; > +} win9x; > + > static WINMM_MMDevice *g_out_mmdevices; > static WINMM_MMDevice **g_out_map; > static UINT g_outmmdevices_count; > @@ -192,6 +199,77 @@ static LRESULT WID_Open(WINMM_OpenInfo *info); > static LRESULT WID_Close(HWAVEIN hwave); > static MMRESULT WINMM_BeginPlaying(WINMM_Device *device); > > +static void (*pWINMM_NotifyClient)(WINMM_CBInfo *info, WORD msg, DWORD_PTR param1, > + DWORD_PTR param2); > + > + > +static DWORD WINAPI win9x_callback_thread(LPVOID param) > +{ > + while(WaitForSingleObject(win9x.event_thread, INFINITE) == WAIT_OBJECT_0) > + { > + if (!win9x.info->hwave) break; > + DriverCallback(win9x.info->callback, win9x.info->flags, (HDRVR)win9x.info->hwave, > + win9x.msg, win9x.info->user, win9x.param1, win9x.param2); > + SetEvent(win9x.event_main); > + } > + return 0; > +} > + > +/* Note: NotifyClient should never be called while holding the device lock > + * since the client may call wave* functions from within the callback. */ > +static inline void WINMM_NotifyClient(WINMM_CBInfo *info, WORD msg, DWORD_PTR param1, > + DWORD_PTR param2) > +{ > + DriverCallback(info->callback, info->flags, (HDRVR)info->hwave, > + msg, info->user, param1, param2); > +} > + > +static inline void WINMM_NotifyClient9x(WINMM_CBInfo *info, WORD msg, DWORD_PTR param1, > + DWORD_PTR param2) > +{ > + /* Prepare callback data for the thread, dispatch and wait response */ > + win9x.info = info; > + win9x.msg = msg; > + win9x.param1 = param1; > + win9x.param2 = param2; > + SetEvent(win9x.event_thread); > + WaitForSingleObject(win9x.event_main, INFINITE); > +} > + > +void WINMM_SetupCallback(void) > +{ > + pWINMM_NotifyClient = WINMM_NotifyClient; > + if (!(GetVersion() & 0x80000000)) > + return; > + > + /* WAIL32.DLL from Rad Game Tools is an audio helper DLL that simplifies the > + * use of sound effects in an application. It seems to be released in 1996 and > + * is used at least by Heroes of Might and Magic and Deadlock. Unfortunately > + * during a callback to the DLL it calls SuspendThread on the main thread and > + * keeps doing some stuff from inside the callback until it does a ResumeThread > + * and returns from the callback. This works in Windows 95/98 because they use > + * a separate thread to send callback messages. XP changed this by going back > + * to a single thread but the games still works due to shim. > + */ > + TRACE("Using old behavior of WinMM callbacks\n"); > + win9x.event_thread = CreateEventA(NULL, FALSE, FALSE, NULL); > + win9x.event_main = CreateEventA(NULL, FALSE, FALSE, NULL); > + win9x.thread = CreateThread(NULL, 0, win9x_callback_thread, NULL, 0, NULL); > + if (win9x.event_thread && win9x.event_main && win9x.thread) > + pWINMM_NotifyClient = WINMM_NotifyClient9x; > + else > + { > + ERR("Failed to create resources for callback, expect problems!\n"); > + TerminateThread(win9x.thread, 0); > + CloseHandle(win9x.event_main); > + CloseHandle(win9x.event_thread); > + CloseHandle(win9x.thread); > + win9x.event_main = win9x.event_thread = win9x.thread = NULL; > + return; > + } > +} > + > +/* tear down function for DLL process detach */ > void WINMM_DeleteWaveform(void) > { > UINT i, j; > @@ -241,6 +319,18 @@ void WINMM_DeleteWaveform(void) > HeapFree(GetProcessHeap(), 0, g_device_handles); > HeapFree(GetProcessHeap(), 0, g_handle_devices); > > + if (win9x.thread) > + { > + /* warn the thread so it can die gracefully */ > + win9x.info->hwave = 0; > + SetEvent(win9x.event_thread); > + > + CloseHandle(win9x.event_main); > + CloseHandle(win9x.event_thread); > + CloseHandle(win9x.thread); > + win9x.event_main = win9x.event_thread = win9x.thread = NULL; > + } > + > DeleteCriticalSection(&g_devthread_lock); > } > > @@ -370,15 +460,6 @@ static WINMM_Device *WINMM_GetDeviceFromHWAVE(HWAVE hwave) > return device; > } > > -/* Note: NotifyClient should never be called while holding the device lock > - * since the client may call wave* functions from within the callback. */ > -static inline void WINMM_NotifyClient(WINMM_CBInfo *info, WORD msg, DWORD_PTR param1, > - DWORD_PTR param2) > -{ > - DriverCallback(info->callback, info->flags, (HDRVR)info->hwave, > - msg, info->user, param1, param2); > -} > - > static MMRESULT hr2mmr(HRESULT hr) > { > switch(hr){ > @@ -1753,7 +1834,7 @@ exit: > WAVEHDR *next = first->lpNext; > first->dwFlags &= ~WHDR_INQUEUE; > first->dwFlags |= WHDR_DONE; > - WINMM_NotifyClient(&cb_info, WOM_DONE, (DWORD_PTR)first, 0); > + pWINMM_NotifyClient(&cb_info, WOM_DONE, (DWORD_PTR)first, 0); > first = next; > } > } > @@ -1929,7 +2010,7 @@ exit: > WAVEHDR *next = first->lpNext; > first->dwFlags &= ~WHDR_INQUEUE; > first->dwFlags |= WHDR_DONE; > - WINMM_NotifyClient(&cb_info, WIM_DATA, (DWORD_PTR)first, 0); > + pWINMM_NotifyClient(&cb_info, WIM_DATA, (DWORD_PTR)first, 0); > first = next; > } > } > @@ -2022,9 +2103,9 @@ static LRESULT WINMM_Reset(HWAVE hwave) > first->dwFlags &= ~WHDR_INQUEUE; > first->dwFlags |= WHDR_DONE; > if(is_out) > - WINMM_NotifyClient(&cb_info, WOM_DONE, (DWORD_PTR)first, 0); > + pWINMM_NotifyClient(&cb_info, WOM_DONE, (DWORD_PTR)first, 0); > else > - WINMM_NotifyClient(&cb_info, WIM_DATA, (DWORD_PTR)first, 0); > + pWINMM_NotifyClient(&cb_info, WIM_DATA, (DWORD_PTR)first, 0); > first = next; > } > > @@ -2774,7 +2855,7 @@ MMRESULT WINAPI waveOutOpen(LPHWAVEOUT lphWaveOut, UINT uDeviceID, > cb_info.user = dwInstance; > cb_info.hwave = info.handle; > > - WINMM_NotifyClient(&cb_info, WOM_OPEN, 0, 0); > + pWINMM_NotifyClient(&cb_info, WOM_OPEN, 0, 0); > > return res; > } > @@ -2802,7 +2883,7 @@ UINT WINAPI waveOutClose(HWAVEOUT hWaveOut) > res = SendMessageW(g_devices_hwnd, WODM_CLOSE, (WPARAM)hWaveOut, 0); > > if(res == MMSYSERR_NOERROR) > - WINMM_NotifyClient(&cb_info, WOM_CLOSE, 0, 0); > + pWINMM_NotifyClient(&cb_info, WOM_CLOSE, 0, 0); > > return res; > } > @@ -3410,7 +3491,7 @@ MMRESULT WINAPI waveInOpen(HWAVEIN* lphWaveIn, UINT uDeviceID, > cb_info.user = dwInstance; > cb_info.hwave = info.handle; > > - WINMM_NotifyClient(&cb_info, WIM_OPEN, 0, 0); > + pWINMM_NotifyClient(&cb_info, WIM_OPEN, 0, 0); > > return res; > } > @@ -3438,7 +3519,7 @@ UINT WINAPI waveInClose(HWAVEIN hWaveIn) > res = SendMessageW(g_devices_hwnd, WIDM_CLOSE, (WPARAM)hWaveIn, 0); > > if(res == MMSYSERR_NOERROR) > - WINMM_NotifyClient(&cb_info, WIM_CLOSE, 0, 0); > + pWINMM_NotifyClient(&cb_info, WIM_CLOSE, 0, 0); > > return res; > } > @@ -3586,7 +3667,7 @@ UINT WINAPI waveInStop(HWAVEIN hWaveIn) > if(buf){ > buf->dwFlags &= ~WHDR_INQUEUE; > buf->dwFlags |= WHDR_DONE; > - WINMM_NotifyClient(&cb_info, WIM_DATA, (DWORD_PTR)buf, 0); > + pWINMM_NotifyClient(&cb_info, WIM_DATA, (DWORD_PTR)buf, 0); > } > > return MMSYSERR_NOERROR; > diff --git a/dlls/winmm/winemm.h b/dlls/winmm/winemm.h > index d7bab0f..10cd0f4 100644 > --- a/dlls/winmm/winemm.h > +++ b/dlls/winmm/winemm.h > @@ -151,6 +151,7 @@ void TIME_MMTimeStop(void) DECLSPEC_HIDDEN; > > MMRESULT WINMM_CheckCallback(DWORD_PTR dwCallback, DWORD fdwOpen, BOOL mixer) DECLSPEC_HIDDEN; > > +void WINMM_SetupCallback(void) DECLSPEC_HIDDEN; > void WINMM_DeleteWaveform(void) DECLSPEC_HIDDEN; > > /* Global variables */ > diff --git a/dlls/winmm/winmm.c b/dlls/winmm/winmm.c > index 0f3cd5d..358f139 100644 > --- a/dlls/winmm/winmm.c > +++ b/dlls/winmm/winmm.c > @@ -139,7 +139,7 @@ BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID fImpLoad) > > if (!WINMM_CreateIData(hInstDLL)) > return FALSE; > - > + WINMM_SetupCallback(); > break; > case DLL_PROCESS_DETACH: > if(fImpLoad) > -- > 2.9.3 > > >

2 8

Re: [PATCH 1/2] server: Store async list in process object and use that to find async in cansel_async request.
by Alexandre Julliard Dec. 1, 2016

Dec. 1, 2016

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -614,6 +615,7 @@ static void process_destroy( struct object *obj ) > > /* we can't have a thread remaining */ > assert( list_empty( &process->thread_list )); > + assert( list_empty( &process->asyncs )); I don't think that this is guaranteed, I believe that there can still be asyncs in the queues of shared files. We'd probably need to clear them explicitly at process exit. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH] iphlpapi: Ensure GetIpAddrTable returns loopback addresses in the end
by Alexandre Julliard Dec. 1, 2016

Dec. 1, 2016

Bruno Jesus <00cpxxx(a)gmail.com> writes: > Manually tested by other people in GNU/Linux and OSX, in every case > loopback was returned first while in all testbot Windows machines and > my Windows machines the loopback comes after everything. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=40247 > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/iphlpapi/iphlpapi_main.c | 27 +++++++++++++++++++++------ > dlls/iphlpapi/tests/iphlpapi.c | 4 ++++ > 2 files changed, 25 insertions(+), 6 deletions(-) This breaks the tests here: ../../../tools/runtest -q -P wine -T ../../.. -M ws2_32.dll -p ws2_32_test.exe.so sock && touch sock.ok sock.c:2489: Tests skipped: SOCK_RAW is not supported sock.c:6947: Test failed: got 11002 expected WSAHOST_NOT_FOUND sock.c:6948: Test failed: expected 11001, got 11002 sock.c:7197: Test failed: got 11002 expected WSAHOST_NOT_FOUND sock.c:7198: Test failed: expected 11001, got 11002 sock.c:8648: Tests skipped: Cannot test SIO_ADDRESS_LIST_CHANGE, interactive tests must be enabled Makefile:208: recipe for target 'sock.ok' failed make: *** [sock.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] winspool.drv: Clear last error when creating mutex
by Alexandre Julliard Dec. 1, 2016

Dec. 1, 2016

"A. Wilcox" <AWilcox(a)Wilcox-Tech.com> writes: > A stale error may reside in thread-local storage that causes > WINSPOOL_LoadSystemPrinters to believe initialisation has already > occurred. CreateMutex always sets last error, so this can't make any difference. There must be something else going on. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] winmm: Use a thread to send driver messages on Win9x
by Nikolay Sivov Dec. 1, 2016

Dec. 1, 2016

On Thu, 1 Dec 2016 04:40:22 -0200 Bruno Jesus <00cpxxx(a)gmail.com> wrote: > More detailed explanation in the patch comments. Basically the games use a DLL that calls SuspendThread from inside the WinMM callback, this makes the program hang as we use the "main thread" to dispatch callbacks. > > Games tested in Win95 config: > Heroes of Might & Magic (well known affected) > Deadlock (well known affected) > Worms 2 (just to ensure things still work) > Age of Empires (just to ensure things still work) > Shivers (just to ensure things still work) > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=3930 > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/winmm/waveform.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 76 insertions(+), 2 deletions(-) > > diff --git a/dlls/winmm/waveform.c b/dlls/winmm/waveform.c > index 7308519..24d7e30 100644 > --- a/dlls/winmm/waveform.c > +++ b/dlls/winmm/waveform.c > @@ -134,6 +134,14 @@ struct _WINMM_MMDevice { > WINMM_Device *devices[MAX_DEVICES]; > }; > > +static struct { > + BOOL is, checked; > + HANDLE thread, event_main, event_thread; > + WINMM_CBInfo *info; > + WORD msg; > + DWORD_PTR param1, param2; > +} win9x; > + > static WINMM_MMDevice *g_out_mmdevices; > static WINMM_MMDevice **g_out_map; > static UINT g_outmmdevices_count; > @@ -286,6 +294,13 @@ static WINMM_Device *WINMM_FindUnusedDevice(WINMM_Device **devices, > { > UINT i; > > + if (!win9x.checked) > + { > + win9x.checked = TRUE; > + if ((GetVersion() & 0xFF) < 5) > + win9x.is = TRUE; > + } > + This only needs to happen during dll initialization. I think cleaner way for a change you're proposing will be two separate vtable structures, one for win9x and another one for the rest. This way you can select appropriate vtable once on dll initialization, and keep this selection forever as a global pointer for example. > /* Note: NotifyClient should never be called while holding the device lock > * since the client may call wave* functions from within the callback. */ > static inline void WINMM_NotifyClient(WINMM_CBInfo *info, WORD msg, DWORD_PTR param1, > DWORD_PTR param2) > { > - DriverCallback(info->callback, info->flags, (HDRVR)info->hwave, > - msg, info->user, param1, param2); > + if (win9x.is) > + { > > HeapFree(GetProcessHeap(), 0, device->orig_fmt); > + if (win9x.thread) > + { > + /* warn the thread so it can die gracefully */ > + win9x.info->hwave = 0; > + SetEvent(win9x.event_thread); > + > + CloseHandle(win9x.event_main); > + CloseHandle(win9x.event_thread); > + CloseHandle(win9x.thread); > + win9x.event_main = win9x.event_thread = win9x.thread = NULL; > + } > > return S_OK; > } This will also let you to get rid of conditional implementation like above.

1 0

Re: [PATCH] winmm: Use a thread to send driver messages on Win9x
by Dmitry Timoshkov Dec. 1, 2016

Dec. 1, 2016

Bruno Jesus <00cpxxx(a)gmail.com> wrote: > + if ((GetVersion() & 0xFF) < 5) > + win9x.is = TRUE; A more correct check for win9x would be if ((GetVersion() & 0x80000000) win9x.is = TRUE; -- Dmitry.

1 0