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

Re: [crypt32/tests 2/2] Vista uses a different error code
by Kai Blin June 13, 2007

June 13, 2007

On Wednesday 13 June 2007 16:13:21 Paul Vriens wrote: > ok ( GetLastError() == ERROR_FILE_INVALID || > + GetLastError() == ERROR_INVALID_PARAMETER /* Vista */ || > GetLastError() == S_OK /* Win98 */, > "Expected ERROR_FILE_INVALID or S_OK, got 0x%08x\n", > GetLastError()); ok ( !memcmp(&subject, &nullSubject, sizeof(GUID)), In that case I think it would make sense to also fix the message. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton.

1 0

Re: gdi32: Add some tests for BITMAPINFOHEADER biSize checks.
by Dmitry Timoshkov June 13, 2007

June 13, 2007

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > These tests pass on XP and on Wine with Dimitry's patch applied. > I can also confirm that the patch fixes bug 8674. > > -Hans > > Changelog > Add some tests for BITMAPINFOHEADER biSize checks. Please add DeleteObject calls to delete a DIB section after each succeeding test. -- Dmitry.

1 0

CJK XCreateFontSet performance problem (bug 5309)
by dank＠kegel.com June 13, 2007

June 13, 2007

It turns out bug 5309 affects Picasa; a Chinese user complained that menus were terribly slow. The patch Aric committed here: http://www.winehq.org/pipermail/wine-cvs/2006-October/027272.html seems to have helped. I'm wondering, though, whether this points up a problem in how linux distros configure their asian fonts. I'm sending this via direct telnet to winehq's tsmtp server, since there's no other way to avoid setnding passwords in the clear from where I am at the momment (dang unencrypted wireless in hotel forooms.). Sorry for all the ^H's :-)

1 0

Seeking advice for rewrite of dlls/quartz/videorenderer.c using DirectDraw
by Alex Villacís Lasso June 13, 2007

June 13, 2007

From a time till now, I am using a test application in Visual Basic in order to test progress in quartz. The code for the application (along with a precompiled EXE) can be found at the following address: http://www.palosanto.com/~a_villacis/WMediaTest.tar.bz2 One of the things I dislike about the current quartz implementation is that when a large AVI video file (say, 640x480) is played with the test application, the sound stutters (in both ALSA and OSS) while the frames are being updated. This occurs with the builtin quartz.dll, but not with native (WinXP) quartz. From what I can deduce from WINEDEBUG=+tid,+quartz , it seems that builtin feeds video and audio in the same thread. In addition, dlls/quartz/videorenderer.c uses StretchDIBits() in order to write one frame of video into the output window. Apparently StretchDIBits() is slow enough in my machine that it cannot complete by the next sound sample. Therefore the stuttering. I made a little patch to move the video rendering in videorender.c into a separate thread, in order to allow it to drop frames. However this does not completely eliminate the stuttering audio. I am now thinking about rewriting the video rendering with DirectDraw. It seems that native quartz.dll uses DirectDraw, not GDI, to display video frames into the output window. One thing I am worried about is the pixel format of the surfaces. The video data is 32bpp, but the output window uses my X config at 16bpp. However, nowhere in the ddraw trace of native quartz I can find any reference to a CreateSurface with 32bpp. It seems that native quartz does the depth conversion itself. The question is this: if I create a 32 bpp surface (in order to lock it and write the 32 bpp frame data into it), can I then blit it into a 16 bpp output window and somehow let DirectDraw take care of the depth conversion? If so, can this be any faster than writing the depth conversion myself? Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

4 5

Re: [GDI+ implementation: 1/8] GdipDrawLineI
by Evan Stade June 13, 2007

June 13, 2007

On 6/12/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > Changelog: > *implemented GdipDrawLineI > > dlls/gdiplus/gdiplus.spec | 2 +- > dlls/gdiplus/graphics.c | 16 ++++++++++++++++ > 2 files changed, 17 insertions(+), 1 deletions(-) > > -Evan Stade > > Sorry, to clarify: this series of patches is a resend of the last without the tests, and with some new patches.

2 1

Re: [GDI+: 2/10] first pen test
by Detlef Riekenberg June 13, 2007

June 13, 2007

On Mo, 2007-06-11 at 11:52 -0700, Evan Stade wrote: > + > + status = GdipCreatePen1((ARGB)0xffff00ff, 10.0f, UnitPixel, > &pen); > + > + todo_wine > + expect(GdiplusNotInitialized, status); > + > + GdipDeletePen(pen); > +} Is pen set to NULL, when GdipCreatePen1 failed? This ist not checked in your test and not done in your implementation, but you pass uninitialized garbage (pen) to GdipDeletePen. You might want to use: - GpPen *pen; + GpPen *pen = NULL; and - GdipDeletePen(pen); + if (status == Ok) then GdipDeletePen(pen); Thanks -- By by ... Detlef

3 2

Re: advapi32: Allow setting CRYPT_VERIFYCONTEXT and CRYPT_NEWKEYSET in CryptAcquireContext
by Mounir IDRASSI June 13, 2007

June 13, 2007

Hi Maarten, You should not modify advapi32 to accommodate this behavior but rsaenh instead. The acceptance of this flags combination is specific to the Microsoft RSA CSP implementation and other vendors don't support it (I tested it with four third party CSPs). Moreover, your patch will clearly introduce unexpected CSP behavior when this combination of flags is specified as you start by acquiring a context using CRYPT_NEWKEYSET only: the returned context will not behave as intended by the CRYPT_VERIFYCONTEXT flag which normally limits many things. The modification to rsaenh is straightforward: in the code of RSAENH_CPAcquireContext, juste add the line "case CRYPT_VERIFYCONTEXT | CRYPT_NEWKEYSET:" above the existing line "case CRYPT_VERIFYCONTEXT:". Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Maarten Lankhorst wrote: > With tests. I think this is the correct way to do this: First try to > Acquire with CRYPT_NEWKEYSET, then CRYPT_VERIFYCONTEXT if it already exists. >

1 0

Re: [7/7] Add ID3D10Device interface and implement it's IUnknown methods
by H. Verbeet June 12, 2007

June 12, 2007

On 13/06/07, Kovács András <andras(a)csevego.net> wrote: > + TRACE("Adapter %p, Driver Type %d, Software Module handle %p, Flags %08x, SDKVersion %d, Device %p\n", > + Adapter, DriverType, Software, Flags, SDKVersion, Device); I think the DriverType should be traces as string there (ie, using something like the debug_d3d*() functions in dlls/wined3d/utils.c). Also, please prefix hexadecimal numbers with 0x. d3d8 and d3d9 are pretty bad wrt producing readable traces, but we might as well do it right when writing a new dll. > + FIXME("ID3D10Device interface is not binary compatible to windows yet\n"); Actually, a void * is binary compatible with IDGXIAdapter * I suppose it's a matter of taste, but personally I think more C like naming (ie, lower case, _ separated) for the parameter names would be easier on the eyes :-) (and you do use those for the ID3D10DeviceImpl functions). Chris already mentioned the initial refcount on IRC.

2 2

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

June 12, 2007

On 13/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 think I wasn't very clear wrt what I said on IRC / wrote in my earlier mail. The original patch was fine with me for what it did. What I meant to say was that an additional patch should probably follow that one to remove the code that modifies srcBlend and dstBlend. Personally I think the changes are small enough to go in a single patch, but that would be up to Alexandre. You should remove the line modifying srcBlend a few lines above as well though.

1 0

Re: [7/7] Add ID3D10Device interface and implement it's IUnknown methods
by Stefan Dösinger June 12, 2007

June 12, 2007

Am Mittwoch, 13. Juni 2007 00:17 schrieb Kovács András: > [7/7] Add ID3D10Device interface and implement it's IUnknown methods >+ object->lpVtbl = &D3D10Device_Vtbl; >+ object->ref = 0; Spotted by KittyCat on irc. The ref should be 1. Either set it to 1, or call ID3D10Device_AddRef(*Device) after setting *Device(ms seems to do it the Addref way).

1 0

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

Can we start/stop services in conformance tests?
by Misha Koshelev June 12, 2007

June 12, 2007

Just wondering. It seems like I can avoid message boxes easily by using a CHT hook, but the Beep() that this particular message box uses can only be disabled with the ControlService/StartService combo. Can I use this in a non-service conformance test, or is it too much to assume that the person running the tests has administrator access (or am I allowed to check for this and simply skip the relevant tests if they don't)? I would assume as long as I am turning the service (beep) back on afterwards if it is on before and check for administrator rights this would be okay? Thanks Misha

1 0

Re: Alexandre Julliard : winecfg: Fix potential null pointer access ( spotted by Yaroslav Skorokhodov).
by Vitaly Lipatov June 12, 2007

June 12, 2007

В сообщении от 12 июня 2007 Alexandre Julliard написал(a): ... > @@ -107,7 +107,7 @@ static void update_comboboxes(HWND dialog) > winver = get_reg_key(config_key, keypath(""), "Version", ""); What wrong with call get_reg_key (,,,NULL) ? Why we need winver as NULL pointer and as empty string? > ver = get_registry_version(); > > - if (*winver == '\0') > + if (!winver || !winver[0]) > { > HeapFree(GetProcessHeap(), 0, winver); -- Lav Виталий Липатов Россия, Санкт-Петербург. www.etersoft.ru GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

2 1

Re: [GDI+: 4/10] graphics test
by Alexandre Julliard June 12, 2007

June 12, 2007

"Evan Stade" <estade(a)gmail.com> writes: > + wndClass.lpszClassName = TEXT(ClassName); > + > + if(!RegisterClassA(&wndClass)) return FALSE; This is broken, TEXT() doesn't work on a variable name, and it's useless since you call the A function anyway. Please don't use any of the ugly TCHAR macros in tests, there's no need for them. Either A/W doesn't matter and you can simply use plain Ascii strings, or it does matter and then you have to explicitly test both cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

opengl conversation on irc
by Dan Kegel June 11, 2007

June 11, 2007

A bunch of folks just had an interesting discussion about the OpenGL problem on irc. I and Roderick saved a log of the conversation, one per room: http://kegel.com/wine/opengl-wine-chat1.html (the original #winehackers discussion) http://roderick.student.utwente.nl/xorg-devel.log (after it moved to #xorg-devel) Roderick gets back from vacation July 22nd or so, and said he expects not only a nice writeup on WWN but also a full implementation by then :-) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: rsaenh: AcquireContext can have multiple flags defined at the same time
by Mounir IDRASSI June 11, 2007

June 11, 2007

Hi, Your patch is wrong: the flags CRYPT_NEWKEYSET and CRYPT_VERIFYCONTEXT can't be mixed and if they are set together like in your patch AcquireContext should return NTE_BAD_FLAGS. You can check that using the MS implementation under windows. It's also clearly stated in MSDN that CRYPT_VERIFYCONTEXT is reserved for non persistent operations which is not the case when you create a new container. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Maarten Lankhorst wrote: > According to msdn a combination of flags are set, since I'm not sure > which combo's are valid I put up a FIXME. > > ------------------------------------------------------------------------ > >

2 3