wine-devel May 2010

wine-devel@winehq.org

115 participants
288 discussions

today's performance results
by Dan Kegel 11 May '10

11 May '10

http://kegel.com/wine/yagmarkdata/wine-1.1.44-19-vs-wine-1.1.44-72.txt shows yesterday's wine's performance compared to today's. Highlights: Comparing wine-1.1.44-19 with wine-1.1.44-72 benchmark_variable wine-1.1.44-19 wine-1.1.44-72 ratio 3dmark06_3DMark_Score 3377.00 3388.00 1.00 3dmark2000_3DMark_Result 16662.00 16917.00 1.02 3dmark2001_3DMark_Score 15691.00 17633.00 1.12 heaven2_d3d9_FPS 9.31 11.08 1.19 heaven2_gl_FPS 16.12 16.21 1.01 Golly, looks like http://www.winehq.org/pipermail/wine-cvs/2010-May/066833.html was a win. Here are a few notes about the raw results. A couple benchmarks (really short ones?) seem to have strongly bimodal distributions on Wine. For instance, here are ten measurements on each OS of 3dmark06_CPU2_Red_Valley: wine-1.1.44-19 1.33 1.36 1.36 1.36 1.37 1.37 1.37 1.37 1.37 1.37 wine-1.1.44-72 1.30 1.31 1.31 1.31 1.31 1.32 1.32 1.32 1.32 1.38 Vista 1.39 1.39 1.39 1.39 1.39 1.39 1.39 1.39 1.39 1.39 For some reason, today's wine usually had the slow result, whereas yesterday it usually had the fast result. Vista didn't suffer from this, and was slightly faster, too. Why does Wine return a slow result sometimes? 3dmark2000_Game_1_Helicopter_High_Detail was quite variable under Wine (and slightly better today), but hardly varied at all on Vista: wine-1.1.44-19 133.70 133.90 141.60 145.00 145.40 151.60 159.30 161.80 164.40 173.60 wine-1.1.44-72 139.50 144.70 154.10 157.40 157.90 162.40 170.50 178.80 180.80 198.60 Vista 281.60 282.50 282.90 283.20 283.40 283.60 283.70 283.80 284.00 284.50 What can explain such variability? heaven2_d3d9_FPS, on the other hand, didn't vary much on Wine - and was quite a bit better today: wine-1.1.44-19 9.23 9.28 9.30 9.30 9.30 9.31 9.31 9.32 9.32 9.32 wine-1.1.44-72 11.05 11.07 11.07 11.07 11.08 11.08 11.08 11.09 11.10 11.10 Vista 18.37 18.37 18.38 18.38 18.38 18.38 18.38 18.38 18.38 18.38 Perhaps I should strip down my system and run fvwm95 rather than Gnome, etc., to see if I can reduce the noise a bit more. - Dan

3 4

Re: [6/6] msi: Set the SourceDir property to the registered source if the product is installed.
by testbot＠testbot.winehq.org 11 May '10

11 May '10

1 0

Re: [2/6] msi: Add more patch registration tests.
by Paul Vriens 11 May '10

11 May '10

On 05/11/2010 02:02 PM, Hans Leidekker wrote: > --- > dlls/msi/tests/patch.c | 23 +++++++++++++++++++++-- > 1 files changed, 21 insertions(+), 2 deletions(-) > > diff --git a/dlls/msi/tests/patch.c b/dlls/msi/tests/patch.c > index ad581d1..a835e1d 100644 > --- a/dlls/msi/tests/patch.c > +++ b/dlls/msi/tests/patch.c > @@ -33,6 +33,8 @@ > static UINT (WINAPI *pMsiApplyPatchA)( LPCSTR, LPCSTR, INSTALLTYPE, LPCSTR ); > static UINT (WINAPI *pMsiGetPatchInfoExA)( LPCSTR, LPCSTR, LPCSTR, MSIINSTALLCONTEXT, > LPCSTR, LPSTR, DWORD * ); > +static UINT (WINAPI *pMsiEnumPatchesExA)( LPCSTR, LPCSTR, DWORD, DWORD, DWORD, LPSTR, > + LPSTR, MSIINSTALLCONTEXT *, LPSTR, LPDWORD ); > > static const char *msifile = "winetest-patch.msi"; > static const char *mspfile = "winetest-patch.msp"; > @@ -143,6 +145,7 @@ static void init_function_pointers( void ) > > GET_PROC( hmsi, MsiApplyPatchA ); > GET_PROC( hmsi, MsiGetPatchInfoExA ); > + GET_PROC( hmsi, MsiEnumPatchesExA ); > #undef GET_PROC > } > > @@ -988,9 +991,9 @@ static void test_system_tables( void ) > static void test_patch_registration( void ) > { > UINT r, size; > - char buffer[MAX_PATH]; > + char buffer[MAX_PATH], patch_code[39]; > > - if (!pMsiApplyPatchA || !pMsiGetPatchInfoExA) > + if (!pMsiApplyPatchA || !pMsiGetPatchInfoExA || !pMsiEnumPatchesExA) > { > win_skip("required functions not available\n"); > return; > @@ -1043,6 +1046,22 @@ static void test_patch_registration( void ) > ok( r == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %u\n", r ); > ok( !buffer[0], "got %s\n", buffer ); > > + r = MsiEnumPatchesExA( "{913B8D18-FBB6-4CAC-A239-C74C11E3FA74}", > + NULL, MSIINSTALLCONTEXT_USERUNMANAGED, MSIPATCHSTATE_APPLIED, > + 0, patch_code, NULL, NULL, NULL, NULL ); > + ok( r == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %u\n", r ); > + ok( !strcmp( patch_code, "{0F96CDC0-4CDF-4304-B283-7B9264889EF7}" ), "wrong patch code\n" ); > + > + r = MsiEnumPatchesExA( "{913B8D18-FBB6-4CAC-A239-C74C11E3FA74}", > + NULL, MSIINSTALLCONTEXT_MACHINE, MSIPATCHSTATE_APPLIED, > + 0, patch_code, NULL, NULL, NULL, NULL ); > + ok( r == ERROR_NO_MORE_ITEMS, "expected ERROR_NO_MORE_ITEMS, got %u\n", r ); > + > + r = MsiEnumPatchesExA( "{913B8D18-FBB6-4CAC-A239-C74C11E3FA74}", > + NULL, MSIINSTALLCONTEXT_USERMANAGED, MSIPATCHSTATE_APPLIED, > + 0, patch_code, NULL, NULL, NULL, NULL ); > + ok( r == ERROR_NO_MORE_ITEMS, "expected ERROR_NO_MORE_ITEMS, got %u\n", r ); > + > r = MsiInstallProductA( msifile, "REMOVE=ALL" ); > ok( r == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %u\n", r ); > You forgot to actually use pMsiEnumPatchesExA in some of these calls (hence the WTB failures). -- Cheers, Paul.

1 0

Re: [3/6] msi: Add a test to show that the InstallSource property is unchanged after an upgrade.
by testbot＠testbot.winehq.org 11 May '10

11 May '10

1 0

Re: [2/6] msi: Add more patch registration tests.
by testbot＠testbot.winehq.org 11 May '10

11 May '10

1 0

Re: kernel32/tests: Remove variable ret which is not really used from load_blackbox. (RESEND)
by testbot＠testbot.winehq.org 11 May '10

11 May '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=1969 Your paranoid android. === W7PROX64 (64 bit debugger) === debugger.c:299: Test failed: Timed out waiting for the child to crash debugger.c:313: Test failed: wrong exit code : 00000103 debugger.c:324: Test failed: Timed out waiting for the debugger debugger.c:146: Test failed: wrong size for 'C:\Users\winetest\AppData\Local\Temp\wt5825.tmp': read=0 debugger.c:329: Test failed: wrong debugger argument count: -28562032 debugger.c:330: Test failed: the child and debugged pids don't match: 660 != 2046 debugger.c:299: Test failed: Timed out waiting for the child to crash debugger.c:306: Test failed: wrong exit code : 00000103 debugger.c:324: Test failed: Timed out waiting for the debugger debugger.c:146: Test failed: wrong size for 'C:\Users\winetest\AppData\Local\Temp\wt2D25.tmp': read=0 debugger.c:329: Test failed: wrong debugger argument count: -28562032 debugger.c:330: Test failed: the child and debugged pids don't match: 1368 != 2046 Timeout

2 1

Re: Remove variable hFont which is not really used from MF_PlayMetaFile. (RESEND)
by Alexandre Julliard 11 May '10

11 May '10

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > --- > dlls/gdi32/metafile.c | 2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) It seems pretty clear that it should be used, not removed. -- Alexandre Julliard julliard(a)winehq.org

2 1

On Ubuntu Lucid? Add the Wine PPA!
by David Gerard 10 May '10

10 May '10

I updated to Lucid in early March and have only just realised I haven't been getting Wine updates. Did you forget too? Then, per the upgrades page: sudo add-apt-repository ppa:ubuntu-wine/ppa - then update and upgrade. Much nicer! - d.

1 0

RFC on console management
by Eric Pouech 10 May '10

10 May '10

There are a couple of shortcomings in our current console implementation. To name a few: - the "bare console handles" concept has very short limitations (see bug reports #5541, or #13189). Globally, bare handles are actually handles to files, whereas lots of programs expect them to behave like console handles. Among the known shortcomings: + A1: GetFileType() returns wrong value, + A2: the console functions should return correct/default values, starting with codepage (in your xterm locale if UTF.8 for example, cmd output is bogus). + A3: no line edition is supported on bare handles There are also issues with the wineconsole back-ends: - B1: wineconsole --backend=curses mypgm.exe doesn't support the redirection of unix default handles (ie. wineconsole --backend=curses mypgm.exe > foo sends all ANSI escapes to the foo file, which isn't what we expect. - B2: in Windows, a GUI program doesn't inherit the console of its parent (it only does if it's a CUI program) - B3: when being nasty, one could create several wineconsole instances for the same TTY, whereas popular wisdom would claim that one is (more than) sufficient - B4: console allocation and inheritance is not properly managed. Let's take the following example: + we have two exes (Cui and CuiChild), CuiChild being started by Cui. Cui is started from command line. + Cui does, in this order: FreeConsole AllocConsole CreateProcess("CuiChild") ExitProcess + AllocConsole spawns an instance of wineconsole, inheriting the Unix fd:s from Cui. + CuiChild inherits the wine console from it's parent + when Cui dies, it also, from the Unix standpoint detaches from the Unix console, and wineconsole loses access to the TTY as it's Unix parent has died. And we lose all input/output for all apps tied to this wineconsole. - B5: job control. We poorly interact with unix console job control I'd like to get feedback on the best way to go in order to put console management on a reliable architecture. Scenario I (aka Client side) ---------------------------- Create simple wineserver objects (ie not linked to wineconsole) for bare console handles. All the management would be done in kernel32, by distinguishing bare console handles from wineserver console handles. Scenario II (aka Wineconsole side) ---------------------------------- Extend the current console objects in wineserver and wineconsole to support a line oriented mode (instead of current mode which takes control of the full screen for both curses and user backends). Comparison (for each criteria, scenarios are ranked best to worse): Size of changes: I,II ScI will require less changes Maintainability: II,I - for ScII, in kernel32, we only deal with console objects, we all behave the same - for ScII all term/termcap support is centralized in wineconsole (A3 would require term/termcap to get the correct keys) Speed: I,II - ScII will require app <=> wineserver <=> wineconsole messages in order to work (ScI will read all fd:s directly). ScII could be enhanced by having messages directly managed between app and wineconsole and bypassing wineserver, but still would be slower Inheritance: II,I - all required mechanisms (except B4) would be similar - for B4, ScI will be hard to implement, as we don't have an app that will keep the control on the unix terminal until all children have died. The most viable solutions (in the wording of B4 above): + don't exit Cui until all its children, grand children... have died. Possible to do, but we may want at some point to hide this running (Unix) app from the list of running (Windows) app, and this will be tricky + create a (Unix) wrapper app that will be kept open until all children have died. Possible but will hinder a lot the tracking/debugging tools (gdb, valgrind) - it may be a bit simpler for ScII, as wineconsole could play the role of the controling app (but with potentially the same limitations) Functionalities: II,I - ScII will ease the job control integration, as wineconsole would gain control of the unix terminal, and hence convert properly the unix events to the windows one. I'd rather favor ScII, but the differences are not that big, so your comments are welcome. -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 2

Re: Improve error handling in scmdatabase_autostart_services. (RESEND)
by Alexandre Julliard 10 May '10

10 May '10

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > I noticed that we are not using the error code coming from service_start, > and indeed there was a FIXME there already. Would it make sense to handle > this (at least) somehow like the patch below? > > If preferred, I could also yank the err variable, but I figured you'd > prefer the error handling. (Or is there a mistake I made when adding > that handling?) Printing an ERR is not error handling. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
18
19
20
21
22
23
24
...
29
Older →

Jump to page:

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 May 2010