Celestia Forums

Hi all,

I'd like to get a distribution of Celestia needing no administrator rights for an installation under Windows XP. Which features will be missing if a make an archive of an installed copy of Celestia?

- I guess file extension association
- ?

It seems that before 1.5, administrator rights weren't mandatory, could you tell me why?

Thanks in advance,

Johan (SpaceBel)

Johan wrote:Hi all,

I'd like to get a distribution of Celestia needing no administrator rights for an installation under Windows XP. Which features will be missing if a make an archive of an installed copy of Celestia?

- I guess file extension association
- ?

It seems that before 1.5, administrator rights weren't mandatory, could you tell me why?

Thanks in advance,

Johan (SpaceBel)

File extension association should be the only missing feature if you just copy an archive.

I'm puzzled about why 1.5 should require administrator privileges, while earlier versions did not. There was no fundamental change to the installation process between 1.4.1 and 1.5.

--Chris

Can you tell me which software you use to make the installer? I could have a look to find what's going wrong.

Johan wrote:Can you tell me which software you use to make the installer? I could have a look to find what's going wrong.

The software is InnoSetup. There's a file in SVN call celestia.iss which is the InnoSetup installer script for Celestia.

--Chris

Thanks, I will have a look at it maybe... next monday
Have a nice weekend.

Here is what I found. A non administrator user cannot write HKEY_LOCAL_MACHINE keys.

you could add this line to the celestia.iss file, in the [Setup] section :

So the installer asks first if you want to become root, and if not, Celestia is well installed but the installation displays this message when trying to write HKCR entries (which are HKEY_LOCAL_MACHINE\SOFTWARE\Classes keys) :

Answering "Ignore" finishes the installation normaly, Celestia works, but there is no file extension association.
Actually this method is not very great, nevertheless it works.


An other solution is to create a user profile within Celestia, an action executed the first time Celestia is run, modifying the HKEY_CURRENT_USER\SOFTWARE\Classes. The installer can do that but:

it is still best to keep per-user actions in the installer to a minimum, and instead modify your application so that it can upgrade or regenerate per-user data as needed. This is because only one user is running the installer, but more than one may be running the application. If your only upgrade code is in the installer, other users will be left out in the cold.

Bare in mind, as mentioned before, neither an installer nor an uninstaller should touch HKEY_CURRENT_USER at all. If your application relies on some keys or values beeing created there during the setup process it will fail anyway if a different user logs on. Keys and values under HKEY_CURRENT_USER should only be created or removed by the application.

The uninstaller can't remove anything under HKEY_CURRENT_USER for other users. This is by Windows design. You can't change this. So why would you want to delete them for one user but not for others? It's best practice to just leave them as they are. As said, this is Windows design, and your uninstaller is not the first and the only one that will leave them behind, which is entirely the correct way. Microsoft don't give you a reliable way of deleting this data.

source : http://www.vincenzo.net/isxkb/index.php?title=Installation_Considerations


By the way, both keys HKCR and HKCU can be set by the installer for file association making a conditional installation, if HKCR fails for a non-admin user, only HKCU keys are set for the current user, using a "noerror" flag for HKCR keys so there is no error message. This is almost the same thing as "install for all users" or "install just for me" option in some installers.

The version of Innosetup itself is also very important, if every program that is being made with it would take the newest version, all their installers would install on vista without the UAC complaining.

Also with what version of Visual Studio is it compiled, done any patches updates in between?
Those things can really matter.

Johan wrote:Here is what I found. A non administrator user cannot write HKEY_LOCAL_MACHINE keys.

you could add this line to the celestia.iss file, in the [Setup] section :

Code: Select all

PrivilegesRequired=none

So the installer asks first if you want to become root, and if not, Celestia is well installed but the installation displays this message when trying to write HKCR entries (which are HKEY_LOCAL_MACHINE\SOFTWARE\Classes keys) :

Answering "Ignore" finishes the installation normaly, Celestia works, but there is no file extension association.
Actually this method is not very great, nevertheless it works.


An other solution is to create a user profile within Celestia, an action executed the first time Celestia is run, modifying the HKEY_CURRENT_USER\SOFTWARE\Classes. The installer can do that but:

it is still best to keep per-user actions in the installer to a minimum, and instead modify your application so that it can upgrade or regenerate per-user data as needed. This is because only one user is running the installer, but more than one may be running the application. If your only upgrade code is in the installer, other users will be left out in the cold.

Bare in mind, as mentioned before, neither an installer nor an uninstaller should touch HKEY_CURRENT_USER at all. If your application relies on some keys or values beeing created there during the setup process it will fail anyway if a different user logs on. Keys and values under HKEY_CURRENT_USER should only be created or removed by the application.

The uninstaller can't remove anything under HKEY_CURRENT_USER for other users. This is by Windows design. You can't change this. So why would you want to delete them for one user but not for others? It's best practice to just leave them as they are. As said, this is Windows design, and your uninstaller is not the first and the only one that will leave them behind, which is entirely the correct way. Microsoft don't give you a reliable way of deleting this data.

source : http://www.vincenzo.net/isxkb/index.php?title=Installation_Considerations


By the way, both keys HKCR and HKCU can be set by the installer for file association making a conditional installation, if HKCR fails for a non-admin user, only HKCU keys are set for the current user, using a "noerror" flag for HKCR keys so there is no error message. This is almost the same thing as "install for all users" or "install just for me" option in some installers.

So, it sounds like Celestia itself should be modified to modify the HKCU section of the registry and create the cel and celx associations. Is that the best solution?

--Chris

The best solution in my opinion would be to add the option "associate file extension" in a Celestia menu. It would add keys to HKEY_CURRENT_USER.

The other solution would be to make an installer which asks if we want to install "for all users on this computer" or "just for me", in this case it add keys either to HKEY_LOCAL_MACHINE or to HKEY_CURRENT_USER. The second solution isn't incompatible with the first solution, actually the "associate file extension" menu should be there in all cases.

Johan wrote:The best solution in my opinion would be to add the option "associate file extension" in a Celestia menu. It would add keys to HKEY_CURRENT_USER.

The other solution would be to make an installer which asks if we want to install "for all users on this computer" or "just for me", in this case it add keys either to HKEY_LOCAL_MACHINE or to HKEY_CURRENT_USER. The second solution isn't incompatible with the first solution, actually the "associate file extension" menu should be there in all cases.

Dumb question: Would it then work, if I install 2 versions of Celestia (let's say 1.5.1 and 1.6.0) on the same windows, and after starting the 1.5.1 say associate Cel:\\URLs. They would then be associated with 1.5.1.

What would happen if I later use 1.6.0 and say there associate Cel:\\URL? Would they without problems be associated to 1.6.0?
And could I later switch them back to 1.5.1?

For example to test the behaviour of something in different Celestia versions.

Regards,

Guckytos

>>Would they without problems be associated to 1.6.0?

I guess so. It's just deleting and creating some keys in the registry, if Celestia uses the same keys between each version, it's just updating the Celestia installation path in the registry.