autorun perhaps dangerous (Was: Wine release 0.9.53)
On Fri, Jan 11, 2008 at 05:36:04PM +0100, Alexandre Julliard wrote:
This is release 0.9.53 of Wine, a free implementation of Windows on Unix.
What's new in this release: - RunOnce and Run entries now executed on startup.
This will probably give some fallout ;) I wanted to write earlier, but did forget about it over the last days. For my grown Wine installation this now starts: - 2 instances of a Windows Worm - Google Talk (not working) - Skype (crashing) - pccam.exe from some digital camera disk - the annoying Steam.exe auto-update and ask-for-subscription dialog - perhaps more and this even on "make check" :( We probably need some tool to edit Run and RunOnce entries now. Ciao, Marcus
Am Freitag, 11. Januar 2008 17:48:06 schrieb Marcus Meissner:
On Fri, Jan 11, 2008 at 05:36:04PM +0100, Alexandre Julliard wrote:
This is release 0.9.53 of Wine, a free implementation of Windows on Unix.
What's new in this release: - RunOnce and Run entries now executed on startup.
This will probably give some fallout ;)
I wanted to write earlier, but did forget about it over the last days.
For my grown Wine installation this now starts:
- 2 instances of a Windows Worm - Google Talk (not working) - Skype (crashing) - pccam.exe from some digital camera disk - the annoying Steam.exe auto-update and ask-for-subscription dialog - perhaps more Works as it is supposed to then :-)
I agree it is a pain with "make test" though, and some way to easilly edit these keys would be helpful
On Jan 11, 2008 12:06 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
I agree it is a pain with "make test" though, and some way to easilly edit these keys would be helpful
maybe we need a tool like msconfig for managing services or a page on winecfg. -- 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
2008/1/11, Marcus Meissner <meissner(a)suse.de>:
On Fri, Jan 11, 2008 at 05:36:04PM +0100, Alexandre Julliard wrote:
This is release 0.9.53 of Wine, a free implementation of Windows on Unix.
What's new in this release: - RunOnce and Run entries now executed on startup.
This will probably give some fallout ;)
I wanted to write earlier, but did forget about it over the last days.
For my grown Wine installation this now starts:
- 2 instances of a Windows Worm - Google Talk (not working) - Skype (crashing) - pccam.exe from some digital camera disk - the annoying Steam.exe auto-update and ask-for-subscription dialog - perhaps more
and this even on "make check" :(
We probably need some tool to edit Run and RunOnce entries now.
wine regedit Maybe it would be a good idea to have an option to make us of this new feature... greets, Christian
On Jan 11, 2008 10:48 AM, Marcus Meissner <meissner(a)suse.de> wrote:
We probably need some tool to edit Run and RunOnce entries now.
maybe we need a tool like msconfig for managing services or a page on winecfg.
Id say so, a one stop place for anything that has a chance to get executed on startup: * HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run * HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run * HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce * HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce * HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ RunServices * HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ RunServicesOnce * HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ RunOnce\Setup above are listed from http://support.microsoft.com/kb/137367 * HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx * HKEY_USERS\.DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\Run * HKEY_USERS\.DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce * HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit * HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows * autoexec.bat * config.sys * startup folder * system.ini Any other areas that windows uses to launch programs when starting up? Regards, John Klehm
..also, a very good utility to handle the autorun stuff is autoruns.exe from the Sysinternals Suite. Actually, the whole suite is a very good testbed for wine as it contains low level monitoring tools like Diskmon.exe, Filemon.exe, Tcpview.exe, procexp.exe, portmon.exe, Winobj.exe.. many of those fail on module:NtLoadDriver stub but some like process explorer or the autoruns tool work almost perfectly fine. Running the splendid bluescreen screensaver would be totally awesome too, but that needs native ntoskrnl.exe to fetch the bootlogo.. by the way yes, sysinternals has been bought by M$ mid 2006, and of course the first thing they did is introduce a nasty legal pop-up to all of the utils, but having a short look at it we should be fine using it to debug WiNE ;) regards
Until someone comes up with the addition to winecfg to edit the Run and RunOnce keys (and it really seems like that is what we need), we should probably detect if those keys have changed and pop up a dialog on the next wineboot that says: "The Run or RunOnce registry keys have changed, probably because you installed a new application. We're now going to execute them, but be prepared for something to explode and steal your lunch money. You can repair anything broken by running "wine regedit" and editing HKLM\Software\Microsoft\Windows\CurrentVersion\Run" -Brian
On Jan 12, 2008 2:15 PM, Brian Vincent <brian.vincent(a)gmail.com> wrote:
Until someone comes up with the addition to winecfg to edit the Run and RunOnce keys (and it really seems like that is what we need), we should probably detect if those keys have changed and pop up a dialog on the next wineboot that says: "The Run or RunOnce registry keys have changed, probably because you installed a new application. We're now going to execute them, but be prepared for something to explode and steal your lunch money. You can repair anything broken by running "wine regedit" and editing HKLM\Software\Microsoft\Windows\CurrentVersion\Run"
Winecfg is not really the place for it. Windows power users expect to have msconfig....its a shame we can't lift the one from ReactOS because they have a working LGPL replacement. -- 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
Why not? Was it reverse engineered? Or is there some other reason preventing its integration? - Austin On 1/12/08, Steven Edwards <winehacker(a)gmail.com> wrote:
On Jan 12, 2008 2:15 PM, Brian Vincent <brian.vincent(a)gmail.com> wrote:
Until someone comes up with the addition to winecfg to edit the Run and RunOnce keys (and it really seems like that is what we need), we should probably detect if those keys have changed and pop up a dialog on the next wineboot that says: "The Run or RunOnce registry keys have changed, probably because you installed a new application. We're now going to execute them, but be prepared for something to explode and steal your lunch money. You can repair anything broken by running "wine regedit" and editing HKLM\Software\Microsoft\Windows\CurrentVersion\Run"
Winecfg is not really the place for it. Windows power users expect to have msconfig....its a shame we can't lift the one from ReactOS because they have a working LGPL replacement.
-- 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
On Jan 13, 2008 12:54 AM, Austin English <austinenglish(a)gmail.com> wrote:
Why not? Was it reverse engineered? Or is there some other reason preventing its integration?
The general policy is to no longer accept code from ReactOS though the Wine taskmgr and registry editor were developed by ReactOS developers. It should be obvious that its cleanly implemented so I don't know if there is any way Alexandre would make an exception to import it. There is really nothing to be reversed from this tool and Colin's version is under the correct license so I don't see any reason why it should be rejected. Its not like its some low level library without documentation or anything. If we can't merge it due to policy then I think taskmgr and regedit should be remove from Winehq git. http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/msconfig/ -- 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
"Steven Edwards" <winehacker(a)gmail.com> wrote:
Winecfg is not really the place for it. Windows power users expect to have msconfig....its a shame we can't lift the one from ReactOS because they have a working LGPL replacement.
I don't see why winecfg can't have a page similar to what msconfig has. It not hard to add it to winecfg, there is nothing magic in the reactos version. -- Dmitry.
On Jan 13, 2008 4:18 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
I don't see why winecfg can't have a page similar to what msconfig has. It not hard to add it to winecfg, there is nothing magic in the reactos version.
This is true. I am just saying most windows power uses expect msconfig to be there these days. We could have a dummy msconfig thats just a wrapper and invokes winecfg on the correct page. Being as we don't follow the design windows power users expect by having CPL applets and the like, it would make sense to stick it in winecfg with everything else I guess... -- 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
"Steven Edwards" <winehacker(a)gmail.com> wrote:
This is true. I am just saying most windows power uses expect msconfig to be there these days. We could have a dummy msconfig thats just a wrapper and invokes winecfg on the correct page. Being as we don't follow the design windows power users expect by having CPL applets and the like, it would make sense to stick it in winecfg with everything else I guess...
My impression was that Wine follows the requests and demands of Linux (and other supported OSes) users, not the Windows' ones regardless of their powerfulness. -- Dmitry.
On Jan 13, 2008 6:24 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
My impression was that Wine follows the requests and demands of Linux (and other supported OSes) users, not the Windows' ones regardless of their powerfulness.
Well most Windows power users are used to a graphical registry editor where Wine supports a text registry and we all know how much Linux users love flat text file manipulation. Perhaps we should revert the graphical registry editor for this and reasons I mentioned in the prior email.... -- 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
On Sunday January 13 2008 12:52:22 Steven Edwards wrote:
On Jan 13, 2008 6:24 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
My impression was that Wine follows the requests and demands of Linux (and other supported OSes) users, not the Windows' ones regardless of their powerfulness.
Well most Windows power users are used to a graphical registry editor where Wine supports a text registry and we all know how much Linux users love flat text file manipulation. Perhaps we should revert the graphical registry editor for this and reasons I mentioned in the prior email....
I see no reason to revert currently abailable tools without *really good* technical or legal reason. Sorry but this would be simply... not smart, really. I like the ability to edit registry directly with text editor but this doesn't mean that I don't need GUI tool for that. Reasons are simple: with GUI I have tree with registry keys and with plain text I have sequence of registry keys. I think it is obvious why one would prefer tree instead of sequence in some cases and sequence instead of tree in other cases. BTW, msconfig isn't very popular tool. Just compare how many Windows users have used regedit and how many have used msconfig (and how freqently it is used in comparison with regedit). And of course many Linux users simply don't know about it. This means that even if we include msconfig its use will not be as intuitive as winecfg use for purpose of editing startup keys. Therefore winecfg is better for that purpose. In fact, use of winecfg will be obvious for all WINE users - including Windows power users. If we can include msconfig - good, but in my opinion its inclusion doesn't mean that winecfg shouldn't support editing of startup keys. Therefore, its inclusion or rejection isn't important to WINE Project (in other words, this is minor issue). As I said, winecfg is more convenient and intuitive for that purpose. If you disagree with WINE policy related to ReactOS you need to talk to AJ directly (for example, on IRC channel). Multiple requests to exclude existing tools on wine-devel without good reasons will not help to make WINE or its current policy better, really.
On Jan 13, 2008 8:39 AM, L. Rahyen <research(a)science.su> wrote:
If you disagree with WINE policy related to ReactOS you need to talk to AJ directly (for example, on IRC channel). Multiple requests to exclude existing tools on wine-devel without good reasons will not help to make WINE or its current policy better, really.
The policy regarding ReactOS is not going to change and I really don't care at this point. My point in reply to Dmitry's comment was while I agree using winecfg for msconfig functionality is fine I was just using a reductio ad-absurdum to point out that if we are not going to make a wrapper program for msconfig for power windows users that are used to certain windows functionality because we don't care about them and the windows way of doing things, then why should we care about windows power users ablity to graphically edit the registry? In regedits case there would be two fold argument for removing it, 1. Because it was contributed by ReactOS developers and 2. Because we obviously don't care about whats convenient to people coming from a windows background using that logic. -- 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
On Sunday January 13 2008 20:45:49 Steven Edwards wrote:
My point in reply to Dmitry's comment was while I agree using winecfg for msconfig functionality is fine I was just using a reductio ad-absurdum to point out that if we are not going to make a wrapper program for msconfig for power windows users that are used to certain windows functionality because we don't care about them and the windows way of doing things, then why should we care about windows power users ablity to graphically edit the registry?
Because it is important for MOST Linux users who use WINE. Of course some users use regedit rarely, some frequently - but fact is that they are using it. For example, I use it but I know very little about Windows. Most users will expect ability to edit startup keys in winecfg. And rest of users who didn't expect it to be there will learn about it very quickly - as soon as they run winecfg at least once. As I have already said, use of winecfg will be intuitive for both Linux and Windows power users. I simply see no problem here. I'm sure that there will be very little number of users who would use something else instead of winecfg when winecfg will have a tab for configurion startup keys.
Because we obviously don't care about whats convenient to people coming from a windows background using that logic.
"We shouldn't care about Windows power users" != "we shouldn't care about Linux users". Please note that I say nothing here about should we care about Windows (power) users or not. I'm just pointing that your logic isn't correct. I try to explain why. First of all, msconfig and regedit cannot be compared like two utilities of same importance or like two programs intended for same audience. regedit is extremely popular, its use is intuitive for most Linux users, and it cannot be replaced with a tab in winecfg. It even cannot be replaced with external Linux tools like text editor because wineserver will overwrite any changes that was made by an external program (this is true of course only if wineserver was running; you need to shutdown it before using external program for registry editing). msconfig is mostly intended for Window power users, its use isn't intuitive for most Linux users (in fact, it even isn't intuitive for most Windows users too), and it can be replaced with a tab in winecfg (at least, its most important functionality). As you can see, there is a big difference. It is incorrect to ignore importance of regedit for Linux users. Why? Because if msconfig was very important then it (or at least its simplified replacement) can be even written from scratch. This is true for regedit but isn't true for msconfig. In other words, it is unlikely that someone will write it from scratch in near future because of very low demand; but if WINE will lack regedit utility it is very likely that someone will write it from scratch if necessary. That just means regedit is important not only for Windows power users but for most of WINE users (including simple Linux users who are using WINE).
L. Rahyen wrote:
On Sunday January 13 2008 20:45:49 Steven Edwards wrote:
Because we obviously don't care about whats convenient to people coming from a windows background using that logic.
"We shouldn't care about Windows power users" != "we shouldn't care about Linux users". Please note that I say nothing here about should we care about Windows (power) users or not. I'm just pointing that your logic isn't correct. I try to explain why. First of all, msconfig and regedit cannot be compared like two utilities of same importance or like two programs intended for same audience. regedit is extremely popular, its use is intuitive for most Linux users, and it cannot be replaced with a tab in winecfg. It even cannot be replaced with external Linux tools like text editor because wineserver will overwrite any changes that was made by an external program (this is true of course only if wineserver was running; you need to shutdown it before using external program for registry editing). msconfig is mostly intended for Window power users, its use isn't intuitive for most Linux users (in fact, it even isn't intuitive for most Windows users too), and it can be replaced with a tab in winecfg (at least, its most important functionality).
L. Rahyen: I have found that I CANNOT contribute code to this project. However, this does not stop me from contributing my USD .02. Regedit serves a single purpose, editing the registry. msconfig serves the purpose of editing the configuration of Windows and as a Windows 'hacker' I live on this program. Of course, for simplicity's sake this can be a tab in winecfg, but for a Windows user/hacker moving to Linux/Wine adding a symlink to winecfg and the appropriate tab would be acceptable, but overlooking this requirement is not 'a good thing'. And adding the suprise of running Run Aways and Run Once is not nice. A warning in the announcement would be nice and almost necessary for those folks running a combination Windows/Linux box, like I used to. This was to overcome the massive number of Windows 'friends' like Storm. So, I would implore the investigation of adding the necessary parts of msconfig to winecfg and before the actual release of Wine 1.0. BTW, regedit is an absolute necessity to the Wine project, but it is also a very dangerous tool in the wrong hands. Thank you. James McKenzie
On Monday January 14 2008 00:17:53 James McKenzie wrote:
I have found that I CANNOT contribute code to this project. However, this does not stop me from contributing my USD .02.
Regedit serves a single purpose, editing the registry. msconfig serves the purpose of editing the configuration of Windows and as a Windows 'hacker' I live on this program. Of course, for simplicity's sake this can be a tab in winecfg, but for a Windows user/hacker moving to Linux/Wine adding a symlink to winecfg and the appropriate tab would be acceptable, but overlooking this requirement is not 'a good thing'.
I agree that it would be great to add additional tools such as msconfig. If it would be added we can make a tab in winecfg (or button in intuitive place of winecfg) for just running it. This would be intuitive for all users. However as I said if we cannot include it there are "more or less" acceptable alternative way to solve the problem. Personally I prefer inclusion of msconfig and possibility to run it from winecfg (along with ability to run it directly as msconfig).
And adding the suprise of running Run Aways and Run Once is not nice.
Yeah, I remember how a lot of (mostly non-functional or partially functional) programs started automatically not only for me but also for my users (because of my multiuser setup). By itself this is useful feature. But lack of proper configuration tool in clean WINE is the real problem currently...
BTW, regedit is an absolute necessity to the Wine project, but it is also a very dangerous tool in the wrong hands.
This is certainly true.
Marcus Meissner schreef:
On Fri, Jan 11, 2008 at 05:36:04PM +0100, Alexandre Julliard wrote:
This is release 0.9.53 of Wine, a free implementation of Windows on Unix.
What's new in this release: - RunOnce and Run entries now executed on startup.
This will probably give some fallout ;)
I wanted to write earlier, but did forget about it over the last days.
For my grown Wine installation this now starts:
- 2 instances of a Windows Worm - Google Talk (not working) - Skype (crashing) - pccam.exe from some digital camera disk - the annoying Steam.exe auto-update and ask-for-subscription dialog - perhaps more
and this even on "make check" :(
We probably need some tool to edit Run and RunOnce entries now.
Agreed, and be able to disable them entirely, I have a program that crashes during autorun, so my virtual wine desktop wouldn't close even with nothing visible. -Maarten
I've found Mike Lin's Startup Control Panel (http://mlin.net/StartupCPL.shtml) very useful for this on windows. It appears to work on Wine, though I don't seem to have any Run or RunOnce entries so can't be sure. On Jan 11, 2008 11:48 AM, Marcus Meissner <meissner(a)suse.de> wrote:
On Fri, Jan 11, 2008 at 05:36:04PM +0100, Alexandre Julliard wrote:
This is release 0.9.53 of Wine, a free implementation of Windows on Unix.
What's new in this release: - RunOnce and Run entries now executed on startup.
This will probably give some fallout ;)
I wanted to write earlier, but did forget about it over the last days.
For my grown Wine installation this now starts:
- 2 instances of a Windows Worm - Google Talk (not working) - Skype (crashing) - pccam.exe from some digital camera disk - the annoying Steam.exe auto-update and ask-for-subscription dialog - perhaps more
and this even on "make check" :(
We probably need some tool to edit Run and RunOnce entries now.
Ciao, Marcus
-- Vincent Povirk
Marcus Meissner wrote:
On Fri, Jan 11, 2008 at 05:36:04PM +0100, Alexandre Julliard wrote:
This is release 0.9.53 of Wine, a free implementation of Windows on Unix.
What's new in this release: - RunOnce and Run entries now executed on startup.
This will probably give some fallout ;)
I wanted to write earlier, but did forget about it over the last days.
For my grown Wine installation this now starts:
- 2 instances of a Windows Worm - Google Talk (not working) - Skype (crashing) - pccam.exe from some digital camera disk - the annoying Steam.exe auto-update and ask-for-subscription dialog - perhaps more
and this even on "make check" :(
We probably need some tool to edit Run and RunOnce entries now.
Ciao, Marcus
We might want to add an option for only executing these on wineboot. Hell, we might want to make this the default unless the user has a new Wine installation made with wineprefixcreate. As it is, this change might break things. Thanks, Scott Ritchie
Scott Ritchie <scott(a)open-vote.org> writes:
We might want to add an option for only executing these on wineboot. Hell, we might want to make this the default unless the user has a new Wine installation made with wineprefixcreate.
As it is, this change might break things.
Any change might break things, that has never stopped us before ;-) I agree we need a way to configure the Run entries to be able to remove worms and other nuisances, but if running a legitimate app causes trouble we want to fix it, not just force users to disable it; and the way to find out about it is by running these entries and seeing what happens. Still, we don't need to debug it all at once, so I've disabled the Run entries for now. This way we can first concentrate on fixing trouble caused by services and RunOnce entries; but once this is done we definitely want to enable them again. -- Alexandre Julliard julliard(a)winehq.org
On 1/11/08, Marcus Meissner <meissner(a)suse.de> wrote:
On Fri, Jan 11, 2008 at 05:36:04PM +0100, Alexandre Julliard wrote:
This is release 0.9.53 of Wine, a free implementation of Windows on Unix.
What's new in this release: - RunOnce and Run entries now executed on startup.
This will probably give some fallout ;)
I wanted to write earlier, but did forget about it over the last days.
For my grown Wine installation this now starts:
- 2 instances of a Windows Worm - Google Talk (not working) - Skype (crashing) - pccam.exe from some digital camera disk - the annoying Steam.exe auto-update and ask-for-subscription dialog - perhaps more
and this even on "make check" :(
We probably need some tool to edit Run and RunOnce entries now.
And a flag to turn off this behaviour. So far I've never had a setup where I'd want the Run/RunOnce entries to execute. -- Peter Bortas
"Peter Bortas" <bortas(a)gmail.com> wrote:
And a flag to turn off this behaviour. So far I've never had a setup where I'd want the Run/RunOnce entries to execute.
For instance Microsoft Office finishes its setup process when being run from the RunOnce key after reboot. -- Dmitry.
On 1/13/08, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
"Peter Bortas" <bortas(a)gmail.com> wrote:
And a flag to turn off this behaviour. So far I've never had a setup where I'd want the Run/RunOnce entries to execute.
For instance Microsoft Office finishes its setup process when being run from the RunOnce key after reboot.
There are quite a few installers that use RunOnce to get around file locking, but I still haven't had to use one fortunately. As I said, as long as I can disable it. RunOnce wouldn't even have to be disabled, I'd be happy with a "RunOnce wants to execute 'foo.exe blipp blopp', 'No, and clear it from registry', 'Sure' ". -- Peter Bortas
participants (16)
-
Alexandre Julliard -
Austin English -
Brian Vincent -
Christian Gmeiner -
Dmitry Timoshkov -
James McKenzie -
John Klehm -
L. Rahyen -
Maarten Lankhorst -
Marcel Partap -
Marcus Meissner -
Peter Bortas -
Scott Ritchie -
Stefan Dösinger -
Steven Edwards -
Vincent Povirk