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