wineboot: Start items in StartUp folder on boot.

[Misha Koshelev]

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

[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.

Vitaliy.

[Misha Koshelev]

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

[John Smith]

I thought wine's goal was "bug for bug" with windows, for good or for ill.

On 2/9/07, Misha Koshelev  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

[Stefan Dösinger]

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.

[David Lichterman]

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  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.

[Jacob Alberty]

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, [e-mail]  wrote:
> On 2/10/07, David Lichterman  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  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, [e-mail]  wrote:
> > On 2/10/07, David Lichterman <[e-mail] > 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.