nemesis wrote:
> Can't you just move it elsewhere after installed?  This is why I like zip
> packages best rather than installers...

If you could, there would be no need for an installer! There's surely lots
of registry settings.

Post a reply to this message

Darren New wrote:
> Rarius wrote:
>> Why is POVRay for Windows 3.7 now being installed into C:\Documents and
>> Settings\Username\Application Data\POV-Ray\v3.7\ ?
> 
> Is the *code* going there?  That's extremely wrong.

That's Vista's equivalent to the way you can install programs anywhere in
$HOME if you don't have root.

Post a reply to this message

Chris Cason wrote:
> Darren New wrote:
>> Rarius wrote:
>>> Why is POVRay for Windows 3.7 now being installed into C:\Documents
>>> and Settings\Username\Application Data\POV-Ray\v3.7\ ?
>> Is the *code* going there?  That's extremely wrong.
> 
> Not wrong. Just different (see below).

Well, OK. If it installs there for just "one user", I suppose there's not a 
whole lot of good places. I didn't realize that's what you meant.

Installing things outside of "Program Files" in the general case breaks a 
whole bunch of stuff, such as System Restore, all kinds of general backup 
scripts, and etc. It would be as "extremely wrong" as storing the per-user 
ini-config files in the /bin directory on Unix. :-)

Installing the whole executable under "Application Data" could, I suppose, 
cause trouble with people who have (for example) corporate networks where 
that stuff gets backed up on a regular basis or roamed or etc.

Personally, I would have put the single-person install under the "my 
documents" area rather than someplace "hidden", but it's certainly not 
something that Windows makes an obvious place for, yes.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Chris Cason wrote:

> Choose 'install for all users'. Then it will allow you to choose an install
> location.

Maybe only the text is misleading, because installing just for
one user usually means that shortcuts and ini files and the such
go to the users app data and not "All Users" app data. Installing
the binaries into the user's app data is rather exceptional and
could be marked more clearly, such as

o Standard installation (requires administrator privileges)
o Private installation  (places program under user files)

Even so, I think the default should be "Standard" and require
explicit action on the part of the user to change. When ignoring
the warning about administrator privileges, UAC popups should
not come as a big surprise.

Depending on the effort it would require using your tool,
the following two modifications might be helpful:

1. If Windows version is XP or lower, skip the query and
    proceed with standard installation.

2. When doing the query, set the default selection based
    on the availability of administrator privileges.

What tool are you using to build the installer? You mentioned
Windows Installer, but I thought that is just an installer platform
nobody writes for manually. Urk ;) You may wish to have a look at
http://www.advancedinstaller.com for targetting MSI, or NSIS to
avoid MSI altogether.

BTW, note that applications can have a manifest for Vista
which specifies that starting them requires administrator
privileges (common for installers).

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> nemesis wrote:
> > Can't you just move it elsewhere after installed?  This is why I like zip
> > packages best rather than installers...
>
> If you could, there would be no need for an installer! There's surely lots
> of registry settings.

registry... meh! XP

In Linux you can locally install a whole database server under an unprivileged
user's directory and work just fine for development purposes.  The power of
ambient variables and simple text file configuration settings...

Sometimes abstracting away too many details from the user is a bad idea... but
this is not a fault of povray, it's a Windows issue.

Post a reply to this message

nemesis wrote:
> In Linux you can locally install a whole database server under an unprivileged
> user's directory and work just fine for development purposes. 

You can do that in Windows, too, if you don't write to registry settings 
that don't belong to the user. There's just no good default place to store 
per-user binaries.  (At least Vista doesn't make it hard to find the "home" 
directory like XP did.)

> The power of
> ambient variables and simple text file configuration settings...

Windows has both of those. :-) The registry is just a more general solution.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> Windows has both of those. :-)

Of course.  But registry simply kills it in the name of ease for users, at the
expense of making it difficult and annoying to "fine-tune" your system.

> The registry is just a more general solution.

Is it really worth the pain?  At work we use Delphi and now and then when we
have to install or update plugins it's always a terrible annoyance involving
manual and stupid registry editing.  The GUI is supposed to hide details away
and make the structure stand out of anything but in the end it just comes in
the way.  Apparently, you can't copy registry keys around with ease or remove
them at will without first.  It's a painful step-by-step procedure.  To call
that "ease of use" is a joke.

Ease of use is to simply go /searchthis, edit it in whatever way you like, copy
it around as many times you want and delete it with a simple dd.  Nothing like
a plain list of key=value strings...

Post a reply to this message

Christian Froeschlin wrote:
> Maybe only the text is misleading, because installing just for
> one user usually means that shortcuts and ini files and the such
> go to the users app data and not "All Users" app data. Installing
> the binaries into the user's app data is rather exceptional and
> could be marked more clearly, such as

IIRC this issue was discussed at some length in a vista thread some time
back; the locations I am using are I believe the most appropriate ones for
Vista and are backwards-compatible with XP and W2K.

> What tool are you using to build the installer? You mentioned

Installshield.

> Windows Installer, but I thought that is just an installer platform
> nobody writes for manually. Urk ;) You may wish to have a look at
> http://www.advancedinstaller.com for targetting MSI, or NSIS to
> avoid MSI altogether.

I wanted to use NSIS ever since we brought out the 64-bit windows version
(as our old installer didn't work for it) but it is useless for our
purposes. To properly install a 64-bit app requires a 64-bit installer; the
NSIS authors are apparently either ignorant of this or don't care since
numerous requests for a 64-bit version got a "32-bit installers work on
win64 so we don't have to", despite their being told it wasn't sufficient.
I even spent some time trying to get a 64-bit build of it myself but gave
up (far too many issues).

I was reluctant to use Installshield but having built a MSI more or less by
hand once (the original Windows 64-bit installer) I had no intention of
repeating the process.

In any event, yes, I could put in an exception for XP, but I would need to
carefully evaluate what impact it may have on other code.

-- Chris

Post a reply to this message

nemesis wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> nemesis wrote:
>> Windows has both of those. :-)
> 
> Of course.  But registry simply kills it in the name of ease for users, at the
> expense of making it difficult and annoying to "fine-tune" your system.

I'm not sure what that sentence means.   If you mean the registry is harder 
to edit, I'd have to disagree. YMMV.

>> The registry is just a more general solution.
> Is it really worth the pain?  

Yes. When you start writing programs that need to (for example) set 
environment variables for every user in a particular list, or to modify the 
configuration of something already there, you realize that having a standard 
way of storing configuration is a benefit.

Compare code to (say) list all configured document roots in Apache with all 
configured document roots in IIS.  Compare code that installs a new web-app 
to an Apache configuration to an IIS configuration, without disturbing 
what's already set up. Include the effort required to write a parser for 
Apache configuration. Now include the effort to write the parser for MySql 
configuration, PHP configuration, and half a dozen other configurations. 
Include the code to *find* the appropriate configuration files, without 
assuming they're necessarily in the default places.

Compare code to (say) set the POVRAY_BETA environment variable to a new 
value at the next login for everyone in the Administrators group on the 
entire domain of Windows machines compared to setting it for everyone in the 
wheel group for an entire company in a Linux-based company.

Write code to find all the machines within your domain with the old version 
of a particular COM component installed, and replace it with the new 
version.  (That's why it's called the "registry" after all.) Now do the same 
for your favorite X-Windows widget you wrote and that you compiled from your 
own sources.

It's not always worth the "pain" as you say, but when you're writing 
professional-grade software, it makes things a lot easier to manage if all 
your configuration information is in a standard format. Substituting "some 
text file somewhere under /etc, or maybe /sys, or maybe /proc" doesn't 
really compare.

> At work we use Delphi and now and then when we
> have to install or update plugins it's always a terrible annoyance involving
> manual and stupid registry editing.

Well, that's stupid software. There are ways of avoiding that, but if one 
doesn't know what they are, one's software probably won't do things right.

> Ease of use is to simply go /searchthis, edit it in whatever way you like, copy
> it around as many times you want and delete it with a simple dd.  Nothing like
> a plain list of key=value strings...

Well, yeah, if all your configuration is in .INI files, that might make 
sense. (I never used dd to delete files, at least not selectively. ;-) If 
you have complex structured configuration, then you need a more complex 
interface to the registry, which is usually easy-to-trivial to implement in 
the event that your software is broken.

Follow-ups yet again redirected. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> In Linux you can locally install a whole database server under an unprivileged
> user's directory and work just fine for development purposes.  The power of
> ambient variables and simple text file configuration settings...
>
> Sometimes abstracting away too many details from the user is a bad idea... but
> this is not a fault of povray, it's a Windows issue.

I guess it's the old question of whether you want a system for standard office
or home use, or want to do something special with it.

I think there still is no one-size-fits-all OS. Linux is trying to go there, but
at the heart of it, "everyday use" is just one more "special thing" you can do
with it, which keeps showing here and there.

(Well, just my 0.02$, with no intention to start any fuss over it.)

Post a reply to this message