Reason for this question:
http://nsis.sourceforge.net/Reference/SetShellVarContext
and
http://forums.winamp.com/showpost.php?p=2326213&postcount=5
I am kind of puzzled here... what is actually most current way to handle this Windows specific installation/uninstallation feature, so that installer/uninstaller would automatically write, for example, registry to right place ( if Admin, then to HKLM, if specific user, then to HKCU )?
What makes me worried here is that the built-in command is pre-NSIS 2.0 introduced feature ... but
MultiUser.nsh
is pretty updated and from Joosts comment I start to think it ( using SHELL_CONTEXT ) might be better solution. Could it be right assumption here?
My goal is to make current Installer more flexible for future changes and development needs, including multi-user capabilities ( if, for example, Windows Certification requieres such support ). Ability to automatically depend on HKLM/HKCU, but not statically only on HKLM is pretty good think, right?
Maybe I just mixing File handling in current User context and Registry handling in current User context?
Any guidelines here would be much appreciated.
MultiUser.nsh uses RequestExecutionLevel and SetShellVarContext.
SetShellVarContext controls where the shell special folders like $appdata resolve to and it also controls the SHCTX pseudo registry root key. This means that you should write uninstall info and file extension registration under the SHCTX key if you wish to support per-user and all users install modes in the same .exe
Related
I am writing desktop programs for windows and when I need to put some program to start automatically I always use one of those options:
1 - Put a shortcut to the program in the startup group
2 - Create a value key on Windows Registry ("SOFTWARE\Microsoft\Windows\CurrentVersion\Run")
Which of this options is a best practice?
It depends on how much weight you would apply to the following questions:
As a user, should I be able to deactivate the automatic startup easily, even temporarily?
As a user, should I get the feeling that the developer trusts me to know what I'm doing?
Clarification:
If I have a shortcut in the AutoStart folder, I know that I can quickly disable this part by myself and the developer trusts me to do this.
If I don't have this visual clue, I have to actively look for it using more-or-less arcane tools (speaking from experience here).
If the automatic startup is essential for the correct function of the program, by all means, put it somewhere I can't get to it. But if it's a nice-to-have thing, like a "quickstarter", then please don't.
There's lots of questions about installers but I haven't seen one about whether or not to actually use one in the first place.
What is the logic behind using them in the first place? Can't the user just extract it somewhere? But I guess it depends on the target user.
And on the subject of the actual setup: Can't that be done on the first startup?
It very much depends on your target audience, and what your installer needs to accomplish.
If your audience is technically savvy, and the installer just has to extract some files, and create shortcuts, I probably wouldn't bother.
If you need to modify system variables, register services, etc, definitely create an installer to make life easier for your users - regardless of how technically savvy they are.
You can always offer the option of installer / no installer, and let your users decide what they want. The number of downloads and resulting support requests will tell you whether you should utilize one or not.
And on the subject of the actual setup: Can't that be done on the first startup?
uTorrent used to do this (I'm not sure if it still does... I update automatically) and I found it a little confusing at first, since I'm used to installers. For users that are possibly clueless though, it's perfect.
For more complicated applications that have multiple files installed to several locations, I think it's better to have an installer. For a series of products we produce where I work, we have several 'flavours' of installer for each product: auto-update installers can be smaller as we know the user already has prerequisites. New users, though, get a larger installer.
I can't see any reason not to use an installer. When you use something like Inno Setup, creating the installer is no more difficult than creating a zip file, and you don';t have to explain to the user how to install.
Having an installer will help your users a lot.
The application will be installed at the right place
The user won't have to set links in program files himself, or copy the extracting content you suggest in a directory
Your application will looks more professionnal
Moreover:
The user will know that using the uninstall system of windows will safely remove your application without affecting the system
You need something which can set up the registry and install prerequisites before starting the app, that's why you need an installer :)
Including a well designed installer can also add value over the lifetime of the application by enabling the application to be updated and enabling the application to be uninstalled cleanly. Eventually the user will want to uninstall the application, and the ideal is to leave their computer in the same state as prior to installation.
I'm working hard on making my product work seamlessly on Windows 7. The problem is that there is a small set of global (not user-specific) application settings that all users should be able to change.
On previous versions I used HKLM\Software\__Company__\__Product__ for that purpose. This allowed Power Users and Administrators to modify the Registry Key and everything worked correctly. Now that Windows Vista and Windows 7 have this UAC feature, by default, even an Administrator cannot access the Key for writing without elevation.
A stupid solution would, of course, mean adding requireAdministrator option into the application manifest. But this is really unprofessional since the product itself is extremely far from administration-related tasks. So I need to stay with asInvoker.
Another solution could mean programmatic elevation during moments when write access to the Registry Key is required. Let alone the fact that I don't know how to implement that, it's pretty awkward also. It interferes with normal user experience so much that I would hardly consider it an option.
What I know should be relatively easy to accomplish is adding write access to the specified Registry Key during installation. I created a separate question for that. This also very similar to accessing a shared file for storing the settings.
My feeling is that there must be a way to accomplish what I need, in a way that is secure, straightforward and compatible with all OS'es. Any ideas?
Do you have to have it in the registry? If not, put it into a simple file, writable by everyone. Writing to HKLM requires additional privileges for a very good reason.
I'm new to here (otherwise i would've left a comment) and i'm not a windows guru, but...
imho the premise is wrong:
there's a reason if a non-elevated user cannot modify registry keys or directories read by all users (like Users\Public by default)
i think that allowing any users to modify a small set of global application settings may be disruptive for the experience of the other users that didn't expect their settings to be modified
on the other hand i don't know your use cases...
could you please specify why all users should be able to modify these settings?
and if indeed all users have to be able to do it... why can't you make these settings user-specific?
Personally I hate auto-created desktop shortcut icons, but some folks seem to think that unless your installer clutters up your desktop, it hasn't worked correctly!
Are there definite guidelines for this (for Windows?)
(Having a "Leave clutter on my desktop?" checkbox in the installer is one option, but to my mind, that's just put MORE clutter into the installer...)
From here: https://learn.microsoft.com/en-us/windows/win32/uxguide/winenv-desktop
If your users are very likely to use your program frequently, provide an option during setup to put a program shortcut on the desktop. Most programs won't be used frequently enough to warrant offering this option.
Present the option unselected by default. Requiring users to select the option is important because once undesired icons are on the desktop, many users are reluctant to remove them. This can lead to unnecessary desktop clutter.
If users select the option, provide only a single program shortcut. If your product consists of multiple programs, provide a shortcut only to the main program.
Put only program shortcuts on the desktop. Don't put the actual program or other types of files.
My take is this: the installer must ask me if I want a desktop icon - to which I can reply yes or no.
Any app that just blindly and without asking installs its icon on my desktop is a bad installation in my opinion.
Ask for permission - if I deem your app important enough to me personally, I might say yes (but most likely I won't). Give your users a choice - don't just assume since it's your app, it's so darn important to everyone that everyone will want to clutter up their desktop with your program icon.
The same goes for the installation directory - unless you have a very good technical reason why you can't install anywhere, allow me to change the program's installation target directory. Not everyone is a big fan of the "c:\program files" folder hierarchy (I'm not, for one - I like to keep my apps in C:\bin for instance).
So in general: any decent installer should ASK the user installing for these things and present sensible defaults - but always give me the option to change the settings to my liking (to my standards).
I don't know of any meaningful guidelines, other than your conscience. As a programmer, I sympathize: I don't want icons on my desktop, either :-) However, having watched non-technical family members struggle with installing software and then trying to run it, I think it's worth noting that
1) There are more non-techies than techies
2) Techies can cope with checkboxes on installers
Based on that, I usually go for having a checkbox on the installer for creating icons, which defaults to on. I don't mind anything other than the "always create icons" approach. (I'm looking at you, Adobe.)
I think that depends on what you see your client doing with the app, the level of the client's expertise with computers and how frequently you see him using it.
If the client is not very well versed with computers he would prefer to have the icon on the desktop where he can access it. If you target market is experienced users you don't need to bother because he can make the icon himself if he wants it.
If the application is for daily frequent use like a web browser the client would want it on his desktop for quick access.
Finally the decision rests on you. If you're being obnoxious you can create 4 icons on the desktop (I've seen apps that do that).
I don't think asking for permission is a bad idea. After all the installation needs to be done only once and it's just one checkbox to tick.
I've no particular love for desktop (or quick launch) shortcut icons either, but I think that you should still give your users the option in the installer to install neither, one or both of these shortcuts.
Depending on how computer literate your users are (if it's possible to determine this) you can default the two options to either enabled or disabled accordingly.
To understand what I'm asking, it's important to distinguish from among the several uses of SUID in Unix.
I have a project that uses an executable in the user's PATH which is owned by the project and which has the SUID bit set. In this way, when it runs, it runs in the context of the file's owner, not the calling user. This way, it has access to things that the user does not, and thereby these things are protected from the user by normal file system protections. This works reasonably well. Plans are to move the project to a client-server architecture but that's going to take some time. In the mean time, how can I replicate this type of behavior on Windows systems?
Note that the project's executables do not call the SETUID library call though, frankly, that would be a great feature to add, in my opinion, given what the project does. The project does not need system root privileges. It's first security concern is that it needs to protect its own files from the user (which is simply any user other than the file owner) and it would be very nice if it had the ability to switch to "user context" to access the file system as if it were the calling user. (In this way, it could more easily determine what is OK for the project to touch and what is not.)
The project is written in a combination of C and Java - a C program with SUID set calls the Java code...
I am keen to know all such mechanisms, and am especially focused on those which are:
Suitable for C and Java, and;
Easy to implement for non-Windows programmers, and;
Require minimal coding unique to Windows.
If some solutions are superior, please share your thoughts on whatever you are aware of in this regard.
NOTES:
LogonUser: Requires a password in plain text. How can that be an answer?
RunAs: Requires password be entered at PROMPT! ...As with LogonUser only worse; I don't see how this is an answer.
Cygwin has an excellent discussion on how they do this without requiring the user password here: Using Windows security in Cygwin
Basically they install a custom LSA authentication package that provides security tokens without requiring a password. As a fallback, when the authentication package is not installed, they use the undocumented NtCreateToken API.
An application wanting to impersonate could make a cygwin setuid call before calling java.
I don't think there's an equivilent of SETUID in Windows, but you can launch a process as another user. If you are using C, there are really only two major Windows Specific functions you'll need to look into:
LogonUser
CreateProcessAsUser
The docs for those functions are pretty good, so it shouldn't be that huge of a challenge. Basicly, you'll use LogonUser to impersonate the user, then CreateProcessAsUser to launch the JVM as that user.
You could also look at the RUNAS command, but I'm not sure if that would meet your needs or not.