January 2004 - Wine-Devel - list.winehq.org

Re: The part of AlphaBlend in msimg32.dll is now coded.

by Alexandre Julliard

taro-x(a)justsystem.co.jp writes: > The part of AlphaBlend in msimg32.dll is now coded. > > Changelog: > > * dlls/gdi/driver.c, dlls/gdi/gdi32.spec, > * dlls/gdi/enhmfdrv/init.c, dlls/gdi/mfdrv/init.c, > * dlls/msimg32/msimg32.spec, dlls/msimg32/msimg32_main.c, > * dlls/x11drv/bitblt.c, dlls/x11drv/x11drv.spec, > * include/gdi.h, include/wingdi.h, graphics/painting.c > > The part of AlphaBlend() in msimg32.dll is now coded. This is making incorrect assumptions about the image format. You have to use the X image RGB masks into account to extract the color components. -- Alexandre Julliard julliard(a)winehq.com

Jan. 27, 2004

Re: Wine history draft

by Dimitrie O. Paun

On August 6, 2003 01:51 pm, Brian Vincent (C) wrote: > I put together the following: > http://users.theshell.com/~vinn/wine-history.html [...] > Comments / suggestions / criticisms? Yeah, what are we waiting for? :) This stuff looks good, let's get it on the site, and update it as time goes on when (1) new interesting things happen, and/or (2) we discover more stuff from the past. But we can do that in patch form, no? -- Dimi.

Jan. 27, 2004

wine/arts won't build with arts > 1.1.90

by sean

artsc-config in arts > 1.1.90 has: --cflags) flags="$flags -I$includedir/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include " When you try to build Wine this gives an error in winearts: make[2]: Entering directory `/usr/src/redhat/BUILD/wine-20040121/dlls/winmm/winearts' ../../../tools/makedep -I. -I. -I../../../include -I../../../include -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -C. arts.c audio.c Unknown option '-pthread' I've worked around it by changing artsc-config, but It seems a better fix is needed. sean

Jan. 27, 2004

Re: 16bit app calls wineps.drv, but wine has wineps.dll (missing alias?)

by Alexandre Julliard

"ceztko\(a)libero\.it" <ceztko(a)libero.it> writes: > I have a 16 bit app that have a older printer initialization mechanism: it loads > the printer driver reading its name from win.ini,adding ".DRV" to it. This is a > problem, cause the builtin postscript driver is called wineps.dll in wine, and > the apps quits with the VB Error (482 run-time error: Printer error). > I tryed to fix this making synlinks to wineps.dll.so in /etc/lib/wine/lib/wine, > but the problem remains. > > The debug output doesn't need comments: > > err:module:NE_LoadBuiltinModule loaded .so but dll wineps.drv still not found That's because the app expects a 16-bit driver. You should use "wineps16" instead of "wineps" in your win.ini (of course depending on what the app actually wants to do with the driver it may not work; but at least it should load). -- Alexandre Julliard julliard(a)winehq.com

Jan. 26, 2004

16bit app calls wineps.drv, but wine has wineps.dll (missing alias?)

by ceztko＠libero.it

I have a 16 bit app that have a older printer initialization mechanism: it loads the printer driver reading its name from win.ini,adding ".DRV" to it. This is a problem, cause the builtin postscript driver is called wineps.dll in wine, and the apps quits with the VB Error (482 run-time error: Printer error). I tryed to fix this making synlinks to wineps.dll.so in /etc/lib/wine/lib/wine, but the problem remains. The debug output doesn't need comments: err:module:NE_LoadBuiltinModule loaded .so but dll wineps.drv still not found I verifyed this using a similar configuration in a real windows installation (renaming printerdriver.drv to .dll, leaving "printerdriver" with no ext in win.ini). In this way, the app quits with the same error. I'm sure the app is NOT calling registry to get the printer configuration (monitored it wit regmon) There are other 2 old threads with similar (read indentical) problem: http://www.winehq.org/hypermail/wine-users/2001/04/0515.html http://www.winehq.org/hypermail/wine-devel/2001/04/0164.html, but no resolution is proposed. I supposed is missing the alias wineps.drv --> wineps.dll, similarly wineps16.drv --> wineps.dll. Someone told me symlinks in /usr/lib/wine/lib/wine should work....but... This is what i have done: -rw-r--r-- 1 root root 1815919 Jan 26 00:14 wineps.dll.so lrwxrwxrwx 1 root root 13 Jan 26 19:06 wineps.drv.so -> wineps.dll.so lrwxrwxrwx 1 root root 13 Jan 26 19:07 wineps16.dll.so -> wineps.dll.so lrwxrwxrwx 1 root root 13 Jan 26 00:14 wineps16.drv.so -> wineps.dll.so The error and debugmsg are the same. I suppose (and hope..) wine loader manages alias in a different way. Thanks! P.S.: i also post this at bugzilla, http://bugs.winehq.org/show_bug.cgi?id=1967 Not sure it's a real bug, anyway..

Jan. 26, 2004

Re: [ddraw] asynchronous screen updates

by Lionel Ulmer

> Here are my changes: > > - User_add_dirty_rect is now an asynchronous equivalent of > User_copy_to_screen. It adds the rectangle to the list of dirty rectangles > and signal the update thread that there is some work to do. > - update thread calls User_get_dirty_rect to iterate over the list of dirty > rectangles > - current "naïve" algoritm keeps only one rectangle which is a union of all > dirty rectangles, so it tends to redraw too much, but better algoritms may be > implemented > - removed now unused lastlockrect variable, and the code which updates it > > I attached the patch for your reviews, comments, suggestions. The only comment I have on the patch is that you are using the rectangle from the 'User_DirectDrawSurface_unlock_update' code. The big problem here is that for old DirectX versions (versions 1 to 3), the lock rectangle was not repeated in the Unlock call (it was only present in the Lock code). So, basically, you will always force a full redraw for these old DirectX versions. So, the best would be to add the dirty rectangles in the Lock calls (if we are not in READONLY mode). A part from that, the patch looks nice. Same comments as in my other mails about contributors :-) Lionel PS: all these dirty region handling should be factorized as I did the same kind of hacks in the D3D code to speed up transfer between 2D and 3D buffers. -- Lionel Ulmer - http://www.bbrox.org/

Jan. 26, 2004

Re: DIB_DirectDrawSurface_BltFast signed/unsigned comparision bug

by Lionel Ulmer

> I just added explicit casting to int where needed. It didn't fix the mouse > trails, but previously missing mouseover effect on icons at the main screen > appeared, so I guess it is a change in the right direction :) While your patch is certainly OK, if 'ddesc.dwWidth-dstx' is lower than zero, it means that there is nothing to do (as the destination X coordinate is out of the screen). Same for the source rectangle. So could you try rewriting your patch with something like that : if (ddesc.dwWidth<=dstx) return DD_OK; (and same for Y and srcs). And check if it gives you the same result as your previous patch. Maybe it's some added code, but well, it will be a bit cleaner IMHO. Anyway, thanks for fixing bugs in the DDraw code, we certainly needs more contributors :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 26, 2004

Re: Strange debug message in programs/winedbg/info.c

by Sami Aario

Patch submitted. ----- Original Message ----- From: "Eric Pouech" <pouech-eric(a)wanadoo.fr> To: "Sami Aario" <sami.aario(a)surfeu.fi> Cc: <wine-devel(a)winehq.org> Sent: Saturday, January 24, 2004 10:57 PM Subject: Re: Strange debug message in programs/winedbg/info.c > Sami Aario a écrit : > > Hi, > > > > The debugger kept messing up my output because of a missing > > newline. This patch fixes that. However, the condition checks for > > first_dll, but the output says first_option. They can't both be right. > > So which one should it be? > > It should be first_dll in both cases. > A+ >

Jan. 26, 2004

Re: Lotus Notes broken in recent CVS

by Mike McCormack

Hi Paul, The purpose of patch 10547 was to link the load order of 16bit dlls and their 32bit parents. eg. commctrl will only be loaded as a native dll if comctl32 is a native dll. You can probably solve the problem by adjusting the DllOverrides section in your wine config file. To do this, you first need to find which 16 bit dll's load order changed due to the patch, then adjust the load order of it's parent dll. Mike Paul R Streitman wrote: > I tested the patches by taking an 01/03 CVS snapshot and replacing the > relevant parts from an 01/02 snapshot rather than trying to un-patch the > files. Using that technique, I found that the changes in patch 10547 > (which required patch 10552 to compile) cause the problem that I am seeing > with Lotus Notes. That problem still occurs with current CVS. > > Thanks, > Paul

Jan. 26, 2004

Re: imm32 ImmDisableIME stub concern

by Jason Edmeades

Alexandre Julliard wrote: >Jason Edmeades <us(a)the-edmeades.demon.co.uk> writes: > > >>However, looking at a history of the IMM32 spec file, it was added >>(version 1.10) and removed (version 1.11). Has anyone any idea why, >>and would anyone have any strong objections to me re-stubbing it? >> >> >It's apparently collateral damage of the removal of Hidenori's >code. Feel free to add it again. > > Thanks for the info - I'm putting together a set of patchs to fix the startup of the game in question, and will submit them once I have a little more progress to report. Jason

Jan. 26, 2004