If you want to implement a time limited trial for an application you would probably want to leave behind some flag (registry key, file etc) so a program couldn't just be re-installed.
Are there any schemes that allow you to do this while still passing the various Windows Certification programs?
Generally :-
Applications must correctly and fully
uninstall from the machine. This
includes removing files, registry
keys, GAC assemblies, database tables,
metabase settings, active directory
accounts, etc. Anything left on the
system after uninstall, including
system components installed by the
application, must be documented and
justified - Windows Server 2008 Software Logo Secification - 2.3 Uninstall Cleanly
You are taking the philosophy of only allowing installation if a flag is NOT there, which means you need to leave the flag there after uninstall. Also this fails when the user finds the flag and deletes it themself.
Better is if you turn it around and only allow the program to work if a flag IS there. This flag would be a registration key that has the date of expiry encrypted into it. When the program expires or is uninstalled, you delete the flag.
I implement this by making my users come to my site to register and get a free trial key. There are probably other ways, but I like this one because it also allows me to collect info about who is trying my program.
If your app is connected to the Internet, then you could store information on your own server about whether it has been installed before or not. However, this almost certainly needs to be designed in from the start with potential investment in hosting your own server to be available to check against.
I'm sure there must be plenty of cases where files are left behind after an uninstall that are perfectly acceptable. For example, I wouldn't expect all my documents to be deleted when I uninstalled Word.
Related
I am working on a VB6 application which has many executable and an Active X dlls.
And there are to be updated in c;lient machines to lates version once in a while which i am asking the user to update manually.
Can you please suggest me a way using which i can update it automatically from the files that can be available online.
Thanks.
Windows Installer has features supporting Patching and Upgrades. Using those techniques you can create various levels of "upgrade" packages.
Your application would need a separate "update" utility that is spawned when the user approves updating, perhaps in response to a prompt your program raises after checking for new versions.
This updater would check the current version and the remote site's catalog of updates to pick the appropriate package, download it to a temporary location, start Windows Installer to process the package (or packages, sometimes you might need to run several Installer runs), and clean up the temp location. Then you might offer to restrt the updated application or on some occasions need to reboot.
This updater would be a fancy form of the common "installation bootstrapper." As you can tell it needs some "smarts" in order to tell what package or packages to download and install in what sequence, when it needs to request rebooting, etc. This would probably be based on a downloaded "rules script" it obtains as part of selecting a valid update option.
After all, sometimes you can just apply a minor upgrade or patch upgrade, sometimes you need a more complete install or entire reinstall.
If your needs are extremely simple (just an EXE and maybe a few DLLs and OCXs - preferably using reg-free COM) you may not need to go to these lengths. However when you start adding in other considerations like multiple programs, data directory creation and security settings, possibly running a settings file conversion or even database conversion, DCOM, firewall, etc. configuration, database drivers or providers, etc. things get complicated quickly. Too complicated for simple snatch and grab updating.
And admin rights/UAC issues are a factor so you'll probably have to deal with privilege elevation.
None of this is trivial stuff. There are people who do little more than construct and test such deployment systems as their entire job.
If you use soemthing like Inno setup to install the application then an update is simple a matter of running that periodically.
You can either detect there is a new version available by checking a web site/local server, or just prompt to run the update after X days.
Many questions on SO say "Windows developer guidelines" or "windows design guidelines" say that you shouldn't write temporary or program data to the Program Files area, but as far as I can tell none of them actually link to a piece of documentation that says as much. Searching the MSDN has yielded me no results. Windows will make the area read-only, so it can be enforced by the OS, but that doesn't mean developers didn't try to write there anyway (e.g., when porting older, XP and earlier based programs forward.)
I realize that it seems odd to ask about it this late into Windows development (since, as a commenter below pointed out, has been enforced by the OS for more than a decade), but a document that says so is sometimes necessary to satisfy people.
With that in mind, Does Microsoft have a document published stating we shouldn't write application data to the Program Files area, and if so, where is it?
From Technical requirements for the Windows 7 Client Software Logo Program:
Install to the correct folders by default
Users should have a consistent and secure experience with the default
installation location of files, while maintaining the option to
install an application to the location they choose. It is also
necessary to store application data in the correct location to allow
several people to use the same computer without corrupting or
overwriting each other's data and settings.
Windows provides specific locations in the file system to store
programs and software components, shared application data, and
application data specific to a user:
Applications should be installed to the Program Files folder by default. User data or application data must never be stored in this
location because of the security permissions configured for this
folder (emphasis added)
All application data that must be shared among users on the computer should be stored within ProgramData
All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in
Users\<username>\AppData
Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as
fonts or drivers
In “per-machine” installations, user data must be written at first run and not during the installation. This is because there is no
correct user location to store data at time of installation. Attempts
by an application to modify default association behaviors at a machine
level after installation will be unsuccessful. Instead, defaults must
be claimed on a per-user level, which prevents multiple users from
overwriting each other's defaults.
And I'm quite sure that there's similar stuff for every Windows version of the NT family going back to Windows NT 4 or even earlier.
See also this question.
Edit: the original link in this post to the Windows 7 Logo program exists no more. Here you find the current link to the Certification requirements for Windows Desktop Apps. See Section 10, Apps must install to the correct folders by default
In later versions of windows (Vista, 7 and of course server versions) access permission are restricted for "special folders" including "Program Files". Even if your program is elevated to have sufficient privileges to write to this folder it is still a bad idea.
I don't know of any guidelines that state this but there is a list of special folders and what they are meant for. The fact that there is a special folder for nearly all types of data I can image means there is no need to use the program files folder.
I know registry is not a best place to hide something.
Right now I'm writing a Licensing software that require to save trial usage information like first install date on registry, etc.
What hive in Windows Registry that meet this criteria :
Not easily discovered by accident by the Users.
The value can be shared among Windows Users.
Didn't mess up Windows and Registry Cleaning Utility not consider this value as a garbage.
If can, it work without administrator privileges on Windows Vista and Windows 7
Edit : I have excluded items # 4 because it is not possible with item # 2, based on answers from David Heffernan
There are no shared locations in the registry that can be written to without admin rights. So your conditions 2 and 4 cannot both be fulfilled. You need to do this with a file I believe.
If you are prepared to drop condition 4 then you need to store it under HKLM so that it is shared. The obvious place is HKLM\Software\YourCompanyName\YourProductName. Naturally you would encrypt the data to avoid tampering. Once you have done that then you don't really care whether or not your users discover it.
What are you trying to defend against? It sounds like you're putting a lot of effort into "don't let people change their system clock to extend their trial" but none at all into "don't let people edit the Registry key to extend their trial" or "don't let people share Registry keys between machines to turn trials into full keys for free". I actually think those are far more likely. Any software that yelled at me for changing the clock on my own machine would get uninstalled in a hurry.
I recommend you don't try to do this yourself. There are licensing libraries you can use that have thought of the various ways people try to trick software. But if you must, because you want to try it, then take some time to distinguish what happens at install, which might require admin rights, from what happens while you're running and checking, which should not. An app that has to run elevated for no other reason than writing license info to HKLM once a minute would also be uninstalled in a heartbeat from my machine.
So at install, write something obscure/encrypted to a Registry key under HKLM. Make it something that's not super helpful to copy from machine to machine, while you're at it, by combining say a date, an email address, and some other information. At runtime, your code should look partly at the unchanging Registry entry or entries and partly at something else that can change easily, like a file under AppData, an HKCU key, or the current date, to decide whether it's ok for the app to run. (At runtime, if the HKLM key is not there or fails a checksum or whatever, refuse to run and ask for a reinstall. Reinstall can worry about whether the person is trying to get infinite free trials.) Focus on the main ways people try to trick licensing schemes and also on being a usable application. Insisting on elevating or preventing general use of the machine fails on the usability side.
You can, on install, change permissions of somewhere in HKLM so that all users have write access.
If you choose a place other than HKLM\SOFTWARE\Your Company Name\something than you're being foolish.
I have a service installation that in order to get it to work on Win2k, I had to include instsrv.exe in the installer, since Win2k doesn't include sc.exe (which I use for XP and up) and instsrv.exe is not always installed...so I cannot count on it being there. (instsrv and sc are both used to create/install the service on the system).
I have not been able to find the license terms or distribution rights for instsrv however. Is there going to be a legal issue with me including this Microsoft exe in my own installer and therefore distributing it to the customers of the product? If you can point me to an actual license document for this exe it would be greatly appreciated.
The instsrv.exe program appears to come from the Windows 2003 Resource Kit, which you can download freely from Microsoft. The referenced page indicates that when you install it, you'll encounter the EULA (End User License Agreement), which would be where you'd read about the license terms regarding things like redistribution.
You should read that agreement yourself. The way I read it, you can't bundle the Kit with your installer, though you could certainly arrange to have it downloaded automatically and have its own installer invoked by yours, with your end user having to click to accept the Microsoft EULA at that time.
What about using a different approach? I believe for a simple service installation there are probably only a few registry keys or something to tweak. Maybe a simple script (Python or such?) could do the job as well.
I'm no legal expert, but is the issue the use of instsrv.exe or that it's lying on the PC until you uninstall your product?
Would it be redistribution if you craft your installer in such a way that you merely package instsrv.exe, unpackage during the install process, run it via a custom action, then let the installer cleanup process delete it from the temporary location?
As a big sidestep, you could change installers to WiX v3. They have standard custom actions to install services. You get the added Msi easily active directory integrated bonus. You could go with something else entirely but I assume this is a very last resort.
In the end, services are nothing more than registry entries in a specific format so you are not entirely limited to using those programs. You just get the bonus of blaming Microsoft if either instsrv or sc happen to blow up the registry.
I just noticed that Chromium was installed in AppData in both Vista and XP. If Google does that and if other applications does this, than is that becuase there is some form of protection? Should we write installers that does the same thing as Google?
Windows still lacks a convention for per-user installation.
When an installer asks whether to install for the current user or all users, it really only refers to shortcut placement (Start Menu; Desktop). The actual application files still go in the system-wide %PROGRAMFILES%.
Microsoft's own ClickOnce works around this by creating a completely non-standard %USERPROFILE%\Local Settings\Apps (%USERPROFILE%\AppData\Roaming on Vista / Server 2008) directory, with both program files and configuration data in there.
(I'm at a loss why Microsoft couldn't add a per-user Program Files directory in Vista. For example, in OS X, you can create a ~/Applications, and the Finder will give it an appropriate icon. Apps like CrossOver and Adobe AIR automatically use that, defaulting to per-user apps. Thus, no permissions issues.)
What you probably should do: if the user is not an admin, install in the user directory; if they do, give them both options.
One advantage nobody mentioned are silent auto-updates. Chrome has an updater process that runs all the time and immediately updates your chrome installation.
I think their use-case is non-standard. They need a way to fix vulnerability issues (since it's a browser) as soon as possible. Waiting for admins approving every single update company-wide, is simply not good enough.
As far as I can tell, the only reason why Chrome installs into the Application Data folder is so that non-admin users can install it.
The Chrome installer currently does not allow the user to pick where the application is to be installed. Don't do that – instead, give the user a choice between a per-user (somewhere like App Data) and computer-wide (Program Files) installation.
Windows 7 and Windows Installer 5.0 provide real per-user installation capabilities now.
http://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx
You can sort of fudge it in Vista and XP by using ~/AppData/Local or the equivalent like Chrome does. Microsoft themselves use this for the ClickOnce installers.
So at least on Windows 7 and beyond the solution is simple.
Frankly, I have yet to see the first installer that really allows both per-user and per-machine installations. Many installers offer this option in their GUI, but the setting only affects where the shortcuts etc. go -- the binaries always fo to %ProgramFiles%.
In fact, it is pretty hard to create Windows Installer packages that allow both kinds of installs, to say the least. With the advent of UAC, I'd say its is impossible: Per user installations must not require elevation, per machine installations have to. But whether an MSI package requires elevation is controlled via a bit in the summary information stream -- there is no way to have user input have impact on that.
Whether per-user or per-machine is the better choice greatly deoends on the application. For small packages, however, I tend to prefer per-user installations. Besides being slightly more user-friendly by not requiring an UAC prompt or runas, they also signalize the user that the setup will not do much harm to the computer (assuming he is a non-admin).
The Chrome installer really ought to allow global installation (with elevation) in addition to per-user. I don't want to have to maintain an installation for every user; I want to be able to centrally manage upgrades and so on. Chrome doesn't allow that.
That said, the option to install per-user is quite nice, as it means no permissions issues.
Just so you people know, Google has created an MSI installer for global system installation and management. It's located here:
https://www.google.com/intl/en/chrome/business/browser/
I do not see anything in %PROGRAMFILES% on Win7. Looks like Chrome must be installed for each user on the machine.
Perhaps the true reason of doing this is faking number of Chrome installations by few times ! Thus making it first browser in the world !