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

Re: BUG (3920) + sync between DIBs and X Server optimisation. (please help)

by Robert Shearman

Marinescu-Ghetau Iulian wrote: > I came to the conclusion that the slowness in "Heroes IV" it has to do > with > sync'ing lage bitmaps between application DIBs and X Server(see the > log: http://bugs.winehq.org/attachment.cgi?id=1470&action=view ). > > Also, a complete description of the bug is here: > http://bugs.winehq.org/show_bug.cgi?id=3902 > > So i had this ideea that every GDI function could memorise the > rectangle that is modifying, so each time a sync between DIB and X > Server is needed, only a small part from the bitmap will get copied! I > also made some changes to dib.c, bitblt.c and x11drv.h in > "wine-0.9.2\dlls\x11drv" folder to implement my ideea, keeping > backwards compatibility (if a DIB function doesn't set a valid > rectangle for the bitmap that its modifying, the default values are > taken - which is the entire bitmap) > > > - and finally, a GDI function calls it like this (for example bitblt): > > X11DRV_SetBoundRect(physDevDst->bitmap,xDst,yDst,width,height); > X11DRV_CoerceDIBSection( physDevDst, DIB_Status_GdiMod, FALSE ); > if (physDevDst != physDevSrc) > { > X11DRV_SetBoundRect(physDevSrc->bitmap,xSrc,ySrc,width,height); > X11DRV_CoerceDIBSection( physDevSrc, DIB_Status_GdiMod, FALSE ); > } I think it would be better to make X11DRV_CoerceDIBSection take the parameters for a bounding rect, otherwise it is possible to forget a call to SetBoundRect and cause the DIB to not be updated. -- Rob Shearman

Dec. 12, 2005

Re: PATCH: handle redirect to https

by Robert Shearman

Marcus Meissner wrote: >On Mon, Dec 12, 2005 at 01:58:37AM -0600, Robert Shearman wrote: > > >>Marcus Meissner wrote: >> >> >> >>>Hi, >>> >>>Redirect from http to https currently segfaults our >>>wininet implementation. >>> >>>Exposed by the Google Earth update check. >>> >>>Ciao, Marcus >>> >>>Changelog: >>> When redirecting, do not forget to reinit NETCON. >>> >>> >>> >>> >>This shouldn't be necessary. The NETCONNECTION structure should have >>been re-initialized to its post-NETCON_init state after calling >>NETCON_close. There are two possible reasons I can think of that would >>cause a crash. The first is the NETCONNECTION stuff not being >>thread-safe. The second is possible ref-counting issues on the SSL >>method object "meth". Can you show me the backtrace? >> >> > >(gdb) r GoogleEarth.exe >Starting program: /usr/bin/wine-pthread GoogleEarth.exe >fixme:atl:AtlModuleInit SEMI-STUB (0x466920 0x4658f8 0x400000) >fixme:imm:ImmGetContext (0x10020): stub >fixme:imm:ImmReleaseContext (0x10020, 0x558fa9b0): stub >fixme:imm:ImmGetContext (0x10020): stub >fixme:imm:ImmReleaseContext (0x10020, 0x558fa9b0): stub > >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 1433261760 (LWP 17926)] >0x00000000 in ?? () >(gdb) bt >#0 0x00000000 in ?? () >#1 0x55fe61c6 in NETCON_secure_connect (connection=0x55983b40, hostname=0x55983970) at netconnection.c:348 >#2 0x55fd9bb1 in HTTP_HttpSendRequestW (lpwhr=0x55983b10, lpszHeaders=0x0, dwHeaderLength=0, lpOptional=0x0, dwOptionalLength=0, > dwContentLength=0, bEndRequest=1) at http.c:2262 >#3 0x55fd8375 in HTTP_HandleRedirect (lpwhr=Cannot access memory at address 0x55c0c16c >) at http.c:1890 >#4 0x55fd95c2 in HTTP_HttpSendRequestW (lpwhr=0x55983b10, lpszHeaders=0x0, dwHeaderLength=0, lpOptional=0x0, dwOptionalLength=0, > dwContentLength=0, bEndRequest=1) at http.c:2094 >#5 0x55fda480 in HttpSendRequestW (hHttpRequest=0x3, lpszHeaders=0x0, dwHeaderLength=0, lpOptional=0x0, dwOptionalLength=0) > at http.c:1703 >#6 0x56ffb887 in ?? () >(gdb) up >#1 0x55fe61c6 in NETCON_secure_connect (connection=0x55983b40, hostname=0x55983970) at netconnection.c:348 >348 ctx = pSSL_CTX_new(meth); >(gdb) print meth >$1 = (SSL_METHOD *) 0x0 >(gdb) print pSSL_CTX_new >$2 = (SSL_CTX *(*)()) 0 >(gdb) print *connection >$3 = {useSSL = 0, socketFD = 38, ssl_s = 0x0, peek_msg = 0x0, peek_msg_mem = 0x0} > >NETCON_init() just never got called with useSSL before. > In that case, your patch looks correct. -- Rob Shearman

Dec. 12, 2005

Re: RESENT: sysparams: read/save minimized metrics from/to registry

by Alexandre Julliard

Rein Klazes <wijn(a)wanadoo.nl> writes: > @@ -776,7 +781,7 @@ static inline BOOL get_bool_param( unsig > } > > /* set a uint parameter that is mirrored in two different registry locations */ > -static BOOL set_uint_param_mirrored( unsigned int idx, LPCWSTR regkey, LPCWSTR regkey_mirror, > +static BOOL set_uint_param_mirrored( int idx, LPCWSTR regkey, LPCWSTR regkey_mirror, > LPCWSTR value, UINT *value_ptr, UINT new_val, UINT fWinIni ) > { > WCHAR buf[10]; > @@ -785,19 +790,19 @@ static BOOL set_uint_param_mirrored( uns > if (!SYSPARAMS_Save( regkey, value, buf, fWinIni )) return FALSE; > if (regkey_mirror) SYSPARAMS_Save( regkey_mirror, value, buf, fWinIni ); > *value_ptr = new_val; > - spi_loaded[idx] = TRUE; > + if( idx >= 0) spi_loaded[idx] = TRUE; I think that's ugly, you shouldn't use set_uint_param if you don't want to set the index (and especially since in your case the params are ints not uints). Just call SYSPARAMS_Save directly instead. -- Alexandre Julliard julliard(a)winehq.org

Dec. 12, 2005

Re: http headers reworking

by Andreas Mohr

Hi, On Mon, Dec 12, 2005 at 10:30:48AM -0600, Aric Stewart wrote: > All fixes for Picasa. [...yet again] I'm sure Google will deliver us a fully working Wine reimplementation of IE on a silver tablet in exchange for all that trouble with their almost always nicely non-cross-platform "software", riiiiight? ;-) Andreas Mohr

Dec. 12, 2005

Re: PATCH: handle NULL XImage in GetBitmapBits

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Hi, > > This fixes bug 4034. > XGetImage() returns NULL since we can pass a 0 height value. (298 bytes > vs 320 byte wide image). This shouldn't happen, the height should have been checked in GetBitmapBits already. There's something wrong here... -- Alexandre Julliard julliard(a)winehq.org

Dec. 12, 2005

gethostbyname(my_name) and IL2-Sturmovik

by David Nolden

Hi everybody. Currently, my favorite Game is "IL2-Sturmovik Forgotten Battles", especially it's online-mode. The Game itself is running nearly flawless and at good performance, but I encountered a network-problem which didn't allow the game to connect to any remote server, so I've analyzed and solved the problem. This is what the game does: 1. Create a Datagram-socket 2. Call gethostbyname(own_name) to find out the current IP-Adress 3. Bind the socket to that IP-Adress 4. Try connecting to the remote game using exactly that socket The Problem: gethostbyname(own_name) always returns 127.0.0.1. I've searched a bit on the internet, and this seems always to be the case, not just on my computer. The socket is then bound to the ip-adress 127.0.0.1, and to it's corresponding loopback-interface, so it's unusable. Any connection-request times out. I don't really know much about Networking itself, I just know how to use IP-Networking, but I think it's pretty boring(especially the way it all is implemented) so I don't even know what IPV6 is, and I don't know if my patch is compatible with it(although I think so). Also I don't know if returning 127.0.0.1 is in fact not a bug but desired, and the game is doing something wrong here. But if it is desired that gethostbyname(own_name) preferrably returns the public IP-Adress, then this code should solve the problem, although maybe a bit more checking should be done which IP-Adress should be chosen as the public one for cases with multiple non-loopback-interfaces. I submit this patch to the wine-devel-list so people who know more about all the network-handling can discuss about it, and decide whether it should be put to cvs, or whether there is a better Solution for this problem. The Code enumerates all available Interfaces through the kernel, and decides which one should be used in a very naive way. greetings, David Nolden (btw. my subscription to the list doesn't seem to be complete yet, I'm sending this anyway)

Dec. 12, 2005

BUG (3920) + sync between DIBs and X Server optimisation. (please help)

by Marinescu-Ghetau Iulian

I came to the conclusion that the slowness in "Heroes IV" it has to do with sync'ing lage bitmaps between application DIBs and X Server(see the log: http://bugs.winehq.org/attachment.cgi?id=1470&action=view ). Also, a complete description of the bug is here: http://bugs.winehq.org/show_bug.cgi?id=3902 So i had this ideea that every GDI function could memorise the rectangle that is modifying, so each time a sync between DIB and X Server is needed, only a small part from the bitmap will get copied! I also made some changes to dib.c, bitblt.c and x11drv.h in "wine-0.9.2\dlls\x11drv" folder to implement my ideea, keeping backwards compatibility (if a DIB function doesn't set a valid rectangle for the bitmap that its modifying, the default values are taken - which is the entire bitmap) The changes i was talking about are listed below! My free time is very limited and i would strongly appreciate some help, moustly because something is not working ;( and i didn't manage to figure out what... -added member to X_PHYSBITMAP: XRectangle modified_rect; -added 2 functions: /*********************************************************************** * X11DRV_SetBoundRect */ void X11DRV_SetBoundRect(X_PHYSBITMAP *physBitmap, INT x, INT y, INT width, INT height) { XRectangle *t; INT xMin,yMin,xMax,yMax; if (!physBitmap) return; t = &(physBitmap->modified_rect); if ( t->width && t->height && /*already a valid rect inside*/ width && height ) /*not trying to invalidate rect*/ { //calculate the union of the two rectangles xMin = ((t->x < x)?t->x:x); yMin = ((t->y < y)?t->y:y); xMax = ((t->x + t->width > x + width)?(t->x + t->width):(x + width)); yMax = ((t->y + t->height > y + height)?(t->y + t->height):(y + height)); t->x = xMin; t->y = yMin; t->width = xMax - xMin; t->height = yMax - yMin; } else { t->x = x; t->y = y; t->width = width; t->height = height; } TRACE("(%p,%d,%d,%d,%d)\n", physBitmap->hbitmap, t->x, t->y, t->width, t->height); } /*********************************************************************** * X11DRV_GetBoundRect */ UINT X11DRV_GetBoundRect(X_PHYSBITMAP *physBitmap, INT *x, INT *y, INT *width, INT *height) { DIBSECTION dib; XRectangle *t; if (!physBitmap || GetObjectW( physBitmap->hbitmap, sizeof(dib), &dib ) != sizeof(dib)) { ERR("called for non-DIBSection!?\n"); return 1; } t = &(physBitmap->modified_rect); /* we should check for oversize values */ if ( (t->width > 0) && (t->height > 0) && (t->x < dib.dsBm.bmWidth) && (t->y < dib.dsBm.bmHeight) ) { *x = t->x; *y = t->y; if (t->x + t->width > dib.dsBm.bmWidth) *width = dib.dsBm.bmWidth - t->x; else *width = t->width; if (t->y + t->height > dib.dsBm.bmHeight) *height = dib.dsBm.bmHeight - t->y; else *height = t->height; } else { *x = 0; *y = 0; *width = dib.dsBm.bmWidth; *height = dib.dsBm.bmHeight; } TRACE("(%p,%d,%d,%d,%d)\n", physBitmap->hbitmap, *x, *y, *width, *height); return 0; } -changed X11DRV_DIB_DoUpdateDIBSection like this: static void X11DRV_DIB_DoUpdateDIBSection(X_PHYSBITMAP *physBitmap, BOOL toDIB) { INT x,y,width,height; if ( X11DRV_GetBoundRect(physBitmap,&x,&y,&width,&height) ) return; /*invalidate bound rect*/ X11DRV_SetBoundRect(physBitmap,0,0,0,0); X11DRV_DIB_DoCopyDIBSection(physBitmap, toDIB, physBitmap->colorMap, physBitmap->nColorMap, physBitmap->pixmap, x, y, x, y, // i think something is wrong here (help?) width, height); } - and finally, a GDI function calls it like this (for example bitblt): X11DRV_SetBoundRect(physDevDst->bitmap,xDst,yDst,width,height); X11DRV_CoerceDIBSection( physDevDst, DIB_Status_GdiMod, FALSE ); if (physDevDst != physDevSrc) { X11DRV_SetBoundRect(physDevSrc->bitmap,xSrc,ySrc,width,height); X11DRV_CoerceDIBSection( physDevSrc, DIB_Status_GdiMod, FALSE ); } result = BITBLT_InternalStretchBlt( physDevDst, xDst, yDst, width, height, physDevSrc, xSrc, ySrc, width, height, rop ); END: if (physDevDst != physDevSrc) X11DRV_UnlockDIBSection( physDevSrc, FALSE ); X11DRV_UnlockDIBSection( physDevDst, TRUE );

Dec. 12, 2005

invalid window width/height

by Cihan Altinay

Hi, I tried to find some information on those messages like err:x11drv:X11DRV_CreateWindow invalid window width 0x10042 -215 What does native do when called with negative widths/height? I found it particularly interesting that Worms Armageddon creates static windows where the x/y coordinates and the width/height correlate like this: x=225 y=39 w=-215 h=-29 (ie. the negative of w and h is always 10px less than the x/y coords) Are these arbitrary values that should be ignored (do we need the err message in that case)? I didn't find a test case for negative values... Cheers, Cihan

Dec. 12, 2005

Re: Outreach to windows ISVs

by Andreas Mohr

Hi, On Mon, Dec 12, 2005 at 02:55:26AM -0800, Dan Kegel wrote: > On 12/12/05, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > > > http://kegel.com/wine/isv/ > > > > Some important missing keywords/topics: "porting", "MFC", "Visual Basic", > > "Unix", "win32", "api", "toolkit". > > Those omissions alone would account for a > 50% internet search failure rate, > > I'm sure ;) > > OK, check it now! Muuuch better, thanks! And perhaps also mention wxwidgets.org (high MFC similarity) and Qt (good MFC porting support, AFAIK) somewhere on the sidelines (it's sorta off-topic), for the yet undecided. Andreas Mohr

Dec. 12, 2005

Re: Outreach to windows ISVs

by Dan Kegel

On 12/12/05, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > > http://kegel.com/wine/isv/ > > Some important missing keywords/topics: "porting", "MFC", "Visual Basic", > "Unix", "win32", "api", "toolkit". > Those omissions alone would account for a > 50% internet search failure rate, > I'm sure ;) OK, check it now! > BTW, big thanks for all your Linux Desktop-centric efforts! You're welcome. All I ask in return is the occasional beer and pizza fix :-) - Dan -- Why won't Johnny run Linux? See http://kegel.com/linux/comfort

Dec. 12, 2005