September 2009 - Wine-Devel

Asynchronus serial port
by Fenixk19 Sept. 10, 2009

Sept. 10, 2009

Hello! I've already post the bug(http://bugs.winehq.org/show_bug.cgi?id=19713) on this subject, but i need more help. So I've decided to write here. There is a problem in wine. When I use asynchronous serial port read, data never comes. Event, caused by select comes. But operation status stays pending, and i can't do anything to this serial port anymore. In windows it never get pending, and port can be accessed just after data arrival. Seems to be wineserver problem, but i don't know, where to look at. What code respond for asynchronous serial port in wineserver? Alexander. P.S. Test program attached.

4 4

Re: [PATCH 12/12] openal32: fixed ctx null ptr debug (Coverity)
by Chris Robinson Sept. 10, 2009

Sept. 10, 2009

I have a different patch that will fix this, that also fixes a problem with error states.

1 0

Re: server: Use kernel support for thread affinity when available
by Chris Robinson Sept. 10, 2009

Sept. 10, 2009

On Thursday 10 September 2009 9:43:02 am Juan Lang wrote: > +/* Define to 1 if you have the `sched_getaffinity' function. */ > +#undef HAVE_SCHED_GETAFFINITY > + ... > +#ifdef HAVE_SCHED_GET_AFFINITY > +#define __USE_GNU > +#include <sched.h> > +#endif Looks like a typo there.

1 0

Re: winex11: Make X11DRV_PALETTE_ComputeColorShifts() static.
by Roderick Colenbrander Sept. 10, 2009

Sept. 10, 2009

In a next patch ComputeChannelShift will be called from outside palette.c and for this reason I made it non-static. Roderick On Thu, Sep 10, 2009 at 5:58 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/winex11.drv/palette.c | 115 ++++++++++++++++++++++---------------------- > dlls/winex11.drv/x11drv.h | 1 - > 2 files changed, 57 insertions(+), 59 deletions(-) > > diff --git a/dlls/winex11.drv/palette.c b/dlls/winex11.drv/palette.c > index 81bb73b..cdbfb21 100644 > --- a/dlls/winex11.drv/palette.c > +++ b/dlls/winex11.drv/palette.c > @@ -131,6 +131,63 @@ static void palette_set_mapping( HPALETTE hpal, int *mapping ) > wine_tsx11_unlock(); > } > > +/*********************************************************************** > + * X11DRV_PALETTE_ComputeChannelShift > + * > + * Calculate conversion parameters for a given color mask > + */ > +static void X11DRV_PALETTE_ComputeChannelShift(unsigned long maskbits, ChannelShift *physical, ChannelShift *to_logical) > +{ > + int i; > + > + if (maskbits==0) > + { > + physical->shift=0; > + physical->scale=0; > + physical->max=0; > + to_logical->shift=0; > + to_logical->scale=0; > + to_logical->max=0; > + return; > + } > + > + for(i=0;!(maskbits&1);i++) > + maskbits >>= 1; > + > + physical->shift = i; > + physical->max = maskbits; > + > + for(i=0;maskbits!=0;i++) > + maskbits >>= 1; > + physical->scale = i; > + > + if (physical->scale>8) > + { > + /* On FreeBSD, VNC's default 32bpp mode is bgrabb (ffc00000,3ff800,7ff)! > + * So we adjust the shifts to also normalize the color fields to > + * the Win32 standard of 8 bits per color. > + */ > + to_logical->shift=physical->shift+(physical->scale-8); > + to_logical->scale=8; > + to_logical->max=0xff; > + } else { > + to_logical->shift=physical->shift; > + to_logical->scale=physical->scale; > + to_logical->max=physical->max; > + } > +} > + > +/*********************************************************************** > + * X11DRV_PALETTE_ComputeColorShifts > + * > + * Calculate conversion parameters for a given color > + */ > +static void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask) > +{ > + X11DRV_PALETTE_ComputeChannelShift(redMask, &shifts->physicalRed, &shifts->logicalRed); > + X11DRV_PALETTE_ComputeChannelShift(greenMask, &shifts->physicalGreen, &shifts->logicalGreen); > + X11DRV_PALETTE_ComputeChannelShift(blueMask, &shifts->physicalBlue, &shifts->logicalBlue); > +} > > /*********************************************************************** > * COLOR_Init > @@ -278,64 +335,6 @@ void X11DRV_PALETTE_Cleanup(void) > } > > /*********************************************************************** > - * X11DRV_PALETTE_ComputeChannelShift > - * > - * Calculate conversion parameters for a given color mask > - */ > -static void X11DRV_PALETTE_ComputeChannelShift(unsigned long maskbits, ChannelShift *physical, ChannelShift *to_logical) > -{ > - int i; > - > - if (maskbits==0) > - { > - physical->shift=0; > - physical->scale=0; > - physical->max=0; > - to_logical->shift=0; > - to_logical->scale=0; > - to_logical->max=0; > - return; > - } > - > - for(i=0;!(maskbits&1);i++) > - maskbits >>= 1; > - > - physical->shift = i; > - physical->max = maskbits; > - > - for(i=0;maskbits!=0;i++) > - maskbits >>= 1; > - physical->scale = i; > - > - if (physical->scale>8) > - { > - /* On FreeBSD, VNC's default 32bpp mode is bgrabb (ffc00000,3ff800,7ff)! > - * So we adjust the shifts to also normalize the color fields to > - * the Win32 standard of 8 bits per color. > - */ > - to_logical->shift=physical->shift+(physical->scale-8); > - to_logical->scale=8; > - to_logical->max=0xff; > - } else { > - to_logical->shift=physical->shift; > - to_logical->scale=physical->scale; > - to_logical->max=physical->max; > - } > -} > - > -/*********************************************************************** > - * X11DRV_PALETTE_ComputeColorShifts > - * > - * Calculate conversion parameters for a given color > - */ > -void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask) > -{ > - X11DRV_PALETTE_ComputeChannelShift(redMask, &shifts->physicalRed, &shifts->logicalRed); > - X11DRV_PALETTE_ComputeChannelShift(greenMask, &shifts->physicalGreen, &shifts->logicalGreen); > - X11DRV_PALETTE_ComputeChannelShift(blueMask, &shifts->physicalBlue, &shifts->logicalBlue); > -} > - > -/*********************************************************************** > * X11DRV_PALETTE_BuildPrivateMap > * > * Allocate colorcells and initialize mapping tables. > diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h > index 62b0d63..844af31 100644 > --- a/dlls/winex11.drv/x11drv.h > +++ b/dlls/winex11.drv/x11drv.h > @@ -494,7 +494,6 @@ extern BOOL X11DRV_IsSolidColor(COLORREF color); > extern COLORREF X11DRV_PALETTE_ToLogical(X11DRV_PDEVICE *physDev, int pixel); > extern int X11DRV_PALETTE_ToPhysical(X11DRV_PDEVICE *physDev, COLORREF color); > extern int X11DRV_PALETTE_LookupPixel(COLORREF color); > -extern void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask); > > extern unsigned int depth_to_bpp( unsigned int depth ); > > -- > 1.6.3.3 > > >

1 0

Re: mshtml: Add support for Reference BSTR when setting styles.
by Paul Vriens Sept. 10, 2009

Sept. 10, 2009

On 09/10/2009 12:00 PM, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > mshtml: Add support for Reference BSTR when setting styles. > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > > Hi Alistair, Now VT_BSTR is used in two case-statements. -- Cheers, Paul.

1 1

Re: msi: Ignore CoInitialize failure in ACTION_CreateShortcuts.
by Hans Leidekker Sept. 10, 2009

Sept. 10, 2009

> Fixes http://bugs.winehq.org/show_bug.cgi?id=19636 Or it doesn't: err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded err:shell:ShellLink_QueryInterface -- Interface: E_NOINTERFACE Because IShellLink is apartment-threaded only? -Hans

1 0

Performance tag for Bugzilla?
by Scott Ritchie Sept. 9, 2009

Sept. 9, 2009

We have a wiki page functioning as sort of a wannabe performance tag here: http://wiki.winehq.org/Performance-related_bugs Is this a reasonable tag to have? Thanks, Scott Ritchie

1 0

http://bugs.winehq.org/show_bug.cgi?id=18337
by Frank Gruman Sept. 9, 2009

Sept. 9, 2009

I have been using wine for various tools and utilities at work and home for some time now. Recently I tried to use wine to run the VMware Infrastructure Client and ran into bug 18337 (http://bugs.winehq.org/show_bug.cgi?id=18337) I am pasting my comments on that bug here to avoid repetition (http://bugs.winehq.org/show_bug.cgi?id=18337#c4) <paste> So - I looked through the code (current git @1.1.29) and compared to the 1.0 release (because of comment 1) and did not see that CERT_CHAIN_POLICY_SSL was ever implemented. Looking at chain.c, line 1886-1902 I can see the switch-case statement where this would have been handled. The problem I ran into while trying to keep up with the code was figuring out what the verify_* methods are trying to do. I'd really like to see this work and may have some spare cycles to help out. The problem is that I don't understand everything happening in these methods - can I get some pointers to what is happening or what should happen in the yet to be created verify_ssl_policy() method? </paste> Regards, Frank

2 3

ddraw: Added support for WINED3DFMT_X8L8V8U8, WINED3DFMT_R8G8B8A8_SNORM and WINED3DFMT_R16G16_SNORM to PixelFormat_WineD3DtoDD
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 9, 2009

Sept. 9, 2009

Stephan, All the patches proposed to bug #16559 forget one thing: it cannot be right to patch only PixelFormat_WineD3DtoDD without patching its converse function in the same file, PixelFormat_DD2WineD3D. There's no gain in silencing a fixme by introducing internal inconsistency in the source code. I had my own patch which changed both but for X8L8V8U8 only, but never published it because I observed no visual difference in the one app I tested, and had no time for 3 other ones I own, nor the other formats. I'm left wondering which of the pixelformats actually produces a visual difference as e.g. in comment #27. BTW, I suggest you submit individual patches, one per format. Regards, Jörg Höhle

2 1

Re: CPPCheck for Sept 8th
by chris ahrendt Sept. 9, 2009

Sept. 9, 2009

Nicolas Le Cam wrote: > 2009/9/9 Alexandre Julliard <julliard(a)winehq.org>: >> chris ahrendt <celticht32(a)yahoo.com> writes: >> >>> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd >> This is the only one that looks a real bug, all the rest are false >> positives. Please filter them out from future reports. >> >> -- >> Alexandre Julliard >> julliard(a)winehq.org >> >> >> > > Not necessary false positives. Errors in dlls/msvcrt/tests/file.c, for > example, are real but expected errors, as it's the purpose of the test > to see how it behaves on Windows in such situation. > So continue to send everything then? Since I have been running them the size has not really been that large... just let me know what you want me to send and I will send it in... Chris

2 1