 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that the install should ask you where you want the pov ray files
to be installed to.
Personally I would prefer the files to be in program files instead of my
documents.
Is it possible at the moment to move the files somewhere else out of my
documents?
If I move the folder, povray complains about it and I can't find any
options, so is there a way to point povray to the new location?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>I think that the install should ask you where you want the pov ray files
> to be installed to.
> Personally I would prefer the files to be in program files instead of my
> documents.
>
> Is it possible at the moment to move the files somewhere else out of my
> documents?
> If I move the folder, povray complains about it and I can't find any
> options, so is there a way to point povray to the new location?
In Vista...
open a cmd prompt as administrator
(windows key, type cmd in search box, cntrl-shift-enter)
run the pov installer from the command line
select install for all users... that should let you select the
location for the program files.
This install process is sort of clumsy, if you do a single
user install with administrator privledges then POV will
end up in program files, but if it doesn't have privledges
it'll end up in a hidden roaming profile because of UAC.
Either way, the editable portion of the files ends up in
documents.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I hope the POVRay team will create a standard installation process to eliminate
multi-user or privilege related problems.
In my opinion, the installation should be :
- Programs (pvengine.exe, manuals...) and non-editable files => Program files
- Shared files (includes, objects...) => Accessible for all users
- Personal files (personal configuration for example) => Current user
The directories should be configurable in a main configuration file.
Applications and data should be separated, Windows provides this.
A portable version will be a great thing for more experienced users who want to
create their own installation. For example, put the shared files in a network
drive.
The current installation process totally breaks non official versions (I have
managed to use MegaPOV on Vista but I had to copy and duplicate files to make it
run like before).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23.01.10 14:51, Rocco wrote:
> I hope the POVRay team will create a standard installation process to eliminate
> multi-user or privilege related problems.
>
> In my opinion, the installation should be :
>
> - Programs (pvengine.exe, manuals...) and non-editable files => Program files
> - Shared files (includes, objects...) => Accessible for all users
> - Personal files (personal configuration for example) => Current user
>
> The directories should be configurable in a main configuration file.
>
> Applications and data should be separated, Windows provides this.
You realize that under Vista the issue is not that POV-Ray does not want to
install in program files, but as discussed numerous times before, is not
allowed to install there by Vista itself unless *you*, the user, allow it to
do so. If you prohibit POV-Ray to access the program files folder, you can
hardly be surprised that it does not install where you prohibited it from
installing at in the first place!
Please read the old messages in this group. The problems Vista creates for
non-administrator installs have been discussed numerous times before. There
is really no need to start over discussing the benefits and drawbacks of
Vista rights management! They are for M$ to fix, and nothing POV-Ray can do
anything about.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> wrote:
> You realize that under Vista the issue is not that POV-Ray does not want to
> install in program files, but as discussed numerous times before, is not
> allowed to install there by Vista itself unless *you*, the user, allow it to
> do so.
What do other programs do? I don't remember seeing the same complaint in
relation to other programs (ie. that the program installs itself into the
My Documents folder by default).
> Please read the old messages in this group. The problems Vista creates for
> non-administrator installs have been discussed numerous times before. There
> is really no need to start over discussing the benefits and drawbacks of
> Vista rights management! They are for M$ to fix, and nothing POV-Ray can do
> anything about.
There is something POV-Ray can do: Ask the user what to do. ("Because of
<reason xyz> POV-Ray will be installed in <the My Documents folder>.
Yes/No/Cancel.")
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 23 Jan 2010 19:19:03 +0100, Warp <war### [at] tagpovrayorg> wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> You realize that under Vista the issue is not that POV-Ray does not
>> want to
>> install in program files, but as discussed numerous times before, is not
>> allowed to install there by Vista itself unless *you*, the user, allow
>> it to
>> do so.
>
> What do other programs do? I don't remember seeing the same complaint
> in relation to other programs (ie. that the program installs itself into
> the My Documents folder by default).
Many installers are properly setup to request privilege escalation if
needed. In some cases, Windows itself will deduce that it is needed and
automatically prompt for it.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23.01.10 19:19, Warp wrote:
>> You realize that under Vista the issue is not that POV-Ray does not want to
>> install in program files, but as discussed numerous times before, is not
>> allowed to install there by Vista itself unless *you*, the user, allow it to
>> do so.
>
> What do other programs do? I don't remember seeing the same complaint in
> relation to other programs (ie. that the program installs itself into the
> My Documents folder by default).
It depends. Some installers just don't work. What does work though,
amazingly, is that if one uses an older Visual Studio (2003) to build a M$
Installer is that it magically works without too many problems. The same is
not true if using VS 2008 to build the same installer (out of a converted
project file).
>> Please read the old messages in this group. The problems Vista creates for
>> non-administrator installs have been discussed numerous times before. There
>> is really no need to start over discussing the benefits and drawbacks of
>> Vista rights management! They are for M$ to fix, and nothing POV-Ray can do
>> anything about.
>
> There is something POV-Ray can do: Ask the user what to do. ("Because of
> <reason xyz> POV-Ray will be installed in<the My Documents folder>.
> Yes/No/Cancel.")
No, because POV-Ray is not the Windows installer!
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23.01.10 19:25, Fredrik Eriksson wrote:
> In some cases, Windows itself will deduce that it is needed and
> automatically prompt for it.
Indeed, this feature seems to exist if the installer is built with an older
version of Visual Studio, for example. I guess the assumption M$ makes is
that if the system detects an older installer it cannot know about Vista's
odd manual privilege requirements and does things automatically.
I wonder if all these issues have been resolved in Windos 7...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 23 Jan 2010 19:44:15 +0100, Thorsten Froehlich <tho### [at] trfde>
wrote:
> On 23.01.10 19:25, Fredrik Eriksson wrote:
>> In some cases, Windows itself will deduce that it is needed and
>> automatically prompt for it.
>
> Indeed, this feature seems to exist if the installer is built with an
> older version of Visual Studio, for example. I guess the assumption M$
> makes is that if the system detects an older installer it cannot know
> about Vista's odd manual privilege requirements and does things
> automatically.
http://msdn.microsoft.com/en-us/library/bb384154.aspx
"Windows Vista built-in installer detection prompts for consent when you
run under UAC. A bootstrapper (Setup.exe) built with Visual Studio 2005
always prompts for consent, regardless of what it is installing."
"In Visual Studio 2008, the behavior of Setup.exe changes; it does not
prompt for elevation when it is started. To prevent the elevation prompt,
the embedded manifest of the bootstrapper specifies that Setup.exe run
with a requested execution level of asInvoker."
The proper way of triggering a privilege escalation prompt with Windows
Installer is to set the RequiresElevation property appropriately. Relying
on the installer detection heuristics is a bad idea, not the least because
it is not available for 64-bit installers.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> I wonder if all these issues have been resolved in Windos 7...
>
> Thorsten
FWIW
When I installed the latest Beta on my Window 7 system it was installed
into “C:\Users\Stephen\AppData\Roaming\POV-Ray\v3.7\bin\” without giving
me the choice of install for all users. But then as I have only one
account on this laptop it is hardly surprising.
Also, doesn’t the installer say that it is a Beta too?
--
Best Regards,
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/01/2010 5:25 AM, Fredrik Eriksson wrote:
> Many installers are properly setup to request privilege escalation if
> needed. In some cases, Windows itself will deduce that it is needed and
> automatically prompt for it.
The installer is built with installshield, is aware of Vista, and will
request elevation. However it is also marked as being capable of being
installed by a non-privileged user. Combining both of these causes issues
on vista. Due to the way that Windows Installer works (at least with our
current setup - never mind what other software can or might do) it needs to
be started with admin privileges first if it is to work "correctly".
One of the reasons is that Windows lies if the installer asks if it already
has admin privileges (I use this word deliberately since this is exactly
what happens: it is a deliberate action taken by Microsoft to tell the
installer false information). One of these issues is that during the user
interface portion of the install I can't tell if you're privileged or not.
Given that windows allows you to write to program files (but silently
re-directs the writes), technically escalation is not required and thus
vista doesn't necessarily invoke it. Frankly I've forgotten the fine
details but I can say I've spent way too long on trying to get it to behave
the way I want and basically decided it's not worth wasting any more time
on it. This is fundamentally a Microsoft issue and there's little I can do
about it.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/01/2010 5:19 AM, Warp wrote:
> There is something POV-Ray can do: Ask the user what to do. ("Because of
> <reason xyz> POV-Ray will be installed in <the My Documents folder>.
> Yes/No/Cancel.")
After 15 years of working on POV-Ray, I have learnt one thing in
particular: 99% of users don't read what the installer says, but will just
click through on everything. Some will then complain when it does something
they don't expect.
Example: the installer used to ask if it should register POV-Ray as the
application to open .INI files. This question was clear and required a
yes/no answer. I still got people complaining that POV had 'stolen' the
association for INI files and that this 'was really rude' (or words to that
effect). So, I took that feature out and no longer associate INI files.
To put it simply, the installer has to be written in such a way as to cater
to the vast majority of users *without* causing us support hassles. This
means I have to apply KISS to the design.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> On 24/01/2010 5:19 AM, Warp wrote:
> > There is something POV-Ray can do: Ask the user what to do. ("Because of
> > <reason xyz> POV-Ray will be installed in <the My Documents folder>.
> > Yes/No/Cancel.")
> After 15 years of working on POV-Ray, I have learnt one thing in
> particular: 99% of users don't read what the installer says, but will just
> click through on everything. Some will then complain when it does something
> they don't expect.
> Example: the installer used to ask if it should register POV-Ray as the
> application to open .INI files. This question was clear and required a
> yes/no answer. I still got people complaining that POV had 'stolen' the
> association for INI files and that this 'was really rude' (or words to that
> effect). So, I took that feature out and no longer associate INI files.
> To put it simply, the installer has to be written in such a way as to cater
> to the vast majority of users *without* causing us support hassles. This
> means I have to apply KISS to the design.
I think that in this particular case the path-of-least-confusion would be
for the installer to fail to install by default if the user has no
privileges to install to the Program Files directory (with a clear error
message stating so), and make the option to install into the My Documents
directory non-trivial (but accessible).
But I understand it if it's mostly out of your control if the installer
program is made by Microsoft and not you.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> What do other programs do?
Well, most software simply doesn't support being installed by a
user with restricted rights. It's perfectly normal under Windows.
And if you are on a Windows system where you don't have access to
administrator privileges even through elevation, then it's usually
an environment where you shouldn't be installing software anyway.
The concept of UAC is designed to force developers to write
software which *runs* under a restricted user account. It does
not seem to be designed to encourage software which *installs*
under a restricted user account (although that is mainly due
to naming conventions ... if you think of "my documents" as
your "home" directory, what povray does makes some sense).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There is really no need to start over discussing the benefits and
> drawbacks of Vista rights management! They are for M$ to fix, and nothing
> POV-Ray can do anything about.
I wonder how every other piece of software manages it?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25.01.10 11:28, scott wrote:
>> There is really no need to start over discussing the benefits and
>> drawbacks of Vista rights management! They are for M$ to fix, and
>> nothing POV-Ray can do anything about.
>
> I wonder how every other piece of software manages it?
I don't know a lot of software that can be installed without administrator
rights on Windows...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25.01.10 11:28, scott wrote:
>> There is really no need to start over discussing the benefits and
>> drawbacks of Vista rights management! They are for M$ to fix, and
>> nothing POV-Ray can do anything about.
>
> I wonder how every other piece of software manages it?
I don't know a lot of software that can be installed without administrator
rights on Windows...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I wonder how every other piece of software manages it?
>
> I don't know a lot of software that can be installed without administrator
> rights on Windows...
I wonder why.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> I don't know a lot of software that can be installed without
> administrator rights on Windows...
I've seen one or two, mainly stuff served off a web server to interact with
the web services one particular company offers, like online meeting managers
and such. That, and a few packages like Tcl and some games. If you like, I
can spin up a XP VM and see where an old version of Tcl puts itself when you
ask for a per-user install, since it's a similar sort of language-processing
package.
The ones I've seen recently create a directory for themselves under the
parent directory of "my documents". (I.e., "my documents" isn't really your
"home" directory any more than "Desktop" is.) That might be a better place
to put things in future releases, since it's less obtrusive. And I'm
*pretty* sure you can change the association for files on a per-user basis,
but I might be misremembering that.
Alternately, putting the code under local appdata and the data under roaming
appdata might make a lot of sense also.
Of course, all that assumes you can tell whether you're actually installing
for one user or for everyone. :-)
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/01/2010 5:16 AM, Warp wrote:
> I think that in this particular case the path-of-least-confusion would be
> for the installer to fail to install by default if the user has no
> privileges to install to the Program Files directory (with a clear error
> message stating so), and make the option to install into the My Documents
> directory non-trivial (but accessible).
The problem is I can't necessarily tell if it will fail. If I ask the API
if the installer has write privilege, it tells me "yes". And if it does
write, the writes are then diverted into the user's profile. This is by
design, to 'help' legacy software. It's a massive PITA though.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> On 25/01/2010 5:16 AM, Warp wrote:
> > I think that in this particular case the path-of-least-confusion would be
> > for the installer to fail to install by default if the user has no
> > privileges to install to the Program Files directory (with a clear error
> > message stating so), and make the option to install into the My Documents
> > directory non-trivial (but accessible).
> The problem is I can't necessarily tell if it will fail. If I ask the API
> if the installer has write privilege, it tells me "yes". And if it does
> write, the writes are then diverted into the user's profile. This is by
> design, to 'help' legacy software. It's a massive PITA though.
Sounds like Microsoft.
It reminds me of the decision Microsoft made with Visual C++ when
compiling to 64-bit. In basically every other C/C++ compiler in existence,
if you compile to a 64-bit executable, the 'long' type will be 64 bits.
Except in Visual C++, where it's 32 bits.
Why? Because of all the software out there (and I'm assuming a big bunch
of Microsoft software) which non-portably assume 32-bit longs.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 25 Jan 2010 18:43:20 +0100, Chris Cason
<del### [at] deletethistoopovrayorg> wrote:
>
> The problem is I can't necessarily tell if it will fail. If I ask the API
> if the installer has write privilege, it tells me "yes". And if it does
> write, the writes are then diverted into the user's profile. This is by
> design, to 'help' legacy software. It's a massive PITA though.
This feature is called "Virtualization" and can be disabled by embedding a
manifest with a requestedExecutionLevel.
If that messes with the ability to install POV-Ray without administrative
privileges, I think a better solution is to do what Warp suggested and
just not have that as a default option.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> The problem is I can't necessarily tell if it will fail. If I ask the API
> if the installer has write privilege, it tells me "yes". And if it does
> write, the writes are then diverted into the user's profile.
This is strange. I thought file virtualization would only kick
in on 32-bit Windows for applications which are *not* Vista-aware
(i.e., don't contain a manifest with requestExecutionLevel). If
the installer is Vista-aware I would have expected you get real
information about write privileges.
This may be related to providing the installer as an MSI. Come
to think of it there probably isn't a way to embed a manifest in
an MSI file. Building an EXE might solve the problem (and be more
convenient anyway for the user who wants to install it with
elevated privileges).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I don't know a lot of software that can be installed without
>> administrator rights on Windows...
>
>
> I've seen one or two, mainly stuff served off a web server to interact
> with the web services one particular company offers, like online meeting
> managers and such. That, and a few packages like Tcl and some games.
I thought one of the reasons of not allowing someone Admin rights (eg in a
corporate setting) was to stop them being able to install new programs
(amongst other things)?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"scott" <sco### [at] scottcom> wrote:
> I thought one of the reasons of not allowing someone Admin rights (eg in a
> corporate setting) was to stop them being able to install new programs
> (amongst other things)?
The main reason is to manage rights, to protect the operating system (most
malwares have limited impact when running in non admin). Managing rights is to
ensure that a user will not do something dangerous such as installing a
spyware-based program in a corporate environment and transform a single computer
in a spam server.
This is for corporate environment or schools, public computers...
In a home computer, most users are admin by default, and if not, they can be
admin when they need. So, if a user wants to install POVRay at home, he doesn't
need to ask the admin "hey, can I install POVRay", he can run the software as
admin.
Okay, you win. I will manage to create a portable POVRay, i am downloading the
source code now... For sure, if I have enough time and this works, I'll share
the trick here (or not if the POVRay team releases a portable version before
me!).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rocco" <nomail@nomail> wrote in message
news:web.4b6341e72144d3b02d04182c0@news.povray.org...
> Okay, you win. I will manage to create a portable POVRay, i am downloading
> the
> source code now... For sure, if I have enough time and this works, I'll
> share
> the trick here (or not if the POVRay team releases a portable version
> before
> me!).
Am I misunderstanding your intent, but isn't this issue managed within the
installer NOT the application source code?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The main reason is to manage rights, to protect the operating system (most
> malwares have limited impact when running in non admin). Managing rights
> is to
> ensure that a user will not do something dangerous such as installing a
> spyware-based program in a corporate environment and transform a single
> computer
> in a spam server.
Indeed, which is why it seems absurd that a program installer should use
special means (which are apparently not fully supported by the OS
manufacturer) to try and install anyway even without these rights.
> In a home computer, most users are admin by default, and if not, they can
> be
> admin when they need. So, if a user wants to install POVRay at home, he
> doesn't
> need to ask the admin "hey, can I install POVRay", he can run the software
> as
> admin.
Actually I found on my Vista and Win7 boxes that usually when a program
wants to do something like install or update itself, a box pops up asking me
to give Admin rights for this operation.
> Okay, you win. I will manage to create a portable POVRay, i am downloading
> the
> source code now... For sure, if I have enough time and this works, I'll
> share
> the trick here (or not if the POVRay team releases a portable version
> before
> me!).
I don't really know what you mean here. My idea is that POV installs just
like any other program, which requires Admin rights to install in the usual
place "Program Files". Why the big effort and hacky workarounds to allow
POV to be installed without Admin rights into some bizarre location?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"scott" <sco### [at] scottcom> wrote:
> I don't really know what you mean here. My idea is that POV installs just
> like any other program, which requires Admin rights to install in the usual
> place "Program Files". Why the big effort and hacky workarounds to allow
> POV to be installed without Admin rights into some bizarre location?
For me, here is how I define a "portable" program :
- In most case you have a zip archive (or a self-extracting package).
- You may extract it anywhere you want. Even external USB drive or memory card.
- It can run on the computer without needing any dependencies. The files are
stored in a directory structure.
- No registry writes, no DLL in Windows directory or program files.
- Uninstall is very easy : simply remove the directory where you extracted it
and the operating system remains clean.
The "one-two-three click" installers are the easy way for most people, and can
do more : associate files, install shared libraries for other programs, plugins,
but need more privileges.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
