 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all,
I think there is still a lot of work to do for the setup designers. First of
all, %APPDATA% is NOT the recommended location for binary files. All application
files that are installed by the setup and are meant to remain unchanged over the
lifetime of the installation should go to a location below %ProgramFiles% by
default. %APPDATA% is meant for files that are created or modified by user
actions but do not qualify as "documents". Configuration files are a good
example of this.
Second, although not explicitly recommended it is a nice gesture to allow the
user to specify where to place the binaries and program menu entries.
Lastly, I'd like to suggest to investigate on the use of "upgrade codes" and
"product codes". Hint: Don't waste time on the "minor upgrade" stuff. These are
awkward and tedious to maintain. Full installation packages are always "major
upgrades"
Some more information about the creation of Windows installation packages can be
found here:
http://www.tramontana.co.hu/wix/
http://wix.sourceforge.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
gerdb42 <nomail@nomail> wrote:
> I think there is still a lot of work to do for the setup designers. First of
> all, %APPDATA% is NOT the recommended location for binary files. All application
> files that are installed by the setup and are meant to remain unchanged over the
> lifetime of the installation should go to a location below %ProgramFiles% by
> default. %APPDATA% is meant for files that are created or modified by user
> actions but do not qualify as "documents". Configuration files are a good
> example of this.
It would be nice to see some official documentation from Microsoft itself
about how program installers should be designed and implemented, which paths
should be used and so on, in such way that it will work properly and according
to Microsoft's recommendations in all XP, Vista and Windows7, when installing
either for a single user or for all users. Then it would be easier to refer
to some concrete documentation on how it should be done.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18.07.10 10:33, gerdb42 wrote:
> Hi all,
>
> I think there is still a lot of work to do for the setup designers. First of
Good, then volunteer to do the work ;-)
> all, %APPDATA% is NOT the recommended location for binary files. All application
> files that are installed by the setup and are meant to remain unchanged over the
> lifetime of the installation should go to a location below %ProgramFiles% by
> default. %APPDATA% is meant for files that are created or modified by user
> actions but do not qualify as "documents". Configuration files are a good
> example of this.
What is the issue you are talking about and how did you determine that
something is wrong?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> wrote:
> Good, then volunteer to do the work ;-)
"I KNEW he'd say that" :-). Hum, I'll see if I can find some time... Is the
current directory layout of an installed version a starting point to pull the
to-be-installed files from?
> What is the issue you are talking about and how did you determine that
> something is wrong?
Well, first I was disappointed by the fact that I was not allowed to choose the
target location of the install (I usually choose something different from
"C:\Program files"). I thought it'd go to somewhere below %ProgramFiles% but
was even more bewildered to find the binaries below %APPDATA%, a user-specific
location. I've done a few setups myself and even though I haven't found the
ultimate "Installer Bible" yet, I found it reasonable to put the binaries to
%ProgramFiles%, which is write-protected from the ordinary user (even more under
Vista and later) but readable to all. If the application is smart enough to pull
some (installed) default data if it doesn't find user stuff there's an easy time
for all.
Just have a look at the way Firefox and Thunderbird handle this: all binaries
and the like are located below %ProgramFiles% and are shared among users but
read-only, and user-profile data is located below %APPDATA%.
Regards
Gerd
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
gerdb42 wrote:
> was even more bewildered to find the binaries below %APPDATA%,
Wasn't the intent to allow a user without admin privileges to install the
program for his private use?
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It would be nice to see some official documentation from Microsoft itself
> about how program installers should be designed and implemented,
It will all be documented and tested in detail as part of the Windows 7 Logo
Program.
The PDF downloadable from this page gives an overview of what is
required/tested for an application to pass:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=27028822-b172-4cec-91a3-26b610a4da79
To quote from the installation section:
"Applications should be installed to the Program Files folder by default.
User data or application data must never be stored in this location because
of the security permissions configured for this folder"
"All application data that must be shared among users on the computer should
be stored within ProgramData"
"All application data exclusive to a specific user and not to be shared with
other users of the computer must be stored in Users\<username>\AppData"
"Never write directly to the "Windows" directory and or subdirectories. Use
the correct methods for installing files, such as fonts or drivers"
not during the installation. This is because there is no correct user
location to store data at time of installation. Attempts by an application
to modify default association behaviors at a machine level after
installation will be unsuccessful. Instead, defaults must be claimed on a
per-user level, which prevents multiple users from overwriting each other's
defaults."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/22/2010 7:07 PM, Darren New wrote:
> gerdb42 wrote:
>> was even more bewildered to find the binaries below %APPDATA%,
>
> Wasn't the intent to allow a user without admin privileges to install
> the program for his private use?
>
Do we really need to allow students to bypass the security restrictions
imposed by the school administrators? If we really want POV-Ray to
become a "portable" app, aren't there better ways?
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/07/2010 6:05 AM, SharkD wrote:
>
> Do we really need to allow students to bypass the security restrictions
> imposed by the school administrators?
Yes.
Or maybe it is workers who want to Pov in their lunch hour.
--
Best Regards,
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Do we really need to allow students to bypass the security restrictions
>> imposed by the school administrators?
>
> Yes.
>
> Or maybe it is workers who want to Pov in their lunch hour.
Sorry, but that's absolute rubbish. There is a system in place to restrict
the installation of programs for many valid reasons, it's not up to software
writers to find devious and bizarre ways to bypass it (eg by installing into
My Documents!). One obvious example is software licensing, if an
organisation needs to track the licenses of all installed software for
audits then POV is going to slip through the net and cause problems.
Another issue is when a user gets concerned when POV installs without asking
for Admin rights, they are not expecting that.
There might even be a legal issue somewhere with the POV license, if the
machine administrator has not given permission for it to be installed,
IANAL.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/07/2010 17:51, scott wrote:
> Sorry, but that's absolute rubbish. There is a system in place to restrict
> the installation of programs for many valid reasons, it's not up to software
> writers to find devious and bizarre ways to bypass it (eg by installing into
I really hope you're not implying that this is what we have done.
> My Documents!). One obvious example is software licensing, if an
> organisation needs to track the licenses of all installed software for
> audits then POV is going to slip through the net and cause problems.
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.
> Another issue is when a user gets concerned when POV installs without asking
> for Admin rights, they are not expecting that.
I see many programs that install without admin rights. In fact, the past
requirement for many programs that actually didn't *need* admin rights to
require them just to be installed is one major factor in the push by
Microsoft to move away from this requirement. They are quite clear in that
if a program doesn't need admin rights to run, it shouldn't need it to be
installed. It's up to the system admin to set policies about install, not
relying on admin or lack thereof.
> There might even be a legal issue somewhere with the POV license, if the
> machine administrator has not given permission for it to be installed,
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.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
