wine-devel February 2013

wine-devel@winehq.org

62 participants
126 discussions

Re: advapi32: Report administrator ownership by default for registry objects (try 3).
by Alexandre Julliard 19 Feb '13

19 Feb '13

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > The attached patch fixes an issue where the Opera installer expects > registry keys to return ownership information (Bug #32904), concluding > the cleanup of [Get|Set]NamedSecurityInfo. This patch addresses the > issue by ensuring that NULL owner and group information is never > returned for registry keys and instead returns the Administrators SID > (S-1-5-32-544) when this information is unavailable, which is > sufficient to keep the Opera installer from encountering an error. > The included test shows that this behavior is the case for system keys > on Windows, which returns the Administrators SID for system registry > keys (such as HKLM\Software). Surely this is not specific to GetNamedSecurityInfo. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [14/14] gdiplus: Reimplement GdipDrawPath.
by Vincent Povirk 19 Feb '13

19 Feb '13

> Please don't apply this [14/14] patch, it causes a test failure. I'm sending > it to show how this is going to look like eventually. Yeah, GdipWidenPath isn't good enough for this yet. But I agree this is the way to go, and the rest of the series looks good.

2 2

Re: [PATCH 5/8] vbscript: Added RegExp.Execute tests
by Marvin 19 Feb '13

19 Feb '13

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=24454 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Re: [PATCH 7/8] vbscript: Added tests for invalid parameters in regular expression functions
by Marvin 19 Feb '13

19 Feb '13

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=24455 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Re: [PATCH 5/8] vbscript: Added RegExp.Execute tests
by Marvin 19 Feb '13

19 Feb '13

1 0

IE 6 related urlmon:protocol failures
by Francois Gouget 18 Feb '13

18 Feb '13

I have investigated the following test failure on the new WineTestBot: urlmon: protocol.c:1051: Test failed: hrResult = 800401e4, expected: 00000000 protocol.c:1056: Test failed: dwError == ERROR_SUCCESS protocol.c:613: Test failed: expected ReportData The results from test.winehq.org show that they only happen on systems that have urlmon.dll version 6.0, which I guess corresponds to Internet Explorer 6.0. More specifically: * The test detects systems that have Internet Explorer 5.5 or older, based on missing functions, declares too old and skips the tests: 5.0.3700.6705 wtb-w2kassp4 5.0.3888.1400 wtb-w2kprosp4 5.50.4807.2300 fg-win2000-ie55 * The test runs and fails on these systems: 6.0.2800.1649 fg-win2000-up1 6.0.2800.1649 fg-win2000-uplast 6.0.2900.3562 fg-winxp-2sp 6.0.2900.3698 wtb-wxpmce 6.0.2900.6049 wtb-wxphmnlsp3 * The test runs and succeeds on systems that have urlmon 7.0 or greater: 7.0.6000.16850 fg-winxp-2spie7 7.0.6000.16850 fg-winxp-3sp 8.0.6001.18806 fg-winxp-3spie8 8.0.6001.19100 fg-winxp-last So I will be applying the latest updates to the new TestBot's Windows XP VM and that should solve the issue in that case. However I think the test should still not fail. So I'm looking for a volunteer to either get the test to succeed with urlmon 6.0, or find a way to detect it and skip these three tests. -- Francois Gouget <fgouget(a)codeweavers.com>

2 4

Re: [PATCH 1/2] wininet: Address string should never be converted to UNICODE in status notifications
by Marvin 18 Feb '13

18 Feb '13

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=24441 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Re: msi: Don't ignore failure to remove an existing product.
by Alexandre Julliard 18 Feb '13

18 Feb '13

Hans Leidekker <hans(a)codeweavers.com> writes: > --- > dlls/msi/action.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) It fails here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so action.c && touch action.ok action.c:6397: Test failed: Expected ERROR_SUCCESS, got 2 action.c:6400: Test failed: Expected ERROR_SUCCESS, got 2 make[1]: *** [action.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

winmm: More compatible waveIn/Out[Un]Prepare WHDR_* flag handling.
by Joerg-Cyril.Hoehle＠t-systems.com 18 Feb '13

18 Feb '13

Hi, One thing to note is a slight change when Prepare is called twice in a row. When the ACM is used, the former Wine code would prepare the ACM again, leaking the memory of the previous preparation. Now that code is by-passed as the header is prepared exactly once, the first time. What if the app changes dwBufferLength in between? We don't know what exactly native does. My tests only show that *some* code is by-passed, because when WHDR_PREPARE is found already set, the other flags are not repeatedly cleared. All calls return NOERROR. The 16 bit code has a comment http://source.winehq.org/source/dlls/mmsystem.dll16/message16.c#L430 > /* dwBufferLength can be reduced between prepare & write */ > if (... && wh32->dwBufferLength < wh16->dwBufferLength) { I've checked neither - what native does in that case when the ACM is involved, nor - how Wine drives the ACM in that case. It's reasonable to assume that only dwBufferLength at the time of waveOutWrite should be relevant. Let's hope that dwBufferLength from the time of Prepare doesn't matter in Wine's 32 bit ACM. Regards, Jörg Höhle

1 0

Re: [PATCH 1/2] wined3d: Make (wined3d_)surface_depth_blt_fbo handle locations other than SFLAG_INTEXTURE.
by Henri Verbeet 18 Feb '13

18 Feb '13

On 17 February 2013 18:10, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -6168,18 +6172,10 @@ HRESULT surface_load_location(struct wined3d_surface *surface, DWORD location, c > > if (surface->resource.usage & WINED3DUSAGE_DEPTHSTENCIL) > { > - if (location == SFLAG_INTEXTURE) > - { > - struct wined3d_context *context = context_acquire(device, NULL); > - surface_load_ds_location(surface, context, location); > - context_release(context); > - return WINED3D_OK; > - } > - else > - { > - FIXME("Unimplemented location %s for depth/stencil buffers.\n", debug_surflocation(location)); > - return WINED3DERR_INVALIDCALL; > - } > + struct wined3d_context *context = context_acquire(device, NULL); > + surface_load_ds_location(surface, context, location); > + context_release(context); > + return WINED3D_OK; > } This is probably wrong (and the original code is probably questionable too), surface_load_ds_location() is only really meant for onscreen <-> offscreen blits. The original code is meant for the case where AlwaysOffscreen is disabled and a depth stencil is used as texture. The implication there is that the only possible locations are SFLAG_INTEXTURE and SFLAG_INDRAWABLE, it doesn't really work with multisampling. Fortunately you can't directly texture from multisampled depth stencil surfaces either. In principle we could make surface_load_ds_location() the generic function for depth / stencil location transfers, but currently it isn't. If you're hitting it with the RESZ code it probably only works by accident.

2 2

← Newer
1
2
3
4
5
6
7
8
9
...
13
Older →

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 February 2013