June 2006 - Wine-Devel - list.winehq.org

Re: urlmon: Implement URLDownloadToCacheFile

by Troy Rollo

On Friday 30 June 2006 07:36, James Hawkins wrote: > + lstrcatW(cache_path, backslash); > + lstrcatW(cache_path, content); > + > + if (!GetTempFileNameW(cache_path, prefix, 0, cache_path)) > + return E_FAIL; > + > + if (lstrlenW(cache_path) > dwBufLength) > + return E_INVALIDARG; > + > + lstrcpyW(szFileName, cache_path); > + > + return URLDownloadToFileW(lpUnkCaller, szURL, szFileName, 0, pBSC); This is not the correct behaviour - doing this will result in the cache directories filling up with files that are not mentioned in the cache index. You should be calling CreateUrlCacheEntryW to get the file name for the new file. -- Troy Rollo - wine(a)troy.rollo.name

June 29, 2006

Re: Call for volunteer: dwarf2 testing

by Paul Romanyszyn

Eric Pouech wrote: > As you may have seen, there's now some support for the dwarf2 debug > format (instead of stabs) in the Wine tree > I'd like to get some feedback on the overall feedback on how it behaves. > To do so, you need to reconfigure Wine with something like > CFLAGS="$CFLAGS -gdwarf-2" ./configure > and then make clean; make (so that all modules are recompiled with > proper format) > > Normal debugging should be available with winedbg. > If something goes wrong, please indicate: > - console messages > - error items > - steps that led to it > - version of gcc used > > TIA > > running a 16 bit application from bug Bug 5493 now gives an a continuous list of fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 instead of continuous page faulting between on the lookup. What traces do you need and I will add them to that bug. That bugs url links to the zip of the exe's with instructions on how to reproduce. gcc (GCC) 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0) Paul R.

June 29, 2006

Re: DDRAW: Releasing attached surfaces

by H. Verbeet

On 29/06/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > If someone can think of a way to prove that a COM object is actually destroyed > then a test case might clear up this issue. > > Stefan Do an AddRef() and hope the memory wasn't overwritten yet? :-)

June 29, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by H. Verbeet

On 29/06/06, Thomas Kho <tkho(a)ucla.edu> wrote: > +(a)REQ(get_menu_item_info) > + user_handle_t handle; > + unsigned int pos; > +(a)REPLY > + unsigned int required_size; > + > + unsigned int type; > + unsigned int state; > + unsigned int id; > + user_handle_t submenu; > + user_handle_t checkbit; > + user_handle_t uncheckbit; > + void* text; > + unsigned long itemdata; > + void* typedata; > + user_handle_t bmpitem; > + > + rectangle_t rect; > + unsigned int xTab; > + dimension_t bmpsize; > + > + VARARG(text,unicode_str); > +(a)END HBITMAPs aren't technically user handles, and afaik you can't pass GDI handles between processes like that. At least, not on Windows.

June 29, 2006

Re: DDRAW: Releasing attached surfaces

by Stefan Dösinger

Am Donnerstag 29 Juni 2006 16:43 schrieb Krzysztof Benkowski: > Hello, > In the latest version of wine (0.9.16) there is a regression which makes > Dune 2000 crash. > After some debugging i found that the problem lays in > IDirectDrawSurfaceImpl_Release method. > The game (Dune 2000) shows that the assumption that all attached > surfaces should be destroyed > regardless of their refcount is wrong. According to the msdn this should happen, and it sounds logical to me. All complex surfaces are created with one call, so they should be destroyed with one call too. I haven't seen a single app explicitly releasing the back buffer, even the sdk demos don't do that. Ideally a test case could be of help, but I don't know how to test if a surface is actually destroyed. > What causes the crash in few words: > - first Dune 2000 creates a surface with a backbuffer > - then it gets the backbuffer interface by GetAttachedSurface method > (refcount for the backbuffer is incremented) > - it releases the frontbuffer (the backbuffer is destroyed even though > its refcount is higher than frontbuffer's) Are you sure that the front buffer is meant to be destroyed? Maybe the front buffer's refcount is meant to be increased somewhere, so it isn't destroyed? > - creates new frontbuffer and an offscreen plain Does it attach the front buffer to the back buffer, or vice versa? > So my fix is rather quick and thus i'm not quite sure if it's correct. > That's because the game works with it > but when it quits it leaves the backbuffer not released. I don't know if > it's the game's fault or the fix has to be > done some other way. I've done it this way: > > --- surface.c 26 Jun 2006 12:15:20 -0000 1.6 > +++ surface.c 29 Jun 2006 14:09:59 -0000 > @@ -377,7 +377,7 @@ IDirectDrawSurfaceImpl_Release(IDirectDr > while( (surf = This->next_complex) ) > { > This->next_complex = surf->next_complex; /* Unchain it > from the complex listing */ > - IDirectDrawSurfaceImpl_Destroy(surf); /* Destroy it */ > + IDirectDrawSurfaceImpl_Release(surf); /* Release it */ > } This was my original way of handling this, and it lead to huge memory leaks in 3D games which create mipmap textures. Usually they call getAttachedSurface for the sublevels and didn't care to release the surfaces. If someone can think of a way to prove that a COM object is actually destroyed then a test case might clear up this issue. Stefan

June 29, 2006

Call for volunteer: dwarf2 testing

by Eric Pouech

As you may have seen, there's now some support for the dwarf2 debug format (instead of stabs) in the Wine tree I'd like to get some feedback on the overall feedback on how it behaves. To do so, you need to reconfigure Wine with something like CFLAGS="$CFLAGS -gdwarf-2" ./configure and then make clean; make (so that all modules are recompiled with proper format) Normal debugging should be available with winedbg. If something goes wrong, please indicate: - console messages - error items - steps that led to it - version of gcc used TIA

June 29, 2006

Re: [AppDB] Viewing application famlies screen shots is broken.

by Chris Morgan

Should be fixed now. Chris On Thursday 29 June 2006 2:53 pm, Tony Lambregts wrote: > Viewing application famlies screen shots is broken. I don't think is from > todays patches. You can see the problem in the following link. > > http://appdb.winehq.org/screenshots.php?appId=631 > > The random screenshot shows up fine on the application page though. > > http://appdb.winehq.org/appview.php?appId=631 > > -- > > Tony Lambregts

June 29, 2006

[AppDB] Viewing application famlies screen shots is broken.

by Tony Lambregts

Viewing application famlies screen shots is broken. I don't think is from todays patches. You can see the problem in the following link. http://appdb.winehq.org/screenshots.php?appId=631 The random screenshot shows up fine on the application page though. http://appdb.winehq.org/appview.php?appId=631 -- Tony Lambregts

June 29, 2006

Re: appdb/ ./appbrowse.php ./appsubmit.php ./appvi ...

by Chris Morgan

Oh ok. If you wanted you could put that on the TODO page so we didn't forget about it. Chris On Thursday 29 June 2006 2:18 pm, Tony Lambregts wrote: > > Are they supposed to be able to monitor application familes? I'm > > confused as to whether that is a bug or just how things are working. > > > > Chris > > Not a bug just a missing feature. They never could. > > -- > > Tony Lambregts

June 29, 2006

Re: appdb/ ./appbrowse.php ./appsubmit.php ./appvi ...

by Tony Lambregts

> Are they supposed to be able to monitor application familes? I'm confused as > to whether that is a bug or just how things are working. > > Chris > Not a bug just a missing feature. They never could. -- Tony Lambregts

June 29, 2006