wine-devel

wine-devel@winehq.org

84471 discussions

slackware download
by hippy hip 20 Feb '06

20 Feb '06

hiya- sorry if this is the wrong place to post this - wasn't sure where to send it- anyway- if you go to your webpage- click on 'download' -then go to slackware to get the install file for slack... you get a error page telling you the servers down. this has been going on for the last 3 days now. has the page actually been down the last 3 days? or is the link to the page wrong? just letting you know. -want to check out 0.9.8 ;) thanks for your time- __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Wine graphics backends
by Segin 19 Feb '06

19 Feb '06

I wans wondering, have any of you ever attepted to make a Wine graphics backend? I thought about making one for either SDL or DirectFB, it would be useful, cause you could do Wine without the drugery of X11. (has anyone read the X Windows Disaster recently?) Also, using the Linux framebuffer would also have a number of advantages, in areas od speed and memory size

1 0

Re: add configure options to control support of misc packages
by Mike McCormack 19 Feb '06

19 Feb '06

Mike Frysinger wrote: > this patch adds a bunch of --without-FOO options to configure ... some are > very simple (like the sane/xml checks) while some others are slightly more > involved What's the point of crippling Wine like this? Mike

2 8

GL mipmap question
by Stefan Dösinger 19 Feb '06

19 Feb '06

Hi, I'm trying to get the Mipmap example of the DX7 sdk running, and I've run into a problem: OpenGL requires mipmap levels down to 1x1 (according to the red book), but DirectX can provide less levels, e.g. the smallest with 16x16. If I use such a mipmaped texture from d3d in opengl, this results in a white texture image. I've verified this with a GL-only program. Is there any way to such a texture with opengl, or do I need other tricks? I could use gluBuild2DMipmaps() to create the smaller textures, but I dislike that way. Stefan

1 1

Re: NTDLL/loader.c: Remove spaces at end of name in import_dll
by Vitaliy Margolen 18 Feb '06

18 Feb '06

Saturday, February 18, 2006, 11:16:10 AM, Uwe Bonnes wrote: > Changelog: > ntdll/loader.c import_dll() > Remove spaces at end of name retrieved with get_rva( module, > descr->>Name ) > +/* Overwrite spaces at end of buffer with NULL */ > +inline static void skip_spaces(WCHAR *buffer, size_t len) > +{ > + while (buffer[len -2] == (WCHAR)' ') > + { > + buffer[len -2] = 0; > + len --; > + } > +} This is wrong (number of errors). It should look something like this: while (len > sizeof(WCHAR)&& buffer[len/sizeof(WCHAR) - 1] == ' ') { len -= sizeof(WCHAR); buffer[len/sizeof(WCHAR)] = 0; } Vitaliy Margolen

2 2

Re: D3D8 Texture -> WineD3D
by Stefan Dösinger 18 Feb '06

18 Feb '06

> This patch (based on Oliver Stieber his d3d8 code) moves d3d8's texturing > code over to WineD3D. The patch adds new datatypes, replaces a few texture > creation calls with wined3d code and updates code to work with the new > datatypes. Unfortunately the patch is quite big because there's one texture > base type of which all other texture types are instances. Just one question: Wouldn't it be a better idea to replace the d3d8 directory in one go? I know that it's against the rule of sending small patches, but I think an interface for interface move makes more troubles than it solves(like the header inclusion, for example). If a game breaks during that move, I'm afraid we have to fully debug it with WineD3D in any case. The reason why I'm asking this is the ddraw move. I plan to make some wined3d_types.h additions in small patches, then some wined3d additions(small patches too) and then replace the whole ddraw directory in one patch, because the original code and the new ddraw code don't have much in common. This saves a lot of hassle without provocing troubles which wouldn't appear otherwise. Stefan

2 1

Re: menu drawing fixes -- RESENT
by Alexandre Julliard 18 Feb '06

18 Feb '06

Rein Klazes <wijn(a)wanadoo.nl> writes: > Updating drawing of menu items with bitmaps and/or strings: > - implemented MNS_NOCHECK menu style; > - support HBMMENU_CALLBACK bitmaps in menu bars; > - replaced some #defined constants by values calculated from windows > metrics; > - added a lot of tests on menu item sizes and the position of the bitmap > and making them pass on Wine. Could you please send separate fixes as separate patches? -- Alexandre Julliard julliard(a)winehq.org

1 0

Possibly crazy idea to deal with memory layout problems once and for all
by Troy Rollo 18 Feb '06

18 Feb '06

I have been looking at a problem that has arisen in recent versions, particularly when using some D3D games, in which the virtual address space above TASK_UNMAPPED_BASE becomes fragmented to the extent that eventually you get an out of memory condition, even though you still have well over a gigabyte free (even in a contiguous block!). This has led to some people using the attached hack (first attachment) to get their D3D games to work. After considering a lot of approaches to this problem that did not seem to get anywhere productive, it seemed that the only way to resolve it would be to get in between the application and any libraries, and the kernel. The solution I came up with is somewhat rude, but if we assume that any libraries that Wine uses only call mmap() and associated calls via the C library, then it may well do the trick, plus make it possible to implement other virtual memory APIs more effectively (and in a couple of cases eliminate calls to wineserver). If wine_preloader were extended to have its own implementation of all the friends of mmap(), and to have its own implementation of the dynamic linker, then in principle it could make sure only its mmap (and not the C library's) is called. An even more aggressive approach might be to load the C library and stick jumps into its mmap that redirect to the preloader's versions. The preloader's mmap would keep track of mappings on its own and when it receives an mmap with a start address of "NULL", decides on its own what base address to use. Any thoughts?

2 2

Re: fixup previous DESTDIR commit
by Alexandre Julliard 17 Feb '06

17 Feb '06

Mike Frysinger <vapier(a)gentoo.org> writes: > the previous commit which added DESTDIR support to cvs was not exactly the > same patch i posted ... this was both good and bad because on one hand an > additional line i missed in programs/make_progs was fixed but on the other > the programs/Makefile.in file now generates an incorrect link What's incorrect about the link? -- Alexandre Julliard julliard(a)winehq.org

2 3

DreamWeaver 8 Issues
by Ian Kellogg 17 Feb '06

17 Feb '06

I tried to install DreamWeaver 8 with WINE 0.9.8 and I get quite alot of errors. [ian@minuet Desktop]$ wine Dreamweaver8-en.exe fixme:msi:MsiInstallProductW L"C:\\windows\\Downloaded Installations\\Macromedia Dreamweaver 8\\Macromedia_Dreamweaver_8.msi" L"" fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:sync:SetNamedPipeHandleState 0xdc 0x61853a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0xdc 0x4b520a98 (nil) (nil) fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:sync:SetNamedPipeHandleState 0xe0 0x61853a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0xd0 0x61853a98 (nil) (nil) fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:sync:SetNamedPipeHandleState 0xd4 0x8122a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0xf4 0x378cba98 (nil) (nil) fixme:ole:RpcChannelBuffer_GetDestCtx (0x4b520734,0x4b520738), stub! fixme:sync:SetNamedPipeHandleState 0xf4 0x5b17a98 (nil) (nil) fixme:ole:NdrConvert (pStubMsg == ^0x92240c, pFormat == ^0x2d841ba): stub. fixme:ole:NdrConvert (pStubMsg == ^0x4b5206c0, pFormat == ^0x2d841ba): stub. err:ole:get_unmarshaler_from_stream Failed to read common OBJREF header, 0x00000000 fixme:ole:RpcChannelBuffer_GetDestCtx (0x4b520730,0x4b520734), stub! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:sync:SetNamedPipeHandleState 0x80 0x378cba98 (nil) (nil) fixme:ole:NdrConvert (pStubMsg == ^0x922408, pFormat == ^0x2d841c8): stub. fixme:ole:NdrConvert (pStubMsg == ^0x4b5206bc, pFormat == ^0x2d841c8): stub. fixme:sync:SetNamedPipeHandleState 0x80 0x5b17a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0xc8 0x1e301a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0xc8 0x8122a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0xd4 0x8122a98 (nil) (nil) fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0092ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 7f80ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0092ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 7f80ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 7f80ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 7f80ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0092ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 7f80ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 7f82ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 7f80ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0092ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 7f82ffff fixme:sync:SetNamedPipeHandleState 0xd0 0x8122a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0xd0 0x5b17a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0xd0 0x1e301a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0xd0 0x8122a98 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0x94 0x1e301a98 (nil) (nil) fixme:ole:RpcChannelBuffer_GetDestCtx (0x4b520778,0x4b52077c), stub! fixme:sync:SetNamedPipeHandleState 0xfc 0x5b17a98 (nil) (nil) fixme:ole:NdrConvert (pStubMsg == ^0x92f2c0, pFormat == ^0x2d841da): stub. fixme:sync:SetNamedPipeHandleState 0x11c 0x50ae4a98 (nil) (nil) err:ntdll:RtlpWaitForCriticalSection section 0x7f7a4048 "compobj.c: apartment" wait timed out in thread 0012, blocked by 002c, retrying (60 sec) err:rpc:I_RpcReceive we got fault packet with status 6be err:ole:ifproxy_release_public_refs IRemUnknown_RemRelease failed with error 0xc0000194 fixme:ole:NdrConvert (pStubMsg == ^0x4b520704, pFormat == ^0x2d841da): stub. err:msi:ACTION_ProcessUISequence Execution halted due to error (1603) fixme:sync:SetNamedPipeHandleState 0xa4 0x61853a98 (nil) (nil) Not sure what is with all the Hex but hopefully someone will know what to do with the information

4 3

x11drv: [PATCH] for X_SetClipRectangles clipping crash
by Jason Green 17 Feb '06

17 Feb '06

While running Quickbooks Pro 99, WINE would crash every time I changed an existing transaction and clicked "Next" or "Prev", then answered Yes to save changes. It gave the following error: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 59 (X_SetClipRectangles) Serial number of failed request: 83724 [<--- that number changed every time] Current serial number in output stream: 87435 [<--- that number changed every time, too] (it also still gives quite a few of these errors elsewhere in the app, but I don't know if it's related): err:x11drv:X11DRV_CreateWindow invalid window height -2 The line it was crashing on was in x11drv/clipping.c: XSetClipRectangles( gdi_display, physDev->gc, physDev->org.x, physDev->org.y, (XRectangle *)data->Buffer, data->rdh.nCount, YXBanded ); After digging around a little, I found this Xlib programming manual entry: http://tronche.com/gui/x/xlib/GC/convenience-functions/XSetClipRectangles.h… Here's what it has to say on the last argument about clipping rectangle sorting: "If known by the client, ordering relations on the rectangles can be specified with the ordering argument. This may provide faster operation by the server. If an incorrect ordering is specified, the X server may generate a BadMatch error, but it is not required to do so. If no error is generated, the graphics results are undefined. Unsorted means the rectangles are in arbitrary order. YSorted means that the rectangles are nondecreasing in their Y origin. YXSorted additionally constrains YSorted order in that all rectangles with an equal Y origin are nondecreasing in their X origin. YXBanded additionally constrains YXSorted by requiring that, for every possible Y scanline, all rectangles that include that scanline have an identical Y origins and Y extents." Changing that last parameter from YXBanded to Unsorted has completely resolved my problem, and it doesn't seem to have broken anything else that I've noticed (Firefox, Mozilla-suite, winefile all seem to run just as well as before). However, I'm sure you all know more than I do about how that particular function works. The code for that function hasn't changed at least since the 20031212 CVS. Either way, I'm submitting a small one-line patch. Please let me know if you think this will cause issues elsewhere. Thanks!

2 1

PATCH/RFC: imagelist rewrite to use N x M grid
by Marcus Meissner 17 Feb '06

17 Feb '06

Hi, This patch is a rewrite of the imagelist handling to not use a Nx1 grid, but a NxM grid with M definable in the source (currently 4). I have tested against winrar, "file open" and "make check". It is not completely regression tested, so I am not wanting to submit it right now. But I welcome comments. :) Ciao, Marcus Index: dlls/comctl32/imagelist.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/imagelist.c,v retrieving revision 1.101 diff -u -r1.101 imagelist.c --- dlls/comctl32/imagelist.c 14 Nov 2005 11:20:10 -0000 1.101 +++ dlls/comctl32/imagelist.c 28 Nov 2005 06:21:43 -0000 @@ -55,6 +55,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(imagelist); +#define PER_ROW 4 #define MAX_OVERLAYIMAGE 15 @@ -84,6 +85,12 @@ return himl && himl->magic == IMAGELIST_MAGIC; } +static DWORD index2x(INT index, INT cx) { return cx*(index/PER_ROW); } +static DWORD index2y(INT index, INT cy) { return cy*(index%PER_ROW); } + +static DWORD count2x(INT count, INT cx) { + return cx*((count+PER_ROW-1)/PER_ROW); +} /************************************************************************* * IMAGELIST_InternalExpandBitmaps [Internal] @@ -93,6 +100,8 @@ * PARAMS * himl [I] handle to image list * nImageCount [I] number of images to add + * cx [I] width of image + * cy [I] height of image * * RETURNS * nothing @@ -113,21 +122,22 @@ if (cy == 0) cy = himl->cy; nNewCount = himl->cCurImage + nImageCount + himl->cGrow; - nNewWidth = nNewCount * himl->cx; + nNewWidth = count2x(nNewCount,himl->cx); - TRACE("Create expanded bitmaps : himl=%p x=%d y=%d count=%d\n", himl, nNewWidth, cy, nNewCount); + TRACE("Create expanded bitmaps : himl=%p x=%d y=%d count=%d\n", himl, + nNewWidth, cy*PER_ROW, nNewCount); hdcBitmap = CreateCompatibleDC (0); - hbmNewBitmap = ImageList_CreateImage(hdcBitmap, himl, nNewWidth, cy); + hbmNewBitmap = ImageList_CreateImage(hdcBitmap, himl, nNewWidth, cy*PER_ROW); if (hbmNewBitmap == 0) - ERR("creating new image bitmap (x=%d y=%d)!\n", nNewWidth, cy); + ERR("creating new image bitmap (x=%d y=%d)!\n", nNewWidth, cy*PER_ROW); if(himl->cCurImage) { hbmNull = SelectObject (hdcBitmap, hbmNewBitmap); - BitBlt (hdcBitmap, 0, 0, himl->cCurImage * himl->cx, cy, - himl->hdcImage, 0, 0, SRCCOPY); + BitBlt (hdcBitmap, 0, 0, count2x(himl->cCurImage,himl->cx), + cy*PER_ROW, himl->hdcImage, 0, 0, SRCCOPY); SelectObject (hdcBitmap, hbmNull); } SelectObject (himl->hdcImage, hbmNewBitmap); @@ -136,7 +146,7 @@ if (himl->flags & ILC_MASK) { - hbmNewBitmap = CreateBitmap (nNewWidth, cy, 1, 1, NULL); + hbmNewBitmap = CreateBitmap (nNewWidth, cy*PER_ROW, 1, 1, NULL); if (hbmNewBitmap == 0) ERR("creating new mask bitmap!\n"); @@ -144,8 +154,8 @@ if(himl->cCurImage) { hbmNull = SelectObject (hdcBitmap, hbmNewBitmap); - BitBlt (hdcBitmap, 0, 0, himl->cCurImage * himl->cx, cy, - himl->hdcMask, 0, 0, SRCCOPY); + BitBlt (hdcBitmap, 0, 0, count2x(himl->cCurImage,himl->cx), + cy*PER_ROW, himl->hdcMask, 0, 0, SRCCOPY); SelectObject (hdcBitmap, hbmNull); } SelectObject (himl->hdcMask, hbmNewBitmap); @@ -179,7 +189,7 @@ { HDC hdcBitmap; INT nFirstIndex, nImageCount; - INT nStartX; + INT i; BITMAP bmp; HBITMAP hOldBitmap; @@ -192,43 +202,42 @@ IMAGELIST_InternalExpandBitmaps (himl, nImageCount, bmp.bmWidth, bmp.bmHeight); - nStartX = himl->cCurImage * himl->cx; - hdcBitmap = CreateCompatibleDC(0); - hOldBitmap = SelectObject(hdcBitmap, hbmImage); - /* Copy result to the imagelist - */ - BitBlt (himl->hdcImage, nStartX, 0, bmp.bmWidth, bmp.bmHeight, - hdcBitmap, 0, 0, SRCCOPY); - - if(himl->hbmMask) - { - HDC hdcTemp; - HBITMAP hOldBitmapTemp; - - hdcTemp = CreateCompatibleDC(0); - hOldBitmapTemp = SelectObject(hdcTemp, hbmMask); + for (i=himl->cCurImage;i<himl->cCurImage+nImageCount;i++) { + /* Copy result to the imagelist */ + BitBlt (himl->hdcImage, index2x(i,himl->cx), index2y(i,himl->cy), + himl->cx, himl->cy, hdcBitmap, himl->cx*(i-himl->cCurImage), 0, SRCCOPY); - BitBlt (himl->hdcMask, - nStartX, 0, bmp.bmWidth, bmp.bmHeight, - hdcTemp, - 0, 0, - SRCCOPY); + if(himl->hbmMask) + { + HDC hdcTemp; + HBITMAP hOldBitmapTemp; - SelectObject(hdcTemp, hOldBitmapTemp); - DeleteDC(hdcTemp); + hdcTemp = CreateCompatibleDC(0); + hOldBitmapTemp = SelectObject(hdcTemp, hbmMask); - /* Remove the background from the image - */ - BitBlt (himl->hdcImage, - nStartX, 0, bmp.bmWidth, bmp.bmHeight, - himl->hdcMask, - nStartX, 0, - 0x220326); /* NOTSRCAND */ + BitBlt (himl->hdcMask, + index2x(i,himl->cx), index2y(i,himl->cy), + himl->cx, himl->cy, + hdcTemp, + himl->cx*(i-himl->cCurImage), 0, + SRCCOPY); + + SelectObject(hdcTemp, hOldBitmapTemp); + DeleteDC(hdcTemp); + + /* Remove the background from the image + */ + BitBlt (himl->hdcImage, + index2x(i,himl->cx), index2y(i,himl->cy), + bmp.bmWidth, bmp.bmHeight, + himl->hdcMask, + index2x(i,himl->cx), index2y(i,himl->cy), + 0x220326); /* NOTSRCAND */ + } } - SelectObject(hdcBitmap, hOldBitmap); DeleteDC(hdcBitmap); @@ -278,12 +287,12 @@ INT WINAPI ImageList_AddMasked (HIMAGELIST himl, HBITMAP hBitmap, COLORREF clrMask) { - HDC hdcMask, hdcBitmap; - INT nIndex, nImageCount, nMaskXOffset=0; + HDC hdcBitmap; + INT nIndex, nImageCount; BITMAP bmp; HBITMAP hOldBitmap; - HBITMAP hMaskBitmap=0; COLORREF bkColor; + int i; TRACE("himl=%p hbitmap=%p clrmask=%lx\n", himl, hBitmap, clrMask); if (!is_valid(himl)) @@ -292,6 +301,8 @@ if (!GetObjectA (hBitmap, sizeof(BITMAP), &bmp)) return -1; + TRACE("bitmap is %d x %d, himl is %d x %d\n", + bmp.bmWidth, bmp.bmHeight, himl->cx, himl->cy); if (himl->cx > 0) nImageCount = bmp.bmWidth / himl->cx; else @@ -304,67 +315,55 @@ hdcBitmap = CreateCompatibleDC(0); - hOldBitmap = SelectObject(hdcBitmap, hBitmap); - if(himl->hbmMask) - { - hdcMask = himl->hdcMask; - nMaskXOffset = nIndex * himl->cx; - } - else - { - /* - Create a temp Mask so we can remove the background of - the Image (Windows does this even if there is no mask) - */ - hdcMask = CreateCompatibleDC(0); - hMaskBitmap = CreateBitmap(bmp.bmWidth, bmp.bmHeight, 1, 1, NULL); - SelectObject(hdcMask, hMaskBitmap); - nMaskXOffset = 0; - } + /* create monochrome image to the mask bitmap */ bkColor = (clrMask != CLR_DEFAULT) ? clrMask : GetPixel (hdcBitmap, 0, 0); - SetBkColor (hdcBitmap, bkColor); - BitBlt (hdcMask, - nMaskXOffset, 0, bmp.bmWidth, bmp.bmHeight, - hdcBitmap, 0, 0, - SRCCOPY); - SetBkColor(hdcBitmap, RGB(255,255,255)); - /*Remove the background from the image - */ - /* - WINDOWS BUG ALERT!!!!!! - The statement below should not be done in common practice - but this is how ImageList_AddMasked works in Windows. - It overwrites the original bitmap passed, this was discovered - by using the same bitmap to iterate the different styles - on windows where it failed (BUT ImageList_Add is OK) - This is here in case some apps rely on this bug - */ - BitBlt(hdcBitmap, - 0, 0, bmp.bmWidth, bmp.bmHeight, - hdcMask, - nMaskXOffset, 0, - 0x220326); /* NOTSRCAND */ - /* Copy result to the imagelist - */ - BitBlt (himl->hdcImage, - nIndex * himl->cx, 0, bmp.bmWidth, bmp.bmHeight, - hdcBitmap, - 0, 0, - SRCCOPY); + for (i=nIndex; i<himl->cCurImage; i++) { + if (himl->hbmMask) { + SetBkColor (hdcBitmap, bkColor); + + BitBlt (himl->hdcMask, + index2x(i,himl->cx), index2y(i,himl->cy), + himl->cx, himl->cy, + hdcBitmap, himl->cx*(i-nIndex), 0, + SRCCOPY); + + SetBkColor(hdcBitmap, RGB(255,255,255)); + /*Remove the background from the image + */ + /* + WINDOWS BUG ALERT!!!!!! + The statement below should not be done in common practice + but this is how ImageList_AddMasked works in Windows. + It overwrites the original bitmap passed, this was discovered + by using the same bitmap to iterate the different styles + on windows where it failed (BUT ImageList_Add is OK) + This is here in case some apps rely on this bug + */ + BitBlt(hdcBitmap, + himl->cx*(i-nIndex), 0, himl->cx, himl->cy, + himl->hdcMask, + index2x(i,himl->cx), index2y(i,himl->cy), + 0x220326); /* NOTSRCAND */ + } + /* Copy result to the imagelist + */ + BitBlt (himl->hdcImage, + index2x(i,himl->cx), index2y(i,himl->cy), + himl->cx, himl->cy, + hdcBitmap, + himl->cx*(i-nIndex), 0, + SRCCOPY); + } + /* Clean up */ + SelectObject(hdcBitmap, hOldBitmap); DeleteDC(hdcBitmap); - if(!himl->hbmMask) - { - DeleteObject(hMaskBitmap); - DeleteDC(hdcMask); - } - return nIndex; } @@ -478,19 +477,20 @@ /* image */ SelectObject (hdcBmp, hbmTempImage); StretchBlt (hdcBmp, 0, 0, himlSrc->cx, himlSrc->cy, - himlDst->hdcImage, iDst * himlDst->cx, 0, himlDst->cx, himlDst->cy, - SRCCOPY); + himlDst->hdcImage, index2x(iDst,himlDst->cx), index2y(iDst,himlDst->cy), + himlDst->cx, himlDst->cy, SRCCOPY); /* mask */ SelectObject (hdcBmp, hbmTempMask); StretchBlt (hdcBmp, 0, 0, himlSrc->cx, himlSrc->cy, - himlDst->hdcMask, iDst * himlDst->cx, 0, himlDst->cx, himlDst->cy, - SRCCOPY); + himlDst->hdcMask, index2x(iDst,himlDst->cx), index2y(iDst,himlDst->cy), + himlDst->cx, himlDst->cy, SRCCOPY); /* copy (and stretch) source to destination */ /* image */ - StretchBlt (himlDst->hdcImage, iDst * himlDst->cx, 0, himlDst->cx, himlDst->cy, - himlSrc->hdcImage, iSrc * himlSrc->cx, 0, himlSrc->cx, himlSrc->cy, - SRCCOPY); + StretchBlt (himlDst->hdcImage, index2x(iDst,himlDst->cx), index2y(iDst,himlDst->cy), + himlDst->cx, himlDst->cy, + himlSrc->hdcImage, index2x(iSrc,himlSrc->cx), index2y(iSrc,himlSrc->cy), + himlSrc->cx, himlSrc->cy, SRCCOPY); /* mask */ StretchBlt (himlDst->hdcMask, iDst * himlDst->cx, 0, himlDst->cx, himlDst->cy, himlSrc->hdcMask, iSrc * himlSrc->cx, 0, himlSrc->cx, himlSrc->cy, @@ -511,13 +511,17 @@ } else { /* copy image */ - StretchBlt (himlDst->hdcImage, iDst * himlDst->cx, 0, himlDst->cx, himlDst->cy, - himlSrc->hdcImage, iSrc * himlSrc->cx, 0, himlSrc->cx, himlSrc->cy, + StretchBlt (himlDst->hdcImage, + index2x(iDst,himlDst->cx), index2y(iDst,himlDst->cy), himlDst->cx, himlDst->cy, + himlSrc->hdcImage, + index2x(iSrc,himlSrc->cx), index2y(iSrc,himlSrc->cy), himlSrc->cx, himlSrc->cy, SRCCOPY); /* copy mask */ - StretchBlt (himlDst->hdcMask, iDst * himlDst->cx, 0, himlDst->cx, himlDst->cy, - himlSrc->hdcMask, iSrc * himlSrc->cx, 0, himlSrc->cx, himlSrc->cy, + StretchBlt (himlDst->hdcMask, + index2x(iDst,himlDst->cx), index2y(iDst,himlDst->cy), himlDst->cx, himlDst->cy, + himlSrc->hdcMask, + index2x(iSrc,himlSrc->cx), index2y(iSrc,himlSrc->cy), himlSrc->cx, himlSrc->cy, SRCCOPY); } @@ -597,15 +601,15 @@ himl->uBitsPixel = (UINT)GetDeviceCaps (himl->hdcImage, BITSPIXEL); if (himl->cMaxImage > 0) { - himl->hbmImage = ImageList_CreateImage(himl->hdcImage, himl, cx * himl->cMaxImage, cy); + himl->hbmImage = ImageList_CreateImage(himl->hdcImage, himl, + count2x(himl->cMaxImage,cx), cy*PER_ROW); SelectObject(himl->hdcImage, himl->hbmImage); } else himl->hbmImage = 0; if ((himl->cMaxImage > 0) && (himl->flags & ILC_MASK)) { - himl->hbmMask = - CreateBitmap (himl->cx * himl->cMaxImage, himl->cy, - 1, 1, NULL); + himl->hbmMask = CreateBitmap (count2x(himl->cMaxImage,himl->cx), + himl->cy * PER_ROW, 1, 1, NULL); if (himl->hbmMask == 0) { ERR("Error creating mask bitmap!\n"); goto cleanup; @@ -1053,7 +1057,7 @@ */ BOOL WINAPI -ImageList_DrawIndirect (IMAGELISTDRAWPARAMS *pimldp) +ImageList_DrawIndirect (IMAGELISTDRAWPARAMS *pimldp) { INT cx, cy, lx, ly, nOvlIdx; DWORD fState, dwRop; @@ -1068,8 +1072,8 @@ if (!is_valid(himl)) return FALSE; if ((pimldp->i < 0) || (pimldp->i >= himl->cCurImage)) return FALSE; - lx = himl->cx * pimldp->i + pimldp->xBitmap; - ly = pimldp->yBitmap; + lx = index2x(pimldp->i,himl->cx) + pimldp->xBitmap; + ly = index2y(pimldp->i,himl->cy) + pimldp->yBitmap; fState = pimldp->cbSize < sizeof(IMAGELISTDRAWPARAMS) ? ILS_NORMAL : pimldp->fState; fStyle = pimldp->fStyle & ~ILD_OVERLAYMASK; @@ -1187,10 +1191,11 @@ if ( (nOvlIdx >= 1) && (nOvlIdx <= MAX_OVERLAYIMAGE)) { nOvlIdx = himl->nOvlIdx[nOvlIdx - 1]; if ((nOvlIdx >= 0) && (nOvlIdx < himl->cCurImage)) { - const INT ox = himl->cx * nOvlIdx + pimldp->xBitmap; + const INT ox = index2x(nOvlIdx,himl->cx) + pimldp->xBitmap; + const INT oy = index2y(nOvlIdx,himl->cy) + pimldp->yBitmap; if (himl->hbmMask && !(fStyle & ILD_IMAGE)) - BitBlt (hImageDC, 0, 0, cx, cy, hMaskListDC, ox, ly, SRCAND); - BitBlt (hImageDC, 0, 0, cx, cy, hImageListDC, ox, ly, SRCPAINT); + BitBlt (hImageDC, 0, 0, cx, cy, hMaskListDC, ox, oy, SRCAND); + BitBlt (hImageDC, 0, 0, cx, cy, hImageListDC, ox, oy, SRCPAINT); } } @@ -1259,11 +1264,13 @@ if (himlDst) { - BitBlt (himlDst->hdcImage, 0, 0, himlSrc->cCurImage * himlSrc->cx, himlSrc->cy, + BitBlt (himlDst->hdcImage, 0, 0, + count2x(himlSrc->cCurImage,himlSrc->cx), himlSrc->cy*PER_ROW, himlSrc->hdcImage, 0, 0, SRCCOPY); if (himlDst->hbmMask) - BitBlt (himlDst->hdcMask, 0, 0, himlSrc->cCurImage * himlSrc->cx, himlSrc->cy, + BitBlt (himlDst->hdcMask, 0, 0, + count2x(himlSrc->cCurImage,himlSrc->cx), himlSrc->cy*PER_ROW, himlSrc->hdcMask, 0, 0, SRCCOPY); himlDst->cCurImage = himlSrc->cCurImage; @@ -1421,7 +1428,9 @@ hOldDstBitmap = SelectObject (hdcDst, ii.hbmMask); if (himl->hbmMask) { BitBlt (hdcDst, 0, 0, himl->cx, himl->cy, - himl->hdcMask, i * himl->cx, 0, SRCCOPY); + himl->hdcMask, + index2x(i,himl->cx), index2y(i,himl->cy), + SRCCOPY); } else PatBlt (hdcDst, 0, 0, himl->cx, himl->cy, BLACKNESS); @@ -1429,7 +1438,8 @@ /* draw image*/ SelectObject (hdcDst, ii.hbmColor); BitBlt (hdcDst, 0, 0, himl->cx, himl->cy, - himl->hdcImage, i * himl->cx, 0, SRCCOPY); + himl->hdcImage, + index2x(i,himl->cx), index2y(i,himl->cy), SRCCOPY); /* * CreateIconIndirect requires us to deselect the bitmaps from @@ -1531,11 +1541,10 @@ pImageInfo->hbmImage = himl->hbmImage; pImageInfo->hbmMask = himl->hbmMask; - pImageInfo->rcImage.top = 0; - pImageInfo->rcImage.bottom = himl->cy; - pImageInfo->rcImage.left = i * himl->cx; - pImageInfo->rcImage.right = (i+1) * himl->cx; - + pImageInfo->rcImage.top = index2y(i,himl->cy); + pImageInfo->rcImage.bottom = index2y(i,himl->cy)+himl->cy; + pImageInfo->rcImage.left = index2x(i,himl->cx); + pImageInfo->rcImage.right = index2x(i,himl->cx)+himl->cx; return TRUE; } @@ -1566,11 +1575,10 @@ if ((i < 0) || (i >= himl->cCurImage)) return FALSE; - lpRect->left = i * himl->cx; - lpRect->top = 0; + lpRect->left = index2x(i,himl->cx); lpRect->right = lpRect->left + himl->cx; - lpRect->bottom = himl->cy; - + lpRect->top = index2y(i,himl->cy); + lpRect->bottom = lpRect->top + himl->cy; return TRUE; } @@ -1724,7 +1732,6 @@ HIMAGELIST himlDst = NULL; INT cxDst, cyDst; INT xOff1, yOff1, xOff2, yOff2; - INT nX1, nX2; TRACE("(himl1=%p i1=%d himl2=%p i2=%d dx=%d dy=%d)\n", himl1, i1, himl2, i2, dx, dy); @@ -1768,25 +1775,29 @@ if (himlDst) { - nX1 = i1 * himl1->cx; - nX2 = i2 * himl2->cx; + int x1, x2, y1, y2; + + x1 = index2x(i1,himl1->cx); + y1 = index2y(i1,himl1->cy); + x2 = index2x(i2,himl2->cx); + y2 = index2y(i2,himl2->cy); /* copy image */ BitBlt (himlDst->hdcImage, 0, 0, cxDst, cyDst, himl1->hdcImage, 0, 0, BLACKNESS); if (i1 >= 0 && i1 < himl1->cCurImage) - BitBlt (himlDst->hdcImage, xOff1, yOff1, himl1->cx, himl1->cy, himl1->hdcImage, nX1, 0, SRCCOPY); + BitBlt (himlDst->hdcImage, xOff1, yOff1, himl1->cx, himl1->cy, himl1->hdcImage, x1, y1, SRCCOPY); if (i2 >= 0 && i2 < himl2->cCurImage) { - BitBlt (himlDst->hdcImage, xOff2, yOff2, himl2->cx, himl2->cy, himl2->hdcMask , nX2, 0, SRCAND); - BitBlt (himlDst->hdcImage, xOff2, yOff2, himl2->cx, himl2->cy, himl2->hdcImage, nX2, 0, SRCPAINT); + BitBlt (himlDst->hdcImage, xOff2, yOff2, himl2->cx, himl2->cy, himl2->hdcMask , x2, y2, SRCAND); + BitBlt (himlDst->hdcImage, xOff2, yOff2, himl2->cx, himl2->cy, himl2->hdcImage, x2, y2, SRCPAINT); } /* copy mask */ BitBlt (himlDst->hdcMask, 0, 0, cxDst, cyDst, himl1->hdcMask, 0, 0, WHITENESS); if (i1 >= 0 && i1 < himl1->cCurImage) - BitBlt (himlDst->hdcMask, xOff1, yOff1, himl1->cx, himl1->cy, himl1->hdcMask, nX1, 0, SRCCOPY); + BitBlt (himlDst->hdcMask, xOff1, yOff1, himl1->cx, himl1->cy, himl1->hdcMask, x1, y1, SRCCOPY); if (i2 >= 0 && i2 < himl2->cCurImage) - BitBlt (himlDst->hdcMask, xOff2, yOff2, himl2->cx, himl2->cy, himl2->hdcMask, nX2, 0, SRCAND); + BitBlt (himlDst->hdcMask, xOff2, yOff2, himl2->cx, himl2->cy, himl2->hdcMask, x2, y2, SRCAND); himlDst->cCurImage = 1; } @@ -1862,6 +1873,7 @@ nheight = cy; nRows = (height/cy); + FIXME("nwidth %d, nheight %d, cy %d\n", nwidth, nheight, cy); if (bitsperpixel==1) hbitmap = CreateBitmap(nwidth,nheight,1,1,NULL); else @@ -2048,36 +2060,36 @@ for (nCount = 0; nCount < MAX_OVERLAYIMAGE; nCount++) himl->nOvlIdx[nCount] = -1; - hbmNewImage = ImageList_CreateImage(himl->hdcImage, himl, himl->cMaxImage * himl->cx, himl->cy); + hbmNewImage = ImageList_CreateImage(himl->hdcImage, himl, + count2x(himl->cMaxImage,himl->cx), himl->cy*PER_ROW); SelectObject (himl->hdcImage, hbmNewImage); DeleteObject (himl->hbmImage); himl->hbmImage = hbmNewImage; if (himl->hbmMask) { - hbmNewMask = CreateBitmap (himl->cMaxImage * himl->cx, himl->cy, + hbmNewMask = CreateBitmap (count2x(himl->cMaxImage,himl->cx), himl->cy*PER_ROW, 1, 1, NULL); SelectObject (himl->hdcMask, hbmNewMask); DeleteObject (himl->hbmMask); himl->hbmMask = hbmNewMask; } - } - else { + } else { /* delete one image */ TRACE("Remove single image! %d\n", i); /* create new bitmap(s) */ nCount = (himl->cCurImage + himl->cGrow - 1); - cxNew = nCount * himl->cx; + cxNew = count2x(nCount , himl->cx); TRACE(" - Number of images: %d / %d (Old/New)\n", himl->cCurImage, himl->cCurImage - 1); TRACE(" - Max. number of images: %d / %d (Old/New)\n", himl->cMaxImage, himl->cCurImage + himl->cGrow - 1); - hbmNewImage = ImageList_CreateImage(himl->hdcImage, himl, cxNew, himl->cy); + hbmNewImage = ImageList_CreateImage(himl->hdcImage, himl, cxNew, himl->cy*PER_ROW); if (himl->hbmMask) - hbmNewMask = CreateBitmap (cxNew, himl->cy, 1, 1, NULL); + hbmNewMask = CreateBitmap (cxNew, himl->cy*PER_ROW, 1, 1, NULL); else hbmNewMask = 0; /* Just to keep compiler happy! */ @@ -2085,31 +2097,45 @@ /* copy all images and masks prior to the "removed" image */ if (i > 0) { - TRACE("Pre image copy: Copy %d images\n", i); + int n = count2x(i,1); - SelectObject (hdcBmp, hbmNewImage); - BitBlt (hdcBmp, 0, 0, i * himl->cx, himl->cy, - himl->hdcImage, 0, 0, SRCCOPY); - - if (himl->hbmMask) { - SelectObject (hdcBmp, hbmNewMask); - BitBlt (hdcBmp, 0, 0, i * himl->cx, himl->cy, - himl->hdcMask, 0, 0, SRCCOPY); + TRACE("Pre image copy: Copy %d images\n", i); + if (n) { /* copy started rows */ + SelectObject (hdcBmp, hbmNewImage); + BitBlt (hdcBmp, 0, 0, n * himl->cx, himl->cy * PER_ROW, + himl->hdcImage, 0, 0, SRCCOPY); + + if (himl->hbmMask) { + SelectObject (hdcBmp, hbmNewMask); + BitBlt (hdcBmp, 0, 0, n * himl->cx, himl->cy * PER_ROW, + himl->hdcMask, 0, 0, SRCCOPY); + } } + /* this might copy some images more. But we will + * overwrite them right afterwards */ } /* copy all images and masks behind the removed image */ if (i < himl->cCurImage - 1) { + int j; + TRACE("Post image copy!\n"); - SelectObject (hdcBmp, hbmNewImage); - BitBlt (hdcBmp, i * himl->cx, 0, (himl->cCurImage - i - 1) * himl->cx, - himl->cy, himl->hdcImage, (i + 1) * himl->cx, 0, SRCCOPY); + + /* copy the post-i images one-by-one */ + SelectObject (hdcBmp, hbmNewImage); + for (j=i;j<himl->cCurImage -1;j++) + BitBlt (hdcBmp, index2x(j,himl->cx), index2y(j,himl->cy), himl->cx, himl->cy, + himl->hdcImage, index2x(j+1,himl->cx), index2y(j+1,himl->cy), SRCCOPY); if (himl->hbmMask) { SelectObject (hdcBmp, hbmNewMask); - BitBlt (hdcBmp, i * himl->cx, 0, - (himl->cCurImage - i - 1) * himl->cx, - himl->cy, himl->hdcMask, (i + 1) * himl->cx, 0, SRCCOPY); + for (j=i;j<himl->cCurImage -1;j++) + BitBlt (hdcBmp, + index2x(j,himl->cx), index2y(j,himl->cy), + himl->cx, himl->cy, + himl->hdcMask, + index2x(j+1,himl->cx), index2y(j+1,himl->cy), + SRCCOPY); } } @@ -2290,12 +2316,16 @@ SetBkColor (himl->hdcImage, RGB(255,255,255)); hbmOldSrc = SelectObject (hdcImage, ii.hbmColor); - StretchBlt (himl->hdcImage, nIndex * himl->cx, 0, himl->cx, himl->cy, - hdcImage, 0, 0, bmp.bmWidth, bmp.bmHeight, SRCCOPY); + StretchBlt (himl->hdcImage, + index2x(nIndex,himl->cx), index2y(nIndex,himl->cy), + himl->cx, himl->cy, + hdcImage, 0, 0, bmp.bmWidth, bmp.bmHeight, SRCCOPY); if (himl->hbmMask) { SelectObject (hdcImage, ii.hbmMask); - StretchBlt (himl->hdcMask, nIndex * himl->cx, 0, himl->cx, himl->cy, + StretchBlt (himl->hdcMask, + index2x(nIndex,himl->cx), index2y(nIndex,himl->cy), + himl->cx, himl->cy, hdcImage, 0, 0, bmp.bmWidth, bmp.bmHeight, SRCCOPY); }

2 1

wininet useragent implementation
by Vijay Kiran Kamuju 17 Feb '06

17 Feb '06

Hi, If anyone has enough patience, please look into my wininet useragent patch. It adds InternetSetOption and InternetQueryOption for INTERNET_OPTION_USER_AGENT. It is still not complete, it still has some bugs. Please fix/improve the implementation and submit it to the wine-patches I will not be available for a week or more. (a month) I have submitted some new tests for wininet. Thanks and Regards, Vijay

1 0

Re: ntdll: Don't Use wine_sigaction on systems without SYS_sigaction
by Alexandre Julliard 17 Feb '06

17 Feb '06

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > Some systems don't define SYS_sigaction as they use realtime > signals. On these systems wine_sigaction shouldn't be needed as it is > there to work around bugs with missing sigaltstack support in glibc, > so make the usage of wine_sigaction depend on SYS_sigaction being > defined. Do you really have a platform that doesn't define it? The only case I know about is building on x86_64 with the wrong kernel headers, and in that case we very much want it to fail. -- Alexandre Julliard julliard(a)winehq.org

1 0

GL texture problems
by Stefan Dösinger 17 Feb '06

17 Feb '06

Hello, I'm trying to change IWineD3DSurface::UnlockRect for rendertargets to avoid glDrawPixels. Instead, I'd like to load the image from memory into an OpenGL texture, and draw that texture with a textured quad onto the front / back buffer. The problem I have is that the texture(or better, the resulting image) only has a solid color: The color of the first pixel in the source memory. I've read the texture section of the GL programming guide, but I didn't find a solution. I've attached a patch with my changes. The reason why I want to make this change is that glDrawPixels and glReadPixels are horribly slow on radeon cards, they take a few secounds for a 1024x768 image. The current code doesn't work for the open source driver at any color depth(mesa software acceleration doesn't work eighter), and it's broken for some color depths with the fglrx driver.

4 8

Re: winspool: Add SetDefaultPrinterA/W, with tests and doc
by James Hawkins 17 Feb '06

17 Feb '06

On 2/16/06, Detlef Riekenberg <wine.dev(a)web.de> wrote: > > Split the Patch does not work: wine will crash on unimplemented function > I don't know if the patch hasn't been accepted because of size or what, but if it is size, the best way to split the patch up is: 1) Add a stub for the new function, with documentation 2) Add the tests 3) Send in the implementation, changing the passing tests accordingly -- James Hawkins

1 0

Re: What to do??? -- WINE 0.9.3-0.9.7 and Photoshop 7
by Aleksey 16 Feb '06

16 Feb '06

K, Photoshop 7 works good like it used to with 0.9.2 now, no visible difference yet. I think I'll unsubscribe from wine-devel on this email and sign up with my other email, it won't cause any cofusion, will it? Oops, sorry Hiji, I meant to send it to the list and sent it to you. Second time I've done this. Argh. On 2/16/06, Aleksey <anime4christ(a)gmail.com> wrote: > K, Photoshop 7 works good like it used to with 0.9.2 now, no visible > difference yet. > I think I'll unsubscribe from wine-devel on this email and sign up > with my other email, it won't cause any cofusion, will it? > > On 2/15/06, Hiji <hijinio(a)yahoo.com> wrote: > > > > On Tuesday 14 February 2006 22:12, Hiji wrote: > > > > > Can anybody help? > > > > > > > > Did you try latest CVS? I don't have PS7, but this > > > > patch went in on Saturday > > > > and might be related (If I recall correctly, > > > Martin > > > > mentioned the PS7 > > > > breakage): > > > > > http://source.winehq.org/git/?p=wine.git;a=commit;h=c362d7c35ba3c02d68a9b7e… > > > > > > Martin just replied to me. I don't pull out of CVS; > > > so, I'll wait for the next release! > > > > > > If it doesn't work out, then I'll report back. > > > > > > Thanks! > > > Hijinio > > > > > > Thumbs up! Photoshop 7 runs once again via 0.9.8. > > Though, I didn't try installing it (I just carried > > over my .wine folder.) > > > > Thanks to everyone! MANY people will be happy again! > > > > Hiji > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > > > >

1 0

re: What would most aid WINE development?
by Daniel Kegel 16 Feb '06

16 Feb '06

Susheel Daswani wrote: > For my 'Antitrust & IP' course this semester I am writing a brief > about why I think the remedy in the Microsoft antitrust case was > inadequate. Back in the day, I wrote an essay about this; it's online at http://kegel.com/remedy/ in particular, http://www.usdoj.gov/atr/cases/ms_tuncom/major/mtc-00028571.htm I now think my essay was naive, but hey, I was young :-) It would be interesting to see the complaints sent to the Technical Committee ( http://www.thetc.org/ ) but I doubt they're public. You might also want to read http://www.lessig.org/content/testimony/msft/msft.pdf if you haven't already. > So my question for the WINE developers is "What materials from > Microsoft would most aid the development of WINE"? The Windows API is > of course public, so my guess is that isn't a huge bar to creating > WINE. So what are the bars? Is it simply the scope of the project? > Is there information that MS could divulge that would greatly aid the > WINE effort? Would open sourcing part of Windows help? As others have noted, the Windows API is not completely public nor particularly well-defined. This makes things harder, but it's not really the main obstacle. Here are a few things a judge could order Microsoft to do that would help Wine: * order them to break up into two companies, one for operating systems and .net, one for everything else * donate gobs of cash to Wine * offer a perpetual, transferrable, royalty-free, GPL-compatible license for its protocols and data formats * support ODF in Microsoft Office That last item is kind of indirect. It would make it much easier for everybody to switch to OpenOffice, which would make it much easier for everybody to switch to Linux, which is the whole point of Wine. - Dan -- Wonder why Aunt Tilly still won't use Linux? See http://kegel.com/linux/comfort

9 12

riched20_crosstest.exe does not build (-lriched20)
by Detlef Riekenberg 16 Feb '06

16 Feb '06

Hi. While testing for bug #4567 ( http://bugs.winehq.org/show_bug.cgi?id=4567 ): riched20_crosstest.exe does not Build: /usr/lib/gcc/i586-mingw32msvc/3.4.2/../../../../i586-mingw32msvc/bin/ld: cannot find -lriched20 Is this the same Problem for "winetest-latest.*" still dated 10.Feb ? -- By By ... ... Detlef

2 1

Re: WINE 0.9.3 and Photoshop 7 & CS
by Aleksey 16 Feb '06

16 Feb '06

The patch has been found that breaks Photoshop, but 0.9.6 still brakes PS. On 1/6/06, Aleksey <anime4christ(a)gmail.com> wrote: > Great! Thanks! > > On 1/1/06, Elvis Pranskevichus <elprans(a)gmail.com> wrote: > > Aleksey wrote: > > > Yesterday I upgraded to WINE 0.9.3, and then tried running Photoshop > > > 7. Photoshop gave me a hardware error. I thought, no problem, I'll > > > just reinstall it, same result. Then I reconfigured WINE using > > > winetools and tried again, same thing. Here is what I got in the > > > Terminal when running Photoshop 7: > > > > > > fixme:actctx:QueryActCtxW stub! > > > fixme:font:WineEngRemoveFontResourceEx :stub > > > fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de2c,0x00000000), stub! > > > fixme:win:EnumDisplayDevicesW > > > (L"\\\\.\\DISPLAY1",0,0x7fa7de2c,0x00000000), stub! > > > fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e694, 0x7fa7e1ac, > > > 0x7fa7e6f4, 0x7fa7e704 ) stub > > > fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de34,0x00000000), stub! > > > fixme:win:EnumDisplayDevicesW > > > (L"\\\\.\\DISPLAY1",0,0x7fa7de34,0x00000000), stub! > > > fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e69c, 0x7fa7e1b4, > > > 0x7fa7e6fc, 0x7fa7e70c ) stub > > > err:shell:HCR_GetFolderAttributes HCR_GetFolderAttributes should be > > > called for simple PIDL's only! > > > fixme:font:WineEngRemoveFontResourceEx :stub > > > fixme:font:WineEngRemoveFontResourceEx :stub > > > > > > Then I tried installing Photoshop CS, knowing that it worked fine with > > > 0.9.2. Photoshop CS told me that certain required files was missing, > > > but I forgot to get down the results from the Terminal. After that I > > > downgraded to WINE 0.9.2 and both versions of Photoshop work great. > > > > > > A little side note: ImageReady 7 works great under 0.9.3, I did not > > > test ImageReady CS. ImageReady 7 works great under 0.9.2 also, but > > > ImageReady CS crashes. > > > > > > God Bless. > > > - Aleksey > > > > > > > > > > Hi, > > > > I've found the patch that breaks the thing. GIT commit-ish is 0b17529332b0ef5ee57873afd4ded6f359e76781. (http://source.winehq.org/git/?p=wine.git;a=commit;h=0b17529332b0ef5ee57873a…). > > > > I haven't looked at it deeply, just done some git bisect's. > > > > -- > > Elvis Pranskevichus - elprans(a)gmail.com > > > > >

3 6

Small and Fast (was: Re: Add InitializeSecurityContext for schannel)
by Detlef Riekenberg 15 Feb '06

15 Feb '06

Am Dienstag, den 14.02.2006, 17:34 +0530 schrieb Vijay Kiran Kamuju: > Add InitializeSecurityContext for schannel in secur32.dll +static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextW( + PCredHandle phCredential, PCtxtHandle phContext, SEC_WCHAR *pszTargetName, + ULONG fContextReq, ULONG Reserved1, ULONG TargetDataRep, + PSecBufferDesc pInput,ULONG Reserved2, PCtxtHandle phNewContext, + PSecBufferDesc pOutput, ULONG *pfContextAttr, PTimeStamp ptsExpiry) +{ I Remembered a statement from fefe (diet-libc => www.fefe.de) about "Writing Small and Fast Software": It is still clear, what each Argument does, when you remove the Variable-Names from the Declaration? - Yes: Efficient Design. - No: Your Interface is to generic == bloated static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextW( PCredHandle, PCtxtHandle, SEC_WCHAR *, ULONG, ULONG, ULONG, PSecBufferDesc, ULONG, PCtxtHandle, PSecBufferDesc, ULONG, PTimeStamp) { We all should thank the People who did such a Design :-) -- By By ... ... Detlef

2 2

Small and Fast (was: Re: Add InitializeSecurityContext for schannel)
by Vijay Kiran Kamuju 15 Feb '06

15 Feb '06

Hi all, I copied it from the negotiate.c In other places like ntlm.c, its like that only. Im not the one who actually designed secur32 ;) :P If i did anything worng please correct me. bye, Vijay On 2/15/06, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On Tue, Feb 14, 2006 at 11:22:09PM +0100, Detlef Riekenberg wrote: > > Am Dienstag, den 14.02.2006, 17:34 +0530 schrieb Vijay Kiran Kamuju: > > > > > Add InitializeSecurityContext for schannel in secur32.dll > > > > +static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextW( > > + PCredHandle phCredential, PCtxtHandle phContext, SEC_WCHAR > > *pszTargetName, > > + ULONG fContextReq, ULONG Reserved1, ULONG TargetDataRep, > > + PSecBufferDesc pInput,ULONG Reserved2, PCtxtHandle phNewContext, > > + PSecBufferDesc pOutput, ULONG *pfContextAttr, PTimeStamp ptsExpiry) > > +{ > > > > I Remembered a statement from fefe (diet-libc => www.fefe.de) about > > "Writing Small and Fast Software": > > > > It is still clear, what each Argument does, when you remove the > > Variable-Names from the Declaration? > > - Yes: Efficient Design. > > - No: Your Interface is to generic == bloated > > > > static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextW( > > PCredHandle, PCtxtHandle, SEC_WCHAR *, ULONG, ULONG, ULONG, > > PSecBufferDesc, ULONG, PCtxtHandle, PSecBufferDesc, ULONG, PTimeStamp) > > { > > > > We all should thank the People who did such a Design :-) > > However, this only works in newer C compilers as far as I know... ;) > > Ciao, Marcus >

3 2

winspool: EnumMonitorsA/W implemented
by Detlef Riekenberg 15 Feb '06

15 Feb '06

Am Mittwoch, den 08.02.2006, 23:33 +0100 schrieb Detlef Riekenberg: > Changelog: > > - EnumMonitorsA/W implemented > - Registry-Entry for "Local Port" added (NT) > Return the Monitor-Entry for "Local Port" also, when the dll > failed to load (we do the work of localspl.dll in our winspool.drv) http://www.winehq.org/pipermail/wine-patches/2006-February/024172.html Anything wrong with this Patch? (Still applies and works in wine-0.9.8) -- By By ... ... Detlef

1 0

winspool/tests: Add tests for EnumMonitors()
by Detlef Riekenberg 15 Feb '06

15 Feb '06

Am Mittwoch, den 08.02.2006, 22:36 +0100 schrieb Detlef Riekenberg: > Changelog: > > - Add tests for EnumMonitors() > http://www.winehq.org/pipermail/wine-patches/2006-February/024171.html Anything wrong with this? (Still apply and works on wine-0.9.8) -- By By ... ... Detlef

1 0

Appdb thoughts
by Dan Kegel 15 Feb '06

15 Feb '06

Hi all, I've been using the Appdb a fair bit in the last couple months, maintaining a couple apps and their bug links, and doing some quick testing of apps I'm not the appdb maintainer for. Mostly I find the appdb adequate and usable, but I've noticed a few things that bug me. Here's a quick dump of what's on my mind: 1) The top 10 platinum, gold, and silver lists on the front page is helpful but appear to be manually maintained. It'd be helpful if there was a way to use the ratings while browsing or searching the appdb. 2) The links between bugzilla and the appdb are great. I really like seeing the list of bugs for each app. But the app db's orientation towards detailed rich text info about apps makes me wonder. I often do quick testing of apps for obvious bugs (like crashes) without really getting to know the app, and I don't feel qualified to say much about the app; I just want to link a bug to it. But the app db gets upset unless I fill in all sorts of info about the app. And unless I'm willing to be the app db maintainer for an app, that info is going to quickly get out of date. So I'd like a way to create an app db entry without filling in any info about the app besides a bug number. 3) It'd be nice if, when entering bugs in bugzilla, the web interface let me enter an appdb app id somehow. Not sure how to do that nicely. Anyway, that's what's on my mind. Tony disagrees with me about #2; he thinks once I've filed a bugzilla report for an app, I have everything I need to create a fully populated appdb entry. I can't quite put my finger on why I disagree with him. Comments, anyone? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel