February 2005 - Wine-devel - list.winehq.org

Re: winmm: fix type-conversions
by Robert Reif 15 Feb '05

15 Feb '05

James Hawkins wrote: >Hi, > >msvc picked up a couple type-conversions problems in winmm. > > > >- union { float f; char c[4]; } sample; >+ union { double f; char c[4]; } sample; > sample.f=y; > > A float is 4 bytes and a double is 8. They are not interchangeable. The H/W reads/writes 4 byte floats.

2 1

Re: [winecfg] Change audio detection order
by Michael Stefaniuc 15 Feb '05

15 Feb '05

Paul van Schayck wrote: > My previous patch to do something usefull with multiple detected audio > systems was not accepted. > > But right now ARTS was detected first. I've changed the order to OSS - > ALSA - ARTS - JACK. > > Changelog: > Change detection order to: OSS-ALSA-ARTS-JACK Are you sure you want to prefer OSS instead of ALSA? If you have both that means that OSS runs as emulation on ALSA. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 2

Re: winsock: use local includes in tests
by Maxime Bellengé 15 Feb '05

15 Feb '05

You seems to have forgotten something :) Max On Tue, 2005-02-15 at 15:40 -0600, James Hawkins wrote: > Hey, > > This patch keeps msvc from pulling in msvc system headers when > compiling with wine's headers. > > Changelog > * Use local includes to keep msvc from mixing the system and wine's headers. >

1 0

Re: wine/dlls/user/dde server.c misc.c ddeml16.c d ...
by Pouech Eric DMI AEI CAEN 15 Feb '05

15 Feb '05

are you sure of this? according to MSDN, the iCodepage in convcontext is unicode or ansi depending on the A/W version called for DDE initialize (I never tested it though). A+ > Message du 14/02/05 13:11 > De : "Alexandre Julliard" > A : wine-cvs(a)winehq.org > Copie à : > Objet : wine/dlls/user/dde server.c misc.c ddeml16.c d ... > > ChangeSet ID: 16099 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/02/14 05:53:15 > > Modified files: > dlls/user/dde : server.c misc.c ddeml16.c dde_private.h > client.c > > Log message: > Dmitry Timoshkov > Make DDE implementation always work internally in Unicode. > > Patch: http://cvs.winehq.org/patch.py?id=16099 > > Old revision New revision Changes Path > 1.18 1.19 +42 -72 wine/dlls/user/dde/server.c > 1.25 1.26 +37 -34 wine/dlls/user/dde/misc.c > 1.12 1.13 +1 -2 wine/dlls/user/dde/ddeml16.c > 1.9 1.10 +7 -10 wine/dlls/user/dde/dde_private.h > 1.21 1.22 +32 -60 wine/dlls/user/dde/client.c > > > >

2 1

printf and the long long case
by Jesse Allen 15 Feb '05

15 Feb '05

Since Mike McCormack's printf patch has our own vsnprintf parsing the format strings, but yet we still push integers to libc's printf, I figured that we can handle the 'I' (eye) size type now. I hacked together a patch that handles it and fixes 3 test failures with long long. It fixes it by converting I (eye) and I32 to long, and I64 to long long. 'll' (ell ell) is translated to be long only. Mike, I have a question. You have flags.IntegerDouble++; on the case of long long -- what were you planning on doing with it? Other than that it is unused. I decided to use it as the flag for long long. Patch below. Jesse --- dlls/msvcrt/wcs.c-original 2005-02-14 16:14:01.000000000 -0700 +++ dlls/msvcrt/wcs.c 2005-02-14 17:48:39.000000000 -0700 @@ -378,6 +378,16 @@ sprintf(p, ".%d", flags->Precision); p += strlen(p); } + if( flags->IntegerLength ) + { + sprintf(p, "%c", flags->IntegerLength); + p += strlen(p); + } + if( flags->IntegerDouble ) + { + sprintf(p, "l"); + p += strlen(p); + } *p++ = flags->Format; *p++ = 0; } @@ -474,12 +484,28 @@ { if( *p == 'h' || *p == 'l' || *p == 'L' ) { - if( flags.IntegerLength == *p ) /* FIXME: this is wrong */ - flags.IntegerDouble++; - else + if( flags.IntegerLength != *p ) flags.IntegerLength = *p; p++; } + else if( *p == 'I' ) + { + if ( *(p+1) == '3' && *(p+2) == '2' ) + { + /* Unchecked on 64-bit systems */ + flags.IntegerLength = 'l'; + p += 3; + } else if ( *(p+1) == '6' && *(p+2) == '4' ) { + flags.IntegerLength = 'l'; + flags.IntegerDouble++; /* Why ++? */ + p += 3; + } else { + /* FIXME: 'I' modifier needs to produce + 64-bit number output on 64-bit systems! */ + flags.IntegerLength = 'l'; + p++; + } + } else if( *p == 'w' ) flags.WideString = *p++; else @@ -567,6 +593,8 @@ if( pf_is_double_format( flags.Format ) ) sprintf( number, fmt, va_arg(valist, double) ); + else if ( flags.IntegerDouble ) + sprintf( number, fmt, va_arg(valist, long long) ); else sprintf( number, fmt, va_arg(valist, int) );

2 1

Re: Resend: [Bug 2631] Trap in RegisterClassExA
by Dmitry Timoshkov 14 Feb '05

14 Feb '05

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> wrote: > Make RegisterClassExA check the reserved bytes is a valid value > Tests to confirm this behaviour > + /* Bug 2631 - Supplying an invalid number of bytes fails */ > + cls.cbClsExtra = 0; > + cls.cbWndExtra = -1; > + ok( ((RegisterClassA( &cls ) == 0) && (GetLastError() == ERROR_INVALID_PARAMETER)), > + "Failed with invalid number of WndExtra bytes\n"); > + > + cls.cbClsExtra = -1; > + cls.cbWndExtra = 0; > + ok( ((RegisterClassA( &cls ) == 0) && (GetLastError() == ERROR_INVALID_PARAMETER)), > + "Failed with invalid number of ClsExtra bytes\n"); > + > + cls.cbClsExtra = -1; > + cls.cbWndExtra = -1; > + ok( ((RegisterClassA( &cls ) == 0) && (GetLastError() == ERROR_INVALID_PARAMETER)), > + "Failed with invalid number of ClsExtra and cbWndExtra bytes\n"); You need to set last error to some bogus value (0xdeadbeef usually works) before every API call to ensure that it's really that API call who sets the error. -- Dmitry.

1 0

[ddraw/dsurface/main.c] LPRECT parameters for Main_DirectDrawSurface_Lock
by Andreas Eckstein 14 Feb '05

14 Feb '05

Good morning, wine devs! When playing Icewind Dale II (using wine-20050111), the game sometimes crashed with these messages: trace:ddraw:Main_DirectDrawSurface_Lock lprect: 0x0-0x0 err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! or, on another occasion: trace:ddraw:Main_DirectDrawSurface_Lock lprect: 0x0-2x0 err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! As you notice, the game tries to lock a surface with width and/or height equal to zero. Frankly I have no idea what the expected behavior is in this case, however playing the critical passages on Windows worked without crash. A quick patch to let Main_DirectDrawSurface_Lock not choke on zero-width or -height LPRECTs solved the problem with wine. Since I don't plan to dig into wine hacking any time soon, could someone merge it into cvs for me (if the new behavior of the function is acceptable, that is)? Thanks in advance! Andreas Eckstein --- The patch: --- dlls/ddraw/dsurface/main.c 2005-01-09 18:35:44.000000000 +0100 +++ dlls/ddraw/dsurface/main.c 2005-02-14 21:03:36.511738080 +0100 @@ -1111,8 +1111,8 @@ (prect->left < 0) || (prect->bottom < 0) || (prect->right < 0) || - (prect->left >= prect->right) || - (prect->top >= prect->bottom) || + (prect->left > prect->right) || + (prect->top > prect->bottom) || (prect->left >= This->surface_desc.dwWidth) || (prect->right > This->surface_desc.dwWidth) || (prect->top >= This->surface_desc.dwHeight) ||

1 0

Re: Fix documentation build
by Alexandre Julliard 14 Feb '05

14 Feb '05

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Those errors are particularly bad as (in the past) it prevented the Wine > documentation on winehq to be built for a release. > > Alexandre, do you build the docs the same way you compile C files after > applying a patch, or is it that your setup allows missing tags? Yes, I always compile the docs, and they build fine on my setup. If you know how to change my config to make it less forgiving I'd be happy to do that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winecfg: various drive detection enhancements
by Paul van Schayck 14 Feb '05

14 Feb '05

On Mon, 14 Feb 2005 16:10:55 +0100, Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > Changelog: > Include config.h to reenable reading /etc/fstab on platforms that support it. > Implemented a black list of mount directories, which should not be mapped. > Ensure that the user's home directory is mapped. Hehe I was just about to send a patch doing almost exactly the same things. Including the fix you put in to properply add a drive letter to the working_mask. And are we ready to let wineprefixcreate use winecfg? Or do we want more testing of the autodetect code? Paul

2 1

Re: [OLE #69] Use RPC Runtime
by Mike Hearn 14 Feb '05

14 Feb '05

Robert Shearman wrote: > Hi, > > This patch is significant as it changes the RPC backend of our COM > implementation from using named pipes to using any transport implemented > by the RPC runtime. As a matter of coincidence, this patch is numbered > 69, which is my favourite number, and this patch is my favourite patch. Haha, 69 DUDE!!!! > Not only this, but it should also solve some real problems with having > way too many threads (one and only one per apartment) and some complex > deadlocking situations caused by this. It also significiantly reduces > the amount of code in the file and reduces most of it to simple wrappers > around the RPC runtime functions. We'll still need to run a message loop in the RPC runtime right? Until we do that I think InstallShield won't work correctly. So that's the keystone - after that it should all fall into place. thanks -mike

2 1