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

Re: [PATCH 7/7] bcrypt: Mostly implement AES decryption
by Marvin Dec. 2, 2016

Dec. 2, 2016

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 https://testbot.winehq.org/JobDetails.pl?Key=27082 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 6/7] bcrypt: Implement AES encryption
by Marvin Dec. 2, 2016

Dec. 2, 2016

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 https://testbot.winehq.org/JobDetails.pl?Key=27081 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 5/7] bcrypt: Beginnings of the AES provider
by Marvin Dec. 2, 2016

Dec. 2, 2016

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 https://testbot.winehq.org/JobDetails.pl?Key=27080 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/7] bcrypt: Implement BCryptGenerateSymmetricKey function
by Bruno Jesus Dec. 2, 2016

Dec. 2, 2016

OOps, sorry for that. I pasted the wrong command in the terminal. This is the real deal but was only supposed to be sent if the previous 5 test patches were commited. On Fri, Dec 2, 2016 at 8:28 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > From: Hans Leidekker <hans(a)codeweavers.com> > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/bcrypt/bcrypt_main.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/dlls/bcrypt/bcrypt_main.c b/dlls/bcrypt/bcrypt_main.c > index 6023c94..50c05c0 100644 > --- a/dlls/bcrypt/bcrypt_main.c > +++ b/dlls/bcrypt/bcrypt_main.c > @@ -138,6 +138,8 @@ NTSTATUS WINAPI BCryptEnumAlgorithms(ULONG dwAlgOperations, ULONG *pAlgCount, > > #define MAGIC_ALG (('A' << 24) | ('L' << 16) | ('G' << 8) | '0') > #define MAGIC_HASH (('H' << 24) | ('A' << 16) | ('S' << 8) | 'H') > +#define MAGIC_KEY (('K' << 24) | ('E' << 16) | ('Y' << 8) | '0') > + > struct object > { > ULONG magic; > @@ -172,6 +174,8 @@ struct algorithm > BOOL hmac; > }; > > +static ULONG get_block_size( enum alg_id alg ); > + > NTSTATUS WINAPI BCryptGenRandom(BCRYPT_ALG_HANDLE handle, UCHAR *buffer, ULONG count, ULONG flags) > { > const DWORD supported_flags = BCRYPT_USE_SYSTEM_PREFERRED_RNG; > @@ -541,6 +545,37 @@ static NTSTATUS hmac_finish( struct hash *hash, UCHAR *output, ULONG size ) > pgnutls_hmac_deinit( hash->u.hmac_handle, output ); > return STATUS_SUCCESS; > } > + > +struct key > +{ > + struct object hdr; > + enum alg_id alg_id; > + ULONG block_size; > + gnutls_cipher_hd_t handle; > + UCHAR *secret; > + ULONG secret_len; > +}; > + > +static NTSTATUS key_init( struct key *key, enum alg_id id, UCHAR *secret, ULONG secret_len ) > +{ > + if (!libgnutls_handle) return STATUS_INTERNAL_ERROR; > + > + switch (id) > + { > + default: > + FIXME( "algorithm %u not supported\n", id ); > + return STATUS_NOT_SUPPORTED; > + } > + > + if (!(key->block_size = get_block_size( id ))) return STATUS_INVALID_PARAMETER; > + > + key->alg_id = id; > + key->handle = 0; /* initialized on first use */ > + key->secret = secret; > + key->secret_len = secret_len; > + > + return STATUS_SUCCESS; > +} > #else > struct hash > { > @@ -584,6 +619,17 @@ static NTSTATUS hmac_finish( struct hash *hash, UCHAR *output, ULONG size ) > ERR( "support for hashes not available at build time\n" ); > return STATUS_NOT_IMPLEMENTED; > } > + > +struct key > +{ > + struct object hdr; > +}; > + > +static NTSTATUS key_init( struct key *key, enum alg_id id, const UCHAR *secret, ULONG secret_len ) > +{ > + ERR( "support for keys not available at build time\n" ); > + return STATUS_NOT_IMPLEMENTED; > +} > #endif > > #define OBJECT_LENGTH_MD5 274 > @@ -694,6 +740,13 @@ static NTSTATUS get_alg_property( enum alg_id id, const WCHAR *prop, UCHAR *buf, > return STATUS_SUCCESS; > } > > +static ULONG get_block_size( enum alg_id alg ) > +{ > + ULONG ret = 0, size = sizeof(ret); > + get_alg_property( alg, BCRYPT_BLOCK_LENGTH, (UCHAR *)&ret, sizeof(ret), &size ); > + return ret; > +} > + > static NTSTATUS get_hash_property( enum alg_id id, const WCHAR *prop, UCHAR *buf, ULONG size, ULONG *ret_size ) > { > NTSTATUS status; > @@ -854,6 +907,32 @@ NTSTATUS WINAPI BCryptHash( BCRYPT_ALG_HANDLE algorithm, UCHAR *secret, ULONG se > return BCryptDestroyHash( handle ); > } > > +NTSTATUS WINAPI BCryptGenerateSymmetricKey( BCRYPT_ALG_HANDLE algorithm, BCRYPT_KEY_HANDLE *handle, > + UCHAR *object, ULONG object_len, UCHAR *secret, ULONG secret_len, > + ULONG flags ) > +{ > + struct algorithm *alg = algorithm; > + struct key *key; > + NTSTATUS status; > + > + TRACE( "%p, %p, %p, %u, %p, %u, %08x\n", alg, handle, object, object_len, secret, secret_len, flags ); > + > + if (!alg || alg->hdr.magic != MAGIC_ALG) return STATUS_INVALID_HANDLE; > + if (object) FIXME( "ignoring object buffer\n" ); > + > + if (!(key = HeapAlloc( GetProcessHeap(), 0, sizeof(*key) ))) return STATUS_NO_MEMORY; > + key->hdr.magic = MAGIC_KEY; > + > + if ((status = key_init( key, alg->id, secret, secret_len ))) > + { > + HeapFree( GetProcessHeap(), 0, key ); > + return status; > + } > + > + *handle = key; > + return STATUS_SUCCESS; > +} > + > BOOL WINAPI DllMain( HINSTANCE hinst, DWORD reason, LPVOID reserved ) > { > switch (reason) > -- > 2.9.3 >

1 0

Re: [PATCH v3] winemapi: Directly use xdg-email if available, enabling file attachments.
by André Hentschel Dec. 2, 2016

Dec. 2, 2016

Hi, comments inline Am 22.11.2016 um 20:46 schrieb Jeremy White: > -ULONG WINAPI MAPISendMail(LHANDLE session, ULONG_PTR uiparam, > +static ULONG BrowserSendMail(LHANDLE session, ULONG_PTR uiparam, > lpMapiMessage message, FLAGS flags, ULONG reserved) > { > ULONG ret = MAPI_E_FAILURE; > @@ -291,6 +370,129 @@ exit: > return ret; > } Do you need all those parameters? > +/************************************************************************** > + * XDGSendMail > + * > + * Send a message using xdg-email mail client. > + * > + */ > +ULONG XDGSendMail(LHANDLE session, ULONG_PTR uiparam, > + lpMapiMessage message, FLAGS flags, ULONG reserved) Same here Also should be a static function > + > + TRACE("(0x%08lx 0x%08lx %p 0x%08x 0x%08x)\n", session, uiparam, message, flags, reserved); I'd keep the TRACE in the WINAPI function > + > + if (!message) > + return MAPI_E_FAILURE; maybe this check, too > + max_args = 1 + (2 + message->nRecipCount + message->nFileCount) * 2; > + argv = HeapAlloc(GetProcessHeap(), 0, (max_args + 1) * sizeof(*argv)); > + if (!argv) > + return MAPI_E_INSUFFICIENT_MEMORY; > + > + ret = add_argument(argv, &argc, "xdg-email", NULL); > + if (ret != SUCCESS_SUCCESS) > + goto exit; > + > + if (message->lpOriginator) > + TRACE("From: %s (unused)\n", debugstr_a(message->lpOriginator->lpszAddress)); Why is the TRACE message different from the original function? > + > + for (i = 0; i < message->nRecipCount; i++) > + { > + if (!message->lpRecips) > + { > + WARN("Recipient %d missing\n", i); > + ret = MAPI_E_FAILURE; > + goto exit; > + } > + > + if (message->lpRecips[i].lpszAddress) > + { > + ret = add_target(argv, &argc, message->lpRecips[i].ulRecipClass, add_target is only used in one place, no need for a helper function IMO > + message->lpRecips[i].lpszAddress); > + if (ret != SUCCESS_SUCCESS) > + goto exit; > + } > + else > + FIXME("Name resolution and entry identifiers not supported\n"); > + } > + > + for (i = 0; i < message->nFileCount; i++) > + { > + TRACE("File Path: %s, name %s\n", debugstr_a(message->lpFiles[i].lpszPathName), > + debugstr_a(message->lpFiles[i].lpszFileName)); > + ret = add_file(argv, &argc, message->lpFiles[i].lpszPathName, message->lpFiles[i].lpszFileName); Same for add_file Hope that helps

2 1

Re: [PATCH 5/5] bcrypt/tests: Add BCryptEncrypt/Decrypt tests
by Marvin Dec. 2, 2016

Dec. 2, 2016

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 https://testbot.winehq.org/JobDetails.pl?Key=27070 Your paranoid android. === wvistau64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 598 bcrypt.c:848: Test failed: got 598 === w2008s64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 598 bcrypt.c:848: Test failed: got 598 === w7pro64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 622 bcrypt.c:848: Test failed: got 622 === w864 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 654 bcrypt.c:848: Test failed: got 654 === w1064 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 654 bcrypt.c:848: Test failed: got 654

2 2

Re: [PATCH 4/5] bcrypt/tests: Add BCryptGenerateSymmetricKey tests
by Marvin Dec. 2, 2016

Dec. 2, 2016

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 https://testbot.winehq.org/JobDetails.pl?Key=27069 Your paranoid android. === wvistau64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 598 bcrypt.c:848: Test failed: got 598 === w2008s64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 598 bcrypt.c:848: Test failed: got 598 === w7pro64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 622 bcrypt.c:848: Test failed: got 622 === w864 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 654 bcrypt.c:848: Test failed: got 654 === w1064 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 654 bcrypt.c:848: Test failed: got 654

1 0

Re: [PATCH 3/5] bcrypt/tests: Add AES provider tests
by Marvin Dec. 2, 2016

Dec. 2, 2016

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 https://testbot.winehq.org/JobDetails.pl?Key=27068 Your paranoid android. === wvistau64 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 598 === w2008s64 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 598 === w7pro64 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 622 === w864 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 654 === w1064 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 654

1 0

Re: [PATCH 1/3] server: Introduced iosb struct for server-side IO_STATUS_BLOCK representation and use it in irp_call.
by Alexandre Julliard Dec. 2, 2016

Dec. 2, 2016

Jacek Caban <jacek(a)codeweavers.com> writes: > +/* release iosb reference */ > +void release_iosb( struct iosb *iosb ) > +{ > + if (--iosb->refcount) return; > + > + free( iosb->in_data ); > + free( iosb->out_data ); > + free( iosb ); > +} I think you should use a proper server object instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: server: Signal pipe server fd in create_pipe_server.
by Marvin Dec. 2, 2016

Dec. 2, 2016

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 https://testbot.winehq.org/JobDetails.pl?Key=27047 Your paranoid android. === w2008s64 (32 bit pipe) === Unable to set the VM system time: the "nc -q0 '10.42.42.136' '4242'" command returned 1 (settime/connect). Maybe the TestAgentd process is missing the required privileges. The test VM is powered off! Did the test shut it down?

1 0

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