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

Re: First complete test run passing on a Windows platform

by Reece Dunn

2009/1/30 Ge van Geldorp <ge(a)gse.nl>: >> From: Reece Dunn <msclrhd(a)googlemail.com> >> >> The Wine tests are now passing on a Windows XP machine >> > (http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group > _XP). > > Actually, that was not the first time. On 20 Jan an XP machine passed: > http://test.winehq.org/data/e9d8c9f572998054b1f9c386ea81a3570c65f2d2/#group_ > XP > And on 27 Jan a 2003 machine: > http://test.winehq.org/data/8f829034f3fe4da3e7adce2f4685e10ba2e2fe82/#group_ > 2003 Nice! Paul Vriens already mentioned this. Quite a few of the XP and 2003 machines have 1-3 failures, so this should mean that we get more Windows machines running at 0 failures. It will also mean that we could potentially use those machines to test the inconsistencies in the test runs, like Dan did with the Wine runs when setting up patchwatcher. This could be used to see exactly what fails when you change the DPI settings, for example. Or use a different theme. Or no theme. And other things that the user could change, doing them one at a time to get a clear "this is what changes when you do X". I suspect that the user32:sysparams tests would be complex to fix. >> Two of the other four only have 2 or 3 failures. >> >> The 2003 group has 3 machines with 1 failure each >> (urlmon:protocol on one, user32:menu on the others). > > I've sent a patch for the user32:menu failure a couple of weeks back but it > got blackholed > http://www.winehq.org/pipermail/wine-patches/2009-January/067483.html Do you know why you need to do a SetForegroundWindow there to make the tests succeed? Why is the input being sent to a different window? Why does it vary from platform-to-platform and machine-to-machine? When you understand that, you can then either give that evidence in the resubmit - which would give the patch a better chance at being accepted - or use it to improve the test another way that is more correct (if that is what the investigation shows). For example, are the tests failing because of DPI settings? Or has Windows changed the menu sizes such that the coordinates are wrong? > I won't be submitting test results next week but don't worry, I'll be > back... No problem. - Reece

Jan. 30, 2009

RE: First complete test run passing on a Windows platform

by Ge van Geldorp

> From: Reece Dunn <msclrhd(a)googlemail.com> > > The Wine tests are now passing on a Windows XP machine > (http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group _XP). Actually, that was not the first time. On 20 Jan an XP machine passed: http://test.winehq.org/data/e9d8c9f572998054b1f9c386ea81a3570c65f2d2/#group_ XP And on 27 Jan a 2003 machine: http://test.winehq.org/data/8f829034f3fe4da3e7adce2f4685e10ba2e2fe82/#group_ 2003 > Two of the other four only have 2 or 3 failures. > > The 2003 group has 3 machines with 1 failure each > (urlmon:protocol on one, user32:menu on the others). I've sent a patch for the user32:menu failure a couple of weeks back but it got blackholed http://www.winehq.org/pipermail/wine-patches/2009-January/067483.html I won't be submitting test results next week but don't worry, I'll be back... Ge.

Jan. 30, 2009

Re: D3D: Implement vertex blending in drawStridedSlow

by Paul TBBle Hampson

On Wed, Jan 28, 2009 at 04:44:44PM +0100, Henri Verbeet wrote: > 2009/1/28 Claudio Ciccani <klan(a)users.sf.net>: >> 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. The other problem that results in is that the D3DX functions that check for vertex blending support produce vertex buffers that Wine doesn't understand if that support is absent. This of course is actually an issue elsewhere (ie someone's gotta work out what the vertex element means and implement it, I guess) but it's the reason that the capabilities hack is floating around. According to a website I forget the location of, it's only the Intel on-board graphics cards that don't claim to be able to do vertex blending with 4 matrices under D3D9. I thought it was suggested here a while ago that DirectX9 itself or the card driver implements vertex blending if the card doesn't support it in hardware. I presume it does this with a shader. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

Jan. 30, 2009

Re: First complete test run passing on a Windows platform

by Paul Vriens

Reece Dunn wrote: > Hi, > > The Wine tests are now passing on a Windows XP machine > (http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group…) > Two of the other four only have 2 or 3 failures. > > The 2003 group has 3 machines with 1 failure each (urlmon:protocol on > one, user32:menu on the others). > > Congratulations to everyone involved fixing the tests! > > - Reece > > > It's not the first one though. We had one or two the last weeks. The biggest problem besides getting to 0 is consistency. Have a look at Alasdair's Wine box. It succeeded a few times but also has tests that intermittently fail. The same is true for a lot of Windows boxes. Nonetheless, we are in a far better position than a few months ago. And after Juan's batch it will be even better. Having a low rate of failures also lowers the burden for people to fix the last remaining ones instead of staring at a red page ;) Just some numbers for my W95, W98, NT4, W2K, W2K3 and Vista boxes: June-24-2008 : 21.7% test failures Aug-26-2008 : 19.7% Nov-14-2008 : 9.8% And yesterday : 6.1% -- Cheers, Paul.

Jan. 30, 2009

Re: Quick and dirty testcases for MS-DOS API?

by Dan Kegel

On Thu, Jan 29, 2009 at 9:40 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > The exception tests in ntdll is a nice example how to do that > without hurting readability and maintainability. Sure, it's doable, but after a while one's fingers begin to bleed. It all depends on how much code we're talking about, and how many people we expect to be able to write DOS testcases. Do you see any harm in using nasm? I can't imagine it would be hard to update our list of build dependencies, and if anybody doesn't have it for some reason, no harm done... - Dan

Jan. 30, 2009

Re: Quick and dirty testcases for MS-DOS API?

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: >>> Compiling DOS code to a .com file will produce a very small >>> executable, then embedding it into the test, put it in %TEMP%, >>> and exec should be trivial. No need for external tools IMO. >> >> I thought of that, it's tempting. >> >> But nasm is pretty common; I don't know that it would >> really be a burden to use it. And it would help testcase >> readability. > > and/or maintainability. Nobody likes having binary blobs > next to the source code they supposedly came from. The exception tests in ntdll is a nice example how to do that without hurting readability and maintainability. -- Dmitry.

Jan. 30, 2009

Re: Quick and dirty testcases for MS-DOS API?

by Dan Kegel

On Thu, Jan 29, 2009 at 9:34 PM, Dan Kegel <dank(a)kegel.com> wrote: >> Compiling DOS code to a .com file will produce a very small >> executable, then embedding it into the test, put it in %TEMP%, >> and exec should be trivial. No need for external tools IMO. > > I thought of that, it's tempting. > > But nasm is pretty common; I don't know that it would > really be a burden to use it. And it would help testcase > readability. and/or maintainability. Nobody likes having binary blobs next to the source code they supposedly came from.

Jan. 30, 2009

Re: Quick and dirty testcases for MS-DOS API?

by Dan Kegel

On Thu, Jan 29, 2009 at 9:20 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Compiling DOS code to a .com file will produce a very small > executable, then embedding it into the test, put it in %TEMP%, > and exec should be trivial. No need for external tools IMO. I thought of that, it's tempting. But nasm is pretty common; I don't know that it would really be a burden to use it. And it would help testcase readability.

Jan. 30, 2009

Re: report on obscure issues: running out of file handles with python under wine

by Damjan Jovanovic

On Fri, Jan 30, 2009 at 5:41 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Luke Kenneth Casson Leighton wrote: >> also note it's file descriptors not file handles > There are no such thing as "handle" in *NIX world. The only thing matter is > a file descriptor. But it's for files, directories, devices, etc. > > Wine takes care of all the handles internally (one of the main tasks for > wineserver). Wineserver has a really big handle limit: > #define MAX_HANDLE_ENTRIES 0x00ffffff > > I really doubt you overrunning that. And you would see messages in the > terminal if Wine can't allocate anymore FDs. > > Vitaliy. > > > Some parts of wine have smaller limits, eg. dlls/msvcrt/file.c: /* FIXME: this should be allocated dynamically */ #define MSVCRT_MAX_FILES 2048 Damjan

Jan. 30, 2009

Re: Quick and dirty testcases for MS-DOS API?

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: > Looking at http://bugs.winehq.org/show_bug.cgi?id=17181 > I get a feeling that we really need some > testcases to verify we conform to the 16 bit MS-DOS > API. Yeah, even though 16 bit is on the way out, > there's still some use for a few win16 programs, and > they use MS-DOS for file I/O. > > We could merge in http://win16test.googlecode.com, > but that requires the Watcom C compiler, and > "apt-cache search watcom" still comes up empty > (unless you're on Ark Linux, see > http://www.openwatcom.org/index.php/Installing_Open_Watcom_on_Linux ) > And the Linux build had problems building DOS apps > last time I tried anyway. > > But "apt-get install nasm" works great, so let's > use it to run just a few crucial testcases, in > particular, the one that keeps DOS apps from > recursively deleting directories. Compiling DOS code to a .com file will produce a very small executable, then embedding it into the test, put it in %TEMP%, and exec should be trivial. No need for external tools IMO. -- Dmitry.

Jan. 30, 2009