"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