Re: tools: add a wrapper script for starting files from file managers and make wine.desktop use it
Please do not commit this patch as explained in comment 18 of bug 5224: http://bugs.winehq.org/show_bug.cgi?id=5224#c18 Windows explorer's default behavior is to always start programs with double quotes around their filenames, even if the filename does not contain a space. Apparently, this is impossible (or more difficult than it's worth) to do in a shell script so I will need to rewrite this as a winelib program. On Feb 13, 2008 7:44 PM, Vincent Povirk <[EMAIL PROTECTED]> wrote: > This is an attempt to solve the problems with double-clicking .exe > files from file managers. > > The patch adds a script named winestartfile that mimics what happens > on windows when a file is double-clicked in explorer. It starts the > file using start.exe with the full path to the file and in the > directory that contains it. > > It also modifies the wine.desktop shortcut to use that script when > opening .exe files. > > My previous attempt at this incorrectly ran start without giving a > full path (so that if a file named start.exe exists in the current > path, it will take precedence) and probably tried to change too many > things at once. > > -- > Vincent Povirk > -- Vincent Povirk
New winetricks 20080216: fixed comctl32 override, hide winetrickscache, add --version option
Austin nudged me into fixing comctl32 override, which has been broken since wine added support for sxs assemblies. He also was the third person to suggest hiding winetrickscache, so I guess it's what people want. And I added a --version option for a guy who said it would make packaging easier. As always, it's available at http://kegel.com/wine/winetricks and the svn repository is http://code.google.com/p/winezeug/ -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Autoplay considered harmful
On Feb 16, 2008 2:29 PM, Chris Robinson <[EMAIL PROTECTED]> 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
Re: ddraw: Assign to structs instead of using memcpy
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.
Re: ddraw: Assign to structs instead of using memcpy
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), ¤t_viewport);
Re: WineD3D: add separate alpha blend support 3/3
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. signature.asc Description: This is a digitally signed message part.
Re: Autoplay considered harmful
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.
Re: Autoplay considered harmful
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 <[EMAIL PROTECTED]> >> To: Steven Edwards <[EMAIL PROTECTED]> >> Cc: wine-devel ; Dan Kegel <[EMAIL PROTECTED]> >> 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&type=business >> 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 > > > > >
Re: Autoplay considered harmful
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 <[EMAIL PROTECTED]> > To: Steven Edwards <[EMAIL PROTECTED]> > Cc: wine-devel ; Dan Kegel <[EMAIL PROTECTED]> > 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&type=business > >> 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
Re: X developer's conference, April 16-18
On Feb 16, 2008 9:47 AM, Vitaliy Margolen <[EMAIL PROTECTED]> 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!
Re: X developer's conference, April 16-18
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
Re: Autoplay considered harmful
John Klehm wrote: >> Dan Kegel wrote: >> >>> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&type=business >>> 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... >>> >>> > > Completely not supported or disabled by default? > > --John Klehm > The autorun.inf files are simple enough to support with a simple script, and they usually launch a windows program. This can be implementet in an end system with minimum effort and no changes to the wine codebase. I'm firmly opposed to wine polling disk drives for new mediums and autoplaying them by default. -- Robert Lövlie [EMAIL PROTECTED]
MSG_PEEK race in urlmon_test?
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 <[EMAIL PROTECTED]> http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
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 <[EMAIL PROTECTED]> wrote: > >> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&type=business >> 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. > >
Re: X developer's conference, April 16-18
> 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 > Perhaps X developers should be aware about the way we implement windowed opengl rendering (bug 2398) using Composite. Basically we use an 'offscreen' window as a buffer and so now and then we copy this data over. Not all drivers support this properly yet (yes, they are working on features like this) but I don't think most are aware of the way Wine uses them (there is more than compiz). Roderick -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Re: Autoplay considered harmful
On Feb 16, 2008 8:58 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: > http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&type=business > 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. -- 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
Re: Autoplay considered harmful
On Feb 16, 2008 7:08 AM, John Klehm <[EMAIL PROTECTED]> wrote: > > Dan Kegel wrote: > > > http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&type=business > > > 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... > > Completely not supported or disabled by default? By default, I guess. Some customers might know their cd-rom's are safe, and we should let them enable it via a control panel, I guess. But autoplay support is kind of a distro packaging thing, I think, so we probably have to discuss this with whoever builds the packages...?
Re: Autoplay considered harmful
> Dan Kegel wrote: > > http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&type=business > > 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... > > Completely not supported or disabled by default? --John Klehm
Re: dlls/shell32/pidl.c -- adjust to unsignedness of a type
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> @@ -109,7 +109,7 @@ BOOL WINAPI ILGetDisplayNameExW(LPSHELLF
> return FALSE;
> }
>
> -if (type >= 0 && type <= 2)
> +if (type <= 2)
> {
> switch (type)
> {
The test should probably be removed completely since there's already a
default for it in the switch() that follows.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [1/16] msxml3: Support functions for typelib
Alistair Leslie-Hughes <[EMAIL PROTECTED]> writes:
> +HRESULT get_typeinfo(enum tid_t tid, ITypeInfo **typeinfo)
> +{
> +HRESULT hres;
> +
> +if(!typelib) {
> +ITypeLib *tl;
> +
> +hres = LoadRegTypeLib(&LIBID_MSXML2, 3, 0, LOCALE_SYSTEM_DEFAULT,
> &tl);
> +if(FAILED(hres)) {
> +ERR("LoadRegTypeLib failed: %08x\n", hres);
> +return hres;
> +}
> +
> +if(InterlockedCompareExchangePointer((void**)&typelib, tl, NULL))
> +ITypeLib_Release(tl);
> +}
> +
> +if(!typeinfos[tid]) {
> +ITypeInfo *typeinfo;
> +
> +hres = ITypeLib_GetTypeInfoOfGuid(typelib, tid_ids[tid], &typeinfo);
> +if(FAILED(hres)) {
> +ERR("GetTypeInfoOfGuid failed: %08x\n", hres);
> +return hres;
> +}
> +
> +if(InterlockedCompareExchangePointer((void**)(typeinfos+tid),
> typeinfo, NULL))
> +ITypeInfo_Release(typeinfo);
> +}
> +
> +*typeinfo = typeinfos[tid];
> +return S_OK;
You should increment the ref count when you are returning a pointer,
even if it's also stored in a global variable.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Autoplay considered harmful
Dan Kegel wrote: > http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&type=business > 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... > > > +1 Let's not forget the infected CDs as well. James McKenzie
Re: wined3d: Fix bug in swapchain release which causes incorrect display mode changes.
On Saturday 16 February 2008 06:01:48 am Peter Dons Tychsen wrote: > Fixed bug in wined3d swapchain, which caused the release of the > swap-chain to mess around with the display-modes set by ddraw. Also > added test-case for this scenario. Reworked test code minimally, to > re-use existing test code. You may want to test D3D8 and D3D9 too, to see what they do when presented by the situation (since the code is shared). Also I don't think you should make those 2-space indents just to avoid changing those few lines.
X developer's conference, April 16-18
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
Autoplay considered harmful
http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&type=business 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...
Re: [PATCH] Environment variable to specify X11 window for desktop
"Timothy Lee" <[EMAIL PROTECTED]> wrote: >> I'm struggling to imagine a case where the behaviour you've >> implemented is useful. >> > I'm actually using this code as the basis of a PowerPoint plugin under > Linux. I little bit more information won't hurt. For instance why your plugin needs to re-route the whole desktop window, and not just its own one. -- Dmitry.
Re: winedos: Allocate a console when loading dos applications
"Maarten Lankhorst" <[EMAIL PROTECTED]> writes: > These things make me think that the old behavior of wine is more > correct then the current one, with relation to console handles. The behavior hasn't changed for console handles, but the default case is to run on the unix stdio handles, not true console ones. That's a feature, we don't want to create a separate window for a simple command line app. There are two bugs here: one is that the unix stdio should be presented to the app as a real console as far as possible, the other is that the code should work correctly on non-console handles because even if we fix the first one we can always redirect i/o. The second bug should be easier to fix so I'd suggest to start with that. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH] Environment variable to specify X11 window for desktop
Robert Shearman wrote: > Timothy Lee wrote: >> The attached patch allows the WINE desktop to be embedded within an >> existing X11 window, and is similar to the windowed mode in WINE. >> >> I've tested this feature using MS PowerPoint Viewer 2007, so that a >> fullscreen slideshow can be fitted inside any X11 window. > > I'm struggling to imagine a case where the behaviour you've > implemented is useful. > I'm actually using this code as the basis of a PowerPoint plugin under Linux. Regards, Timothy
Re: d3dx9 patches
Okay, thanks. Then I'll just resend them and see if they get in this time. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
