wine-devel December 2010

wine-devel@winehq.org

83 participants
219 discussions

Start a nNew thread

Re: user32/tests: skip more input tests on 98 and ME
by Marvin 03 Dec '10

03 Dec '10

1 0

Re: d3d8/d3d9: fix compiler warnings on non x86/x86_64
by Marvin 03 Dec '10

03 Dec '10

1 0

Re: d3d8/d3d9: fix compiler warnings on non x86/x86_64
by Marvin 03 Dec '10

03 Dec '10

1 0

Re: Death to win9x?
by James Mckenzie 02 Dec '10

02 Dec '10

Austin English <austinenglish(a)gmail.com> wrote: > >On Thu, Dec 2, 2010 at 8:00 PM, K.King <k.king177(a)ntlworld.com> wrote: >> <<< >> That's not useful. The whole point is that we don't want to spend the >> effort required to keep the tests error-free on platforms that we don't >> care about. That makes it easier to write tests for platforms that >> actually matter, which is a more productive use of everybody's time. >>>>> >> You may not care, but I know a number of people who do. >> For some running the older software is more important, of interest, or use. > >A majority of that effort is rewriting tests to make win9x happy, not >rewriting behavior to fix win9x applications. > >Few people (if any) want to intentionally break win9x applications, >but spending a large amount of developer effort to maintain the tests >there isn't really the best investment, when it could instead be spent >fixing real bugs. > This I do agree with. I'm working on tests for richedit and the expected reaction of the Win9x version is much different than the reaction of the WindowsXP version. I could drop the Win9x tests and concentrate on Windows 2000 and higher. Would this be a good course of action? James McKenzie

1 0

Re: Death to win9x?
by K.King 02 Dec '10

02 Dec '10

<<< That's not useful. The whole point is that we don't want to spend the effort required to keep the tests error-free on platforms that we don't care about. That makes it easier to write tests for platforms that actually matter, which is a more productive use of everybody's time. >>> You may not care, but I know a number of people who do. For some running the older software is more important, of interest, or use.

2 1

Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.
by Alexandre Julliard 02 Dec '10

02 Dec '10

Jacek Caban <jacek(a)codeweavers.com> writes: > I know that this patch is the most questionable. Gecko expects us to > give it a DLL named np*.dll, so we can't do it in mshtml. Also, this > plugin will be visible to other NPAPI-based browsers running in Wine > (that's a matter of change in the next Gecko release), so it's good > that it's a tiny wrapper that fails to load if mshtml is not loaded > (meaning that we're not running in Wine Gecko). This prevents the dll registration code from running, since mshtml is not loaded at that point. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [1/2] wininet: Use proper error code define instead of its value
by Alexandre Julliard 02 Dec '10

02 Dec '10

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -270,7 +270,7 @@ static DWORD netconn_verify_cert(PCCERT_CONTEXT cert, HCERTSTORE store, > else if (chain->TrustStatus.dwErrorStatus & ~supportedErrors) > err = ERROR_INTERNET_SEC_INVALID_CERT; > } > - if (!err) > + if (err == ERROR_SUCCESS) There's no reason to change this. 0 meaning success is a common convention, and at least as clear as using an error code for no error. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wineps.drv: return error if unable to select a builtin font
by Alexandre Julliard 02 Dec '10

02 Dec '10

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -191,6 +191,12 @@ BOOL PSDRV_SelectBuiltinFont(PSDRV_PDEVICE *physDev, HFONT hfont, > if(!family) > family = physDev->pi->Fonts; > > + if (!family) > + { > + ERR("Unable to get any font for printer\n"); > + return FALSE; > + } If this is something that can legitimately happen it should be handled correctly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [4/4] shdocvw: In PersistFile_Save, output the Icon Path and Icon Index properties
by Damjan Jovanovic 02 Dec '10

02 Dec '10

On Thu, Dec 2, 2010 at 5:39 AM, Andrew Bogott <Andrew(a)codeweavers.com> wrote: > This gets Icon Path and Icon Index written out to .url files if they've been > set previously. > > > > I think you leak a reference to pPropStgRead here. Nice patch set otherwise :-) Damjan

1 0

Re: [2/2] msi: Clear last error on success in MsiQueryFeatureState and MsiQueryProductState.
by Marvin 02 Dec '10

02 Dec '10

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=7392 Your paranoid android. === W2KPROSP4 (32 bit msi) === msi.c:618: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:633: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:646: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:666: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:677: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:695: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:705: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:716: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:727: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:736: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:972: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:979: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:994: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1004: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1028: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1037: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1046: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1055: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1064: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1086: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1095: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1104: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1114: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1124: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1134: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1144: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1154: Test failed: expected ERROR_SUCCESS, got 1008

1 0

poor Wine performance creating fat dialogs
by Andreas Pflug 02 Dec '10

02 Dec '10

I'm investigating running a commercial ERP system under Wine (only binary available). It mostly works, but creating the main dialogs for item, customer and such will need around 25 seconds, while running on Wxx it takes 2-3 seconds. After that, there's no serious performance impact working on these dialogs. The dialogs contain a lot of controls, like 500 or so each, so I suspect that's what makes things slow. I'm willing to investigate this in the wine sources, if it makes sense. So before I start I'd like to know if there are known or suspected inefficient code regions that might cause the problem? Maybe some win<->x11 translation tables that degrade with 1000+ windows? Or has this been observed before, and the problem is outside of wine's scope? Any hint appreciated. Regards, Andreas

3 3

Re: [PATCH] shell32/tests: Fixed SHPathPrepareForWriteW tests on Asian platforms.
by Marvin 02 Dec '10

02 Dec '10

1 0

Death to win9x?
by Dan Kegel 01 Dec '10

01 Dec '10

I'm all for removing stuff that nobody needs anymore. I imagine there are still a few popular older apps that will force us to keep some old win9x behaviors around, though, so we probably won't be able to remove the 'emulate win98' choice from winecfg any time soon.

3 3

Re: [PATCH 4/5] quartz: Add quality control to sound renderer
by Alexandre Julliard 01 Dec '10

01 Dec '10

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > --- > dlls/quartz/dsoundrender.c | 29 +++++++++++++++++++++++++++++ > 1 files changed, 29 insertions(+), 0 deletions(-) It breaks here: ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so dsoundrender.c && touch dsoundrender.ok dsoundrender.c:153: Test succeeded inside todo block: IUnknown_QueryInterface returned 0 dsoundrender.c:153: Test succeeded inside todo block: Pointer is NULL dsoundrender.c:154: Test succeeded inside todo block: IUnknown_Release should return 1, got 1 make: *** [dsoundrender.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Stopping Win9x testing
by Greg Geldorp 01 Dec '10

01 Dec '10

> From: Wolfram Sang > > > I'll mark the Win9x VMs offline when there's nothing queued to run on them. > > Then in a weeks time I can delete them after all jobs referring to them > > have been retired/deleted (referential integrity in the database). > > That means they even won't be available then for some specific corner-case > tests (in which they are selected manually)? Hmm, is there much overhead > involved to keep them "just in case"? Yeah, that might be a good idea. Currently VMs are divided into a "Base" and a "Extra" group, I can add a "Retired" group to hold the Win9x VMs. VMs in this group wouldn't participate in the daily winetest run, wouldn't be used for verification of wine-patches submissions and wouldn't be selected by default when manually submitting a job. However, they would be available for selection if you click "Show all VMs" button when submitting a job. This will require some changes to the code, but nothing major. I'll look into it. Greg.

1 0

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)
by Alexandre Julliard 01 Dec '10

01 Dec '10

Peter Urbanec <winehq.org(a)urbanec.net> writes: > +static BOOL load_funcs(void *handle) > +{ > +#define LOAD_FUNCPTR(f) if((p##f = (void*)wine_dlsym(handle, #f, NULL, 0)) == NULL) \ > + { ERR("Can not find " #f "\n"); return FALSE; } else { TRACE("Loaded function " #f "\n"); }; > + > + /* Platform API */ > + LOAD_FUNCPTR(clGetPlatformIDs) > + LOAD_FUNCPTR(clGetPlatformInfo) > + > + /* Device APIs */ > + LOAD_FUNCPTR(clGetDeviceIDs) > + LOAD_FUNCPTR(clGetDeviceInfo) Why are you loading everything dynamically instead of simply linking to it? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)
by Roderick Colenbrander 01 Dec '10

01 Dec '10

It looks fine to me, but I'm worried whether it can work properly in the end. A few months ago I worked on Cuda support for something (I implemented nvcuda.dll which is what cuda runtime libraries like cudart or physx are using). Certain lowlevel nvcuda applications worked, but more fancy applications didn't. I had some contact with Nvidia about it and it was not possible to support Cuda without assistance on their side. OpenCL is a little different of course, but I fear that not all OpenCL implementations will like wrapping. What OpenCL applications have you tried so far? The Nvidia GPU Computing SDK (or whatever it was called) has a ton of samples for both Cuda and OpenCL. Do all their OpenCL samples work? Roderick On Mon, Nov 29, 2010 at 2:39 PM, Peter Urbanec <winehq.org(a)urbanec.net> wrote: > Resending because previous patch was mangled by Thunderbird. > > --- > dlls/opencl/opencl.c | 1142 > +++++++++++++++++++++++++++++++++++++++++++++++ > dlls/opencl/opencl.spec | 159 ++++--- > 2 files changed, 1232 insertions(+), 69 deletions(-) > > > > > >

2 1

Re: include: Fix error logic
by Alexandre Julliard 01 Dec '10

01 Dec '10

André Hentschel <nerv(a)dawncrow.de> writes: > The file is nearly always used with one of both, so "or" makes no sense. > Also if you have a look through tchar.h you see it catches all cases, > but not the case where both are defined It doesn't make any sense to define both. -- Alexandre Julliard julliard(a)winehq.org

1 0

Stopping Win9x testing
by Greg Geldorp 01 Dec '10

01 Dec '10

> From: Paul Vriens > > On 11/30/2010 04:41 PM, Alexandre Julliard wrote: > > The value of running tests on Win9x these days is certainly questionable. > > We don't try to emulate the Win9x behavior anyway, except in a very few > > cases (which most likely don't have tests...) so it only serves to > > document historical behavior that nobody cares about any longer. > > > > I wouldn't be opposed to switching off win9x test runs and getting rid > > of the corresponding broken(). > > So the first thing is a patch to winetest.exe and the winetest website > and at the same time tell Greg to exclude it from 'patchwatcher' and the > batch running of the (almost) daily winetests. I'll mark the Win9x VMs offline when there's nothing queued to run on them. Then in a weeks time I can delete them after all jobs referring to them have been retired/deleted (referential integrity in the database). So for the next week you'll see a red dot with "One or more VMs are offline" on the testbot main page, don't be alarmed by this. Greg.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2010