wine-devel November 2011

wine-devel@winehq.org

59 participants
156 discussions

Re: [PATCH 2/6] appwiz.cpl: Add Catalan translation
by André Hentschel 30 Nov '11

30 Nov '11

Am 30.11.2011 08:39, schrieb Alex Henrie: > --- > dlls/appwiz.cpl/Ca.rc | 85 +++++++++++++++++++++++++++++++++++++++++++ > dlls/appwiz.cpl/Makefile.in | 1 + > 2 files changed, 86 insertions(+), 0 deletions(-) > create mode 100644 dlls/appwiz.cpl/Ca.rc > > diff --git a/dlls/appwiz.cpl/Ca.rc b/dlls/appwiz.cpl/Ca.rc > new file mode 100644 > index 0000000..e411bf0 > --- /dev/null > +++ b/dlls/appwiz.cpl/Ca.rc > @@ -0,0 +1,85 @@ > +/* > +* Add/Remove Programs English resources > +* > +* Copyright 2001-2002, 2008 Owen Rudge > +* Copyright 2005-2006 Jacek Caban really? :) -- Best Regards, André Hentschel

1 0

Re: [PATCH 1/5] wined3d: Don't apply fixups to converted surfaces.
by Stefan Dösinger 30 Nov '11

30 Nov '11

Am Donnerstag, 24. November 2011, 22:52:32 schrieb Henri Verbeet: > + if (surface->flags & SFLAG_CONVERTED) > + { > + ENTER_GL(); > + glEnable(textype); > + checkGLcall("glEnable(textype)"); > + LEAVE_GL(); > + return WINED3D_OK; > + } I don't think this is correct. E.g. signed formats without GL_NV_texture_shader have load time and read time fixups and both have to be applied. What exactly are you trying to fix? I assume it is something about P8 blits, but P8->P8 blits don't enter the ARB blitting code(due to the dest fixup check), and I don't know of any app that uses P8->RGB or SNORM->UNORM blits. Stefan

3 16

Re: [PATCH 3/5] ddraw: Keep the primary surface mapped at the same address for early ddraw versions.
by Stefan Dösinger 30 Nov '11

30 Nov '11

Am Mittwoch, 30. November 2011, 06:01:46 schrieb Henri Verbeet: > + if (flags & WINED3D_SURFACE_PIN_SYSMEM) > + surface->flags |= SFLAG_PIN_SYSMEM; The address will still change when GetDC is called. Is this intentional? > + /* Some applications assume that the primary surface will always be > + * mapped at the same address. Some of those also assume that this > + * address is valid even when the surface isn't mapped, and that > + * updates done this way will be visible on the screen. The game Nox > + * is such an application. */ I've seen ddraw applications that create systemmem primaries, and we currently allow this. What surface caps does Nox use? Does Nox expect us to magically pick up the new data, or does it map and unmap the surface to get the data onto the screen?

1 0

Re: [PATCH 2/4] jscript: Use bytecode for delete on array expression implementation
by Marvin 30 Nov '11

30 Nov '11

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=15711 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/5] ddraw: Resize the swapchain window on mode changes in exclusive mode.
by Marvin 30 Nov '11

30 Nov '11

2 1

Re: [PATCH 5/5] user32: Implement GetRawInputDeviceInfoW completely on user side. (resend)
by Marvin 29 Nov '11

29 Nov '11

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=15692 Your paranoid android. === WVISTAADM (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W2K8SE (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PRO (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (32 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (64 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (64 bit input) === input.c:1787: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737

1 0

Re: [PATCH 3/5] user32: Implement GetRawInputDeviceList completely on user side. (resend)
by Marvin 29 Nov '11

29 Nov '11

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=15691 Your paranoid android. === WVISTAADM (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W2K8SE (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PRO (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (32 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (64 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (64 bit input) === input.c:1794: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737

1 0

Re: [PATCH 2/5] user32: Add initial input parameter validations to RawInput functions. (resend)
by Marvin 29 Nov '11

29 Nov '11

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=15690 Your paranoid android. === WVISTAADM (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W2K8SE (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PRO (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (32 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (64 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (64 bit input) === input.c:1797: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737

1 0

Re: [PATCH 1/5] user32/tests: Initial tests for RawInput functions. (try 2)
by Marvin 29 Nov '11

29 Nov '11

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=15689 Your paranoid android. === WVISTAADM (32 bit input) === input.c:1803: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W2K8SE (32 bit input) === input.c:1803: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PRO (32 bit input) === input.c:1803: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (32 bit input) === input.c:1803: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (32 bit input) === input.c:1803: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === W7PROX64 (64 bit input) === input.c:1803: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737 === TEST64_W7SP1 (64 bit input) === input.c:1803: Test failed: GetRawInputDeviceInfoA should have failed: 32, 32, -559038737

1 0

Re: user32: Fix 64-bit 'msg' test hang in test_timers (try 2).
by Dmitry Timoshkov 28 Nov '11

28 Nov '11

"Erich E. Hoover" <ehoover(a)mines.edu> wrote: > The attached patch changes the test_timers() crash function to use > RtlRaiseException (if available) rather than attempting to write to memory > address 0. This change stops the timer tests from hanging on the 64-bit VM. Why not use kernel32.RaiseException (which is always available) instead? -- Dmitry.

2 4

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 November 2011