August 2015 - Wine-Devel - list.winehq.org

Re: Does wine send window messages without waiting apps to reenter userdll?

by Javier Pimás

I wrote a small test which I attach here, very small program where you can see if WndProc is called from WaitMessage. It fails, which I think shows what I doubted is actually happening. Tested in the old 1.6.2 wine and also in 1.7.50. Cheers! On Wed, Aug 26, 2015 at 11:29 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 26.08.2015 16:04, Sebastian Lackner wrote: > > If you are concerned that WaitMessage immediately dispatches the > messages, > > Wine doesn't do that. Processing of window messages is only done in the > > context of GetMessage and PeekMessage, no matter if its a "queued" or > > "non-queued" message. In fact Wine doesn't really make a difference > between > > the two, it just assigns specific internal message numbers for non-queued > > messages. To identify those the the highest bit (0x80000000) is set. > > After reading the last part again I noticed that I wasn't really very > precise, > because I somehow already assumed that you are talking about non-queued > messages > caused by SetWindowPos and things like that. Those are implemented using > internal > messages in Wine, and might be affected by the "bugs" mentioned in the > last mail. > > Besides that its of course also possible to send other non-queued messages > directly with SendMessage and similar functions. But in this case the > answer would > be the same: WaitMessage does not dispatch them immediately, they are > processed > during a call to PeekMessage or GetMessage. > > Regards, > Sebastian > > -- Javier Pimás Ciudad de Buenos Aires

Aug. 28, 2015

Re: Does wine send window messages without waiting apps to reenter userdll?

by Javier Pimás

Thanks for reading, sorry for the delay, I wanted to do more tests. Answer between lines On Wed, Aug 26, 2015 at 9:27 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Am 2015-08-25 um 22:09 schrieb Javier Pimás: > > Hi! this is a very low-level technical question and my first one to > > this list so please take with a grain of salt. I'm debugging a 32 > > bit app in wine 1.6.2, on ubuntu 15.04 64 bits. > I recommend to switch to the development version of Wine if you're > doing debugging like this. > > > The app I'm debugging is a smalltalk vm, so it is very possessive > > with the native stack, synchronization, callbacks and things like > > that. I'm having a problem that happens in wine and not in windows, > > and the following thing I describe might be the cause, it's very > > subtle. > I can't answer the core part of your question I'm afraid. I'm curious > though why this would make a difference. Does the VM place something > on the stack that the message handler expects to find? If so, how does > it find it? Does it expect a certain stack depth as well? > It's not so much for the stack shape but that the VM expects executing app code after returning from a WndProc. Before returning, the VM sets a RETURNED_FROM_CALLBACK flag, that is checked on method activations (very frequently). If WaitMessage doesn't return, a method activation doesn't occur and the flag is left active. A second non-queued message then reenters app code, and on the first method activation the flag is detected the code isn't where it supposed (after returning) but in another callback, confusing the app. This is not to mean the VM is bug free, the strange thing is that it behaves differently in wine and windows. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJV3bCaAAoJEN0/YqbEcdMwoXEP/Rss350C+9yjpzRoZKcXkhop > 37QwmLrlkXg7Br0xWhgltfiIXpmRcrKq1EgGah0m9YTfSTjLbOIz80XszUELSCCc > lGnTOlkvETCJMv7EdinIVehngpm4phRugpfZSDdPNnx+orJn6T87PkbDhwTZsZ6u > g3TljQ1sLbF2O/AOKzr8S3CltIkf5oReHB29T4DnABbQqfXm0X5PhyKPevCtnWTG > od3PgQprwCve+DJmikZAVrqQtyms9xaryLh9Xc3XrYO8YNe2lxgfKYJY8NA3tDsk > nA+A1sNZferqIl5xUMooaquzU9471FS5pItXRPsnXJ5zwrzC47afgF47bnLpUmaQ > R2B6Vt8mUlB/KpNnhzzu9Q/RrEDwOj8PxmY/lhcSH2y4Y3VTAQCY2Mhrqc2tdJWT > li8R6OCF24pA1EM7q/+5gB2hedO4kMHcy5LcDvtxXbamIafxuUCM6loG5LR2VE+x > 6qR1z+83CknyOOAm/MePNMDZqJ4dJmuM3V+8Dsv5YK5YtyM03i1Qy9l78jTkUGIG > 2jVsRW1Ske+Uz50cBtago9z8S01BTMsLtctmQeFfmushfPW5BUjRLrJD257EngVH > lqNSBDSV/u41EiDjapN3ASkcWrEihdOyYQLJAfDjwu4vAN5MMO27B3N14wL2zKQ0 > 5+q0DrKfLGFUTgIQL0bR > =J5gb > -----END PGP SIGNATURE----- > -- Javier Pimás Ciudad de Buenos Aires

Aug. 28, 2015

Re: ws2_32: WSACleanup cleans up open sockets (OSX only)

by Bruno Jesus

On Fri, Aug 28, 2015 at 8:30 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 28 August 2015 at 05:46, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: >> +DECL_HANDLER(close_all_sockets) > You'll want to just move this to sock.c and avoid making sock_ops > available outside sock.c. You may want to change the request name to > something along the lines of "close_process_sockets", since it only > closes sockets for the current process, not all sockets the server > knows about. I think a better name would be winsock_cleanup or socket_cleanup because closing the sockets may not be the only action required to proper implement WSACleanup. > + } > + else > + { > + TRACE("pending cleanups: %d\n", num_startup); > + } Please just drop the else and let the message be printed so the amount of cleanups and starts is always displayed in the log.

Aug. 28, 2015

Re: [PATCH 5/5] xaudio2/tests: Add callback tests

by Marvin

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=16390 Your paranoid android. === build (build) === Unable to regenerate dlls/xaudio2_7/Makefile Unable to regenerate dlls/xaudio2_7/Makefile

Aug. 28, 2015

Re: [PATCH 4/5] xaudio2: Add a simple audio streaming test

by Marvin

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=16389 Your paranoid android. === build (build) === Unable to regenerate dlls/xaudio2_7/Makefile Unable to regenerate dlls/xaudio2_7/Makefile

Aug. 28, 2015

Re: po: Update German translation.

by Florian Pelz

Sorry for sending to the wrong list. On 08/28/2015 03:03 PM, Florian Pelz wrote: > On 08/28/2015 02:35 PM, Julian Rüger wrote: >> +"Wine Anwendungsentferner\n" > > This needs a hyphen ("Wine-Anwendungsentferner\n"). >

Aug. 28, 2015

Re: ws2_32: WSACleanup cleans up open sockets (OSX only)

by Henri Verbeet

On 28 August 2015 at 05:46, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: > +DECL_HANDLER(close_all_sockets) You'll want to just move this to sock.c and avoid making sock_ops available outside sock.c. You may want to change the request name to something along the lines of "close_process_sockets", since it only closes sockets for the current process, not all sockets the server knows about. > +{ > + obj_handle_t sock; > + UINT index = 0; "unsigned int" would be more appropriate. > + while ( (sock = enumerate_handles(current->process, &sock_ops, &index)) > ) > + { > + close_handle(current->process, sock); > + } > +} > + The formatting here is a bit different from the rest of the server. (I.e., spaces around function parameter lists, no spaces around control statement conditions.)

Aug. 28, 2015

Re: [PATCH 5/5] d3d11/tests: Add test for 2D texture interfaces.

by Henri Verbeet

On 28 August 2015 at 00:39, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + hr = ID3D11Texture2D_QueryInterface(texture, &IID_IDXGISurface, (void **)&surface); > + ok(hr == E_NOINTERFACE, "Texture should not implement IDXGISurface.\n"); > + if (SUCCEEDED(hr)) IDXGISurface_Release(surface); You don't need the Release(), if the QueryInterface() would succeed the test would fail. > + if (FAILED(hr)) > + { > + skip("2D textures do not implement ID3D10Texture2D, skipping tests.\n"); This should probably be a win_skip(). You're leaking the device here. > + hr = ID3D11Device_CreateTexture2D(device, &desc, NULL, &texture); > + ok(SUCCEEDED(hr), "%u: Failed to create a 2d texture, hr %#x.\n", i, hr); > + if (FAILED(hr)) continue; ... > + hr = ID3D11Texture2D_QueryInterface(texture, &IID_IDXGISurface, (void **)&surface); > + ok(SUCCEEDED(hr), "%u: Texture should implement IDXGISurface.\n", i); > + if (SUCCEEDED(hr)) IDXGISurface_Release(surface); ... > + hr = ID3D11Texture2D_QueryInterface(texture, &IID_ID3D10Texture2D, (void **)&d3d10_texture); > + ok(SUCCEEDED(hr), "%u: Texture should implement ID3D10Texture2D.\n", i); > + if (SUCCEEDED(hr)) > + { Similar to above, you don't need to account for conditions where the test would fail.

Aug. 28, 2015

Re: [PATCH 4/5] d3d11/tests: Port test_create_texture2d() from d3d10core.

by Henri Verbeet

On 28 August 2015 at 00:39, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static ID3D11Device *create_default_device(void) > +{ > + ID3D11Device *device; > + > + if (SUCCEEDED(D3D11CreateDevice(NULL, D3D_DRIVER_TYPE_HARDWARE, NULL, 0, NULL, 0, D3D11_SDK_VERSION, > + &device, NULL, NULL))) > + return device; > + if (SUCCEEDED(D3D11CreateDevice(NULL, D3D_DRIVER_TYPE_WARP, NULL, 0, NULL, 0, D3D11_SDK_VERSION, > + &device, NULL, NULL))) > + return device; > + if (SUCCEEDED(D3D11CreateDevice(NULL, D3D_DRIVER_TYPE_REFERENCE, NULL, 0, NULL, 0, D3D11_SDK_VERSION, > + &device, NULL, NULL))) > + return device; > + > + return NULL; > +} > + I think I'd make the "feature_level" parameter to the existing create_device() a pointer, and then make it optional. See also e.g. create_device() in dlls/d3d9/tests/device.c.

Aug. 28, 2015

Re: [PATCH 3/5] d3d11: Implement d3d11_device_CreateTexture2D().

by Henri Verbeet

On 28 August 2015 at 00:39, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static inline struct d3d10_texture2d *impl_from_ID3D11Texture2D(ID3D11Texture2D *iface) > +{ > + return CONTAINING_RECORD(iface, struct d3d10_texture2d, ID3D11Texture2D_iface); > +} > + We usually try to keep these in the file that contains the interface implementation, texture.c in this case. We do make the occasional exception though. > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*object)); > + if (!object) You could just do "if (!(object = HeapAlloc(...)))" here, but it doesn't matter that much. > @@ -2006,15 +2025,12 @@ static HRESULT STDMETHODCALLTYPE d3d10_device_CreateTexture2D(ID3D10Device1 *ifa > { > struct d3d_device *device = impl_from_ID3D10Device(iface); > D3D11_TEXTURE2D_DESC d3d11_desc; > + ID3D11Texture2D *d3d11_texture; > struct d3d10_texture2d *object; > HRESULT hr; > > TRACE("iface %p, desc %p, data %p, texture %p.\n", iface, desc, data, texture); > > - object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*object)); > - if (!object) > - return E_OUTOFMEMORY; > - > d3d11_desc.Width = desc->Width; > d3d11_desc.Height = desc->Height; > d3d11_desc.MipLevels = desc->MipLevels; > @@ -2026,16 +2042,14 @@ static HRESULT STDMETHODCALLTYPE d3d10_device_CreateTexture2D(ID3D10Device1 *ifa > d3d11_desc.CPUAccessFlags = d3d11_cpu_access_flags_from_d3d10_cpu_access_flags(desc->CPUAccessFlags); > d3d11_desc.MiscFlags = d3d11_resource_misc_flags_from_d3d10_resource_misc_flags(desc->MiscFlags); > > - if (FAILED(hr = d3d10_texture2d_init(object, device, &d3d11_desc, data))) > - { > - WARN("Failed to initialize texture, hr %#x.\n", hr); > - HeapFree(GetProcessHeap(), 0, object); > + if (FAILED(hr = d3d11_device_CreateTexture2D(&device->ID3D11Device_iface, &d3d11_desc, > + (const D3D11_SUBRESOURCE_DATA *)data, &d3d11_texture))) > return hr; > - } > > + object = impl_from_ID3D11Texture2D(d3d11_texture); > *texture = &object->ID3D10Texture2D_iface; > > - TRACE("Created ID3D10Texture2D %p\n", object); > + TRACE("Created ID3D10Texture2D %p.\n", object); > > return S_OK; > } This change doesn't really seem worth it. You do save a couple of lines by avoiding the memory allocation, but you need to make impl_from_ID3D11Texture2D() available outside of texture.c to do it. You could create a d3d_texture2d_create() function similar to e.g. d3d9_swapchain_create() in d3d9 and avoid the duplication that way, but it may not make much of a difference in line count. Up to you.

Aug. 28, 2015