wine-devel October 2009

wine-devel@winehq.org

92 participants
261 discussions

Re: [try 4] Add help message box to dxdiag implementation
by Joel Holdsworth 09 Oct '09

09 Oct '09

I'm just wondering how easy would it be to do something simple with a proper dialog template. The reason I ask is that I've been working on an icon for dxdiag (http://www.airwebreathe.org.uk/wine-icon/), and it'd be nice if there was a dialog ready to receive it. It's no big deal though. What do you think? Joel

2 1

re: BSTR caching
by Dan Kegel 09 Oct '09

09 Oct '09

Hi Markus, Wine development is driven by test cases checked in to the Wine source tree. Please extend the test cases in dlls/oleaut32/tests to verify that oleaut32 is caching BSTRs properly, and make sure that test passes on Windows and is marked todo_wine. Once we have a test case like that checked into the Wine source tree, we'll be in better shape to accept a patch that fixes bug 12460. Thanks!

6 15

Re: include/dwmapi.h: Add defenition of MIL_MATRIX3X2D
by Nikolay Sivov 09 Oct '09

09 Oct '09

Louis. Lenders wrote: > needed to add a stub for //DwmGetGraphicsStreamTransformHint later on > // > > Hi, Louis. > > +typedef struct _MIL_MATRIX3X2D > +{ > + DOUBLE S_11; > + DOUBLE S_12; > + DOUBLE S_21; > + DOUBLE S_22; > + DOUBLE DX; > + DOUBLE DY; > +} MIL_MATRIX3X2D; > + This is called MilMatrix3x2D in PSDK. Would you mind to resend?

1 0

[try 4] Add help message box to dxdiag implementation
by Dan Kegel 09 Oct '09

09 Oct '09

Looks fine to me. FWIW, I'd suggest continuing on with a second patch that adds one more feature, and post the two-patch series. Also, you're welcome to send it to Austin and me first for pre-review. [I 'spose you should have mentioned it's identical to the previous try.]

1 0

Re: [try 4] Add help message box to dxdiag implementation
by Nikolay Sivov 09 Oct '09

09 Oct '09

Brian Nguyen wrote: > This patch adds a simple help message box to dxdiag; this change is > intentionally small in order to start implementing features of dxdiag > incrementally. How does it look? > > -- > Brian Nguyen > mtxcoll(a)gmail.com <mailto:mtxcoll@gmail.com> > --- /dev/null > +++ b/programs/dxdiag/En.rc > @@ -0,0 +1,13 @@ > +#include "dxdiag_res.h" > + > +STRINGTABLE > +{ You should add a license header for new created files.

1 0

Re: comctl32: initial theming tests (try 4)
by Nikolay Sivov 08 Oct '09

08 Oct '09

André Hentschel wrote: > --- > dlls/comctl32/tests/Makefile.in | 1 + > dlls/comctl32/tests/theming.c | 235 +++++++++++++++++++++++++++++++++++++++ > 2 files changed, 236 insertions(+), 0 deletions(-) > create mode 100644 dlls/comctl32/tests/theming.c > Hi, Andre. > +#ifdef __i386__ > +#define ARCH "x86" > +#elif defined __x86_64__ > +#define ARCH "amd64" > +#else > +#define ARCH "none" > +#endif > + > +static const CHAR manifest[] = We already have this stuff defined in v6util.h. No reason to duplicate I suppose.

3 6

Re: [ntdll] Move file attribute logic to new function DIR_get_attributes()
by Juan Lang 08 Oct '09

08 Oct '09

Hi Dan, > This is a bit different from the code I posted earlier; > following Samba's example, it combines the > fd and filename cases into a single function, Since you don't actually use the fd in your patch, I think it's preferred style not to include it for now. Also, +void DIR_set_attributes(int fd, DWORD attributes) +{ + /* Unimplemented. Wine does not yet store win32 file attributes. */ (snip) + + /* Try to save attributes. We don't care too much if it doesn't work. */ + DIR_set_attributes(fd, info->FileAttributes); Adding a no-op part of the patch is a bit ugly. Removing it allows you to focus on one thing in this patch, rewriting querying the file attributes. You re-add setting them later. (Thanks for working on this, by the way.) --Juan

2 4

BSTR caching
by Markus Stockhausen 08 Oct '09

08 Oct '09

Hi, the last week I took some time to implement the first try of BSTR caching in oleaut.c. On the one hand this will fix a bug, on the other hand Wine could save some CPU cycles and can catch up with the speed of the native implementation. Attached you will find the result of my considerations. It is not yet ready for implementation but will reflect the "big picture" I thought of. I would be happy to receive some feedback on this work especially the following questions are still open: - Is DllMain the right location for Initialization/Cleanup - I'm totally confused about the task of how to write a testcase for this change. Thanks for your help. Markus

4 6

Re: rpcrt4: A signed 1-bit bitfield doesn't make much sense; use unsigned.
by Paul Vriens 08 Oct '09

08 Oct '09

On 10/08/2009 11:22 AM, Francois Gouget wrote: > --- > > While signed 1-bit bitfields don't make much sense, that's how they are > defined in the PSDK. So maybe we want to stick with the signed > definition anyway. If not then we can apply this patch. > > As far as I can tell this is the only place left where we have signed > 1-bit bitfields. > > include/rpcndr.h | 26 +++++++++++++------------- > 1 files changed, 13 insertions(+), 13 deletions(-) > > diff --git a/include/rpcndr.h b/include/rpcndr.h > index 8fee143..81baa87 100644 > --- a/include/rpcndr.h > +++ b/include/rpcndr.h > @@ -204,19 +204,19 @@ typedef struct _MIDL_STUB_MESSAGE > struct _FULL_PTR_XLAT_TABLES *FullPtrXlatTables; > ULONG FullPtrRefId; > ULONG PointerLength; > - int fInDontFree:1; > - int fDontCallFreeInst:1; > - int fInOnlyParam:1; > - int fHasReturn:1; > - int fHasExtensions:1; > - int fHasNewCorrDesc:1; > - int fIsIn:1; > - int fIsOut:1; > - int fIsOicf:1; > - int fBufferValid:1; > - int fHasMemoryValidateCallback:1; > - int fInFree:1; > - int fNeedMCCP:1; > + unsigned int fInDontFree:1; > + unsigned int fDontCallFreeInst:1; > + unsigned int fInOnlyParam:1; > + unsigned int fHasReturn:1; > + unsigned int fHasExtensions:1; > + unsigned int fHasNewCorrDesc:1; > + unsigned int fIsIn:1; > + unsigned int fIsOut:1; > + unsigned int fIsOicf:1; > + unsigned int fBufferValid:1; > + unsigned int fHasMemoryValidateCallback:1; > + unsigned int fInFree:1; > + unsigned int fNeedMCCP:1; > int fUnused:3; > int fUnused2:16; > DWORD dwDestContext; Hi Francois, This one introduces some test failures: http://test.winehq.org/data/d62d442d6d2fbb4a892f2448830aaabcda449b17/ The tests rely on the signedness so it seems. -- Cheers, Paul.

1 0

Re: [2/5] ddraw: Simplify and test DirectDrawEnumerateA.
by Alexandre Julliard 08 Oct '09

08 Oct '09

Andrew Nguyen <arethusa26(a)gmail.com> writes: > The tests for the following series of patches succeed on Windows XP > and Windows 7. The crash code is borrowed from the timer callback > crash test in commit f20f411925e789a2aecf740776f441335837ac5f. > --- > dlls/ddraw/main.c | 6 +- > dlls/ddraw/tests/Makefile.in | 1 + > dlls/ddraw/tests/ddrawenum.c | 99 ++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 103 insertions(+), 3 deletions(-) > create mode 100644 dlls/ddraw/tests/ddrawenum.c It's a bit overkill to create a new file for testing just one function. Please put this in an existing file, or create something more generic. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
17
18
19
20
21
22
23
...
27
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 October 2009