Gee sounds like a "great" idea. We all waiting too see some patches...
It sure would be cool to have:
- Multiuser Wine
- Wine stable enough to run as service (err hmm whatever the hell
that means... ah you mean daemon ?)
- Run something more complicated then 'printf("hello world\n");'
without X
- Talk to WMs to show icons and ask questions.
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.
Vitaliy
Um hold on a second. Clearly many developers have different ideas about what's reasonable. It makes sense to obtain a semblance of unanimity and mutual understanding before taking action. You shouldn't go around quashing discussions like that.
Will
On Friday 30 June 2006 14:52, William Knop wrote:
Um hold on a second. Clearly many developers have different ideas about what's reasonable.
Actually I don't think that's true. As far as I can see all of the *developers* participating in this thread agreed that autorun (1) is a bad idea and should not be implemented, and (2) is on the other side of the demarcation line between Wine and the desktop environment.
I would be surprised if any significant number of developers disagreed with these two points. As for the first, it reflects the difference between Windows' security model and the Unix/Linux security model (the difference being that the latter systems actually have a model deserving of the label "security"). As for the second, an end user may well not understand the distinction between Wine's role and that of the desktop environment, but a developer should. Wine is for making Windows applications (and native applications coded to the Windows API) run - I am not aware of any developer who thinks it should be a complete reimplementation of Windows.
On Jun 30, 2006, at 1:08 AM, Troy Rollo wrote:
On Friday 30 June 2006 14:52, William Knop wrote:
Um hold on a second. Clearly many developers have different ideas about what's reasonable.
Actually I don't think that's true. As far as I can see all of the *developers* participating in this thread agreed that autorun (1) is a bad idea and should not be implemented, and (2) is on the other side of the demarcation line between Wine and the desktop environment.
I would be surprised if any significant number of developers disagreed with these two points. As for the first, it reflects the difference between Windows' security model and the Unix/Linux security model (the difference being that the latter systems actually have a model deserving of the label "security"). As for the second, an end user may well not understand the distinction between Wine's role and that of the desktop environment, but a developer should. Wine is for making Windows applications (and native applications coded to the Windows API) run - I am not aware of any developer who thinks it should be a complete reimplementation of Windows.
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.
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. Hell, the user would have to run `wine --media-autorun /mountpoint/autorun.inf`. That has to be as secure as the user running `cd /mountpoint/somedir; wine ./some.exe`.
Will
On 6/30/06, William Knop william.knop@gmail.com wrote:
- 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
On Jun 30, 2006, at 2:01 AM, Tim Schmidt wrote:
On 6/30/06, William Knop william.knop@gmail.com wrote:
- 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
On 6/30/06, William Knop william.knop@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
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 ;)
On Friday 30 June 2006 15:47, William Knop wrote:
- 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.
-
Saulius Krasuckas -
Tim Schmidt -
Troy Rollo -
William Knop