wineboot: Start items in StartUp folder on boot.
Hi, As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder (Programs) just like Windows. The reason this is necessary, well #1 this is something Windows does that Wine doesn't do, but #2 this is required by the Vector NTI installer (bug #7384), which installs necessary dependencies (MDAC and about 6 other things) by installing one, then placing a link to itself in StartUp, then rebooting. With this patch, it will actually restart correctly, and in fact just running wine installer.exe will actually successfully do the install from start to finish (for the alternative to install this prior to this and a few other patches, see my shell script http://misha680.googlepages.com/InstallVectorNTI10.sh). There is still the lack of JScript support which fails to install some things, but that's about it.y (and freely available to academic researchers) can be installed on Wine and run with quite little problem with a quite complicated install script I made http://misha680.googlepages.com/InstallVectorNTI10.sh). There was one pretty significant bug, but after that I wanted to try to track down and patch other bugs that forced the above script to be required. With the exception of a pretty significant lack of JScript support in wine/MSI which causes installation of quite a few files to fail (and thus still require native jscript.dll and native MSI), this final patch I just sent out makes the install work from start to finish, which is quite a change from before. I posted two patches earlier (a conformance test and a fix) that adds path searching to shell link creation (which the conformance test shows exists in Windows for a file like rundll32.exe that is not found in the current directory), and if anyone has comments about those patches please send them to me. My last patch ensures that this shelllink that the Vector NTI installer creates every time it tries to restart (about six or so times after every Microsoft component it installs that it needs and comes with) will be executed, and in fact is meant to reproduce the Windows behavior of starting items in the StartUp program group on login that occurs in Windows. I am new to the whole IShellFolder thing, though, and I tried to make it as proper as I could. But I certainly feel that I would like to have someone more experience to look at it. Oh, and I just wanted to say a big thanks to Dan Kegel, James Hawkings, Mike McCormack, and others who have helped me so far (not to mention Alexandre Julliard for committing some of my patches). Misha
Misha Koshelev wrote:
Hi,
As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed.
I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Vitaliy.
On Fri, 2007-02-09 at 21:20 -0700, Vitaliy Margolen wrote:
Misha Koshelev wrote:
Hi,
As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed.
I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows.
Vitaliy.
Well that is fair if that is the consensus. I did try the installer on a plain Win98 system and this restart does work for it there. Maybe have some kind of option to optionally do this or is that out of the question too? Thanks for the info. Misha
I thought wine's goal was "bug for bug" with windows, for good or for ill. On 2/9/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote:
On Fri, 2007-02-09 at 21:20 -0700, Vitaliy Margolen wrote:
Misha Koshelev wrote:
Hi,
As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed.
I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows.
Vitaliy.
Well that is fair if that is the consensus. I did try the installer on a plain Win98 system and this restart does work for it there. Maybe have some kind of option to optionally do this or is that out of the question too?
Thanks for the info.
Misha
Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen:
Misha Koshelev wrote:
Hi,
As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder
IMHO this should not be fixed.
I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder.
Stefan Dösinger wrote:
Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen:
Misha Koshelev wrote:
Hi,
As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed.
I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder.
------------------------------------------------------------------------
I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder. It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location? /2cents -Dave
On 2/10/07, David Lichterman <laviddichterman(a)gmail.com> wrote:
Stefan Dösinger wrote:
Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen:
Misha Koshelev wrote:
Hi,
As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed.
I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder.
------------------------------------------------------------------------
I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder.
It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location?
What a gksu? How about prompting the user during startup? e.g., "Start <title> using command line <program + args>? Yes/No ([x] Don't ask again" Don't ask again items could either be stored as hash codes in a configuration file outside the wine filesystem, or else by deleting command/moving to a usual Unixy autostart location. This should be done for all startup programs, whether start menu or registry. It would be the best of both worlds, it works as expected for the user without requiring them to give up control of their system. There could even be a winecfg option whether to prompt the user, silently allow, automatically+loudly deny, or silently deny.
Why not integrate this functionality into wineboot? That way if a user wants to completely deny the start-up folder they can just not add wineboot to the list of programs to be started on login, but if they want that functionality they can simply add wineboot to the list of programs for start up when they login? It would allow similar functionality to windows whilst still keeping it a separate system. On 2/10/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote:
On 2/10/07, David Lichterman <laviddichterman(a)gmail.com> wrote:
Stefan Dösinger wrote:
Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen:
Misha Koshelev wrote:
Hi,
As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed.
I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder.
I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder.
It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location?
What a gksu?
How about prompting the user during startup?
e.g., "Start <title> using command line <program + args>? Yes/No ([x] Don't ask again" Don't ask again items could either be stored as hash codes in a configuration file outside the wine filesystem, or else by deleting command/moving to a usual Unixy autostart location.
This should be done for all startup programs, whether start menu or registry.
It would be the best of both worlds, it works as expected for the user without requiring them to give up control of their system.
There could even be a winecfg option whether to prompt the user, silently allow, automatically+loudly deny, or silently deny.
On 2/10/07, Jacob Alberty <jacob.alberty(a)vetmanage.com> wrote:
Why not integrate this functionality into wineboot? That way if a user wants to completely deny the start-up folder they can just not add wineboot to the list of programs to be started on login, but if they want that functionality they can simply add wineboot to the list of programs for start up when they login? It would allow similar functionality to windows whilst still keeping it a separate system.
I think everyone agrees that wineboot is where this functionality should be, if it's implemented at all? Well, part of my idea was that even if the configuration option is set to "silently deny", any option that was previously accepted with the don't ask again option checked (or Always in case wine has buttons for Never, Not This Time, Run This Time, Always) would still execute, which is rather different from totally disabling wineboot. Then you could presumably run wineboot explicitly or some helper program, in order to manage the entries.
On 2/10/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote:
On 2/10/07, David Lichterman <laviddichterman(a)gmail.com > wrote:
Stefan Dösinger wrote:
Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen:
Misha Koshelev wrote:
Hi,
As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed.
I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder.
I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder.
It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location?
What a gksu?
How about prompting the user during startup?
e.g., "Start <title> using command line <program + args>? Yes/No ([x] Don't ask again" Don't ask again items could either be stored as hash codes in a configuration file outside the wine filesystem, or else by deleting command/moving to a usual Unixy autostart location.
This should be done for all startup programs, whether start menu or registry.
It would be the best of both worlds, it works as expected for the user without requiring them to give up control of their system.
There could even be a winecfg option whether to prompt the user, silently allow, automatically+loudly deny, or silently deny.
participants (7)
-
David Lichterman -
Jacob Alberty -
John Smith -
Misha Koshelev -
richardvoigt＠gmail.com -
Stefan Dösinger -
Vitaliy Margolen