January 2009 - Wine-Devel - list.winehq.org

Re: Worldbench?

by Dan Kegel

On Wed, Jan 28, 2009 at 6:56 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > Very interesting. Here at CodeWeavers we have been very interested in > benchmarking test and had very little luck finding ones that ran. So out of curiosity, I just dug up my old copy of WinBench 96 and tried it again. The GUI has trouble measuring FILES= and the CRT's refresh rate, but the workaround of just killing and restarting described in http://bugs.winehq.org/show_bug.cgi?id=12267 still works. This time I tried running the 32 bit CPU test. It launched ok and burned lots of CPU. When it finished burning CPU, I found a results file in c:\windows\temp\zd3.$$$ containing results: [Test] Argument= Signature=Processor vendor prerelease 2 - expires Nov. 13, 1995. Not for distribution. Active=188 Result=5703.43485783837 So, there you go, my compaq presario r3000 is 20 times faster than a 133 MHz Pentium :-) http://www.imdl.gatech.edu/john/benchmarks.html The GUI kept outputting err:ntdll:RtlpWaitForCriticalSection section 0x7ef29420 "syslevel.c: Win16Mutex" wait timed out in thread 0019, blocked by 0022, retrying (60 sec) so something's screwed up, but at least I got some results out of the thing, which is a first. The disk test also seems to get launched and do something; I'm tracking down a problem it has, and will follow up on that tomorrow.

Jan. 29, 2009

Re: Should winetest retrieve msi log file on msi test failures?

by James Hawkins

On Wed, Jan 28, 2009 at 3:12 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Wed, Jan 28, 2009 at 12:14 PM, James Hawkins <truiken(a)gmail.com> wrote: >>> http://test.winehq.org/data/8f829034f3fe4da3e7adce2f4685e10ba2e2fe82/xp_fg-… >>> says >>> dlls/msi/tests/msi.c >>> msi.c:254: Test failed: wrong error 1618 >>> >>> 1618 is ERROR_INSTALL_ALREADY_RUNNING. >> >> ... There error is ERROR_INSTALL_ALREADY_RUNNING >> because the test before msi.c timed out (but is still running). > > So I guess the existing report has enough info. > > Does this happen enough that we should clean up after timed out msi > tests better somehow? > Just the opposite. We've made a lot of efforts before to cut down the test time for msi tests (always a struggle). That's the direction to continue moving. The problem is that winetest only kills a timeout process when the user running the winetest clicks the 'Ok' button on the timeout dialog. IMO winetest should just kill the process no matter what, or only depend on the message box when the tests are interactive. That's not a real solution to the problem though, as there is still a race between the msiexec process finishing the current install and the next msi test starting. One more piece of information I forgot to say in the first email. Adding logging is definitely out of the question, because that increases the running time of the msi tests tremendously. The real problem is users running winetest on boxes that are severely shut down as far as user restrictions go. We need to find a way to test for this condition before trying to run the msi tests. When the boxes are that closed off, msi practically isn't allowed to do anything and all of the tests fail. -- James Hawkins

Jan. 28, 2009

Re: Should winetest retrieve msi log file on msi test failures?

by Dan Kegel

On Wed, Jan 28, 2009 at 12:14 PM, James Hawkins <truiken(a)gmail.com> wrote: >> http://test.winehq.org/data/8f829034f3fe4da3e7adce2f4685e10ba2e2fe82/xp_fg-… >> says >> dlls/msi/tests/msi.c >> msi.c:254: Test failed: wrong error 1618 >> >> 1618 is ERROR_INSTALL_ALREADY_RUNNING. > > ... There error is ERROR_INSTALL_ALREADY_RUNNING > because the test before msi.c timed out (but is still running). So I guess the existing report has enough info. Does this happen enough that we should clean up after timed out msi tests better somehow?

Jan. 28, 2009

Re: Implement BiDi mirroring

by Khaled Hosny

On Wed, Jan 28, 2009 at 11:22:04PM +0200, Khaled Hosny wrote: > On Wed, Jan 28, 2009 at 01:00:43PM -0800, Juan Lang wrote: > > Hi Khaled, > > > > +void doMirror(WCHAR* ch) > > > > This should be static. > > > > + else if(*ch == mirrored[k].first) > > + { > > + *ch = mirrored[k].mirror; > > + return; > > + } > > > > The else if block is indented one level too many. > > Both fixed. Sorry, the patch was broken (I used git-diff --color!). I attached a new one. Regards, Khaled -- Khaled Hosny Arabic localizer and member of Arabeyes.org team

Jan. 28, 2009

Re: Implement BiDi mirroring

by Khaled Hosny

On Wed, Jan 28, 2009 at 01:00:43PM -0800, Juan Lang wrote: > Hi Khaled, > > +void doMirror(WCHAR* ch) > > This should be static. > > + else if(*ch == mirrored[k].first) > + { > + *ch = mirrored[k].mirror; > + return; > + } > > The else if block is indented one level too many. Both fixed. Regards, Khaled -- Khaled Hosny Arabic localizer and member of Arabeyes.org team

Jan. 28, 2009

Re: Implement BiDi mirroring

by Juan Lang

Hi Khaled, +void doMirror(WCHAR* ch) This should be static. + else if(*ch == mirrored[k].first) + { + *ch = mirrored[k].mirror; + return; + } The else if block is indented one level too many. Thanks, --Juan

Jan. 28, 2009

Re: Should winetest retrieve msi log file on msi test failures?

by James Hawkins

On Wed, Jan 28, 2009 at 5:05 AM, Dan Kegel <dank(a)kegel.com> wrote: > Looking at test.winehq.org's XP results, it seems we're doing > quite well; some of the remaining failures seem to be unusual situations. > For instance: > > msi:msi.c is passing flawlessly on 7 out of 10 computers, > and on one of the computers, it has just one failure: > http://test.winehq.org/data/8f829034f3fe4da3e7adce2f4685e10ba2e2fe82/xp_fg-… > says > dlls/msi/tests/msi.c > msi.c:254: Test failed: wrong error 1618 > > 1618 is ERROR_INSTALL_ALREADY_RUNNING. > > Say, can winetest retrieve and display the msi log file on failure? That > might be informative... > It wouldn't be useful. There error is ERROR_INSTALL_ALREADY_RUNNING because the test before msi.c timed out (but is still running). -- James Hawkins

Jan. 28, 2009

Re: advapi32: Fix potential NULL pointer dereference in RegSetValueExA [with test] (Saturn)

by Aurimas Fišeras

Alexandre Julliard wrote: > Aurimas Fišeras <aurimas(a)gmail.com> writes: > > >> How to know when to fix NULL pointer dereferences if in most such cases >> code flow can be traced back to a windows API called by "other program"? > > If some other program is really calling it with NULL then you can fix > it. You can't preemptively fix every API that takes a pointer. > OK, I won't "fix" any windows API if no program calls it, although I don't believe that is right. But what about this and similar situations? Error report: server/debugger.c:160 red Possible NULL dereference of exe_module Intraprocedural Null error 143: struct process_dll *exe_module = get_process_exe_module( process ); ... 160: if (exe_module->file && process.h: static inline struct process_dll *get_process_exe_module( struct process *process ) { struct list *ptr = list_head( &process->dlls ); return ptr ? LIST_ENTRY( ptr, struct process_dll, entry ) : NULL; } What should I do? 1. change get_process_exe_module() to return LIST_ENTRY( ptr, struct process_dll, entry ); 2. change debugger.c:160 to if (exe_module && exe_module->file && 3. inspect list_head()? 4. ignore it?

Jan. 28, 2009

Re: D3D: Implement vertex blending in drawStridedSlow

by Henri Verbeet

2009/1/28 Claudio Ciccani <klan(a)users.sf.net>: > Why not both? It doesn't really work that way, you have to justify adding stuff. > I mean, you could implement a hardware based vertex blending routine > using a vertex shader and keep the software vertex blending routine in > case vertex programs are not supported by underlying hardware. > Actually this is what the patch does: fall back to software vertex > blending when hardware vertex blending is not supported. > I'm fairly certain there aren't a whole lot of cards that don't support either ARB_vertex_blend or vertex shaders, but do support vertex blending on Windows. >> > If I understand, the software-only wined3d backend is dead and gone, so >> Slightly OT, but we might need to implement software shaders at some >> point, although that has a rather low priority right now. Would be >> interesting to see if we could use Mesa swrast for that. > > Implementing shaders in software would be terribly slow. Sure, but that's not a problem, applications that create software shaders are probably aware of that. Note that this would be for software shaders as exposed by d3d, not a software implementation of hardware shaders. We currently run software shaders in hardware as well, but that imposes some limits on eg. the amount of available constants. This is unrelated to vertex blending.

Jan. 28, 2009

Re: D3D: Implement vertex blending in drawStridedSlow

by Claudio Ciccani

Il giorno mer, 28/01/2009 alle 12.34 +0100, Henri Verbeet ha scritto: > 2009/1/28 Paul TBBle Hampson <Paul.Hampson(a)pobox.com>: > > The only position I have on this is that this code exists and if the > > vertex shader code exists, I am unaware of it. The last comment I > > thought I read regarding vertex shaders was that they had produced a > > marked speed decrease (in my thread late last year about this issue) but > > on reflection, I may have conflated two things here. > > > Stefan implemented shader based fixed function vertex processing a > while ago. It does have performance issues, but I think it should be > possible to fix those. > > > You're suggesting in effect a specialised vertex shader that can just > > perform this matrix blending, rather than a full shader-based FFP, > > right? > > > It's not quite that easy, since we need to handle stuff like lighting > and texcoord generation as well. However, we do need shader based > fixed function vertex processing for things like specular alpha fog, > certain combinations of material tracking and drawing pre-transformed > vertices. My argument is essentially that if we're going to have > shader based fixed function vertex processing anyway, that's where we > should implement vertex blending, not as another drawStridedSlow() > fallback. Why not both? I mean, you could implement a hardware based vertex blending routine using a vertex shader and keep the software vertex blending routine in case vertex programs are not supported by underlying hardware. Actually this is what the patch does: fall back to software vertex blending when hardware vertex blending is not supported. > > > If I understand, the software-only wined3d backend is dead and gone, so > Slightly OT, but we might need to implement software shaders at some > point, although that has a rather low priority right now. Would be > interesting to see if we could use Mesa swrast for that. Implementing shaders in software would be terribly slow. Doing vertex blending in software instead doesn't have a relevant impact on the performance side. Honestly I think that we have been waiting too much for a fix to this bug. There are many games in the AppDB that could go "gold" with this patch. http://appdb.winehq.org/viewbugs.php?bug_id=6955

Jan. 28, 2009