Re: [PATCH 4/8] jscript: Added bytecode version of try statement
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 http://testbot.winehq.org/JobDetails.pl?Key=16180 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [PATCH 8/8] jscript: Added more control flow tests
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 http://testbot.winehq.org/JobDetails.pl?Key=16181 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [PATCH 8/8 try2] jscript: Added more control flow tests
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 http://testbot.winehq.org/JobDetails.pl?Key=16183 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [PATCH 4/8 try2] jscript: Added bytecode version of try statement
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 http://testbot.winehq.org/JobDetails.pl?Key=16182 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: include: Only include winuser.h in oleidl.idl as a replacement for windows.h when compiling the Wine source.
Hi Francois, On 12/28/11 10:39, Francois Gouget wrote: -cpp_quote(#includewinuser.h) +cpp_quote(#ifdef __WINESRC__) +cpp_quote(# includewinuser.h) +cpp_quote(#endif) /* * IOleTypes interface How about entirely removing that include? We can always include it in C files that need it. Jacek
Re: DIB crash with gdb
On 12/23/2011 09:56 PM, Ken Thomases wrote: On Dec 23, 2011, at 3:10 PM, Michael Ost wrote: This all makes sense, and pulls the code together for me. Thanks! You're welcome. I assume this is a recent development, because I was successfully using gdb with our last wine version - 1.1.7. Nope. This is how it has worked for a long, long time. Don't know what else has changed. Maybe some of the other work on the DIB engine has changed whether/when the DIB accesses cause access violations that you're seeing. Interesting. Maybe a resource that is loaded at startup changed so it needs alpha blending now. I'll see if I can hack around that for my local use with gdb. Thanks again, Michael Ost But it no longer sounds workable to use gdb for debugging winelib applications, which is a drag. Are you suggesting using winedbg instead? Well, you can use winedbg with $BreakOnFirstChance set to 0, for some apps. (Setting $BreakOnFirstChance to 0 only has to be done once for a given WINEPREFIX. It's saved in the registry.) You can also try that handle SIGSEGV nostop noprint pass command I gave you. You might try starting with that signal-handling setup and then, when you get close to where you expect a true crash to happen, switch it back (handle SIGSEGV stop print nopass). Some day, the DIB engine will be complete and this memory protection scheme will not be necessary to coordinate DIB access between memory and the X server. Do you know if it can be used as a drop-in replacement in, say, Qt Creator (which is my IDE of choice)? No, it can't. Its interface is not identical to gdb's. Regards, Ken
Re: include: Only include winuser.h in oleidl.idl as a replacement for windows.h when compiling the Wine source.
On Wed, 28 Dec 2011, Jacek Caban wrote: Hi Francois, On 12/28/11 10:39, Francois Gouget wrote: -cpp_quote(#includewinuser.h) +cpp_quote(#ifdef __WINESRC__) +cpp_quote(# includewinuser.h) +cpp_quote(#endif) /* * IOleTypes interface How about entirely removing that include? We can always include it in C files that need it. Substituting an alternative header for windows.h is an approach that is used in a few other places, specifically in dshow.h, msctf.h, pdh.h, rpc.h, snmp.h and winsock.h. So I think it's ok to follow the pattern here, it should just be a bit clearer. But if the consensus is that it (and the others?) should be removed I can do that too. The patch will be quite a bit bigger though. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
PVS-Studio run against ReactOS: (at least) one bug in wine git
Hi. Reading this page about a PVS-Studio run against ReactOS: http://www.viva64.com/en/a/0076/ I looked up in wine's repository the ones mentioned in the article. There are more in the full output: http://www.viva64.com/external-pictures/txt/PVS-Studio-vs-ReactOS-en-unicode.txt I found only one error still present: strcmpW without use of return value is still present, dlls/msdmo/dmoreg.c:620 I guess wcscpy (or so) was intended. Cc'ed Ulrich Czekalla, as git blame brings his name up (...from 2003 !). Regards, -- Vincent Pelletier
Re: [PATCH 2/7] wined3d: Move srgb checks away from d3dfmt_get_conv.
On Wed, Dec 28, 2011 at 07:46:09AM +0100, Henri Verbeet wrote:
On 26 December 2011 05:32, Diego Nieto Cid dnie...@gmail.com wrote:
trace:d3d_surface:surface_allocate_surface (0x1a25f0) : Creating surface
(target 0xde1) level 0, d3d format WINED3DFMT_P8_UINT, internal format
0x80e5, width 1024, height 512, gl format 0x1908, gl type=0x1401
err:d3d_surface:surface_allocate_surface GL_INVALID_VALUE
(0x501) from glTexImage2D @ surface.c / 2571
Does your hardware really support EXT_paletted_texture? That's somewhat
unusual.
I've got a rather old NVIDIA video card:
01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 4000]
(rev c1)
On Wed, Dec 28, 2011 at 07:46:09AM +0100, Henri Verbeet wrote:
It's located in d3dfmt_get_conv under the WINED3DFMT_P8_UINT case. For
some reason only glInternal is updated by the conversion. In any case it
didn't matter before the patch as none of the internal values were
actually used in case a conversion was applied.
Should the three internal values be updated by the conversion now that
any of them could be used?
Probably, yeah. Not just for WINED3DFMT_P8_UINT, but for all the
formats in d3dfmt_get_conv(). I guess something like the following at
the end of d3dfmt_get_conv() should work:
if (*convert != NO_CONVERSION)
{
format-glGammaInternal = format-glInternal;
format-rtInternal = format-glInternal;
}
The HEAD checkout is randomly failing due to
wine: Unhandled page fault on read access to 0x at address (nil)
(thread 0036), starting debugger...
X Error of failed request: GLXBadDrawable
Major opcode of failed request: 128 (GLX)
Minor opcode of failed request: 5 (X_GLXMakeCurrent)
Serial number of failed request: 621
Current serial number in output stream: 621
But I'll try adding that snippet to a checkout of the version installed on
my system. (I have no idea how to debug the error above :)
