 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The approach I've taken for the beta I'm rolling now is to remove reference
to 'all users' from the dialogs, and simply say 'install to
Microsoft-recommended location' or 'install anywhere' (the latter of which
defaults to program files, with a warning about possibly needing additional
privileges). Both of these are available all the time, even if the user
hasn't elevated.
For standard users, Microsoft will probably (depending on the OS) re-direct
the writes to program files into a compatibility folder within the user's
profile (even though to the user it will appear as if the files are in
program files).
This change should remove much of the confusion that appears to exist
regarding install location.
At some point I will probably provide a separate installer that is
dedicated to all-user and network installs. This seems simpler to me than
trying to cater for all circumstances in the one install script.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/7/2010 5:12 PM, Chris Cason wrote:
>
> At some point I will probably provide a separate installer that is
> dedicated to all-user and network installs. This seems simpler to me than
> trying to cater for all circumstances in the one install script.
>
> -- Chris
Chris, OOC are you using Visual Studio to create the installer or a
third party package, such as InstallShield or Wise?
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/09/2010 01:18, Mike Raiford wrote:
> Chris, OOC are you using Visual Studio to create the installer or a
> third party package, such as InstallShield or Wise?
Currently I'm using IS12.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
