November 2005 - Wine-Devel - list.winehq.org

Re: PATCH/RFC: imagelist rewrite to use N x M grid

by Vitaliy Margolen

Tuesday, November 29, 2005, 1:37:01 PM, Marcus Meissner wrote: > On Tue, Nov 29, 2005 at 01:24:47PM -0700, Vitaliy Margolen wrote: >> Tuesday, November 29, 2005, 12:58:55 PM, Marcus Meissner wrote: >> > On Mon, Nov 28, 2005 at 09:55:57PM -0600, Dustin Navea wrote: >> >> Hmmmm. I havent tested due to sys overhaul, but it seems that this >> >> should work. Just out of curiosity, what was the reason for picking 4 >> >> as the magic number? >> >> > Randomness. Any number could be used. >> I think native uses 4. As I remember, Delphi understands only 4xN. >> So when you edit an imagelist in IDE and save it, Delphi could not use >> produced output and was crashing/displaying corrupted images. > So our current implementation has problems? Correct. It work as long as you don't try to save image list to stream. > Is this the Read/Write to/from IStream interface to imagelists? Yes. Delphi stores that information in the raw form during the design time. So when application start it reads whole image list from resources. In other words. What Wine saves to stream is not binary compatible with windows. To make it compatible it has to be 4xN bitmap. Vitaliy.

Nov. 29, 2005

Re: PATCH/RFC: imagelist rewrite to use N x M grid

by Marcus Meissner

On Tue, Nov 29, 2005 at 01:24:47PM -0700, Vitaliy Margolen wrote: > Tuesday, November 29, 2005, 12:58:55 PM, Marcus Meissner wrote: > > On Mon, Nov 28, 2005 at 09:55:57PM -0600, Dustin Navea wrote: > >> Hmmmm. I havent tested due to sys overhaul, but it seems that this > >> should work. Just out of curiosity, what was the reason for picking 4 > >> as the magic number? > > > Randomness. Any number could be used. > I think native uses 4. As I remember, Delphi understands only 4xN. > So when you edit an imagelist in IDE and save it, Delphi could not use > produced output and was crashing/displaying corrupted images. So our current implementation has problems? Is this the Read/Write to/from IStream interface to imagelists? > > However I got another suggestion to just store all the images in > > an array (of HBITMAP or similar). > > > > Does anything speak against doing this instead of having this > > large bitmap and cutting out the images? > > The problem is that you can't read it as-is from the stream. Also you > will have to put it back together into a single bitmap to save it. Also > some ops require operation on the whole image list. And last but not > least, it will be much slower, as you will have to create/delete DCs each > time you need to use imagelist. Ah ok. Ciao, Marcus

Nov. 29, 2005

Re: PATCH/RFC: imagelist rewrite to use N x M grid

by Vitaliy Margolen

Tuesday, November 29, 2005, 12:58:55 PM, Marcus Meissner wrote: > On Mon, Nov 28, 2005 at 09:55:57PM -0600, Dustin Navea wrote: >> Hmmmm. I havent tested due to sys overhaul, but it seems that this >> should work. Just out of curiosity, what was the reason for picking 4 >> as the magic number? > Randomness. Any number could be used. I think native uses 4. As I remember, Delphi understands only 4xN. So when you edit an imagelist in IDE and save it, Delphi could not use produced output and was crashing/displaying corrupted images. > However I got another suggestion to just store all the images in > an array (of HBITMAP or similar). > > Does anything speak against doing this instead of having this > large bitmap and cutting out the images? The problem is that you can't read it as-is from the stream. Also you will have to put it back together into a single bitmap to save it. Also some ops require operation on the whole image list. And last but not least, it will be much slower, as you will have to create/delete DCs each time you need to use imagelist. Vitaliy

Nov. 29, 2005

Re: PATCH/RFC: imagelist rewrite to use N x M grid

by Marcus Meissner

On Mon, Nov 28, 2005 at 09:55:57PM -0600, Dustin Navea wrote: > Hmmmm. I havent tested due to sys overhaul, but it seems that this > should work. Just out of curiosity, what was the reason for picking 4 > as the magic number? Randomness. Any number could be used. However I got another suggestion to just store all the images in an array (of HBITMAP or similar). Does anything speak against doing this instead of having this large bitmap and cutting out the images? Ciao, Marcus

Nov. 29, 2005

Re: WSACleanup fix.

by Robert Shearman

Rein Klazes wrote: >On Tue, 29 Nov 2005 10:33:49 -0600, you wrote: > > > >> if (num_startup) >>+ { >>+ num_startup--; >> return 0; >>+ } >> >> > >Yes, that is more correct. Re-reading the MSDN this is what should be >happening. > >Changelog: >dlls/winsock : socket.c >dlls/winsock/tests : sock.c >(With input from Robert Shearman) Decrement the reference counter in >WSACleanUp with regression test. > > Alexandre already committed a corrected version of your patch. -- Rob Shearman

Nov. 29, 2005

Re: WSACleanup fix.

by Vitaliy Margolen

Tuesday, November 29, 2005, 12:10:52 PM, Rein Klazes wrote: > On Tue, 29 Nov 2005 10:33:49 -0600, you wrote: >> if (num_startup) >>+ { >>+ num_startup--; >> return 0; >>+ } > Yes, that is more correct. Re-reading the MSDN this is what should be > happening. > Changelog: > dlls/winsock : socket.c > dlls/winsock/tests : sock.c > (With input from Robert Shearman) Decrement the reference counter in > WSACleanUp with regression test. > Rein. I think you a little too late. <g> Check the CVS log. Vitaliy

Nov. 29, 2005

Re: WSACleanup fix.

by Rein Klazes

On Tue, 29 Nov 2005 10:33:49 -0600, you wrote: > if (num_startup) >+ { >+ num_startup--; > return 0; >+ } Yes, that is more correct. Re-reading the MSDN this is what should be happening. Changelog: dlls/winsock : socket.c dlls/winsock/tests : sock.c (With input from Robert Shearman) Decrement the reference counter in WSACleanUp with regression test. Rein.

Nov. 29, 2005

Re: Compiling wine on Ubuntu amd64

by Peter Beutner

keep wine-devel list cc'ed. James Trotter schrieb: > On 11/29/05, Peter Beutner <p.beutner(a)gmx.net> wrote: >> >>I think we should rather get rid of including >>/usr/include/X11/Intrinsic.h. >>The code in x11drv which include this header doesn't even link against >>libXt. >>(and afaik no other part of wine does it) > > So, you'd say it's safe to remove any includes of X11/Intrinsic.h in the > wine source? If so, I'd be willing to do this as soon as I can. Just do an 'cvs update' ;). Alexandre Julliard already fixed it today.

Nov. 29, 2005

Re: Please HELP, info required about 'DIB_Status_GdiMod' and 'DIB_Status_AppMod'

by Robert Shearman

Marinescu-Ghetau Iulian wrote: > Hello, > > Could anyone give me some more info on X11DRV_CoerceDIBSection > function and the logic behind using 'DIB_Status_GdiMod' and > 'DIB_Status_AppMod' stats? I am trying to repair a bug (3902) that has > to do with application waiting exccessivly on some locks and i am kind > of lost ;( Any help would be greatly appreciated! That code is designed to keep DIBs sync'ed between applications and the X server. When the application does a Win32 GDI call then the state of the DIB gets set to DIB_Status_GdiMod and the memory that backs the DIB is set to no-access so that a page fault occurs if the application tries to read it. A handler detects this and downloads the DIB from the X server and sets the state to DIB_Status_None. In this state the DIB memory is set to read-only, so that a page fault occurs if the application tries to write it. The same handler also detects this and consequentially sets the DIB state to DIB_Status_AppMod and allows full access to the DIB memory. If this doesn't answer help with your bug then you'll have to be more specific. -- Rob Shearman

Nov. 29, 2005

Re: RESEND: Page Fault With Freetype calls fixed

by Alexandre Julliard

Rein Klazes <wijn(a)wanadoo.nl> writes: > Not included in the new release, no comments. Is there a problem with > this one ? I think it would be cleaner to have WineEngGetFontData do the right thing directly, instead of calling it twice. -- Alexandre Julliard julliard(a)winehq.org

Nov. 29, 2005