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

Re: Worldbench?

by Aric Stewart

Very interesting. Here at CodeWeavers we have been very interested in benchmarking test and had very little luck finding ones that ran. We have a very very old one called officebench (which is no longer even avalable) that does VB scripting of office which was the only one we could get working. But it has been a while since we have tried them. I do not recall if we tested worldbench directly but since I cannot seem to find a demo and we do not own it i am guessing we did no try it. -aric Dan Kegel wrote: > It's hard to keep the benchmark programs straight. > > I ran into one called Worldbench today in > this review > http://www.washingtonpost.com/wp-dyn/content/article/2009/01/27/AR200901270… > and I see it's used quite a bit: > http://www.networkworld.com/reviews/2008/102908-hps-mini-1000-a-new.html > > It would be nice if we didn't see reviews like this: > http://www.pcworld.com/article/142724/200_linux_desktop_systems_are_no_barg… > which say > "Because these PCs run Linux, not Windows, we couldn't run our > WorldBench 6 Beta 2 test suite on them." > > It looks like Worldbench 6 has been stuck at beta 2 for a long time, > so people still reference Worldbench 5 scores. > More info: > > http://www.worldbench.com/ > http://www.pcworld.com/article/122812/how_we_test.html > http://www.pcworld.com/article/116888/pc_worlds_worldbench_50.html > > The benchmark costs $250. Has anybody here tried it on Wine? > - Dan > >

Jan. 28, 2009

Consistency in programs/winecfg/drivedetect.c

by Ben Klein

I just noticed my first patch got accepted, yay :) commit 8df74a0edb3304dfc26bd524327f9128f63de47f Author: Ben Klein <shacklein(a)gmail.com> Date: Wed Jan 21 21:02:12 2009 +1100 winecfg: Fix a typo in autodetect_drives. I also noticed someone removed the superfluous () around the expression in my patch. I included this for consistency in the file, and note that the same superfluous () appears on lines 244 and 272 in drivedetect.c in current git HEAD. Since this is not a functional thing in any way, and it doesn't matter on the compiler level whether it's (a == (b + c)) or (a == b + c), I'm not sure if it's worth me submitting a patch to correct the consistency. What's the prefered coding style for this situation? :)

Jan. 28, 2009

Re: server: Use kernel support for process affinity when available (try 2)

by Darragh Bailey

On Wed, Jan 28, 2009 at 02:46:00PM +0100, Alexandre Julliard wrote: > Juan Lang <juan.lang(a)gmail.com> writes: > > > Is this better? This trades a single call to sched_getaffinity per > > process to one every time the process affinity is queried. This seems > > safer, since a non-Wine process can also change a process's affinity, > > but it can have higher overhead. > > Yes, that's better. But AFAICT sched_get/setaffinity applies to a > single thread, not to the whole process. I believe that's only where you provide the thread id instead of the process id. -- Darragh "Nothing is foolproof to a sufficiently talented fool."

Jan. 28, 2009

Re: [twain_32 2/7] Add an interactive set of tests for a selected scanner.

by Jeremy White

> + rc = pDSM_Entry(appid, source, DG_CONTROL, DAT_CAPABILITY, MSG_GET, > &cap); Bletch. Forgot to add --attach. I'll resend the series. Sorry :-/. Cheers, Jeremy

Jan. 28, 2009

Re: server: Use kernel support for process affinity when available (try 2)

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > Is this better? This trades a single call to sched_getaffinity per > process to one every time the process affinity is queried. This seems > safer, since a non-Wine process can also change a process's affinity, > but it can have higher overhead. Yes, that's better. But AFAICT sched_get/setaffinity applies to a single thread, not to the whole process. -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2009

Worldbench?

by Dan Kegel

It's hard to keep the benchmark programs straight. I ran into one called Worldbench today in this review http://www.washingtonpost.com/wp-dyn/content/article/2009/01/27/AR200901270… and I see it's used quite a bit: http://www.networkworld.com/reviews/2008/102908-hps-mini-1000-a-new.html It would be nice if we didn't see reviews like this: http://www.pcworld.com/article/142724/200_linux_desktop_systems_are_no_barg… which say "Because these PCs run Linux, not Windows, we couldn't run our WorldBench 6 Beta 2 test suite on them." It looks like Worldbench 6 has been stuck at beta 2 for a long time, so people still reference Worldbench 5 scores. More info: http://www.worldbench.com/ http://www.pcworld.com/article/122812/how_we_test.html http://www.pcworld.com/article/116888/pc_worlds_worldbench_50.html The benchmark costs $250. Has anybody here tried it on Wine? - Dan

Jan. 28, 2009

Re: setupapi: implement pSetupInstallCatalog

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > + if (!CryptCATAdminAcquireContext(&admin,NULL,0)) > + { > + ERR("Could not acquire security context\n"); > + return ERROR_GEN_FAILURE; > + } > + if (!(cat = CryptCATAdminAddCatalog(admin,catalog,basename,0))) > + { > + ERR("Could not add catalog\n"); > + CryptCATAdminReleaseContext(admin, 0); > + return ERROR_GEN_FAILURE; You should return proper error codes based on the result of the called functions instead of a generic ERROR_GEN_FAILURE. -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2009

Should winetest retrieve msi log file on msi test failures?

by Dan Kegel

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

Jan. 28, 2009

Re: [1/2]reg.exe: Implement ADD for REG_SZ

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > + if (key_name[0]=='\\' && key_name[1]=='\\') > + { > + static const WCHAR remoteW[] = {'U','n','a','b','l','e',' ','t','o',' ','a','d','d',' ','k','e','y','s',' ','t','o',' ','r','e','m','o','t','e',' ','m','a','c','h','i','n','e',' ','%','s','\n',0}; This should go in the resources like the other messages. -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2009

Re: D3D: Implement vertex blending in drawStridedSlow

by Henri Verbeet

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

Jan. 28, 2009