April 2011 - Wine-Devel - list.winehq.org

Re: [PATCH] dinput: Mark internal symbols as hidden

by Marcus Meissner

On Sat, Apr 30, 2011 at 05:18:03AM +0200, Henri Verbeet wrote: > On 30 April 2011 00:41, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > I don't know how much the effect of marking a few functions hidden changes that > > though. In the d3d code most things are already either static or hidden, and > > still not using -fPIC on wined3d alone improves things. > > > Things like TRACEs still cause pc loads. There's the actual > wine_dbg_log() call that has to go through the plt, but also the > string references and the debug channel info that go through the got. > I suppose that if you're crazy enough about performance to care about > that kind of thing you'd already compiled those out anyway though. This is one of our major overheads, yes. As distribution packager I wonder if I should build without debug or not. A special package (wine-nodebug)? Or just leave out TRACE() messages? Ciao, Marcus

April 30, 2011

Re: gecko and native msvcrt

by Jacek Caban

On 4/29/11 11:58 PM, Eric Pouech wrote: > Le 29/04/2011 23:07, Dan Kegel a écrit : >> While testing a game with current gecko, I saw the error >> >> wine: Call from 0x7bc4ad90 to unimplemented function >> msvcrt.dll._snwprintf_s, >> aborting >> >> The game needed a native msvcrt, so I had installed one with winetricks, >> and it didn't export that function. >> >> So it seems that new gecko is incompatible with old msvcrt, >> and using native msvcrt as a workaround for bugs in wine's >> version is going to be harder than it used to be. >> >> Time to fix more of them msvcrt bugs, I guess... >> And/or find a more up to date msvcrt.dll for winetricks. >> >> >> > or link gecko against msvcr80 or msvcr90 instead of msvcrt It's harder than it seems, esp. because it's not well supported by mingw-w64. Also even if we did it, Wine would still forward these calls to msvcrt, so one would need another native DLL. Given that, we need more serious reason for the change than supporting hackish winetricks verb. Fixing our msvcrt implementation is the way to go IMO. Jacek

April 30, 2011

Re: [PATCH] dinput: Mark internal symbols as hidden

by Marcus Meissner

On Sat, Apr 30, 2011 at 12:41:19AM +0200, Stefan Dösinger wrote: > On Friday 29 April 2011 21:01:36 Marcus Meissner wrote: > > I do not think there will be noticable speed-up. > Actually, not using -fPIC gives a ~2-3% speed boost in a number of d3d > benchmarks. > > I don't know how much the effect of marking a few functions hidden changes that > though. In the d3d code most things are already either static or hidden, and > still not using -fPIC on wined3d alone improves things. I suspect the fixes I am doing are really neglible speed wise. They are usually not in any fast-paths, it is basically just clean-up. Perhaps a small bit better load speed of the DSO, also %ebx handling changes might assist broken Windows programs, but otherwise there likely will be no measurable effect. Ciao, Marcus

April 30, 2011

comctl32: realloc or free and alloc

by Alexey Fisher

Hallo, i currently digg in comctl32 to find why my app fails. I found that string conversation AtoW in some places silently fails. The problem is that the destination for string is just a fresh pointer (not NULL). Str_SetPtrAtoW check if it is NULL pointer and if not it trys to ReAlloc. There was no Alloc before so ReAlloc returns NULL. Because there is no other checks, Str_SetPtrAtoW just go back without converting the string. Here is affected code: dlls/comctl32/comctl32undoc.c:999 > BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc) > { > TRACE("(%p %s)\n", lppDest, lpSrc); > > if (lpSrc) { > INT len = MultiByteToWideChar(CP_ACP,0,lpSrc,-1,NULL,0); > LPWSTR ptr = ReAlloc (*lppDest, len*sizeof(WCHAR)); > > if (!ptr) { > ERR("last error %x\n", GetLastError()); > return FALSE; > } > MultiByteToWideChar(CP_ACP,0,lpSrc,-1,ptr,len); > *lppDest = ptr; > } > else { > Free (*lppDest); > *lppDest = NULL; > } > > return TRUE; > } The question is, is it appropriate reaction of ReAlloc and if it so, may be it make more sense to do this: --- a/dlls/comctl32/comctl32undoc.c +++ b/dlls/comctl32/comctl32undoc.c @@ -998,18 +998,26 @@ INT Str_GetPtrAtoW (LPCSTR lpSrc, LPWSTR lpDest, INT nMaxLen) */ BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc) { - TRACE("(%p %s)\n", lppDest, lpSrc); + TRACE("(%p, %s)\n", *lppDest, debugstr_a(lpSrc)); if (lpSrc) { + if (*lppDest) { + Free (*lppDest); + *lppDest = NULL; + } INT len = MultiByteToWideChar(CP_ACP,0,lpSrc,-1,NULL,0); - LPWSTR ptr = ReAlloc (*lppDest, len*sizeof(WCHAR)); + LPWSTR ptr = Alloc (len*sizeof(WCHAR)); - if (!ptr) + if (!ptr) { + ERR("Can't allocait memory size: %u," + " for string %s.\n", len*sizeof(WCHAR), lpSrc); return FALSE; + } MultiByteToWideChar(CP_ACP,0,lpSrc,-1,ptr,len); *lppDest = ptr; } else { + TRACE("lpSrc = NULL, nothing to convert.\n"); Free (*lppDest); *lppDest = NULL; } -- Regards, Alexey

April 30, 2011

Re: wined3d: If Wine fails to acquire the focus window, allow the wndproc function to continue receiving messages.

by Henri Verbeet

On 30 April 2011 01:23, John Edmonds <pocketcookies2(a)gmail.com> wrote: > @@ -6559,6 +6559,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_Reset(IWineD3DDevice *iface, > { > ERR("Failed to acquire focus window, hr %#x.\n", hr); > wined3d_swapchain_decref(swapchain); > + This->filter_messages = filter; > return hr; > } This patch looks right in principle. Note that if you're running into this code you probably have problems elsewhere though.

April 30, 2011

Re: [PATCH] dinput: Mark internal symbols as hidden

by Henri Verbeet

On 30 April 2011 00:41, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > I don't know how much the effect of marking a few functions hidden changes that > though. In the d3d code most things are already either static or hidden, and > still not using -fPIC on wined3d alone improves things. > Things like TRACEs still cause pc loads. There's the actual wine_dbg_log() call that has to go through the plt, but also the string references and the debug channel info that go through the got. I suppose that if you're crazy enough about performance to care about that kind of thing you'd already compiled those out anyway though.

April 30, 2011

Re: [PATCH] dinput: Mark internal symbols as hidden

by Stefan Dösinger

On Friday 29 April 2011 21:01:36 Marcus Meissner wrote: > I do not think there will be noticable speed-up. Actually, not using -fPIC gives a ~2-3% speed boost in a number of d3d benchmarks. I don't know how much the effect of marking a few functions hidden changes that though. In the d3d code most things are already either static or hidden, and still not using -fPIC on wined3d alone improves things.

April 29, 2011

Re: gecko and native msvcrt

by Hin-Tak Leung

--- On Fri, 29/4/11, Eric Pouech <eric.pouech(a)orange.fr> wrote: > Le 29/04/2011 23:07, Dan Kegel a > écrit : > > While testing a game with current gecko, I saw the > error > > > > wine: Call from 0x7bc4ad90 to unimplemented function > msvcrt.dll._snwprintf_s, > > aborting > > > > The game needed a native msvcrt, so I had installed > one with winetricks, > > and it didn't export that function. > > > > So it seems that new gecko is incompatible with old > msvcrt, > > and using native msvcrt as a workaround for bugs in > wine's > > version is going to be harder than it used to be. > > > > Time to fix more of them msvcrt bugs, I guess... > > And/or find a more up to date msvcrt.dll for > winetricks. > > > > > > > or link gecko against msvcr80 or msvcr90 instead of msvcrt > A+ This may be asking for trouble - I assume gecko is (preferably) built with mingw gcc, rather than msvc. Recently I tried to go this route - wanted to have 64-bit file access from msvc80. Turned out that binaries generated this way gets very confused by the side-by-side assembly system with msvc80 and you need to add/insert a manifest to the PE if you want to go this route, and doing manifest insertion with mingw gcc or open-source tools (rather than microsoft's manifest tool) aren't easy. Ended up just switching to use mingw-specific unix-like 64-bit file access functions instead, to stay with msvcrt (v7). (i.e. the code wouldn't then build with MSVC because it uses mingw-specific things); but I would rather have it built easy with mingw gcc - it is a small sacrifice and easy to make to drop compatibility with msvc compiler..

April 29, 2011

Re: gecko and native msvcrt

by Eric Pouech

Le 29/04/2011 23:07, Dan Kegel a écrit : > While testing a game with current gecko, I saw the error > > wine: Call from 0x7bc4ad90 to unimplemented function msvcrt.dll._snwprintf_s, > aborting > > The game needed a native msvcrt, so I had installed one with winetricks, > and it didn't export that function. > > So it seems that new gecko is incompatible with old msvcrt, > and using native msvcrt as a workaround for bugs in wine's > version is going to be harder than it used to be. > > Time to fix more of them msvcrt bugs, I guess... > And/or find a more up to date msvcrt.dll for winetricks. > > > or link gecko against msvcr80 or msvcr90 instead of msvcrt A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 29, 2011

gecko and native msvcrt

by Dan Kegel

While testing a game with current gecko, I saw the error wine: Call from 0x7bc4ad90 to unimplemented function msvcrt.dll._snwprintf_s, aborting The game needed a native msvcrt, so I had installed one with winetricks, and it didn't export that function. So it seems that new gecko is incompatible with old msvcrt, and using native msvcrt as a workaround for bugs in wine's version is going to be harder than it used to be. Time to fix more of them msvcrt bugs, I guess... And/or find a more up to date msvcrt.dll for winetricks.

April 29, 2011