March 2010 - Wine-Devel - list.winehq.org

Re: rsaenh(2/6): Add support for SHA-256, SHA-384, and SHA-512 (try 2)
by Alexandre Julliard March 15, 2010

March 15, 2010

Juan Lang <juan.lang(a)gmail.com> writes: > +/* Hash constant words K for SHA-384 and SHA-512: */ > +const static sha2_word64 K512[80] = { > + 0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL, > + 0xb5c0fbcfec4d3b2fULL, 0xe9b5dba58189dbbcULL, ULL constants are not portable and should be avoided. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: comctl32: resend [Bug 17251] cchTextMax needs to be set for LVS_OWNERDATA as it uses LVN_GETDISPINFO notifications
by Nikolay Sivov March 15, 2010

March 15, 2010

On 3/15/2010 16:08, Jeff Latimer wrote: > > Changed LISTVIEW_EndEditLabel to set up the call to LISTVIEW_GetItemT > the same as LISTVIEW_EditLabel > > If not set then no value is returned and in the case of uTorrent the > next entry selected is renamed. > http://bugs.winehq.org/show_bug.cgi?id=17251 > > A test case has proved difficult to construct as the event is > triggered by mouse clicks and the behaviour of EditLabel appears to be > different in test. > --- > dlls/comctl32/listview.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) I think this looks reasonable. Does it fix a bug by the way?

1 0

Re: [PATCH] configure.ac: use proper quoting throughout the file
by Yann Droneaud March 15, 2010

March 15, 2010

Hi, Le lundi 15 mars 2010 à 11:13 +0100, Yann Droneaud a écrit : > Added quoting around macro parameters as recommanded by autoconf: > http://www.gnu.org/software/autoconf/manual/html_node/Autoconf-Language.htm… > > Autoconf output was checked to be the same with and without the patch, > so that it's easy to validate the patch: configure script is exactly the > same with or without the patch. > > Note: Quoting were not added for WINE macros related to Makefile generation > as they broke things: there are some quoting magic in aclocal.m4 not > fixed by this patch. As stated in the patch log, it can be applied safely. But once applied on current HEAD, most pending patches on configure.ac won't apply. So if this patch is going to be applied, developer must be warned first and hold their own patches. I'm ok to hold this one a week or two, so pending patches could be applied without modification before this one get applied. I have another patches waiting to fix some autoconf constructs. Regards. -- Yann Droneaud

2 2

Re: comctl32: [Bug 17251] cchTextMax needs to be set for LVS_OWNERDATA as it uses LVN_GETDISPINFO notifications
by Nikolay Sivov March 15, 2010

March 15, 2010

On 3/13/2010 06:35, Jeff Latimer wrote: > > If not set then no value is returned and in the case of uTorrent the > next entry selected is renamed. > http://bugs.winehq.org/show_bug.cgi?id=17251 No value returned from what? > > A test case has proved difficult to construct as the event is > triggered by mouse clicks and the behaviour of EditLabel appears to be > different in test. > --- > dlls/comctl32/listview.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > dispInfo.item.iItem = editedItem; > dispInfo.item.iSubItem = 0; > dispInfo.item.stateMask = ~0; > + dispInfo.item.cchTextMax = textlenT(pszText, isW)+2; > if (!LISTVIEW_GetItemW(infoPtr,&dispInfo.item)) > Could you explain what this change fixes exactly? As I remember uTorrent uses an LVS_OWNERDATA listview, so this cchTextMax isn't processed in LISTVIEW_GetItemW. Also I'm not sure what you mean here --- textlenT(pszText, isW)+2 --- pszText is Edit control text at this point (or NULL). How it's related to LISTVIEW_GetItemW? And what this +2 adding mean?

3 6

Documentation?
by André Hentschel March 15, 2010

March 15, 2010

Hi Folks, As we are getting somehow closer to Wine 1.2 i wonder how important updates on the Documentation are. Further i am confused about sending patches, should they just change the git-repo "docs" or the pages on the website or both? -- Best Regards, André Hentschel

7 8

.net 3.5sp1 status check, blocking GFWL
by Edward Savage March 15, 2010

March 15, 2010

Several high profile games are currently being blocked from working by Games for Windows - Live. GFWL installs successfully under wine how ever is unable to run due to its reliance on .net 3.5sp1. Neither mono 2.4 or 2.6 currently for-fill its requirements. The games affected either install and run (in the case of Batman at a Platinum status) with no ability to save current progress or crash due to the lack of GFWL. Many Steam games cannot run due to Steam attempting to install GFWL and the installer fails due to it detecting a lack of .net 3.5sp1. I'm interested to find out the current progress on .net 3.5sp1, what still needs to be done, and if its installed status can be faked for the purposes of tricking the GFWL installer in to completing. This would allow the games to be run via Steam sans the ability to save. As an aside if people have other examples of games being broken by GFWL please report them so a list of blocked games can be compiled. My list currently includes Batman Arkham Asylum, Red Faction: Guerrilla, Dawn of War 2 and several less popular titles. The GFWL binary is available here http://www.microsoft.com/games/EN-US/LIVE/Pages/livejoin.aspx Regards,

2 1

Re: [3/7] dxdiagn: Fix string copy behavior with an excessively short buffer in IDxDiagContainer::EnumChildContainerNames. (try 2)
by Vitaliy Margolen March 15, 2010

March 15, 2010

On 03/14/2010 11:04 AM, Andrew Nguyen wrote: > --- a/dlls/dxdiagn/container.c > +++ b/dlls/dxdiagn/container.c > @@ -97,12 +97,10 @@ static HRESULT WINAPI IDxDiagContainerImpl_EnumChildContainerNames(PDXDIAGCONTAI > > p = This->subContainers; > while (NULL != p) { > - if (dwIndex == i) { > - if (cchContainer <= strlenW(p->contName)) { > - return DXDIAG_E_INSUFFICIENT_BUFFER; > - } > + if (dwIndex == i) { > lstrcpynW(pwszContainer, p->contName, cchContainer); > - return S_OK; > + return (cchContainer <= strlenW(p->contName)) ? > + DXDIAG_E_INSUFFICIENT_BUFFER : S_OK; > } You sure it's "<="? You still need one more character for \0. Vitaliy.

2 2

Re: [2/7] dxdiagn: Fix return and output behavior of IDxDiagContainer::EnumChildContainerNames. (try 2)
by Vitaliy Margolen March 15, 2010

March 15, 2010

On 03/14/2010 11:03 AM, Andrew Nguyen wrote: > --- > dlls/dxdiagn/container.c | 15 +++++------ > dlls/dxdiagn/tests/container.c | 49 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 56 insertions(+), 8 deletions(-) > > - > - TRACE("(%p, %u, %s, %u)\n", iface, dwIndex, debugstr_w(pwszContainer), cchContainer); > > - if (NULL == pwszContainer) { > + TRACE("(%p, %u, %p, %u)\n", iface, dwIndex, pwszContainer, cchContainer); > + > + if (NULL == pwszContainer || 0 == cchContainer) { > return E_INVALIDARG; > } Please add printing of debugstr_w(pwszContainer) back, after sanity checks. It's something really useful to know.

2 2

Re: msxml3: Treat input BSTR as general WCHAR string for ::loadXML()
by Vitaliy Margolen March 14, 2010

March 14, 2010

On 03/14/2010 02:08 PM, Nikolay Sivov wrote: > http://bugs.winehq.org/show_bug.cgi?id=22020 > > Some applications don't bother to pass properly allocated BSTR as a ::loadXML() parameter, > so we crash on invalid length taken from DWORD before passed pointer. > Some tests verifying this would be nice. Also you might as well rename bstr_to_utf8() to represent what it's doing. Vitaliy.

2 1

Re: winex11.drv: Set WM_COMMAND property so that xlsclients can list Wine.
by Vincent Povirk March 14, 2010

March 14, 2010

You should create a WM_CLIENT_LEADER window as described here: http://tronche.com/gui/x/icccm/sec-5.html That way, the windows belonging to a single client can be reliably linked together. I think you can ignore the requirement that the client leader window have an id from the session manager. I have several programs running right now that don't set SM_CLIENT_ID on their client leader window. On Fri, Mar 12, 2010 at 4:18 AM, Kusanagi Kouichi <slash(a)ac.auone-net.jp> wrote: > Signed-off-by: Kusanagi Kouichi <slash(a)ac.auone-net.jp> > --- > dlls/winex11.drv/window.c | 14 ++++++++++++++ > 1 files changed, 14 insertions(+), 0 deletions(-) > > diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c > index 47f7245..73eba1f 100644 > --- a/dlls/winex11.drv/window.c > +++ b/dlls/winex11.drv/window.c > @@ -947,6 +947,9 @@ static void set_initial_wm_hints( Display *display, struct x11drv_win_data *data > Atom dndVersion = WINE_XDND_VERSION; > XClassHint *class_hints; > char *process_name = get_process_name(); > + LPCWSTR cmdline; > + int len; > + LPSTR buf; > > wine_tsx11_lock(); > > @@ -969,6 +972,17 @@ static void set_initial_wm_hints( Display *display, struct x11drv_win_data *data > XFree( class_hints ); > } > > + /* set WM_COMMAND */ > + cmdline = GetCommandLineW(); > + len = WideCharToMultiByte(CP_UNIXCP, 0, cmdline, -1, NULL, 0, NULL, NULL); > + buf = HeapAlloc(GetProcessHeap(), 0, len); > + if (buf != NULL) > + { > + WideCharToMultiByte(CP_UNIXCP, 0, cmdline, -1, buf, len, NULL, NULL); > + XSetCommand(display, data->whole_window, &buf, 1); > + HeapFree(GetProcessHeap(), 0, buf); > + } > + > /* set the WM_CLIENT_MACHINE and WM_LOCALE_NAME properties */ > XSetWMProperties(display, data->whole_window, NULL, NULL, NULL, 0, NULL, NULL, NULL); > /* set the pid. together, these properties are needed so the window manager can kill us if we freeze */ > -- > 1.7.0 > > > >

2 1