September 2015 - Wine-Devel

Wine and Buildroot
by André Hentschel Sept. 25, 2015

Sept. 25, 2015

Hi, For those interested, I just add an introduction of Buildroot to our Wine-Wiki: http://wiki.winehq.org/Buildroot See also my slides from WineConf2015: http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=otherar… And a short WWN article from March 2015: https://www.winehq.org/wwn/387#Wine%20in%20Buildroot

2 1

Wine Stable/Release Changes
by Michael Stefaniuc Sept. 25, 2015

Sept. 25, 2015

-----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-----

6 6

Re: [PATCH] [comctl32] Fix sizing of edit window for listview icon view
by Nikolay Sivov Sept. 25, 2015

Sept. 25, 2015

On 25.09.2015 4:33, Barrett Karish wrote: > --- > dlls/comctl32/listview.c | 42 +++++++++++++++++++++++++----------------- > 1 file changed, 25 insertions(+), 17 deletions(-) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index e3fad51..ba227a7 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -6048,12 +6048,15 @@ static LRESULT CALLBACK EditLblWndProcA(HWND hwnd, UINT uMsg, WPARAM wParam, LPA > */ > static HWND CreateEditLabelT(LISTVIEW_INFO *infoPtr, LPCWSTR text, BOOL isW) > { > - static const DWORD style = WS_CHILDWINDOW|WS_CLIPSIBLINGS|ES_LEFT|ES_AUTOHSCROLL|WS_BORDER|WS_VISIBLE; > - HINSTANCE hinst = (HINSTANCE)GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_HINSTANCE); > + DWORD style = WS_CHILDWINDOW | WS_CLIPSIBLINGS | ES_LEFT | ES_AUTOHSCROLL | WS_BORDER | WS_VISIBLE | ES_MULTILINE; > + HINSTANCE hinst = (HINSTANCE)GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_HINSTANCE); Hi, Barrett. Please use existing 4 space formatting and avoid unnecessary changes. > HWND hedit; > > TRACE("(%p, text=%s, isW=%d)\n", infoPtr, debugtext_t(text, isW), isW); > > + if (infoPtr->uView == LV_VIEW_ICON) > + style |= ES_CENTER; We need a test that proves that Edit gets centered style on icon view. > + > /* window will be resized and positioned after LVN_BEGINLABELEDIT */ > if (isW) > hedit = CreateWindowW(WC_EDITW, text, style, 0, 0, 0, 0, infoPtr->hwndSelf, 0, hinst, 0); > @@ -6093,7 +6096,6 @@ static HWND LISTVIEW_EditLabelT(LISTVIEW_INFO *infoPtr, INT nItem, BOOL isW) > HFONT hOldFont = NULL; > TEXTMETRICW tm; > RECT rect; > - SIZE sz; > HDC hdc; > > TRACE("(nItem=%d, isW=%d)\n", nItem, isW); > @@ -6152,24 +6154,30 @@ static HWND LISTVIEW_EditLabelT(LISTVIEW_INFO *infoPtr, INT nItem, BOOL isW) > GetWindowTextW(infoPtr->hwndEdit, disptextW, DISP_TEXT_SIZE); > TRACE("edit box text=%s\n", debugstr_w(disptextW)); > > - /* get string length in pixels */ > - GetTextExtentPoint32W(hdc, disptextW, lstrlenW(disptextW), &sz); > + DrawTextW(hdc, disptextW, -1, &rect, infoPtr->uView == LV_VIEW_ICON ? LV_FL_DT_FLAGS : LV_SL_DT_FLAGS | DT_CALCRECT); > > - /* add extra spacing for the next character */ > - GetTextMetricsW(hdc, &tm); > - sz.cx += tm.tmMaxCharWidth * 2; > + if (infoPtr->uView != LV_VIEW_ICON) > + { > + /* add extra spacing for the next character */ > + GetTextMetricsW(hdc, &tm); > + rect.right += tm.tmMaxCharWidth; > + rect.left -= 2; > + rect.top -= 1; > + rect.bottom += 2; > + } > + else > + { > + rect.bottom += 3; > + } > This should ideally use some font metrics instead of hardcoded magic, but I know we do it this way already. > - if (infoPtr->hFont) > - SelectObject(hdc, hOldFont); > + if (infoPtr->hFont) > + SelectObject(hdc, hOldFont); > > - ReleaseDC(infoPtr->hwndSelf, hdc); > + ReleaseDC(infoPtr->hwndSelf, hdc); > > - sz.cy = rect.bottom - rect.top + 2; > - rect.left -= 2; > - rect.top -= 1; > - TRACE("moving edit=(%d,%d)-(%d,%d)\n", rect.left, rect.top, sz.cx, sz.cy); > - MoveWindow(infoPtr->hwndEdit, rect.left, rect.top, sz.cx, sz.cy, FALSE); > - ShowWindow(infoPtr->hwndEdit, SW_NORMAL); > + TRACE("moving edit=(%d,%d)-(%d,%d)\n", rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top); > + MoveWindow(infoPtr->hwndEdit, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top, FALSE); > + ShowWindow(infoPtr->hwndEdit, SW_NORMAL); > SetFocus(infoPtr->hwndEdit); > SendMessageW(infoPtr->hwndEdit, EM_SETSEL, 0, -1); > return infoPtr->hwndEdit; >

1 0

Re: [2/2] kernel32: Implement Set/GetThreadGroupAffinity and add tests.
by Marvin Sept. 23, 2015

Sept. 23, 2015

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)

2 1

Inconsistent argument type declaration in dinput.h: WriteEffectToFile()
by Elias Vanderstuyft Sept. 23, 2015

Sept. 23, 2015

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

3 4

Re: [PATCH 11/12] ddraw: cache active DCs
by Stefan Dösinger Sept. 23, 2015

Sept. 23, 2015

-----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-----

1 0

Re: [PATCH 11/12] ddraw: cache active DCs
by Jonas Maebe Sept. 23, 2015

Sept. 23, 2015

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

2 1

Re: [PATCH 02/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX surfaces
by Stefan Dösinger Sept. 23, 2015

Sept. 23, 2015

-----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-----

2 1

Re: kernel32: Create registry keys for available COM ports
by Austin English Sept. 22, 2015

Sept. 22, 2015

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

1 0

Re: msi: Set the PrimaryVolumeSpaceRequired and PrimaryVolumeSpaceRemaining properties.
by Marvin Sept. 22, 2015

Sept. 22, 2015

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

1 0