February 2008 - Wine-Devel - list.winehq.org

Re: Autoplay considered harmful

by Steven Edwards

On Feb 16, 2008 2:29 PM, Chris Robinson <chris.kcat(a)gmail.com> wrote: > Some desktop managers already do autoplay-like behavior. In KDE, when I put in > a CD/DVD for the first time, it'll ask me if I want to play it (if it's a > video dvd/audio cd), if I want to open a burning program (if it's a blank > cd/dvd), or if I want to browse it. And whether I want it to continue asking. > It'd be quite annoying for both Wine *and* the DM to keep trying to autorun a > disc I put in. Ideally the freedesktop should define a spec (which they may already do as part of HAL) that we should be able to interface with. There should be a way to have the auto insert event detect a autorun.inf and prompt the user if they want to open it with Wine. If no one else wants to research it I'll try to take a look in to it sometime. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 17, 2008

Re: ddraw: Assign to structs instead of using memcpy

by Andrew Talbot

Stefan Dösinger wrote: > Am Samstag, 16. Februar 2008 23:33:37 schrieb Andrew Talbot: >> Here, I am assuming that the "dwSize" elements in all these cases should >> be set to the size of the struct each is in, respectively. Please advise >> if this assumption is wrong. > It's not necessarily true. Sometimes there are multiple versions of the > same structure. You can check ddraw.h and d3dtypes.h. If there is only one > version your assumption should be true. > > If there isn't, then your assumption may still be true. In that case there > are some tests how the Setter methods deal with newer or older > structures(in some cases we may need more tests) > Hi Stefan, I checked that I wasn't assigning between entities whose types had different suffixes, such as assigning to a D3DVIEWPORT variable from one of type D3DVIEWPORT2, for example. (In fact, the only one I had to avoid was the assignment to a DDSURFACEDESC type variable from a DDSURFACEDESC2 one, in ddraw/ddraw_thunks.c.) And I presume that if the underlying struct tags are different between two similar types, then the compiler would warn of type incompatibility if such an assignment were attempted. Thanks, -- Andy.

Feb. 17, 2008

Re: ddraw: Assign to structs instead of using memcpy

by Stefan Dösinger

Am Samstag, 16. Februar 2008 23:33:37 schrieb Andrew Talbot: > Here, I am assuming that the "dwSize" elements in all these cases should be > set to the size of the struct each is in, respectively. Please advise if > this assumption is wrong. It's not necessarily true. Sometimes there are multiple versions of the same structure. You can check ddraw.h and d3dtypes.h. If there is only one version your assumption should be true. If there isn't, then your assumption may still be true. In that case there are some tests how the Setter methods deal with newer or older structures(in some cases we may need more tests) > Thanks, > > -- Andy. > --- > Changelog: > ddraw: Assign to structs instead of using memcpy. > > diff --git a/dlls/ddraw/device.c b/dlls/ddraw/device.c > index b60b6f3..03ccea8 100644 > --- a/dlls/ddraw/device.c > +++ b/dlls/ddraw/device.c > @@ -704,7 +704,7 @@ > IDirect3DDeviceImpl_1_CreateExecuteBuffer(IDirect3DDevice *iface, > object->d3ddev = This; > > /* Initializes memory */ > - memcpy(&object->desc, Desc, Desc->dwSize); > + object->desc = *Desc; > > /* No buffer given */ > if ((object->desc.dwFlags & D3DDEB_LPDATA) == 0) > diff --git a/dlls/ddraw/material.c b/dlls/ddraw/material.c > index d6b9a7c..8e17174 100644 > --- a/dlls/ddraw/material.c > +++ b/dlls/ddraw/material.c > @@ -250,7 +250,7 @@ IDirect3DMaterialImpl_SetMaterial(IDirect3DMaterial3 > *iface, /* Stores the material */ > EnterCriticalSection(&ddraw_cs); > memset(&This->mat, 0, sizeof(This->mat)); > - memcpy(&This->mat, lpMat, lpMat->dwSize); > + This->mat = *lpMat; > LeaveCriticalSection(&ddraw_cs); > > return DD_OK; > @@ -285,7 +285,7 @@ IDirect3DMaterialImpl_GetMaterial(IDirect3DMaterial3 > *iface, EnterCriticalSection(&ddraw_cs); > dwSize = lpMat->dwSize; > memset(lpMat, 0, dwSize); > - memcpy(lpMat, &This->mat, dwSize); > + *lpMat = This->mat; > LeaveCriticalSection(&ddraw_cs); > > return DD_OK; > diff --git a/dlls/ddraw/viewport.c b/dlls/ddraw/viewport.c > index deb4146..8dfc015 100644 > --- a/dlls/ddraw/viewport.c > +++ b/dlls/ddraw/viewport.c > @@ -261,7 +261,7 @@ IDirect3DViewportImpl_GetViewport(IDirect3DViewport3 > *iface, } > dwSize = lpData->dwSize; > memset(lpData, 0, dwSize); > - memcpy(lpData, &(This->viewports.vp1), dwSize); > + *lpData = This->viewports.vp1; > > if (TRACE_ON(d3d7)) { > TRACE(" returning D3DVIEWPORT :\n"); > @@ -301,7 +301,7 @@ IDirect3DViewportImpl_SetViewport(IDirect3DViewport3 > *iface, EnterCriticalSection(&ddraw_cs); > This->use_vp2 = 0; > memset(&(This->viewports.vp1), 0, sizeof(This->viewports.vp1)); > - memcpy(&(This->viewports.vp1), lpData, lpData->dwSize); > + This->viewports.vp1 = *lpData; > > /* Tests on two games show that these values are never used properly > so override them with proper ones :-) > @@ -856,7 +856,7 @@ IDirect3DViewportImpl_GetViewport2(IDirect3DViewport3 > *iface, } > dwSize = lpData->dwSize; > memset(lpData, 0, dwSize); > - memcpy(lpData, &(This->viewports.vp2), dwSize); > + *lpData = This->viewports.vp2; > > if (TRACE_ON(d3d7)) { > TRACE(" returning D3DVIEWPORT2 :\n"); > @@ -895,7 +895,7 @@ IDirect3DViewportImpl_SetViewport2(IDirect3DViewport3 > *iface, EnterCriticalSection(&ddraw_cs); > This->use_vp2 = 1; > memset(&(This->viewports.vp2), 0, sizeof(This->viewports.vp2)); > - memcpy(&(This->viewports.vp2), lpData, lpData->dwSize); > + This->viewports.vp2 = *lpData; > > if (This->active_device) { > > IDirect3DDevice3_GetCurrentViewport(ICOM_INTERFACE(This->active_device, > IDirect3DDevice3), &current_viewport);

Feb. 16, 2008

Re: WineD3D: add separate alpha blend support 3/3

by Stefan Dösinger

Am Samstag, 16. Februar 2008 17:29:31 schrieb Roderick Colenbrander: > Hi, > > This patch adds support for separate alpha blend one of the last > unimplemented D3D9 features. Here are a few suggestions: *) Setting WINED3DPMISCCAPS_SEPARATEALPHABLEND in directx.c should only be done if the extension is supported *) after the "GL_LINE_SMOOTH needs GL_BLEND to work, according to the", WINED3DRS_SEPARATEALPHABLENDENABLE should probably be removed from the if block. I don't think that blending should be enabled if the WINED3DRS_ALPHABLENDENABLE is off. A test would be helpful for certainty. *) The code translating the separate blending settings could be moved into the if(stateblock->renderState[WINED3DRS_SEPARATEALPHABLENDENABLE]) block. That way they are only executed if they're needed(The compiler may take care of that though) *) The separate blend states should be grouped with the alpha states, ie, set the representative to STATE_RENDER(WINED3DRS_ALPHABLENDENABLE) instead of STATE_RENDER(WINED3DRS_SEPARATEALPHABLENDENABLE). Not doing that should not cause any rendering problems because the whole alpha blend states are set every time, but grouping them will improve performance. (e.g., if alphablendenable and separatealphaenable are changed state_blend is only executed once, not twice) *) The blendop is currently not reapplied if WINED3DRS_SEPARATEALPHABLENDENABLE is changed. One solution is to group the blendops with alphablend and move the code from state_blendop to state_blend. A better way is to make this a one-way dependency from state_alpha to state_blend. Compare STATE_RENDER(WINED3DRS_LIGHTING) and STATE_VDECL for a reference.

Feb. 16, 2008

Re: Autoplay considered harmful

by Chris Robinson

On Saturday 16 February 2008 10:54:47 am Remco wrote: > Vista (and I think XP too) ask whether you want to start the Autorun > program, or do a few other actions (open explorer, copy disk, etc). Some desktop managers already do autoplay-like behavior. In KDE, when I put in a CD/DVD for the first time, it'll ask me if I want to play it (if it's a video dvd/audio cd), if I want to open a burning program (if it's a blank cd/dvd), or if I want to browse it. And whether I want it to continue asking. It'd be quite annoying for both Wine *and* the DM to keep trying to autorun a disc I put in.

Feb. 16, 2008

Re: Autoplay considered harmful

by Evil Jay

XP does not do this. I've never used Vista, nor can I imagine why anyone would want to. If Vista does do this, then prompting would be proper, but only when Wine is configured to present itself as Vista. -J Remco wrote: > Vista (and I think XP too) ask whether you want to start the Autorun program, or do a few other actions (open explorer, copy disk, etc). > > Remco > > ----- Original Message ---- > >> From: Evil Jay <wine(a)eternaldusk.com> >> To: Steven Edwards <winehacker(a)gmail.com> >> Cc: wine-devel <wine-devel(a)winehq.org>; Dan Kegel <dank(a)kegel.com> >> Sent: Saturday, February 16, 2008 5:44:15 PM >> Subject: Re: Autoplay considered harmful >> >> The purist in me says that WINE should not improve on Windows - it >> should behave the same way, warts and all. If I had a vote, I'd vote to >> enable it by default, but give the user an easy way to disable it in >> winecfg. (And I'd immediately disable it the first time I ran Winecfg!) >> >> But, whatever you guys decide to do is cool - as long as you keep >> cranking out this great package! :) >> >> -Jesse >> >> >> >> Steven Edwards wrote: >> >>> On Feb 16, 2008 8:58 AM, Dan Kegel wrote: >>> >>> >> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&t… >> >>>> says that USB devices are being sold with infected >>>> autorun apps. "If you plug in, you're already infected," >>>> >>>> I'd say that's a pretty good argument for not supporting autoplay... >>>> >>>> >>> I was actually thinking about this today. The right method would be to >>> use HAL notification events to prompt the user if they want to autorun >>> when sticking a new cdrom in. There could even be warning text in the >>> dialog so that if it pops up with other device insertion, the user >>> would know that it could be a virus. >>> >>> >>> >> >> >> > > > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > > > > >

Feb. 16, 2008

Re: Autoplay considered harmful

by Remco

Vista (and I think XP too) ask whether you want to start the Autorun program, or do a few other actions (open explorer, copy disk, etc). Remco ----- Original Message ---- > From: Evil Jay <wine(a)eternaldusk.com> > To: Steven Edwards <winehacker(a)gmail.com> > Cc: wine-devel <wine-devel(a)winehq.org>; Dan Kegel <dank(a)kegel.com> > Sent: Saturday, February 16, 2008 5:44:15 PM > Subject: Re: Autoplay considered harmful > > The purist in me says that WINE should not improve on Windows - it > should behave the same way, warts and all. If I had a vote, I'd vote to > enable it by default, but give the user an easy way to disable it in > winecfg. (And I'd immediately disable it the first time I ran Winecfg!) > > But, whatever you guys decide to do is cool - as long as you keep > cranking out this great package! :) > > -Jesse > > > > Steven Edwards wrote: > > On Feb 16, 2008 8:58 AM, Dan Kegel wrote: > > > >> > http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&t… > >> says that USB devices are being sold with infected > >> autorun apps. "If you plug in, you're already infected," > >> > >> I'd say that's a pretty good argument for not supporting autoplay... > >> > > > > I was actually thinking about this today. The right method would be to > > use HAL notification events to prompt the user if they want to autorun > > when sticking a new cdrom in. There could even be warning text in the > > dialog so that if it pops up with other device insertion, the user > > would know that it could be a virus. > > > > > > > > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

Feb. 16, 2008

Re: X developer's conference, April 16-18

by Dan Kegel

On Feb 16, 2008 9:47 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > - relative mouse motion events > > I'd phrase this as ability to open main pointer device and keyboard as > XInput device. That will be enough. Ah. Yes. That makes a lot more sense. Thanks!

Feb. 16, 2008

Re: X developer's conference, April 16-18

by Vitaliy Margolen

Dan Kegel wrote: > http://www.x.org/wiki/Events/XDC2008 > > Seems like Wine might want a representative. > What issues would we want to bring up there? > - relative mouse motion events > ...? > > - Dan > > I'd phrase this as ability to open main pointer device and keyboard as XInput device. That will be enough. Vitaliy

Feb. 16, 2008

MSG_PEEK race in urlmon_test?

by Francois Gouget

When I run the urlmon_test test the kernel (2.6.22.9) has this to say: Feb 16 05:53:54 amboise kernel: TCP(urlmon_test.exe:9836): Application bug, race in MSG_PEEK. Does anyone know what's up with that? Maybe someone who knows more than me about urlmon? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

Feb. 16, 2008