August 2007 - Wine-devel - list.winehq.org

Re: try2:patch for sysparams.c
by L. Rahyen 29 Aug '07

29 Aug '07

On Wednesday August 29 2007 09:15, Ivan Sinitsin wrote: > Has corrected "logpixels=72" to " logpixels = 96 " and has changed the > indentation > > This patch adds an opportunity for fonts of the menu, statusbar and > messages to increase depending on logpixels. > > > Changelog: > This patch does a font for the menu,statusbar and messages dependent from > logpixels. With your patch applied to current GIT head I have too large fonts in all menus even in notepad if for example I have set logpixels to 120 dpi using winecfg. "Too large" means MUCH larger than in, for example, winecfg itself (you need to restart the program to see the effect). See atached snapshot to see how notepad looks like with your patch if I set 120 dpi in winecfg. Font size is ridiculously big! For testing I have used clean WINE with your patch only and clean WINEPREFIX. In Windows and current WINE without your patch in clean WINEPREFIX all fonts are of same size no matter what DPI I set in LogPixels or winecfg and this is correct behavior. What application you are trying to fix?

1 0

re: getting started...
by Dan Kegel 29 Aug '07

29 Aug '07

Ed wrote: >I'm brand new to the list and would like to get a Windows application that >I wrote (uCon) to work with wine/winelib. I've submitted it to the application >database. I've tried it on Wine and it *almost* works, so I'd like to pursue >this further by building uCon with Winelib (as is recommended somewhere >in the documentation). Egads. Where does it recommend that? Using winelib is a terrible idea unless you really need it (e.g. on non-x86 platforms, it's your only option). The downside is that your app suddenly becomes very fragile with respect to user updates of wine; they need a synchronized version of your app that matches their version of Wine. I've seen this happen, and it's not pretty. Also, this means double the QA and release trouble. The Right Thing To Do IMHO is just make your app and wine work better together, not use winelib. So your next move is to file bugs in http://bugs.winehq.org describing how your app doesn't work with wine, and work with us to solve them. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 7

Re: winex11.drv[2/2]: Support GdiAlphaBlend with blendfn.AlphaFormat == 0 (fixes bug #9262)
by Alexandre Julliard 29 Aug '07

29 Aug '07

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > @@ -1600,6 +1603,16 @@ #endif > for(; y >= y2; y--) { > memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > widthSrc * 4); > + if (!(blendfn.AlphaFormat & AC_SRC_ALPHA)) > + { > + int i; > + RGBQUAD *quad = (RGBQUAD *)dstbits; > + for (i = 0; i < widthSrc; i++) > + { > + quad->rgbReserved = blendfn.SourceConstantAlpha; > + quad++; > + } > + } It would be nicer to have a separate loop for that case, and do everything in one go instead of patching up the values after the copy. Also RGBQUAD is meant for color tables, it's not an appropriate type for the bitmap data itself. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: static controls should have a clipping region set while sending the WM_CTLCOLORSTATIC (3rd try, with testcase, fixes bug #9195)
by Alexandre Julliard 29 Aug '07

29 Aug '07

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > Is there something wrong with this patch? You should use IntersectClipRect or ExtSelectClipRgn to avoid intermediate copies. Also GetClipRgn doesn't return a region code so checking it against NULLREGION is wrong. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: patch for sysparam.c
by Paul Vriens 29 Aug '07

29 Aug '07

Ivan Sinitsin wrote: > This patch adds an opportunity for fonts of the menu, statusbar and messages > to increase depending on logpixels. > > > Changelog: > This patch does a font for the menu,statusbar and messages dependent from > logpixels. > > > ------------------------------------------------------------------------ > > With the latest release winecfg can set this value. The default there is 96 and the range is 96..120. How does that relate to the 72 in your code? : +if (!RegQueryValueExW( myhKey, log_pixels, NULL, &type, + (LPBYTE) &logpixels, &size )==ERROR_SUCCESS) + logpixels=72; Cheers, Paul.

1 0

Re: patch for sysparam.c
by Robert Shearman 29 Aug '07

29 Aug '07

Ivan Sinitsin wrote: > This patch adds an opportunity for fonts of the menu, statusbar and messages > to increase depending on logpixels. > > > +size=sizeof(DWORD); > +RegOpenKeyExW( HKEY_LOCAL_MACHINE, registry_key, > + 0, KEY_QUERY_VALUE, &myhKey ); > +if (!RegQueryValueExW( myhKey, log_pixels, NULL, &type, > + (LPBYTE) &logpixels, &size )==ERROR_SUCCESS) > + logpixels=72; > +ncm.lfMenuFont.lfHeight=-MulDiv(ncm.lfMenuFont.lfHeight,logpixels,72); > +RegCloseKey( myhKey ); You're missing some indentation here. -- Rob Shearman

1 0

Re: [PATCH] Support for animated cursors
by H. Verbeet 28 Aug '07

28 Aug '07

On 28/08/07, Trent Waddington <trent.waddington(a)gmail.com> wrote: > On 8/28/07, H. Verbeet <hverbeet(a)gmail.com> wrote: > > You should use the timing and frame sequence info from the .ani. > > Also, Xcursor actually supports proper animated cursors, so it would > > be better to handle the animation in winex11.drv > > Can you please direct me to some example code of defining and using an > animated cursor with Xcursor? > http://repo.or.cz/w/wine/hacks.git?a=blob;f=dlls/winex11.drv/mouse.c;h=b344… should be a decent start. > > As explained in the comment at the top of cursoricon.c, you can't do > > that, because it will break win16 applications. > > Umm.. what comment would that be? This one: > * Cursors and icons are stored in a global heap block, with the > * following layout: > * > * CURSORICONINFO info; > * BYTE[] ANDbits; > * BYTE[] XORbits; > * > * The bits structures are in the format of a device-dependent bitmap. > * > * This layout is very sub-optimal, as the bitmap bits are stored in > * the X client instead of in the server like other bitmaps; however, > * some programs (notably Paint Brush) expect to be able to manipulate > * the bits directly :-( > Should I replace hNext with a CURSORICONINFO *? This is what I had > initially.. or should I be using something else? Or should I just > make it an BYTE bFrames and append multiple data blocks to the end of > the CURSORICONINFO struct? > Well, what it comes down to is that you can't change the cursor memory layout for win16 applications at all, which complicates things a bit.

3 12

[PATCH] the function called is cdecl, not WINAPI
by Juan Lang 28 Aug '07

28 Aug '07

Hi Marcus, > the function called is cdecl, not WINAPI No it isn't. It's declared that way, but it's wrong. Calling it that way in Windows crashes. That's why I sent this patch: http://www.winehq.org/pipermail/wine-cvs/2007-August/035682.html --Juan

2 2

Re: winex11.drv: test for out-of-bound src coordinates in GdiAlphaBlend (fixed, with testcase, fixes bug #7428)
by Alexandre Julliard 28 Aug '07

28 Aug '07

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > The previous version didn't take into account that dib.dsBmih.biHeight > can be negative. You should check for negative widthSrc/heightSrc too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: tests: some values of _mbctype are dependent on the version of Windows
by Alexandre Julliard 28 Aug '07

28 Aug '07

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > @@ -144,10 +144,18 @@ static int result_cp_949_mbctype[] = { 0 > static int result_cp_950_mbctype[] = { 0x0,65, 0x8,1, 0x18,26, 0x8,6, 0x28,26, 0x8,4, > 0x0,2, 0x4,32, 0xc,94, 0,1 }; > > +/* these characters may differ on different Windows versions */ > +static int fuzzy_cp_1252_mbctype[] = {142, 158, 170, 181, 186, -2}; > +static int fuzzy_cp_1250_mbctype[] = {131, 141, 142, 143, 157, 158, 159, 163, 165, 170, 175, 179, 181, 185, 186, 188, 190, 191, -2}; > +static int fuzzy_cp_932_mbctype[] = { -2 }; > +static int fuzzy_cp_936_mbctype[] = { -2 }; > +static int fuzzy_cp_949_mbctype[] = { -2 }; > +static int fuzzy_cp_950_mbctype[] = { -2 }; What this shows is that the exact values don't matter, and that apps are very unlikely to depend on them. This also means that having slightly different tables in Wine is not a problem, so I'd suggest to not try to test every single char, but just pick a few that are the same on all platforms. -- Alexandre Julliard julliard(a)winehq.org

1 0