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

Re: [Tools/Wine.inf] Set Internet Explorer version

by Robert Shearman

Vitaliy Margolen wrote: >Thursday, June 29, 2006, 6:28:11 PM, Olaf Leidinger wrote: > > >>On Thu, 29 Jun 2006 10:56:12 -0700 >>"James Hawkins" <truiken(a)gmail.com> wrote: >> >> > > > >>>On 6/28/06, Maarten Lankhorst <M.B.Lankhorst(a)gmail.com> wrote: >>> >>> >>>>Should we require that people install Internet Explorer or should we put >>>>in patches that increase application compatibility with vanilla wine? >>>> >>>> >>>I don't know why we would require people to install IE, when we have a >>>replacement for it already. >>> >>> > > > >>Web designers - to see what their pages look like in IE. But they could also install IE 7. >> >> > >As been mentioned before this argument is invalid. Native IE does not and will >not behave like on real windows. Thus rendering any such tests invalid. > IE running in Wine still allows me to view sites that don't display properly in Firefox, so it definitely has a use. -- Rob Shearman

June 30, 2006

Re: DDRAW: Releasing attached surfaces

by Stefan Dösinger

Hi, > That's weird, now it works without the "fix" and even Tiberian Sun > starts where previously it hung. > I must have wrongly assumed that the bug was related to surface > implementation code... > But i'm still curious what might be the cause. Will check that out later. > Sorry for bothering then... ;) It was most likely the fix for Tiberian Sun that fixed dune. The problem with ts was that the primary surfaces(front and back) were missing some flags. Maybe dune didn't like the surfaces it got and tried to get rid of them and hit a buggy code path in its code. Stefan

June 30, 2006

Re: wine autorun utility

by Saulius Krasuckas

Forgive my lazyness and my bad english, but IMHO most of discussion resembles MS Corporation behaviour by trying to decide what is good for a user, and what is not. Hey, just let the user or his admin to decide this. IMO there should be just one checkbox in winecfg that rules autorunability. * On Fri, 30 Jun 2006, Tim Schmidt wrote: > KDE and Gnome already have similar functionality. No reason the parser > can't go there (where, perhaps, people might be a little less hostile to > the idea?) Right, but then it still should be nice to find a way for Wine to know if KDE/Gnome is set to autorun win32 apps. And a way to toggle this KDE/Gnome setting. This way could let user/admin to manage autorunability from winecfg by clicking mentioned checkbox. Otherwise user/admin would complain about Wine inability to integrate with the rest of a graphical system :-/ And of course, the autorunability should be disabled by default when graphical environment knows/says nothing about autoruns. Just likes all my neighbouring win-admins do for their customized/unattended XP setups. <g> Hm, someone should show this thread to KDE/Gnome/FreeDesktop folks, IMHO. I am off this task ;)

June 30, 2006

Re: wine autorun utility

by Tim Schmidt

On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: > Parsing a windows inf hardly belongs anywhere but wine. Actually, Troy makes that point rather well in an earlier mail: > This is not true. The existing action-on-CD-insertion programs provided by the > desktop environment try to detect the contents of the CD to see what they > should do, so they will be looking for the autorun.inf file. Additionally the > autorun.inf file format is designed to include specifications of different > commands for multiple environments, so if autorun.inf files are to be > respected at all it makes sense that they should also be able to start a > native Linux executable or shell script (discovered from an > [autorun.linux.i386] section, for example). > > There is nothing in this that requires or enhances the Win32 API facilities > that Wine seeks to provide. Only once the native Windows executable has been > identified as the only (or best) target for autorun would Wine become > involved, when the program in the desktop environment invoked Wine to run the >executable. --tim

June 30, 2006

Re: wine autorun utility

by Tim Schmidt

On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: > Yeah, then in that situation the user wouldn't run `wine --media- > autorun /mountpoint/autorun.inf` either. I fail to see your point. Hey... If all you want to do is write a parser for autorun.inf files and attach it to a command line switch, that sounds pretty easy. Where's the patch? That said, as others have mentioned, KDE and Gnome already have similar functionality. No reason the parser can't go there (where, perhaps, people might be a little less hostile to the idea?) --tim

June 30, 2006

Re: wine autorun utility

by Damjan Jovanovic

--- Chris <chris.kcat(a)gmail.com> wrote: > On Thursday 29 June 2006 21:13, Vitaliy Margolen > wrote: > > Chris if you think that autostart is such a great > idea - you are very > > welcome to start sending patches in. And if they > are reasonable enough they > > might get in. But if you want to rant about that > Linux doesn't have some > > absolutely required "feature" that windows has - > this not the right place. > > This sounds like you missed my point. My argument > isn't that autorun is cool > and Linux should have it (when in fact KDE *does* > have it, to some degree), > my argument is that Windows has it and it's not > inherently detramental (since > the user would be instructed to manually do what > autorun does automatically > anyway, and hence have the same effects), so Wine, > if it is trying to match > Windows feature-for-feature and bug-for-bug, should > have it too. IMO, of > course. Exactly. Windows is such a ubiquitous OS that it sets the standards for all others. Users see Windows autoruning stuff, so when Linux doesn't, "Windows is better". > If I knew how dbus and hal worked, I would probbly > try to make the necesarry > patches. But as I'm not familiar with Win32 or > Wine's internals, I'm not > really qualified to work on it, at this time. I'm > just a user voicing my > opinion. > Chances are it's probably going to work better (and raise fewer objections from developers) if you start wine from the Gnome or KDE autorun, rather than try make wine autorun stuff internally. (Autoruning stuff internally in wine is problematic: both wine and Gnome/KDE could be trying to autorun something at the same time!) I've used hal and dbus before: they're not as bad as they look. Look at wine's explorer, it uses them to both monitor hardware for changes and query hardware properties. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

June 30, 2006

Re: wine autorun utility

by Troy Rollo

On Friday 30 June 2006 15:47, William Knop wrote: > 2) The line you refer to I believe would put detecting media inserts > on the desktop environment side, and the parsing and execution of > windows autorun inf files on the wine side. This is not true. The existing action-on-CD-insertion programs provided by the desktop environment try to detect the contents of the CD to see what they should do, so they will be looking for the autorun.inf file. Additionally the autorun.inf file format is designed to include specifications of different commands for multiple environments, so if autorun.inf files are to be respected at all it makes sense that they should also be able to start a native Linux executable or shell script (discovered from an [autorun.linux.i386] section, for example). There is nothing in this that requires or enhances the Win32 API facilities that Wine seeks to provide. Only once the native Windows executable has been identified as the only (or best) target for autorun would Wine become involved, when the program in the desktop environment invoked Wine to run the executable. -- Troy Rollo - wine(a)troy.rollo.name

June 30, 2006

Re: wine autorun utility

by William Knop

On Jun 30, 2006, at 2:01 AM, Tim Schmidt wrote: > On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: >> 1) While I agree maintaining a staunch security policy is important, >> that has nothing to do with autorun. Making the user browse to find >> an executable is not security. > > Yet again... when a user sticks an audio CD in his computer and gets > a rootkit because of autorun, that's _b_a_d_ > > That user isn't going to browse out to the rootkit and install it > him/her self. Yeah, then in that situation the user wouldn't run `wine --media- autorun /mountpoint/autorun.inf` either. I fail to see your point. Will

June 30, 2006

Re: [AppDb] update the comments in some files

by Jonathan Ernst

Le jeudi 29 juin 2006 à 12:43 -0400, Chris Morgan a écrit : > Why not replace the require_once() with requires instead of putting it on the > todo? Because we have to check that it nevers poses a problem (for example if the file is included elsewhere), so that's another patch entierly. > We don't really need the $aClean TODO item since thats high on the priority > list at the moment and we'll just end up removing it in a day or two right? i don't like to rediff it, we'll have to remove the aClean one by one to be sure that it's not posing problems too so that we can remove the todo elements one by one in the files. > > The move of show_note() into its class is on my todo list for class cleanups > today or tomorrow as well. Excellent, you'll remove the todo item at the same time then. > > Basically I think we can do without the todo notes for now since most of it is > in the process of being fixed. The rest of the comments look good though. Please don't refuse this patch because of this, I don't want to rediff it... Thanks

June 30, 2006

Re: wine autorun utility

by Tim Schmidt

On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: > 1) While I agree maintaining a staunch security policy is important, > that has nothing to do with autorun. Making the user browse to find > an executable is not security. Yet again... when a user sticks an audio CD in his computer and gets a rootkit because of autorun, that's _b_a_d_ That user isn't going to browse out to the rootkit and install it him/her self. --tim

June 30, 2006