There are a lot of setups out there which just copy some files and then run the application. I often wonder why they really need Administrator rights at all. So IMO, if you want to create a setup for your product you should really consider the following question:

Does your setup really need Administrator rights?

I often wonder why some setups need administrative rights at all. Many setups just fail to run if someone isn’t running with highest privileges.  But why can’t they just copy their files to a directory of my choice. I have a friend who doesn’t like to install an application. He is always lucky if he finds a zip download instead – otherwise he doesn’t use it.
If I choose to place product files in the protected “Program Files”-folder, well then a setup could elevate itself because it detects an inaccessible folder. There are setups out there which elevate themselves right before copying the files – with some effort this is possible for none MSI setups, too (run a second elevated process for copying, e.g.). However it is always possible to tell the user that the target folder isn’t accessible.

HKEY_LOCAL_MACHINE

Secondly, is it really necessary to create registry keys in the local machine tree? Well, if you want to hide your secret registration information that is a good reason. A second good reason will be if you want to write system wide and valid data which should not be messed around with — like installation information for uninstalling. However you should also consider to store this kind of data in the current user tree if the user isn’t an Administrator! In this way the user can remove the product and you support people who are not members of Administrators group like office staff, students and of course relatives who have an Administrator in their family. Furthermore, if you go one more step you could move the registration stuff into your application. In this way your application can restore its data and even be saved on a USB data drive.

Fairly everything can be done in your application:

• Create your registry keys. But keep in mind to check the return value of TRegistry.OpenKey!! If it fails try to evade to the current user tree.
• Store your files in the AppData folder of the current user. Don’t save ini files or other data in your binary folder! In this way you also support several users/profiles on one system and removes the need of virtual machines for your app. Also consider to provide import and export features (simplest way: open the storage folder in Windows Explorer).
• Services can be created and run without any setup. An example is my RunAsSys tool which even asks you for elevation if necessary. In this way the service only runs when needed. What a nice feature!
• COM servers can be registered programmatically. Well, you need elevated rights to do so.
• On XP: If you need more privileges you can use a second process (e.g. in the background). Kay Brun’s SuRun takes the place of UAC in Vista but with more comfort and better handling of “who wants to be elevated”. It even supports ShellExecute verb (again see RunAsSys sources)
  On Vista: Benefit from the UAC. Use COM Server Elevation, ShellExecute and so on. There are plenty of examples in the JWSCL and on the internet.

and

• DLLs in your folder are loaded at first. Disk space isn’t an excuse for this because Windows doesn’t allow to override an existing DLL. All DLLs in the Windows folder always remains on your system (WinSxS – Side by Side). If you create DLL files which aren’t used by the 3rd party programmers, don’t make them public. They don’t belong into the Windows folder.

Admin + App := Admin + Setup;

I told you that there are setups which elevate, copy their files and then run the application. Did you know that this application is run with the same administrative privileges as the setup? If the setup isn’t written to lower the rights, the application is started with Administrator rights! Did you notice?

Some applications are trying to access the local machine registry key at the first start – to do their init stuff. Since I do not run these applications from the setup, they often fail to start. I think only few people know about the “run by setup for the first time”-issue.

So if you can avoid writing to secured places like windows folder/registry/”Program Files” you could transfer some initial routines to your application. It would mean less “you have to reinstall the product”-errors when your app tries to start and, of course, less “I reinstalled your app for the 20th time and it doesn’t work”-customers.

Don’t hesitate to use “elevate yourself ” feature (ShellExecute + runas + ParamStr(0) or COM elevation) if you need administrator rights. But use it only if you need it.

Conclusion

Nowadays, imo, it is all about installation. Don’t misunderstand me! Setups can be nice and comfortable. Installation of JWA and JWSCL is still made by hand and I’m in the middle of creating a setup FOR YOU!  But today, setup applications grew to big monsters which take a lot of time to start (”Initializing…”), to run (”Registering {139D6D44-6008-F26F-AA2B-214A31915CCD}…”) and sometimes to understand (”Error xxx. DLL not registered”).  Many years ago (good old DOS days *g*), a setup just copied files, created directory structures and setup the sound card for the first time (often the setup could be used to change that later). In times of Windows, setup applications became sometimes more than the applications which they install. Well, I must say: “Times became more complicated”.

I would like to see more and more apps which are independent of the machines they run on. You don’t have to abandon your setup routines though! Think about a setup that allows a customer to run your app directly from the setup itself – without installation! That it is possible shows us Embarcadero with “Instant-On” (Olaf’s Thoughts). Delphi on a USB data store – I’m looking forward to it!