June 2007 - Wine-Devel - list.winehq.org

Re: [PATCH try2 1/3] setupapi/tests: Add rudimentary tests for InstallHinfSectionA/W.
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 23:29 -0500, Misha Koshelev wrote: > + * - On installation problems, a MessageBox is displayed and there > does not seem to be a way to turn this off. A CBT-Hook (HCBT_CREATEWND) might help -- By by ... Detlef

2 1

Re: [GDI+: 3/10] graphics implementation
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 11:54 -0700, Evan Stade wrote: > + > + *graphics = (GpGraphics*) HeapAlloc(GetProcessHeap(), > HEAP_ZERO_MEMORY, > + sizeof(GpGraphics)); Have you checked, that the native dll does the same? (WINEDEBUG="+snoop,+relay") Your implementation of GdipCreatePen1 is using GdipAlloc. Thanks -- By by ... Detlef

2 1

Re: [GDI+: 3/10] graphics implementation
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 11:54 -0700, Evan Stade wrote: > +GpStatus WINGDIPAPI GdipCreateFromHDC(HDC hdc, GpGraphics **graphics) > +{ > + if(hdc == NULL) > + return OutOfMemory; > + > + if(graphics == NULL) > + return InvalidParameter; > + > + *graphics = (GpGraphics*) HeapAlloc(GetProcessHeap(), > HEAP_ZERO_MEMORY, > + sizeof(GpGraphics)); > + (*graphics)->hdc = hdc; > + (*graphics)->hwnd = NULL; There is no need to set a member to NULL, when you use HEAP_ZERO_MEMORY. -- By by ... Detlef

2 1

Re: [GDI+: 6/10] GdipDrawLineI test
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 12:00 -0700, Evan Stade wrote: > > Changelog: > *Added framework for pixel-by-pixel comparison in tests > *added GdipDrawLineI test > > dlls/gdiplus/tests/graphics.c | 164 > +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 164 insertions(+), 0 deletions(-) > > -Evan Stade The Patch is missing -- By by ... Detlef

1 0

Add new dll mscat32
by Vijay Kiran Kamuju June 12, 2007

June 12, 2007

Hi, I would like to add a stub dll for mscat32.dll in wine. It mostly is a forwarder dll ie, it has forwards for most of the functions to wintrust.dll And it also provides functions for reading catalog files. It is mostly used by microsoft for it installers. I mean for its own products like Winodows Media Player 9, IE, etc. I wanted to inform to get the approval from wine team, for inclusion of this dll. Thanks, VJ

2 4

Re: widl: Add a missing assignment to current_structure before calling write_embedded_types.
by Dan Hipschman June 12, 2007

June 12, 2007

On Tue, Jun 12, 2007 at 10:29:24AM +0100, Robert Shearman wrote: > error("structure size for %s exceeds %d bytes by %d bytes\n", > name, USHRT_MAX, total_size - USHRT_MAX); > > + current_structure = type; > has_pointers = write_embedded_types(file, NULL, type, name, 0, tfsoff); > + current_structure = NULL; > > array = find_array_or_string_in_struct(type); > if (array && !processed(array->type)) That was taken care of by the patch I sent in a little before you. It's like we're reading each other's minds. ;-)

1 0

Re: [GDI+: 3/5] added graphics implementation and tests
by Evan Stade June 12, 2007

June 12, 2007

> On 6/10/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > > "Evan Stade" <estade(a)gmail.com> wrote: > > > > >> Any reason why are you creating a new pen in GdipDrawRectangleI, and while using > > >> an existing one in GdipDrawLineI? > > >> > > >> -- > > >> Dmitry. > > >> > > > > > > Yes, the reason for that is the passed pen can have any endcap style, > > > but to draw the rectangle the pen needs square endcaps. The same does > > > not apply to DrawLine. > > > > Do you have a confirmation that native gdiplus does that as well? +relay,+snoop > > trace, some other test? > > > > -- > > Dmitry. > > Native GDI+ does its own rendering. For example, GDI+ drawline uses repeated stretchblts rather than GDI drawline. However, GDI drawline can be pretty close, if not pixel-for-pixel the same.

1 0

Re: [GDI+: 1/10] first pen implementation
by Detlef Riekenberg June 12, 2007

June 12, 2007

On Mo, 2007-06-11 at 11:51 -0700, Evan Stade wrote: > +GpStatus WINGDIPAPI GdipCreatePen1(ARGB color, FLOAT width, GpUnit > unit, > + GpPen **pen) > +{ > + LOGBRUSH lb; > + GpPen *gp_pen; > + > + gp_pen = (GpPen*) GdipAlloc(sizeof(GpPen)); > + if(!pen) return OutOfMemory; > + > + gp_pen->style = GP_DEFAULT_PENSTYLE; This looks not correct. You returned "OutOfMemory", but you check "pen". I think, you really mean "gp_pen" in that "if". A test with pen==NULL would be nice. > + if((gp_pen->unit == UnitWorld) || (gp_pen->unit == UnitPixel)) { > + > + } else { > + FIXME("UnitWorld, UnitPixel only supported units"); > + return NotImplemented; You leak the allocated memory from gp_pen here. The FIXME does not help very much. You should dump the value for the unsupported unit. > + if(!gp_pen) > + return GenericError; This is dead code in this location. When the allocation for gp_pen failed, you will never reach this line, because gp_pen was accesed before and produced a crash. -- By by ... Detlef

1 0

Re: Allow GL_ONE on WINED3DRS_EDGEANTIALIAS dstBlend value
by H. Verbeet June 12, 2007

June 12, 2007

On 12/06/07, Kovács András <andras(a)csevego.net> wrote: > Hi, > > Allow GL_ONE on WINED3DRS_EDGEANTIALIAS' dstBlend value. This fixes Pirates Of > Caribbean At The Worlds End blending problem. ( black square behind linght > sources) > -- I'm not sure we should be changing srcBlend/dstBlend in the first place over there. The comment at the top of the function claims the red book says GL_LINE_SMOOTH need "special blending parameters", but the copy I've got says no such thing. The closest I could find was "The blending factors you most likely want to use are GL_SRC_ALPHA (source) and GL_ONE_MINUS_SRC_ALPHA (destination)." It also explicitly mentions GL_ONE as a possible alternative for the destination. MSDN also doesn't specify a specific way of antialiasing. Either way, I think we'd rather have correct blending parameters than correctly aliased lines, if we'd have to make a choice between the two.

1 0

Re: [PATCH try2 1/3] setupapi/tests: Add rudimentary tests for InstallHinfSectionA/W.
by James Hawkins June 12, 2007

June 12, 2007

On 6/11/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > Changes from previous version in patch 1: > * Comments to explain why this conformance test cannot be quite standard - see Notes comment @ beginning > * Try A function first - I decided that since the A function works on Win98 but not WinXP it is the one > "broken" (reminder: W works on XP but not 98) > * Added asserts in helper _InstallHinfSection function to verify A/W function pointers to make sure that > in the future useW is not misassigned (currently it is assigned properly in START_TEST(install) section as > it was in previous version). > * Changed test_install to ok_install to make its purpose more clear. Specifically, the idea is that > ok_install does the actual install and checks that everything is installed properly, whereas > test_InstallHinfSection allows us to try using the _InstallHinfSection functions (through ok_install) in > various ways to test effects of parameters on the installation (e.g., see patch 2) > * Use property of the "stub" functions of not changing last error to determine which function is stub instead > of using registry checks > > Hopefully this patchset is clearer. > This would still be clearer and more efficient if you set up a function pointer at the beginning of the tests, and just use that function for the rest of the tests. You make a helper function that tests which version (A or W) works, and assign the working version to the function pointer. This way, you don't have to deal with a useW variable, or any of that mess, and other people can write direct tests without having to use ok_install (which really shouldn't be needed if you use a function pointer). Keep in mind you'll have to use void pointers for the string parameters when declaring the function pointer type. -- James Hawkins

2 3