September 2015 - Wine-Devel

Re: [2/2] kernel32: Implement Set/GetThreadGroupAffinity and add tests.

by Sebastian Lackner

On 23.09.2015 23:35, Marvin wrote: > 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=16838 > > Your paranoid android. > > > === w1064 (32 bit thread) === > thread.c:1087: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE) > This is unrelated to the patch.

Sept. 23, 2015

Re: [2/2] kernel32: Implement Set/GetThreadGroupAffinity and add 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=16838 Your paranoid android. === w1064 (32 bit thread) === thread.c:1087: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

Sept. 23, 2015

Re: Inconsistent argument type declaration in dinput.h: WriteEffectToFile()

by Elias Vanderstuyft

On Tue, Sep 22, 2015 at 10:00 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > On 09/22/2015 09:32 PM, Elias Vanderstuyft wrote: >> On Mon, Sep 21, 2015 at 11:06 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: >>> On Mon, Sep 21, 2015 at 10:15:32PM +0200, Elias Vanderstuyft wrote: >>>> Hi everyone, >>>> >>>> The docs of IDirectInputDevice8::WriteEffectToFile() declare the third >>>> argument as >>>> LPCDIFILEEFFECT rgDiFileEft: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_… >>>> This is inconsistent with Microsoft's "dinput.h" file, they declare it as >>>> LPDIFILEEFFECT (thus, no "const"): >>>> ftp://sccn.ucsd.edu/pub/LSL/lsl-dependencies/external_libs/EmbarcaderoXE/sh… >>>> Wine's "dinput.h" follows the same mistake as Microsoft's: >>>> https://github.com/wine-mirror/wine/blob/master/include/dinput.h#L1866 >>>> >>>> Is there a particular reason for this? >>> >>> No, it was probably missed. >>> >>> I am sending a patch. >> >> Thanks, I suppose a patch to Wine? > Yes. > >> And leave Microsoft unnotified? > You can of course notify Microsoft. They might even update MSDN to > reflect the header. > > bye > michael OK, thanks! Cheers, Elias

Sept. 23, 2015

Re: Videos or Slides from WineConf

by Saulius Krasuckas

* On Wed, 23 Sep 2015, Marcus Meissner wrote: > I supplied the names as far as I remembered. > > Please review, correct and add missing ones. Thank you and Michael Mueller, and Nikolay Sivov. Nice to see Wine-staging guys there. Then unexpectedly I see two guys from China: Qian and Jactry -- cool! And even His Misteriousity A. Focht seems to be there! Waiting for videos. Congrats to all the commandos:) S.

Sept. 23, 2015

Re: [PATCH 11/12] ddraw: cache active DCs

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > + sub_resource = wined3d_texture_get_sub_resource(surface_impl->wined3d_texture, surface_impl->sub_resource_idx); > + wined3d_surface = wined3d_surface_from_resource(sub_resource); > + if (FAILED(hr = wined3d_surface_getdc(wined3d_surface, &surface_dc))) I expect the getdc call to fail because the application already called GetDC. I think you can just add a HDC dc field to struct wined3d_surface and compare it to the dc passed to GetSurfaceFromDC. > + if (!hdc) > { > - TRACE("No surface found for dc %p.\n", hdc); > *Surface = NULL; > return DDERR_NOTFOUND; > } Personally I prefer to write a WARN if we return failure to the application. Note that this is just my personal choice though, the existing code is not consistent here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAnJqAAoJEN0/YqbEcdMwGTwP/3zCYpjVZYY0M3Mafxs7j3Dq WPDkiiRzshspPTLIx3kurk7lRd2JXa8GbXZ8bOjx6bOz9wZC1wtejQEwLGhENOgz bzX9tyYT2FdRXVXM0V0bEOAvd0rivgIeE0xcPWYZg289bHTx4bw/3Ql+uSsUY/8L lamfMT5xOKhZmr6T5mI3MpHjUnbIUtBrOHvAggNexfl+RcvlFgmsl1MqajBHO+O7 W1ws4F35MzbXiEKUNEX3yH1cr3WRW+9xcAi89YYTnOTIpYsJHGOOOXoAeF1G2W2c dvj131zQRdlIknLxxZPZXSQJJffdiDdnuJ6xeMfJ1f9SdH0PNPKhX08wH2Wz+Zr8 77zY0vK2iqnAl0HUcq4WrL4TLh60VU2UeyhAy8vqYjso60OvANAmYBljgO5Z4oI/ mypsa1sq11Vrp+DAIaxFyj15whgdV2tE/NvC4Kapx4OK8DTQ+9xHGJoED9AX/E+/ OvynPYd/r/WPYyIYJpSv/YOAN4OAusNpY7i4nlXu8RbphTFcNZTrtLU/EUJCfI6T LaEx3TX9/Dg4BNrwY72cPleLKSZbGK1/59q0XWbH5Oft8HS48jL7IEJkNsNtJpqf GOJr/EotzHpJC2QGKOZ19NhgcCb22GbF8jCniLMVUSj/DelDzKOJs+5VaRiFcNqo AVr5Gv4UMzGlq7CjMo4v =UoFu -----END PGP SIGNATURE-----

Sept. 23, 2015

Re: [PATCH 11/12] ddraw: cache active DCs

by Riccardo Bortolato

The idea behind this is that only wined3d calls need to lock that mutex. Once we come back to ddraw, we can release it. Ciao, Riccardo 2015-09-23 11:25 GMT+02:00 Jonas Maebe <jonas.maebe(a)elis.ugent.be>: > > Riccardo Bortolato wrote on Wed, 23 Sep 2015: > > Disclaimer: I'm everything but an expert on Wine internals, so I'm just > asking in case I'm not missing something obvious. > >> - surface_impl = wined3d_surface_get_parent(wined3d_surface); >> - *Surface = &surface_impl->IDirectDrawSurface7_iface; >> - IDirectDrawSurface7_AddRef(*Surface); >> - TRACE("Returning surface %p.\n", Surface); >> - return DD_OK; >> + wined3d_mutex_lock(); >> + LIST_FOR_EACH_ENTRY(surface_impl, &ddraw->active_dcs, struct >> ddraw_surface, active_dcs_entry) > > > Here you get a mutex lock before iterating over the active_dcs. > >> + if (surface_dc == hdc) >> + { >> + wined3d_mutex_unlock(); >> + *Surface = &surface_impl->IDirectDrawSurface7_iface; >> + IDirectDrawSurface7_AddRef(*Surface); >> + TRACE("Returning surface %p.\n", Surface); >> + return DD_OK; >> + } > > > Here you free the lock before increasing the reference count. At first > sight, it would seem that you either don't need the lock while iterating, or > that you should increase the reference count before releasing the lock in > order to avoid races (unless the lock is for a completely unrelated reason) > >> --- a/dlls/ddraw/surface.c >> +++ b/dlls/ddraw/surface.c >> @@ -2176,7 +2176,9 @@ static HRESULT WINAPI >> ddraw_surface7_GetDC(IDirectDrawSurface7 *iface, HDC *hdc) >> if(hdc) *hdc = NULL; >> return DDERR_INVALIDPARAMS; >> >> - default: return hr; >> + default: >> + list_add_head(&surface->ddraw->active_dcs, >> &surface->active_dcs_entry); > > > Here you add something to the actives_dcs list without locking, so this can > race with the iterating (unless this is implicitly synchronised in another > way I'm not aware of). > > >> @@ -2246,6 +2248,8 @@ static HRESULT WINAPI >> ddraw_surface7_ReleaseDC(IDirectDrawSurface7 *iface, HDC h >> hr = ddraw_surface_update_frontbuffer(surface, NULL, FALSE); >> wined3d_mutex_unlock(); >> >> + list_remove(&surface->active_dcs_entry); >> + >> return hr; >> } > > > Similarly, here you remove an item after releasing the lock, so it can race > with both adding and iterating (same caveat). > > > Jonas

Sept. 23, 2015

Re: Videos or Slides from WineConf

by Marcus Meissner

On Wed, Sep 23, 2015 at 10:00:30AM +0300, Saulius Krasuckas wrote: > * On Wed, 23 Sep 2015, Austin English wrote: > > > http://wiki.winehq.org/WineConf2015 (under Agenda), > > Someone please add the names of participants under the photo. I see a > quite a few new faces this year -- it's nice to know! : ) I supplied the names as far as I remembered. Please review, correct and add missing ones. Ciao, Marcus

Sept. 23, 2015

Re: [PATCH 11/12] ddraw: cache active DCs

by Jonas Maebe

Riccardo Bortolato wrote on Wed, 23 Sep 2015: Disclaimer: I'm everything but an expert on Wine internals, so I'm just asking in case I'm not missing something obvious. > - surface_impl = wined3d_surface_get_parent(wined3d_surface); > - *Surface = &surface_impl->IDirectDrawSurface7_iface; > - IDirectDrawSurface7_AddRef(*Surface); > - TRACE("Returning surface %p.\n", Surface); > - return DD_OK; > + wined3d_mutex_lock(); > + LIST_FOR_EACH_ENTRY(surface_impl, &ddraw->active_dcs, struct > ddraw_surface, active_dcs_entry) Here you get a mutex lock before iterating over the active_dcs. > + if (surface_dc == hdc) > + { > + wined3d_mutex_unlock(); > + *Surface = &surface_impl->IDirectDrawSurface7_iface; > + IDirectDrawSurface7_AddRef(*Surface); > + TRACE("Returning surface %p.\n", Surface); > + return DD_OK; > + } Here you free the lock before increasing the reference count. At first sight, it would seem that you either don't need the lock while iterating, or that you should increase the reference count before releasing the lock in order to avoid races (unless the lock is for a completely unrelated reason) > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -2176,7 +2176,9 @@ static HRESULT WINAPI > ddraw_surface7_GetDC(IDirectDrawSurface7 *iface, HDC *hdc) > if(hdc) *hdc = NULL; > return DDERR_INVALIDPARAMS; > > - default: return hr; > + default: > + list_add_head(&surface->ddraw->active_dcs, > &surface->active_dcs_entry); Here you add something to the actives_dcs list without locking, so this can race with the iterating (unless this is implicitly synchronised in another way I'm not aware of). > @@ -2246,6 +2248,8 @@ static HRESULT WINAPI > ddraw_surface7_ReleaseDC(IDirectDrawSurface7 *iface, HDC h > hr = ddraw_surface_update_frontbuffer(surface, NULL, FALSE); > wined3d_mutex_unlock(); > > + list_remove(&surface->active_dcs_entry); > + > return hr; > } Similarly, here you remove an item after releasing the lock, so it can race with both adding and iterating (same caveat). Jonas

Sept. 23, 2015

Re: [PATCH 01/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX volumes

by Riccardo Bortolato

I personally prefer going {volume,surface}->wined3d_texture over {volume,surface}->{volume, texture}->wined3d_texture, also I'm not really sure this is applicable to the way ddraw currently works (I might be wrong though). Ciao, Riccardo 2015-09-23 10:51 GMT+02:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: >> - HRESULT (__cdecl *volume_created)(struct wined3d_device_parent >> *device_parent, void *container_parent, - struct >> wined3d_volume *volume, void **parent, const struct >> wined3d_parent_ops **parent_ops); + HRESULT (__cdecl >> *volume_created)(struct wined3d_device_parent *device_parent, + >> struct wined3d_texture *texture, unsigned int sub_resource_idx, + >> void **parent, const struct wined3d_parent_ops **parent_ops); > Is there a reason why you're passing the wined3d_texture container > instead of the container parent? It doesn't matter too much because > you can either do wined3d_resource_get_parent or > d3d*_texture->wined3d_texture, but I think it is a needless change. > > It seems the patch is bigger than it needs to be. You could just add > unsigned int sub_resource_idx and keep the rest in place. Through > struct d3d8_texture *texture inside struct d3d8_volume you already > have access to the wined3d texture. With the addition of the sub > resource idx you can migrate the volume methods one by one, and in the > last patch that removes access to wined3d_volume drop struct > wined3d_volume *volume from the callback. > > For surfaces in d3d8 and d3d9 you have to make sure you're always > creating a d3d8/9_texture struct for plain surfaces, but this is > something you can change internally in d3d8/9. > > It doesn't matter too much for this patch because the volume API is > pretty simple, but the next patch is pretty complicated because it > changes all the stuff at once. It'll be terrible to bisect / fix if > there are regressions. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWAmguAAoJEN0/YqbEcdMwpecP/RqlgzxhIzYQikgOQHhMBuLr > 1jOtBW2aAj8qRCPebkM5JAGK+93Y+r9jrkFbJn01ZHKR1fQCfWQteCoMRUIDJ6Iz > TUf5IeuKsUMucU6XJ70kh/d8MQCauOKJizvROCg6F1qILF+W6higdGHC/6FjSqqb > GiXmYAtqGgOP3BGAjM4W4r8+A7yoqssLhLYmJggn8PlX6yFfdIwl/rpOdRfSC+9T > ADrncsPVPpyYFRnQI+atdQuMN5M/GvioqxFS24Fuq65tUqNaXC6D8BsGy0tk6bN2 > nZAWkSkrx1bSi24U7RzHbq936Z+qnUp5UH/ZkView8dp5dXiqjmOLucWd4WJ/+0I > rMjIduEPuLgDraKnE4vKtn5WpPmV/ITX6If5zI9fTuFBLwyIrC06lIeaGd5VOHiO > 2/U00pyIQuS9F6Ir73J0hl5CJITYhmSdT9xsz2sIBbQheZu7OYLqqfIHM0d3DGBk > tC3H9X4bJQh9nDzLy4IGVr2W2vqQgKIVGxyVcYFyvA448kP7/W2Z1i+ak9CevFGg > fVBrwoPtTzPIoucC9cQ1vnskTITgzSNCuy3t+HBKsbm+0+7VsDnq8CL7wrGbs8uN > hSXwpCA4qLsPyK+6XCuITB8rmkGVX3/2j6Ratf2lSgdZVexQfsK/+hWQYIwXzjki > otAB34aWZl2+f/socndA > =6ndo > -----END PGP SIGNATURE-----

Sept. 23, 2015

Re: [PATCH 02/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX surfaces

by Riccardo Bortolato

The idea is to change individual api calls later as some of them are *really* complicated (at least for me). Ciao, Riccardo 2015-09-23 10:57 GMT+02:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: >> wined3d_mutex_lock(); >> + sub_resource = wined3d_texture_get_sub_resource(bitmap_impl->wined3d_texture, bitmap_impl->sub_resource_idx); >> + wined3d_surface = wined3d_surface_from_resource(sub_resource); >> hr = wined3d_device_set_cursor_properties(device->wined3d_device, >> - hotspot_x, hotspot_y, bitmap_impl->wined3d_surface); >> + hotspot_x, hotspot_y, wined3d_surface); >> wined3d_mutex_unlock(); > You may want to consider changing wined3d_device_set_cursor_properties > to accept a wined3d_texture instead. Keep in mind though that this would > be a bit of a side quest, as you'll have to find out if native accepts > surfaces that are part of textures or just stand-alone surfaces created > by CreateImageSurface. If it is the latter (which I suspect it is) then > wined3d_texture alone is OK. Otherwise you need texture + idx. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWAmlwAAoJEN0/YqbEcdMwGlkP/RfRVsceuPRGgVE0yJvhV26U > ci6CDlrj4Lb2mFcH3IVlJKuJEOcT2TLrcx2hT3H2+0OjDBvAIJyLhzjxABaZsg0N > OU4TJCvLfPiieF0npy7EBpUoe+E8a4046DRnLJsooco1Cp+Fk2LZO4B1OjMoaexl > FaO9zoAO+3KlTNVwRKX65KnOsZB7PtP0soCS9Gsmvx1gwwVe42uQ8B5pSgQQzcgW > UablqGdE0NnUGN2Bcj6vxPdW14FEaWC7Mp8fBl8olLO/FdlEoehzUMO7bPJNgGr2 > wePB12qwmTfizcQ+Nmd5/HAGZMsn4vgfxu+kQSb0iaWxdgRtqKztlkLzAOFvGDTS > x+yZ2pWTcNp41MzZI9yxRStI5eLq5ZBQ9vY64A85W3Zwj/wTb7eR6A/qWveOUYsG > 6EtQ9F0pQ43hotiE9a/8AdvTlrwQ+lcK6W01Ngg2mh9xnZ8pcD1Zqugy7RYDoHiQ > u+yd0BxvV3SjmjA0h4qZRVUh/ct5UMPCp6gJdHJFtSsKfoRAq96BzI3g3AFGH+Xv > u0Tkjq7QbhtLPxdjdc8A61SbwRFqygrj3XsZi0ji6qar5tjW58u0PdRskb4NTUhu > lEYUETpysaj29ktGURJ3s5/G1TKauDM9G4jx9puM8Kh0LilKshRwIsJaZf+4uHeW > BBmwwFk8QMQpKffLOCie > =W7On > -----END PGP SIGNATURE----- > >

Sept. 23, 2015

Re: [PATCH 02/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX surfaces

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > wined3d_mutex_lock(); > + sub_resource = wined3d_texture_get_sub_resource(bitmap_impl->wined3d_texture, bitmap_impl->sub_resource_idx); > + wined3d_surface = wined3d_surface_from_resource(sub_resource); > hr = wined3d_device_set_cursor_properties(device->wined3d_device, > - hotspot_x, hotspot_y, bitmap_impl->wined3d_surface); > + hotspot_x, hotspot_y, wined3d_surface); > wined3d_mutex_unlock(); You may want to consider changing wined3d_device_set_cursor_properties to accept a wined3d_texture instead. Keep in mind though that this would be a bit of a side quest, as you'll have to find out if native accepts surfaces that are part of textures or just stand-alone surfaces created by CreateImageSurface. If it is the latter (which I suspect it is) then wined3d_texture alone is OK. Otherwise you need texture + idx. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAmlwAAoJEN0/YqbEcdMwGlkP/RfRVsceuPRGgVE0yJvhV26U ci6CDlrj4Lb2mFcH3IVlJKuJEOcT2TLrcx2hT3H2+0OjDBvAIJyLhzjxABaZsg0N OU4TJCvLfPiieF0npy7EBpUoe+E8a4046DRnLJsooco1Cp+Fk2LZO4B1OjMoaexl FaO9zoAO+3KlTNVwRKX65KnOsZB7PtP0soCS9Gsmvx1gwwVe42uQ8B5pSgQQzcgW UablqGdE0NnUGN2Bcj6vxPdW14FEaWC7Mp8fBl8olLO/FdlEoehzUMO7bPJNgGr2 wePB12qwmTfizcQ+Nmd5/HAGZMsn4vgfxu+kQSb0iaWxdgRtqKztlkLzAOFvGDTS x+yZ2pWTcNp41MzZI9yxRStI5eLq5ZBQ9vY64A85W3Zwj/wTb7eR6A/qWveOUYsG 6EtQ9F0pQ43hotiE9a/8AdvTlrwQ+lcK6W01Ngg2mh9xnZ8pcD1Zqugy7RYDoHiQ u+yd0BxvV3SjmjA0h4qZRVUh/ct5UMPCp6gJdHJFtSsKfoRAq96BzI3g3AFGH+Xv u0Tkjq7QbhtLPxdjdc8A61SbwRFqygrj3XsZi0ji6qar5tjW58u0PdRskb4NTUhu lEYUETpysaj29ktGURJ3s5/G1TKauDM9G4jx9puM8Kh0LilKshRwIsJaZf+4uHeW BBmwwFk8QMQpKffLOCie =W7On -----END PGP SIGNATURE-----

Sept. 23, 2015

Re: [PATCH 01/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX volumes

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > - HRESULT (__cdecl *volume_created)(struct wined3d_device_parent > *device_parent, void *container_parent, - struct > wined3d_volume *volume, void **parent, const struct > wined3d_parent_ops **parent_ops); + HRESULT (__cdecl > *volume_created)(struct wined3d_device_parent *device_parent, + > struct wined3d_texture *texture, unsigned int sub_resource_idx, + > void **parent, const struct wined3d_parent_ops **parent_ops); Is there a reason why you're passing the wined3d_texture container instead of the container parent? It doesn't matter too much because you can either do wined3d_resource_get_parent or d3d*_texture->wined3d_texture, but I think it is a needless change. It seems the patch is bigger than it needs to be. You could just add unsigned int sub_resource_idx and keep the rest in place. Through struct d3d8_texture *texture inside struct d3d8_volume you already have access to the wined3d texture. With the addition of the sub resource idx you can migrate the volume methods one by one, and in the last patch that removes access to wined3d_volume drop struct wined3d_volume *volume from the callback. For surfaces in d3d8 and d3d9 you have to make sure you're always creating a d3d8/9_texture struct for plain surfaces, but this is something you can change internally in d3d8/9. It doesn't matter too much for this patch because the volume API is pretty simple, but the next patch is pretty complicated because it changes all the stuff at once. It'll be terrible to bisect / fix if there are regressions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAmguAAoJEN0/YqbEcdMwpecP/RqlgzxhIzYQikgOQHhMBuLr 1jOtBW2aAj8qRCPebkM5JAGK+93Y+r9jrkFbJn01ZHKR1fQCfWQteCoMRUIDJ6Iz TUf5IeuKsUMucU6XJ70kh/d8MQCauOKJizvROCg6F1qILF+W6higdGHC/6FjSqqb GiXmYAtqGgOP3BGAjM4W4r8+A7yoqssLhLYmJggn8PlX6yFfdIwl/rpOdRfSC+9T ADrncsPVPpyYFRnQI+atdQuMN5M/GvioqxFS24Fuq65tUqNaXC6D8BsGy0tk6bN2 nZAWkSkrx1bSi24U7RzHbq936Z+qnUp5UH/ZkView8dp5dXiqjmOLucWd4WJ/+0I rMjIduEPuLgDraKnE4vKtn5WpPmV/ITX6If5zI9fTuFBLwyIrC06lIeaGd5VOHiO 2/U00pyIQuS9F6Ir73J0hl5CJITYhmSdT9xsz2sIBbQheZu7OYLqqfIHM0d3DGBk tC3H9X4bJQh9nDzLy4IGVr2W2vqQgKIVGxyVcYFyvA448kP7/W2Z1i+ak9CevFGg fVBrwoPtTzPIoucC9cQ1vnskTITgzSNCuy3t+HBKsbm+0+7VsDnq8CL7wrGbs8uN hSXwpCA4qLsPyK+6XCuITB8rmkGVX3/2j6Ratf2lSgdZVexQfsK/+hWQYIwXzjki otAB34aWZl2+f/socndA =6ndo -----END PGP SIGNATURE-----

Sept. 23, 2015

Re: Videos or Slides from WineConf

by Aaryaman Vasishta

Stefan is working on getting the videos up. Cheers, Aaryaman On Wed, Sep 23, 2015 at 12:30 PM, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > * On Wed, 23 Sep 2015, Austin English wrote: > > > http://wiki.winehq.org/WineConf2015 (under Agenda), > > Someone please add the names of participants under the photo. I see a > quite a few new faces this year -- it's nice to know! : ) > > TIA, > > S. > > >

Sept. 23, 2015

Re: Videos or Slides from WineConf

by Saulius Krasuckas

* On Wed, 23 Sep 2015, Austin English wrote: > http://wiki.winehq.org/WineConf2015 (under Agenda), Someone please add the names of participants under the photo. I see a quite a few new faces this year -- it's nice to know! : ) TIA, S.

Sept. 23, 2015

Re: Videos or Slides from WineConf

by Austin English

On Tue, Sep 22, 2015 at 6:52 PM, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: > Hi, are there any plans to publish videos or slides from wineconf? > > Joel http://wiki.winehq.org/WineConf2015 (under Agenda), or refer to http://wiki.winehq.org/WineConf2015?action=AttachFile Note: not all may be uploaded (yet), I just uploaded mine.. -- -Austin

Sept. 23, 2015

Re: user32/tests: Allow tracing in menu test

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > + if (winetest_debug > 1) > + trace("item #%u: fType %04x, fState %04x, wID %u, hSubMenu %p\n", > + i, mii.fType, mii.fState, mii.wID, mii.hSubMenu); Please use 4 spaces for indentation after 'if ()', not 8. Also, what's the reason of this patch? There are several other similar disabled debug traces in that file, anything special about this one? And I'd suggest to simply replace if (0) by if (1) in the personal build if you really need to see the traces. -- Dmitry.

Sept. 23, 2015

Videos or Slides from WineConf

by Joel Holdsworth

Hi, are there any plans to publish videos or slides from wineconf? Joel

Sept. 22, 2015

Re: Wine Stable/Release Changes

by Jens Reyer

On 09/22/2015 01:39 PM, Michael Stefaniuc wrote: > Hello, > > at WineConf we had a fairly uncontroversial discussion about the Wine > Stable release process. As the current process of feature based Wine > releases isn't working(*) following changes were agreed upon. > > Release Process Changes > ----------------------- > - Switch to time based releases. > > - Major releases once a year in autumn/fall. Code freeze starts around > mid/end of September. > > - Michael Stefaniuc will be the stable maintainer starting with 1.8.x. > Other people are more than welcome to help out with Wine Stable. > I'll document stuff and send out a request for help during the code > freeze. > > - The stable release will be supported in bugzilla. > > - This changes take effect immediately. You can expect Alexandre to > announce a code freeze in the next couple of weeks. > > - We will revisit this changes should the need arise, e.g. reduce the > time between two major stable releases. [...] Awesome, thank you all and especially thank you Michael! This sounds generally good and looks like fitting perfectly for Debian, which currently freezes in November/December. Greets jre

Sept. 22, 2015

Re: kernel32: Create registry keys for available COM ports

by Austin English

On Tue, Sep 22, 2015 at 3:14 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > dlls/kernel32/kernel_private.h | 3 +++ > dlls/kernel32/oldconfig.c | 42 +++++++++++++++++++++++++++++++++++++++--- > dlls/kernel32/volume.c | 2 +- > 3 files changed, 43 insertions(+), 4 deletions(-) > > diff --git a/dlls/kernel32/kernel_private.h b/dlls/kernel32/kernel_private.h > index 76611d7..9f2db22 100644 > --- a/dlls/kernel32/kernel_private.h > +++ b/dlls/kernel32/kernel_private.h > @@ -107,6 +107,9 @@ extern void LOCALE_InitRegistry(void) DECLSPEC_HIDDEN; > /* oldconfig.c */ > extern void convert_old_config(void) DECLSPEC_HIDDEN; > > +/* volume.c */ > +extern char *get_dos_device_path(LPCWSTR) DECLSPEC_HIDDEN; > + > /* returns directory handle for named objects */ > extern HANDLE get_BaseNamedObjects_handle(void) DECLSPEC_HIDDEN; > > diff --git a/dlls/kernel32/oldconfig.c b/dlls/kernel32/oldconfig.c > index 2c8bc18..b7f6b97 100644 > --- a/dlls/kernel32/oldconfig.c > +++ b/dlls/kernel32/oldconfig.c > @@ -264,8 +264,8 @@ static int SCSI_getprocentry( FILE * procfile, struct LinuxProcScsiDevice * dev > } > > > -/* create the hardware registry branch */ > -static void create_hardware_branch(void) > +/* create the scsi registry branch */ > +static void create_scsi_branch(void) > { > /* The following mostly will work on Linux, but should not cause > * problems on other systems. */ > @@ -389,6 +389,41 @@ static void create_hardware_branch(void) > } > > > +/* create SERIALCOMM branch */ > +void create_serialcomm_branch(void) > +{ > + static WCHAR comW[] = {'C','O','M','1',0}; > + UNICODE_STRING nameU; > + DWORD disp; > + HANDLE key; > + int i; > + > + /* Ensure there is a SERIALCOMM key */ > + if (create_key( 0, "Machine\\HARDWARE\\DEVICEMAP\\SERIALCOMM", &key, &disp )) return; > + > + for (i = 1; i <= 9; i++) > + { > + char *link; > + int ret; > + > + comW[3] = 0x30 + i; > + link = get_dos_device_path( comW ); > + ret = access( link, R_OK | W_OK ); > + > + RtlCreateUnicodeString( &nameU, comW ); > + if (ret) > + NtDeleteValueKey( key, &nameU ); > + else > + NtSetValueKey( key, &nameU, 0, REG_SZ, (BYTE*)comW, sizeof(comW) ); > + RtlFreeUnicodeString( &nameU ); > + > + HeapFree(GetProcessHeap(), 0, link); > + } > + > + NtClose(key); > +} > + > + > /*********************************************************************** > * convert_old_config > */ > @@ -400,5 +435,6 @@ void convert_old_config(void) > /* create some hardware keys (FIXME: should not be done here) */ > if (create_key( 0, "Machine\\HARDWARE", &key, &disp )) return; > NtClose( key ); > - if (disp != REG_OPENED_EXISTING_KEY) create_hardware_branch(); > + if (disp != REG_OPENED_EXISTING_KEY) create_scsi_branch(); > + create_serialcomm_branch(); > } > diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c > index 7a1dc11..43fbb7e 100644 > --- a/dlls/kernel32/volume.c > +++ b/dlls/kernel32/volume.c > @@ -99,7 +99,7 @@ static char *read_symlink( const char *path ) > } > > /* get the path of a dos device symlink in the $WINEPREFIX/dosdevices directory */ > -static char *get_dos_device_path( LPCWSTR name ) > +char *get_dos_device_path( LPCWSTR name ) > { > const char *config_dir = wine_get_config_dir(); > char *buffer, *dev; > -- > 1.9.1 Hi Andre, You forgot to sign off on this patch ;) -- -Austin

Sept. 22, 2015

Re: Inconsistent argument type declaration in dinput.h: WriteEffectToFile()

by Michael Stefaniuc

On 09/22/2015 09:32 PM, Elias Vanderstuyft wrote: > On Mon, Sep 21, 2015 at 11:06 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: >> On Mon, Sep 21, 2015 at 10:15:32PM +0200, Elias Vanderstuyft wrote: >>> Hi everyone, >>> >>> The docs of IDirectInputDevice8::WriteEffectToFile() declare the third >>> argument as >>> LPCDIFILEEFFECT rgDiFileEft: >>> https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_… >>> This is inconsistent with Microsoft's "dinput.h" file, they declare it as >>> LPDIFILEEFFECT (thus, no "const"): >>> ftp://sccn.ucsd.edu/pub/LSL/lsl-dependencies/external_libs/EmbarcaderoXE/sh… >>> Wine's "dinput.h" follows the same mistake as Microsoft's: >>> https://github.com/wine-mirror/wine/blob/master/include/dinput.h#L1866 >>> >>> Is there a particular reason for this? >> >> No, it was probably missed. >> >> I am sending a patch. > > Thanks, I suppose a patch to Wine? Yes. > And leave Microsoft unnotified? You can of course notify Microsoft. They might even update MSDN to reflect the header. bye michael

Sept. 22, 2015

Re: Inconsistent argument type declaration in dinput.h: WriteEffectToFile()

by Elias Vanderstuyft

On Mon, Sep 21, 2015 at 11:06 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On Mon, Sep 21, 2015 at 10:15:32PM +0200, Elias Vanderstuyft wrote: >> Hi everyone, >> >> The docs of IDirectInputDevice8::WriteEffectToFile() declare the third >> argument as >> LPCDIFILEEFFECT rgDiFileEft: >> https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_… >> This is inconsistent with Microsoft's "dinput.h" file, they declare it as >> LPDIFILEEFFECT (thus, no "const"): >> ftp://sccn.ucsd.edu/pub/LSL/lsl-dependencies/external_libs/EmbarcaderoXE/sh… >> Wine's "dinput.h" follows the same mistake as Microsoft's: >> https://github.com/wine-mirror/wine/blob/master/include/dinput.h#L1866 >> >> Is there a particular reason for this? > > No, it was probably missed. > > I am sending a patch. Thanks, I suppose a patch to Wine? And leave Microsoft unnotified? Thanks, Elias

Sept. 22, 2015

Re: msi: Set the PrimaryVolumeSpaceRequired and PrimaryVolumeSpaceRemaining properties.

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=16820 Your paranoid android. === w7u (32 bit install) === The test timed out === wvistau64 (64 bit install) === Failure running script in VM: timed out waiting for the child process

Sept. 22, 2015

Re: [2/2] wininet/tests: Fix a couple of test failures.

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=16819 Your paranoid android. === w2000pro (32 bit http) === http.c:2400: Test failed: InternetReadFile failed 12030 http.c:2401: Test failed: count was wrong === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

Sept. 22, 2015

Re: [1/2] wininet/tests: Never use a proxy for connections to localhost.

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=16818 Your paranoid android. === w7u (32 bit http) === http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w7pro64 (64 bit http) === http.c:5813: Test failed: HttpAddRequestHeadersA failed 12019 http.c:5819: Test failed: HttpQueryInfoA failed 12019 http.c:5820: Test failed: header missing === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

Sept. 22, 2015

Re: How to add the Signed-off-by field in the git patch

by Alex Henrie

I just updated http://wiki.winehq.org/SubmittingPatches with instructions on how to include the Signed-off-by line. I will update the GitWine page soon. Please feel free to improve the wiki further. -Alex

Sept. 22, 2015

Re: How to add the Signed-off-by field in the git patch

by Hin-Tak Leung

You don't need to edit git's config by hand - 'git config --global ... ' can do that for you. read the documentation for git-config, and particularly the --global option. I also have colorised diff and a few other useful thing configured. ------------------------------ On Tue, Sep 22, 2015 3:21 PM BST Aaryaman Vasishta wrote: >Hi Dimitry, > >Thanks! this will definitely help if this info is added to the wiki too. >Though it seems to be down right now. There's a discussion going on about >it on IRC right now. > >Cheers, >Aaryaman > >On Tue, Sep 22, 2015 at 4:10 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > >> Hi all, >> >> since I personally asked that question and investigated a bit the subject, >> here is some information that could be probably useful to someone else: >> >> >> http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… >> >> http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… >> >> http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… >> http://git-scm.com/docs/git-format-patch (CONFIGURATION section) >> >> Personally I've chosen to add >> [format] >> signOff = true >> to git.config file. >> >> -- >> Dmitry. >> >> >>

Sept. 22, 2015

Re: How to add the Signed-off-by field in the git patch

by Aaryaman Vasishta

Hi Dimitry, Thanks! this will definitely help if this info is added to the wiki too. Though it seems to be down right now. There's a discussion going on about it on IRC right now. Cheers, Aaryaman On Tue, Sep 22, 2015 at 4:10 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Hi all, > > since I personally asked that question and investigated a bit the subject, > here is some information that could be probably useful to someone else: > > > http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… > > http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… > > http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… > http://git-scm.com/docs/git-format-patch (CONFIGURATION section) > > Personally I've chosen to add > [format] > signOff = true > to git.config file. > > -- > Dmitry. > > >

Sept. 22, 2015

Wine Stable/Release Changes

by Michael Stefaniuc

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, at WineConf we had a fairly uncontroversial discussion about the Wine Stable release process. As the current process of feature based Wine releases isn't working(*) following changes were agreed upon. Release Process Changes - ----------------------- - - Switch to time based releases. - - Major releases once a year in autumn/fall. Code freeze starts around mid/end of September. - - Michael Stefaniuc will be the stable maintainer starting with 1.8.x. Other people are more than welcome to help out with Wine Stable. I'll document stuff and send out a request for help during the code freeze. - - The stable release will be supported in bugzilla. - - This changes take effect immediately. You can expect Alexandre to announce a code freeze in the next couple of weeks. - - We will revisit this changes should the need arise, e.g. reduce the time between two major stable releases. Discussion - ---------- The discussion was done based on slide 9 of Alexandre's keynote http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=winecon… At the start Alexandre and others noted that we do not hear from users for whom 1.6 is just working. We are getting reports only about the stuff that breaks. The discussion quickly geared to the changes accepted from above with the focus on implementation details: - - 6 months better? No, the 12-18 months stable release cadence prior to 1.8 was ok. Can be reduced later on should the need arise. - - Synchronize with (a) major distro? No, release dates can slip on both ends. Freeze should also not impact GSoC. - - Nobody else volunteered during the discussion for the stable maintainer role. For the more drastic proposal of removing the the Wine Stable version altogether, Alexandre made drafted a plan to follow a similar model to the Linux Kernel. One release for the risky stuff and every second release is for stabilization. He proposed also a two weeks "merge window" for risky stuff followed by two weeks for the fixes and the last two weeks of "freeze". This produced a loud outcry from most developers: it would be unworkable without a prior move to a git pull model to accept new features. This basically killed the proposal. (*) 1.6 released > 2 years ago and was latest updated 1.5 years ago. It doesn't compiles on a modern distribution anymore. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFWAT4O0ei8kcpE1VERAprfAKC0x+Zb6zHGv095REWGGYy+L/qsBQCgpr1+ Z9VxsMM7J1/wdpAyC8DPJaE= =zhZ8 -----END PGP SIGNATURE-----

Sept. 22, 2015

How to add the Signed-off-by field in the git patch

by Dmitry Timoshkov

Hi all, since I personally asked that question and investigated a bit the subject, here is some information that could be probably useful to someone else: http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… http://git-scm.com/docs/git-format-patch (CONFIGURATION section) Personally I've chosen to add [format] signOff = true to git.config file. -- Dmitry.

Sept. 22, 2015

Re: prelink (needed to compile wine) missing on Fedora 23

by Sebastian Lackner

On 22.09.2015 10:44, Zhenbo Li wrote: > Thanks, Sebastian > > 2015-09-22 1:55 GMT+08:00 Sebastian Lackner <sebastian(a)fds-team.de>: >> >> You might need it for some apps, especially older ones. The official Fedora >> packages fix this issue by applying a patch to use compiler features instead of >> prelink: >> >> http://pkgs.fedoraproject.org/cgit/wine.git/plain/wine-relocate-base.patch?… > > > So I have this question: Do I need to apply this patch to wine-git > before I'm working on wine? > If I don't, will I face the risk that my patch may behave differently > on other developers/users' computers and mine? > For most parts of Wine it will make no difference. You should only keep it in mind, when you want to reproduce bugs. There is a small chance that you might run into a different issue without prelink or the patch applied.

Sept. 22, 2015

Re: prelink (needed to compile wine) missing on Fedora 23

by Zhenbo Li

Thanks, Sebastian 2015-09-22 1:55 GMT+08:00 Sebastian Lackner <sebastian(a)fds-team.de>: > > You might need it for some apps, especially older ones. The official Fedora > packages fix this issue by applying a patch to use compiler features instead of > prelink: > > http://pkgs.fedoraproject.org/cgit/wine.git/plain/wine-relocate-base.patch?… So I have this question: Do I need to apply this patch to wine-git before I'm working on wine? If I don't, will I face the risk that my patch may behave differently on other developers/users' computers and mine? -- Have a nice day! Zhenbo Li

Sept. 22, 2015

Re: [PATCH] dinput: WriteEffectToFIle dieffects parameter is const

by Michael Stefaniuc

On 09/22/2015 08:08 AM, Marcus Meissner wrote: > On Mon, Sep 21, 2015 at 06:18:13PM -0500, Ken Thomases wrote: >> On Sep 21, 2015, at 5:50 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >>> >>> On 22.09.2015 0:06, Marcus Meissner wrote: >>>> Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> >>>> --- >>>> dlls/dinput/device.c | 4 ++-- >>>> dlls/dinput/device_private.h | 4 ++-- >>>> include/dinput.h | 8 ++++---- >>>> 3 files changed, 8 insertions(+), 8 deletions(-) >>>> >>> >>> PSDK header doesn't use const for that argument, I checked with Win10 SDK. Does it really make sense to diverge from it in this case? >> >> I think Marcus misunderstood Elias's earlier email about this. Elias was pointing out that, while the _docs_ claim the parameter is const, it isn't actually declared that way in Microsoft's headers but is in Wine's headers (for IDirectInputDevice8::WriteEffectToFile()). Apparently, Marcus thought he was saying it was the other way, so he "corrected" the wrong way. > > > So what should we follow... The documentation or PSDK? PSDK as we and others that want to use the Wine headers need to be able to compile Win32 code unmodified. > The const makes sense as this is a input parameter, but then "making sense" is of course optional in the Win32 api :) The PSDK even keeps clear typos / copy and paste errors. There is a struct that uses the wrong handle type for a field. Alexandre rejected my patch to fix that one even though it wouldn't break the ABI and it wouldn't be an API problem for mildly sane source code out there. bye michael

Sept. 22, 2015

Re: [PATCH] dinput: WriteEffectToFIle dieffects parameter is const

by Marcus Meissner

On Mon, Sep 21, 2015 at 06:18:13PM -0500, Ken Thomases wrote: > On Sep 21, 2015, at 5:50 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > > > > On 22.09.2015 0:06, Marcus Meissner wrote: > >> Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> > >> --- > >> dlls/dinput/device.c | 4 ++-- > >> dlls/dinput/device_private.h | 4 ++-- > >> include/dinput.h | 8 ++++---- > >> 3 files changed, 8 insertions(+), 8 deletions(-) > >> > > > > PSDK header doesn't use const for that argument, I checked with Win10 SDK. Does it really make sense to diverge from it in this case? > > I think Marcus misunderstood Elias's earlier email about this. Elias was pointing out that, while the _docs_ claim the parameter is const, it isn't actually declared that way in Microsoft's headers but is in Wine's headers (for IDirectInputDevice8::WriteEffectToFile()). Apparently, Marcus thought he was saying it was the other way, so he "corrected" the wrong way. So what should we follow... The documentation or PSDK? The const makes sense as this is a input parameter, but then "making sense" is of course optional in the Win32 api :) Ciao, Marcus

Sept. 22, 2015

Re: [PATCH] dinput: WriteEffectToFIle dieffects parameter is const

by Ken Thomases

On Sep 21, 2015, at 5:50 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > > On 22.09.2015 0:06, Marcus Meissner wrote: >> Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> >> --- >> dlls/dinput/device.c | 4 ++-- >> dlls/dinput/device_private.h | 4 ++-- >> include/dinput.h | 8 ++++---- >> 3 files changed, 8 insertions(+), 8 deletions(-) >> > > PSDK header doesn't use const for that argument, I checked with Win10 SDK. Does it really make sense to diverge from it in this case? I think Marcus misunderstood Elias's earlier email about this. Elias was pointing out that, while the _docs_ claim the parameter is const, it isn't actually declared that way in Microsoft's headers but is in Wine's headers (for IDirectInputDevice8::WriteEffectToFile()). Apparently, Marcus thought he was saying it was the other way, so he "corrected" the wrong way. -Ken

Sept. 21, 2015

Re: [PATCH] dinput: WriteEffectToFIle dieffects parameter is const

by Nikolay Sivov

On 22.09.2015 0:06, Marcus Meissner wrote: > Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/dinput/device.c | 4 ++-- > dlls/dinput/device_private.h | 4 ++-- > include/dinput.h | 8 ++++---- > 3 files changed, 8 insertions(+), 8 deletions(-) > PSDK header doesn't use const for that argument, I checked with Win10 SDK. Does it really make sense to diverge from it in this case?

Sept. 21, 2015

No release this week

by Alexandre Julliard

Hey guys, Because of WineConf, it looks like I won't be able to make a release today. And since I'll be taking some vacation next week, I plan to release 1.7.52 on Friday two weeks from now. -- Alexandre Julliard julliard(a)winehq.org

Sept. 21, 2015

Re: Inconsistent argument type declaration in dinput.h: WriteEffectToFile()

by Marcus Meissner

On Mon, Sep 21, 2015 at 10:15:32PM +0200, Elias Vanderstuyft wrote: > Hi everyone, > > The docs of IDirectInputDevice8::WriteEffectToFile() declare the third > argument as > LPCDIFILEEFFECT rgDiFileEft: > https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_… > This is inconsistent with Microsoft's "dinput.h" file, they declare it as > LPDIFILEEFFECT (thus, no "const"): > ftp://sccn.ucsd.edu/pub/LSL/lsl-dependencies/external_libs/EmbarcaderoXE/sh… > Wine's "dinput.h" follows the same mistake as Microsoft's: > https://github.com/wine-mirror/wine/blob/master/include/dinput.h#L1866 > > Is there a particular reason for this? No, it was probably missed. I am sending a patch. Ciao, Marcus

Sept. 21, 2015

Inconsistent argument type declaration in dinput.h: WriteEffectToFile()

by Elias Vanderstuyft

Hi everyone, The docs of IDirectInputDevice8::WriteEffectToFile() declare the third argument as LPCDIFILEEFFECT rgDiFileEft: https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_… This is inconsistent with Microsoft's "dinput.h" file, they declare it as LPDIFILEEFFECT (thus, no "const"): ftp://sccn.ucsd.edu/pub/LSL/lsl-dependencies/external_libs/EmbarcaderoXE/sh… Wine's "dinput.h" follows the same mistake as Microsoft's: https://github.com/wine-mirror/wine/blob/master/include/dinput.h#L1866 Is there a particular reason for this? Best regards, Elias

Sept. 21, 2015

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible

by Martin Storsjö

On Mon, 21 Sep 2015, Marvin wrote: > 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=16808 > > Your paranoid android. > > > === w2003std (32 bit string) === > Unable to set the VM system time: the "nc -q0 '10.42.42.140' '4242'" command returned 1 > > === w7u (32 bit string) === > Failure running script in VM: timed out waiting for the child process These obviously seem unrelated to the test at hand. // Martin

Sept. 21, 2015

Re: prelink (needed to compile wine) missing on Fedora 23

by Sebastian Lackner

On 20.09.2015 17:10, Zhenbo Li wrote: > Hello, > I installed Fedora 23 Alpha to my computer, and tried to compile wine today. > After running "./configure", I got this in my terminal > > configure: WARNING: prelink not found, base address of core dlls won't > be set correctly. > > The reason is that prelink has been obsoleted since Fedora 23[1] > > There is a successful build for wine on Fedora23[2], and it seems that > that package has been affected by missing prelink too.[3] > > Is this a critical problem? Should I ignore this WARNING, or try to fix it? You might need it for some apps, especially older ones. The official Fedora packages fix this issue by applying a patch to use compiler features instead of prelink: http://pkgs.fedoraproject.org/cgit/wine.git/plain/wine-relocate-base.patch?… > > Thank you > > [1]: https://admin.fedoraproject.org/pkgdb/package/prelink/ > [2]: http://koji.fedoraproject.org/koji/buildinfo?buildID=683683 > [3]: https://kojipkgs.fedoraproject.org//packages/wine/1.7.51/1.fc23/data/logs/x… >

Sept. 21, 2015

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible

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=16808 Your paranoid android. === w2003std (32 bit string) === Unable to set the VM system time: the "nc -q0 '10.42.42.140' '4242'" command returned 1 === w7u (32 bit string) === Failure running script in VM: timed out waiting for the child process

Sept. 21, 2015

Re: [PATCH 2/2] ucrtbase: Make the strtod implementation C99 compatible

by Martin Storsjö

On Mon, 31 Aug 2015, Piotr Caban wrote: > On 08/30/15 22:47, Martin Storsjo wrote: >> @@ -339,6 +341,38 @@ static double strtod_helper(const char *str, char >> **end, MSVCRT__locale_t locale >> } else if(*p == '+') >> p++; >> >> +#if _MSVCR_VER >= 140 >> + if(p[0] == '0' && tolower(p[1]) == 'x') { >> + char *e; >> + MSVCRT_long val = sign*MSVCRT_strtol(p, &e, 16); > This will not work for doubles > LONG_MAX. > > It will also not work if specified hexadecimal value has dot, e.g.: > strtod("0x1.1p+1") = 2.125 Thanks. It turned out to be pretty straightforward to integrate this into the existing base-10 parsing loop, which made sure all such cases should be handled, at least as well as the rest. // Martin

Sept. 21, 2015

Re: [1/2] [website] Add up-to-date download page for Debian

by Jens Reyer

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

Sept. 20, 2015

Re: [1/2] [website] Add up-to-date download page for Debian

by Jens Reyer

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

Sept. 20, 2015

prelink (needed to compile wine) missing on Fedora 23

by Zhenbo Li

Hello, I installed Fedora 23 Alpha to my computer, and tried to compile wine today. After running "./configure", I got this in my terminal configure: WARNING: prelink not found, base address of core dlls won't be set correctly. The reason is that prelink has been obsoleted since Fedora 23[1] There is a successful build for wine on Fedora23[2], and it seems that that package has been affected by missing prelink too.[3] Is this a critical problem? Should I ignore this WARNING, or try to fix it? Thank you [1]: https://admin.fedoraproject.org/pkgdb/package/prelink/ [2]: http://koji.fedoraproject.org/koji/buildinfo?buildID=683683 [3]: https://kojipkgs.fedoraproject.org//packages/wine/1.7.51/1.fc23/data/logs/x… -- Have a nice day! Zhenbo Li

Sept. 20, 2015

Re: psapi/tests: Don't check for exact value (try 7)

by André Hentschel

Am 20.09.2015 um 15:36 schrieb 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=16805 > > Your paranoid android. > > > === w1064 (32 bit psapi_main) === > psapi_main.c:157: Test failed: cbNeeded=136 > psapi_main.c:644: Test failed: wrong length 3 > No test summary line found > > === w1064 (64 bit psapi_main) === > psapi_main.c:644: Test failed: wrong length 3 > No test summary line found > Unrelated win10 problems, I'll address them later

Sept. 20, 2015

Re: psapi/tests: Don't check for exact value (try 7)

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=16805 Your paranoid android. === w1064 (32 bit psapi_main) === psapi_main.c:157: Test failed: cbNeeded=136 psapi_main.c:644: Test failed: wrong length 3 No test summary line found === w1064 (64 bit psapi_main) === psapi_main.c:644: Test failed: wrong length 3 No test summary line found

Sept. 20, 2015

Re: Wine test update

by Austin English

On Sep 20, 2015 3:25 PM, "Jeremy White" <jwhite(a)codeweavers.com> wrote: > > We reviewed my list of interesting test bot vm failures: > > https://www.winehq.org/~jwhite/latest.html > > and have assigned blame to most of them. A few we think we can ignore, and we've dropped 2000 from the definition of 'interesting'. For clarification, that's Windows 2000.

Sept. 20, 2015

Wine test update

by Jeremy White

We reviewed my list of interesting test bot vm failures: https://www.winehq.org/~jwhite/latest.html and have assigned blame to most of them. A few we think we can ignore, and we've dropped 2000 from the definition of 'interesting'. The following glorious people volunteered to work on one or more of these issues: Andrew, Alexandre, Aric, Francois, Huw, Stefan, Piotr, Jacek, Qian, Hans, and Sebastian, and I've emailed Bruno to ask him to look into one. Cheers, Jeremy

Sept. 20, 2015

Re: Winsock 2

by Christopher Harrington

On Sun, Sep 20, 2015, 03:16 Bruno Jesus <00cpxxx(a)gmail.com> wrote: When I studied this function I could not find any real life example about what it does, so I thought it was related to listing information from your own system only, I never thought it could be used for name resolving, that is interesting to know. Please expand the tests if possible to demonstrate this. Just for your reference, the last paragraph of the Remarks section on MSDN[1] appears to imply that it works for this purpose. I'm not positive that it does, but I'll determine that soon. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms741679(v=vs.85).…

Sept. 20, 2015

Re: Winsock 2

by Bruno Jesus

On Sun, Sep 20, 2015 at 3:44 PM, Christopher Harrington <ironiridis+winehq(a)gmail.com> wrote: > On Sun, Sep 20, 2015 at 2:17 AM Henri Verbeet <hverbeet(a)gmail.com> wrote: >> >> On 19 September 2015 at 23:53, Christopher Harrington >> <ironiridis+winehq(a)gmail.com> wrote: >> > I'm looking at trying to implement some of the Winsock 2 stubs, namely >> > WSALookupServiceBegin/Next/End. I'm probably only going to implement >> > enough >> > of it that my target binary will stop bailing out with "out of memory". >> > I >> > suspect the app is using it to resolve DNS... >> > >> > Am I stepping on anyone's toes? If not, can someone point me at the >> > right >> > place to look for where wine is currently doing DNS lookups so I can >> > reuse >> > that non-broken code? >> > >> I think we'd welcome the help. We do lookups in for example >> resolve_hostname() in dlls/winhttp, but it's probably a good idea to >> learn how getaddrinfo() works in general. > > > Sure, I just don't want to duplicate code/effort if there's already > functional and tested code living elsewhere in the tree. Writing my own from > scratch, even if I'm proficient in the API, is bound to be less > bug-resilient. Thanks for your interest in working in this. Currently we have some applications suffering from the stub implementation of these functions, most notably [1] which will not run. Many other applications will cope with the stub returns, looking for WSALookupServiceBegin in wine bugzilla will get some results. I have written some tests for this function a while ago, but never got into developing the function. So they can at least be used for some basic testing ("make test" inside dlls/ws2_32/tests will run them, source at dlls/ws2_32/tests/sock.c:8550. When I studied this function I could not find any real life example about what it does, so I thought it was related to listing information from your own system only, I never thought it could be used for name resolving, that is interesting to know. Please expand the tests if possible to demonstrate this. [1] https://bugs.winehq.org/show_bug.cgi?id=29231 Best wishes, Bruno

Sept. 20, 2015

Re: Winsock 2

by Christopher Harrington

(on-list this time, thanks Gmail) On Sun, Sep 20, 2015 at 2:17 AM Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 19 September 2015 at 23:53, Christopher Harrington > <ironiridis+winehq(a)gmail.com> wrote: > > I'm looking at trying to implement some of the Winsock 2 stubs, namely > > WSALookupServiceBegin/Next/End. I'm probably only going to implement > enough > > of it that my target binary will stop bailing out with "out of memory". I > > suspect the app is using it to resolve DNS... > > > > Am I stepping on anyone's toes? If not, can someone point me at the right > > place to look for where wine is currently doing DNS lookups so I can > reuse > > that non-broken code? > > > I think we'd welcome the help. We do lookups in for example > resolve_hostname() in dlls/winhttp, but it's probably a good idea to > learn how getaddrinfo() works in general. > Sure, I just don't want to duplicate code/effort if there's already functional and tested code living elsewhere in the tree. Writing my own from scratch, even if I'm proficient in the API, is bound to be less bug-resilient. Thank you for the pointer. -Chris

Sept. 20, 2015

Re: Winsock 2

by Henri Verbeet

On 19 September 2015 at 23:53, Christopher Harrington <ironiridis+winehq(a)gmail.com> wrote: > I'm looking at trying to implement some of the Winsock 2 stubs, namely > WSALookupServiceBegin/Next/End. I'm probably only going to implement enough > of it that my target binary will stop bailing out with "out of memory". I > suspect the app is using it to resolve DNS... > > Am I stepping on anyone's toes? If not, can someone point me at the right > place to look for where wine is currently doing DNS lookups so I can reuse > that non-broken code? > I think we'd welcome the help. We do lookups in for example resolve_hostname() in dlls/winhttp, but it's probably a good idea to learn how getaddrinfo() works in general.

Sept. 20, 2015

Re: Changes for Wine on Debian

by Kyle Auble

On 09/19/2015 12:48 PM, Michael Gilbert wrote: > On Fri, Sep 18, 2015 at 9:48 PM, Kyle Auble wrote: >> Particularly, I wonder... >> 1. Will many questions from Debian Stable users about "wine-development" >> being outdated pop up on the Wine forums or IRC? > I doubt this as a practical problem. You can always tell them to > reproduce it with a newer version, pointing them to the wiki page > about Debian's backport packages. You're right, it's definitely not a major problem; I was more interested in keeping tabs on how often it happens as a data-point. I'm just wondering if the confusion earlier this summer was a one-time thing or if it will keep recurring even as word gets out about the wine-development package. On 09/19/2015 12:48 PM, Michael Gilbert wrote: > I don't think the popcon interface can query for backports vs. stable numbers. On 09/18/2015 10:32 PM, Jens Reyer wrote: > There is no version data in popcon. We can only compare wine and > wine-development, and look both at "Installed" (including occasional > users, which are also stable's target group, but also one-time users) > and "Vote" (regular users). I thought that might be the case when I tried looking for the data. It surprised me a little though because I figure including the package version in the popcon reports wouldn't be too hard. If there's not something else preventing it (like security), that might be something I look into down the road. On 09/19/2015 12:48 PM, Michael Gilbert wrote: > The data [0] shows users favoring the stable release by a factor of > 20:1; granted this is only year one with a development package being > available that is only 4 months in Debian stable, and more than 10 > years with the stable package. > > That data also shows interest in the stable version stagnating, and > interest in the development version growing. Yeah, "wine-development" is still too young to claim anything from the data, but I noticed the trend too. What I found interesting is if you actually break apart the data for "wine" into the four different fields, there's still growth in the number of recent users (though "old" users are increasing faster); most of the stagnation in total installations comes from a massive drop in the number of "no-files" [1]. On 09/19/2015 12:48 PM, Michael Gilbert wrote: > Anyway, somewhat unexpectedly different user have different needs. > Some favor stability, and others favor bleeding edge. That is why > there are longterm, stable, mainline, next, and various other linux > kernel versions available to pick from. Why not support them all at > least in some way? Upstream really needs to take the lead on making > those decisions, otherwise distributions have no idea which to pick > from, and end up with an arbitrary snapshot. On 09/18/2015 10:32 PM, Jens Reyer wrote: > Yes of course for #1, but also for #2. There are 1046 commits between > 1.5.31 and 1.6.2, from these 687 commits between 1.5.31 (2013-05-24) and > 1.6 (2013-08-07). This is an awesome quality effort by winehq. > Of course at some point this is void for a completely outdated stable > release, but imo this is counted in years: Wine has so many use cases, > and much is working even with a years old, but mostly regression free > and thoroughly looked over version. > > I think single distributions can't do this, neither by developers > (manpower and technical knowledge), nor by users required for this. > Which distributions actually use development releases as base for their > default Wine release? E.g. kernel releases are first taken care of by > upstream. Only later the distributions take over maintainership. > > btw (just my 2 cent): I think dropping release goals would make more > frequent Wine releases, and following this their support, much easier. > Dropping a release goal doesn't mean you don't value the goal, it just > states that it wasn't ready at the release date. There is no loss in > releasing without some new feature. Debian does this by specifying the > next freeze date directly after the release, this turned out to work > much better then waiting for everything being ready. I think we actually agree for the most part and I've been using the phrase "development release" in a confused way (in the sense of a regular release from the tip of mainline, not in the sense that there hasn't been any code-freeze or focus on QA... I probably have Wine's release schedule in mind). You're both absolutely right that the release-candidate procedures should be handled upstream, plus the more regularly they happen, the better. It's interesting you both mentioned the Linux kernel too because that's the example I had in mind (along with Firefox and Chrome). They don't have alternating stable and development versions anymore, but rather use branches off of mainline more liberally. I didn't think of it at first, but you're also right that it makes a lot of sense for all those branches to be hosted upstream. At the same time, aren't the actual branches managed independently? That was the picture in my head when I said I thought downstream should have more say in deciding which release is stable. After thinking about what you both said, I can see that probably isn't the right approach, but I still feel like even if the branches happen under one roof, they should fall to independent teams. Once everyone gets back from Wineconf though, it will be interesting to see if a consensus is forming on the stable vs. development question. - Kyle [1] https://qa.debian.org/popcon-graph.php?packages=wine&show_vote=on&show_old=…

Sept. 20, 2015

Winsock 2

by Christopher Harrington

I'm looking at trying to implement some of the Winsock 2 stubs, namely WSALookupServiceBegin/Next/End. I'm probably only going to implement enough of it that my target binary will stop bailing out with "out of memory". I suspect the app is using it to resolve DNS... Am I stepping on anyone's toes? If not, can someone point me at the right place to look for where wine is currently doing DNS lookups so I can reuse that non-broken code? Thank you in advance. -Chris Harrington

Sept. 19, 2015

Re: Changes for Wine on Debian

by Michael Gilbert

On Fri, Sep 18, 2015 at 9:48 PM, Kyle Auble wrote: > Particularly, I wonder... > 1. Will many questions from Debian Stable users about "wine-development" > being outdated pop up on the Wine forums or IRC? I doubt this as a practical problem. You can always tell them to reproduce it with a newer version, pointing them to the wiki page about Debian's backport packages. > 2. Will the install ratio for Backports vs. Stable "wine-development" grow > significantly as Jessie ages (if popcon can distinguish between the two)? I don't think the popcon interface can query for backports vs. stable numbers. > 3. Ditto for "wine" vs. "wine-development". The data [0] shows users favoring the stable release by a factor of 20:1; granted this is only year one with a development package being available that is only 4 months in Debian stable, and more than 10 years with the stable package. That data also shows interest in the stable version stagnating, and interest in the development version growing. Anyway, somewhat unexpectedly different user have different needs. Some favor stability, and others favor bleeding edge. That is why there are longterm, stable, mainline, next, and various other linux kernel versions available to pick from. Why not support them all at least in some way? Upstream really needs to take the lead on making those decisions, otherwise distributions have no idea which to pick from, and end up with an arbitrary snapshot. Best wishes, Mike [0]https://qa.debian.org/popcon-graph.php?packages=wine%2Cwine-development&s…

Sept. 19, 2015

Re: Changes for Wine on Debian

by Jens Reyer

On 09/19/2015 03:48 AM, Kyle Auble wrote: > On 09/18/2015 01:34 PM, Jens Reyer wrote: >> Now, for all those wondering about the *usefulness of wine stable*: yes, >> please! > > I'm not at Wineconf, but isn't Michael S. giving a talk about exactly > this? I already mentioned my (not very weighty) opinion in another > email, but I think we should be asking two distinct questions about > wine's stable release: > 1. Is there value in having a stable release? > 2. Should it be decided on upstream and the same for everyone? > > My view is "definitely yes" for #1 but "probably not" for #2. Especially > with git and the mature infrastructure of the distros these days, it > makes more sense to me to let each distro follow their own timeline - > resync their git tree with WineHQ's, pick a dev release to fix as > stable, create a branch there, then apply their custom patches and > occasional upstream bug-fixes on top. I get the impression that's the > approach many of the other flagship FOSS projects have settled into. Yes of course for #1, but also for #2. There are 1046 commits between 1.5.31 and 1.6.2, from these 687 commits between 1.5.31 (2013-05-24) and 1.6 (2013-08-07). This is an awesome quality effort by winehq. Of course at some point this is void for a completely outdated stable release, but imo this is counted in years: Wine has so many use cases, and much is working even with a years old, but mostly regression free and thoroughly looked over version. I think single distributions can't do this, neither by developers (manpower and technical knowledge), nor by users required for this. Which distributions actually use development releases as base for their default Wine release? E.g. kernel releases are first taken care of by upstream. Only later the distributions take over maintainership. btw (just my 2 cent): I think dropping release goals would make more frequent Wine releases, and following this their support, much easier. Dropping a release goal doesn't mean you don't value the goal, it just states that it wasn't ready at the release date. There is no loss in releasing without some new feature. Debian does this by specifying the next freeze date directly after the release, this turned out to work much better then waiting for everything being ready. >> I see the need and usefulness of wine-development for many people, and >> therefore I promised to maintain them in backports at least for Debian >> Jessie (i.e. probably the next 2 years). >> But this is only an additional service for users who have a reason to >> leave the stable path of their system. The occasional user is happy to >> know that Wine exists and that it works for an awesome lot of >> applications (and will do so for the next time, because neither the >> system or wine will change frequently). I'm sure they are the vast, but >> silent, majority. > > I can see why WineHQ still recommends the dev release for most users at > this point. I did have similar concerns to yours though, when I asked in > my bug report if the "wine-development" package should be part of the > normal Debian Stable repo. I wanted to ask if both people here at WineHQ > and at Debian packaging could keep an eye out for relevant data over the > next year or so. > > Particularly, I wonder... > 1. Will many questions from Debian Stable users about "wine-development" > being outdated pop up on the Wine forums or IRC? > 2. Will the install ratio for Backports vs. Stable "wine-development" > grow significantly as Jessie ages (if popcon can distinguish between the > two)? > 3. Ditto for "wine" vs. "wine-development". > > I'd interpret any of those things as a sign that the frozen version of > "wine-development" on Stable might be redundant (and the 3rd that you're > right about most Debian users being fine with the stable release). The > Debian team could take that into account when deciding what to include > in Stretch. There is no version data in popcon. We can only compare wine and wine-development, and look both at "Installed" (including occasional users, which are also stable's target group, but also one-time users) and "Vote" (regular users). atm wine stable leads by a factor of about 20. But interpreting that number and its future changes is quite hard. Greets jre

Sept. 19, 2015

RFC - oleaut32: Cope with invalid icon data

by Bruno Jesus

While testing bug [1] I noticed that invalid data is sent to OLEPictureImpl_LoadIcon. This patch is meant to resist these kind of issues and makes the game goes on a little further until other crash. I'm sending this as RFC because I don't know then icon structure but my tests seem very straight forward from what I can guess from the function. [1] https://bugs.winehq.org/show_bug.cgi?id=21012 Thanks in advance and best regards, Bruno

Sept. 19, 2015

Re: Changes for Wine on Debian

by Kyle Auble

On 09/18/2015 01:34 PM, Jens Reyer wrote: > Thanks for bringing this up at Debian directly, Kyle. Wine and Debian > will win by being closer together and talking directly, here and there. > (I'll try to answer more promptly *here* in the future, as well as I > will help on the wiki here.) I've started working on a Debian-specific download page for WineHQ (modeled on the Ubuntu one); I should be able to submit a patch for review before the weekend's up. After that, I'll be taking a break from Debian issues for a while, but I'll still be subscribed to the mailing list. > Now, for all those wondering about the *usefulness of wine stable*: yes, > please! I'm not at Wineconf, but isn't Michael S. giving a talk about exactly this? I already mentioned my (not very weighty) opinion in another email, but I think we should be asking two distinct questions about wine's stable release: 1. Is there value in having a stable release? 2. Should it be decided on upstream and the same for everyone? My view is "definitely yes" for #1 but "probably not" for #2. Especially with git and the mature infrastructure of the distros these days, it makes more sense to me to let each distro follow their own timeline - resync their git tree with WineHQ's, pick a dev release to fix as stable, create a branch there, then apply their custom patches and occasional upstream bug-fixes on top. I get the impression that's the approach many of the other flagship FOSS projects have settled into. > I see the need and usefulness of wine-development for many people, and > therefore I promised to maintain them in backports at least for Debian > Jessie (i.e. probably the next 2 years). > But this is only an additional service for users who have a reason to > leave the stable path of their system. The occasional user is happy to > know that Wine exists and that it works for an awesome lot of > applications (and will do so for the next time, because neither the > system or wine will change frequently). I'm sure they are the vast, but > silent, majority. I can see why WineHQ still recommends the dev release for most users at this point. I did have similar concerns to yours though, when I asked in my bug report if the "wine-development" package should be part of the normal Debian Stable repo. I wanted to ask if both people here at WineHQ and at Debian packaging could keep an eye out for relevant data over the next year or so. Particularly, I wonder... 1. Will many questions from Debian Stable users about "wine-development" being outdated pop up on the Wine forums or IRC? 2. Will the install ratio for Backports vs. Stable "wine-development" grow significantly as Jessie ages (if popcon can distinguish between the two)? 3. Ditto for "wine" vs. "wine-development". I'd interpret any of those things as a sign that the frozen version of "wine-development" on Stable might be redundant (and the 3rd that you're right about most Debian users being fine with the stable release). The Debian team could take that into account when deciding what to include in Stretch. - Kyle

Sept. 19, 2015

Re: Changes for Wine on Debian

by Jens Reyer

Disclaimer: I talk about the state of Wine in Debian on a best effort basis. I am involved in packaging, but I am not the maintainer. My opinion is not authorative. On 09/18/2015 10:29 PM, Vincent Povirk wrote: >>> - wineserver is not in PATH but in an arch specific subdirectory in >>> /usr/lib (works flawlessly for plain wine, but is a pita for 3rd party >>> stuff like winetricks and PlayOnLinux). >> >> Also a pita for people who advise typing things like 'wineserver -k'? >> Are they really supposed to know to look in this directory? >> >> Why is it in an arch-specific subdirectory when wineserver is designed >> to be architecture independent (same interface, and potentially the >> same server instance, used with 32-bit and 64-bit clients)? > > Er, sorry, I missed the part where you were describing the current > state and not necessarily advocating for it. Never mind. Np :) Is this true also without WoW64? I thought not (please tell me otherwise). So on a 64-bit system we need both the 32-bit and the 64-bit server installed. So currently I can't think of a better solution, because we don't have WoW64 yet. > On Fri, Sep 18, 2015 at 2:34 PM, Jens Reyer <jre.winesim(a)gmail.com> wrote: >> - Download of gecko and mono packages is disabled. > > Doesn't keeping it (so that the wine package downloads a binary blob > not built by Debian) violate their principles? Maybe a misunderstanding (I used packages confusingly): Indeed Debian disables the download of the mono and gecko *binary blobs*. Downloading them wouldn't fit Debian's policy and definition of free software. I doubt we will change that (this would probably mean moving wine from the "main" repository to official-inofficial "contrib"). Therefore changing that at its root is "not possible". Instead Debian provides gecko packages directly. Unfortunately they aren't updated regularly enough, so atm you can only use them for wine stable. That leaves you with downloading gecko and mono manually and placing them in the correct folder. ... which is broken for gecko currently (https://bugs.debian.org/783428) Imo our TODO is to fix the latter and communicate instructions better to the user. btw: for the same "political" reasons Debian disables the download of the Khronos XML API Registry for building wine. Instead khronos-api was packaged especially for this and is now a part of Debian. Greets jre

Sept. 18, 2015

Re: Changes for Wine on Debian

by Vincent Povirk

>> - wineserver is not in PATH but in an arch specific subdirectory in >> /usr/lib (works flawlessly for plain wine, but is a pita for 3rd party >> stuff like winetricks and PlayOnLinux). > > Also a pita for people who advise typing things like 'wineserver -k'? > Are they really supposed to know to look in this directory? > > Why is it in an arch-specific subdirectory when wineserver is designed > to be architecture independent (same interface, and potentially the > same server instance, used with 32-bit and 64-bit clients)? Er, sorry, I missed the part where you were describing the current state and not necessarily advocating for it. Never mind. Although now this part seems a bit odd: On Fri, Sep 18, 2015 at 2:34 PM, Jens Reyer <jre.winesim(a)gmail.com> wrote: > - Download of gecko and mono packages is disabled. Doesn't keeping it (so that the wine package downloads a binary blob not built by Debian) violate their principles?

Sept. 18, 2015

Re: Changes for Wine on Debian

by Vincent Povirk

> - wineserver is not in PATH but in an arch specific subdirectory in > /usr/lib (works flawlessly for plain wine, but is a pita for 3rd party > stuff like winetricks and PlayOnLinux). Also a pita for people who advise typing things like 'wineserver -k'? Are they really supposed to know to look in this directory? Why is it in an arch-specific subdirectory when wineserver is designed to be architecture independent (same interface, and potentially the same server instance, used with 32-bit and 64-bit clients)?

Sept. 18, 2015

Re: Changes for Wine on Debian

by Jens Reyer

On 09/10/2015 01:48 AM, Kyle Auble wrote: > Hi everyone, > > I just wanted to update you all on the state of the Wine packages for > Debian; back in July, the difference between the "wine-development" and > "wine" packages came up, not to mention which version WineHQ's download > page should actually point to. Although it's fresher than the stable > release of Wine, the default version of the wine-development package in > Jessie is outdated by almost a year now. > > Over the past couple of months though, Jens Reyer worked with the Debian > wine packaging team on backporting an up-to-date version of > wine-development for Jessie. That Jessie-Backports package became > available right around the beginning of September so now there's a > curated way for users on Debian Stable to track the upstream development > releases. IIUC, the Backports version tracks the package in Testing so > it will still fall behind some while Testing is in a code-freeze, but > it's a good compromise with Debian's goals, plus the policy for > Backports is that they should only track Unstable for critical reasons. > > When closing out my bug report, Jens mentioned that upgrading the > wine-development packages directly from the Jessie version to > Jessie-Backports still may take some manual tweaking, though he's > working on resolving that. He also recommended that instead of having > the WineHQ download page link to... > https://packages.debian.org/stable/wine-development > we aim the link at the list of all living versions of the > wine-development package: > https://packages.debian.org/wine-development > He also suggested that if it doesn't cause problems, we keep a link to > the stable release package, just in case someone prefers it (or they're > still stuck on oldstable): > https://packages.debian.org/wine > I can probably squeeze in some time in the next few days to submit those > changes myself. Hi, I'm said person doing the backports and other stuff at Wine-Debian. So the current wine development version is now regularly updated in the backports suite for Debian stable, yay! Thanks for bringing this up at Debian directly, Kyle. Wine and Debian will win by being closer together and talking directly, here and there. (I'll try to answer more promptly *here* in the future, as well as I will help on the wiki here.) I don't worry too much about the backports being hit by the pre-release freeze. This is only the standard procedure, and I think we can convince Debian's backports admins to make an exception in about 14 months when the next freeze starts. Now, for all those wondering about the *usefulness of wine stable*: yes, please! I see the need and usefulness of wine-development for many people, and therefore I promised to maintain them in backports at least for Debian Jessie (i.e. probably the next 2 years). But this is only an additional service for users who have a reason to leave the stable path of their system. The occasional user is happy to know that Wine exists and that it works for an awesome lot of applications (and will do so for the next time, because neither the system or wine will change frequently). I'm sure they are the vast, but silent, majority. FYI, the imo *main differences of wine-development in Debian* (unfortunately they exist, but we're working on removing them if possible): - You need a suffix "-development" for the commands themselves, e.g. wine-development, winecfg-development, ... . I saw some confusion about this here at winehq, so for now: yes, these commands exist and work fine. And yes, hopefully soon we will make wine-development working also with unsuffixed command names. (https://bugs.debian.org/758291) - WoW64 is not supported, yet. Instead separate prefixes ~/.wine and ~/.wine64 are used automatically unless specified otherwise. (https://bugs.debian.org/762058) - wineserver is not in PATH but in an arch specific subdirectory in /usr/lib (works flawlessly for plain wine, but is a pita for 3rd party stuff like winetricks and PlayOnLinux). - Download of gecko and mono packages is disabled. - wine-development is currently built without capi, hal, gphoto, gstreamer, sane and v4l. Greets jre (Jens Reyer)

Sept. 18, 2015

Re: wined3d: TRACE fixes. (try 2)

by Henri Verbeet

On 16 September 2015 at 14:39, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > @@ -1243,7 +1243,7 @@ static int context_choose_pixel_format(const struct wined3d_device *device, HDC > unsigned int cfg_count = device->adapter->cfg_count; > unsigned int i; > > - TRACE("device %p, dc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > + TRACE("device %p, hdc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > device, hdc, debug_d3dformat(color_format->id), debug_d3dformat(ds_format->id), > auxBuffers, findCompatible); This isn't wrong, but I'd be more inclined to change the parameter to match the trace than the other way around. > @@ -157,8 +157,8 @@ HRESULT CDECL wined3d_palette_create(struct wined3d_device *device, DWORD flags, > struct wined3d_palette *object; > HRESULT hr; > > - TRACE("device %p, flags %#x, entries %p, palette %p.\n", > - device, flags, entries, palette); > + TRACE("device %p, flags %#x, entry_count %d, entries %p, palette %p.\n", > + device, flags, entry_count, entries, palette); Unsigned values should use %u instead of %d. > @@ -114,7 +114,7 @@ enum wined3d_event_query_result wined3d_event_query_finish(const struct wined3d_ > const struct wined3d_gl_info *gl_info; > enum wined3d_event_query_result ret; > > - TRACE("(%p)\n", query); > + TRACE("(%p, %p)\n", query, device); This isn't wrong per se either, but I'd prefer that as "query %p, device %p.\n" like the rest of wined3d. > @@ -1275,7 +1275,7 @@ static void shader_dump_decl_usage(const struct wined3d_shader_semantic *semanti > break; > > case WINED3D_DECL_USAGE_BLEND_INDICES: > - TRACE("blend"); > + TRACE("indices"); I'd either just leave that the way it is, or change it to "blendindices". In the latter case you'd have to change the one for WINED3D_DECL_USAGE_BLEND_WEIGHT to "blendweight", and the one for WINED3D_DECL_USAGE_TEXCOORD to "texcoord%u" as well. > @@ -2037,8 +2037,8 @@ static HRESULT shader_set_function(struct wined3d_shader *shader, const DWORD *b > unsigned int backend_version; > const struct wined3d_d3d_info *d3d_info = &shader->device->adapter->d3d_info; > > - TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u.\n", > - shader, byte_code, output_signature, float_const_count); > + TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u, type %#x, max_version %d.\n", > + shader, byte_code, output_signature, float_const_count, type, max_version); %d -> %u

Sept. 18, 2015

Running WineTest every day the easy way

by Francois Gouget

So this time I've done things in the right order: first publish the code and then announce it. So here's wt-daily, a script to "orchestrate all the daily WineTest runs and related tasks." Here's the 'quickstart guide': git clone https://github.com/fgouget/wt-daily.git cd wt-daily vi wt-daily.config In this file set the following environment variables: email="your email address here" tag="a-tag" desc="A description of your system for Wine developers" shutdown="suspend" Then when you know you won't be needing your computer for a while, just type ./wt-daily. This will update and rebuild Wine, run the tests and finally suspend your machine. It's that simple! If you'd rather not suspend your machine you can set shutdown to "poweroff", "reboot" or even leave it out to keep the computer on. By default wt-daily will ask for your green light before starting the tests. So you can start it while still using the computer and click 'Ok' once you take off. To have the tests run automatically (e.g. from cron), pass --auto-test on the command line or set default_options="--auto-test" in the configuration file. If you have a 64-bit system then you can also set the {tag,desc}wow32 and {tag,desc}wow64 variables to run the tests in a mixed 32/64-bit WinePrefix. If you have a Mac, set the {tag,desc}mac variables to run the tests using the Mac driver instead of (or in addition to) X11. The script should work on OS/X though I have obviously not tested it in a long time. I'ĺl be happy to get feedback on that, particularly in the form of patches. Now you can totally stop reading here. But there's a ton more that the script can do. Read on if you want to discover more. You can have the script start an application that will prevent the tests from running until you close it. I used that to run the tests on a MythTV client box. Wine would get updated and rebuilt in the background while I was watching TV and once that was done the script would run the tests and finally power off the computer. You can also take an image of a suitably configured Windows partition and have wt-daily restore that image to the partition, reboot to Windows which will automatically run WineTest (you'll find the batch script for that in the repository), then reboot back to Linux (or shutdown the computer). This functionality is used on the cw1-hd6800 and xw2-gtx560 CodeWeavers boxes to run the tests on Linux, then Windows 8.1 and then Windows 10. All automatically. The script actually runs every hour and skips the tests (and rebooting) if nothing changed since the last run. I also have this Windows image thing set up on my fg-acer64 laptop but there I interactively select which Windows image to restore, with a choice of Windows 8, 8.1 and 10 (or nothing if I don't feel like going through a reboot). You can also extend wt-daily to add non Wine tasks. For instance on my laptops it runs another script that synchronizes the Documents folder with my desktop and runs 'git fetch --all' in all my Git repositories. This way the next time I go offline everything is up to date. The repository also contains a number or scripts that you may find useful in your own automation tasks as they support not just Linux but OS/X too. wt-image Creates, checks, restores or reboots to a disk image. wt-bot Update, build and check the Wine source code, and run the tests. wt-make Seeks to automatically fully use CPU and I/O parallelism when running make. wt-ask Asks a simple Yes/No question to the user. wt-notify Displays a notification to the user. wt-power Powers off, reboots, suspends or hibernates the computer. wt-screensaver Controls the screensaver. In particular it can prevent it from triggering. wt-nice Runs the specified command with the lowest possible CPU and I/O priority. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

Sept. 18, 2015

Re: Optimizing synchronization objects

by Daniel Santos

On 09/17/2015 07:08 AM, Michael Stefaniuc wrote: > Did you look at memfd as opposed to plain share memory and how that can > simplify your memory corruption problem? > I know that Michael Müller worked on that and proof of concept code is > available, see > https://github.com/wine-compholio/wine-staging/tree/master/patches/server-S… I've gotten a bit behind and wasn't aware of create_memfd, so I've had to study up on this -- very interesting (found a nice LWN article https://lwn.net/Articles/593918) Also, I wish that each patch set in staging had a README so that I wouldn't have to analyze the whole patch set to figure out its purpose and theory of operation. This patch set is actually very exciting to me because it addresses some of the biggest problems with excessive wineserver call problems that I've seen in profiling (e.g., PeekMessage & GetForegroundWindow.). However, I still don't quite understand what memfd is buying in this case as opposed to just an mmap with MAP_ANONYMOUS. Please enlighten me if I'm missing something, but does create_memfd and sealing with SEAL_SHRINK & SEAL_GROW just prevent clients from being able to change the size of the underlying file? It looks like it's still writable and still up to the client to mmap it as read-only. I actually haven't gotten to play with the low level bits of shared memory too much yet. (any good reading material on this topic welcomed! :) Anyway, in this case it looks like we're using the TEB's Reserved5[0] to point to a global share memory region and Reserved5[1] for a thread-specific one, but they are both mmaped read-only. I know that in this thread we've discussed a lot of different design ideas, but what I'm specifically discussing in *this* (most recent) proposal is read/write memory that both wineserver and clients can perform atomic operations on and that client threads and processes can futex each other with. As such, a rogue process can corrupt it. The concept here is a.) limiting the scope of possible corruption to other processes that are already sharing objects anyway (and would very likely be susceptible to the same corruption problems on windows as well) and b.) assuring that the wineserver is able to positively identify misuse of objects in this shared memory. The basic concept for this is that each client will keep track of changes it has made to an object with a simple (32 or 64 bit) audit value -- e.g., for each time it releases a semaphore, it will add one to it, each time it completes a wait it will subtract one. The wineserver will periodically flip a bit in the shared portion of a synchronization object using an atomic fetch-and-add operation. Clients performing subsequent operations will then begin to log to an alternate buffer. The server will then request each processes' total change count for the last audit period. By adding them all together with the value of the object in the previous audit cycle, the server can verify that the memory has not been corrupted. If it has, it can simply emit an error message to the console, mark the object as "bad" and fail all subsequent and in-process operations on it (waits return WAIT_FAILED with an appropriate last error). Daniel

Sept. 17, 2015

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.

by Erich E. Hoover

On Thu, Sep 17, 2015 at 2:25 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 16 September 2015 at 19:22, Erich E. Hoover > <erich.e.hoover(a)wine-staging.com> wrote: >> So yes, this works. >> > It does something for patch 3, but I'd be very surprised if it did > anything for the first two. (Though for what it's worth, the version > of gcc I have (4.9.2) seems to put "glyph_table" in .data.rel.ro even > before making the table const, as long as the compiler can determine > it's never written to.) I already admitted that I misread the other two thinking there was a table of pointers. If you'd like I'd happily resend part 3 on its own. > But note the "WRITE" flag on .data.rel.ro. While .data.rel.ro is > slightly better than .data, it's only made read-only after processing > relocations. It's not going to do much for e.g. .so load times. If you > really wanted to put the various tables in .rodata you'd have to > replace the string pointers in GLYPHNAME with indices into a string > table. Since those tables seem to be generated that's probably > feasible, although whether it's worth the effort is a different > question. I do not, personally, have time to do that. My work is pressuring me to get a lot of things done on an incredibly short timescale, so I have very little time for Wine at the moment. All of my recent activity has actually been to get something running for work - this was just to do a quick cleanup that was suggested on IRC that I clearly didn't pay enough attention to. Best, Erich

Sept. 17, 2015

Re: Prep for Wineconf - testing

by Bruno Jesus

On Thu, Sep 17, 2015 at 2:15 AM, Jeremy White <jwhite(a)codeweavers.com> wrote: > On 09/11/2015 10:11 AM, Jeremy White wrote: >>> As for the reader brand/model the only important thing is to ensure >>> the reader is PC/SC compatible, because some may be proprietary driver >>> driven or simplified card ID to HID converters. >> >> I had Jer order 4 SCR 3310 card readers. I know first hand that they >> work with pcsclite. > > And they are now attached to the vms. Bruno, holler if you need > something configured for that to work. Right now, I don't have any > smartcards inserted. Maybe let's start simple, and add them later. (I > have a few smartcards, but not 4 identical ones :-/). Thanks for the effort. It's ok to have different cards, each card may follow different specs so we are not interested in what they do or not, just that they work in the readers so SCardConnect and SCardTransmit works.

Sept. 17, 2015

Re: Optimizing synchronization objects

by Michael Stefaniuc

On 09/17/2015 09:36 AM, Daniel Santos wrote: > On 09/16/2015 10:49 AM, Vincent Povirk wrote: >> Well, I didn't read what he said that way: >> >> On Mon, Sep 14, 2015 at 2:18 AM, Alexandre Julliard >> <julliard(a)winehq.org> wrote: >>> Using shared memory means you'll need one page per object, because you >>> can't allow a process to corrupt the state of unrelated objects. This >>> doesn't scale. >> This is true only if you share memory between multiple clients. If you >> share memory only between wineserver and individual clients, you need >> at least one page per client, but you can use the entire page (and >> most of the overhead can remain in the individual processes, ideally >> you only need 32 or 64 bits of shared memory per object). >> >> Maybe there's another objection to this approach, but I didn't see it >> in this thread. >> > Actually, this does not need to be true if you share memory between > multiple clients. Every unique combination of processes involved in > sharing objects can have it's own "process group" where those objects, > and only those objects reside. Further, to identify corruption, each > process can keep accounting on its interaction with each object which > can be used to validate that the memory has not been altered outside of > proper use of the API. For a semaphore, I think that 32 bits will be > enough to and leave plenty of room left over for various flags, like one > for "object being moved" and another for "server wants a notification." Did you look at memfd as opposed to plain share memory and how that can simplify your memory corruption problem? I know that Michael Müller worked on that and proof of concept code is available, see https://github.com/wine-compholio/wine-staging/tree/master/patches/server-S… > > If an additional process gains access to the object it can just be moved > again to the new process group. This design would allow complex waits to > occur on the server without requiring the object to be migrated. Of > course the server would never block, it will rely upon the client to > signal it in some form when a "signaling" function is performed > (ReleaseMutex, ReleaseSemaphore, WakeConditionVariable, etc.). > > What are your thoughts Alexandre? If I implement it and provide tests to > reasonably prove that memory corruption cannot affect the wineserver's > function, nor the stability of other programs that are not sharing > objects will you consider it at some point? I know that something like > this would have to sit in staging for a long time, but I just don't want > to build something that has no chance of being merged. bye michael

Sept. 17, 2015

Re: [10/10] msvcirt: Implement strstreambuf::seekoff (resend)

by Piotr Caban

Hi, On 09/17/15 11:06, Iván Matellanes wrote: > DEFINE_THISCALL_WRAPPER(strstreambuf_seekoff, 16) > streampos __thiscall strstreambuf_seekoff(strstreambuf *this, streamoff offset, ios_seek_dir dir, int mode) > { > - FIXME("(%p %d %d %d) stub\n", this, offset, dir, mode); > - return EOF; > + char *base[3]; > + > + TRACE("(%p %d %d %d)\n", this, offset, dir, mode); > + > + if (dir < 0 || dir > 2 || !(mode & (OPENMODE_in|OPENMODE_out))) > + return EOF; > + /* read buffer */ > + if (mode & OPENMODE_in) { > + base[0] = this->base.eback; > + base[1] = this->base.gptr; > + base[2] = this->base.egptr; The code will be easier to read if you use SEEKDIR_beg, SEEKDIR_cur and SEEKDIR_end instead of its values. > + if (this->base.gptr >= this->base.egptr) > + call_streambuf_underflow(&this->base); According to my testing call_streambuf_underflow should be called always, even so default implementation will just return in this case. I was not really checking it but it looks wrong that you store base table values before underflow is called. Patches 1-9 looks good for me. Thanks, Piotr

Sept. 17, 2015

Re: dxgi: upgrade Direct3D 10 WARN to a FIXME

by Henri Verbeet

On 17 September 2015 at 04:21, Austin English <austinenglish(a)gmail.com> wrote: > I considered that, but all current uses of winediag are ERR that are > within the user's control. I didn't want to make it an ERR, so a FIXME > (which does eventually need to be fixed) felt more appropriate to me. > I don't feel strongly at all about that though, so I'll resend. > I don't think we care that much about ERR vs. FIXME for winediag. Note that this isn't necessarily something we or anyone else can fix. The wined3d core context work will make d3d10+ work on Mesa and MacOS for some classes of cards, but there's also plenty of hardware that's simply incapable of shader model 4. In that regard this isn't all that different from the situation with hardware/drivers that can't do shader model 3.

Sept. 17, 2015

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.

by Henri Verbeet

On 16 September 2015 at 19:22, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > So yes, this works. > It does something for patch 3, but I'd be very surprised if it did anything for the first two. (Though for what it's worth, the version of gcc I have (4.9.2) seems to put "glyph_table" in .data.rel.ro even before making the table const, as long as the compiler can determine it's never written to.) But note the "WRITE" flag on .data.rel.ro. While .data.rel.ro is slightly better than .data, it's only made read-only after processing relocations. It's not going to do much for e.g. .so load times. If you really wanted to put the various tables in .rodata you'd have to replace the string pointers in GLYPHNAME with indices into a string table. Since those tables seem to be generated that's probably feasible, although whether it's worth the effort is a different question.

Sept. 17, 2015

RE: [PATCH 1/2] reg: simplify root key search

by Michel Zou

Hi, Jonathan clearly mentionned he isn't interested in wine anymore though and did not respond to Alexandre. Cheers > Subject: Re: [PATCH 1/2] reg: simplify root key search > To: xantares09(a)hotmail.com; wine-devel(a)winehq.org > From: stefandoesinger(a)gmail.com > Date: Tue, 15 Sep 2015 11:38:21 +0200 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > Those patches look OK to me, and I've informed Alexandre on IRC about > that. My guess is that he'd prefer if the original author (Jonathan) > sent the code. I can't give any guarantees about that though, I can't > look into Alexandre's mind. > > Cheers, > Stefan > > Am 2015-09-14 um 15:18 schrieb Michel Zou: > > Hi, > > > > Are those patches still ok ? I did not see a reply on wine-devel, > > did I miss something ? > > > > M > > > >> Subject: Re: [PATCH 1/2] reg: simplify root key search To: > >> wine-devel(a)winehq.org CC: xantares09(a)hotmail.com From: > >> stefandoesinger(a)gmail.com Date: Fri, 4 Sep 2015 12:25:57 +0200 > >> > > Hi, > > > > Thanks, this time the patches apply OK for me. I've told Alexandre > >> that the patches look OK to me, let's see what he says. > > > > Cheers, Stefan > > > > Am 2015-09-03 um 21:51 schrieb Michel Zou: > >> Split patch from Jonathan Vollebregt: > > > >> https://github.com/jnvsor/wine/commit/ea0e2fc70db6ce4904655ea4a27ee34531d96… > >> > >> > - --- > >> programs/reg/reg.c | 85 > >> +++++++++++++++++++++++++++--------------------------- 1 file > >> changed, 43 insertions(+), 42 deletions(-) > > > >> diff --git a/programs/reg/reg.c b/programs/reg/reg.c index > >> 4ec25bc..0f28b63 100644 --- a/programs/reg/reg.c +++ > >> b/programs/reg/reg.c @@ -22,6 +22,32 @@ > > > >> #define ARRAY_SIZE(A) (sizeof(A)/sizeof(*A)) > > > >> +static const WCHAR short_hklm[] = {'H','K','L','M',0}; +static > >> const WCHAR short_hkcu[] = {'H','K','C','U',0}; +static const > >> WCHAR short_hkcr[] = {'H','K','C','R',0}; +static const WCHAR > >> short_hku[] = {'H','K','U',0}; +static const WCHAR short_hkcc[] = > >> {'H','K','C','C',0}; +static const WCHAR long_hklm[] = > >> {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N','E',0}; > >> > >> > +static const WCHAR long_hkcu[] = > >> {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0}; > >> > >> > +static const WCHAR long_hkcr[] = > >> {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > >> > >> > +static const WCHAR long_hku[] = > >> {'H','K','E','Y','_','U','S','E','R','S',0}; +static const WCHAR > >> long_hkcc[] = > >> {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F','I','G',0}; > >> > >> > + > >> +static const struct +{ + HKEY key; + const WCHAR *short_name; + > >> const WCHAR *long_name; +} +root_rels[] = +{ + > >> {HKEY_LOCAL_MACHINE, short_hklm, long_hklm}, + > >> {HKEY_CURRENT_USER, short_hkcu, long_hkcu}, + {HKEY_CLASSES_ROOT, > >> short_hkcr, long_hkcr}, + {HKEY_USERS, short_hku, long_hku}, + > >> {HKEY_CURRENT_CONFIG, short_hkcc, long_hkcc}, +}; + static const > >> WCHAR type_none[] = {'R','E','G','_','N','O','N','E',0}; static > >> const WCHAR type_sz[] = {'R','E','G','_','S','Z',0}; static const > >> WCHAR type_expand_sz[] = > >> {'R','E','G','_','E','X','P','A','N','D','_','S','Z',0}; @@ > >> -95,51 +121,26 @@ static int reg_message(int msg) return > >> reg_printfW(formatW, msg_buffer); } > > > >> -static int reg_StrCmpNIW(LPCWSTR str, LPCWSTR comp, int len) > >> +static inline BOOL path_rootname_cmp(const WCHAR *input_path, > >> const WCHAR *rootkey_name) { - int i; + DWORD length = > >> strlenW(rootkey_name); > > > >> - for (i = 0; i < len; i++) - { - if (!str[i]) - { - len = i + > >> 1; - break; - } - } - - return CompareStringW(CP_ACP, > >> NORM_IGNORECASE, str, len, comp, len) - CSTR_EQUAL; + return > >> (!strncmpiW(input_path, rootkey_name, length) && + > >> (input_path[length] == 0 || input_path[length] == '\\')); } > > > >> -static HKEY get_rootkey(LPWSTR key) +static HKEY > >> path_get_rootkey(const WCHAR *path) { - static const WCHAR > >> szHKLM[] = {'H','K','L','M',0}; - static const WCHAR > >> szHKEY_LOCAL_MACHINE[] = > >> {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N','E',0}; > >> > >> > - - static const WCHAR szHKCU[] = {'H','K','C','U',0}; > >> - static const WCHAR szHKEY_CURRENT_USER[] = > >> {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0}; > >> > >> > - - static const WCHAR szHKCR[] = {'H','K','C','R',0}; > >> - static const WCHAR szHKEY_CLASSES_ROOT[] = > >> {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > >> > >> > - - static const WCHAR szHKU[] = {'H','K','U',0}; > >> - static const WCHAR szHKEY_USERS[] = > >> {'H','K','E','Y','_','U','S','E','R','S',0}; - static const WCHAR > >> szHKCC[] = {'H','K','C','C',0}; - static const WCHAR > >> szHKEY_CURRENT_CONFIG[] = > >> {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F','I','G',0}; > >> > >> > - - > >> - if (!reg_StrCmpNIW(key, szHKLM, 4) || - !reg_StrCmpNIW(key, > >> szHKEY_LOCAL_MACHINE, 18)) - return HKEY_LOCAL_MACHINE; - else if > >> (!reg_StrCmpNIW(key, szHKCU, 4) || - !reg_StrCmpNIW(key, > >> szHKEY_CURRENT_USER, 17)) - return HKEY_CURRENT_USER; - else if > >> (!reg_StrCmpNIW(key, szHKCR, 4) || - !reg_StrCmpNIW(key, > >> szHKEY_CLASSES_ROOT, 17)) - return HKEY_CLASSES_ROOT; - else if > >> (!reg_StrCmpNIW(key, szHKU, 3) || - !reg_StrCmpNIW(key, > >> szHKEY_USERS, 10)) - return HKEY_USERS; - else if > >> (!reg_StrCmpNIW(key, szHKCC, 4) || - !reg_StrCmpNIW(key, > >> szHKEY_CURRENT_CONFIG, 19)) - return HKEY_CURRENT_CONFIG; - else > >> return NULL; + DWORD i; + + for (i = 0; i < > >> ARRAY_SIZE(root_rels); i++) + { + if (path_rootname_cmp(path, > >> root_rels[i].short_name) || + path_rootname_cmp(path, > >> root_rels[i].long_name)) + return root_rels[i].key; + } + + > >> return NULL; } > > > >> static DWORD wchar_get_type(const WCHAR *type_name) @@ -237,7 > >> +238,7 @@ static int reg_add(WCHAR *key_name, WCHAR *value_name, > >> BOOL value_empty, } p++; > > > >> - root = get_rootkey(key_name); + root = > >> path_get_rootkey(key_name); if (!root) { > >> reg_message(STRING_INVALID_KEY); @@ -307,7 +308,7 @@ static int > >> reg_delete(WCHAR *key_name, WCHAR *value_name, BOOL value_empty, > >> } p++; > > > >> - root = get_rootkey(key_name); + root = > >> path_get_rootkey(key_name); if (!root) { > >> reg_message(STRING_INVALID_KEY); > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJV9+cNAAoJEN0/YqbEcdMwaSEP/0DplIaF0ppoxF8ILAoGiZv/ > vRuinCBw3i/QwQwy7SNtrlm+Utj5o/g1OIMkedPBbgVvRTPKGfwahbw9rykr4DnD > akaQHBfjvxVLT4XxKwoi+uGDyKEfkrEgSMq8Nc0+GB5MjJi4jHCgA1LAMp9r5J7t > OSRbbPKprQUALRT4LzKCah/yXXMKz8qBjQ4SDldAbxEm8UiEpJJe1NL2WfIJAsTT > tasBTT+8gs2aBJsO4LARrNRpAXojHpzvOAihDiCr782t3ZsPUg8gVr4d9Wp7xx+c > 9X/xpbygEZQ3Icwa8/7kuClHvU8UXhJBcgt3FyPPux/lMgiRSlDM/uUEthDYOzB0 > xxyhx9tOW5led+40IfBlp94d6E9HKmaOzcbbCU8y+bv20eN5lMGNH9EH3QKZv8R6 > AniBoPp+AVokFuvmPPC7DKxqHrYJR2+TRm2iIPIdfxvDbo5/O0jfh5zpOvlk64dK > hecpYVyZNTwDdCZPkkts6Y0PfOTB+rC5sR1Hx75nO3TWXKDtVQawFPdqMrnfJdCP > TH6wUXXlas9HI5/KyzyWU9i6IcDnzhEVpUbmVLtgpfCGLU0lXUBmK6qa7mboRxD2 > DpMSbwsEU/Dwc0YKXM1B2F5dmkgsjtQ7pdkEjwLvn2pKn3QBKkLEjcarNWWXPptO > MENLGfZu3FJOFXu0CwKH > =MV7q > -----END PGP SIGNATURE-----

Sept. 17, 2015

Re: Optimizing synchronization objects

by Daniel Santos

On 09/16/2015 10:49 AM, Vincent Povirk wrote: > Well, I didn't read what he said that way: > > On Mon, Sep 14, 2015 at 2:18 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Using shared memory means you'll need one page per object, because you >> can't allow a process to corrupt the state of unrelated objects. This >> doesn't scale. > This is true only if you share memory between multiple clients. If you > share memory only between wineserver and individual clients, you need > at least one page per client, but you can use the entire page (and > most of the overhead can remain in the individual processes, ideally > you only need 32 or 64 bits of shared memory per object). > > Maybe there's another objection to this approach, but I didn't see it > in this thread. > Actually, this does not need to be true if you share memory between multiple clients. Every unique combination of processes involved in sharing objects can have it's own "process group" where those objects, and only those objects reside. Further, to identify corruption, each process can keep accounting on its interaction with each object which can be used to validate that the memory has not been altered outside of proper use of the API. For a semaphore, I think that 32 bits will be enough to and leave plenty of room left over for various flags, like one for "object being moved" and another for "server wants a notification." If an additional process gains access to the object it can just be moved again to the new process group. This design would allow complex waits to occur on the server without requiring the object to be migrated. Of course the server would never block, it will rely upon the client to signal it in some form when a "signaling" function is performed (ReleaseMutex, ReleaseSemaphore, WakeConditionVariable, etc.). What are your thoughts Alexandre? If I implement it and provide tests to reasonably prove that memory corruption cannot affect the wineserver's function, nor the stability of other programs that are not sharing objects will you consider it at some point? I know that something like this would have to sit in staging for a long time, but I just don't want to build something that has no chance of being merged. Thanks, Daniel

Sept. 17, 2015

Re: dxgi: upgrade Direct3D 10 WARN to a FIXME

by Austin English

On Wed, Sep 16, 2015 at 6:58 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 15 September 2015 at 21:36, Austin English <austinenglish(a)gmail.com> wrote: >> For https://bugs.winehq.org/show_bug.cgi?id=39277 >> >> Side note: I'm pretty sure I've seen this or a similar issue on my >> Intel/Nvidia desktop with Dragon Age 2, but didn't investigate it >> further at the time, so I'd really like to see this committed :). >> > This should probably go to winediag then. I considered that, but all current uses of winediag are ERR that are within the user's control. I didn't want to make it an ERR, so a FIXME (which does eventually need to be fixed) felt more appropriate to me. I don't feel strongly at all about that though, so I'll resend. Thanks for reviewing. -- -Austin

Sept. 17, 2015

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2)

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=16776 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

Sept. 16, 2015

Re: rsaenh/tests: Adjust length value to pass on Win 10

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=16775 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

Sept. 16, 2015

Re: Prep for Wineconf - testing

by Jeremy White

On 09/11/2015 10:11 AM, Jeremy White wrote: >> As for the reader brand/model the only important thing is to ensure >> the reader is PC/SC compatible, because some may be proprietary driver >> driven or simplified card ID to HID converters. > > I had Jer order 4 SCR 3310 card readers. I know first hand that they > work with pcsclite. And they are now attached to the vms. Bruno, holler if you need something configured for that to work. Right now, I don't have any smartcards inserted. Maybe let's start simple, and add them later. (I have a few smartcards, but not 4 identical ones :-/). Cheers, Jeremy

Sept. 16, 2015

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.

by Erich E. Hoover

On Wed, Sep 16, 2015 at 10:42 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 16 September 2015 at 18:33, Erich E. Hoover > <erich.e.hoover(a)wine-staging.com> wrote: >> Sorry, I've been incredibly busy and wasn't paying close enough >> attention to the fact that those tables did not contain pointers. >> Patch 3 still applies. >> > They do, and that's what stops the compiler from putting them in > .rodata. It's good to make the table in patch 3 const, but it won't > really affect where it's placed. Either way, if you send this kind of > patch you should verify it works. Relevant section headers: ehoover(a)lappy:/usr/local/lib/wine$ readelf --section-details wineps.drv.so ... [19] .data.rel.ro PROGBITS 000562c0 0552c0 024c20 00 0 0 32 [00000003]: WRITE, ALLOC ... [23] .data PROGBITS 0007b0e0 07a0e0 007f08 00 0 0 32 [00000003]: WRITE, ALLOC Before: ehoover(a)lappy:/usr/local/lib/wine$ readelf -s wineps.drv.so | grep -e glyph_table -e Num Num: Value Size Type Bind Vis Ndx Name 214: 00082f00 1032 OBJECT LOCAL DEFAULT 23 glyph_table.17436 After: ehoover(a)lappy:/usr/local/lib/wine$ readelf -s wineps.drv.so | grep -e glyph_table -e Num Num: Value Size Type Bind Vis Ndx Name 214: 0007a8c0 1032 OBJECT LOCAL DEFAULT 19 glyph_table.17436 So yes, this works. Best, Erich

Sept. 16, 2015

The fg-xxx VMs now accessible on demand

by Francois Gouget

So as you may know I run WineTest in a variety of Windows configurations daily (28). The results can be seen on test.winehq.org but the problem is investigating the test failures because most of these configurations cannot be found on the Wine TestBot. I have three options to work around this: * As I mentionned before (1), if you're interested in a specific configuration I may be able to temporarily switch a WineTestBot VM to that configuration. * Another option is to send me an executable to run in the VM and I'll send back the results. * And the new option is that I can now give you VNC access to the VM. Access is open to any Wine developer (i.e. you got a patch accepted in Wine). To get access to the VM contact me on IRC or send me an email and give me the tag of the VM configuration you're interested in (e.g. fg-winxp-lusr). Then I'll start up the VM in the right configuration and send you the address to use to connect to the VM. Of course if I'm asleep or out you may have to wait a bit to get access. Also my uplink is not very fast so expect slow refreshes and some lag. But in the short test I've done it seems to be usable (at least to someone who's used to transatlantic VNC links with an elastic mouse pointer). And for reference here is a list of the available VM configurations. We may not care about some of them, for instance those running the earlier service pack revisions. Let me know if that's the case. Windows 2000 ------------ The French Windows 2000 Professional SP4 installed from an official Microsoft CD. Unless otherwise noted the tests are run in an administrator account. fg-win2000-4sp IE 5.00 SP2 fg-win2000-ie55 = 4sp + IE 5.5 SP2, MSXML3 fg-win2000-ie6 = ie55 + IE 6.0 SP1 fg-win2000-up1 = ie6 + all updates up to 2011/03/21 fg-win2000-uplast = up1 + DirectX 9.0c, WMP 9, .Net 1.1 & 2.0 fg-win2000-rusr = uplast but in a 'Restricted User' account fg-win2000-susr = uplast but in a 'Power User' account Windows XP ---------- I created this VM from the Compaq Windows XP partition of my (former) computer. So this started with a number of extra non-Microsoft applications (blasts from the past: Netscape 7, RealOne Player, etc.). On the one hand this is more representative of what Windows users normally have and on the other the configuration is not as 'straight out of the box' as the other VMs. That may not matter though. fg-winxp-1sp XP SP 1, IE 6.0 SP1, DirectX 8.1 fg-winxp-2sp = 1sp + XP SP2, IE 6.0, DirectX 9.0c, .Net 1.0 SP3 fg-winxp-2spie7 = 2sp + IE 7.0, WMP 10, .Net 1.1 fg-winxp-3sp = 2spie7 + XP SP3, WMP 11, .Net 2.0 SP2 & 3.0 SP2 & 3.5 SP1 fg-winxp-3spie8 = 3sp + IE 8 fg-winxp-last = 3spie8 + all updates up to 2011/09/08 fg-winxp-lusr = last but in a 'Limited User' account Windows 7 --------- Installed from an official English Windows 7 Ultimate CD. Unless otherwise noted the tests are run in an administrator account with Elevated Privileges. fg-win7u64-0sp Base install + French language pack (but still configured for English) fg-win7u64-1sp = 0sp + SP1 fg-win7u64-1spie9(64) = 1sp + IE 9.0, all language packs fg-win7u64-1spie9adm = 1spie9 but no 'Elevated Privileges' fg-win7u64-1spie9usr = 1spie9 but in a 'Standard user' account fg-win7u64-1spie9-ar = 1spie9 but in an Arabic locale fg-win7u64-1spie9-de = 1spie9 but in a German locale fg-win7u64-1spie9-es = 1spie9 but in a Spanish locale fg-win7u64-1spie9-fr = 1spie9 but in a French locale fg-win7u64-1spie9-he = 1spie9 but in a Hebrew locale fg-win7u64-1spie9-ja = 1spie9 but in a Japanese locale fg-win7u64-1spie9-ko = 1spie9 but in a Korean locale fg-win7u64-1spie9-mx = 1spie9 but in a mixed locale (1) https://www.winehq.org/pipermail/wine-devel/2015-September/109252.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

Sept. 16, 2015

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.

by Henri Verbeet

On 16 September 2015 at 18:33, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > Sorry, I've been incredibly busy and wasn't paying close enough > attention to the fact that those tables did not contain pointers. > Patch 3 still applies. > They do, and that's what stops the compiler from putting them in .rodata. It's good to make the table in patch 3 const, but it won't really affect where it's placed. Either way, if you send this kind of patch you should verify it works.

Sept. 16, 2015

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.

by Erich E. Hoover

On Wed, Sep 16, 2015 at 3:39 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 16 September 2015 at 00:02, Erich E. Hoover > <erich.e.hoover(a)wine-staging.com> wrote: >> This patch series fixes several places where glyph table values are >> not const, preventing the compiler from placing the table in read-only >> memory. >> > Did you verify this does what you think it does? I suspect you don't > really understand const and relocations. Sorry, I've been incredibly busy and wasn't paying close enough attention to the fact that those tables did not contain pointers. Patch 3 still applies. Best, Erich

Sept. 16, 2015

Re: Optimizing synchronization objects

by Vincent Povirk

> Well, Alexandre doesn't like that approach. I still think that it's doable > to manage such a thing and still have the wineserver know when something > isn't right and respond accordingly and I would still love to be able to > convince Alexandre of that! :) Well, I didn't read what he said that way: On Mon, Sep 14, 2015 at 2:18 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Using shared memory means you'll need one page per object, because you > can't allow a process to corrupt the state of unrelated objects. This > doesn't scale. This is true only if you share memory between multiple clients. If you share memory only between wineserver and individual clients, you need at least one page per client, but you can use the entire page (and most of the overhead can remain in the individual processes, ideally you only need 32 or 64 bits of shared memory per object). Maybe there's another objection to this approach, but I didn't see it in this thread.

Sept. 16, 2015

Re: [PATCH 1/4] xaudio2: Implement IXAudio2SourceVoice frequency functions

by Andrew Eikum

On Tue, Sep 15, 2015 at 07:06:11PM -0700, Chris Robinson wrote: > This doesn't strike me as correct. Assuming the SampleRate or > FrequencyRatio can be altered in real-time, this will break the > OpenAL buffer queue which needs to have the same sample rate on each > buffer. SetFrequencyRatio looks like it'd map directly to the AL > source's pitch property, while SetSourceSampleRate may be a bit > trickier depending on when it's allowed to be called (it'd require > stopping the source and clearing the queue, then rebuffering and > requeueing the buffers to start where it left off). > Thanks again for the review! It's nice having an AL expert review my usage; I didn't know all queued AL buffers had to have the same sample rate. I'll look into using the pitch property, and re-queueing buffers shouldn't be too hard, I think. > Also, I notice the OperationSet parameter isn't used. What is that for? It's used for syncronizing changes to different objects. Queue up several changes with the same OperationSet, then execute all the changes at the same time with IXAudio2::CommitChanges. I haven't implemented that yet, and I don't see it used very often in my testing programs. We'll want it eventually, but it's not a priority. Andrew

Sept. 16, 2015

Re: dxgi: upgrade Direct3D 10 WARN to a FIXME

by Henri Verbeet

On 15 September 2015 at 21:36, Austin English <austinenglish(a)gmail.com> wrote: > For https://bugs.winehq.org/show_bug.cgi?id=39277 > > Side note: I'm pretty sure I've seen this or a similar issue on my > Intel/Nvidia desktop with Dragon Age 2, but didn't investigate it > further at the time, so I'd really like to see this committed :). > This should probably go to winediag then.

Sept. 16, 2015

Re: RFC: Hybrid (wineserver / process-local) native semaphores

by Stefan Dösinger

> There was still a lot of graphic artifacts in game play (I have an nvidia > card, so I always suspect their drivers). Did you actually enable the multithreaded command stream (HKCU/Software/Wine/Direct3D/CSMT=enabled? That's necessary to get useful performance in these games and correct graphics. (the other alternative is StrictDrawOrdering = enabled, but that will make performance even worse)

Sept. 16, 2015

Re: [PATCH 1/3] oledb32: Add DataConvert support of DBTYPE_VARIANT(NULL) to DBTYPE_DBDATE

by Alistair Leslie-Hughes

On 15/09/2015 9:51 PM, Nikolay Sivov wrote: > If it acts the same for all source variant types it looks like it'd be > better to test them all and have this case handled once. > > > No, they don't behave the same, BSTR is one example that is different, it would be possible to make a generic function for the variant type. Best Regards Alistair Leslie-Hughes

Sept. 16, 2015

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.

by Henri Verbeet

On 16 September 2015 at 00:02, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > This patch series fixes several places where glyph table values are > not const, preventing the compiler from placing the table in read-only > memory. > Did you verify this does what you think it does? I suspect you don't really understand const and relocations.

Sept. 16, 2015

Re: [3/3] Add period to status bar, dialog box messages (try 2)

by Florian Pelz

On 09/16/2015 09:22 AM, Florian Pelz wrote: > On 09/16/2015 08:59 AM, Nikolay Sivov wrote: >> On 15.09.2015 11:28, Florian Pelz wrote: >>> STRINGTABLE >>> { >>> - IDS_STATUS_DONE "Done" >>> + IDS_STATUS_DONE "Done." >>> IDS_STATUS_DOWNLOADINGFROM "Downloading from %s..." >>> } >> >> I don't think it's better really to have punctuation in status bars. >> Probably messages can live without it, unless they consist of multiple >> sentences, then last one needs termination too. > > I think it's better style to have a period at the end, and Windows does > it. Wine has one such status bar message with two sentences, only the > first with a period (oleview.rc:110, "Quit the application. Prompts to > save changes"). It would look inconsistent if that were the only message > to have a period at the end. But of course, messages can live without it. > To follow up on this, why should the patch be rejected? Possible reasons: - You believe that the changes to the translations should not be done by someone who does not know the language. Because changes to the translations are required to not break the translations (especially those that are unmaintained), it may be preferrable not to change the punctuation. I don't think so however because these cases become clear from other translations. I know enough about Japanese and Chinese to use "circle periods" there. I don't know any Thai, but apparently they don't use periods. I can leave Thai unchanged and fuzzy if you want. Other languages without "Western" punctuation (like Hindi) don't have translations for the affected strings anyway. - The patch is too much to review. It really is quite big, but there is not a lot of potential for errors, especially not for grave errors.

Sept. 16, 2015

Re: [3/3] Add period to status bar, dialog box messages (try 2)

by Florian Pelz

On 09/16/2015 08:59 AM, Nikolay Sivov wrote: > On 15.09.2015 11:28, Florian Pelz wrote: >> STRINGTABLE >> { >> - IDS_STATUS_DONE "Done" >> + IDS_STATUS_DONE "Done." >> IDS_STATUS_DOWNLOADINGFROM "Downloading from %s..." >> } > > I don't think it's better really to have punctuation in status bars. > Probably messages can live without it, unless they consist of multiple > sentences, then last one needs termination too. I think it's better style to have a period at the end, and Windows does it. Wine has one such status bar message with two sentences, only the first with a period (oleview.rc:110, "Quit the application. Prompts to save changes"). It would look inconsistent if that were the only message to have a period at the end. But of course, messages can live without it.

Sept. 16, 2015

Re: RFC: Hybrid (wineserver / process-local) native semaphores

by Daniel Santos

On 09/10/2015 04:21 AM, Stefan Dösinger wrote: > Hi, > > I have a few games that appear to be slowed down by heavy wineserver use with my CSMT patchset. I'll give your patches a try to see how they work. > > The games I suspect being affected by wineserver calls are various Call of Duty versions, Guild Wars 2 and World in Conflict. > > Cheers, > Stefan > by the way, I wanted to do a little profiling and I ran the demo CoD4 against the head (from Sept 10th) with the csmt patches. It crashed a few times, but sometimes it didn't. I put my server call logging / debug-toggle patch in and this is a sample from starting the game until the level is finished loading (minus things called less often) 3171 enum_key 5512 send_hardware_message 5682 get_window_children_from_point 5709 accept_hardware_message 8657 read_process_memory 8712 open_key 9441 close_handle 10296 get_key_value 86708 get_thread_input 202405 get_message 245653 set_cursor 553083 event_op 640397 release_mutex 1468300 select And this is a sample of several minutes of game play (I died a lot) 2457 get_window_property 7551 get_key_state 11958 get_window_children_from_point 17232 accept_hardware_message 19087 send_hardware_message 19780 get_thread_input 32922 set_cursor 41224 get_message 638672 event_op 2282578 release_mutex 3246029 select There was still a lot of graphic artifacts in game play (I have an nvidia card, so I always suspect their drivers). Daniel

Sept. 16, 2015

Re: [3/3] Add period to status bar, dialog box messages (try 2)

by Nikolay Sivov

On 15.09.2015 11:28, Florian Pelz wrote: > STRINGTABLE > { > - IDS_STATUS_DONE "Done" > + IDS_STATUS_DONE "Done." > IDS_STATUS_DOWNLOADINGFROM "Downloading from %s..." > } I don't think it's better really to have punctuation in status bars. Probably messages can live without it, unless they consist of multiple sentences, then last one needs termination too.

Sept. 16, 2015

Re: [PATCH 1/2] user32: Implement semi-stub for FlashWindowEx. (resend)

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=16750 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0003012C message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

Sept. 16, 2015

Re: Optimizing synchronization objects

by Daniel Santos

On 09/15/2015 08:26 PM, Vincent Povirk wrote: >> The part I'm not sure about yet is how we notify the first process that >> their object is now shared. My most sane thought for doing this (I have >> plenty of others :) is adding a more generic mechanism to tell the client "I >> have a message for you", but both SIGUSR1 and 2 are both being used. The >> handler for SIGUSR1 could be modified so that it first asks the server what >> the message is, which may be a "suspend thread" or "migrate object to >> server." So before proceeding, I would like to know your preference on how >> this should be handled. > FWIW, in our discussion on #winehackers, I was assuming you'd do the > equivalent of InterlockedExchange in shared memory (between wineserver > and the client) that contains the object state. Well, Alexandre doesn't like that approach. I still think that it's doable to manage such a thing and still have the wineserver know when something isn't right and respond accordingly and I would still love to be able to convince Alexandre of that! :) > The client would > notice as soon as it tried to do anything with the object that the > object was moved to the server, and the server would know the previous > state from the result of InterlockedExchange. (This assumes every > valid object state, including a state indicating that it's in the > server, can fit in 64 bits.) I think that the idea Alexandre proposed is that the object will not use shared memory, so the "moving to the server" scenario occurs when a complex WaitForMultipleObjects (i.e., with mixed object types) is requested or another process gains access to the object. > I'm not sure it's a good idea for the wineserver to have to wait on > code in a windows process (which, if the process is really hosed, > might never respond) before it can reply to a DuplicateHandle request. Well, the wineserver can't actually block, but somewhere we have to cause the calling thread of the second process to block until the object is migrated to the sever. I think that there's 3 ways to do this. 1. When the second process makes a call to get a handle to the (previously private) object, block the calling thread (delay the response) until the object is migrated to the server, or 2. When the second process makes a call to get a handle to the (previously private) object, trigger a migration but don't block the calling thread (pending a completed migration) until it makes a call to actually *use* that object (ReleaseSemaphore, QuerySemaphore, server_select, etc.), or 3. Don't do anything until the second process makes a call to actually use the object, then trigger the migration and wait for it to finish. For simplicity, I was heading for the first option, but greater throughput could be obtained by the second option (if this is happening a lot) and a process will have a greater chance of getting to use an optimized (local) object with the 3rd option (not that I think it's a good option, just trying to be complete). > The only time you'd need to signal the client is when a thread is > waiting on the object being moved, so that the thread can restart the > wait using the server. Ah, another good reason to share memory between client & server! :) Also, it would enable wait multiple with mixed object types w/o forcing the object to be migrated to the server too. > I don't know how you plan to wait on > process-local objects, but perhaps you can perform the wait in such a > way that the server can interrupt it easily, without disturbing the > thread if it's doing anything else? > I don't have a complete design for this yet. I'm thinking that a custom synchronization mechanism using futexes would be appropriate (not that I've done that before or even used futexes) so we just notify a futex. Without the shared memory, I was thinking of having the server send SIGUSR1 (or some such) to the client and that handler would send a request to the server to see what it wanted. The server would reply by telling it to migrate some object and then the client would manage this from the handler. So with just kill(), I don't think you get a choice over which thread responds to it, so the handler would just need to be aware if it was actually waiting on a futex when it was signaled and manage that appropriately. Again, I haven't really worked that part out just yet. Using shared memory is certainly another option -- then we just have the server mark the object as needing migration and signal a futex. When a wait is completed on the client, it should just always read that value to know why it was signaled.

Sept. 16, 2015

Re: disabling wow64, testing 64-bit wine-mono P/invoke

by Vincent Povirk

> I was very confused by both of > libmono-2.0-x86_64.dll libmono-2.0-x86.dll MonoPosixHelper-x86_64.dll MonoPosixHelper-x86.dll > in c:/windows/mono/mono-2.0/bin/ > > In fact libmono-2.0-x86_64.dll MonoPosixHelper-x86_64.dll > are never used, at the moment. Correct. Alexandre insisted we include 64-bit builds anyway. In theory, they would work if Wine had everything required.

Sept. 16, 2015

Re: disabling wow64, testing 64-bit wine-mono P/invoke

by Hin-Tak Leung

------------------------------ On Wed, Sep 16, 2015 3:45 AM BST Vincent Povirk wrote: >> Is there any way of doing this with 64-bit wine and 64-bit wine-mono? > >Currently, Wine does not have the ability to load pure .NET PE images >in a 64-bit process. > >Ntdll needs to call _CorValidateImage during the loading process. >_CorValidateImage needs to convert the image, in memory, to the >correct architecture. > >It's complicated, and I don't have a solution. Actually you do :-). Using http://madewokherd.nfshost.com/omgsecret/mono-64bit-exe.tar.gz from https://bugs.winehq.org/show_bug.cgi?id=30518 It is a bit dated, but does the job. I was very confused by both of libmono-2.0-x86_64.dll libmono-2.0-x86.dll MonoPosixHelper-x86_64.dll MonoPosixHelper-x86.dll in c:/windows/mono/mono-2.0/bin/ In fact libmono-2.0-x86_64.dll MonoPosixHelper-x86_64.dll are never used, at the moment. When 64-bit mono loads a .NET PE image which then P/Invoke, it does so P/Invoke to 64-bit dlls.

Sept. 16, 2015

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION. (try 2)

by Dmitry Timoshkov

Jactry Zeng <jzeng(a)codeweavers.com> wrote: > +void X11DRV_FlashWindow( HWND hwnd, BOOL bInvert ) > +{ > + struct x11drv_win_data *data = get_win_data( hwnd ); > + XEvent xev; > + > + if (!data) > + return; > + > + memset( &xev, 0, sizeof(xev) ); > + xev.type = ClientMessage; > + xev.xclient.window = data->whole_window; > + xev.xclient.message_type = x11drv_atom( _NET_WM_STATE ); > + xev.xclient.format = 32; > + xev.xclient.data.l[0] = 1; > + xev.xclient.data.l[1] = XInternAtom( data->display, "_NET_WM_STATE_DEMANDS_ATTENTION", > + False ); > + > + XSendEvent( data->display, DefaultRootWindow( data->display ), False, > + SubstructureNotifyMask, &xev ); > + release_win_data( data ); > +} This can't work, please have a look how XSendEvent is used in other parts of x11drv. -- Dmitry.

Sept. 16, 2015

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with UrgencyHint flag.

by Jactry Zeng

Hi Dmitry, 2015-09-14 17:34 GMT+08:00 Dmitry Timoshkov <dmitry(a)baikal.ru>: > > Probably FlashWindow should be implemented with _NET_WM_STATE_DEMANDS_ATTENTION > instead. I have sent another try implemented with _NET_WM_STATE_DEMANDS_ATTENTION. Could you make some comment on it? Thank you very much! :-) -- Regards, Jactry Zeng

Sept. 16, 2015

Re: disabling wow64, testing 64-bit wine-mono P/invoke

by Vincent Povirk

> Is there any way of doing this with 64-bit wine and 64-bit wine-mono? Currently, Wine does not have the ability to load pure .NET PE images in a 64-bit process. Ntdll needs to call _CorValidateImage during the loading process. _CorValidateImage needs to convert the image, in memory, to the correct architecture. It's complicated, and I don't have a solution.

Sept. 16, 2015

Re: [PATCH 3/4] xaudio2: Call OnStreamEnd callback

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=16733 Your paranoid android. === w864 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFB6EDD4B7D === w1064 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFC549A4B7D

Sept. 16, 2015