Why is POVRay for Windows 3.7 now being installed into C:\Documents and 
Settings\Username\Application Data\POV-Ray\v3.7\ ?

As I regularly build very large datasets with POV, I have always 
installed my POVRay into a secondary harddrive (D:). Now it appears with 
the current Beta installers I get no control over where it is installed. 
I now have two competing POV directory structures!

Is this a temporary situation for the Betas or is it the future scheme 
for 3.7... if so why?

Rarius

Post a reply to this message

Attachments:
Download 'iso-8859-1' (2 KB)

"Rarius" <rar### [at] rariuscouk> wrote:
> Why is POVRay for Windows 3.7 now being installed into C:\Documents and
> Settings\Username\Application Data\POV-Ray\v3.7\ ?
>
> As I regularly build very large datasets with POV, I have always
> installed my POVRay into a secondary harddrive (D:). Now it appears with
> the current Beta installers I get no control over where it is installed.

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

Post a reply to this message

nemesis wrote:
> "Rarius" <rar### [at] rariuscouk> wrote:
>> Why is POVRay for Windows 3.7 now being installed into C:\Documents and
>> Settings\Username\Application Data\POV-Ray\v3.7\ ?
>>
>> As I regularly build very large datasets with POV, I have always
>> installed my POVRay into a secondary harddrive (D:). Now it appears with
>> the current Beta installers I get no control over where it is installed.
> 
> Can't you just move it elsewhere after installed?  This is why I like zip
> packages best rather than installers...
> 
Actually, that isn't quite the point. The problem is, this behavior is 
annoying as hell. It obfuscates, for the average person, and I would 
argue, at least initially, for me too, where the hell the files are. 
And, if you are a dumb fuck like me, you assumed that XP worked like 98, 
and your "documents" and "programs" would all end up where you told the 
OS to put them, so didn't bother with a huge partition for the OS. I for 
one simply don't have the space on C: for an endless number of idiot 
applications stuffing things in those locations (and at the moment, its 
just not practical for me to try to fix it, not the least because I have 
drives running from C to I on the machine, and trying to mess with 
partitions, even if I could find an old copy of partition magic that 
could help me fix it, could, do to one of those partitions needing to 
go, seriously screw up a lot of installations.

Windows behavior in this is just bone headed imho, and I can't 
comprehend, given this behavior, how they ever managed to get it to run, 
at all, on one of those Asus Eee PCs. Its not like those have hundreds 
of gigs of space sitting around for every application in the known 
universe to dump its junk into the same partition as the OS. lol

Yeah, with respect, I much prefer to have control over where things put 
themselves, instead of being "told" by Windows, yet again, "You can have 
anything you want, just so long as its what we decided you want!"


-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

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.

If the local data is going there, like .ini files, that's where it belongs.

If the user data is going there, it should be going under "My documents" in 
XP, or wherever you tell it to install.

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

> If the local data is going there, like .ini files, that's where it
> belongs.

> If the user data is going there, it should be going under "My documents"
> in XP, or wherever you tell it to install.

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

NB this new behaviour is more or less forced on me by Vista, since when
installing for the current user only (the default unless you want to get
UAC prompts), it is required to install the entire thing into a place the
user has permission to write to. Basically the binaries and the user files
are now split and end up in two locations; I use one of the pre-defined
variables set by Windows Installer for the path of the binaries. It so
happens that the above is what it resolves to on XP.

[Yes it's a pain in the ass but unless I spend the time supporting both
pre-Vista and post-Vista install schemes (= less time to work on other
stuff) there's not a lot I can do about it.]

-- Chris

Post a reply to this message

Rarius wrote:
> Why is POVRay for Windows 3.7 now being installed into C:\Documents and
> Settings\Username\Application Data\POV-Ray\v3.7\ ?
>  
> As I regularly build very large datasets with POV, I have always
> installed my POVRay into a secondary harddrive (D:). Now it appears with
> the current Beta installers I get no control over where it is installed.
> I now have two competing POV directory structures!
>  
> Is this a temporary situation for the Betas or is it the future scheme
> for 3.7... if so why?

Reading the release notes usually answers such questions.

-- Chris

Post a reply to this message

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

"nemesis" <nam### [at] gmailcom> wrote:
> 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.

Average-end-user ease of use.

The average end user has no reason for messing around with the registry in the
first place - or with any .ini files, for that matter.

You're by no means an average end user.

Post a reply to this message

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

Yes, the main suggestion was just to adapt the text to make it
clearer (and preferably change the default setting), because it
is not so intuitive that the install location will be hard-coded
to a different place when you don't say "install for all users".

> To properly install a 64-bit app requires a 64-bit installer

In what way? I recently used NSIS at work to build a rather
huge installer including support for installation of 64-bit
applications and libraries. This works perfectly fine even if
the installer runs as a 32-bit process. There are only few
things to consider, such as using the appropriate version
of $PROGRAMFILES for your desired result, and the correct
root key for making changes to the 64-bit branch of the
registry. There is not even a need to make separate
installers for 32 and 64 bit, if you can live with
a bit of overhead for packaging both binaries.

Hey, even Microsoft's own Visual Studio 2005/8 used to build
the 64-bit applications in the first place is only available
as a 32-bit binary  ;)

Post a reply to this message

Christian Froeschlin wrote:
> In what way? I recently used NSIS at work to build a rather
> huge installer including support for installation of 64-bit
> applications and libraries. This works perfectly fine even if
> the installer runs as a 32-bit process. There are only few
> things to consider, such as using the appropriate version
> of $PROGRAMFILES for your desired result, and the correct
> root key for making changes to the 64-bit branch of the
> registry. There is not even a need to make separate
> installers for 32 and 64 bit, if you can live with
> a bit of overhead for packaging both binaries.

This is a common question, and the fact that it *appears* you can install
programs on Win64 with a 32-bit executable has been an impediment in
getting software engineers to understand the issue. Perhaps they have
updated NSIS to be a 64-bit program now, but certainly last time I looked
into it, it was only 32-bit, and they had no intention of changing.

A 32-bit installer cannot (easily) *properly* install 64-bit programs in
Win64. It cannot, for example, put anything into "Program Files", any
accesses to this are redirected by the OS to "Program Files (x86)".
Here's a summary:

  http://developer.amd.com/pages/316200464.aspx

While there are work-arounds for many of these issues (e.g. disabling the
WOW64 file redirection is possible via an API call), I'd rather go with the
flow than fight the system.

NB I'd like to make it clear that I am not saying that a 64-bit user-mode
program installed by a 32-bit installer won't work. It will. I'm saying
that unless you make special effort, it won't be installed in the standard
location for 64-bit binaries, and there may be other issues that turn up
that are related to the WOW64 layer being applied to the system view of the
installer program but not to the installed program. It really comes back to
what the installed program is designed to expect.

-- Chris

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.

Then you move it to another directory and it doesn't work anymore because of
hardcoded-at-compile-time paths to, for example, config files. Try it with
POV-Ray! The default Library_Path is set that way.

Post a reply to this message

clipka wrote:
> 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.

http://graphjam.wordpress.com/files/2008/12/song-chart-memes-os.gif

Post a reply to this message

Darren New wrote:
> 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.

It's not documents. It's application data.

Post a reply to this message

Chris Cason wrote:
> While there are work-arounds for many of these issues (e.g. disabling the
> WOW64 file redirection is possible via an API call), I'd rather go with
> the flow than fight the system.

Which would involve sticking to MSI, no matter how that MSI is generated.
Which I think is a good thing.

After so many years (of dealing with 16-bit installshield crap to install
32-bit programs) Microsoft finally added an installer system to the
operating system. Let's use it...

Post a reply to this message

Nicolas Alvarez wrote:
> It's not documents. It's application data.

Well, it's application code, if it's a .exe file. Application data is more 
the sort of stuff you'd put in a .dotfile or under /etc in Linux. Thumbnails 
of your albums in your photo album software, caches of web pages, etc.

But yeah, there's no good place to put per-user executables under any 
version of Windows, methinks.

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

> This is a common question, and the fact that it *appears* you can install
> programs on Win64 with a 32-bit executable has been an impediment in
> getting software engineers to understand the issue. Perhaps they have
> updated NSIS to be a 64-bit program now, but certainly last time I looked
> into it, it was only 32-bit, and they had no intention of changing.

While they haven't made it a 64-bit program, they added full
support for installing 64-bit applications. It looks like this
happened around April 2007 / release 2.26, so it might not have
been in the version you tested. For example, the variables
$PROGRAMFILES32 and $PROGRAMFILES64 can be used to select
the desired target directory explicitely. I don't know if
this means they disable some redirection internally.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> 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.
>
> Then you move it to another directory and it doesn't work anymore because of
> hardcoded-at-compile-time paths to, for example, config files. Try it with
> POV-Ray! The default Library_Path is set that way.

I don't know what you're talking about.  I did this to a PostgreSQL install I
had at some floppy.  PostgreSQL also has configurable command-line switches for
telling root and config dir...

I've also had lots of fun in the past by directly exchanging some libs for
others at command-line call time with ldd, /lib/ld-linux (or something like
that) and $LD_LIBRARY_PATH.  oh, the feeling of power... :D

Post a reply to this message