July 2008 - Wine-devel - list.winehq.org

Re: regedit: 3/7 Convert the rest of setValue to unicode
by Alexandre Julliard 10 Jul '08

10 Jul '08

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > @@ -185,13 +199,16 @@ static DWORD getDataType(LPSTR *lpValue, DWORD* parse_type) > *lpValue+=ptr->len; > if (type == -1) { > char* end; > + char* buf = HeapAlloc(GetProcessHeap(), 0, (lstrlenW(*lpValue)+1)*sizeof(WCHAR)); > + WideCharToMultiByte(CP_ACP, 0, *lpValue, -1, buf, (lstrlenW(*lpValue)+1)*sizeof(WCHAR), NULL, NULL); > /* "hex(xx):" is special */ > - type = (int)strtoul( *lpValue , &end, 16 ); > - if (**lpValue=='\0' || *end!=')' || *(end+1)!=':') { > + type = (int)strtoul( buf , &end, 16 ); > + if (*buf=='\0' || *end!=')' || *(end+1)!=':') { > type=REG_NONE; > } else { > - *lpValue=end+2; > + *lpValue += (end - buf)*sizeof(WCHAR) + 2; The last line is not correct, besides we have strtoulW so you don't need any of that W->A conversion. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [Gdiplus 2/3] Add a test for a floating-point triangle
by Huw Davies 10 Jul '08

10 Jul '08

Hi Adam, This is mainly a brain-dump, there's nothing wrong the patch. On Thu, Jul 10, 2008 at 12:44:55AM -0400, Adam Petaccia wrote: > --- > dlls/gdiplus/tests/region.c | 38 ++++++++++++++++++++++++++++++++++++++ > 1 files changed, 38 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdiplus/tests/region.c b/dlls/gdiplus/tests/region.c > index 1b1b047..7b1eba5 100644 > --- a/dlls/gdiplus/tests/region.c > +++ b/dlls/gdiplus/tests/region.c > @@ -361,6 +361,44 @@ todo_wine > expect(Ok, status); > status = GdipDeleteRegion(region); > expect(Ok, status); > + status = GdipGetRegionDataSize(region, &needed); > + expect(Ok, status); > + ok(needed == 72, "Expected 72, got %d\n", needed); > + status = GdipGetRegionData(region, (BYTE*)buf, sizeof(buf), &needed); > + expect(Ok, status); > + expect_dword(buf, 64); > + trace("buf[1] = %08x\n", buf[1]); > + expect_dword(buf + 2, RGNDATA_MAGIC); > + expect_dword(buf + 3, 0); > + expect_dword(buf + 4, RGNDATA_PATH); > + > + expect_dword(buf + 5, 48); > + expect_dword(buf + 6, RGNDATA_MAGIC); > + expect_dword(buf + 7, 4); > + expect_dword(buf + 8, 0); > + expect_float(buf + 9, 5.6); > + expect_float(buf + 10, 6.2); > + expect_float(buf + 11, 7.2); > + expect_float(buf + 12, 8.9); > + expect_float(buf + 13, 8.1); > + expect_float(buf + 14, 1.6); > + expect_float(buf + 15, 5.6); > + expect_float(buf + 16, 6.2); There's one more DWORD left here (buf + 17). I realised after I sent in my last lot of tests that this is the BYTE array of PathPointType*s packed into DWORDs (hence the 0x81...... vs 0x01...... that you noted in an earlier patch). As you've also noticed there are two ways of storing paths, if all the co-ords are short ints then they get stored that way and the 0x00004000 bit of buf + 8 is set. Otherwise the co-ords are stored as floats. In addition, the 0x00002000 bit of that same DWORD corresponds to the FillMode of the path. Anyway, good work! Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: gdiplus: Add a trailing '\n' to Wine traces.
by Nikolay Sivov 10 Jul '08

10 Jul '08

Francois Gouget wrote: > --- > > I believe it's independent from the spelling fixes patch. I'll > resubmit if not. > > dlls/gdiplus/font.c | 2 +- > dlls/gdiplus/image.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) I think you should just remove a bracket here: - FIXME("%p (%s), %f, %p\n)", font, + FIXME("%p (%s), %f, %p\n", font,

2 1

re: Support of USB hardware tokens
by Dan Kegel 10 Jul '08

10 Jul '08

> I think should split my patch into many little commits. > Should also add some tests or make some changes? Yes, add conformance tests for the new ntoskrnl functions and usbd.sys, and break the patch up a lot... Looks like people have been hoping for something like this for a couple years now, e.g. http://www.winehq.org/pipermail/wine-devel/2005-November/042357.html

3 2

Re: gdiplus: Add a trailing '\n' to Wine traces.
by Alistair Leslie-Hughes 09 Jul '08

09 Jul '08

> @@ -327,7 +327,7 @@ GpStatus WINGDIPAPI > GdipGetFontHeightGivenDPI(GDIPCONST GpFont *font, REAL dpi, > { > if (!(font && height)) return InvalidParameter; > > - FIXME("%p (%s), %f, %p\n)", font, > + FIXME("%p (%s), %f, %p\n)\n", font, The first \n in the fixme should be removed. Best Regards Alistair Leslie-Hughes

1 0

Crashes in winetest under wine
by Austin Lund 09 Jul '08

09 Jul '08

I get a crash all the time in winetest since 1.0. Seems there is not a problem with any of the tests themselves (i.e. running make test). The last few lines of output from winetest is: fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 16 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1440x900x24 @0! (XRandR) err:ntdll:RtlpWaitForCriticalSection section 0x7bc91824 "loader.c: loader_section" wait timed out in thread 0039, blocked by 0036, retrying (60 sec) wine: Critical section 7bc91824 wait failed at address 0x7bc3ab60 (thread 0039), starting debugger... err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x7bc3ab60 And the output file made in /tmp has at the end: uxtheme:system start dlls/uxtheme/tests/system.c - system.c:491: Starting test_IsThemed() system.c:87: Theming is inactive system.c:495: Starting test_GetWindowTheme() system.c:499: Starting test_SetWindowTheme() system.c:503: Starting test_OpenThemeData() system.c:263: No active theme, skipping rest of OpenThemeData tests system.c:507: Starting test_GetCurrentThemeName() system.c:511: Starting test_CloseThemeData() system: 45 tests executed (11 marked as todo, 0 failures), 0 skipped. uxtheme:system done (0) It takes quite a long time to get to the point where it crashes so I'd be open to ideas as to how to narrow this down quicker. I'm running everything on a clean install with an empty ~/.wine directory.

2 5

Re: Revert "winemp3: Don't keep unused data buffered."
by Chris Robinson 09 Jul '08

09 Jul '08

On Wednesday 09 July 2008 11:44:17 am Maarten Lankhorst wrote: > This reverts commit 8f46a5119249562aceabff6d120948cbfacb6423. > The data isn't unused, mp3's can set up 'bit buckets', so while the > bit rate is constant, some data is needed anyway for later playback. > --- I don't believe reverting this is correct. Some apps needed this change to keep from stopping the stream prematurely (indeed, acmwrapper does not make sure all data is flushed out after using all input data). See bug 11659 <http://bugs.winehq.org/show_bug.cgi?id=11659>.

2 2

Feedback for "Regedit: Implement deleting multiple values"
by Andre Wisplinghoff 09 Jul '08

09 Jul '08

Hallo, my patch [1] wasn't applied. Can anyone give me a hint what wasn't OK with it? Thanks for your time. Best Regards - Andre Wisplinghoff [1] http://www.winehq.org/pipermail/wine-patches/2008-July/057227.html

3 2

CUDA wrapper
by Seth Shelnutt 09 Jul '08

09 Jul '08

The compiler chokes on the C++ coding that you pointed out. I'm not sure exactly how to handle it, maybe just convert it all to c syntax? For now I'll just commit out those lines and just work on trying to get something to compile. Now are you saying the code should be, retval, WINAPI wine_cudaGetDeviceCount( int* count ){ return cudaGetDeviceCount( count ); } or should it be retval, WINAPI wine_cudaGetDeviceCount( int* count ) or retval = WINAPI wine_cudaGetDeviceCount( int* count ){ return cudaGetDeviceCount( retval ); } I've never used retval and going off of http://www.systhread.net/texts/200612retval.php , it seems that retval is as simple as returning the value from a function, so I set the input to equal retval then I can return the function ( retval) and it will have all the values right? Maybe I am miss understanding it. On Mon, Jul 7, 2008 at 12:26 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Actually you want something like > > retval WINAPI wine_cudaSomething(int a, int etc) > > so instead of the void use the return value the function is supposed to > return > > > > WINAPI tells the compiler about the calling convention(ie, first parameter > on the stack, in ecx, or elsewhere, who takes care about cleaning up the > stack, etc). You'll have to check the calling convention Win32 cuda uses, > but most likely WINAPI is correct. You don't have to care about the Linux > cuda calling convention, since the compiler knows about that from the Linux > cuda headers > > > > I am also not quite sure about some constructs, like > > "wine_cudaBindTexture( size_t* offset, const struct texture < T, dim, > readMode >& texRef, const void* devPtr, const struct cudaChannelFormatDesc& > desc, size_t size = UINT_MAX )" As far as I know this contains C++ or > Microsoft syntax, which is not valid in pure C. > > > > >

3 10

Re: [Gdiplus 11/15] Implement GdipCreateRegionRect
by Huw Davies 09 Jul '08

09 Jul '08

On Wed, Jul 09, 2008 at 03:34:01AM -0400, Adam Petaccia wrote: > --- > dlls/gdiplus/region.c | 28 ++++++++++++++++++++++++---- > dlls/gdiplus/tests/region.c | 8 ++++---- > 2 files changed, 28 insertions(+), 8 deletions(-) > > diff --git a/dlls/gdiplus/region.c b/dlls/gdiplus/region.c > index 59e2fa6..de86ce1 100644 > --- a/dlls/gdiplus/region.c > +++ b/dlls/gdiplus/region.c > @@ -129,12 +129,32 @@ GpStatus WINGDIPAPI GdipCreateRegionPath(GpPath *path, GpRegion **region) > return Ok; > } > > -GpStatus WINGDIPAPI GdipCreateRegionRect(GDIPCONST GpRectF *rect, GpRegion **region) > +GpStatus WINGDIPAPI GdipCreateRegionRect(GDIPCONST GpRectF *rect, > + GpRegion **region) > { > - FIXME("(%p, %p): stub\n", rect, region); > + GpPath *path; > + GpStatus stat; > > - *region = NULL; > - return NotImplemented; > + if (!(rect && region)) > + return InvalidParameter; > + > + TRACE("%p, %p\n", rect, region); > + > + *region = GdipAlloc(sizeof(GpRegion*)); > + if(!*region) > + return OutOfMemory; > + > + stat = GdipCreatePath(FillModeAlternate, &path); > + if (stat != Ok) { GdipDeleteRegion(*region); return stat;} > + stat = GdipAddPathRectangle(path, rect->X, rect->Y, > + rect->Width, rect->Height); > + if (stat != Ok) { GdipDeleteRegion(*region); return stat;} > + stat = GdipCreateRegionPath(path, region); > + if (stat != Ok) { GdipDeleteRegion(*region); return stat;} > + > + GdipDeletePath(path); > + > + return Ok; > } This doesn't look right. See the GdipGetRegionData tests (and extend them to add paths), these are supposed to help understanding how regions are stored. It looks to me that a region is stored as a sequence of rects and paths that are combined with various CombineMode ops. I'll send a patch that adds paths to the test in a bit. Huw. -- Huw Davies huw(a)codeweavers.com

2 3