As you know, Windows has a "Add/Remove Programs" system in the Control Panel.
Let's say I am preparing an installer and I want to register my program to list of installed programs and want it to be uninstallable from "Add/Remove Programs"?
Which protocols should I use. Any tutorials or docs about registering programs to that list?
I am coding with python and I can use WMI (Windows Management Instrument) or Win32 API. IMHO, it is done with Registry keys but I am not sure with it.
I also want to execute an uninstaller upon the Uninstallation to remove installed files. Any related docs or tutorials are highly appreciated. Thanks.
As stated on IRC:
"Windows keeps its uninstall information in the registry"
Its in HLLM\Software\Microsoft\Windows\CurrentVersion\uninstall\ keys.
You need a few things from the Win32 API, but I belive there's a fair amount of Python support for the win32 API.
Basically, a key in ...\Uninstall\ with a unique name (like "MyApp") with a few special values stashed in there. Add/Remove programs looks through there.
Its pretty self-explanatory.
If you are developing for Windows platform I think using Windows Installer from Microsoft won't be a problem.
You can check documentation of Windows Installer from Microsoft.com Windows Installer Page
Inno Setup is open source so perhaps you can get some ideas from that.
Related
I work at a software company,
And we have a product for Windows OS that is installed using a custom installer.
We want to have an automated system that will run the installer on a daily basis, make sure that everything is installed and functional (application installed, appears in Add/Remove, shortcut created, registry keys created, browser addons installed, etc)
I also want to test the functionality of the app by using a GUI macro of some sort.
Is there anything like what i'm looking for?
We ended up using TestComplete 9 from SmartBear: https://smartbear.com
Its doing exactly what we need, and it has many advanced features like connecting to remote virtual computers for parallel testing.
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've nearly completed developing a game for Windows and I'm curious where I should have the installer install it. I know it used to be in "Program Files" but has that changed under Vista?
I know that World of Warcraft now installs under Users/Public/Games... what is the Microsoft-recommended location for games?
In Vista, the recommended directory is still %PROGRAMFILES%.
Note that in Windows 7, Microsoft has enabled the creation of true per-user installations, including support for per-user Program Files. This is a feature of Windows Installer 5.0, and you can read more about it here:
http://msdn.microsoft.com/en-us/library/dd408068(VS.85).aspx
You should use the Environment variables.
Namely %PROGRAMFILES% for you.
Just read the question a little more thoroughly. From my experience of Vista, most of the gubbins still install to %PROGRAMFILES%. Perhaps the /users/public... path is somewhere where things can install (and update) without having to get admin perms all the time. (A complete guess)
Looks like you should use SHGetKnownFolderPath to ask for the location of the FOLDERID_Games KNOWNFOLDERID.
EDIT: Nope, doesn't look like that is right. This thread has a discussion of FOLDERID_Games and notes that it is a virtual directory. This knowledgebase article discusses the Windows Vista Games Explorer. And this article has some more Vista specific information.
Sorry - this has turned into a non-answer but maybe the links will help you find the answer.
The recommended directory is still Program Files, as everyone has said. However, if you want a per-user install, you could install it in the AppData folder. I know Google Chrome does this to allow installation without being an administrator, and also for user-specific installation.
I'm trying to install a DMO which requires me to write to HKCR\DirectShow\MediaObjects\Categories\57f2db8b-e6bb-4513-9d43-dcd2a6593125, this registry path is protected by TrustedInstaller and it seems that this protection is new in Windows 7 (it work on previous platforms).
How am I suppose to install DMOs?
There are plenty of places that suggest to take ownership on the this registry key but this just doesn't feel right.
BTW, were using boilerplate Wix3 to write the registry values.
The Windows Installer cannot be used to update Windows. I know it sounds funny but Windows Installer is for "applications" and the Trusted Installer is for "the operating system". To update pieces of the operating system, you need to use an operating system service pack or KB.
If this is a documented place in the registry that you are supposed to be able to extend then I would guess it would be necessary to contact Microsoft about the key being protected. My guess would be that it is a bug.
If it is a bug in Windows then Microsoft hopefully would provide a work around or fix. Maybe the answer is to take ownership of the registry but I agree that doesn't seem right.
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 !