> Is this recommended from MS?  Other programs seem to ask for admin
> rights if you run them as non-admin.

Does this make them right and us wrong? Or are we just ahead of the curve
for wanting to provide a better end-user experience? The fact is most end
users don't care where the software sits, as long as when they click the
launch icon, it starts. UAC prompts are annoying and unnecessary for most
cases. If POV doesn't need admin rights to run, it shouldn't need them to
install, except in the case for an 'all users' installation.

The fact is Microsoft are moving away from the 'central installation
location' model. We have chosen to deal with that rather than fight it as I
don't want to have to re-write the installer in two years time. This is
volunteer work and I simply don't have the time or inclination.

I'm not saying my choice of exact default install location is right or
wrong. I am saying that my choice to install outside of program files - for
our application and in non-all-users mode - is neither incorrect nor
against proper practices.

The fact is Microsoft has left the 'proper' place for such installs to be
rather nebulous. Possibly I might change to the compatibility folder
location for program files, which would make it *look* like it's in program
files, even though it actually isn't ...

FYI if you look at Microsoft's 'Click Once' installation mechanism (which
is an alternative to MSI's for certain types of applications), you'll see
that they don't install into Program Files at all:

  http://msdn.microsoft.com/en-us/library/142dbbz4%28VS.90%29.aspx

Quote:

  The application is added to the user's Start menu and to the Add or
  Remove Programs group in the Control Panel. Unlike other deployment
  technologies, nothing is added to the Program Files folder, the
  registry, or the desktop, and no administrative rights are required for
  installation

This is the way they are pushing the industry, because the old model of
stuffing things into the registry and common file locations has shown, over
the years, that it is a liability. (We still use the registry, but
we aren't dependent on it - it's possible to run POV-Ray for Windows
without any registry entries, using the 'inferred install location' feature).

> Any reason why the default isn't in to program files in this case?

Just because someone is running elevated doesn't mean they want to install
for all users. It's not too hard to click the 'all users' radio button is
it? Sure, I could change the default, but is it such a big deal?

> Just trying to understand why POV feels the need to be different to what
> most people have grown to expect.

LOL, so we should stay the same forever? Expectations change, Microsoft is
driving this change, and as per usual, developers such as myself have to
take the flack from end-users who want to complain about it. It took me
some time to get around to fixing the installer so it worked under vista
*at all* (this was a total re-write using a new tool), so having done it
once, I don't want to do it again.

The fact is the installation model for windows is changing, if you don't
like it then by all means keep using outdated software or just don't use
POV-Ray.

Post a reply to this message

Just a followup for reference in case this issue comes up again: I have
come across an article referencing some of the issues raised in this thread
with respect to Windows Installer 5.0, which has explicit support for
dual-mode installs (at least for windows 7 and higher).

  http://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx

This at least makes it easier for me to cater for both scenarios.

Microsoft has also apparently realized that it was a bit confusing not to
have defined a program files equivalent under the user's profile, so now
there is one: by default, it's C:\Users\<username>\AppData\Local\Programs
(see the above article for reference to this, where they state "When a user
installs the dual-purpose package on Windows 7 or Windows Server 2008 R2
using the per-user context, these components are saved in the Programs
folder of the current user (for example at %LocalAppData%\Programs) and can
be accessed only by that user.")

I think that pretty much answers the 'where to put it' issue for non-admin
installs, as this is now an officially 'blessed' location (and in AppData
to boot). While the above support only applies to Windows 7/Server 2008,
the location itself can be created (if it doesn't already exist) under
Vista by the installer itself.

I suspect it should also put to rest the complaints (I will point out that
this is not by any means the first thread complaining about the install
location) of any who have claimed that AppData is not for executable files
and/or that I eat babies for breakfast because I chose to use it rather
than good ol 'c:\program files'.

(Did I mention I also got roasted by another group of expert users for
moving to c:\program files from c:\povray when Windows 95 was introduced?
Deja vu. Hopefully this won't happen again in another 15 years. No, I'm not
bitter at all. Not in the least. Just jaded :-)

-- Chris

PS FWIW a little research shows that Google got blasted by users for doing
a similar thing with Chrome and Google Talk. So at least I'm not alone.

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> schreef in 
bericht news:4c50e88b@news.povray.org...
> (Did I mention I also got roasted by another group of expert users for
> moving to c:\program files from c:\povray when Windows 95 was introduced?
> Deja vu. Hopefully this won't happen again in another 15 years. No, I'm 
> not
> bitter at all. Not in the least. Just jaded :-)

Keep up the good work, Chris, we are behind you  :-)

Thomas

Post a reply to this message

On 7/28/2010 10:33 PM, Chris Cason wrote:
> Microsoft has also apparently realized that it was a bit confusing not to
> have defined a program files equivalent under the user's profile, so now
> there is one: by default, it's C:\Users\<username>\AppData\Local\Programs
> (see the above article for reference to this, where they state "When a user
> installs the dual-purpose package on Windows 7 or Windows Server 2008 R2
> using the per-user context, these components are saved in the Programs
> folder of the current user (for example at %LocalAppData%\Programs) and can
> be accessed only by that user.")

The next step for MS would seem to be to replace "C:\Program Files" with 
"C:\Users\All Users\AppData\Local\Programs" if this is the case. And I 
still don't think executables and settings should both be located in 
"AppData". Or at least, they should make the distinction between 
executables and settings much more clear in the folder naming scheme. 
Therefore, I would bet MS will change the recommendations yet once 
again, maybe when they release their next OS.



Mike

Post a reply to this message

SharkD <pos### [at] gmailcom> wrote:
> On 7/28/2010 10:33 PM, Chris Cason wrote:
> > Microsoft has also apparently realized that it was a bit confusing not to
> > have defined a program files equivalent under the user's profile, so now
> > there is one: by default, it's C:\Users\<username>\AppData\Local\Programs
> > (see the above article for reference to this, where they state "When a user
> > installs the dual-purpose package on Windows 7 or Windows Server 2008 R2
> > using the per-user context, these components are saved in the Programs
> > folder of the current user (for example at %LocalAppData%\Programs) and can
> > be accessed only by that user.")
>
> The next step for MS would seem to be to replace "C:\Program Files" with
> "C:\Users\All Users\AppData\Local\Programs" if this is the case. And I
> still don't think executables and settings should both be located in
> "AppData". Or at least, they should make the distinction between
> executables and settings much more clear in the folder naming scheme.
> Therefore, I would bet MS will change the recommendations yet once
> again, maybe when they release their next OS.
>
>
>
> Mike
They'll probably set up a junction point at each C:\Users\<username>\AppData to
rename it to something more appropriate in Windows 8, just like they did at
Vista when they reorganized the users' directory tree (My Documents is a
junction point to Documents, for example).

To be honest, I'd rather have them invert the tree slightly there and make it
C:\Users\<username>\Local\(Applications, AppData, etc.) (and likewise for
LocalLow and Roaming) as that makes more sense from an organizational standpoint
- to me, at least.

Post a reply to this message

On 7/27/2010 3:08 AM, Chris Cason wrote:

> POV-Ray is installed into the users profile folder. This is as far as I
> could tell the best solution for a non-privileged user on Vista. And
> insofar as suggesting the install could be missed, that is nonsense. When
> POV is installed via a MSI, the software is registered with the Windows
> Installer DB. This applies no matter where the EXE ends up on the hard disk.
>

I can't recall... does the installer offer the choice between "Install 
for all users" and "Install for just me"?

What the installer is doing is correct for the "Just for the current 
user" case. It does not make software changes to the system as a whole 
and does nothing to affect other accounts. This is correct behavior, and 
allows the program to be used without the need for escalated privileges.

> If the machine admin doesn't want any software installed and hasn't locked
> down installs completely, then he's got more to worry about than POV. We
> use MSI-based installs rather than a setup.exe, meaning that anyone with
> control over group policy can easily restrict exactly what Windows
> installer does or doesn't allow. Programs that don't use windows installer
> can bypass this. Put simply, if a user can put a EXE on the system, they
> can install software, and it's not our problem to deal with this. We
> provide the means for admins to audit installs by using Windows Installer,
> and that's about the most we can do.

We have controls like this where I work, and in my experience that is 
exactly what happens. It doesn't matter how, but an admin will be 
notified as soon as someone adds software. Regardless of where it is added.

-- 
~Mike

Post a reply to this message

On 7/28/2010 5:35 AM, Chris Cason wrote:

>    Run it without elevation and it defaults to the user profile dir.
>    [This makes sense as they can't install to program files.]
>
>    Run it with elevation and they are offered an option to install as one
>    user or for all users. If they choose all users, it installs to
>    \program files.
>    [This make sense since as an elevated install, they are given the option]

Actually, this *may* be an issue. The option should be available. (Of 
course, the "Install for everyone" option should have the shield icon 
and request elevation, if chosen.

IIRC, running an MSI as an admin on Vista was no easy feat. There was no 
"Run as Administrator" button on the context menu for MSI files, which 
would be a major inconvenience. I don't know if Win7 has improved this 
aspect, but the option should be available without requiring elevation 
until that item is selected. I don't know what it would take to build 
the installer that way, though.

-- 
~Mike

Post a reply to this message

Mike Raiford wrote:
> We have controls like this where I work, and in my experience that is 
> exactly what happens. It doesn't matter how, but an admin will be 
> notified as soon as someone adds software. Regardless of where it is added.

It's easy enough to audit all file creations and watch the logs for 
something with .EXE or .COM at the end, I would guess.

-- 
Darren New, San Diego CA, USA (PST)
    Quoth the raven:
        Need S'Mores!

Post a reply to this message

Mike Raiford wrote:

> IIRC, running an MSI as an admin on Vista was no easy feat. There was no 
> "Run as Administrator" button on the context menu for MSI files, which 
> would be a major inconvenience. I don't know if Win7 has improved this 
> aspect

nope, just got a new windows 7 system and had to use msiexec
from a command prompt with administrator privileges.

, but the option should be available without requiring elevation
> until that item is selected. I don't know what it would take to build 
> the installer that way, though.

It's a bit fiddly, any "shielded" button needs to launch a
new elevated process to perform the actual task. So basically
the installer needs to restart itself with elevation and then
terminate the original. This is the most flexible solution as
the user can decide while the installer is running. Alternatively,
an EXE installer would at least offer the context menu option.

Post a reply to this message

Christian Froeschlin wrote:
> It's a bit fiddly, any "shielded" button needs to launch a
> new elevated process to perform the actual task. 

That's part of the security process. All the new MS security stuff (like in 
their new OSes) is like that.  The idea is that if you managed to corrupt 
the one you're running, you *still* haven't corrupted the privileged version.

-- 
Darren New, San Diego CA, USA (PST)
    Quoth the raven:
        Need S'Mores!

Post a reply to this message